日本FDE協会
ビジネススキル・顧客折衝

FDE要件定義で失敗しない実践テクニック

FDE要件定義で失敗しない実践テクニック

「要件定義書は作ったのに、できあがったものが現場で使われない」——こうした失敗は珍しくありません。私たち日本FDE協会は、FDE(Forward Deployed Engineer=顧客の現場に入り込んで技術とビジネスの両面から課題を解くエンジニア)の実践者が集まる団体です。この記事を読めば、FDE 要件定義の失敗パターンと、それを避けるために現場で実際にやっている実践テクニックがわかり、自分のプロジェクトにすぐ取り入れられるようになります。特定のツールや外注先へ誘導するのではなく、誰に頼むにせよ必要になる考え方をフラットにお伝えします。

FDE 要件定義でよくある失敗パターン

要件定義の失敗は、技術力の不足よりも「聞き方」と「進め方」に原因があることがほとんどです。まず典型的な3つのパターンを押さえておきましょう。

言われた要件をそのまま作ってしまう

顧客が口にする「こういう機能が欲しい」は、多くの場合すでに顧客なりの解決策です。その裏にある本当の課題を確認しないまま作ると、動くのに使われないシステムができあがります。前川会長がEコマース事業に転身した当初、技術はあってもマーケの知識が足りず、最初の半年は売上がほぼゼロでした。「いいものを作れば売れる」という思い込みを捨て、顧客ヒアリングを徹底してから伸びたという経験が、要件を鵜呑みにしない姿勢の裏付けになっています。

完璧な要件定義書を待ってしまう

すべての要件を紙の上で固めてから作り始めようとすると、認識のズレが最後まで見えません。FDEの現場では、まず動くものを最速で見せてフィードバックを得るアプローチを大切にしています。文字で合意した仕様より、実際に触れる画面のほうが誤解を早く潰せるからです。

FDEがやっている要件定義の実践テクニック

ここからは、実際にプロジェクトを回すなかで有効だった具体的なやり方を紹介します。

「それ、本当に必要ですか?」から始める

要件を減らすことも要件定義の仕事です。FDEに寄せられる反応で多いのが、「最初に『それ、本当に必要ですか?』と言われたのが衝撃だった。不要な開発を止めてくれた」という声です。作らない判断は、限られた工数を本当に効く部分へ振り向けるための選択です。提案はROI・コスト・工数で裏付ける、という数字で語る姿勢が、この線引きを冷静にします。

プロトタイプで合意を取る

製造業のクライアントの現場では、入出荷まわりの帳票を紙の仕様書で詰めるより、簡易な画面を1つ見せたほうが「ここは現場の運用と違う」という指摘が一気に出てきました。動くものを触ってもらうと、言語化されていなかった暗黙のルールが表面化します。プロトタイプは完成品ではなく、認識をそろえる道具だと捉えると気が楽になります。具体的な進め方は「FDEのプロトタイピング術」も参考にしてください。

課題の背景を引き出す聞き方

「うちの社員よりうちの業務に詳しくなっている」という反応をいただくことがあります。これは特別な才能ではなく、業務の流れを一つずつ確認し、なぜその手順なのかを掘り下げているだけです。ヒアリングの型は「FDEのヒアリング術」で詳しく整理しています。

見落とされがちな「統制・属人化」の要件

市場の一般的な要件定義の解説は、機能と業務フローで話を止めます。しかし本番導入で問われるのは、その先の領域です。

誰が何にアクセスできるかを最初に決める

要件定義の段階で、権限の設計と作業記録の残し方を織り込んでおかないと、後から作り直しになります。特に部門をまたぐシステムでは、既存の権限の仕組みを崩さない配慮が信頼につながります。SaaS企業の経営者と話すと、機能は作れても、この監査に耐える設計まで見られる人材が足りないという声をいただくことがあります。

担当者が変わっても回る形にする

要件定義書は作った本人だけがわかる状態になりがちです。スタートアップでの経験から言うと、立ち上げ期に属人化した仕組みは、人が増えた瞬間に引き継ぎで詰まります。誰が読んでも判断できるドキュメントとして残すことも、要件定義に含めるべき仕事です。この統制と属人化防止の視点を要件定義に組み込めるかどうかが、FDEの実力の分かれ目だと私たちは考えています。要件定義の基本の型は「要件定義で失敗しない|FDEがやっている5つのこと」にまとめています。

よくあるご質問

Q. 要件定義書を先に完璧に作るべきではないのですか?

A. 完璧を目指すより、動くものを早く見せて認識のズレを潰すほうが確実です。仕様書は合意の記録として残しつつ、プロトタイプで検証しながら固めていく進め方をおすすめします。

Q. 統制や権限の要件は、あとから足せばよいのでは?

A. 後付けは作り直しにつながりやすい領域です。誰が何にアクセスでき、作業記録をどう残すかは、機能設計と同じタイミングで要件に含めておくと手戻りが減ります。

Q. 社内にFDE的な人材がいない場合はどうすればよいですか?

A. 育成と外部活用の両方があります。既存メンバーの学習の目標としてFDE検定を活用する方法もありますし、プロジェクト単位での支援や法人研修のご相談も承っています。

FDE的な要件定義を自社に取り入れたい方へ。ご相談はお気軽に

法人研修・お問い合わせはこちら →

コミュニティに参加する →

日本FDE協会

FDE(Forward Deployed Engineer)の認知拡大・人材育成・コミュニティ形成を目的とした協会です。技術とビジネスの双方を現場で実践するエンジニアを支援しています。

お問い合わせ →