「FDE（Forward Deployed Engineer）に来てもらうとして、3か月で何がどこまで進むのか」。契約の前に経営者と情シス責任者から必ず聞かれる問いです。答えを週の単位で持っていないと、着任後の会話は「順調です」「もう少しです」の繰り返しになり、経営は本番投入の判断をいつ迫られるのか分からないまま四半期が終わります。FDE 型の支援が PoC（概念実証）と違うのは、本番で動いている仕組みと動かし方を残して帰る点にあり、それには「いつ何を決めるか」を先に置いた計画が要ります。
この記事は、FDE が着任してから90日、およそ13週間のうち、第2週から第13週までを週単位で書きます。第1週の業務分解・データ棚卸し・Echo 役の決め方は着任1週間の記事に書いたので、そちらに譲る。FDE という職種の定義と背景はハブ記事にまとめました。ここで答えるのは3つです。12週間を4つの区間に分けたとき、各週の終わりに何が見えているべきか。区間の切れ目にある3つの判断ポイントで、誰が何を材料に何を決めるか。そして、計画どおりに進まないときにどこを直すか。AWS の FDE 部門の発表、OpenAI と Anthropic の公式ガイド、IPA のアジャイル開発版モデル契約と DX 推進指標の分析レポートにある記述と、当社が経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験を一般化して書いています。
FDE の90日は、第2〜4週「本番データで動く試作」、第5〜8週「人が確定する並走運用」、第9〜11週「本番投入と旧手順の停止」、第12〜13週「引き継ぎ完了と次の90日の選定」の4区間に分ける。区間の切れ目が判断ポイントで、第4週末に「この業務で続けるか差し替えるか」、第8週末に「本番に入れるか」、第11週末に「旧手順をいつ止めるか」を、実測値を材料に経営が決める。第13週末の完了判定は「Echo 役だけで業務1サイクルを回せたか」。当社に来る相談では、遅れの原因は技術より判断待ちのほうが多い。計画を直すときは週を延ばす前に判断者と期限を直す。
この記事の要約
90日を4つの区間に分ける——各週の終わりに何が見えているか
13週間を均等に切らず、目的の違いで4つに分けます。第2〜4週は、第1週に選んだ業務1本について本番データで動く試作を現場に触ってもらう区間。第5〜8週は、仕組みが下書きを出し人が確定する形で実業務を並走させる区間。第9〜11週は本番に切り替えて旧手順を止める区間。第12〜13週は、FDE が手を離しても回ることを確かめ、次の90日で入る業務を決める区間です。
区間ごとに「終わりの判定」を1つだけ、実測値で置きます。区間 A はテストセットに対する合格率と誤りの重さの分布、区間 B は並走中の修正率と人が止めた件数の内訳、区間 C は旧手順の利用件数がゼロになった週があるか、区間 D は Echo 役だけで回した1サイクルでの FDE への質問件数。判定が複数あると、どれか1つが未達のまま次の区間に進み、後で全部が未達に戻りやすい。区間の切れ目が曖昧になるのは、判定が「概ねできた」という言葉で済まされたときです。
AWS は2026年6月30日の発表で、FDE 部門の狙いを「導入を数か月から数日に圧縮する」と書き、案件が進むにつれて顧客側のエンジニアが「観察者から共同開発者へ、そして自律的な運用者へ」移ると説明しています。この3段階は、4つの区間のうち A・B と D にそのまま対応します。区間 A で現場は観察者、区間 B で共同開発者、区間 D で運用者。区間 C はその間にある「切り替え」で、ここに経営の決裁が集中します。
週の刻み方は Scrum Guide（2020年版）の考え方を借りています。スプリントは「1か月以下の固定長」で、前のスプリントが終わった直後に次が始まる。当社は1週間を1スプリントとし、日次15分の場で進み具合を確認し、週次30〜60分の場で判断を出します。会議体の設計は[受け入れ側の体制の記事]({TEAM})に書いたとおりで、この記事では各週に何を持ち込むかだけを扱います。
第2〜4週——本番データで動く試作を、現場が毎日触る
区間 A の目的は「動くものを見せる」ではなく「現場が毎日触る」状態を作ることです。見せるだけなら第1週の Day4 で済んでいる。第2週からは実データを流し、現場が自分の業務の一部として毎日開く。
| 週 | FDE がやること | 受け入れ側がやること | 週末に見えているもの |
|---|---|---|---|
| 第2週 | 第1週に選んだ業務1本について、実データの読み取り口を作る。入力→判断→出力のうち「判断」の部分を最小の形で動かす | 情シスが閲覧用の ID とデータの出し方を渡す。現場が実データで直近1か月分を指定する | 実データで動く試作（判断1か所だけ）と、直近1か月分のテストセットの原型 |
| 第3週 | 現場の指摘を日次で反映する。例外を「作らない」「人が見る」「仕組みで扱う」の3つに分ける | 現場が毎日触り、「ここが違う」を日次15分で出す。Echo 役が例外の分類を記録する | 例外一覧（3分類）と、現場が毎日開いている試作 |
| 第4週 | テストセットに対する合格率を測る。誤りを重さで分けて一覧にする。次区間の権限・ログの設計案を出す | 現場が「出力の正しさ」の目標を、経営が「誤りの重さの許容」を決める。情シスが本実装の権限一覧を確定する | 合格率と誤りの分布の1枚。判断ポイント①の材料 |
第2週で最初に作るのは、業務全体ではなく「判断1か所」です。経理なら仕訳の勘定科目の候補、案件管理なら次の担当者の割り当て、問い合わせなら分類の下書き。1か所に絞る理由は、第3週に現場が指摘を出しやすくするためで、画面が広いと指摘が「全体的に使いにくい」になり、直せなくなる。Anthropic は「Building effective agents」（2024年12月）で「可能な限り単純な解決策を見つけ、必要になったときだけ複雑さを増やす」ことを勧めており、OpenAI のエージェント構築ガイドも「まず1つのエージェントの能力を最大化する」ことを一般的な推奨としています。当社の進め方も同じで、第2週に複数の判断を同時に動かした案件は、第4週の合格率の測り方で揉めます。何が誤りかを1か所ずつ決められないからです。
第3週の例外の3分類は、この区間で最も時間を使う作業です。現場が「これは月末だけ」「この取引先だけ違う」と言うたびに、作らない（業務側でやめる）、人が見る（仕組みは下書きを出さず人に回す）、仕組みで扱う（条件を足す）のどれかに Echo 役がその場で振り分ける。当社が見てきた範囲では、経理の業務でこの分類をすると「作らない」に入る例外が相応の割合で出て、それが第9週以降の旧帳票の停止を早めます。分類の記録は引き継ぎ記事で書いた判断ログの原型になります。
第4週は測る週です。合格率の測り方と合格基準の決め方は評価設計の記事に書いたので繰り返しませんが、ロードマップの観点で外せないのは、合格基準を第4週より前に文書にしておくことです。Anthropic の公式ドキュメント「Define success criteria」は、LLM を使う仕組みの開発は「成功の基準を明確に定義し、それに対する評価を設計するところから始まる」と書き、基準は具体的で測定可能で達成可能で目的に合ったものにせよと述べています。基準が第4週の測定後に決まると、測った数字に合わせて基準を下げる誘惑が働く。第3週の週次で「出力の正しさの目標は現場」「誤りの重さの許容は経営」と分担して決めておき、第4週はその基準に対して測るだけにします。
第5〜8週——人が確定する並走運用。権限とログを本実装する
区間 B は、仕組みが下書きを出し、人が確定する形で実業務を回す区間です。並走と呼んでいるのは、この4週間は旧手順も残っているからで、現場の負担は一時的に増えます。その分、第8週末の判断材料が実測値で揃う。ここを飛ばして第4週の合格率だけで本番に入れると、本番投入後に「試作では出なかった例外」が毎日出て、現場が旧手順に戻ります。
| 週 | FDE がやること | 受け入れ側がやること | 週末に見えているもの |
|---|---|---|---|
| 第5週 | 権限・操作ログ・保存期間を本実装する。人が確定する画面（承認・修正・差し戻し）を作る | 情シスが権限一覧と監査要件を確定し、書き込み用の ID を出す。現場が確定者を決める | 権限どおりに動く本実装の仕組み。確定者の一覧 |
| 第6週 | 並走を開始する。実業務の全件を仕組みに通し、人が確定した結果と下書きの差分を記録する | 現場が全件を確定する。差分が出たら理由を一言で残す。Echo 役が差分を毎日集計する | 並走1週目の修正率と、修正理由の分類 |
| 第7週 | 修正理由の上位から直す。人が止める条件（金額・相手先・回数）を判断表にする | 現場と経営が「人が止める条件」を承認する。情シスが操作ログの出方を確認する | 例外時の判断表と、修正率の推移（2週分） |
| 第8週 | 並走3週分の実測値を1枚にする。本番投入の手順と戻し方を書く | Echo 役が実測値を週次に持ち込み、経営が本番投入の可否を決める | 判断ポイント②の材料。本番投入手順と戻し方 |
第5週を権限とログに使う理由は、後から入れると画面より下を組み直すことになるからです。データの扱いの記事で書いた「誰が何を見られるか」「誰がいつ何をしたかをどこまで残すか」は、第1週に情シスから一覧で受け取り、第4週で確定し、第5週で実装する。この順番で進めておくと、第9週の本番投入の直前に権限や証跡の不足が見つかって差し戻される、という手戻りを減らせます。
第7週の「人が止める条件」は、区間 B で決める中で最も業務に近い判断です。OpenAI のエージェント構築ガイドは、人の介入を要する引き金として「失敗の上限を超えたとき」と「取り消せない・影響の大きい操作のとき」の2つを挙げ、後者の例として注文の取り消し、高額の返金、支払いを挙げています。経理に置き換えれば、一定金額を超える仕訳、新規の取引先、月次の締めに直接かかる処理。案件管理なら、契約金額の変更や担当者の付け替え。これらは仕組みが下書きを出しても人が確定する、と判断表に書く。第7週にこの表を経営が承認しておくと、第8週の本番投入の議論が「精度が足りるか」から「人が止める範囲は妥当か」に変わり、決めやすくなります。
並走中の修正率は週ごとに下がるのが普通で、当社の目安では修正理由の上位3つを直すとおおむね半分になります。第7週になっても下がらないときは、原因が仕組みではなく入力側にあることが多い。マスタの表記揺れ、現場ごとに違う入力の癖、判断の基準が人によって違う。この場合は第8週の判断で「対象業務を狭めて並走を2週延ばす」を選びます。
第9〜13週——本番投入、旧手順の停止、引き継ぎ完了
区間 C は切り替えの区間です。技術的な作業は少なく、経営の決裁が集中します。本番投入の日、旧手順（旧帳票・旧システムへの入力・手作業の転記）の停止日、二重入力の終了日。この3つが決まらないまま本番に入ると、新旧が並んだ状態が続き、現場は楽になっていないのに仕組みだけが「稼働中」になります。続く第12〜13週が区間 D で、FDE が手を離しても回るかを確かめる2週間です。表は第9週から第13週までをまとめました。
| 週 | FDE がやること | 受け入れ側がやること | 週末に見えているもの |
|---|---|---|---|
| 第9週 | 本番に切り替える。切り替え初日は現場に同席し、戻し方を手元に置く。週次サンプリング監査の型を作る | 現場が本番で確定する。Echo 役が初週の例外を日次で集める。情シスがログの取れ方を確認する | 本番1週目の処理件数・所要時間・例外件数 |
| 第10週 | 旧手順の利用件数を測る。まだ旧手順で処理している理由を分類する | 情シスが旧システムの参照先・止めた場合に困る人を一覧にする。現場が旧帳票を「止める」「残す」に分ける | 旧手順の利用件数と理由。停止に必要な材料 |
| 第11週 | 旧手順の停止手順と、停止後に問題が出た場合の戻し方を書く。監視の項目（費用・件数・修正率）を週次1枚に載せる | 経営が旧手順の停止日と二重入力の終了日を決裁する。Echo 役が停止を関係部署に通知する | 判断ポイント③の結論。停止日が書かれた週次1枚 |
| 第12週 | 質問対応のみに回る。Echo 役からの質問を件数と内容で記録し、文書の不足箇所に対応づける | Echo 役が主担当として業務1サイクルを回す。日次15分を Echo 役が進行する | Echo 役だけで回した1サイクルの記録と、質問の一覧 |
| 第13週 | 日次運用手順・障害時の手順・権限表・変更のやり方・判断ログの5点を揃える。次の90日の候補業務を3つまで出す | 経営が引き継ぎ完了を承認し、次の対象業務と FDE の関与の続け方を決める。情シスが文書を受け取る | 引き継ぎ完了の承認。次の90日の対象業務 |
第9週の本番投入日は、月次の締めや繁忙期と重ならない週に置きます。経理なら月初の第1営業日から数日空けた週、案件管理なら期末の見込み集計が終わった週。切り替え初日に FDE が同席する理由は、初日に出る例外が並走中と質が違うからです。当社の目安では、本番初日の例外件数は並走時の水準より増え、数日のうちに並走時の水準へ近づきます。初日の数字だけで「失敗」と判断しないよう、経営には第8週の時点で「初日は増える」と伝えておきます。
第10週に旧手順の利用件数を測るのは、停止日を決める材料を数字で持つためです。「もう使っていないと思う」では決裁が下りない。旧帳票を開いた回数、旧システムに入力した件数、手作業で転記した件数を1週間分数え、まだ使われている理由を「仕組みに足りない機能がある」「習慣」「他部署が旧帳票を要求している」に分ける。3つ目は現場では解決できず、経営から相手部署に伝えてもらいます。
第11週は本番後の監視の型を固める週でもあります。項目は処理件数と所要時間、人が修正した割合、AI を使っている場合は月額費用の3つ。修正率が第8週の判断時の水準を上回ったら人の確認に戻す、という条件を週次1枚に書いておく。AI のモデルの版の固定と切替手順はモデル更新の記事のとおり、この週に文書へ残します。
区間 D の判定の基準は引き継ぎ記事に書いた「Echo 役だけで業務1サイクルを回し、出た質問が全部文書に反映された」を使う。新しい機能は作りません。第12週に FDE は質問対応だけに回り、Echo 役が主担当として1サイクルを回す。
第12週の質問件数は、引き継ぎの出来を測る最も単純な数字です。当社の目安では、1サイクルで質問が5件以内なら文書に足して完了、10件を超えるなら第13週も並走に戻し、完了を1〜2週遅らせる。質問の中身も見ます。「この画面のこのボタンは何か」は手順書の不足、「この例外はどうするか」は判断表の不足、「誰に権限を頼めばいいか」は権限表の不足。件数より分布のほうが、どの文書を直すかを教えてくれます。成果物として何を渡すかの全体像は成果物と検収の記事にあります。
第13週に次の90日の候補業務を3つまでに絞るのは、経営が1つを選べるようにするためです。候補は、第1週の棚卸しで見つかったが今回は入らなかった業務、今回の業務の前後で二重入力が残っている業務、今回の仕組みを横展開できる別部署の同じ業務の3方向から出す。2回目の90日は Echo 役が日次15分と論点一覧の型を持っているので、第1週の棚卸しが2〜3日で終わります。当社が見てきた範囲でも、同じ仕組みを部署ごとに順に入れる進め方では、2部署目以降は区間 A が短くなります。
3つの判断ポイントで、誰が何を材料に決めるか
区間の切れ目にある3つの判断ポイントは、週次30〜60分の場で、経営が出席して決めます。共通の型は3つです。材料は前の区間で測った実測値だけ。決めるのは経営で、現場と情シスは材料の説明役として同席する。選択肢は3つまでにし、「延期」を選択肢に入れない。延ばすなら、何が分かれば決められるかと新しい期限を論点一覧に書く。
| 判断ポイント | 時期 | 問い | 材料（実測値） | 選択肢 |
|---|---|---|---|---|
| ① | 第4週末 | この業務で続けるか、対象業務を差し替えるか | テストセットに対する合格率、誤りの重さの分布、例外の3分類の件数 | 続ける／対象を狭めて続ける／別の業務に差し替える |
| ② | 第8週末 | 本番に入れるか | 並走3週分の修正率の推移、人が止めた件数と理由、権限とログの実装確認 | 本番投入／並走を2週延長／対象を狭めて本番投入 |
| ③ | 第11週末 | 旧手順をいつ止めるか | 旧手順の利用件数と理由の分類、本番3週分の処理件数・所要時間・例外件数 | 停止日を決める／残す帳票を限定して停止／次の締め後に再判断 |
判断ポイント①で「差し替える」を選ぶのは失敗ではありません。第1週に選んだ業務が、実データを流してみたら判断の基準が人によって違い、合格基準そのものが作れないことがある。この場合は基準を揃える業務改善が先で、FDE の仕事ではない。第4週で差し替えを決めれば、残り9週で別の業務を本番まで持っていける。第8週で気づくと残り5週しかなく、本番投入は次の90日に持ち越しになります。PoC で止まる会社の記事で書いた「PoC が本番に乗らない7か所」のうち、成功基準と例外の判断者はこの①で決まるものです。
判断ポイント②で当社に来る相談に多いのは、修正率が下がっているのに「もう少し様子を見たい」で並走を延ばし続けることです。並走中は現場の負担が増えているので、延ばすほど旧手順に戻る。「並走を2週延長」を選ぶなら、2週後に何がいくつになっていれば本番投入かをその場で論点一覧に書く。書けないなら延長は選びません。
判断ポイント③は、経営にしか決められない判断の典型です。旧手順を止めると他部署が旧帳票を受け取れなくなり、現場の一部は「念のため残したい」と言う。全部を聞いていると止まらない。③の場では「止めた場合に誰の何が困るか」の一覧を読み上げ、困る相手ごとに「代替を用意する」「一定期間だけ残す」「困ってもらう」を決める。Echo 役や FDE が代行すると、停止後に他部署から差し戻され、結局は経営が出てくることになります。
90日で終わらないとき——遅れの原因と、計画の直し方
13週で終わらない案件はあります。原因は技術より判断待ちのほうが多く、当社が伴走した範囲で遅れの上位に来るのは、判断ポイントに経営が出てこない、情シスの権限一覧が第4週までに確定しない、例外の3分類で「仕組みで扱う」が多すぎる、の3つです。3つとも、週を延ばしても解決しません。直すのは判断者と期限のほうです。
- 判断ポイントに経営が出てこない。①〜③の結論が週次で出ず、月次で初めて議論になり、並走が延び続ける。直し方は、判断ポイントの日付を第1週に経営の予定へ入れること。出られない週は代理の判断者を氏名で決めておく
- 権限一覧が第4週までに確定しない。第5週の本実装が始められず、区間 B が後ろにずれる。直し方は、第2週に「分からない」欄付きの一覧を先に出してもらい、分からない行だけを週次の論点にすること。閲覧用 ID は初日に出す
- 「仕組みで扱う」に振り分けた例外が多すぎる。第3週の例外一覧が減らず、第4週の合格率が測れない。直し方は、「作らない」「人が見る」に振り直すこと。判断表に載せて人が確定する側に寄せ、仕組みの条件は増やさない
- 対象業務が広い。判断1か所のはずが画面全体になり、現場の指摘が「使いにくい」で止まる。直し方は、第4週の判断①で対象を狭めること。狭めた分は次の90日の候補に回す
経営が全社の方針を出さないまま部門単位の試行が続く形は、当社の案件に限った話ではありません。IPA が2026年5月15日に公開した DX 推進指標の自己診断結果の分析レポート（2025年に提出された1,164件を分析）では、35項目の成熟度の平均が現在値1.98に対して目標値3.51、レベル4以上の企業は全体の3%でした。同レポートは成熟度レベル1を「全社戦略が明確でない中、部門単位での試行・実施にとどまっている」状態と定義しており、全社の戦略が無いまま部門単位の試行にとどまる企業が残っていることを示しています。なお、このレポートは成熟度の分布を示すもので、遅れの原因の順位を示したものではありません。FDE の90日は、経営に3回、実測値を材料にした判断を求める設計です。判断ポイントの日付を第1週に経営の予定へ入れてもらう。遅れの原因の1つはそれで減らせます。
IPA のアジャイル開発版モデル契約（2020年3月公開）も、発注側が「プロダクトの方向性及び内容に対して責任を持つプロダクトオーナー」を置き、開発が行き詰まったときは「権限のある責任者を交えた問題解消協議」で解く建て付けになっています。契約と法律に触れる話なので、個別の契約に落とすときは弁護士に確認してください。判断ポイントに経営が出る設計は、この「権限のある責任者を交えた協議」を行き詰まってから開くのではなく、最初から週に組み込んでおくものです。それでも止まる典型は失敗パターンの記事にまとめました。
計画を直すときの原則は1つです。週を延ばす前に、判断者と期限を直す。「第8週の判断を第10週に延ばす」ではなく、「第8週の判断に必要な材料のうち、揃っていないのは権限一覧の3行で、情シスの誰が第7週の水曜までに出す」と論点一覧に書く。こう書けば、延ばす必要があるかどうかもその場で分かります。それでも延びる場合は、区間 D を削らず、区間 B か C を延ばす。引き継ぎの2週間を削ると、FDE が抜けた後に手順や権限の不明点を誰も答えられなくなり、現場が旧手順に戻りやすくなります。
まとめ
FDE の90日は、第2〜4週「本番データで動く試作」、第5〜8週「人が確定する並走運用」、第9〜11週「本番投入と旧手順の停止」、第12〜13週「引き継ぎ完了と次の90日」の4区間で進みます。区間ごとに終わりの判定を実測値で1つ置き、区間の切れ目にある3つの判断ポイントで、経営が実測値を材料に「続けるか差し替えるか」「本番に入れるか」「旧手順をいつ止めるか」を決める。完了判定は「Echo 役だけで業務1サイクルを回し、出た質問が文書に反映された」こと。AWS が言う「観察者から共同開発者へ、自律的な運用者へ」の移行を、13週の中に置いた形です。
経営がこの記事から持ち帰るものは3つです。第4週末・第8週末・第11週末の3つの日付を、着任前に自分の予定に入れる。各判断の材料は実測値だけで、選択肢に「延期」を入れない。遅れたときは週ではなく判断者と期限を直し、引き継ぎの2週間は削らない。当社はこの型で、経理 AX・kintone・案件管理システム刷新・Claude 導入を本番稼働まで伴走してきました。90日の計画表は、契約書より先に、経営の予定表に書いてください。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
貴社の業務に合わせた90日の計画表を、着任前に一緒に作ります
対象業務の選び方、4区間の週次計画、3つの判断ポイントの日付と材料、経営・現場・情シスが各週に出すもの、引き継ぎ完了の判定を、貴社の業務と既存システムに合わせて1枚の計画表にします。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに、計画づくりから本番投入後の監視までご相談いただけます。