1.よくある失敗
システム開発のプロジェクトにおいて、発注者が最も頭を抱える瞬間。それは、毎週の定例会議で「進捗は順調です」という報告を受けていたにもかかわらず、リリースの2週間前になって突然、「実は動くものがまだできていません」「納期に間に合いません」と告げられる時です。
「なぜもっと早く言ってくれなかったのか」と憤りたくなる気持ちはわかります。しかし、これはエンジニアが悪意を持って嘘をついているとは限りません。多くの場合、「進捗の定義」が発注者と開発者の間でズレていることが原因で起こる、構造的な悲劇なのです。
本記事では、この認識のズレを解消し、プロジェクトを成功に導くための具体的な管理技術について、よくある5つの失敗事例とともに解説します。
2. 問題の正体：「進捗率95%」の罠
なぜ、報告書上の数字とプロジェクトの実態はこれほど乖離するのでしょうか。よくあるその最大の原因は、「技術目線でのタスクの積み上げ」で進捗を管理していることにあります。
多くのプロジェクトでは、ガントチャートやWBS（作業分解図）を使って、以下のような技術的な工程を管理してしまいます。
- データベース構築：100%完了
- 画面デザイン作成：100%完了
- プログラム実装：90%完了
- これらを平均すると、プロジェクト全体の進捗率は「95%」に見えます。しかし、これらが結合され、実際にデータが流れて機能するかどうかのテストが未実施であれば、ビジネスとしての価値はまだ「0%」です。 「タイヤはあります、ハンドルもあります。でもエンジンと繋がっていないので、車として1メートルも走りません」という状態を、「進捗95%」と報告しているのが、システム開発における数字の罠です。実際にユーザーやステークホルダーに見せて、修正が出ないとも言い切れません。
3. 実践手順：発注者が行うべき管理の技術
この罠を避け、実態のある進捗を把握するために、発注者は以下の手順で管理を行ってください。
手順1：タスクの親カテゴリを「ビジネス価値」に変える
進捗管理表（WBS）を見る際、タスクの親カテゴリが「データベース設計」などの技術用語になっていたら要注意です。 正しい管理方法は、親タスクを「ユーザーストーリー（ビジネス価値）」に設定することです。
• 悪い例：商品データベース構築
• 良い例：ユーザーが商品を登録できる
その親タスクの下に、必要な技術タスク（DB設計、画面作成など）を子タスクとしてぶら下げます。そして、**「子タスクが全て完了し、実際にその機能が動いて初めて、親タスクを完了とする」**というルールを徹底します。 これにより、「裏側の処理はできましたが、画面はまだです」といった状態での完了報告を防ぐことができます。
手順2：数字ではなく「週次デモ」で管理する
「進捗率◯％」という報告書の数字を信じるのはやめましょう。代わりに、1〜2週間ごとの定例会議で、必ず**「動く画面（デモ）」**をユーザーストーリーごとに見せてもらってください。
現代の開発環境（AI活用やノーコードなど）において、2週間あって何も動くものが見せられないということは、通常考えにくいことです。もし、「バックエンドの処理が複雑で...」と言って画面が出てこない期間が2週間以上続くなら、それはプロジェクトが停滞している「危険信号」です。
4. 具体例：よくある5つの失敗と対策
ここからは、プロジェクト管理で頻発する具体的な失敗事例と、その対策を紹介します。
失敗事例1：進捗が見えず不安
状況 定例会議ではパワーポイントの報告書が読み上げられるだけで、実物が出てこない。「順調」と言われるが、本当に進んでいるのか確証が持てない。
対策：週次デモで可視化し、定期的に確認する 報告書を読む時間を廃止し、**「前回の会議から今日までに作った動くもの」**を見せてもらうデモの時間に変えてください。動くものがなければ進捗はゼロとみなします。エンジニアは未完成品を見せるのを嫌がることがありますが、「進捗確認のためであり、品質は問わない」と伝えて、強制的に可視化させることが重要です。
失敗事例2：エンジニアとの意思疎通がうまくいかない
状況 「こういう機能が欲しい」と伝えたはずなのに、上がってきたものは微妙にニュアンスが違う。専門用語が多くて会話が噛み合わない。
対策：言葉ではなく「動くもの」で伝える 言葉やドキュメントだけで仕様を詰めようとすると、必ず認識のズレ（Gap）が生じます。開発初期から簡単なプロトタイプ（試作品）を作成し、「これをクリックしたらこうなる」と、動くものを操作しながら会話してください。実物を前にすれば、専門知識がなくても「使いにくい」「イメージと違う」といった具体的な指示が出せます。
失敗事例3：社内の合意が取れず進まない
状況 関係部署によって意見がバラバラで、要件が決まらない。「あちらを立てればこちらが立たず」でプロジェクトが停滞する。
対策：プロトタイプを早期に見せて認識を合わせる 会議室で長時間議論するよりも、荒削りでも良いのでプロトタイプを見せてしまった方が合意形成は早いです。「今の議論を形にするとこうなります」と実物を見せることで、「ここは良いが、ここはダメ」という議論の土台ができ、決定スピードが劇的に上がります。
失敗事例4：作ったシステムが使われない
状況 完成して納品されたが、現場からは「使いにくい」「今の業務フローに合わない」と不評で、結局Excel管理に戻ってしまった。
対策：現場を巻き込み、段階的に導入する 開発の最終段階まで現場に秘密にするのはやめましょう。プロトタイプの段階で現場のスタッフに触ってもらい、「なぜこの機能が必要なのか」「どんな場面で使うのか（ユーザーストーリー）」を確認します。現場の声を反映させながら段階的に機能を作り込むことで、「自分たちのシステム」という当事者意識を持ってもらうことができます。
失敗事例5：報告がうまく伝わらない
状況 経営陣や上層部への報告で、技術的な詳細ばかり説明してしまい、「結局、何ができて何が遅れているのか」が伝わらない。
対策：ビジネス価値で簡潔に伝える 「サーバー構築完了」といった技術用語ではなく、「会員登録機能の実装完了」といったビジネス価値（ユーザーストーリー）単位で報告してください。また、言葉で説明するよりも、スマホやタブレットで実際のデモ画面を見せる方が、進捗の説得力は何倍にもなります。
5. まとめ
システム開発のプロジェクト管理において、発注者が意識すべきポイントは以下の通りです。
- 進捗報告書の「パーセンテージ」や「ガントチャート」を過信せず、「動くもの」があるかどうかで進捗を判断する。
- 管理表（WBS）の親タスクを技術用語ではなく、「ビジネス価値（ユーザーストーリー）」に設定し、機能単位で管理する。
- 1〜2週間ごとに実演デモを行い、言葉ではなく実物でコミュニケーションをとる。
- 「ITは分からない」と丸投げせず、なぜその機能が必要かという「背景」を共有し続ける。
不確実性の高いシステム開発において、計画を守ることよりも、「短いサイクルで動くものを作り、事実を確認しながら修正していくこと」こそが、失敗を回避する唯一の方法です。
まずは、次回の定例会議で「資料説明はいいので、今動くものを見せてください」と言ってみることから始めてみましょう。
--------------------------------------------------------------------------------
よくある質問（FAQ）
Q. 毎週デモをするのはエンジニアの負担になりませんか？ A. 準備の負担はありますが、最後にまとめて「イメージと違う」となって作り直すコストに比べれば、はるかに安上がりです。また、デモをマイルストーンにすることで、チームに良い緊張感とリズムが生まれます。
Q. プロトタイプを作る費用は余計にかかりませんか？ A. 作成費用はかかりますが、本開発での手戻りを防ぐための保険料と考えれば安いものです。最近はAI活用により、プロトタイプ作成のコストは劇的に下がっています。
Q. エンジニアが未完成のものを見せたがりません。 A. 「品質チェックではなく、認識合わせがしたいだけ」「責任は問わない」と伝えて安心させてください。エンジニアは「未完成のものを見せて怒られる」ことを恐れています。