AI時代こそ要件定義｜情シスが押さえるべき「BPO見て費用対効果から逆算する」発注術

「AIで速くなるなら要件定義は短くていい」は逆

2024〜2026年にかけて、生成AI（ChatGPT、Claude、GitHub Copilot、Cursor、Claude Codeなど）がコードを機能単位で書けるようになり、ソフトウェア開発の現場が大きく変わりました。エンジニアの役割は「コードを書く人」から「AIが書いたコードをレビューして仕上げる人」へシフトしつつあります。詳しくは生成AI駆動開発（AIファースト開発）とはを参照してください。

この変化を見て「AIでコード生成が速くなるなら、要件定義は短くていい」「上流をスキップして、まず動くものを作ってから決めればいい」と考える方もいます。しかし、Beekleが受託開発の現場で実感しているのは、まったく逆です。AIでコード生成が速くなったからこそ、要件定義の精度がそのまま結果を決めます。間違った要件で速く書けば、間違ったシステムが超高速で出来上がるだけです。

本記事は、情シス向けDXシリーズのうち、AI時代の要件定義に特化した実践記事です。全体像は情シスのためのDX進め方完全ガイドを、姉妹記事としてBPO見直しの進め方とToBe再設計の判断軸も参照してください。

AI時代に要件定義が「より重要」になる構造

「AIが速く書ける」と「要件定義が重要」は矛盾しません。むしろ、コード生成スピードが上がるほど、上流の精度がボトルネックになります。

従来の構造: 上流が崩れても下流で吸収できた

従来の開発では、要件定義が多少曖昧でも、設計フェーズで気づいて修正したり、実装中にエンジニアが現場と再ヒアリングして調整したり、テストフェーズで「これじゃない」が出たときに作り直したりしていました。コード作成の物理的な時間が長かったため、その間に上流の修正が間に合うこともあったのです。

AI時代の構造: 上流が崩れたまま下流まで突き進む

生成AI駆動開発では、コードが機能単位で短期間に書き上がるため、上流の認識ズレが見つかる前に、間違ったシステムが完成してしまうリスクが高まります。「動くもの」がスピーディに出来上がるので、関係者は早期に成果を見て安心しがちですが、実は要件自体がズレているケースが頻発します。

Beekleの実感としては、「最初の8割は超高速で出来るが、残り2割（業務適合・例外処理・本当に使われるかの検証）に従来以上の労力が必要になる」のがAI時代の開発です。ソフトウェア工学のいわゆる「90対90ルール」（最初の9割のコードが開発時間の9割を消費し、残り1割がさらに9割の時間を消費する）が、AI時代にはより顕著になります。

AI時代の発注で情シスがやること

では、情シスはAI時代の発注で何を変えるべきか。Beekleが推奨するのは、上流（要件定義）への投資をむしろ厚くすることです。

1. ユーザーシナリオで「なぜ」を握る

AI時代でも変わらないのは「人間がシステムをどう使うか」です。生成AIは画面の絵やコードは書けますが、「現場の誰が・どんな状況で・なぜそれを使うのか」のユーザーシナリオは人間が決める必要があります。

ユーザーストーリー（As a〜／I want to〜／So that〜の3要素）で「誰が・何を・なぜ」を握ることで、AIが書いたコードのレビュー基準が明確になります。詳しい書き方はユーザーストーリー書き方完全ガイド、たたき台作りには無料のユーザーストーリー作成ツールを使えます。

2. As-Is／To-Beを精緻に可視化する

業務フローの可視化は、AI時代でも人間がやる工程です。As-Isの正確性が低いと、AIが速く書いたコードも結局現場では使えません。スイムレーン図で業務フローを描き、関係者で照合する作業に時間をかけます。業務フロー可視化ツールで素早く描けます。

3. FM法でスコープクリープを止める

AIで開発が速くなると、「ついでにこれも作ろう」が起きやすくなります。コード生成のコストが安く感じられるため、機能を盛り込むハードルが下がるのです。これがスコープクリープの引き金になり、AI時代こそFM法での絞り込みが重要です。

FM法の3軸（ビジネス価値・現場で使えるか・技術コスト）で要件を「作る／後回し／作らない」に振り分け、最初のリリースには「作る」だけを含めます。詳しくはスコープ管理「FM法」の使い方、無料で試せるのはスコープ管理ツールです。

4. エンジニアリング視点でBPOを見て費用対効果から逆算する

これがBeekleが特に重視している点です。AI時代に発注の判断ミスを防ぐには、エンジニアリングの知識を持つ人が業務プロセス（BPO）を見て、システム化したときの実装コストと業務効果から逆算する必要があります。

業務改善コンサルだけだと、AIで速く書けるコストの新しい現実が読めず、「やらないほうが良い業務改善」をシステム化するToBeを描いてしまいます。エンジニアだけだと、業務の意味が読めず、「動くが使われない」AIシステムを作ります。両方の視点を持つ人が、案件の入り口でBPOと費用対効果を見て、ToBeを再設計するのがAI時代の要件定義の核心です。

「AIで速く動くもの」を見せる進め方の落とし穴

AI時代によく聞く進め方として「とりあえずAIで動くものを作ってから、見ながら要件を決めよう」というアプローチがあります。これは部分的に正しいですが、運用の仕方を誤るとリスクになります。

正しい使い方: 認識合わせの手段としてのプロトタイプ

動くプロトタイプは、関係者の認識合わせに有効です。「言葉で説明されてもイメージできない」を解決するために、AIで素早く画面のたたき台を作って触ってもらうのは、要件定義の精度を上げる手段として優れています。

誤った使い方: 要件定義を放棄してAIに委ねる

一方、「AIが何でも作れるから、要件定義は省略してプロトタイプから始めよう」というアプローチは危険です。これは「使われないシステムを高速で量産する」確実な方法になります。AIが速く書ける時代だからこそ、何を作るかの判断は人間（情シス・経営層）が責任を持って行う必要があります。

Beekleが推奨する4ステップ

Beekleでは、AI時代のプロトタイプ開発を次の4ステップで進めることを推奨しています。

1. ユーザーストーリーで「誰が・何を・なぜ」を1行に揃える（画面の絵を描くより先に動機を握る）
2. FM法で「何を作る／作らない」を3軸（ビジネス価値・現場で使えるか・技術コスト）で決める
3. 残った要件をGherkin（Given／When／Then）に変換してデモ＝テストの種にする
4. 生成AI＋フルスタックフレームワークでプロトタイプを実装する

このパイプラインに乗せている限り、AIの「最初の8割を高速に書く」能力をそのまま活かせます。逆に1〜3を省略すると、速く書いた分だけ使われない機能が量産されます。詳しい4ステップは生成AIで1〜2週間プロトタイプを作る4ステップを、生成AI開発全体の進め方は生成AI開発の進め方を参照してください。

情シスの新しい役割｜「コード書き手」より「業務とエンジニアリングの翻訳者」

AI時代の情シスの役割は、「コードを書ける人を雇う／育てる」よりも、「業務を理解して要件を整理し、AI生成コードのレビューができる人を確保する」方向にシフトします。

情シスが磨くべき3つのスキル

• 業務理解: 現場の業務プロセス・例外運用・暗黙ルールを把握する力。BPO見直し・As-Is可視化の主導
• 要件レビュー: ベンダー提案やAI生成コードに対して「業務目的に合っているか」「例外時の挙動が抜けていないか」を判定する力
• 費用対効果の判断: システム化コストと業務効果を読み合わせて「作る／作らない」を決める力。エンジニアと協働しながら経営層に説明する

外部パートナー（受託開発会社）との協働の仕方

情シス1〜3名の中堅企業が、これらすべてを社内だけで完結するのは現実的ではありません。Beekleのような受託開発会社と協働する場合、AI時代では「コードを書いてもらう」だけでなく「BPO見直しから要件定義の精度を上げる工程を一緒にやる」ことを依頼するのが、効果的な使い方です。

具体的には、(1) 業務フロー可視化のワークショップに参加してもらう、(2) ToBe案を一緒にレビューしてもらう、(3) FM法でのスコープ判定に費用対効果の試算を入れてもらう、(4) プロトタイプで早期に認識を合わせる、という協働パターンです。Beekleではプロトタイプ無料体験（ゼロスタート）でこの協働の入り口を提供しています。

まとめ｜AI時代こそ要件定義の重要度が上がる

本記事の主張をまとめます。

• 「AIで速くなるなら要件定義は短くていい」は逆。AIで速く書ける分、間違った要件で間違ったシステムが速く出来上がるリスクが高まる
• 従来は上流の認識ズレを下流で吸収できたが、AI時代はそれが間に合わない
• 情シスがやることは上流投資を厚くすること: ユーザーシナリオ／As-Is／FM法／費用対効果
• エンジニアリング視点でBPOを見て費用対効果から逆算するのが、AI時代の発注の核心
• プロトタイプは認識合わせの手段。要件定義を放棄してAIに委ねるのは「使われないシステムを量産する確実な方法」
• Beekle推奨の4ステップ: ユーザーストーリー → FM法 → Gherkin → 実装
• 情シスの新しい役割: コード書き手より「業務とエンジニアリングの翻訳者」
• 外部パートナーとは「コード書き」より「要件定義精度を上げる工程の協働」を依頼するのがAI時代の使い方

情シス向けDXシリーズはここで一旦完結です。BPO見直し → As-Is可視化 → ユーザーシナリオ → ToBe再設計 → FM法でスコープ確定 → AI時代の要件定義、という一連の流れで、情シスがDX案件をコントロールできる状態を目指します。