要件の言語化とは——曖昧な依頼を「AIで解ける形」に変換する能力
顧客企業から寄せられる依頼の多くは、「問い合わせ対応をAIで楽にしたい」「レポート作成をなんとなく自動化したい」といった曖昧な業務課題の形をしています。このままではAIはもちろん、人間のエンジニアでも手のつけようがありません。
要件の言語化とは、この曖昧な依頼を次の3点が定義された技術仕様に変換する能力です。
- 入力——何のデータが、どんな形式・頻度で入ってくるのか（例: 1日約200件の問い合わせメール、形式は自由文＋添付あり）
- 出力——何がどんな形で出れば業務が前に進むのか（例: 問い合わせ分類＋回答ドラフト＋担当部署の割り当て）
- 評価基準——どうなれば「成功」と判定するのか（例: 分類の一致率90%以上、担当者の修正時間が1件あたり5分未満）
特に重要なのが3つ目の評価基準です。LLMは仕様が曖昧でも「それらしい出力」を返してしまうため、成功条件が定義されていないと、できたものが使えるのかどうかを誰も判断できません。FDEとはで解説した「導入したのに使われない」問題の多くは、実装の失敗ではなく、この言語化の欠落から生まれています。
FDEの現場でどう使うか——ヒアリングから成功条件の合意まで
FDEの現場では、要件の言語化はおおむね次の流れで実践されます。
- ヒアリング——「効率化したい」の裏にある実際の困りごとを聞き出す。「その作業は誰が・いつ・何を見ながらやっていますか」と、行動レベルまで具体化する質問を重ねます
- 業務プロセスの分解——業務を工程に分け、それぞれの入力と出力を書き出す。この過程で、ベテランの頭の中にしかない判断基準（暗黙知）が大量に見つかります
- AIで解ける部分の特定——分解した工程のうち、LLMが得意な部分（分類・要約・ドラフト生成など）と、人間の判断を残すべき部分を切り分けます
- 成功条件の合意——「何がどうなれば導入成功か」を顧客と数字で合意する。これが後工程のPoC設計の土台になります
この仕事の性質は、国内でFDE組織を立ち上げたSansanの公式テックブログの定義がよく表しています。同社はFDEの役割を、顧客の業務や暗黙知を深く理解・言語化し「本当に解くべき課題は何か」を見極めることだと説明しています（出典: Sansan Tech Blog・2026年7月）。つまり要件の言語化は数あるスキルの一つではなく、FDEという職種の定義そのものに組み込まれた中核能力です。
具体例: 「問い合わせ対応を効率化したい」の言語化
たとえば「問い合わせ対応をAIで効率化したい」という依頼をヒアリングで分解すると、実際のボトルネックは「回答を書くこと」ではなく「過去の類似対応を探すのに1件20分かかること」だった——というケースは珍しくありません。この場合、作るべきものは自動回答ボットではなく過去対応の検索・要約システムであり、評価基準は「回答時間」ではなく「類似案件の検索時間」になります。言語化を省いて着手していたら、的外れなものを高品質に作ってしまうところです。
今どうやって身につけるか——現職でできる3つの訓練
要件の言語化は、FDEに転身する前から現職で鍛えられる数少ないスキルです。次の3つの訓練をおすすめします。
1. 自部署の業務を「入力→処理→出力」で記述する練習
自分やチームの定型業務を1つ選び、「何を受け取り（入力）、何を判断し（処理）、何を出すか（出力）」を文章で書き出してみてください。書いてみると「この判断、実は基準を説明できない」という箇所が必ず見つかります。それが暗黙知であり、AIに任せる際に言語化が必要になる部分です。週1業務からで構いません。
2. 議事録から「要求」と「要件」を分けて抽出する練習
会議の議事録を読み返し、発言を要求（〜したい・〜が困る）と要件（入出力や条件として定義できる記述）に仕分けます。ほとんどの発言は要求のままで、要件に落ちていないことに気づくはずです。「この要求を要件にするには何を質問すべきだったか」まで考えると、次のヒアリング設計の練習になります。
3. ドメインエキスパートへの質問設計
社内のベテラン（経理・法務・営業事務など）に「その判断はどうやってしていますか」と聞く機会を意図的に作り、相手が答えやすい質問の順番を設計してみてください。「例外はどんなときに起きますか」「新人がよく間違えるのはどこですか」といった質問は暗黙知を引き出しやすい定番です。この場数はFDEの選考でもそのままエピソードとして使えます。
言語化した要件は、実際にLLMを組み込んだ小さなプロトタイプで検証するところまでやると効果が跳ね上がります。作り方はポートフォリオの作り方、学習全体の計画は未経験からのロードマップを参照してください。
FDE Outlook: AIがコードを書く時代に、最後まで人間に残るスキル
今見えていること: コード生成の主役はすでにAIに移りつつあり、「仕様が明確ならAIが実装できる」領域は毎年広がっています。一方で、Sansanの採用情報が「コーディングスキルよりも業務経験やドメイン知識が価値を持つ」と明言しているように（SansanのFDE解説参照）、採用側の評価軸は実装力から課題を定義する力へ重心を移し始めています。
今後の見立て: 実装がコモディティ化するほど、ボトルネックは「何を作るべきかを定義する工程」に集中します。曖昧な業務課題を評価基準つきの仕様に変換する作業は、顧客の現場に入り込んで暗黙知を引き出す対人プロセスと不可分であり、AIによる代替が最も遅い領域だと当サイトは見ています。要件の言語化と対になる実行系スキル——検証を設計し本番移行まで持ち込む力——についてはPoC設計スキルで解説しています。あわせてお読みください。