システム開発にもAIが使われる時代に
生成AIは私たちのビジネスや生活において多くの変革をもたらしています。システム開発の現場でも生成AIが使われており、作業効率とコストが大幅に改善されています。実際、これまで数か月かかっていたプロトタイプ作成が1〜2週間で済むケースも出てきました（参考: 生成AI開発のスピード｜プロトタイプを1〜2週間で作る方法）。
生成AIによって開発の手法がどれほど改善されても、実はシステム開発プロジェクトにおける「成果物が思ってたのと違う」という悲劇は起こり得るのです。むしろ高速化したからこそ、上流工程の精度が結果を大きく左右します。今回は、生成AI時代にこそ発注者が把握しておくべきシステム開発の進め方について、PoCからプロトタイプ・本番までの全工程で解説します。
発注者側の進め方を体系的に押さえたい方は、先に システム開発の進め方 完全ガイド｜発注側のプロジェクト管理 を読むと全体像を掴みやすいです。
AIが改善できること、人じゃないとできないこと
生成AIがシステム開発の作業を改善したというのは事実ですが、具体的にAIはシステム開発において何を改善できるのでしょうか。生成AIが貢献できる点の一つとして、開発初期段階においてプロンプト（指示文）から短期間で画面イメージやプロトタイプを作れてしまうことが挙げられます。これまでは人間が一からコードを書いていたのですが、その作業を今では生成AIがかなりの割合で代替してくれます。
一方で、開発の前段階となる「現場でどう使われるのか」というシナリオが間違っていれば、間違ったシステムが超高速で出来上がるだけになり、結果的に誰も使わないシステムを生み出してしまいます。システム開発が失敗して手戻りや炎上を起こす原因の多くは、「誰が何のために何をするのか」というユーザーシナリオ（ユーザーストーリー）が定義できていないことにあります（書き方は 【無料テンプレート】ユーザーストーリーの書き方完全ガイド で詳しく解説）。これに関して生成AIはアイデアの提案や整理に貢献できますが、社員がシステムをいつどのように使うかは人が決める必要があります。
したがって、AIが普及した今の時代でもシステム開発はユーザー目線で人間が設計しない限り、誰にも使われないシステムができてしまうのです。「使われないシステム」を防ぐ具体策は 「作ったのに使われない」を防ぐ機能フィルタリング｜FM活用法 でも紹介しています。
AIに任せること / 人がやることの早見表
領域 | AIが得意 | 人がやるべき |
|---|---|---|
要件発散 | アイデア量産・観点出し | 業務文脈での取捨選択 |
シナリオ定義 | たたき台の整形 | 「誰が・何を・なぜ」の決定 |
画面・プロトタイプ生成 | 初版の高速生成 | 業務フローとの突合・受入判断 |
コード実装 | 定型実装の量産 | 非機能要件・例外処理の責任設計 |
テスト | テストケース案の生成 | 業務シナリオでの最終検証 |
意思決定 | 選択肢の比較整理 | 優先順位付けと責任の引き受け |
AI時代の開発フェーズ｜PoC・プロトタイプ・本番の役割分担
AI活用で開発が高速化した結果、PoC・プロトタイプ・本番という3フェーズの境界が曖昧になりがちです。フェーズごとに「目的」「成果物」「発注者の関与」を明確に分けることで、暴走を防げます。
フェーズ1: PoC（コンセプト検証）
- 目的: 「そもそも作る価値があるか」「技術的に可能か」を最小投資で確かめる
- 成果物: ユーザーシナリオ、画面スケッチ、技術調査メモ、判断ペーパー
- 発注者の関与: シナリオ提示、業務文脈の説明、Go/No-Go判断
- 失敗パターン: PoCのまま本番に流用しようとして、後から非機能要件で破綻
PoC段階では「何を作らないか」を決めることが最重要です。優先順位付けは スコープ管理「FM法」の使い方 や 要件の優先順位付け: MoSCoW vs FM法 完全比較 が参考になります。
フェーズ2: プロトタイプ（動くもので検証）
- 目的: 業務シナリオが実際に成立するかを動く画面で検証
- 成果物: 動くプロトタイプ、ユーザビリティテスト結果、改善バックログ
- 発注者の関与: 現場ユーザーによる実機評価、シナリオの合否判定
- 失敗パターン: 「動いたから完成」と誤解し、現場での使い込みなしに本番へ進める
段階的に進める考え方は システム開発を段階的に進める方法｜MVP・プロトタイプ活用法 でも詳述しています。
フェーズ3: 本番開発・運用
- 目的: 本番運用に耐える品質・性能・セキュリティで実装
- 成果物: 本番環境、運用手順、引き継ぎドキュメント、監視・障害対応体制
- 発注者の関与: 受入テスト、運用設計、変更管理ルールの合意
- 失敗パターン: プロトタイプのコードを流用したまま本番化し、保守不能になる
本番フェーズでは見積もりや契約形態の見直しも論点になります。システム開発の見積もり完全ガイド や 見積もりがブレる理由と追加費用を防ぐ対策 もあわせてどうぞ。
シナリオを軸にした発注側のシステム開発の進め方
システム開発を成功させるためには、発注者自身がシナリオを用意し、開発チームと協力して検証を進める必要があります。ここでいう「シナリオ」とは、ユーザーストーリーと受入条件を組み合わせたもので、Beekleでは無料ツールの ユーザーストーリー作成ツール でテンプレート通りに作成できます。
手順1：やりたいことのシナリオをリスト化する
まずは社内で「誰が、何をしたいのか」という要求をリストアップし、ビジネス的な優先度をつけます。これを作ることで、プロジェクトのテーマやゴールがブレにくくなるメリットがあります。そのリストを開発会社に持ち込み、技術的な実現性や、現場のユーザーが実際に使いこなせるかという目線でフィルタリング（絞り込み）を行います。
絞り込みの判断軸を3つに分けて見える化したい場合は、Scope Manager（無料ツール） で「ビジネス価値・現場で使えるか・技術コスト」の3軸評価ができます。手法の背景は スコープ管理「FM法」の使い方 を参照してください。
手順2：動くプロトタイプで早期にシナリオを検証する
続いて、開発の初期段階で動くプロトタイプ（試作品）を作成してもらいます。人間は言葉だけではシステムのイメージを正確に共有することが難しいため、画面を見ながら実際に自分の業務に各機能が合うか、想定したシナリオ通りに業務が進められるかを確認します。データは本番に近い「構造」のサンプルデータ（個人情報はマスキングまたはダミー化したもの）を使うと、より実践的なフィードバックができます。個人情報保護や情報セキュリティの観点から、プロトタイプ段階で実顧客情報を無加工で使うのは避けましょう。
「思っていたのと違う」を防ぐ具体的な進め方は システム開発「思ったのと違う」を防ぐ3ステップ｜要件のズレ対策 で別途まとめています。
手順3：シナリオをベースに共にテストを行う
ある程度開発が進んだら、想定されたシナリオを基にテストを実施します。開発ベンダーの多くは、言われた機能を作ることは得意でも、発注側のビジネスの背景や目的までは考えてくれません。そのため、システムをテストする際はベンダーに丸投げせず、発注側も一緒になってシナリオ通りの動きができるか確認することが重要です。
受入条件を曖昧さなく記述したい場合は、EARS（要件記述構文）入門｜曖昧さを排除する5パターン の構文を使うと、テスト項目に直結する形で書けます。
シナリオ駆動開発のチェックリスト
- 誰が、何を、なぜ行うのかというシナリオ（背景）が言語化できているか
- 言葉や静止画だけでなく、動くプロトタイプを使ってシナリオを検証しているか
- ベンダー任せにせず、発注者自身もテストや動作確認に参加する体制があるか
- 「使う人」「使う頻度」「使う場面」が現場視点で具体化されているか
- 「作らない機能」を意思決定として明文化したか
- バーコードを読み取る
- 合計金額を表示する
- 現金で会計する
- レシートを印刷する
誰が・どんな状況で・どんな順序で使うかが不明。機能は正しく動いても現場では使えない。
レジ担当者として、混雑時に会計列を止めないために、割引シールを貼った商品は1タップで単価変更したい。
また、現金とクーポン併用の会計も1画面で完結させたい。
返品対応は管理者呼出なしで処理したい。
誰が・いつ・どんな制約下で使うかが明確で、エンジニアが適切な設計を選べる。
AI生成プロトタイプの評価｜「動く」≠「使える」
AIが生成したプロトタイプは見た目が整っているため、つい「これで完成」と思いがちです。しかし、現場で使えるかは別問題です。受入判断の前に、以下の観点で評価しましょう。
- 業務シナリオ完走: 主要シナリオが最初から最後まで止まらず通るか
- 例外操作: 入力ミス・キャンセル・戻る操作で破綻しないか
- 負荷耐性の見立て: ピーク時の同時利用やデータ量で持つか
- セキュリティ: 認証・権限・ログ・データ取り扱いが要件を満たしているか
- 運用性: マスタメンテ・障害時対応・引き継ぎの段取りが現実的か
- 非機能要件: 性能・可用性・保守性などの目標値に対する見通しがあるか
AI生成コードは「とりあえず動く」だけで、上記が抜けていることが多々あります。本番化前にチェックリストで一つずつ潰すのが基本です。
シナリオ不在の失敗事例とシナリオ共有による成功事例
よくある失敗例：
ある中規模スーパーでレジシステムをリニューアルしました。発注者は「バーコードで商品を読み取り、合計金額を表示する」という基本機能だけを伝えていました。システム会社は機能としては正しく動くものを作りましたが、運用が始まると次々に問題が発覚しました。
- 割引シールを貼った商品の単価変更に5タップ必要で、混雑時に2レーン分の行列が伸びた
- 現金とクーポン併用の会計で画面遷移が3画面にまたがり、打ち直しが頻発した
- 返品処理の導線が「管理者呼出」必須で、1件あたり3〜5分のロスが発生した
原因は、現場のオペレーターが「どんな場面で・どんな順序で・どんな割り込みを受けながら」使うかというシナリオが要件に含まれていなかったことでした。機能一覧は正しくても、シナリオが欠けると現場では使えないシステムになります。同様の失敗パターンは システム開発の失敗事例8選｜原因と発注側ができる対策 でも紹介しています。
成功例：
訪問看護事業所の記録システム開発では、単に機能のリストを渡すのではなく、「訪問看護師が利用者宅で、その場で看護記録をつけたい。なぜなら帰社してから30件分を思い出して記録すると記憶違いが起きるからだ」といった具体的なシナリオと背景を共有しました。これにより、エンジニアは「オフライン保存」「前回記録の自動呼び出し」「音声入力」など複数の技術選択肢を検討できるようになりました。さらにプロトタイプを実際の看護師に触ってもらい、車内での片手操作や訪問先のネットワーク環境まで確認した結果、現場に定着するシステムが完成しました。
AI時代の見積もり・契約で押さえる3点
AI活用で開発が高速化すると、見積もりと契約の前提も変わります。発注者として最低限押さえたい3点です。
- フェーズ別契約: PoC・プロトタイプ・本番を一括見積もりにせず、フェーズごとに契約を切る。失敗してもPoCで止められる。
- 成果物の所有権・再利用条件: AIで生成したコードや学習に使ったデータの権利関係を契約で明示する。
- 変更コストの織り込み: 高速で作れる分、要件変更も発生しやすい。変更管理のルールと費用負担の取り決めを事前に。
見積もり全般は システム開発の見積もり完全ガイド、複数社比較のチェック項目は 失敗しない見積もり比較チェックリスト をどうぞ。
まとめ
生成AIは人間より格段に優秀なはたらきをする時がありますが、あくまでも作業効率を高めてくれるツールです。下記のポイントを押さえながら、AI時代のシステム開発を成功させていきましょう。
- 生成AI時代は開発が高速化するため、基盤となるシナリオ定義がより重要になる
- 単なる機能一覧ではなく、ユーザーの振る舞い（誰が、何を、なぜ）を軸にする
- 言葉の解釈ズレを防ぐため、動くプロトタイプでシナリオを検証する
- 開発会社はビジネスの背景までくみ取らないため、発注側もテストに協力する
- PoC・プロトタイプ・本番のフェーズを混ぜず、目的と成果物を明確に分ける
- AI生成プロトタイプは「動く」だけ。現場の業務シナリオで受入判断する
FAQ
Q1. シナリオ（ユーザーストーリー）はどこまで細かく書けばよいですか？
A. 発注側は「誰が・何を・なぜ」という主語と動詞のセットで主要シナリオを言語化することに集中してください。例外シナリオ（エラー時や離脱時など）の洗い出しはシステム会社がリードしてくれることが多いので、発注側が最初から全パターンを網羅する必要はありません。大切なのは、主要な業務フローの背景と目的をしっかり伝えることです。書き方の型は ユーザーストーリーの書き方完全ガイド を参照ください。
Q2. PoCとプロトタイプの違いは？
A. PoCは「コンセプトが成立するか」を判断するための検証で、必ずしも動かなくても構いません（紙のスケッチ、技術調査メモ、判断ペーパーなど）。プロトタイプは「業務シナリオが動く画面で成立するか」を確かめるもので、現場ユーザーに触ってもらえる粒度まで作り込みます。両者を混同して「動くPoC」を作ると、本番化のタイミングを逃します。
Q3. AIが書いたコードの品質はどう確認すればよいですか？
A. 発注者側で見るべきは「業務シナリオが完走するか」「例外操作で破綻しないか」「現場で運用できるか」の3点です。コードの内部品質（保守性・テスト網羅率・セキュリティ）は開発会社の責任範囲なので、契約上の品質基準と受入条件を明確にしておくことが現実的な解です。受入条件の書き方は EARS（要件記述構文）入門 が役立ちます。
Q4. 生成AIで開発期間は実際どれくらい短縮できますか？
A. プロトタイプフェーズでは数か月→1〜2週間といった大幅な短縮が起きるケースもありますが、本番フェーズの短縮幅はもっと小さいのが実情です。理由は、本番化に必要な非機能要件・運用設計・テストは依然として人手の判断が中心になるためです。詳細は 生成AI開発のスピード｜プロトタイプを1〜2週間で作る方法 を参照してください。
Q5. AI開発でも要件定義は必要ですか？
A. むしろAI時代こそ要件定義の重要性が増しています。AIは「指示通りに高速で作る」ことは得意ですが、「何を作るべきか」を判断するのは人間の仕事です。要件が曖昧なままAIで作ると、間違ったものが超高速で完成します。要件定義の進め方は システム開発 要件定義の進め方｜失敗しない7つの観点 をどうぞ。
関連記事 / 関連ツール
- Story Builder（無料ツール） — ユーザーストーリーをテンプレート通りに作成
- Scope Manager（無料ツール） — 3軸で要件を評価し「作る/後回し/作らない」を判定
- システム開発の進め方 完全ガイド｜発注側のプロジェクト管理
- スコープ管理「FM法」の使い方
- 要件の優先順位付け: MoSCoW vs FM法 完全比較
- ユーザーストーリーの書き方完全ガイド
- EARS（要件記述構文）入門
- 「作ったのに使われない」を防ぐ機能フィルタリング
- システム開発を段階的に進める方法
- システム開発「思ったのと違う」を防ぐ3ステップ
- システム開発の失敗事例8選
- 生成AI開発のスピード
- システム開発の見積もり完全ガイド
ご相談
AI時代の開発の進め方や、要件・スコープの整理でお困りなら、無料相談で具体的なアドバイスをお出しします。