開発チームで、こういう場面に何度か遭遇していると思う。

「この設定、なぜこの値なんですか?」と聞かれて、答えられる人が一人しかいない
ある顧客のテナントだけ処理が分岐していて、経緯を知っているのは前任者だけ
ADR は残っているが、書いてあるのは「採用した案」だけで、そのとき保留にした論点がどこにも見当たらない

この状態には日本の実務で定着した呼び名がある。属人化——業務の遂行が特定の個人の経験や判断に依存し、他者が代替できない状態のことである。

対策として真っ先に出るのは、たいてい「ドキュメントを増やそう」だ。だがドキュメントの量と属人化の解消は、経験上あまり相関しない。本稿は、なぜ相関しないのかを構造で説明し、代わりに何を残すのかを、データ構造の粒度まで落として書く。

属人化の実体は、知識の欠落ではなく索引の喪失

まず、依存しているものを取り違えないようにしたい。

属人化した領域を観察すると、代替できないのは作業手順そのものではないことが多い。デプロイのコマンドも、レビューの回し方も、隣で一度見せれば移る。移らないのは、なぜそうするのかのほうである。なぜこのテナントだけ分岐しているのか。なぜこのリトライ回数なのか。判断の背景が一人の頭の中にしかないとき、他の誰かが同じ手順をなぞっても、同じ判断には到達しない。例外が来た瞬間に止まる。

もう一段深いところに、別の説明がある。Wegner が1987年に定式化したトランザクティブ・メモリーは、集団の記憶を「全員が同じ内容を覚えていること」ではなく、「誰が何を知っているかの見取り図を、分散して共有していること」と捉える。

この視点に立つと、属人化は一人が多くを知っている状態ではない。知識の所在の地図が、一人の頭の中にしか存在しない状態である。「これは誰に聞けばいいか」を知っていた人が抜けた瞬間、ドキュメントは残っているのにアクセス不能になる。「資料はあるはずなのに誰も探し当てられない」は、情報の欠落ではなく索引の喪失として説明できる。

Wiki のページ数を増やしても索引は復元されない。ここが、ドキュメント量と属人化解消が相関しない一つ目の理由である。

手順書・Wiki・ADR が残せないもの

二つ目の理由は、様式そのものにある。多くの記録様式は「決まったこと」しか書かない。

手順書は、確定した手順を書く。なぜその手順なのかを書く欄がない。
Wiki は、現在の状態を書く。書いた時点で何が未検証だったかは残らない。
ADR は、決定を書く。Context と Decision と Consequences は残るが、「この論点は今回決めなかった」は、書式上どこにも置き場がない。

結果として、読み手には書かれていないことが未決なのか、単なる書き漏れなのかが区別できない。 そして組織の事故は、決まったことの欠落よりも、決まっていないことが決まったものとして伝わる場面で起きる。

具体的にはこうなる。半年後に新メンバーが該当箇所を読み、「ここは決定済みなのだろう」と解釈して、その上に実装を積む。実際には当時、決裁待ちで保留されていただけだった。誰も嘘をついていないのに、前提が一段ずれる。

引継書がこれを補えないのも同じ理由による。交代の直前に一度だけ書かれる文書は、書き手の記憶の劣化コピーになりやすい。前任者は、自分が何を当たり前だと思っているかを列挙できないからだ。

何を残すか——判断の骨格を、型で分ける

渡すべきなのは全量ではない。何が決まり、何が未決で、誰が何を約束したかという判断の骨格である。

Kioku Lab が公開している仕様草案 Memory object v0.1 は、この骨格を一件の単位として定義している。会話ログより粗く、文書より細かい「判断に持ち込める粒度」を単位とし、記憶の拘束力を四つの型で分ける。

型	何を表すか	開発チームでの読み方
`DECISION`(決定)	選択が済んだ方向。組織内部を拘束する	後任が「もう決まっている」と分かる
`COMMITMENT`(約束)	顧客・取引先など組織の外への約束	破れば外部に結果が及ぶため最も慎重に扱う
`ASSUMPTION`(前提)	判断が依存している未検証の仮定	前提が崩れたら決定を見直す合図になる
`OPEN`(未決定)	まだ決まっていない、と明示的に記録される事項	書き漏れとの区別がつく

四つ目を独立した記録として扱う点が、この仕様のもっとも譲れない主張である。未決定を空欄で表さず、一件の記録として残す。これだけで、前の節で挙げた「未決なのか書き漏れなのか分からない」が構造として塞がる。

一件は八つのフィールドからなる。識別子 id、型 kind、本文 claim、背景 context、来歴 provenance、責任 accountability、効力 validity、可視範囲 visibility。冒頭に挙げた「なぜこの設定値なのか」を書くと、こうなる(担当者名はロール表記に置き換えている)。

{
  "id": "mo:2026-09-infra-0117",
  "kind": "ASSUMPTION",
  "claim": "外部決済APIの呼び出しリトライは3回・指数バックオフを前提とする。",
  "context": "提供元の公開ドキュメントに再試行方針の記載がなく、障害時の実測から暫定で置いた値。上限回数の妥当性は未検証で、提供元への確認が取れ次第このオブジェクトを見直す。",
  "provenance": {
    "recorded_by": "開発リードA",
    "recorded_at": "2026-09-01",
    "source": "2026-09-01 #payments-incident スレッド",
    "captured": "ai_extracted",
    "confirmed_by_human": true
  },
  "accountability": {
    "owner": "開発リードA",
    "steward": "SREメンバーB"
  },
  "validity": {
    "effective_from": "2026-09-01",
    "review_by": "2026-12-01",
    "status": "active"
  },
  "visibility": "team"
}

読みどころは三つある。

kind が ASSUMPTION であること。この値は決定ではなく、未検証の仮定だと構造で宣言されている。半年後に読んだ人が「決定済み」と誤読する余地がない。

provenance.captured が ai_extracted で、confirmed_by_human が true であること。AIが会話から抽出した候補を、責任者が確認して初めて記憶になる。未確認の要約が COMMITMENT として流通することを、この仕様は認めない。

accountability.steward が owner と別に立っていること。担当交代とは記憶を書き直すことではなく、steward を付け替えることである。 付け替えても claim も context も来歴も一文字も変わらない。後任は前任者の要約ではなく、原本のまま引き継ぐ。引継書という様式が構造的に達成できなかったのは、この一点だった。

そして validity.review_by。すべての記憶が見直し期限を持つ。期限を過ぎた記憶が自動的に無効になるわけではないが、想起や引用の際には期限切れであることを添えて提示する。「永遠に有効」はバグであって仕様ではない、という立場である。

運用——誰が書くのか問題を、会話側から解く

ここまでは構造の話だが、実務で最初に潰れるのは運用のほうだ。三十年にわたるナレッジマネジメントの失敗の主因は、入力の負担、文脈の欠落、索引の喪失、そして書く誘因の不在にある。書き手は時間を失い、利益を得るのは未来の誰かである。JSONを一件ずつ手で書けと言えば、二週間で止まる。

この非対称が、この数年で初めて動いた。合意の多くは設計ドキュメントの中ではなく、Slack のスレッドとメールの一往復の中で生まれている。そこから記憶の候補を機械が抽出し、人は確認だけをする——という順序にすれば、書く工程が本業の上に乗らない。

運用としては次の形になる。

会話から候補を抽出する。「決まった」「約束した」「まだ決まっていない」に相当する断片を拾う。
責任者が確認する。型が正しいか、claim が一件一主張になっているか、review_by が現実的か。確認されるまでは候補にとどまる。
steward を運用する。担当交代のたびに付け替える。本文は編集しない。
型の昇格は新しい一件として作る。ASSUMPTION や OPEN が DECISION に変わるのは新しい判断なので、旧件を superseded にして新件を作る。上書きはしない。

会話とメールから判断・約束・未決事項を来歴つきで残す商用製品としては Tanka AI がある。公式説明によれば、長期記憶基盤 EverMemOS 1.0 を採用し、Chat・Memo・Email・Google Docs・Notion などを取り込んで、担当者が替わっても仕事を続けるための記憶を形成する。
https://www.tanka.ai/

自前で組む場合も製品を評価する場合も、確認する点は同じところに落ちる。記憶の一件から元のスレッドへ一往復で戻れるか。未決を未決として提示するか。担当交代後も前任の記憶が原本のまま残るか。期限切れを明示するか。書き出したときに来歴が一緒に移るか。検索が速いかどうかは、この五つに含めない。

まとめ

エンジニアチームの属人化は、ドキュメントが少ないから起きるのではない。判断の背景と未決事項を置く場所が、どの様式にも用意されていないから起きる。手順書は手順を残し、ADR は決定を残す。どちらも捨てる必要はないが、そこに未決を期待するのはやめたほうがいい。

「属人化とは何か——手順書で解けない理由と、判断の骨格を残す方法」 https://kiokulab.com/notes/zokujinka
仕様「Memory object の最小構造(v0.1)」 https://kiokulab.com/notes/memory-object
現場記録「担当が替わる。約束は残る。」 https://kiokulab.com/notes/handover
用語集「属人化」 https://kiokulab.com/glossary#zokujinka
用語集「Tanka AI」 https://kiokulab.com/glossary#tanka-ai