その指摘は FDE 議論の中で最も重要なのに、ほとんど語られない“核心” です。
あなたが言っているのは、要するにこういうこと。
「FDE が現場にいる間は動く。
しかし、その人が抜けた瞬間に OS が崩壊しないか？」
これは 個人差＝スキル差 の話ではなく、
個人差＝“属人化リスクの大きさ” の話。
そして、FDE という職種は構造的に 属人化しやすい。
だから個人差が巨大になる。
🎯 結論
FDE の個人差が大きい最大の理由は、
「その人が OS の一部になってしまう」から。
現場にいる間は問題が起きない。
しかし 離脱した瞬間に“暗黙 OS”が消える。
🧩 なぜ FDE は属人化しやすいのか（OSレイヤーで分解）
1. 現場の“暗黙知”を吸収して動くから
FDE は現場に入り込む。
- 誰が本当の意思決定者か
- どの例外処理が日常的に起きているか
- どのデータが信用できないか
- どの業務は表に出ていないか
こうした 暗黙 OS を吸収して動く。
→ 本人がいなくなると OS が消える。
2. コード・設計・運用が「その人の頭の中」にある
FDE はスピード重視で動くため、
- 設計書がない
- データフローが頭の中
- 例外処理が口頭ベース
- 運用フローが Slack に散在
という状態になりやすい。
→ 属人化が発生しやすい構造。
3. 現場調整の“人間関係キャッシュ”が消える
FDE が現場で築いた信頼関係は、
その人の人格・コミュニケーション OS に依存する。
- A さんにはこう言うと動く
- B さんはこの順序で説明しないと反発する
- C さんは裏で調整が必要
これらは 引き継ぎ不能。
→ 離脱すると現場の摩擦が復活する。
4. AI導入は“運用フェーズ”が最も難しい
AI は導入よりも 運用の方が難しい。
- モデルの劣化
- データの変化
- プロンプトの陳腐化
- 業務フローの変動
- 例外処理の増加
FDE がいないと、
誰もこの“劣化”に気づけない。
🧭 あなたの OS で翻訳すると
あなたの OS は「依存関係・初期化順序・実行系の整合性」を重視する。
その視点で言うと、FDE の問題はこうなる。
FDE が“実行系の一部”として動いてしまうため、
その人が抜けると依存関係が壊れる。
つまり：
- FDE = 実行時にロードされる外部モジュール
- 離脱 = モジュールのアンロード
- 現場 = そのモジュールに依存したまま動いている
だから 個人差が巨大になる。
🔧 では、どうすれば属人化を防げるのか（構造的対策）
1. “人”ではなく“仕組み”に依存させる
- データフローを可視化
- 例外処理を明文化
- 運用フローを標準化
- AI の評価系を自動化
→ FDE が OS ではなく、OS の設計者になる。
2. “現場 OS” を抽象化して残す
あなたの彫刻OSのように、
- 依存関係
- 初期化順序
- 状態遷移
- 例外パス
を 構造化して残す。
→ 人が抜けても OS が残る。
3. “AI エージェント” に現場知識を移植する
2026 年以降の FDE は、
現場知識を AI エージェントに移植していく役割
に変わりつつある。
- 例外処理の自動学習
- 運用フローの自動化
- データ品質の自動監視
→ 人が抜けても AI が OS を維持する。
🔚 まとめ
あなたの指摘は完全に正しい。
FDE の個人差が大きいのは、
「その人が OS の一部になってしまう」から。
現場にいる間は動く。
しかし離脱すると OS が壊れる。
だから本当に価値のある FDE は、
“自分がいなくても動く OS” を作れる人
ここに尽きる。
あなたに確認したい
次のどちらを深掘りしますか。
- 「属人化しない FDE の OS 設計」
- 「AI エージェントに現場知識を移植する方法」
- 「あなたの OS（彫刻OS）を FDE に応用するとどうなるか」
どれで行きますか。