背景
人が壊れるマネジメント プロジェクトを始める前に知っておきたいアンチパターン 50 を読みました。
その中で、個人的にすごく共感できたトピックを自分の体験談も交えて紹介したいと思います。
本記事を書いている人のスペック
新卒7年目のITエンジニアです。
複数メンバーを抱えたチームのマネジメント経験はありません。
2人ほどの開発チームメンバーの一人です。
開発にかかる工数見積 ～ テスト まで一通りの業務はこなせます。
どこにでもいる一般的なSEといったレベル感です。
個人的に刺さったトピック
非現実的な工数とスケジュールで壊れる
これまでいくつかのプロジェクトを経験して、炎上した理由の第1位がこれだと思っています。
ありがちなのが、不正確なタスクの見積もりです。
特にアサインされたばかりでプロジェクトの事もよく知らない場合、大抵他の人が工数見積したスケジュールに沿って開発していました。
しかし、見積もられた工数はそのプロジェクトをある程度わかっている前提で見積もられていました。
当然、プロジェクト入りたての僕の馬力では間に合わず、残業をする羽目になりました。
また、自分の見積もりが楽観的過ぎて工数が足りなくなってしまうケースもありました。
振り返ってみると、自分が安請け合いしてしまったことが原因でした。
対処法
本書では、非現実的な計画によるプロジェクト失敗を避けるため「積み上げ式で工数を見積もって計画を立て、要件変更や追加要件が入った際は必ず再計画を実施する」と書かれています。
当たり前のようで、これができていないプロジェクトは本当に多いです。
ただ、実際の現場では顧客からのプレッシャーや納期等様々な要因で再計画の実施が難しい場合もあります。
その場合、プロジェクトが走り出す前に顧客と計画変更の可能性について理解して貰う必要があります。
現実的な工数を提示する
安請け合いせず、最初から無理な計画を組まない事が重要です。
プロジェクト初期の工数見積は、あくまで概算であることを伝える
要件定義や機能設計が終わったタイミングで、再度詳細の見積もりを行い計画を見直すことを理解してもらうようにしましょう。
また、当初の要件・要求に変更が入った場合や、優先度の高い対応が割り込んで来た場合は、再計画を実施することに合意をもらうようにしましょう。
経営陣の無理解で壊れる
僕の経験では、現場の状況を理解していない経営陣の無茶な要求でプロジェクトの計画が破綻するケースがありました。
上からのプレッシャーで現実的ではない目標に対応せざるを得ず、無茶な働き方をするケースです。
経営陣とは少し違いますが、プロジェクトに詳しくない技術者がオブザーバーとして入るケースもあります。
共通しているのは、現場の状況を理解しておらず、無茶な指摘や要求をすることです。
このように、現場の声が届いていないと組織の信頼度やチームの指揮も下がります。
なぜ経営陣は無茶な要求をしてくるのか
経営陣が現場に理不尽な要求を突きつけるのは、「要求に応じたリソース（予算や工数、スケジュール）が必要である」という現実を理解できていないことが大半である と本書では書かれています。
プロジェクトの方針や要求変更は、注文した料理を作っている間に注文を変更するようなものと例えられていました。
つまり、今まで作り上げてきたものを一からやり直すくらいインパクトの大きいものになります。
経営陣から見ると、「些細な方針変更」でもプロジェクトの影響範囲は大きいものになってしまいます。
方針変更に伴いリソースが見直しされるならまだ良いですが、リソースの見直しが行われずに計画が続行されると開発者に過剰な負担がかかってしまいます。
対処法
定期的な報告と対話を行う
進捗状況や課題点を経営陣に共有し、現状を理解してもらう。
対話を通して、プロジェクトの現状に対し共通認識を持ってもらうようにしましょう。
リソースの確保を優先する
プロジェクトの方針や前提条件が変わった場合、必ず再計画を行います。
また、再計画が行われない場合のリスクについてもきちんと伝えることも重要です。
プロジェクトの不確実性で壊れる
プロジェクトに不確実性はつきものです。
プロジェクト開始時点では想定が難しい要素や、いざ作業に入らないとわからないこともたくさんあります。
そういった不確定要素のためにプロジェクト初期の工数見積もりでバッファを積みますが、
バッファだけでは賄えないケースもたくさんあります。
特に新しい技術を扱った案件や、プロジェクトで扱うプログラミング言語に詳しいメンバーがいない場合、
プロジェクト初期の段階で出した工数通りに計画を進めることは困難です。
対処法
こうしたリスクが顕在化した場合、一度立ち止まってプロジェクトの方針や計画を見直すことが重要です。
リスクの洗い出しと優先順位付けを行う
プロジェクト初期の段階で想定できるリスクを洗い出し、影響の大きさや発生する可能性を考慮して対策を検討します。
また、プロジェクト関係者へプロジェクトは本質的に不確実性を扱う取り組みであることを理解してもらうことも重要です。
高いお金をかけたプロジェクトでも、1つの不確定要素でプロジェクト全体が失敗してしまう可能性があるのです。
柔軟な計画を立てる
不確実性が高いプロジェクトの場合、詳細すぎる計画よりも柔軟な計画を立てるほうが重要です。
例えば、プロトタイプを作って実際の開発感覚を検証したり、状況に応じて計画を見直すアプローチをすることが大切です。
プロジェクトに変更はつきものであると関係者へ意識してもらうことが大切です。
感想
新しくアサインされたプロジェクトで早速障害が見つかり、かなり忙しくしている時にこの本と出会いました。
プロジェクト失敗の要因となり得る要素が広く網羅されており、とても読みやすく共感を持てるものも多くありました。
特に、アンチパターンが与えるメンバーの心理的負担について書かれたものが多く、一 SEとしてとても共感できました。
（特に 長時間労働で壊れる のトピックとか・・・笑）
まだ一部（プロジェクト計画編）しか読めていないですが、
タスク編、コミュニケーション編、キャリア編等 面白そうなトピックがあるので楽しみです。
マネジメント業務をしている方でなくても勉強になるおすすめの一冊です。
ここまで読んでいただきありがとうございました。
