FDEの引き継ぎとドキュメント化｜属人化を防ぐ

ここでいうFDEは Forward Deployed Engineer（顧客の現場に入りAIやソフトを業務に合わせて実装する技術者）を指します。全ディスク暗号化（Full Disk Encryption）の略ではありません。FDEの仕事は「作って動かす」だけでは終わりません。担当者が現場を離れても運用が回り続けるかどうかは、FDE 引き継ぎのための記録をどう設計したかで決まります。本記事を読めば、現場で残すべきドキュメントの種類と粒度、引き継ぎの順序を把握し、自分の案件でどの記録を・どの時点で・誰に向けて残すかを決めて、属人化しない引き継ぎ計画に着手できるようになります。FDEに必要なスキルの全体像はFDEに必要なスキルの全体像｜8領域で解説で扱っていますので、本記事は「引き継ぎとドキュメント化」の一点に絞ります。

引き継ぎ資産は「動くもの」とは別に設計する

一般的なFDEの解説は「現場に入り込んで成果を出す」ところで止まり、去り際の設計をほとんど語りません。しかし私たちが現場で見てきた限り、導入が成功しても引き継ぎが弱いと、半年後には誰も触れないシステムが残ります。動くシステムと、それを他人が運用できる状態は別物です。後者を支えるのが引き継ぎ資産であり、これは意識して設計しないと残りません。

なぜ属人化は起きるのか

属人化は怠慢ではなく、むしろ有能なFDEほど陥りやすい構造です。現場に深く入り込むと「頭の中で分かっているから書かなくても動く」状態になり、記録を後回しにします。ある製造業のクライアントの現場では、入出荷まわりの業務ロジックを一人のエンジニアが把握しきっていたために、その人の予定が空くまで変更が止まる、という状況が生まれていました。優秀さが依存を生むのです。

残すべきは「判断の理由」

引き継ぎで最も抜けやすいのは、操作手順ではなく「なぜそう設計したか」です。コードや画面は見れば分かりますが、「この項目をあえて自動化しなかった理由」「この権限を広げなかった背景」は記録しないと消えます。後任者が理由を知らずに変更すると、過去に避けた失敗を踏み直します。判断根拠こそ最優先で残す資産です。

何を・どの粒度で残すか

ドキュメントは多ければ良いわけではありません。詳細すぎると誰も更新せず、すぐ陳腐化します。私たちが大切にしているのは、読み手を決めて粒度を変えることです。運用担当者向け・管理者向け・次のFDE向けで必要な情報は違います。全部を一つの文書に詰めると、どの読み手にも使いにくくなります。

読み手別の4つの記録

下表は、引き継ぎ資産を読み手別に整理したものです。自分の案件でどれが欠けているか点検してみてください。

記録の種類	主な読み手	残す内容と粒度
運用手順書	日々の運用担当者	通常操作・エラー時の初動を画面単位で
設計意図メモ	次のFDE・改修者	なぜその構成にしたか・採用しなかった案
権限・証跡の所在表	管理者・監査担当	誰が何にアクセスでき、ログがどこにあるか
決定ログ	関係者全員	決めたこと・保留・変更の履歴を日付つきで

権限と証跡は「所在」を書けば足りる

引き継ぎで権限管理やログを扱うとき、設計の詳細を書き直す必要はありません。引き継ぎ資産として必要なのは「どのアカウントが何にアクセスできるか」「操作ログがどこに・どの期間保管されているか」という所在の明示です。後任者や管理者が、何かあったときに辿れる地図があれば十分です。権限設計そのものの考え方はAIエージェントの権限管理設計｜FDE実践術で扱っています。

引き継ぎの順序と現場での進め方

ドキュメントを揃えても、渡す順序を間違えると定着しません。去り際にまとめて書こうとすると粒度も精度も落ちます。私たちが大切にしているのは、引き継ぎは最後にやる作業ではなく、着手時から少しずつ積む作業だという考え方です。

決定ログは着任初日から残す

最も効くのは、プロジェクト開始時から決めたこと・保留にしたこと・次にやることを毎回短く記録する習慣です。これは信頼構築にも効きますが、引き継ぎ資産としても最強です。あるSaaS企業の案件では、この決定ログがそのまま後任への説明書になり、口頭の引き継ぎがほぼ不要になりました。着任直後の動き方はFDEが現場で最初の1週間にやることも参考になります。

引き継ぎの順序

渡す順序は、全体像→運用手順→設計意図→権限・証跡の所在、の流れが実務的です。まず「このシステムが何のためにあり、どこまで担うか」を共有し、次に日々の操作、そのうえで改修に必要な設計意図、最後に管理者向けの権限・証跡を渡します。いきなり詳細から入ると、受け手が全体像を描けないまま断片を抱えることになります。

自分を手放せる形で残す誠実さ

スタートアップでの経験から言うと、信頼されるFDEほど「自分がいなくても回る状態」を目指します。属人化を手放すことは短期的には自分の価値を減らすように見えますが、実は最も長く任される道です。引き継ぎ資産が整っていれば、顧客は次の課題でもまた声をかけてくれます。運用定着の進め方はAI導入後の運用定着｜伴走支援の実際でも掘り下げています。

よくあるご質問

Q. ドキュメントはどこまで詳しく書けばいいですか。
読み手を決めてから粒度を決めるのが実務的です。運用担当者向けは画面単位の操作、次のFDE向けは判断の理由、管理者向けは権限と証跡の所在、と分けます。全部を一つに詰めると更新されず陳腐化します。更新され続ける粒度に抑えるほうが、精緻だが放置される文書より価値があります。

Q. 引き継ぎはいつから準備すればいいですか。
去り際ではなく、着任初日からです。決めたこと・保留・変更を日付つきで記録する決定ログを最初から積んでおくと、それ自体が引き継ぎ資産になります。まとめて書こうとすると粒度も精度も落ちるため、日々少しずつ残すほうが結果的に楽で確実です。

Q. 権限やログの情報も引き継ぎ資産に含めるべきですか。
含めるべきですが、設計を書き直す必要はありません。「誰が何にアクセスでき、ログがどこに保管されているか」という所在が辿れれば十分です。何かあったときに後任者や監査担当が追える地図を残すことが、法人の現場では特に安心につながります。

属人化しない引き継ぎ体制づくりのご相談はお気軽に

FDE活用・法人研修のお問い合わせはこちら →

コミュニティに参加する →

日本FDE協会

FDE（Forward Deployed Engineer）の認知拡大・人材育成・コミュニティ形成を目的とした協会です。技術とビジネスの双方を現場で実践するエンジニアを支援しています。

お問い合わせ →