プロジェクトの進捗報告を受けるたびに「本当に大丈夫なのだろうか」と感じながらも、何をどう確認すればいいか分からず、毎回「分かりました」と返答するしかない——そんな経験はないでしょうか。
「順調です」「予定通りです」という言葉を信じ続けた結果、残り2週間のタイミングで「実は1ヶ月遅れています」と告げられる。このようなシナリオは、システム開発プロジェクトだけでなく、あらゆる種類の業務プロジェクトで繰り返されています。
問題は、報告者が意図的に嘘をついているわけではないケースが多い点です。担当者自身も状況を正確に把握できていなかったり、悪い情報を報告しにくい空気があったりします。だからこそ、報告を「受け取る側」に読み解く技術が必要なのです。
本記事では、進捗報告に潜む5つの危険シグナルと、実態を引き出すための問い返しの型を解説します。明日の報告会から実践できる内容を中心にまとめました。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
進捗報告を誤って読み続けるとどうなるか
「順調です」が正確かどうか確認する仕組みがない構造的問題
プロジェクト進捗報告には、そもそも構造的な問題があります。報告者（担当者やベンダー）は自分が把握している情報を共有しますが、「何が終わっていて何が残っているか」を正確に数値化することは、特にシステム開発では非常に難しい作業です。
「全体の25%が完了しました」という報告を受けても、その25%という数字の根拠が何かは、報告書を眺めるだけでは分かりません。「担当者の感覚値」である場合も多く、意図せず楽観的な数値になっている可能性があります。
受け取る側が適切な問いを持たない限り、実態との乖離は広がり続けます。
報告者が無意識に楽観値を報告してしまうメカニズム
報告者が悪意を持って虚偽の進捗を伝えているケースは、実はそれほど多くありません。多くの場合、以下のような心理的メカニズムが働いています。
楽観バイアス: 人は一般的に、自分が関与しているプロジェクトの完了について楽観的に見積もる傾向があります。「明日には解決できるはず」「今週中には追いつける」という見通しが積み重なると、報告される進捗率は実態より高くなります。
悪いニュースを報告しにくい心理: チーム内に「遅れを報告すると責められる」という空気があると、担当者は問題を小さく見せようとします。遅延が発覚しても「挽回できます」という言葉でやり過ごし、問題が表面化するのを先延ばしにします。
本人も実態を把握していないケース: 大規模プロジェクトでは、担当者自身が全体の進捗を正確に把握できていない場合があります。自分の担当タスクだけを見て「順調」と報告し、他のタスクの遅延を認識していないこともあります。
これらの要因から、「問題ありません」という報告が来たとしても、それが事実かどうかは別の問題として考える必要があります。
進捗報告に潜む「危険シグナル」5つ
次に示す5つのシグナルが報告に現れたときは、すぐに実態を確認してください。それぞれ「なぜ危険か」と「何が起きている可能性があるか」をセットで理解しておくことが重要です。
危険シグナル①「進捗率が90%前後から動かない」
「進捗率90%」という報告が2〜3週間続いているとしたら、それは危険のサインです。
「90%病」とも呼ばれるこの現象は、プロジェクト管理においてよく知られたパターンです。開発や作業が終盤に差し掛かると、残り10%の部分にこそ難しい問題が集中することが多く、予想以上の時間がかかります。一方で報告者は「もうすぐ終わる」という認識から、毎回「90%」「92%」「93%」と少しずつ数字を動かしながら実質的な進捗がない状態を維持し続けます。
また、そもそも「100%になったら何をした状態か」が定義されていないため、進捗率という数字そのものが曖昧な場合もあります。
危険シグナル②「おおむね順調」「問題ありません」などの定性的な表現だけが続く
具体的な数字や完了したタスクの記載がなく、「今週も概ね計画通りです」「特に問題は発生していません」という定性的な表現が繰り返される場合は注意が必要です。
この種の報告は、問題を隠蔽する意図がある場合にも使われますが、それ以上に「担当者自身が実態を数値化して把握していない」場合のサインである可能性があります。何を根拠に「順調」と判断しているのか、具体的な証拠がなければ確認が必要です。
危険シグナル③「完了予定日が毎回後ろ倒しになっている」
先週の報告では「来週末完了予定」だったのに、今週の報告では「再来週完了予定」になっている——こうした予定日のスライドが毎回起きている場合、実態として遅延が進行中です。
特に「完了予定日の変更」が報告書の中で目立たない形で書き換えられている場合は要注意です。「今週の進捗状況」が正常であるように見えても、完了日基準で見ると確実に遅れが積み重なっているというケースがあります。
報告書を受け取ったら、前週の完了予定日と今週の完了予定日を必ず比較してください。
危険シグナル④「やったこと」だけが書かれていて「残り作業」がない
進捗報告書に「今週実施したこと」だけが書かれていて、「残り作業とその見込み工数」が明記されていない場合は、実態が把握しにくくなっています。
完了した作業量を積み上げて進捗率を計算する方法（完成量ベース）は、残りの作業量が見えにくいという欠点があります。プロジェクトの残り期間を正確に予測するためには、「残り作業が何で、それに何時間・何日かかるか」という情報が不可欠です。
「今週はA機能の実装が終わりました」という報告を受けたとき、「B機能・C機能はあとどのくらいで終わりますか」と必ず確認してください。
危険シグナル⑤「リスク・課題欄が毎回空欄または形式的な記載のみ」
報告書に「リスク・課題」欄があるにもかかわらず、毎回「特になし」「引き続き注意します」といった記載しかない場合は注意が必要です。
プロジェクトにリスクや課題がまったく存在しないというケースはほとんどありません。通常、開発プロジェクトでは要件の曖昧さ、技術的なはまりどころ、外部依存（他チームの成果物待ち、外部API連携など）といったリスクが常に存在します。
「課題なし」が続く場合は、問題が把握されていないか、報告されていないかのどちらかです。どちらも早期に対処すべき状況です。
シグナルを察知したら使う「問い返しの型」
危険シグナルを発見したとき、どう問えばいいか分からず沈黙してしまう——これも多くの方が抱える悩みです。責め立てているように聞こえたり、信頼関係を損なうのではないかと躊躇される場合もあるでしょう。
ここで紹介するのは、実態を引き出すために使える具体的な問い返しの型です。責めるのではなく「一緒に把握しよう」というスタンスで問いを立てることがポイントです。
問い返しの基本フレーム——What / Why / How
日経コンピュータの記事でも紹介されている「What / Why / How」の三問フレームは、進捗確認で実態を引き出すために有効です。
問い | 意味 | 例文 |
|---|---|---|
What | 何が完了しているか | 「今週完了した作業を具体的に教えてください」 |
Why | なぜその進捗状況なのか | 「現在の進捗になった理由（想定より速い・遅い理由）を教えてください」 |
How | 今後どうするか | 「次のマイルストーンまでに何が残っていて、それに何日かかりますか」 |
この三問に答えられない場合は、報告者自身が実態を把握できていない可能性があります。その場合は把握する時間を設けることが先決です。
シグナル別の問い返し例
シグナルの種類に応じて、以下のように問いを変えると実態が引き出しやすくなります。
「90%から動かない」場合
- 「残り10%を完了するために、具体的に何の作業が残っていますか？それにはあと何日かかりますか？」
- 「100%になったとき、どのような状態になっていますか？完了の定義を教えてください」
「定性的な表現が続く」場合
- 「今週完了したタスクを1つずつ挙げてもらえますか？」
- 「スケジュール表と照らし合わせると、今週終わる予定だったものはどれですか？それは完了しましたか？」
「完了予定日が後ろ倒し」の場合
- 「先週の報告書では○月○日完了予定でしたが、今週の予定は○月○日になっています。この変更はどのような理由で発生しましたか？」
- 「変更が発生したとき、すぐに連絡をいただけますか？報告書の提出を待たずに教えてほしいのですが」
「残り作業の記載がない」場合
- 「今後残っている作業をリストアップしてもらえますか？それぞれの完了見込み日も合わせて教えてください」
「リスク・課題欄が空欄」の場合
- 「今の時点で、プロジェクトの完了を難しくする可能性があると感じていることはありますか？小さなことでも教えてください」
- 「外部に依存している部分（他チームの作業、外部サービスの連携など）で不確かな点はありますか？」
問い返しが機能しないケース
問い返しを重ねても実態が見えてこない場合、以下の可能性を検討してください。
一つは、担当者が本当に全体像を把握していないケースです。この場合は、担当者一人への問い返しではなく、プロジェクト全体を俯瞰できるリーダーや複数メンバーとの確認の場を設けることが有効です。
もう一つは、報告しにくい空気が生まれているケースです。「遅れを報告すると叱られる」という認識が担当者の間に広がっていると、誠実な情報共有が難しくなります。「問題を早期に共有してくれることを歓迎する」というメッセージを明示的に伝えることが必要です。
仕組みとして「正確な実態」を可視化する方法
問い返しによる確認は有効ですが、毎回の報告会で個別に問い続けるのは双方にとって負担です。より根本的な解決策として、報告の仕組み自体を整備することで、自然に実態が見える状態を作れます。
完了基準を最初に合意する
プロジェクト開始時に「何をもって完了とするか」を合意してください。これはアジャイル開発で「Definition of Done（完了の定義）」と呼ばれる概念で、システム開発以外のプロジェクトにも応用できます。
例えば、「画面が動いている」だけではなく「テスト完了・レビュー済み・本番環境で確認済み」を完了とする、あるいは「資料作成」であれば「ドラフト→レビュー→修正→最終確認」のどのフェーズで「完了」なのかを定義します。完了基準が曖昧なまま進捗率を報告させると、担当者ごとの解釈のばらつきが生まれ、90%病が起きやすくなります。
「残り時間・残り工数」を報告フォーマットに含める
「今週やったこと」に加えて「残り作業と見込み完了日」を必ず報告フォーマットに入れることで、実態が見えやすくなります。
残工数や残時間を毎週記録していくと、プロジェクト全体を通じた完了予測が立てやすくなります。工数が増えていれば追加コスト・スコープの変更判断、時間が増えていれば納期の見直しを早期に判断できます。
報告フォーマット例:
- 今週完了したタスク（具体的に）
- 来週取り組む予定のタスク（具体的に）
- 残り作業の一覧と、それぞれの見込み完了日
- 現在のリスク・課題（なければ「なし」と明記）
リスク・課題を常に記載させる報告テンプレートの活用
「リスク・課題なし」という記載を減らすには、記載が義務になるフォーマットを使うことが有効です。「リスク・課題」欄を「特になし」と書くと目立つような設計、あるいは「今週発生した課題」「今後発生しうるリスク」を別々の欄にすることで、記載の抜けを防ぎやすくなります。
課題管理ツール（Jira、Backlog、Asana など）を使ってリスク・課題をチケット化し、ステータスを可視化する方法も効果的です。ツールを使うことで、進捗報告書に記載されていなくても課題の実態が共有されます。
まとめ——進捗報告は「信頼」ではなく「読む技術」で管理する
進捗報告を正しく読む技術は、プロジェクトの成否を大きく左右します。報告者を信頼することは大切ですが、「信頼しているから確認しない」では、問題が表面化したときには手遅れになりかねません。
今回紹介した5つの危険シグナルを、次回の報告会から活用してください。
進捗報告の危険シグナル チェックリスト
- 「進捗率が90%前後から数週間動いていない」——残り作業と完了定義を確認
- 「おおむね順調など定性的な表現だけが続く」——完了タスクを具体的に確認
- 「完了予定日が毎回後ろ倒しになっている」——日付変更の理由と即時報告をルール化
- 「やったことだけで残り作業の記載がない」——残工数と見込み日を確認
- 「リスク・課題欄が毎回空欄または形式的」——外部依存や不確実な部分を確認
これらのシグナルに早期に気づき、適切な問い返しができるようになれば、プロジェクトの遅延リスクを大幅に減らせます。報告を「受け取る」のではなく「読み解く」という姿勢が、プロジェクトを守る第一歩です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
