実装エンジニアがFDEになるには、新しい技術を学ぶよりも、仕様が決まる前の工程を順番に経験していくことが近道です。具体的には「業務を読む → 聞く → 課題を整理する → あるべき姿を描く → 決める」の順に、今の仕事の中で小さく試していきます。この記事では、その順番と理由、今の現場でできること、つまずきやすい点を説明します。
実装エンジニアに足りないのは「仕様の手前」の経験
実装を数年続けてきたエンジニアは、設計の判断、既存コードを読む力、不具合の原因を追う力をすでに持っています。FDEの仕事のうち「作る」部分は、ほぼそのまま通用します。
足りないのは、多くの場合次の経験です。
- 現場の業務がどう流れているかを、自分の目と耳で把握した経験
- 顧客の話から課題を見つけ、優先順位をつけた経験
- 作る範囲を顧客と交渉し、合意した経験
これらは研修で知識として学ぶことはできても、実際にやってみないと身につきにくいものです。ただし、いきなり上流工程の案件を任される必要はありません。今の仕事の中に、練習できる場面がいくつもあります。FDEの仕事の全体像はFDEとは？で説明しています。
身につける順番は「読む・聞く・整理する・描く・決める」
上流のスキルには、身につける順番があります。前の工程ができていないと、次の工程がうまくいかないからです。
| 順番 | スキル | できるようになること | 関連するガイド |
|---|---|---|---|
| 1 | 業務を読む | 業務フローを図にし、データから業務を推測できる | ASIS業務フロー、データから業務を予想 |
| 2 | 聞く | 仮説を持ってヒアリングし、現状・あるべき姿・差分をそろえられる | プロジェクトスタート時のヒアリング |
| 3 | 整理する | 課題を根本原因まで分解できる | イシューツリー、仮説思考 |
| 4 | 描く | 課題が解消された後の業務フローを描ける | TOBE業務フロー設計 |
| 5 | 決める | 要件と見積もりを顧客と合意できる | 現場導入のための要件定義、見積もりのやり方 |
最初に「業務を読む」を置いているのには理由があります。業務の流れがわからないまま顧客の話を聞くと、何を聞けばよいかがわからず、相手の話をメモするだけで終わってしまうからです。逆に、事前に業務フローの仮説を持って行けば、「この確認作業は誰がやっていますか」「この帳票はどこに回りますか」と具体的に聞けます。
今の現場でできる練習
上流の案件に入る前でも、今担当している仕事の中で各ステップを練習できます。
ステップ1の練習：担当機能の業務フローを書く
自分が実装している機能について、その機能が使われる業務の流れを図にしてみます。たとえば在庫管理システムの入荷登録画面を担当しているなら、次の流れを書きます。
- 仕入先から商品が届く
- 倉庫担当が納品書と現物を照合する（検品）
- 数量が合えば入荷登録、合わなければ仕入先に連絡
- 入荷登録された数量が在庫に反映される
- 経理が月末に仕入額を締める
書いてみると、「数量が合わないとき、登録はどうしているのか」「経理は入荷登録のデータをどう使っているのか」など、わからない点が出てきます。この「わからない点」が、次のステップで聞くべき質問になります。
ステップ2の練習：仕様の背景を一つ聞く
仕様の確認をするときに、ついでに一つだけ背景を聞いてみます。「この項目を必須にするのは、後工程で何に使うからですか」のような質問です。答えが返ってくると、業務フローの図がより正確になります。毎回一つずつでも続けると、仕様を出す側が何を考えているかが見えてきます。
ステップ3の練習：不具合や要望の「本当の原因」を考える
障害対応や改修要望が来たとき、直す前に「なぜこれが起きたのか」を一段深く考えます。たとえば「請求書の金額がずれる」という不具合でも、原因がプログラムなのか、締め日の運用ルールが部署ごとに違うことなのかで、打つべき手が変わります。課題を原因まで分解する練習になります。
ステップ4・5の練習：小さな改善を自分から提案する
日々の作業の中で見つけた小さな改善（手作業の確認を一つ減らす、入力項目の順番を業務の流れに合わせる、など）を、改善前と改善後の流れを並べて提案してみます。提案が通るかどうかより、「今の流れ」「変えた後の流れ」「そのために作るもの」を一枚にまとめる経験が大切です。
つまずきやすい点
実装エンジニアが上流に踏み出すときに、よくあるつまずき方を挙げておきます。
- 解決策から考えてしまう：話を聞きながら「こう作ればいい」と頭の中で設計を始めてしまい、現状の把握が浅くなる。まずは現状を図にすることを優先する
- 顧客の言葉をそのまま要件にしてしまう：「ボタンを一つ増やしてほしい」という要望の裏に、別の課題があることは多い。要望を聞いたら、その目的を一度確かめる
- 全部を作ろうとしてしまう：出てきた課題をすべて解決しようとすると、範囲が広がって期限に間に合わない。優先順位をつけ、今回作らないものを決めることも仕事のうち
- 作った後の確認を開発側だけで済ませる：テストが通っても、業務上正しいとは限らない。現場の担当者と一緒に、実際の業務データで動作を確かめる
最後の点は動作確認の基本で、業務上「ここが動けばよい」を判定する型として整理されています。
段階ごとの目安
経験の段階を、担当できる範囲で分けると次のようになります。FDE Guildでは、この段階を見習い・一人前・熟練・師範という呼び方で表しています。
| 段階 | 担当できる範囲 | 次に目指すこと |
|---|---|---|
| 見習い | 経験者の隣で、業務フローの作成やヒアリングの記録を担当する | 自分で仮説を持ってヒアリングする |
| 一人前 | 小規模な案件で、課題整理から実装までを一人で担当する | 要件と見積もりを顧客と合意する |
| 熟練 | 複数の部署にまたがる案件で、方針から定着までを担当する | 見習いを育てながら案件を進める |
| 師範 | 大きな案件を率い、他のメンバーの伴走もする | 型そのものを改善し、周りに広げる |
どの段階でも実装はし続けます。FDEのキャリアは実装から離れていく道ではなく、実装の前後に担当範囲を広げていく道です。
この記事のまとめ
- 実装エンジニアに足りないのは技術ではなく、仕様が決まる前の工程の経験
- 身につける順番は「読む・聞く・整理する・描く・決める」で、業務を読むことが出発点
- 担当機能の業務フローを書く、仕様の背景を一つ聞くなど、今の現場でも練習できる
- よくあるつまずきは、解決策から考える、要望をそのまま要件にする、全部作ろうとする、確認を開発側だけで済ませること
- FDEのキャリアは、実装の前後に担当範囲を広げていく道
身につける順番をそのまま7つのステップにしたものがFDEになるロードマップです。最初のステップ1「業務を読む」では、ASIS業務フローとデータからの業務予想を扱っているので、まずは担当している機能の業務フローを書くところから始めてみてください。