【読了】プロジェクトマネジメントの基本が全部わかる本

『プロジェクトマネジメントの基本が全部わかる本』を読んだ。
交渉とか関係性とかそういうあたりから始まってるのがよかった。

Coursera にある Google のプロジェクトマネジメントのを取りあえずやりきるまでは我慢してた。

能勢さんも最近ブログ書いてた。

「プロジェクトマネジメントの基本が全部わかる本」を読んで | ノセノセブログ
https://2nose.com/blog/2022/12...

どう作るか？

何を作るかはもちろん重要なのだけど、それに加えてどう作るか？が重要だと思うのだけど、なんかその辺が足りない案件があるなぁと思うことがあり。
交渉に始まり、要件の整理、ヒアリング。

作りたい物、予算、スケジュールという関係をいかに調整しながら進めていくか。
それを進める人と人の関係をいかに構築して進めていくか。
細かいところから相互に信頼を積み重ねないと何もできないよなぁと。

失敗パターンの1つとして関係性の話も書かれていた。

どちらかに落ち度があればそれを指摘するのもまぁ仕事だから仕方ない。
それがゴールに向かう上でプラスに働くのであれば。
契約の話でもあるから一概にあれこれ言い切れる物でも無い。

結局の所それで、ステークホルダーの心が離れれば、プラスには向かわないと思うのだけど。
「仕事だから」と無難にこなして終了。

スキルセット

スキルセットとかを見ていても、普段やっているところとやっていないところが結構わかれる。
やっていないところはやれと言われてもなかなかうまいことできない気もするなぁ。

自分の立場でいうと、下請けで開発チームって感じだから担当するところが違うところはあるんだろうけど。

とはいえ、その立場ででもまだまだできることはあるだろうし、リスクの提示はもっとしていけるだろうなぁ。

不確実性の高いプロジェクトで、その不確実性をイメージできないクライアントとどのようにその認識をすりあわせていくか。
これは難しい所だなぁ、とやはり思う。
不確実性が高いというか、決めていくことが多いことがスタート時点で多いというだけなんだろうけど、それがどう転ぶが見えない時点で先ははっきりしないというだけなんだけど。

プロジェクトマネジメントする人が案件掛け持ちすぎだとやはりプロジェクト全体に取ってプラスには働かないだろうし。
そこのポジションで全体を把握してプロジェクトをスムーズに進める。

自分の場合は上に1クッションある場合が多いわけだから、そこをいかにフォローできるような立ち回りができるのか？というところなきはする。
コストを超えない中で、リスクにならないような立ち回り。

フォローするにしても最低限のことはちゃんとやってくれないと、フォローする気にならないというのが本音な気がする。

ゴールからの自発

自分がやっている設計とかは細かいところまで首を突っ込みすぎていないか？というのも気になった。
プロジェクトのゴールとか全体をチーム全体で共有できているのかとかとか。

丸投げはNGだけど、細かく突っ込みすぎると成果の上限が自分次第になってしまう所もあるだろうし。
ある程度自由度を持って開発できる方がいいんじゃないのかなぁ、とか。
もちろん設計とか間違ってるところとか、疑問点は常に質問されたり改善案とかをもらえる関係だからいいんだけど。

ある程度委譲しつつ、進行のサポートをするくらいの場合がいいところもありそう。
丸投げとの線引きが難しい気がする。

自分が作るドキュメンテーションの問題もありそうだ。

ガントチャートの弊害

ガントチャートの弊害として

ガントチャートでタスクを共有すると、多くの人は宿題を出された学生と同じように「自分のタスクの〆切」ばかりを気にするようになり、その締切に向かって仕事をするようになるのです。

という風に記載されていて。
個人的には変更は確実にあるとわかって作りつつ、全体のスケジュール感やタスクの重なり具合をザックリ見通したいという意味で作ってはいたが。
そういう発想もあるか、というのは思ったところ。

タスクの前後関係・依存関係さえ明確にできればいいわけだから、まぁそこはマンモスプロジェクト的に考えたらそうなるよなぁと。

プロジェクトの全体像、共有できてますか？ マンモスプロジェクト（Mammoth Project）
https://mmth.pro/ja

これは今のツールでなんかいい感じにできないか？を考えてみてもいいかもしれない。
GitHub の issue をベースになんかできれば良さそうな気がするのだけど。

朝会、進捗、共有

朝会の話は、なんとなく自分たちのフローになじまない気がしていて、今はやってはいないが。
多分、同期的にやるのでは無く非同期で同じような効果が出るような事をやる必要はあるだろうな、と。

みんなが同じ1つのプロジェクトに関わっている訳ではないというのもあるだろうし。
ここは負担の増えない範囲で方法を考えていきたいところだなぁ。

あわないからやらないのでは無く、やってる人たちがいると言うことはそこに何かしらの効果がある状況なんだろうから、何か吸収できないかを考えていきたい。

KPT

KPTもあまりやれていない。
これもどうにかしたいところではあるなぁ。

まずは自分で定期的に振り返りをして KPT を定期的に出していくところからだろうな。

プロジェクトマネージャーが読むのもそうなんだろうけど、何かしらのプロジェクトに関わる人はさらっと読んでおくと良さそうだなぁと思った。