FDE（Forward Deployed Engineer）に必要なスキルは、大きく「顧客の業務を理解して課題を決める力」と「生成AIなどを使って小さく作り、現場で使われるところまで持っていく力」の二つに分かれます。この記事では、それを6つの領域に分けて具体的なスキルに落とし、自分がどこまでできているかを確かめられるチェックリストを用意しました。
FDEという働き方そのものについてはFDEとはの記事で説明しています。
FDEのスキルを6つの領域に分ける
FDEの仕事を流れで見ると、顧客の業務を読み、話を聞き、課題を整理し、あるべき姿を描き、作るものを決め、作って進める、という順番になります。それぞれの段階で必要なスキルを並べると、次の表になります。
| 領域 | 何ができればよいか | 主な成果物 |
|---|---|---|
| 1. 業務を読む | 資料やデータから顧客の業務の流れを推測できる | ASIS業務フロー、事業課題メモ |
| 2. 聞く | 現状・あるべき姿・課題の3つを聞き出してそろえられる | 課題一覧表 |
| 3. 課題を構造化する | 課題を分解し、どこから手をつけるか決められる | イシューツリー、検証計画 |
| 4. あるべき姿を描く | 課題が解けた後の業務を描き、顧客と合意できる | TOBE業務フロー、打ち合わせ資料 |
| 5. 要件と見積もり | 作る範囲と費用を決め、顧客が選べる状態にできる | 要件一覧、複数案の見積もり |
| 6. 作って進める | 状態とデータを設計し、試作し、確かめ、計画どおりに進める | 試作、確認記録、WBS・課題ログ |
実装経験のあるエンジニアは、6の「作る」部分をすでに持っています。FDEとして伸ばすのは、1〜5と、6のうち「確かめる」「進める」の部分です。
各領域で必要なスキル
1. 業務を読む
話を聞く前に、手元の情報から業務を推測する力です。
- 担当者ごとのレーンに作業を並べた業務フローを描ける
- 紙・電話・Excelなど、システム外のやり取りも図に入れられる
- CSVの列や件数の偏りから、「誰がいつ入力しているか」を推測できる
- 上場企業ならIR資料や中期経営計画から、事業の課題の仮説を立てられる
2. 聞く
顧客の話を、そのまま記録するのではなく整理して受け取る力です。
- 顧客の発言をASIS（現状）・TOBE（あるべき姿）・GAP（課題）に切り分けられる
- 「〜したい」には現状を、「〜で困っている」にはあるべき姿を聞き返せる
- 困りごとを、1回あたりの時間や月の回数といった数字で聞ける
- 1回で全部埋めず、分からない欄を残して次回に聞くことを整理できる
詳しくはヒアリングの記事にまとめています。
3. 課題を構造化する
集めた課題の大小や原因を見極める力です。
- 大きな課題を、重なりなく漏れなく分解できる
- 情報を集めきる前に仮説を立て、確かめ方を決められる
- 条件の組み合わせを表にして、例外や抜けを見つけられる
4. あるべき姿を描く
課題が解けた後の業務を、顧客が想像できる形にする力です。
- ASISと対比できる形でTOBE業務フローを描ける
- システムでやること、人がやること、やめることを分けて示せる
- 打ち合わせの前に、決めたいことと結論の案を1枚にまとめられる
5. 要件と見積もり
作るものを決め、顧客が納得して選べる状態を作る力です。
- 要件の一つひとつを、課題（GAP）に結びつけて説明できる
- 見積もりを明細に分け、金額の根拠を説明できる
- 範囲の違う複数の案を出し、「できること」の違いとして示せる
要件のまとめ方は要件定義の記事を参照してください。
6. 作って進める
決めたものを、現場で使われる形にする力です。
- 業務の状態（受付・確認中・完了・取消など）を整理し、テーブル設計に落とせる
- ルールで解くか、最適化か、生成AI・RAGかを、業務に合わせて選べる
- 正常・例外・境界値の確認項目を書き、顧客に渡す前に自分で試せる
- WBSと課題ログを作り、定例で進み具合と課題を報告できる
動作確認の進め方は動作確認入門の記事が参考になります。
セルフチェックリスト
各項目について、「できる（2点）」「やったことはある（1点）」「やったことがない（0点）」で採点してみてください。正確な点数よりも、どの領域が薄いかを知ることが目的です。
| 領域 | チェック項目 | 点数 |
|---|---|---|
| 業務を読む | 身近な業務を、担当ごとのレーンで業務フローに描いたことがある | |
| 業務を読む | CSVを見て、各列を誰がいつ入力しているか説明できる | |
| 業務を読む | IR資料を読んで、事業課題の仮説を3つ挙げたことがある | |
| 聞く | 顧客の発言をASIS・TOBE・GAPに分けてメモしたことがある | |
| 聞く | 困りごとを「1回何分、月何回」まで聞き出せる | |
| 聞く | 課題一覧表を作り、空欄を次回の宿題として管理したことがある | |
| 構造化 | 課題を3階層程度のイシューツリーに分解したことがある | |
| 構造化 | 仮説を先に置き、確かめるデータを決めてから調べたことがある | |
| 構造化 | 条件の組み合わせ表で、仕様の抜けを見つけたことがある | |
| あるべき姿 | ASISと対比したTOBE業務フローを描いたことがある | |
| あるべき姿 | 打ち合わせ資料の冒頭で「今日決めたいこと」を示したことがある | |
| 要件と見積もり | 要件を課題に結びつけて一覧にしたことがある | |
| 要件と見積もり | 明細つきの見積もりを作り、根拠を説明したことがある | |
| 要件と見積もり | 範囲の違う複数案を出し、顧客に選んでもらったことがある | |
| 作って進める | 業務の状態遷移を書き出し、テーブル設計に反映したことがある | |
| 作って進める | 生成AIを使う場面と使わない場面を理由つきで選んだことがある | |
| 作って進める | 確認項目を書いて、渡す前に自分で全部試したことがある | |
| 作って進める | WBSと課題ログを作り、定例で報告したことがある |
結果の読み方
- 領域ごとに合計点を出し、一番低い領域を次に伸ばす対象にします
- 「作って進める」だけが高い場合は、実装寄りの経験が中心という意味です。業務を読む・聞くから順に練習すると、上流の経験が積み上がりやすくなります
- 「聞く」「構造化」が高く「作って進める」が低い場合は、コンサル寄りの経験が中心です。状態設計と動作確認を補うと、FDEとして現場で作るところまで担えます
点数は人と比べるためのものではありません。3か月後にもう一度つけてみて、変化を見るのに使います。
領域とランクの目安
6つの領域は、一度に全部そろえる必要はありません。現場では、前半の領域から順に任される範囲が広がっていくのが普通です。目安を示すと次のようになります。
| 段階 | 一人で担える範囲 | 伴走があれば担える範囲 |
|---|---|---|
| 見習い | 業務を読む、聞く（記録と整理） | 課題の構造化 |
| 一人前 | 聞く、課題を構造化する、あるべき姿を描く | 要件と見積もり |
| 熟練 | 要件と見積もり、作って進める | 顧客との合意形成の主導 |
| 師範 | 1〜6を通して担い、他の人の成果物をレビューできる | 複数の案件や人の育成 |
この表は、ロードマップのステップとギルドのランクの関係を、スキルの面から見たものです。例えば「聞く」が2点、「構造化」が1点の人は、ヒアリングと課題一覧表は一人で担い、イシューツリーはレビューを受けながら作る、という関わり方から始めるのが現実的です。
チェックリストで点数が低い領域があっても、その領域の仕事ができないという意味ではありません。伴走があれば担える範囲として現場で経験を積み、次のチェックで点数が上がっていれば十分です。
スキルを伸ばすときの順番
6つの領域は、前の領域の成果物が次の領域の材料になる関係です。業務フローがないとヒアリングで何を聞くか決まらず、課題一覧表がないと要件の根拠が書けません。そのため、苦手な領域だけを単独で練習するより、1つの題材で1から順に成果物をつなげて作る方が身につきます。
例えば「社内の備品発注」を題材にするなら、次のように一続きで練習できます。
- 備品発注の業務フローを描く
- 発注担当に話を聞き、課題一覧表にまとめる
- 一番大きい課題を分解して原因の仮説を立てる
- 課題が解けた後の業務フローを描く
- 作るもの・作らないものを分け、範囲の違う案を作る
- 状態遷移を書き出し、小さな画面を作って確認項目を試す
この記事のまとめ
- FDEのスキルは、業務を読む・聞く・構造化・あるべき姿・要件と見積もり・作って進めるの6領域に分けられる
- 実装経験者が主に伸ばすのは1〜5と、6のうち「確かめる」「進める」の部分
- チェックリストは人と比べるためではなく、薄い領域を見つけて定期的に変化を見るために使う
- 各領域の成果物は次の領域の材料になるので、1つの題材で順につなげて練習すると身につきやすい
6つの領域は、FDEになるためのロードマップの7つのステップに対応しています。チェックで点数が低かった領域から、該当するステップを開いて練習を始めてみてください。