2026/1/23

生成AI受託開発のプロジェクト進行|要件定義からPoC・本番化までの全ステップ

教科書通りの進め方では失敗する

「要件定義をして、設計をして、開発をして、テストをして、納品」。 システム開発の進め方を調べると、このような階段状の工程(ウォーターフォールモデル)が紹介されます。

しかし、この通りに進めて成功するプロジェクトは稀です。なぜなら、「最初に決めた計画通りに全てが進む」という前提自体が、現代のビジネス環境では非現実的だからです

半年かけて完璧な計画書を作っても、いざ開発が始まれば「やっぱりこの機能も欲しい」「画面のイメージが違う」という変更は必ず発生します。 本記事では、教科書的な工程論ではなく、不確実な開発現場で失敗を防ぐための、「動くもの(プロトタイプ)」を中心とした実践的な進め方を解説します。

成功率を高める5つのステップ

リスクを最小限に抑えながら、納得感のあるシステムを作るための具体的な5ステップを紹介します。

ステップ1:現状分析と「やりたいことリスト」の作成

いきなりシステム会社に相談する前に、社内の現状(As-Is)を可視化します。 「今の業務フローはどうなっているか」「誰がどのような課題を感じているか」を洗い出し、「やりたいことリスト(要求)」を作成します。 この段階では、システム的な要件(サーバー構成など)を決める必要はありません。ビジネス的な目的と優先度を整理してください。

ステップ2:3つの視点でフィルタリング

「やりたいことリスト」をすべて盛り込むと、予算も期間も破綻します。開発側と相談しながら、以下の3つの基準で機能を絞り込みます(フィルタリング)。

1. ビジネス価値:売上向上やコスト削減につながるか?

2. 現場の受容性:現場のスタッフが使いこなせるリテラシーレベルか?

3. 技術的コスト:実装にどれくらい費用がかかるか?

特に「現場が使えるか」の視点が重要です。高機能でも使われなければ意味がありません。

ステップ3:プロトタイプ作成

要件定義書を書き始める前に、「動くプロトタイプ」を作成します。開発側はFigma MakeやBolt、Lovableといった生成AIツールを活用すれば、プロンプトから動作するプロトタイプを短期間で作成できます。プロトタイプを現場のユーザーに触らせて、「ボタンの位置はここでいいか」「文字サイズは見やすいか」を検証します。この段階での修正は計画後半の修正と比較した場合コストが抑えられます。

ステップ4:MVP開発と週次デモ

プロトタイプで合意できたら、必要最小限の機能(MVP)に絞って開発を始めます。 ここでのポイントは、「1〜2週間ごとの週次デモ」を行うことです。 「進捗報告書」だけではなく、実際に動く画面を毎週確認します。「進捗90%です」という言葉より、1つの動く機能を確認する方が確実です。

ステップ5:運用と継続的な改善

実際にシステムをリリースします。しかし、リリースはゴールではありません。実際に使い始めると、必ず新たな要望が出てきます。 システムは「作って終わり」ではなく「育てていくもの(生き物)」です。 最初から完璧を目指さず、運用しながら機能を追加・修正していくサイクルを回します。

プロジェクト成功のためのチェックリスト

各フェーズで発注者が確認すべきポイントをリスト化しました。

企画・選定フェーズ

• 「何を作るか(機能)」だけでなく「なぜ作るか(目的)」を言語化できているか?

• 現場のキーマン(実際に使う人)の意見を聞いたか?

• パートナー選定時、見積もり金額だけでなく「動く実績」や「思想」を確認したか?

• いきなり本開発契約を結ばず、プロトタイプ作成(PoC)から始める検討をしたか?

要件定義・設計フェーズ

• 「やりたいことリスト」に対し、優先順位がついているか?

• 静止画のデザインだけでなく、画面遷移がわかる「プロトタイプ」を触ったか?

• 現場のリテラシーを考慮して、機能を削る(引き算する)決断をしたか?

開発・実装フェーズ

• 1〜2週間に1回、定例ミーティングを設定しているか?

• 定例では資料の説明だけでなく、「動くデモ」を見せてもらっているか?

• 進捗報告は「技術的なタスク」ではなく「ビジネス価値(ユーザーができること)」単位でされているか?

• 「順調です」という報告だけでなく、課題やリスクが共有されているか?

テスト・リリースフェーズ

• 現場のユーザーが参加してテストを行っているか?

• マニュアルがなくても直感的に操作できるか確認したか?

• リリース後の改善予算(保守・改修費)を確保しているか?

5. まとめ

生成AIを使ったシステム開発において、重要なポイントは下記の通りです。これらを抑えてシステム開発を成功させましょう。

• システム開発は計画通りには進まない。不確実性を前提に進める。

• ドキュメントではなく「動くプロトタイプ」を共通言語にする。

• 機能を詰め込まず、ビジネス価値・ユーザー受容性・コストでフィルタリングする。

• 週次デモで「動くもの」を確認し続け、軌道修正しながら完成に近づける。

--------------------------------------------------------------------------------

FAQ

Q1. プロトタイプを作るのにどれくらいの期間がかかりますか?

A. 規模にもよりますが、Figma MakeやBoltなどの生成AIツールを使えば、動作するプロトタイプをヒアリングから1〜2週間程度で提示できることが一般的です。

Q2. 途中で仕様変更はできますか?

A. 契約内容によって変更可能な範囲が定められます。プロトタイプや週次デモを通じて早期に要望を出し、変更することを推奨します。ただし、無制限な変更は予算超過を招くため、優先順位を見直しながら調整します。

Q3. エンジニアに進捗確認をするコツはありますか?

A. 「進捗率は何%ですか?」と聞くのではなく、「今週動くようになった機能を見せてください」と依頼してください。動くものがない場合は、進捗がないとみなして課題を確認しましょう。

関連記事

「プロジェクトの進め方」カテゴリの他の記事

失敗しないRFPの作り方|骨格テンプレートと9つの落とし穴

2026/5/3
読む

生成AI/DXの導入は「業務可視化」から始める|As-Is/To-Beで失敗しない進め方完全ガイド

2026/5/3
読む

要求定義と要件定義の違い|混同しやすい3つのポイントと実例で整理

2026/4/28
読む

要件定義の進め方|実プロジェクト例で学ぶ5フェーズ実践ガイド

2026/4/28
読む

【無料DL】要件定義書テンプレート+EARS記法とユーザーストーリーの実例集

2026/4/28
読む

要件定義とは?目的・進め方・要件定義書テンプレートまで完全ガイド【2026年版】

2026/4/28
読む

EARS×Gherkin|要件定義からデモ/シナリオテストまでを生成AIで一直線につなぐ

2026/4/28
読む

Gherkin入門|Given/When/Thenでシナリオテストを書く・読むための完全ガイド

2026/4/28
読む

発注側がやらなくていい2つのこと|WBSとフロー図の維持を捨ててスコープ管理に集中する

2026/4/28
読む

要件の優先順位付け: MoSCoW vs FM法 完全比較|どちらをいつ使うか

2026/4/28
読む

EARS(要件記述構文)入門|曖昧さを排除する5パターンと書き方の実例

2026/4/28
読む

スコープ管理「FM法」の使い方|要件を3軸で見える化して何を作らないか決める

2026/4/28
読む

【無料テンプレート】ユーザーストーリーの書き方完全ガイド|AsA・IWantTo・SoThat の3要素を使いこなす

2026/4/28
読む

生成AI開発の進め方|PoCからプロトタイプ・本番までの全工程

2026/4/27
読む

システム開発の進め方 完全ガイド|発注側のプロジェクト管理

2026/3/16
読む

システム開発の要件定義の進め方|失敗しない7ステップと発注者がやること

2026/3/10
読む

生成AI時代のシステム開発の進め方

2026/3/6
読む

システム開発「思ったのと違う」を防ぐ3ステップ|要件のズレ対策

2026/1/23
読む

システム開発を段階的に進める方法|MVP・プロトタイプ活用法

2026/1/23
読む

システム開発の失敗事例8選|原因と発注側ができる対策

2026/1/23
読む

この知識を実践してみませんか?

現状(As-Is)と改善後(To-Be)を可視化して改善点を発見できます。

次の工程で使うツール: 要件を3軸で評価して「作る/後回し/作らない」を整理できます

いきなり試すのが不安な方は 先に相談する こともできます。