FDE（Forward Deployed Engineer）が着任した初日、会議室で要件定義の資料を開くことはありません。やるのは、現場の人の隣に座り、毎朝開いている画面と毎月印刷している帳票を見せてもらうこと。ハブ記事「今さら聞けない『FDE』とは？」では、FDE を「顧客の業務の中に入り、動くものを先に出し、判断を顧客と一緒に決め、本番まで持っていく」職種として整理しました。この記事はその続きで、「では初日から5日目まで、具体的に何をするのか」を書きます。
読者として想定しているのは2種類の方です。ひとつは FDE を受け入れる側の経営者・管理部門・情シスの方で、「1週間で何が出てくるのか」「自社は何を用意すればよいのか」が分かるように書いた。もうひとつは FDE として働きたいエンジニアやコンサル出身の方で、着任1週間の手順・ヒアリングの問い・Echo 役（社内で業務と仕組みを引き継ぐ担当）の選び方を、そのまま使える粒度で置いています。当社が経理の AX、kintone、案件管理システムの刷新、Claude の導入で本番稼働まで伴走してきた経験を、一般化して書いています。
着任1週間の目的は「何を作るか」を決めることではなく、「誰が何を毎日触り、どこで人の判断が挟まり、そのデータを誰が直せるか」を把握すること。Day1 で画面・帳票・データを棚卸しし、Day2 で業務を入力→判断→出力に分解し、Day3 でデータの持ち主と権限を確かめ、Day4 で動くモックを見せて「作らない」候補を出し、Day5 で Echo 役と日次15分・週次報告の型を決める。要件は情シス経由でまとめず、部署ごとに現場へ聞く。
この記事の要約
着任1週間で決めるのは「何を作るか」ではない
受託開発なら、最初の1週間は要件定義に使います。FDE は違う。最初の1週間で決めるのは「何を作るか」ではなく、「この会社の業務はどこで人の判断に依存していて、そのデータを誰が直せて、誰が判断を上に通せるか」です。作るものはその後、動くものを見せながら決めていきます。
理由は単純で、着任直後に聞き取った要件は、ほぼ必ず後で変わるからです。The Pragmatic Engineer が紹介する OpenAI の FDE の進め方でも、最初の見立て（スコーピング）の段階は「数日間、顧客先でユーザーの隣に座り、業務の流れを図にし、価値の大きい領域を見つける」ことに使われています。要件書をもらって帰るのではなく、業務そのものを見に行く。それが1週目です。
当社が入った案件でも、この順番を崩したときに失敗しています。設備投資型の事業を営む中堅企業（従業員100〜300人）で案件管理システムを刷新したとき、最初に手にしたのは、情シス経由でまとまった要件書でした。ところが8つの部署に直接入って帳票を棚卸しすると、要件に書かれていない帳票が部署ごとに数枚から十数枚あり、しかもそれが日々の判断に使われていました。1週目にこの棚卸しをしていなければ、要件どおりに作って現場で使われない、という結末になっていたはずです。
Day1 業務の入口に立つ——画面・帳票・データの棚卸し
初日は「誰が、何を、毎日触っているか」を目で見る日です。会議室でのキックオフは30分で切り上げ、残りの時間は現場に行きます。見せてもらうのは3つ。毎朝開いている画面、毎週・毎月印刷や送付をしている帳票、そして Excel や共有フォルダに置かれている「正式ではないが業務に必要なファイル」です。3つ目がいちばん大事で、たいてい情シスの台帳には載っていません。
| 内容 | |
|---|---|
| FDE がやること | 現場に座り、朝礼から午前中の作業を見る。開いた画面と印刷した帳票をすべて写真かスクリーンショットに残す。「この帳票は誰がいつ見るか」を1枚ずつ聞く。共有フォルダと個人の Excel の場所を聞き出す |
| 顧客側にお願いすること | 各部署に「1日つきっきりで見せてもらう相手」を1人ずつ指名しておく。画面のログイン ID（閲覧権限でよい）を初日までに発行する。帳票の現物を、直近1か月分そのまま出す |
| その日の終わりに手元にあるもの | 画面・帳票・ファイルの一覧表（名称、誰が、いつ、何のために、どこにあるか）。写真つき。件数は部署あたり数十点になることが多い |
初日に「業務フロー図を書いてください」とは頼みません。フロー図は書く人の理解でできあがるので、書いた人が知らない例外処理が抜けます。代わりに集めるのは現物。帳票の現物には、手書きの修正、蛍光ペンの印、付箋が付いています。その印こそが「システムが対応できていない判断」の跡で、翌日の業務分解の材料になります。
先ほどの案件管理システムの案件では、初日から数日かけて8つの部署を回り、帳票を棚卸ししました。数え上げると部署あたり十数点から数十点、合計で100点前後。そのうち「情シスが把握していたもの」は半分に届きません。半分以上は、現場が自分の判断のために Excel で作り足したものでした。
Day2 業務分解——「入力→判断→出力」に分け、人に依存する判断に印を付ける
2日目は、初日に集めた帳票と画面を、ひとつの業務ごとに「入力→判断→出力」の単位に分けます。入力は「何が届くか」（注文、申請、メール、電話）。判断は「届いたものをどう扱うか決める」（承認する、差し戻す、金額を確認する、担当を割り振る）。出力は「決めた結果をどこへ出すか」（システムに登録する、帳票を印刷する、次の部署に回す）です。
分解したら、判断の箱ひとつひとつに「その判断は、何を見て、誰がしているか」を書き込みます。ここで印を付けたいのは、「ルールが文書になっておらず、特定の人の経験で決まっている判断」です。「この金額なら課長に回す」「この取引先は前回トラブルがあったから先に電話する」。こうした判断は、システムにもマニュアルにも載っていません。その人が休んだ日に業務が止まる箇所でもあります。
| 内容 | |
|---|---|
| FDE がやること | 初日の一覧表をもとに、業務を1つずつ入力→判断→出力に分ける。判断ごとに「何を見て決めるか」「誰が決めるか」「決め方は文書化されているか」を聞く。人に依存している判断に印を付け、その人の名前ではなく役割で記録する |
| 顧客側にお願いすること | 印が付いた判断について、「その判断を実際にしている人」に30分ずつ時間をもらう。管理職ではなく、実際に手を動かしている担当者を出す |
| その日の終わりに手元にあるもの | 業務分解表（業務ごとに入力・判断・出力の3列、判断には依存度の印）。印の数は業務あたり数個から十数個 |
印の付いた判断は、そのまま「AI や仕組みで肩代わりする候補」になります。ただし、全部を自動化する前提で見ないでください。「この判断は人が残すべきか、仕組みに移せるか」を決めるのは4日目以降で、しかも決めるのは FDE ではなく顧客側です。2日目の仕事は、判断の場所を可視化するところまでです。
PoC で止まる会社と動かせた会社の分かれ目で書いたとおり、AI 導入が止まる会社は「どの判断を任せるか」が曖昧なまま作り始めています。業務分解表は、その曖昧さを取り除くための道具です。
Day3 データの持ち主と権限——マスタは誰が直すか、外に見せるのはどこまでか
3日目は、2日目の業務分解表に出てきたデータについて、「持ち主」を確かめます。ここでいう持ち主は、データを閲覧している人ではなく、間違っていたときに直す権限と責任を持つ人です。取引先マスタ、商品マスタ、担当者マスタ、単価表。どれも「誰でも見られるが、誰が直すのかは決まっていない」状態になっていることが多く、それが二重登録や古い単価の残存を生みます。
もうひとつ確かめるのが、「外に見せる情報はどこまでか」です。仕組みができると、これまで部署の中に閉じていた情報が、別の部署や取引先、あるいは AI の処理に流れます。原価、粗利、個人の評価、取引先ごとの値引き。これらを誰に見せてよいかは、FDE が決められることではありません。3日目のうちに論点として挙げ、先方の判断を仰ぎます。
| 内容 | |
|---|---|
| FDE がやること | 業務分解表に出てきたデータ（マスタ・トランザクション・添付ファイル）を一覧にし、それぞれ「誰が閲覧」「誰が更新」「誰が承認」「外部（取引先・AI 処理）に出してよいか」を聞く。決まっていない項目は「未決」と正直に書く |
| 顧客側にお願いすること | マスタごとに「直す権限を持つ人」を1人決める（兼務可）。原価・粗利・個人情報など「見せる範囲を経営判断で決める情報」を洗い出し、判断者を決めておく。既存システムの権限設定画面を見せる |
| その日の終わりに手元にあるもの | データ一覧と権限表（データ × 閲覧・更新・承認・外部提供の4列）。未決の項目には担当者と期限を付ける |
当社が案件管理システムの刷新で入った中堅企業では、この権限設計を先方と一緒に決めるのに、初回の話し合いだけで数時間かかりました。「営業は他部署の案件の粗利を見てよいか」「協力会社に進捗画面を開放するか」といった論点は、情シスにも FDE にも決められない。3日目にこれを一覧にして経営側に持ち込めたことで、後工程で「その画面は見せられない」と作り直す事態を避けられました。
権限の論点は、AI を使う場合にはさらに増えます。AI に読ませるデータの範囲、AI が出力した結果を誰が確認するか、外部の AI サービスに送ってよいデータの線引き。これらも3日目の権限表に列を足して扱います。
Day4 最初に動くものを見せて、直す。「作らない・捨てる」候補を出す
4日目に、動くものを見せます。3日分の材料があれば、ひとつの業務の入力から出力までを通した画面（モック）は作れます。完成度は問わない。実データの一部を入れ、初日に見た帳票と同じ形で出力が出れば十分です。見せる相手は、決裁者ではなく、その業務を毎日やっている担当者です。
モックを見せる目的は、賛同を得ることではなく、直されることです。「この列はいらない」「この順番だと入力しづらい」「この帳票は実はもう誰も見ていない」。こうした反応は、要件定義の会議では出てこない。動くものを目の前にして初めて出る。当社の経験では、初回のモックに対する修正指摘は、業務ひとつで十数件から数十件出ます。少ないときは、見せた相手が実務者ではなかったか、モックが実業務から離れているかのどちらかです。
| 内容 | |
|---|---|
| FDE がやること | 業務分解表から1つ選び、入力から出力までを通したモックを作る。実データの一部を使う。担当者の隣で操作してもらい、指摘をその場で直す。「もう誰も見ていない帳票」「二重に入力しているデータ」を作らない・捨てる候補として書き出す |
| 顧客側にお願いすること | 実務担当者に1時間、モックを操作する時間をもらう。「遠慮せず直してよい」と上長から一言添えてもらう。捨てる候補の帳票について、本当に誰も見ていないかを確認する |
| その日の終わりに手元にあるもの | 修正済みのモック（1業務分）。修正指摘の一覧。「作らない・捨てる」候補一覧（帳票・入力項目・承認段階） |
「作らない・捨てる」候補を出すのは、4日目の大事な仕事です。刷新のたびに帳票が増える会社は多く、旧システムの帳票を全部新システムに移すと、使われないものを作る工数が半分近くを占めることがあります。棚卸しの時点で「誰が見るか」を1枚ずつ聞いてあれば、「見る人がいない」帳票は候補に挙げられる。最終的に捨てるかどうかを決めるのは顧客側ですが、候補を出すのは FDE の役目です。
Day5 Echo 役を決め、日次15分と週次報告の型を作る
5日目は、翌週以降の進め方を固めます。決めるのは3つ。社内で業務と仕組みを引き継ぐ Echo 役、毎日15分の確認の場、週1回の報告の型です。加えて、4日間で出てきた「先方に決めてもらわないと進まない論点」を一覧にして、判断者と期限を付けて渡します。
| 内容 | |
|---|---|
| FDE がやること | Echo 役の候補を挙げ、経営側と合意する。日次15分の場（誰が出るか、何を確認するか）と週次報告の型（進捗・決まったこと・未決の論点・翌週の予定）を決める。4日間で出た論点を一覧にし、判断者・期限を付ける |
| 顧客側にお願いすること | Echo 役の任命を、本人と上長の両方に伝える。日次15分の枠を Echo 役の予定に入れる。論点一覧の判断者を確定し、最初の判断日を決める |
| その日の終わりに手元にあるもの | Echo 役の任命（名前・役割・稼働の目安）。日次15分・週次報告の型。論点一覧（論点・判断者・期限・決まった場合の影響）。1週目の成果物一式（棚卸し表・業務分解表・権限表・モック・作らない候補） |
日次15分は、FDE と Echo 役が「今日直したこと」「明日見せるもの」「決めてほしいこと」だけを確認する場です。会議ではないので資料は作らない。週次報告は、経営側と情シスに向けて、決まったこと・未決の論点・翌週の予定を1枚にまとめます。この2つの型があると、FDE が本社に戻っている日や、案件の後半で FDE が抜けた後も、Echo 役が同じ型で回せます。
論点一覧は、1週目でいちばん経営側に読んでほしい成果物です。「営業に他部署の粗利を見せるか」「承認段階を3つから2つに減らすか」「この帳票を廃止するか」。決めるのに技術は要りません。要るのは、業務の責任者の判断だ。この一覧が空のまま2週目に入ると、FDE は判断を推測して作ることになり、後で作り直します。
Echo 役とは誰か——業務を知っていて、判断を上に通せる人
Echo という呼び名は、FDE を生んだ Palantir の社内用語です。同社の公式ブログ（2022年3月）によれば、Echo は Deployment Strategist（デプロイメント・ストラテジスト）の社内呼称で、FDE（社内では Delta）と組んで案件に入る。理屈の上では Echo が製品責任者寄り、Delta が技術寄りとされていますが、同社自身が「実際には両者の線引きは頻繁に曖昧になる」と書いています。Echo の仕事として挙げられているのは、顧客の業務を理解して効果の大きい箇所を見つけること、ユーザーと素早く繰り返して解決策を合わせること、顧客との関係と案件の進行を管理することです。
当社では、この役を顧客側に置いてもらいます。Palantir では自社の社員が Echo を務めますが、中堅企業の AI 導入で仕組みが定着するかどうかは、FDE が帰った後に社内で誰が回すかで決まる。だから Echo 役は顧客の社員で、次の3つを満たす人です。その業務を実際に知っている。判断を上に通せる、つまり経営側や部門長に「これを決めてください」と言える立場か関係がある。週の一定時間を確保できる。
情シスとは限りません。むしろ、情シスが Echo 役になると、業務の判断で詰まることが多い。「この承認段階を減らしてよいか」は情シスには決められないからです。案件管理システムの刷新では、Echo 役は業務側の管理職が務め、情シスはデータと権限の実装で並走する形。経理 AX の案件なら経理課長、営業支援なら営業企画の担当者、というように、業務側から選びます。
Echo 役を選ぶときに避けたいのは、「いちばん忙しい人」と「いちばん詳しいが権限のない人」です。前者は日次15分に出られない。後者は論点を上に通せず、判断が止まります。理想は「業務に詳しく、週に数時間を確保でき、部門長に直接話せる人」で、いなければ「詳しい担当者」と「判断を通せる管理職」の2人組にする。ハブ記事で「先に決めるべきは Echo 役」と書いたのは、この人がいないと FDE の技術が生きないからです。
なぜ情シス経由ではなく、部署ごとに聞くのか
要件は情シスがまとめて渡してくれる。それでよいのではないか。受け入れ側からよく受ける質問だ。答えは「情シスの要件は必要だが、それだけでは足りない」です。情シスがまとめる要件は、システムに載っているものが中心。現場が Excel で作り足した帳票、手書きで直している項目、電話で済ませている確認は、情シスの視界に入りません。
典型的なずれを3つ挙げます。1つ目は「帳票の数」で、情シスの台帳にある帳票の数と、現場が実際に使っている帳票の数は、当社の経験では後者が2倍前後になる。2つ目は「入力の順番」で、システムの画面順と現場が実際に入力する順番が違い、現場は Excel に一度まとめてから転記しています。3つ目は「判断の場所」で、システム上は自動で進む処理が、実際にはその前に担当者が目視で止めている。どれも、情シスの要件書には「問題なし」と書かれる箇所です。
部署ごとに聞く理由はもうひとつあります。部署間で同じデータを別の名前で呼んでいる、あるいは同じ名前で別のものを指している例が、必ず見つかるからです。「案件」が営業では見積段階から、管理部門では受注後からを指す、といった違いだ。これを1週目に見つけておかないと、モックを見せた段階で部署ごとに反応が割れます。
情シスを飛ばすという意味ではない。情シスには、初日に画面のログイン ID を用意してもらい、3日目に権限設定を一緒に見てもらい、5日目の週次報告の宛先に入ってもらいます。現場の聞き取りに情シスの担当者が同席してくれると、「それはシステムで対応できる」「それは既にある機能で解決する」という判断がその場で出るので、むしろ同席を勧めます。
ヒアリングの問い——現場で使う10問
Day1 から Day3 の聞き取りで、当社が実際に使っている問いを表にします。どれも「業務を説明してください」のような大きな問いではなく、帳票や画面を指さしながら聞ける小さな問いです。大きな問いは、説明する側の理解でまとめられてしまい、例外が抜ける。
| No. | 問い | 何を知るための問いか | 主に使う日 |
|---|---|---|---|
| 1 | この帳票は、誰が、いつ、何のために見ますか | 帳票の要不要。「見る人がいない」帳票の発見 | Day1 |
| 2 | この画面を開かない日はありますか。開かない日は何をしていますか | 画面の実利用頻度。画面外で回っている業務 | Day1 |
| 3 | この Excel は誰が作りましたか。作った人が休んだら誰が更新しますか | 個人依存のファイル。属人化の場所 | Day1 |
| 4 | この列が空欄のとき、誰がどうしますか | 例外処理と、人の判断が挟まる場所 | Day2 |
| 5 | この承認は、実際に差し戻されることがありますか。最近の差し戻しはいつ、なぜでしたか | 承認段階が機能しているか。形式だけの承認の発見 | Day2 |
| 6 | この判断を新人に任せるとしたら、何を教えますか | 文書化されていない判断ルールの言語化 | Day2 |
| 7 | このマスタが間違っていたら、誰が直しますか。最後に直したのはいつですか | データの持ち主。更新されていないマスタの発見 | Day3 |
| 8 | この数字を、他の部署や取引先に見せてよいですか。見せてはいけないなら、誰がそう決めましたか | 外部提供の線引きと判断者 | Day3 |
| 9 | 同じ内容を、別の場所にも入力していますか | 二重入力。捨てる候補の発見 | Day1〜2 |
| 10 | この業務で、いちばん時間がかかっているのはどこですか。それは月に何回ありますか | 効果の大きい箇所。件数で優先順位を付ける材料 | Day1〜2 |
問い4「この列が空欄のとき、誰がどうしますか」は、当社がもっとも多くの発見を得ている問いです。空欄のときの扱いはシステムの仕様書に書かれていないことが多く、答えは「担当者に電話する」「とりあえず0を入れる」「上長に聞く」と人によって違います。この違いが、仕組みに移すときの設計論点そのものになる。
問い6「新人に任せるとしたら何を教えますか」は、判断ルールを引き出す問いです。「この判断はどうやっていますか」と聞くと「経験で」と返ってきますが、「新人に教えるなら」と聞くと、「まず金額を見て、次に取引先の過去の履歴を見て」と手順が出てきます。この手順が、AI や仕組みに移せる部分と、人が残す部分を分ける材料になる。
受け入れ側が着任前に用意しておくもの
1週目を上の流れで進めるために、受け入れ側には着任前に用意してほしいものがあります。多くはありません。各部署に「1日つきっきりで見せる相手」を1人ずつ指名すること。閲覧権限のログイン ID を初日までに出すこと。帳票の現物を直近1か月分そのまま出すこと。そして、Echo 役の候補を1〜2人考えておくことです。
逆に、用意しなくてよいものもあります。要件定義書、業務フロー図、RFP（提案依頼書）。あれば読みますが、なくても始められます。「まだ業務が整理できていないので、整理してから呼びます」という会社が多いのですが、整理は FDE の1週目の仕事です。整理されていない状態のほうが、現場の実態がそのまま見えるので、むしろ都合がよい。
AWS が2026年6月に FDE 専門組織を作ったときの発表では、顧客側のエンジニアが「見学者から共同開発者へ、そして自律的な運用者へ」と移っていくこと、顧客に残るものとして稼働する仕組みに加えて「手順書、構成の説明資料、社内で運用を引き継ぐ担当者」を挙げています。1週目に Echo 役を決め、日次15分の型を作るのは、この「見学者から運用者へ」の移行を初日から始めるためです。エンタープライズ AI 導入のスケール4段階でいえば、1週目のうちに2段目（試作）と3段目（業務化）をつなぐ人と場を決めておく、ということになる。
まとめ
FDE の着任1週間は、要件を固める期間ではなく、「誰が何を毎日触り、どこで人の判断が挟まり、そのデータを誰が直せて、誰が判断を上に通せるか」を把握する期間です。Day1 で画面・帳票・データを現物で棚卸しし、Day2 で業務を入力→判断→出力に分けて人に依存する判断に印を付け、Day3 でデータの持ち主と外に見せる範囲を確かめ、Day4 で動くモックを実務者に直してもらい「作らない・捨てる」候補を出し、Day5 で Echo 役と日次15分・週次報告の型、そして先方に決めてもらう論点の一覧を作ります。
受け入れ側が用意するものは、各部署に見せる相手を1人ずつ、閲覧用のログイン ID、帳票の現物、Echo 役の候補。要件定義書は要りません。要件は情シス経由でまとめず、部署ごとに現場に聞く。そして Echo 役は情シスとは限らず、業務を知っていて判断を上に通せる人から選ぶ。「AI 導入」の本当の難しさで書いたフロー管理の壁を越えるのは、この1週目の型と Echo 役です。
FDE として働くことに関心がある方へ
この記事の Day1〜Day5 の流れと10の問いは、当社の FDE が実際に使っているものです。求められるのは、コードを書く力と同じくらい、現場の帳票を1枚ずつ見て「この列が空欄のとき誰がどうするか」を聞き続けられる根気と、権限や承認の論点を経営側に持ち込める度胸。エンジニア出身の方も、コンサルや業務部門の出身で開発は AI と一緒に進めたいという方も、当社ではこの型で FDE として働く仲間を探しています。関心のある方は 採用のお問い合わせ からご連絡ください。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
着任1週間の棚卸しから、本番稼働まで伴走します
はてなベースの FDE 型支援は、この記事の Day1〜Day5 から始まります。画面・帳票・データの棚卸し、業務分解、権限設計の論点整理、動くモックでの確認、Echo 役の選定までを1週目で行い、その後は AI エージェントや kintone・案件管理システムを既存の業務フローに組み込んで本番稼働まで進めます。「まだ業務が整理できていない」「どの部署から始めるべきか分からない」段階からご相談いただけます。