1. 導入：教科書通りの進め方では失敗する
「要件定義をして、設計をして、開発をして、テストをして、納品」。 システム開発の進め方を調べると、このような階段状の工程（ウォーターフォールモデル）が紹介されます。
しかし、この通りに進めて成功するプロジェクトは稀です。なぜなら、「最初に決めた計画通りに全てが進む」という前提自体が、現代のビジネス環境では非現実的だからです。
半年かけて完璧な計画書を作っても、いざ開発が始まれば「やっぱりこの機能も欲しい」「画面のイメージが違う」という変更は必ず発生します。 本記事では、教科書的な工程論ではなく、不確実な開発現場で失敗を防ぐための、「動くもの（プロトタイプ）」を中心とした実践的な進め方を解説します。
2. 問題の正体：言葉とドキュメントの限界
多くのプロジェクトが進め方で躓く最大の原因は、「言葉や静止画（ドキュメント）だけで合意形成しようとする」点にあります。
弊社の知見によると、人間はデザイン画を見せられても、実際に操作してみるまでは「本当に使いやすいか」「業務に合うか」を判断できません。 ドキュメントだけで「承認」を積み重ね、完成直前に初めて動くシステムを見て「思ったのと違う」と気付く。これがシステム開発における最大の悲劇であり、手戻りによるコスト増大の主因です。エクセルで作ったドキュメントを作って形骸化するプロジェクトをたくさん見てきました。
3. 実践手順：成功率を高める5つのステップ
リスクを最小限に抑え、納得感のあるシステムを作るための具体的な5ステップを紹介します。
ステップ1：現状分析と「やりたいことリスト」の作成
いきなりシステム会社に相談する前に、社内の現状（As-Is）を可視化します。 「今の業務フローはどうなっているか」「誰がどのような課題を感じているか」を洗い出し、「やりたいことリスト（要求）」を作成します。 この段階では、システム的な要件（サーバー構成など）を決める必要はありません。ビジネス的な目的と優先度を整理してください。
ステップ2：3つの視点でフィルタリング
「やりたいことリスト」をすべて盛り込むと、予算も期間も破綻します。以下の3つの基準で機能を絞り込みます（フィルタリング）。
1. ビジネス価値：売上向上やコスト削減につながるか？
2. 現場の受容性：現場のスタッフが使いこなせるリテラシーレベルか？
3. 技術的コスト：実装にどれくらい費用がかかるか？
特に「現場が使えるか」の視点が重要です。高機能でも使われなければ意味がありません。
ステップ3：プロトタイプ作成（Proof-first）
要件定義書を書き始める前に、「動くプロトタイプ」を作成します。 Figma makeなどのツールやAIを活用すれば、コードを書かずに画面遷移を確認できる模型を短期間で作れます。 これを現場のユーザーに触らせて、「ボタンの位置はここでいいか」「文字サイズは見やすいか」を検証します。この段階での修正はコストがかかりません。
ステップ4：MVP開発と週次デモ
プロトタイプで合意できたら、必要最小限の機能（MVP）に絞って開発を始めます。 ここでのポイントは、「1〜2週間ごとの週次デモ」を行うことです。 「進捗報告書」ではなく、実際に動く画面を毎週確認します。「進捗90%です」という言葉より、1つの動く機能を確認する方が確実です。
ステップ5：運用と継続的な改善
リリースはゴールではありません。実際に使い始めると、必ず新たな要望が出てきます。 システムは「作って終わり」ではなく「育てていくもの（生き物）」です。 最初から完璧を目指さず、運用しながら機能を追加・修正していくサイクルを回します。
4. プロジェクト成功のためのチェックリスト
各フェーズで発注者が確認すべきポイントをリスト化しました。
企画・選定フェーズ
• [ ] 「何を作るか（機能）」だけでなく「なぜ作るか（目的）」を言語化できているか？
• [ ] 現場のキーマン（実際に使う人）の意見を聞いたか？
• [ ] パートナー選定時、見積もり金額だけでなく「動く実績」や「思想」を確認したか？
• [ ] いきなり本開発契約を結ばず、プロトタイプ作成（PoC）から始める検討をしたか？
要件定義・設計フェーズ
• [ ] 「やりたいことリスト」に対し、優先順位（松・竹・梅）がついているか？
• [ ] 静止画のデザインだけでなく、画面遷移がわかる「プロトタイプ」を触ったか？
• [ ] 現場のリテラシーを考慮して、機能を削る（引き算する）決断をしたか？
開発・実装フェーズ
• [ ] 1〜2週間に1回、定例ミーティングを設定しているか？
• [ ] 定例では資料の説明だけでなく、「動くデモ」を見せてもらっているか？
• [ ] 進捗報告は「技術的なタスク」ではなく「ビジネス価値（ユーザーができること）」単位でされているか？
• [ ] 「順調です」という報告だけでなく、課題やリスク（Bad News）が共有されているか？
テスト・リリースフェーズ
• [ ] 現場のユーザーが参加してテストを行っているか？
• [ ] マニュアルがなくても直感的に操作できるか確認したか？
• [ ] リリース後の改善予算（保守・改修費）を確保しているか？
6. まとめ
• システム開発は計画通りには進まない。不確実性を前提に進める。
• ドキュメントではなく「動くプロトタイプ」を共通言語にする。
• 機能を詰め込まず、ビジネス価値・ユーザー受容性・コストでフィルタリングする。
• 週次デモで「動くもの」を確認し続け、軌道修正しながら完成に近づける。
--------------------------------------------------------------------------------
よくある質問（FAQ）
Q. プロトタイプを作るのにどれくらいの期間がかかりますか？ A. 規模にもよりますが、Figmaなどを使った画面だけのプロトタイプであれば、ヒアリングから1〜2週間程度で提示できることが一般的です。
Q. 途中で仕様変更はできますか？ A. はい。むしろ、プロトタイプや週次デモを通じて早期に要望を出し、変更することを推奨します。ただし、無制限な変更は予算超過を招くため、優先順位（松竹梅）を見直しながら調整します。
Q. エンジニアに進捗確認をするコツはありますか？ A. 「進捗率は何％ですか？」と聞くのではなく、「今週動くようになった機能を見せてください」と依頼してください。動くものがない場合は、進捗がないとみなして課題を確認しましょう。