定量報告でも問題が見えなくなる、2つの落とし穴
開発ベンダーのPMOが意図的に都合の悪い情報を隠しているとは限りません。
むしろ、開発ベンダーPMO自身が問題に気づいていないまま「大丈夫」と言い続けているケースのほうが多いと感じています。
進捗状況を正しく把握するために、EVMをはじめとする定量的な報告を求めるアプローチは有効です。「順調です」という言葉だけでは本当かどうかわかりませんので、数値という客観的な根拠を求めることには意義があります。
開発ベンダー側に説明責任を持たせることで、曖昧な進捗報告を防ぐ効果もあります。数値として記録されることで、後から問題の兆候を遡って確認することも可能になります。
しかし、定量報告がされているにもかかわらず、問題が露見しないまま、プロジェクトが進行してしまうケースがあります。背景には、次の2つのパターンがあると思います。
報告の粒度が粗すぎる
EVMを例に挙げると、ワークパッケージ（Work Package）単位ではなくチーム単位で集計された数値として提示されることがあります。
ワークパッケージとは、WBSの最下位要素で8～40時間程度の作業量（期間としては1～2週間程度）が目安になります。例えば、フロントチーム、バックエンドチーム、インフラチームに分かれていたとして、チーム単位というのはこのそれぞれのチームということになります。
ワークパッケージ単位は、フロントチームであれば、画面単位の設計や開発作業ということになると思います。
チーム単位で集計すると、遅延しているタスクと前倒しで完了しているタスクが互いに相殺されてしまいます。
開発チームの中で、ある機能が2週間遅れていても、別の機能が予定より早く完了していれば、チーム全体のEVMはプラスマイナスゼロとなり、数値上は「順調」に見えてしまいます。
しかし、ワークパッケージ単位で見たら、ある機能の設計が著しく遅れているということがあったとします。
実はこの機能が、すでに進行している他の機能の設計に影響を与える、またはこの機能の設計が終わらないと進められない後続タスクが多くあるとしたらどうでしょうか。
現時点ではトータルでオンスケですが、この後、大幅に遅延するリスクが潜んでいる状態ということになります。
問題を正しく検知するにはワークパッケージ単位の集計が必要です。
開発ベンダーがチーム単位でサマリーした状態でEVMの数値を出してきた場合は、ワークパッケージ単位にブレイクダウンした数値を報告してもらうように求めると早期に問題を検知できるかもしれません。
開発ベンダー内部の統括力が弱い
大規模な開発プロジェクトでは、開発ベンダー側に例えば、統括チーム（PMやPMO）、フロントエンド、バックエンド、インフラといった複数チームが存在します。
発注側のプロマネやPMO（Project Management Office：プロジェクトマネジメントオフィス）がコミュニケーションするのはベンダー側の統括チームのみというケースも多いです。
その統括チームが各チームの実態をタイムリーに把握できていないということがあります。
よくあるのが、開発チームが複数の会社の混成チームになっていて、ガバナンスが取れていないというケースです。
手を動かすチームと統括するチームで別の会社だと、意外とコミュニケーションがしっかりとれていないということがあります。
例えば、手を動かすチームが統括チームにしっかり情報共有しない（関係性ができていないというのはよく見かけます）、統括チームは一応のヒアリングはするものの開発内容をいまいちわかっていないので、手を動かすチームが伝えた内容を理解できていない、こんなことが起きます。
この場合、発注サイドとしても、問題ないという報告を受けるばかりでなかなか本当に実態がわからないという事態に陥ります。
疑うのではなく、実態を確かめる姿勢
こうした状況への対処として重要なのは、「報告を鵜呑みにしない」という姿勢です。
これは不信感を前面に出して接するということではなく、報告された内容を出発点として、実態をより正しく、深く確認しようとする姿勢のことです。
JQが現場で実践してきた考え方として、特に有効なアプローチが3つあります。
発注側チーム間の密なコミュニケーションを取る
大規模プロジェクトでは発注側も複数チームで体制が組まれることが多いです。
各チームリーダーと日常的に情報交換を行い、現場で感じている違和感や気になっていることをすくい上げる機会を意識的につくることが重要です。
ベンダー側の統括チームから情報が届きにくい場合でも、自分たちのチーム内から異変を察知できることがあります。
開発サイドの各チームのミーティングに時々参加する
報告書の数値だけでは伝わらない情報があります。
チームの雰囲気や発言のトーン、議論の温度感を肌で感じることで、問題が小さなうちに気づけることがあります。
「報告を聞く」ではなく「現場を見る」という発想で、開発サイドのミーティングに顔を出すことを習慣にするといいでしょう。
プロジェクトの途中で、出たいといっても嫌がられる恐れがあるので、プロジェクト計画時のコミュニケーション計画であらかじめそう取り決めてくと良いでしょう。
または大きな遅延や品質問題が起きた時に、アクションプランとして提案すると良いと思います。
定量報告の細部の変化を見逃さない
報告の遅延、数値の矛盾、記載ミスといった変化には、問題の予兆が現れることがあります。
「先週と比べて数字の動きが不自然だ」「いつもより報告が遅れている」という小さな違和感を見逃さないことが、早期発見につながります。
細かいことを気にしすぎだと思っても、その違和感を確認する問いかけを習慣にしておくことが大切です。
忙しい局面でこそ、違和感を手放してはいけない
最も重要な姿勢として強調したいのが、忙しいときこそ違和感に敏感になることです。
人は追われているときほど正常性バイアス（問題を過小評価し「大丈夫だろう」と思い込む心理的な傾向）に支配されやすく、「気になるけどまあ大丈夫だろう」と違和感から目を逸らしがちになります。
プロジェクトが忙しい局面こそ、小さなシグナルを意識的にキャッチしようとすることが重要です。
自分が忙しいときに「細かいことは確認しなくていい」と感じたら、それ自体が危険なサインだと思ってください。
開発サイドへのリスペクトを持ちながら、粘り強く確認し続ける
最後に、一つ注意点があります。
報告に問題があると気づいたとき、感情的な対応は悪手です。
意図的に情報を隠しているとわかったとき、多少腹立たしく感じることもあるかもしれません。
しかしそういった感情が言葉遣いや態度に現れると、開発ベンダーとの関係が悪化し、プロジェクト全体の士気が下がってしまう恐れがあります。
大切なのは、丁寧に、しかし確実に確認を取り続けることです。
「この点についてもう少し教えていただけますか」「数値をワークパッケージ単位で共有していただけますか」という形で、事実を引き出す問いかけを続けることが重要です。
こうした対応を積み重ねることで、「この人にはごまかしは通じない」という認識が開発サイド側に自然と生まれます。
威圧感や不信感からではなく、丁寧で粘り強いコミュニケーションから生まれる適度な緊張感こそが、報告の質を高め、問題の早期発見につながります。
プロジェクトの炎上から守ってくれるのは、疑念ではなく、丁寧で粘り強い確認の積み重ねです。
