プロジェクトを炎上させないためのひと手間「兆候管理」

連載 [第5回] :

2022年9月14日(水)

はじめに

皆さんは「炎上プロジェクト」という言葉を聞いたことがありますか? 一般的な「炎上」と言うと、一般常識からかけ離れた言動をSNSなどで公開してしまったり、公開されてしまい批判の嵐に晒されるイメージが強いと思いますが、ITの世界での炎上は、プロジェクトの運営においてスケジュールがそのままだと取り戻し不可能なレベルで遅れてしまうことを指します。

この炎上プロジェクトですが、結構な頻度で見かけることが多く、また私が関わるプロジェクトの中でも時々発生することがあります。皆さんの中にも、ご自身や同じ社内の別プロジェクトが炎上した経験をお持ちの方は多くいらっしゃるのではないかと思います。

一般的に、この炎上プロジェクトの原因となる要素には大きく3つあります。

炎上プロジェクトの3大原因

1. 要件の漏れ・認識違い・プロジェクト立ち上げ後の要件変更

コンペ方式での入札案件やITベンダー切替直後の再構築、大規模改修の様なプロジェクトで発生することが多い傾向にあります。発注側と受注側のコミュニケーションが万全ではなく、お互いにとっての常識も異なる、といった環境で発生するイメージです。最近も大手証券会社と大手SIerが失敗したプロジェクトの損害賠償を巡って裁判となり、一審では証券会社勝訴、二審ではSIerが勝訴となり、三審目は証券会社が上告を取り下げたことで大きな話題になりました。

2. プロジェクト計画の甘さ

これはさらに2つに分類できます。1つは、全体規模や設計・開発を行う際の生産性などプロジェクト計画で使用する定量情報に正確性がなく、算出した工数がいい加減になり結果として計画全体が甘くなるパターン。もう1つは、プロジェクトの計画段階では下流工程などの一部について対応方針やプロセスが十分に考え切れておらず、下流工程に入るまでに計画を詳細化・現実化していく(これを段階的詳細化と言います)ことが往々にしてありますが、この段階的詳細化の活動自体がスケジュールに組み込まれていなかったり、組み込まれていても他のタスクが多忙で先送りしている間に詳細化・現実化できていない工程を迎えてしまい、プロジェクトメンバーがやるべき仕事が分からず炎上するパターンです。傾向としては、要件定義や見積り、プロジェクト計画策定の期間が短かったり、プロジェクト計画をレビューする人の経験がスキルが低い場合など、プロジェクト計画のミスや落とし穴ができやすい環境で発生することが多いです。

3. マネジメントの甘さ

何度も書きますが、プロジェクトマネジメントは、基本的に事前計画を綿密に練り上げ、プロジェクト立ち上げ後は計画を緻密に実施し、それでも発生してしまう想定外の問題をプロジェクト全体で討ち取り進めて行くことが大原則です。ほとんどのプロジェクトマネージャは、プロジェクト計画の段階でプロジェクト運営自体の計画も想定できうる限り綿密に段取りしてマネジメントに臨みます。しかし、現実にはそれでもプロジェクトは炎上します。個人的な経験で言うと、炎上プロジェクトはこの3つ目の原因が全体の半数以上を占めています。

以降では、この3つ目の原因と、その対策について解説します。

PMBOKに従っても
マネジメントの甘さは出るのか

マネジメントについて、想定できうることはキッチリ段取り・対応しているのにも関わらず、スケジュールが破綻し炎上する。本当にそういったことが頻繁にあるのだろうか? と思う方も沢山いらっしゃるでしょう。確かに、字面だけで考えると俄かには状況が頭に浮かばないかと思いますが、では、以下のような事例を経験したり、見聞きしたことはないでしょうか。

先週まで進捗報告では「順調」となっていたタスクが、ある日突然「●●MD遅れです」などと報告される
「進捗も品質も問題なし」と報告されていた工程が、工程の終盤になって指摘対応や、やり直し無し対応のため「●●MD遅れです」などと報告される

私が見てきた限り、こういった問題が全く報告されなかったプロジェクトは非常に少ないです。また、このような報告が頻発してコントロール不能になるとプロジェクト全体が炎上するのです。

では、これらの問題はどこに原因があり、どうすれば防げるのでしょうか。

基本的に、プロジェクトは1人でやるものではありません。決められた期限に向かって決められたゴールを目指す1回限りの活動になります。そのため、プロジェクトへ参画した際に初めて顔を合わせる技術者同士も非常に多いのです。生まれた場所も育った環境も、受けた教育も生きている年数も異なる人たちが一同に会すとなると、プロジェクトマネージャがいくら方針やルールを策定しても、やはり微妙にズレた報告や成果物が生まれてしまいます。それらのズレと時間の経過が重なると収拾がつかなくなり、炎上するのです。

PMBOKでは、これら(実際には課題や品質も含まれますが)を管理するために、

コミュニケーションマネジメントの計画
コミュニケーションのマネジメント
コミュニケーションの監視

この3つを組み合わせて「コミュニケーションマネジメント」というプロセスと知識で整理しています。1は主にプロジェクト憲章やプロジェクト計画書に「いつ」「誰が」「どの様に」「どの位の頻度で」情報を収集・伝達するのかを計画するプロセス、2はプロジェクトマネージャがステークホルダに報告や情報収集を行うプロセス、そして3はプロジェクトマネージャがプロジェクトメンバーに情報の展開や情報の収集を行うプロセスになります。

3のコミュニケーションの監視では、コミュニケーションマネジメント計画書に従って情報の収集・伝達が正しく行われているかを、パフォーマンス情報(上手く成果物が出せているか、EVMなどで実績価値が出ているかなど)を元に確認しますが、この仕組みの決定的な問題は、実績が確定しパフォーマンス情報を収集した際に初めて「進捗遅れ」として気付く点です。プロジェクトマネージャはなるべく各タスクを短いスケジュールに細分化し、遅れが発生しても数MDで済むようにするなど事前対策を打つことが多いですが、それでも後手に回ってしまうのが辛いところです。

兆候管理

そこで、PMBOKにはない要素ですが、私が関わるプロジェクトでは「兆候管理」という考え方を採用し、問題を事前に把握するようにしています。兆候管理は問題が顕在化する前に状況を把握し、問題となる前に対処することで遅れ発生のリスクを低減する活動になります。

進捗遅れが発生する原因にはいろいろありますが、多くの場合、結果的に遅れが発生したタスクを検証すると、次の3点が原因になっている場合が多いです。

タスクの着手自体が遅れてしまった
タスク推進に決定的な影響を与える課題・問題が事前に解決されていなかった
タスク担当のメンバーは遅れを把握していたが、責められるのが嫌で「残業すれば取り戻せる」と安易に見切り中間報告では「順調」と報告していたが、結果的に取り戻せなかった

そのため、非常に単純ですが、1は各タスクに着手遅れが発生していないかの情報収集と分析、2は週末に課題・問題の読み合わせ会を開催し、課題・問題ごとに各メンバーに来週のタスクに影響のある課題で未解決のものがないかのヒアリング、3は進捗報告の際の言葉(後ろめたいことがある場合は、何等かの課題がありそうな言葉を言いつつ「残業で何とかなりそうです」と報告することが圧倒的に多い)を慎重に聞き、報告内容に怪しさを感じたら同じ内容を別の切り口で状況確認する、など、これから遅れに繋がる可能性のある情報をいち早く、かつ正確に把握するプロセスを組み込んでいます。このひと手間で、ある日突然遅れが顕在化したり、遅れが同時多発的に発生してプロジェクトがコントロール不能になることを抑制できます。