1. 導入：「順調です」という報告の裏側にあるブラックボックス
「スケジュール通り、進捗は順調です」 毎週の定例会議でプロジェクトマネージャーからそう報告を受けて安心していたのに、リリースの1ヶ月前になって突然「バグが多発しており、間に合いません」と告げられる。
これはシステム開発における典型的な失敗パターンです。なぜ、直前になるまで遅延が発覚しなかったのでしょうか。嘘をついていたわけではありません。彼らの基準では「コードは書き終わっていた（＝順調）」からです。
しかし、経営者にとって重要なのは「コードが書かれたか」ではなく「ビジネスに使える状態になったか」です。この認識のズレ（ブラックボックス）を解消しない限り、悲劇は繰り返されます。
2. 問題の正体：ガントチャートと「進捗90%」の罠
多くのプロジェクトで使われるガントチャート（工程表）には、大きな落とし穴があります。それは、開発という作業が「不確実性との戦い」であり、当初の計画通りに進むことはほぼあり得ないということです。
また、エンジニアはタスクを「データベース構築」「API作成」「画面実装」といった技術的な単位で管理しがちです。これらが並行して進むと、全体の進捗率は「90%」に見えますが、実はこれらが結合して動く機能は「0個」という状態が起こり得ます。
「部品はできているが、動く車は一台もない」。これでは進捗とは言えません。経営者が確認すべきは、タスクの消化率ではなく、完成した機能の数です。
3. 実践手順：本当の進捗を見抜く3つのポイント
エンジニアの専門用語に惑わされず、プロジェクトの実態を把握するために、経営者が確認すべき3つのポイントを解説します。
ポイント1：言葉や資料ではなく「動くデモ」を見る
進捗報告会でパワーポイントの資料を読み上げるのはやめましょう。代わりに、その時点で作られている「動くソフトウェア」を実演（デモ）してもらってください。
今の時代、生成AIなどの活用により開発スピードは加速しています。1〜2週間あれば、何かしらの機能は見せられるはずです。もし「バックエンド（裏側の処理）しかできていないので見せられません」と言われたら要注意です。 動くものを見せない限り、それは「進捗ゼロ」とみなすくらいの厳しい基準を持ってください。「来週までには動くものを見せてほしい」とリクエストすることが、プロジェクトに健全な緊張感を生みます。
ポイント2：タスクを「ビジネス価値」で管理させる
進捗表の項目が「DB設計」「サーバー構築」といった専門用語で埋め尽くされていませんか。これでは経営者は判断できません。 タスクの親項目（親タスク）を、「ユーザーが会員登録できる」「商品を検索できる」といったビジネス価値（ユーザーストーリー）にするよう指示してください,。
• 親タスク（ビジネス価値）：ユーザーが商品をカートに入れられる
- 子タスク：データベース設計
- 子タスク：画面デザイン
- 子タスク：ボタン実装
このように階層化し、「すべての子タスクが完了し、実際に動く状態」になって初めて、親タスクを完了とみなします。こうすれば、「進捗90%だけど機能は動かない」という事態を防げます。
ポイント3：課題・問題が共有されているか確認する
順調な報告ばかりが続くプロジェクトは危険です。システム開発にトラブルは付き物であり、何も課題がないこと自体が不自然だからです。 「現在、技術的に詰まっているところはあるか」「仕様が決まっていなくて困っていることはないか」と、こちらから課題を聞き出してください。
エンジニアは完璧な状態を見せようとして、不都合な真実を隠したり、解決しようと抱え込んだりする傾向があります。 「トラブルは早く言ってくれた方が助かる」という姿勢を示し、悪いニュースほど早く共有される文化を作ることが、進捗管理の要諦です。
4. 具体例：ブラックボックス型 vs 可視化型
失敗ケース：ブラックボックス型
PMがガントチャートで管理。「設計完了」「実装完了」という工程ベースで進捗報告を受けていた。進捗率は常にオンスケジュールだったが、結合テストの段階で「画面とデータが繋がらない」という不具合が大量発生。実は動く状態での確認を一度もしていなかったため、リカバリー不能となり納期が3ヶ月遅れた。
成功ケース：可視化型（週次デモ）
2週間ごとのスプリント（短い開発期間）を採用。「ログイン機能」「検索機能」など、機能単位で開発を進めた。 隔週の定例会議では必ず「動くデモ」を実施。最初は画面が崩れていたが、その場でフィードバックを行い修正。進捗が遅れている機能も一目瞭然だったため、優先度の低い機能（梅機能）を早期にカットする判断ができ、納期通りに重要機能のみをリリースできた,。
5. まとめ
• システム開発は計画通りに進まない前提で、柔軟に対応する。
• 「進捗率」などの数字や資料ではなく、実際に動く「デモ」で確認する。
• タスクは技術単位ではなく、「ビジネス価値（ユーザーストーリー）」で管理し、動く状態になって初めて完了とする。
• 「動くもの」を定期的に確認することで、エンジニアとの信頼関係が生まれ、リスクを早期に発見できる。
ゼロスタートでは、週次デモを通じて進捗を完全に可視化します。「何ができているか」が常にクリアな状態でプロジェクトを進められるため、ブラックボックス化する心配がありません。
--------------------------------------------------------------------------------
よくある質問（FAQ）
Q. エンジニアが「まだ見せられる状態じゃない」とデモを嫌がります。 A. エンジニアは完成品を見せたがる傾向があり、未完成品を見せる作業を「遠回り」と感じることがあります。しかし、発注者としては安心材料が必要であることを伝え、「品質チェックではないので、進捗確認のために見せてほしい」と説得してください。
Q. どのくらいの頻度で確認すべきですか？ A. 1〜2週間に1回が目安です。今の開発スピードであれば、2週間あれば何らかの機能追加や進捗は見せられるはずです。それ以上間隔が空くと、手戻りのリスクが高まります。
Q. 進捗が遅れている場合、どうすればいいですか？ A. 詰めるのではなく「なぜ遅れているか」を聞き、課題を特定してください。その上で、優先順位の低い機能（梅機能）を削るか、リリース時期を調整するか、経営判断を行うのが発注者の役割です。