【やらかした】プロジェクトの失敗談とそこから得た教訓

はじめに

この記事では、自分が経験したプロジェクトにおける失敗談から得た教訓を記載していきます。
私はプロジェクトマネジメントの経験がほぼ皆無の中、PL(プロジェクトリーダー)としてある案件にアサインしてもらいました。非常に有り難いことです。社会人経験としてもPM,PLとしても未熟な私がその案件で経験した失敗を元に、学びをまとめていこうと思います。
特にタスク管理の観点で「こうしたほうが良かったな」と反省することが多々あったので、「同じ失敗はもう二度としない」という意気込みと、同じような状況に置かれている方々の参考になってほしいという思いを込めて記載します。

前提

今回の失敗はウォーターフォール型の開発案件での失敗談です。そのためアジャイルでは違うよという内容もあるかもしれません。
また、この記事の内容は「マネジメントする人としては常識だろ」という学びもあるかと思いますが、温かい目で見守ってほしいです。
あと割と個別具体よりなので後から抽象化してまとめられたらと思ってます。

失敗から学んだこと

まずは今回の失敗から学んだことを一覧で紹介します。失敗の内容と各学びの詳細は各セクションを御覧ください。

1. デイリーの進捗管理はタスクごとにヒアリングする
2. タスク状況は詳細に多角的にヒアリングする
3. バッファを十分に設ける
4. ネガティブな計画を立てる
5. タスクの状況を数値化して具体で管理する

1. デイリーの進捗管理はタスクごとにヒアリングする

失敗の内容

チーム内でデイリーMTGを開催してました。そのMTGにてメンバーの進捗を聞いて、タスク管理を行っています。流れとしては、

• 全体共有事項
• メンバーAの前日の進捗と当日の作業予定
• メンバーBの前日の進捗と当日の作業予定
  ・・・
• その他連絡事項

という流れです。

メンバー単位で進捗の進み具合を確認していました。ここで良くないと感じたのは、WBSに書いていない作業をしていることが散見されていました。
また、メンバーのレベルによっては作業ごとの報告内容の粒度がばらばらであったり、マネジメント側が把握したい情報を伝えてくれないこともあります。
そういったことが相まって、全体で共通認識を持てていなかったり、タスク状況の解像度が低いままプロジェクが進行したりという失敗を経験しました。

学び

このことから、人単位で状況をヒアリングするのではなく、WBSベースで、タスクベースでヒアリングするほうが良いのではないかと感じました。「〇〇さんお願いします」ではなく「△△のタスクの状況を〇〇さんお願いします」とタスクを軸としてヒアリングしたほうが、一つひとつのタスク状況を明確に把握できると思います。

2. タスク状況は詳細に多角的にヒアリングする

失敗の内容

デイリーMTGでタスク状況をヒアリングしていましたが、極端に言えば「昨日はどの作業をやっていて、今日の予定はこれです」というところしか確認できていませんでした。
ちょっと盛ってますけど、それくらいヒアリングが浅かったなと思っています。

学び

「自分がわからないことがないくらい」または「タスク状況が今どんな状態で何をすれば完了するということを人に説明できるくらい」には色んな視点でヒアリングをすることが大事です。質問力が問われそうです。ヒアリングの観点は経験値で得られるのかもしれないですが、マインドとしては「人に説明できるまで」ヒアリングしようという気持ちでいたいと思いました。

3. バッファを十分に設ける

失敗の内容

プロジェクトの外部要因的にどうしようもない部分もありましたが、とにかくバッファがありませんでした。そのため一つのタスクが遅延すると後続タスクもどんどん遅延し、バッファもないためただただスケジュールが伸びるだけという状況になってしまいました。

学び

バッファを設けるのは当たり前ですが、観点としてはどのようにバッファを設けるか、そしてそれをメンバーにしっかり伝達することが大事だというところが学びポイントです。タスク一つ一つにバッファを設けてスケジュールを組むか、スケジュールの最後に１ヶ月分バッファを設けるかで計画は変わります。また、前者パターンでバッファを設けた場合、「タスクはバッファ含んでいるからスケジュールより速いスピード感で進めてね。２日でできるものを３日かけて進めていいというわけではないよ。」ということを適切に伝えないとバッファが無駄に食いつぶされてしまいます。

4. ネガティブな計画を立てる

失敗の内容

バッファがない納期だったので、「もはやこのカツカツなスケジュールでやるしかない、うまくいくことを祈るしかない」と思っていました。楽観的な計画だったなと思います。人間のバイアスで、計画通りうまくいくと思ってしまうバイアスがありますが、9割は計画通りにならないです。今回もまさに楽観的な計画が尽く倒れ、遅延を生んでしまいました。

学び

プロジェクトマネジメントに限らず全てに言えることですが、計画を立てるときはネガティブなプランも考えたほうがいいです。一番最初に思いついた計画からマイナス20~30%くらいした計画を立て、そうなった時の対策まで考えることで、結果的には「ネガティブな計画通りだったよね、でも計画通りだし問題にはならなかったね」で済むと思っています。何もうまくいかない位に思って計画したほうが確実です。

5. タスクの状況を数値化して具体で管理する

失敗の内容

プロジェクトが遅延し、先輩からヒアリングが入りました。そこで「あとタスクはいくつ残っているのか、それは合計何人日なのか」と聞かれ、その場でさっと答えることが出来ませんでした。WBSを見れば分かるけど、、、というように数値情報を普段意識していないことに気づきました。先輩は「あと何人日分のタスクが残っていて、メンバーは何人いて何人日分の稼働ができるから…」と数値情報をもとにどうするか話を進めている姿が印象的でした。

学び

計画を立てるうえで、なんとなくとか定性的なもので計画を立てるのは未熟だと学びました。特にタスクの管理などは数値化できるところです。数値は具体であり揺るがないので認識がずれることはありません。計画を立て、状況をヒアリングしていく中で数値情報を駆使することで全員が共通認識を持つことができる学びました。

おわりに

管理がずさん過ぎて、こんなひどいPM,PLがいるのかと思われた方もいるかも知れません。
この記事が、新米PMなどの人たちの役に立てばなによりです。
記事の内容に対して、「ここはこうだろう」という意見がある方はぜひコメントお願いします！
最後までご覧いただきありがとうございました。