要件定義で失敗しない｜FDEがやっている5つのこと
FDE要件定義のアプローチは、従来のウォーターフォール型とは根本的に異なります。「完璧な要件定義書を作ってから開発に入る」のではなく、「動くものを見せながら顧客と一緒に要件を定義していく」。私は日本FDE協会の会長として活動していますが、1億円規模のシステムプロジェクトで8名の開発チームと20名以上のステークホルダーの要件を整理した経験から確信しているのは、要件定義で最も危険なのは「完璧を目指して時間をかけること」だということです。
この記事では、FDEが現場で実践している5つの手法を解説します。読み終わるころには、顧客との認識ズレを防ぐ具体的なアプローチを実践できるようになるはずです。FDEに求められるスキルの全体像は「FDEに必要なスキル5選」で解説しています。
なぜ要件定義は失敗するのか
「完璧な要件定義書」という幻想
従来型の要件定義が失敗する最大の原因は、「要件定義を完璧にすれば開発は成功する」という前提そのものにあります。しかし現実には、顧客自身が何を作りたいか正確にわかっていないケースがほとんどです。言葉で書かれた要件定義書だけでは、顧客とエンジニアの頭の中のイメージは一致しません。
製造業のクライアントから「在庫管理システムを刷新したい」と依頼されたことがあります。要件定義書通りにシステムを作ることもできました。しかし現場を歩いてみると、本当の課題は在庫管理ではなく、倉庫と営業と経理が別々のデータを見ていることでした。要件定義書は「顧客が言ったこと」を正確に記録しますが、「顧客が本当に必要としていること」は書かれていません。
従来型とFDE型の決定的な違い
比較項目 | 従来型の要件定義 | FDE型の要件定義 |
|---|---|---|
出発点 | 顧客の「要望」をヒアリング | 顧客の「現場」を観察 |
成果物 | 要件定義書（文書） | 動くプロトタイプ |
認識合わせの方法 | レビュー会議で文書を確認 | 動くものを触って確認 |
変更への対応 | 変更管理プロセスを経由 | その場で修正して見せ直す |
リスク | 開発後半に「思っていたのと違う」が発覚 | 早期にズレを発見・修正 |
顧客の役割 | 要望を伝えて承認する | 一緒に定義する当事者 |
一言でまとめると、従来型は「書いてから作る」、FDE型は「作りながら決める」です。
FDEが要件定義で実践している5つのこと
1. 要件定義書を待たずに現場に入る
FDEの要件定義は、要件定義書を作るところから始まりません。まず顧客の現場に入り、担当者の隣に座って業務を観察するところから始まります。ある中小企業の現場では、経理担当者が毎朝2時間かけて3つのシステムからデータをExcelに手作業で転記していました。本人は「いつもの作業です」と言いますが、外から見れば明らかに自動化すべき工程です。この課題は、要件定義書のテンプレートをいくら埋めても出てきません。
2. プロトタイプで「顧客の本音」を引き出す
FDEは要件のすり合わせに文書ではなくプロトタイプを使います。動くものを見せると、顧客は「ここをこうしたい」「この機能は要らない」と具体的に話し始める。言葉だけの会議は空中戦になりがちですが、動くものの前では誰もが本音を話します。
SaaS企業のプロジェクトでは、午前中のヒアリングで課題を整理し、午後にはノーコードで簡易版を組んで見せたことがあります。「これ、明日から使えますか？」と聞かれた瞬間に、要件のうち80%はその場で固まりました。
3. 「それ、本当に必要ですか？」でスコープを絞る
1億円規模のシステムプロジェクトでPMを務めたとき、20名以上のステークホルダーからそれぞれ異なる要望が出てきました。全部を実装したら予算も期間も足りません。各部門に対して「もしこの機能がなかったら、業務が止まりますか？」と聞いて回りました。「止まる」と答えたものだけを必須要件として残した結果、開発スコープは当初の40%に絞り込め、利益目標180%を達成できました。要件を「足す」のではなく「引く」技術が、要件定義の成否を分けます。
4. 変更を前提にした設計にする
要件は変わるものだという前提で設計に入ります。最初から「変更が来ても影響範囲を最小にできる構造」を意識する。AIプロダクトの開発では、最初のプロトタイプは数十行のPythonスクリプトで作り、顧客のフィードバックを得てから本番コードをゼロから書き直すことが当たり前でした。最初のコードに固執するほうが、結果的にコストがかかります。
5. 要件定義の「完了」を顧客と一緒に宣言する
従来型では要件定義書に顧客のハンコをもらって「完了」としますが、FDE型ではプロトタイプを触ってもらい、「この方向で進めてよい」と口頭で合意を取ります。大事なのは文書の完成度ではなく、「顧客が本当に欲しいものの方向性」が合っているかどうかです。文書にハンコを押すより、動くものを触って「これでいい」と言ってもらうほうが、はるかに確実な合意です。
企業が要件定義で困ったときにFDEができること
「要件定義がうまくいかない」という相談は、SIerに発注した企業から最も多く寄せられるテーマの1つです。要件定義書を作ったのに開発が始まると認識ズレが発覚する、変更のたびにスコープと費用が膨らむ、そもそも要件を言語化できない——こうした課題に対して、FDEは顧客の現場に入り込み、「一緒に要件を見つけて一緒に定義する」アプローチで対応します。
スタートアップで組織をゼロから60名規模まで構築した経験からも、「完璧な計画を立ててから動く」より「小さく動いてフィードバックを得る」ほうが、結果的にスピードも品質も上がることを実感しています。要件定義も同じです。企業のFDE活用について詳しく知りたい方は「企業のFDE活用ガイド」もあわせてご覧ください。
よくあるご質問
Q. FDE型の要件定義はウォーターフォール型のプロジェクトでも使えますか？
A. 使えます。ウォーターフォールの要件定義フェーズ内でプロトタイプを使い、文書の精度を上げる方法が効果的です。「要件定義書＋動くプロトタイプ」のセットで合意形成すれば、後工程での手戻りリスクを大幅に減らせます。
Q. プロトタイプを見せたら「これで完成ですよね？」と誤解されませんか？
A. よくある懸念ですが、「これは方向性を確認するための試作品です」と事前に伝えるだけで解決します。むしろ粗い状態で見せることで「まだ変えられるんだ」と安心して意見を出してもらえます。
Q. 要件定義をFDEに依頼する場合の費用感は？
A. 課題の規模によりますが、現場観察からプロトタイプまでの要件定義フェーズは数週間〜1カ月、費用は数十万円〜数百万円が目安です。大規模なシステム開発に入る前に方向性を固められるため、トータルの開発費を抑える効果があります。
要件定義でお困りの方へ
「要件が固まらない」「SIerとの認識がズレる」——そんなお悩みに、FDE実践者がお答えします。要件定義フェーズへのFDE活用もご相談いただけます。
FDEに関心のあるエンジニアの方は コミュニティに参加する →
日本FDE協会
FDE（Forward Deployed Engineer）の認知拡大・人材育成・コミュニティ形成を目的とした協会です。技術とビジネスの双方を現場で実践するエンジニアを支援しています。