システム開発プロジェクトで進捗報告書を作成する際、こんな状況に直面したことはないでしょうか。
エンジニアから「80％完了しました」と報告を受けたものの、その進捗率が本当に妥当なのか判断できない。完了報告を受けたタスクを確認してみたら、実は残課題があって終わっていなかった。結果として、遅延が頻発し、作業の手戻りや追加が発生してしまう。
PM（プロジェクトマネジメント）業務において、進捗管理は最も基本的でありながら、最も難しい業務の一つです。特に、エンジニアの成果物を直接確認するスキルがない場合、報告された進捗の真偽をどう確かめるべきか。この判断は、プロジェクトの成否を大きく左右します。
ただ進捗を聞いてくるだけというアプローチ
多くの現場で見られるのは、PMO（プロジェクトマネジメントオフィス）がエンジニアに対して定期的にヒアリングし、報告された内容をそのまま取りまとめるというアプローチです。
週次や日次で「今どれくらい進んでいますか？」「いつ完了しますか？」と確認し、エンジニアの回答を進捗報告書に反映する。進捗率に疑問があれば質問し、遅延があれば理由を聞く。PMOは情報を集約し、整理して報告する役割を担います。
このアプローチが採用される理由は明確です。PMOにシステム開発の専門スキルがない場合、成果物の中身を直接確認することは困難だからです。設計書やソースコードを見ても、その品質や完成度を判断できません。したがって、エンジニアの報告を信じるしかない、というのが現実的な判断となります。
また、エンジニアは専門家であり、自分の作業について最もよく理解しているはずです。プロフェッショナルとして、正確な報告をしてくれるだろうという前提に立つことも、自然な考え方でしょう。
このスタンス自体は決して悪いものではありません。エンジニアの自律性を尊重し、専門性を信頼することは重要です。
ただし、この方法だけでは、進捗管理がうまくいかないケースが非常に多く見られます。
PMOが信頼されない現実
このアプローチには、深刻な問題が潜んでいます。
第一に、PMOの役割が「ただ進捗を聞いてくる人」と思われてしまいます。エンジニアの立場から見ると、PMOは進捗を報告する相手であり、監視する存在のように映ります。進捗を聞かれ、遅延していれば理由を説明し、報告書を作るための情報を提供する。しかし、それ以上の価値を感じられない。結果として、PMOとエンジニアの間で信頼関係が構築できません。
第二に、エンジニアから邪険に扱われるケースも発生します。ただ聞いてくるだけで、結局は助けてくれないPMOという印象を持たれると、協力的な態度を引き出すことは困難です。最低限の情報は提供するものの、本当の問題や懸念事項は共有されません。「どうせ言っても何もしてくれない」という諦めが生まれるのです。
第三に、正確な現状把握ができなくなります。信頼関係がない状態では、エンジニアは本当のことを言いません。遅延していても「順調です」と報告したり、残課題があるのに「完了しました」と言ったりします。これは嘘をつこうとしているわけではなく、「他のタスクが終わらないと自分の作業も進められない」という状況を「完了」と認識してしまうような、認識の齟齬も起きているのです。
遅延した場合でもリカバリプランを一緒に考え、調整してくれる人がPMOとしていれば、エンジニアもそのような目線でPMOを見てくれますし、嘘や適当な報告をしてきません。一方で、ただエンジニアが一方的に説明して取りまとめるだけのPMO、結局は助けてくれないPMOという印象を持たれると、進捗管理は形骸化してしまいます。
日常的な進捗確認の仕組みを構築する
私は、進捗の真偽を確かめるのではなく、正確な進捗報告が自然に上がってくる仕組みを構築するという方針を推奨しています。
そのためには、まず適切なWBS（Work Breakdown Structure：作業分解構成図）を作ることが大前提です。
第一に、WBSを成果物単位で作成・管理します。「設計作業」というような曖昧なタスクではなく、「A画面の処理設計書の作成」「αテーブルのテーブル定義書作成」というように、具体的な成果物に紐づいたタスクに分解します。そして、各成果物の「作成」と「レビュー」のWBSを明確に分けます。これにより、作業のゴールが明確になります。
第二に、各作業は5人日以内に細分化します。大きなタスクは進捗の把握が困難です。5人日以内に分割することで、遅くとも1週間で遅延に気付けるようになります。また、作業のゴール設定をPMOでもわかるレベルで明確にすることが重要です。
第三に、作業着手時に「着手確認」を行います。単に「着手しました」という報告を受けるだけでなく、そのWBSのゴール設定を改めて確認します。「この作業が完了したら、どのような状態になっているか」を共有することで、認識の齟齬を防ぎます。
第四に、作業終了時に残作業がないか確認します。特に、他メンバーや他タスクに起因して着手できないような作業がある場合、エンジニアは「完了」と言いがちです。このような状態になっていないかを確認する目的で「この作業は完了とのことだが、他者の情報の取込待ちで残した作業はないか？」という問いかけが有効です。
第五に、作業の途中進捗率はエンジニアリーダーによるメンバーヒアリングに任せ、基本的にはその言葉を信じます。5人日単位にWBSを細分化しているため、PMOは遅くとも1週間で遅延には気付けます。リーダーにはその裁量を与えることで、現場の自律性を尊重します。
ただし、PMOも日々、進捗率のヒアリングは行います。その目的は、進捗率の妥当性確認ではなく、遅延していた場合、メンバー横断的な観点などで一緒にリカバリプランを考えてあげるためです。こうすることで、「遅延と報告しても助けてくれるんだ」という印象をエンジニアに与えることができますし、適切な進捗率の報告をもらえることにもつながります。
なお、頻繁に完了遅延を起こすメンバーがいた場合、その途中進捗率を確認し、そこにギャップがあれば虚偽報告と判断するケースももちろんあります。その場合は、エンジニアリーダーの交代などといった対処も当然行います。
第六に、レビューまで完了した成果物については、PMOにて一部成果物そのもののサンプルチェックも行います。こうすることで、適切な粒度や内容で成果物ができているのか、残課題が本当にないのかを確認し、工程後半や次工程で大きな問題が発生しないようにします。
この方針の最大のメリットは、PMOが「一緒にリカバリプランを考えてくれる存在」として認識されることです。信頼関係が構築されれば、正確な進捗報告が自然に上がってくるようになります。
この仕組みを機能させるための条件
この方法を実践する上で、いくつか重要な注意点があります。
まず、WBSが適切に作られていることが大前提です。成果物単位にWBSが作られていなければ、完了のゴールが不明確になりがちです。WBSを5人日に分けていなければ遅延に気付くのが遅くなり、リカバリが難しくなります。いくら進捗確認の仕組みを整えても、WBSが適切でなければ機能しません。
次に、PMOの緻密かつ丁寧なマインドが必要です。着手確認、完了確認ともにルールに基づき必要なことを伝える、確認する必要がありますし、雑になってはいけません。形式的に「着手しましたか？」と聞くだけでは意味がなく、ゴール設定を丁寧に確認するような、ルールに基づき丁寧に事実確認をしていく姿勢が求められます。
第三に、コミュニケーション力や機動力を持ったメンバーがPMOを担当する必要があります。途中進捗に遅延が発生した場合には、関係者を集めて話をするような行動力が求められます。現場ヒアリングのPMOは若手が担当することも多いですが、技術的なスキルがなくともこのようなマインドを持っているメンバーをアサインすることが大切です。
最後に、PMOチームにシステム開発スキル・知見を持ったメンバーを配置することも重要です。遅延時のリカバリプラン検討や成果物のサンプルチェックには一定レベルの専門知識が必要です。各PMOメンバーがこのスキルを必ず有している必要はないですが、PMOチームの中にこのようなスキルを持ったメンバーを配置して体制構築することが大事です。
例えば、若手PMOメンバーが日々の進捗確認を行い、ベテランのPMOメンバーがサンプルチェックやリカバリプラン検討をサポートする、という役割分担が有効です。
確かめるのではなく信頼関係を作る
進捗の真偽を確かめようとするアプローチは、多くの場合うまくいきません。エンジニアとPMOの関係が監視する側とされる側になってしまい、正確な情報が上がってこなくなるからです。
「ただ進捗を聞いてくる人」と思われたPMOは、エンジニアから信頼されず、形式的な報告しか得られません。進捗率の妥当性を疑い、完了報告の真偽を確かめようとすればするほど、関係は悪化します。
必要なのは、正確な進捗報告が自然に上がってくる仕組みです。適切なWBSを作り、着手確認と完了確認で認識齟齬を防ぎ、遅延時には一緒にリカバリプランを考える。こうして「助けてくれる存在」として認識されることで、信頼関係が生まれます。
ただし、何でもかんでもエンジニアを信じればよいわけではありません。5人日以内のタスク分割により早期に遅延を検知し、サンプルチェックで成果物の品質を確認する。仕組みと信頼関係の両輪が重要です。
完璧な正解はありませんが、進捗の真偽を確かめようとするのではなく、正確な報告が自然に上がってくる関係性を作るという姿勢こそが、確実な進捗管理を実現する鍵なのです。
