はじめに

今年のプロジェクトマネジメントのセミナーに参加してきたのでレポーティングしたいと思います。
前前回分：https://qiita.com/mnoguchi/items/f86cc67ac752faa6bd4e
前回分：https://qiita.com/mnoguchi/items/75e389dabf09c1a163aa

テーマ

PMOは見た！炎上プロジェクト -どこにルート分岐があったのか-
事例から見る失敗させないためのポイントを紹介

導入

現代のPMOとして、炎上プロジェクトに「炎上してから」送り込まれることの多かった私が現場で見たこと、繰り返されること、どこが岐路だったのか考察した結果、失敗ルートが見えてきました。
経営層でもなく、当事者でもない第三者のニュートラルな視点でこそ、本質が見えることがあります。
ここ一番の社運がかかったプロジェクトで失敗を繰り返さない組織になるために必要なヒントをお伝えします。

プロジェクトの “炎上” とは？

プロジェクトの計画時に想定していた予算や期間内での開発が不可能な状態を指します。主に納期が差し迫る状況で開発困難な状況に陥っているプロジェクトを指すケースが多いです。

登壇者のプロジェクト事例

規模: 300人月
期間: 2年間
ユーザー業種: 建設業
システム概要: 積算システム新規構築

開発フロー

要件定義
基本設計
詳細設計
開発、単体テスト
結合テスト
システムテスト
受け入れテスト
リリース

開発、単体テスト時の問題点

詳細設計書がレビュー不十分だった
課題の積み残し、変更要求が多発し、頻繁に仕様変更
複数の拠点との自動連携を双方向で実現しようとしていた（難易度高）
複雑な機能を1機能として扱う設計の無理
1社に100機能を一括委託し、詳細設計の品質が悪いため製作できず

結果

完成できない機能が多発
障害も頻発
正解の仕様がわからない
修正するたびに矛盾が発生
収束の見通しが立たない

当時の状態

思考停止
怒り
疲弊
他責
自責

発生した理由（PMBOKの10のエリアから）

ステークホルダマネジメントの欠如
委託先の精査不足
リスク対策の不十分さ
チーム分けの不適切さとフォロー体制不足
設計レビューやテストの不十分さ
推進者の役割不足
コミュニケーションフォローの不足

実施した対策

その1：マネジメント体制の強化

課長に指揮・命令系統を一本化
課長をフロントに、バックで密なコミュニケーションをとりサポート
マネジメント支援、作業支援、レビュー、ミーティングに参画

その2：状況の確認

機能の一覧を確認し、スコープと機能の状態を確認
不要な機能の排除
ボトルネックの特定

その3：スコープ・品質の確認

設計者／製造者の組み合わせと品質の分析
品質強化ポイントの仮説を立てる

その4：単体テストからやり直し

再単体テストの実施

対策の具体的手法

事業部長によるステークホルダマネジメント
委託先の打ち切りと内製への転換
リスクの定期棚卸し
適正・特性を重視したチーム分けとフォロー体制の確立
機能単位の品質調査
工程進行基準、品質合格基準の再設定と合意
再テスト計画の実施
課長をリーダーに交代
コミュニケーションとルールの見直し
何が何でもやり切る “覚悟”
単体テストリーダーを申し出る
準備を入れて1ヶ月半、機能数200超

結果を出すための徹底的な体制構築と準備

徹底的な “体制構築” と “準備”
スキル、得意分野、性質を考慮して担当割り振り
経験が浅いメンバーが気軽に質問できる環境作り
単純なUI部分は派遣・協力会社グループをアサイン
日次で進捗を把握し、PL自らテスト仕様書の最終確認
“課題・障壁” を即時に取り除く体制づくり
初期メンバーのサブリーダーとチャットグループを作り迅速な判断
仕様に詳しい専門家とのチャットグループを作り迅速な確認
ユニットリーダーとPLを入れたチャットグループで問題の共有

効果

チャットメンバー間で認識・問題の共有、信頼関係が生まれ、自発的な行動が促進
取り組みを毎日欠かさず繰り返す
当日中のフィードバック
日々の進捗確認
課題問題の監視
専門家による迅速な判断

“現在の状況” と “調整” と “感謝”

毎日進捗状況を説明
遅れているところにはベテランメンバーに調整を依頼
感謝を伝える
- 質問者には “質問してくれてありがとう”
- 回答者には “答えてくれてありがとう”
- 巻き取ってくれた人には “代わってくれてありがとう”
- ヘルプで入ってくれた人にも “助けてくれてありがとう”
- 元々入っている人にも “ここまで頑張ってくれてありがとう”
- 経験が浅くても毎日頑張ってくれる人に “頑張ってくれてありがとう”

判断”ルート”は1つ。判断は迅速に

判断権限のない人に質問しないように是正
判断者は責任を持って回答

本当に ”レビュー” しているか

思えば、レビューのまずさが発端だった
本当のレビューができていれば
- 詳細設計が終わっていないことがわかった
- 作り切れない難易度であることがわかった
- 設計者が十分に理解できていないことがわかった
- レビュアーにレビュースキルやレビュー時間が不足していたことがわかった
レビューの中でもインスペクションを実施し、厳密な設計品質の担保を行うべきだった
- => レビューした “つもり” が一番危ない

PM（PL）は “良いスチュワードであれ”

PM（PL）は、何でもできるからリーダーなのではない
みんながいて、リーダーにしてもらっているのだということを痛感した
PMとは現場のみんなが作業を進め続けられるように障害物をどかしていく役割

炎上を回避するための「正しいマネジメント」

各フェーズのポイントを押さえる

フェーズごとのポイント

要件定義: 綿密なQCD計画
基本設計: 過不足なく要件を盛り込む
詳細設計: インスペクションで設計を確認
開発: 機能を理解して製造
結合テスト: 設計通りに作り切る
受け入れテスト: 計画通りに品質保証
リリース: 工程ごとに完了確認

再発防止に向け

実行可能かつ綿密な計画
冷静かつ合理的な総合判断
人と接して状況を把握する

まとめ

PM（PL）は何でもできるからリーダーではない
みんながいてリーダーにしてもらっていることを認識する
各メンバーの役割を尊重し、障害物をどかす役割

“炎上”を回避するためには「正しいマネジメント」しかないということでした
正しいマネジメントの上で各フェーズのポイントを押さえ、再発防止に努めましょう。