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