FDE（Forward Deployed Engineer）が抜けた翌月に仕組みが止まるかどうかは、渡した文書の厚さでは決まりません。設計書を200ページ渡しても月初の取り込みエラーで担当者が固まる会社はあり、A4で20ページの運用手順と判断ログだけで担当者が交代しても回る会社もある。差は「何を、どの粒度で、誰に、どの順番で渡したか」にあります。
この記事は、FDE の型のうち「本番まで持っていき、動かし方も渡す」の最後の部分、つまり引き継ぎの中身だけを扱います。何を成果物として検収するかは成果物と検収の記事に、受け入れ側で誰が引き継ぐか（Echo 役）は社内体制の記事に書いたので繰り返しません。答えるのは、失敗の典型、渡す文書5点の構成、FDE 不在でも使えるランブック（運用手順書）の書き方、引き継ぎ完了の判定の4つです。Google の SRE 本、AWS の Well-Architected フレームワーク、IPA のモデル契約書と、当社が経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに書いています。
渡す文書は5点。日次運用手順（画面と操作の単位）、障害時の手順（症状から引ける）、権限表（役割で書き、鍵の持ち主を明記）、変更のやり方（変えてよい範囲）、判断ログ（なぜそう決めたか）。ランブックには「望む結果・必要な権限・失敗時の対処・更新責任者」を入れ、書いた本人以外が実行して検証する。期間は「並走→Echo 役が主担当→FDE は質問対応のみ」の3段階。完了判定は「Echo 役だけで業務1サイクルを回し、質問が全部文書に反映された」こと。AI 部分はプロンプト・評価セット・モデル更新時の確認手順を追加で残す。
この記事の要約
引き継ぎで失敗する典型——「設計書は渡した」と「一人に集中」
失敗は文書がなかったから起きるのではなく、当社が見てきた範囲で4つの型に分かれます。1つ目は「設計書は渡したが直せない」。テーブル定義書と画面仕様書は揃っているのに、「取引先マスタに1件足したい」ときにどの画面で何をするかが書かれていない。設計書は「何が作られているか」の記録で、「どう動かすか」の記録ではない。2つ目は「手順はあるが判断がない」。想定外のエラーが出た瞬間に止まり、手順書には「エラーが出たら FDE に連絡」とあるが、その FDE の契約は終わっている。
3つ目は「一人に集中する属人化」。Echo 役が全部を頭に入れ、文書を更新しないまま半年が経ち、異動した月に後任が文書と実態のずれで止まる。4つ目は「文書の置き場所が FDE 側」。手順も判断ログも FDE の道具に置かれたまま契約が終わり、開けなくなる。AWS の Well-Architected フレームワーク（AWS が公開している設計と運用の指針集）も、手順が文書化されていない、スクリプトの使い方が少数の個人に握られている、更新が必要なのに元の作者がもう組織にいない、を「よくある悪い型」として挙げています。FDE が抜けた後の中堅企業で起きることは、これと同じです。
引き継ぎの文書が効くかどうかは、数字でも示されています。Google の SRE（Site Reliability Engineering）本の第1章は、人が対応せざるを得ない障害について、あらかじめ最善の手順を考えて「プレイブック」に記録しておくと、その場しのぎで対応する場合に比べて復旧までの時間（MTTR）がおよそ3倍改善する、と Google 社内の経験から書いています。同じ章は、手順書はその場で考えられるエンジニアの代わりにはならない、とも釘を刺している。引き継ぎ文書の目的は、FDE がいなくても止まらない時間を稼ぐことです。
失敗パターン10で挙げた「Echo 役不在」の先、人は揃っているのに文書の中身と渡し方で失敗する型が、この記事の対象です。
渡す文書は5点——それぞれの読み手と構成
成果物と検収の記事では、「動かし方」を運用手順・例外時の判断表・権限表・データの持ち主一覧・変更のやり方・Echo 役への引き継ぎ記録の6つに分けました。この記事では、それを渡す文書の形に組み直して5点にします（権限表とデータの持ち主一覧を1つに、引き継ぎ記録を判断ログに含める）。5点に分けるのは、読み手と開く場面が違うからです。担当者が毎日開く文書と監査で情シスが開く文書を1冊にすると、どちらにも探しにくい。
| 文書 | 読み手・開く場面 | 構成（見出しの単位） | 更新のきっかけ |
|---|---|---|---|
| ① 日次運用手順 | 業務の担当者。毎日・毎週・毎月の作業のたびに開く | 作業ごとに「開始条件／開く画面／操作／確認する値／終了条件／所要時間」。月初・月末・期末は別節。代理手順も入れる | 画面や設定が変わったとき。変更のやり方（④）を実行したら必ず①を直す |
| ② 障害時の手順 | 担当者と Echo 役。止まったとき・数字が合わないときに開く | 「症状」から引ける索引が先頭。症状ごとに「まず確認すること／よくある原因／その場の対処／連絡先と伝える情報／業務を止めない暫定手段」 | 新しい症状が出たとき。判断ログ（⑤）に記録した例外のうち、再発しうるものを②に昇格させる |
| ③ 権限表 | 情シス・監査・Echo 役。人事異動・退職・監査・契約終了のときに開く | 役割（担当者／承認者／管理者／閲覧のみ）ごとに「見られる／変えられる／承認できる」。別表で「鍵」（API キー・サービスアカウント・外部サービスの契約者名義）の持ち主と失効手順。データの正本の置き場所と責任者 | 人が変わったとき、外部サービスを足したとき。四半期に1回の棚卸しを日付で決めておく |
| ④ 変更のやり方 | Echo 役と、Echo 役が指名した担当者。直したいときに開く | 「Echo 役だけで変えてよい範囲／情シスの確認が要る範囲／外部に頼む範囲」を先に線引き。次に種類ごとの手順、変更前の確認方法（試験データ・影響する画面）、戻し方、記録の残し方 | 新しい種類の変更を初めて行ったとき。線引きの見直しは月次で |
| ⑤ 判断ログ | Echo 役、後任、経営。「なぜこうなっているか」を聞かれたときに開く | 日付・論点・決めた人・内容・理由・捨てた案とその理由。FDE 期間中の論点一覧を引き継ぎ、引き継ぎ期間中の質問と回答を追記する | 判断が出るたびに追記。消さない。上書きせず、変更したときは新しい行を足す |
表の右端「更新のきっかけ」が、5点を生かすか殺すかを決めます。AWS の指針は手順書の更新を変更管理の一部と位置づけ、システムと手順書がずれたまま放置されることを「よくある悪い型」に挙げている。だから④の最後の手順は必ず「①の該当箇所を直す」にする。変更と文書更新を別の作業にしないことが、属人化を防ぐ一番安い方法です。
置き場所は受け入れ側が普段使う道具（共有ドライブ・kintone・社内 Wiki）にします。条件は、Echo 役と担当者が自分の権限で開ける、版の履歴が残る、FDE の契約が終わってもアクセスが消えない、の3つ。当社は着任1週目に置き場所を決め、FDE 側の道具には置きません。文書が FDE の手元にあるうちは、引き継ぎは始まっていない。
ランブックの書き方の原則——画面と操作の単位、判断基準、更新責任者
5点のうち、①日次運用手順と②障害時の手順をまとめて、この記事ではランブック（運用手順書）と呼びます。AWS の Well-Architected フレームワークは、ランブックを「特定の結果を得るために文書化された手順」と定義し、誰が使っても同じ結果になる「成文化された手順」であること、最も単純な形では「作業を完了するためのチェックリスト」であること、と説明しています。含めるべきものとして、望む結果、必要な道具と権限、失敗したときの対処、例外、上への連絡先を挙げ、更新責任者を明記して一か所に公開し、「別の人に実行してもらって検証する」ことを求めている。障害の原因を調べる手順は「プレイブック」と呼び分けられていますが、この記事では②障害時の手順に両方を入れます。
当社の原則は3つです。1つ目は「画面と操作の単位で書く」。「取り込みを実行する」ではなく「〇〇画面を開き、左上の『取込』を押し、完了メッセージに件数が出るのを確認する」まで書く。読み手の担当者は半年後に交代しているかもしれない。2つ目は「判断基準を数字で書く」。「金額が大きい場合は確認」ではなく「1件〇〇万円以上、または前月比〇〇%以上の差なら承認者に回す」。3つ目は「更新責任者を1人決めて先頭に書く」。AWS の指針は、手順ごとに持ち主を一意に決め、その人が「適切な権限を持つ担当者なら実行できること」を確認する責任を持つとしています。当社の場合、持ち主は Echo 役です。
| 書き方の例 | 直す前（FDE 不在で止まる） | 直した後（担当者だけで進む） |
|---|---|---|
| 操作の粒度 | 月次の取り込みを実行し、エラーがあれば対処する | 〇〇画面で『取込』を押す。完了メッセージの件数が当月の請求書枚数と一致することを確認する。一致しなければ②「件数不一致」へ |
| 判断基準 | 内容が怪しいものは担当者が確認する | AI の下書きのうち、勘定科目が前回と違う・金額が〇〇万円以上・取引先がマスタに無いものは承認者に回す。それ以外は確定する |
| 失敗時の対処 | エラーが出たら FDE に連絡 | エラー文言に「認証」があれば③の「鍵」一覧で有効期限を確認し、期限切れなら情シスに再発行を依頼（1営業日）。その間は手入力で進める |
| 更新責任者 | （記載なし） | 先頭に「更新責任者 〇〇（Echo 役）／最終更新日／次回見直し日」。④を実行した人がその日に該当箇所を直す |
「直した後」はどの行も他の文書を指しています。①の失敗時は②へ、②の認証エラーは③へ、④を実行したら①へ。5点は参照し合う1組として渡し、担当者が「どこを見ればいいか」で止まらないようにします。
契約実務の側でも、運用手順書は同じ扱いです。IPA（情報処理推進機構）の「情報システム・モデル取引・契約書（第二版）」（2020年12月公表、2025年4月更新）には、保守・運用の業務仕様書サンプルとして、サービスの具体的内容と連絡体制を「運用手順書」に定める例が載っています。解説には、役割分担の定義が曖昧だとサービス開始後に「どちらが実施すべき作業か不明な事態」が多々起きること、運用要件が変わったら運用手順書を「正確に修正し合意していかなければならない」ことが書かれ、「運用手順書の変更」の項は、書面で申し入れ、契約条件への影響を両者で判断し、変更後の手順書を責任者が確認する手続きを置いている。契約の細部は個別の事情で変わるので、契約書に落とす前に弁護士に確認してください。IPA のモデル契約書も運用手順書を「変更のたびに直して合意する文書」として扱っている、という点です。
引き継ぎ期間の設計——並走、Echo 役が主担当、FDE は質問対応のみ
引き継ぎは最終日に文書を渡して終わるものではなく、期間を持った工程です。AWS が2026年6月に FDE 組織の設立を発表した文書には、案件が進むにつれて顧客側のエンジニアが「観察者から共同開発者へ、そして自律的な運用者へ」移っていく、と書かれています。当社はこれを3段階に分け、段階ごとに FDE と Echo 役の関与と、文書の書き手を変えています。
| 段階 | 期間の目安 | FDE の関与 | Echo 役・担当者の関与 | 文書の状態 | 次の段階に進む条件 |
|---|---|---|---|---|---|
| 第1段階 並走 | 業務1サイクル（月次なら1か月） | 主担当として操作し、手順を口に出す | 隣で見る。疑問をその場で言う | FDE が①②を書く。Echo 役が読んで「分からない」箇所に印を付ける | ①②の初版が揃い、Echo 役が通読して印を付け終えた |
| 第2段階 Echo 役が主担当 | 業務1〜2サイクル | 手を出さず、詰まったら文書のどこを見るかだけ指す | 自分で操作する。文書と実態のずれを見つけたら自分で直す | Echo 役が直し FDE が確認。③④⑤を FDE が書く | Echo 役が1サイクルを自分の操作で完走し、途中で FDE が手を出した回数がゼロ |
| 第3段階 質問対応のみ | 業務1サイクル | 同席しない。チャットで答え、回答を文書に反映させる | 担当者だけで回す。質問は記録してから送る | Echo 役が更新責任者。FDE は変更を提案するだけ | 1サイクルの質問がゼロ、または全部が①〜⑤のいずれかに反映済み |
第1段階で FDE が「操作しながら手順を口に出す」のは、①の下書きをその場で作るためです。机で書いた手順書より、操作を実況しながら Echo 役に書き取ってもらった手順書のほうが、担当者が詰まる箇所が少ない。Echo 役が「分からない」と印を付けた箇所が、FDE には自明で書き飛ばした箇所です。
第2段階で大事なのは、FDE が手を出さないことです。詰まった Echo 役を FDE が直すと、Echo 役の記憶には「FDE が直した」しか残らず、文書も直らない。FDE の役割は「文書のどこを見るかを指す」だけ。指した先に答えがなければ文書の不備で、その場で Echo 役が追記する。手を出した回数がゼロになるまで、第2段階は終わりません。
第3段階は、成果物と検収の記事で書いた「FDE の同席なしに業務1サイクル」と同じ状態です。質問は FDE がチャットで答えて終わりにせず、必ず①〜⑤のどれかに書き足す。3段階の合計は、月次業務なら3〜4か月、日次業務なら6〜8週間が当社の目安です。短くするなら削れるのは第3段階で、第2段階を削ると FDE が抜けた月に止まります。
引き継ぎ完了の判定——Echo 役だけで1サイクル回せたか
「引き継ぎました」（FDE の申告）と「引き継がれました」（Echo 役の実績）は別の状態です。判定は後者で行い、次の10項目を Echo 役が自分で埋め、上司が確認します。
| 確認項目 | 判定の方法 | 合格の目安 |
|---|---|---|
| 1 Echo 役だけで業務1サイクルを完走した | 第3段階で FDE が同席・遠隔操作した回数 | 0回。質問はあってよい |
| 2 サイクル中の質問が文書に反映された | 質問一覧と①〜⑤の更新履歴を突き合わせる | 質問の全件が、いずれかの文書の追記・修正に対応している |
| 3 Echo 役以外の担当者が①だけを見て日次作業を完了できた | 副担当に①を渡して1日分の作業をしてもらう | Echo 役への口頭質問が0〜1件 |
| 4 障害時の手順を1回以上使った | ②を見て自力で処理した例外の件数 | 1件以上。例外が出なければ FDE が試験データで起こす |
| 5 権限表が実態と一致している | ③の役割とシステム上の権限設定を突き合わせる | 差分ゼロ。管理者権限を日常作業で使っていない |
| 6 「鍵」の持ち主と失効手順が書かれている | ③の別表に持ち主の氏名と失効手順があるか | 全件に持ち主がいる。FDE 個人の名義が残っていない |
| 7 Echo 役が自分で1回以上変更した | ④に沿って Echo 役が行った変更の記録 | 1件以上。その変更が①に反映されている |
| 8 判断ログが受け入れ側の道具にある | ⑤の置き場所とアクセス権 | Echo 役と上司が自分の権限で開ける。FDE の道具に原本がない |
| 9 更新責任者と次回見直し日が各文書の先頭にある | ①〜⑤の先頭を見る | 5点すべてに氏名と日付がある |
| 10 Echo 役が経営に「動かし方」を自分の言葉で説明した | 月次の場で5分。FDE は同席しない | 経営から「で、誰に聞けばいいの」が出ない |
当社が一番重く見ているのは3番です。Echo 役が回せることと、Echo 役以外が回せることは違う。副担当が①だけで1日分を完了できるかは、文書が「人ではなく手順」に依存しているかの試験で、合格しなければ①の粒度が粗い。
6番も見落とされがちです。試作段階で FDE 名義で取った API キーが本番でそのまま使われ、契約終了後に失効して原因不明で止まることがある。経理業務の FDE 方式の記事の「承認履歴と変更記録は最初から入れる」と同じで、名義は本番に乗せる時点で受け入れ側に移し、判定の場では③で移っているかを確認するだけにします。
合格したら、完了日と判定した Echo 役・上司の氏名を⑤判断ログに残します。PoC→本番と契約の記事に書いたとおり、引き継ぎの完了条件を契約の別紙に写しておけば、この10項目を完了確認の項目として使えます。
AI 部分の引き継ぎで特に残すもの——プロンプト・評価セット・モデル更新時の確認手順
仕組みに AI（大規模言語モデルを使った下書き・分類・要約など）が入っている場合、5点に加えて残すものが3つあります。設定値が「プロンプト（AI への指示文）」という自然文で、動作が確率的で、モデルがベンダ側の都合で更新される、という3つの性質が、通常のシステムにない論点を生むからです。
- プロンプトの原本と版の履歴。原本は受け入れ側の版管理のある場所に置き、画面上の設定欄だけに存在する状態にしない。各版に「変えた理由」と「変える前後で評価セットの結果がどう変わったか」を添える
- 評価セット。本番データから抜いた数十〜数百件の入力に、担当者が正解を付けたもの。プロンプトやモデルを変える前後で同じセットを流し、正解率や修正率の動きを見る。正解の基準と、四半期ごとに追加する担当者・件数も④に書く
- モデル更新時の確認手順。ベンダがモデルを更新・廃止したとき、誰が気づき、誰が評価セットを流し、どの水準を下回ったら何をするか。当社は「正解率が導入時より〇ポイント下がったらプロンプトを見直す、〇ポイント下がったら人の確認を全件に戻す」と2段階の閾値を②に書き、更新告知の受け取り先も明記しています
通常のシステムはエラーを出して止まるが、AI は止まらずに出力の質が少しずつ下がる。「最近、直す量が増えた気がする」と感じたとき、評価セットがあれば数字で確かめられる。なければ感覚の話で終わり、もういない FDE に「なんか変」と連絡するしかなくなる。
AI 部分で Echo 役が最初に手を出せるのは、判断基準の閾値です。「AI の下書きをそのまま確定してよい条件」を着任1週間の記事の判断表の数字（金額・前月比・マスタ有無）で書いておけば、Echo 役はモデルの中身を知らなくても閾値を安全側に寄せられる。当社が伴走した経理の下書き AI では、Echo 役が最初に自分で行った変更は「人が確認する金額の下限を下げる」で、プロンプトには触っていません。それが AI 部分の引き継ぎの正しい入口だと考えています。
まとめ
FDE が抜けた後も回る引き継ぎは、文書の厚さではなく、渡す文書の中身と渡し方で決まります。渡すのは日次運用手順・障害時の手順・権限表・変更のやり方・判断ログの5点で、参照し合う1組として受け入れ側の道具に置き、更新責任者を Echo 役にする。ランブックには「望む結果・必要な権限・失敗時の対処・更新責任者」を入れ、書いた本人以外が実行して検証する。
引き継ぎ期間は「並走→Echo 役が主担当→FDE は質問対応のみ」の3段階で、第2段階で FDE が手を出した回数がゼロになるまで進めない。完了判定は Echo 役が10項目を埋め、Echo 役以外の担当者が日次運用手順だけで1日分を回せるかを最も重く見る。AI 部分はプロンプトの版・評価セット・モデル更新時の確認手順を追加で残す。この形で渡せば、FDE が帰った翌月も、担当者が交代した半年後も、仕組みを受け入れ側の手で回し続けられる状態を目指せます。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
FDE が抜けた後も回る引き継ぎを、文書の設計から一緒に作ります
渡す文書5点の構成、ランブックの書き方、3段階の期間設計、完了判定の10項目、AI 部分の評価セットとモデル更新時の確認手順まで、貴社の業務と既存の道具に合わせて設計します。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働と引き継ぎまで伴走した経験をもとに、「前のベンダから設計書は受け取ったが直せない」段階からもご相談いただけます。