トピック10.3 — ナレッジマネジメントとドキュメンテーション

一文で言うと： 安全が重要なサービスでは、チームが知っていながら書き留めていないことは、単なる不便ではなく臨床リスクです。したがって、ドキュメンテーションを第一級の成果物として扱い、知識の継続性を、あれば良いものではなく義務として扱ってください。

医療・ケアにおいてなぜ重要か#

デジタルヘルスのチームは、小さく、専門化され、しばしば正規職員、契約者、サプライヤーのエンジニアから寄せ集められています。病理の連携が失敗する前になぜ3回再試行するのか、あるいは電子患者記録のどのフラグが重複アレルギーのアラートを抑制するのかを理解している人は、しばしば一人だけであり、その人は、連携が午前2時に壊れる週に、異動し、退職し、あるいは病欠します。知識がその人とともに去ると、システムは単に保守しにくくなるだけでなく、安全に運用しにくくなります。臨床家が頼っていた文書化されない回避策は、静かに消えうるのに、それが荷重を担っていたことを、誰も知りません。

賭け金は、この部門に特有です。誤解された設定は、患者の取り違えの記録、見逃されたアラート、壊れた紹介を生みえ、その害は、ダウンタイムのチケットではなく、患者の成果で測られます。公的機関は法定の義務も負います。健康記録は定められた期間保持されなければならず、ケアと公的資金についての判断は、検視官、規制当局、情報公開請求がやって来たとき、何年後でも監査可能で、見つけられなければなりません。したがって、良いナレッジマネジメントは、一部は臨床安全であり、一部はガバナンスであり、一部は、サービスを動かし続けなければならない次の人への敬意です。それは、ライブ運用の方法（トピック3.8 — サービスマネジメントとライブ運用参照）と、チームの設計方法（トピック7.0 — チーム構造、役割、責任参照）から切り離せません。

中核概念#

規律としてのナレッジマネジメント。 ナレッジマネジメントとは、組織が知っていることを、創出し、捕捉し、共有し、再利用する一連の実践です。それは、人と文化、プロセスと構造、技術の三つの構成要素のバランスをとり、リーダーがそれを習慣ではなくツールの購入として扱うたびに失敗します。「知識」は、あるトラストで臨床経路が実際にどう機能するかから、特定の連携エンジンがどう設定されているかまで及びます。

暗黙知と形式知。 暗黙知は、人の頭と手に生きているもの、つまり、判断、直感、そして書き下しにくい、苦労して得た「このトラストは退院を別の方法でコード化していると知っておく必要がある」です。形式知は、明確に表現され、文書、図、ランブックに体系化されたものです。サービスを安全に保つ知識の大半は暗黙知として始まり、ナレッジマネジメントの仕事は、サービスが誰か一人の頭に依存しないよう、十分な量を形式知へ変換することです。

SECIの知識変換モデル。 野中と竹内によるSECIモデル（共同化、表出化、連結化、内面化）は、知識が暗黙知と形式知の間をどう移るかを記述します。互いに並んで働くことによる共有（共同化）、暗黙知を書き下すこと（表出化）、形式知の断片をより大きな文書へ組み合わせること（連結化）、そして文書化された知識を、流暢な実践へ再び吸収すること（内面化）。それが有用なのは、ドキュメンテーションだけでは十分でないことを思い出させるからです。ペアリング、シャドーイング、コミュニティは、wikiと同じくらい重要です。

属人性とバスファクター。 バスファクターとは、それを理解する人がいなくなってサービスが止まるまでに、失われなければならない人数です。バスファクター1は、ほとんどの小さなデジタルチームの既定の状態であり、人々の健康が依存するサービスにとって、深刻な運用リスクです。高い離職、多用される契約者、単一サプライヤーへのロックインは、すべてその数を押し下げ、意図的なドキュメンテーション、クロストレーニング、ペアリングは、それを押し上げます。

第一級の成果物としてのドキュメンテーション。 文書を、副産物ではなく、プロダクトとして扱ってください。サービスマニュアルは、サービスが何であり、どう振る舞うかを記述し、ランブック（またはプレイブック）は、それを起動し、停止し、復旧するための段階的な手順を与え、アーキテクチャ決定記録（ADR）は、重要な選択がなぜなされたかを捉え、将来の保守者が、理由を知らずにそれを解きほぐさないようにします。信頼できる唯一の情報源とは、各事実がちょうど一つの場所でマスター管理されることで、「現在のアーキテクチャ」の矛盾するコピーを追いかけずに済みます。

ドキュメント・アズ・コード。 ドキュメンテーションを、作業と同じバージョン管理されたリポジトリに保ち、プレーンテキストやMarkdownで書き、コードのようにレビューし、自動的に公開することは、ドキュメントを、記述する対象の近くに置き、最新に保たれる可能性をはるかに高めます。図がコードの隣にあり、同じプルリクエストで変わるとき、それはよりゆっくり腐ります。

実践コミュニティ。 実践コミュニティ（ギルドと呼ばれることもある）とは、臨床安全責任者、フロントエンドのエンジニア、情報ガバナンスのリードのような、ある技芸を共有し、ともに改善する、チームをまたぐグループです。実践コミュニティは、縦割りのチームの境界が閉じ込めてしまう、組織全体の中で、暗黙知を水平に広げます。

記録管理と保持。 記録管理は、情報をそのライフサイクル全体を通じて統治し、どれだけ長く保持しなければならないか、いつ破棄してよいかを含みます。医療では、これは部分的に法定です。臨床記録には、NHS Records Management Code of Practiceのもとで定められた保持期間があります。これはチームのドキュメンテーションとは別であり、両者の混同は、本物の誤りを引き起こします。この点は、後で再び触れます。

情報アーキテクチャと見つけやすさ。 情報アーキテクチャとは、人々が必要なものを見つけられるよう、情報空間を構造的に設計することです。1万ページあって構造のないwikiは、ドキュメンテーションではなく、ごみ捨て場です。見つけやすさは、存在する知識と、使われる知識の違いです。

ベストプラクティス#

1. ドキュメンテーションを、後付けではなく、完了の定義にする。 機能、連携、設定変更は、そのランブックの項目、（重要な判断がなされたなら）ADR、サービスマニュアルの更新が存在するまでは「完了」ではありません。知識が新鮮なうちに、それを持つ人が書くよう、これを働き方に組み込んでください。システムを6か月後に記憶から後追いで文書化することは、不正確さと危険なギャップが生まれる場所です。

2. 信頼できる唯一の情報源を保ち、そこから外へリンクする。 ドメインごとに、各事実の権威ある版がどこにあるか、つまりアーキテクチャ、オンコールの当番表、データフロー図を決め、ほかのすべてを、コピーではなく、そこを指すようにしてください。重複したドキュメンテーションは漂流し、臨床の文脈では、アレルギーチェックがオフなのに「オンだ」と言う古いコピーは、文書がないよりも悪いのです。すでにある古い重複を、容赦なく削除するか、リダイレクトしてください。

3. ドキュメント・アズ・コードを採用し、ドキュメンテーションを作業の隣に置く。 ランブック、ADR、サービスマニュアルを、それが記述するシステムと並べてバージョン管理に保存し、ドキュメンテーションの変更を、コードの変更と同じプルリクエストでレビューし、自動的に公開してください。これにより、更新が安価になり、変更がレビュー可能になり、履歴が監査可能になり、システムを変更する人が、同じ息でドキュメンテーションも変えるよう促されます。

4. 午前3時に、ストレスを受けた見知らぬ人が従えるランブックを書く。 ランブックは、読者が疲れ、システムに不慣れで、圧力のもとにいると想定すべきです。重大インシデントの間、彼らはそうなるからです。番号付きの文字どおりの手順を使い、正確な画面とコマンドを名指しし、各ステップの期待される結果と、失敗した場合の対処を述べてください。それを書かなかった人に、演習で復旧を実行させることで、テストしてください。

5. アーキテクチャ決定記録で、「何を」だけでなく「なぜ」を捉える。 短いADR、つまり文脈、決定、帰結は、重要な選択の背後にある推論を保存し、将来の保守者が、それを駆動した制約を理解せずに決定を覆さないようにします。医療では、これは切実です。奇妙に見える設定は、臨床安全のハザード分析や情報ガバナンスの裁定のために存在しているかもしれません。理由を記録することは、善意の「整理」が、既知のリスクを再び持ち込むのを防ぎます。

6. すべての重要なシステムで、バスファクターを意図的に引き上げる。 バスファクター1のシステムを特定し、それを、名前のある所有者と計画とともに、リスク登録簿上のリスクとして扱ってください。人をペアにし、オンコールの知識をローテーションし、専門家が文書化する間、同僚が一緒に追う「ティーチバック」のセッションを行い、安全に不可欠なサービスをデプロイまたは復旧できるのが、一人だけという状態を禁じてください。これは、停止中にギャップを発見するより安価です。

7. 人を責めるのではなく、実践を変えるインシデント後レビューを行う。 重大なインシデントの後には、文書化され、所有者がおり、期限のある行動を生む、非難のないインシデント後レビューを行い、そして実際にそれらを完了させてください。ファイルされて二度と見直されない教訓は演劇であり、プロセスのテストは、同じ形の後のインシデントが防がれるかどうかです。発見を、ランブックと臨床安全のケースへ直接フィードバックしてください（トピック3.8 — サービスマネジメントとライブ運用参照）。

8. 情報アーキテクチャと見つけやすさに投資する。 新しく加わった人が、1分以内にオンコールのランブックを見つけられるよう、知識ベースを構造化し、積極的に刈り込んでください。古くなったページは、資産ではなく負債です。命名規則、明確な階層、各領域の所有者に合意し、重要なページには、読者が新しさを判断できるよう「最終レビュー」の日付を付けてください。検索は構造の代わりではなく、それを補うものです。

9. 実践コミュニティを育てて、暗黙知を広げる。 臨床安全、セキュリティ、フロントエンド、データエンジニアリングなど、重要な技芸のために、軽い役割を持つチーム横断のギルドを立ち上げてください。学んでいることを共有し、共通のパターンに合意し、新人を指導する。これらの場は、どの文書も捉えない暗黙知を動かし、チーム間で重複する誤りを減らします（トピック7.5 — 人材・組織開発参照）。勤務週の中に時間を与えなければ、それらは枯れます。

10. チームのドキュメンテーションと法定の記録を分け、両方を管理する。 チームの知識（ランブック、ADR、wiki）と、法的な保持の対象となる記録（臨床記録、ケアの判断、財務の承認、情報ガバナンスの判断）を、明示的に区別してください。後者には、NHS Records Management Code of Practiceの保持スケジュールを適用し、何気ないwikiの削除が、法的に保持を求められていたものを破壊しないようにしてください。同様に、「念のため」何もかもを永遠にため込まないでください。過剰な保持は、それ自体がガバナンスとデータ保護のリスクです。

11. オンボーディングを、ドキュメンテーションのテストにする。 あらゆるオンボーディングを、ライブの監査として扱ってください。有能な新しいエンジニアや臨床家が、書かれた資料と少しのペアリングから生産的になれないなら、ドキュメンテーションは失敗しており、彼らがぶつかったギャップが、あなたのバックログです。新しく加わった人に、最初の貢献として、最初に混乱したことを直すよう依頼してください。これにより、オンボーディングは、一方向のコストから、知識の継続性のための継続的改善のループに変わります。

チームで話し合うための問い#

1. 最も重要な連携を理解している唯一の人が明日辞めたら、私たちが無防備になるまでどれだけかかるか。そして具体的に、何が分からなくなるか。 これは、バスファクターという抽象的な考えを、最も重要なシステムの具体的なストレステストに変えます。病理のフィード、シングルサインオンの設定、共有ケア記録の照合ロジックなど、実際の例を通して、その人なしに、誰がそれを運用し、変更し、復旧できるかを、誠実に問ってください。表に出すべき緊張は、最も深い知識が、通常、最も忙しく、最も信頼される個人にあり、納品の圧力が、その人が立ち止まってそれを書き下さないことを合理的にしていることです。本当に暗黙的で体系化しにくい知識と、誰も時間をとらなかったために、単にまだ捕捉されていない知識を区別してください。良い誠実な答えは、バスファクター1のシステムを声に出して名指しし、どのギャップが本物かを認め、「それはすべて人の頭の中にあり、それで構わない」という曖昧な安心ではなく、ペアリング、ドキュメンテーションのスプリント、クロストレーニングといった、コストを見積もった計画を出します。会話が心地よいなら、十分に具体的ではありません。

2. 何かを書き留めたとき、誰かがそれを見つけ、信頼し、最新に保つと、どうして分かるか。そして私たちのドキュメンテーションは、すでにどこで私たちに嘘をついているか。 古くなったドキュメンテーションは中立ではなく、安全が重要な場では、ストレスを受けたオペレーターを、積極的に誤った行動へ導きます。議論は、文書を持っていることと、人々が見つけ、信頼し、行動に移せる文書を持っていることの違いに向き合うべきです。それは、量ではなく、情報アーキテクチャ、所有、新しさの問題です。知識ベースが本物の構造を持っているか、誰もナビゲートしない広がりになっているか、そしてドキュメントが、最新に保たれるほど作業の近く（ドキュメント・アズ・コード）にあるか、誰も更新しない別のツールで漂流しているかを議論してください。各人に、最後に社内文書に頼ってそれが間違っていた時はいつか、それがどんなコストだったかを問ってください。強い答えは、古いと分かっている具体的なページを特定し、所有者とレビュー日を割り当て、最も重要な事実について唯一の情報源に合意し、加えるより多くを削除する意思があります。

3. 前回の深刻なインシデントの後、私たちの働き方は実際に何が変わったか。そして答えが「あまり変わっていない」なら、なぜレビューを続けているのか。 インシデント後レビューは一般的ですが、実践を変えるレビューはまれで、両者の間のギャップは、同じ失敗が再発する場所です。これは、教訓のプロセスが、本物のフィードバックループか、文書を生むだけで変化を生まない儀式かを試します。文化的な条件を誠実に探ってください。レビューは、非難がなければ真実を表に出すだけで、プロセスが罰するなら人々は本当の原因を隠すため、心理的安全性は、あれば良いものではなく前提条件です（トピック8.1 — チェンジマネジメント参照）。直近のいくつかのインシデントを見て、各行動が完了したか、再発を防いだかを辿ってください。良い答えは、過去のレビューが生んだ具体的な変更、つまり書き直されたランブック、新しいアラート、設計の修正を指し示し、記録されて静かに放棄された行動について率直で、そのループを閉じる計画を持ちます。

4. 私たちが保持しているもののうち、法的に保持を義務づけられた法定の記録はどれで、最新性のために管理する作業メモはどれか。そして私たちは、前者を削除せず、後者をため込んでいないと確信しているか。 医療・ケアの組織は、ほとんどのデジタルチームが、規則ではなく直感で扱う保持の義務を負い、どちらの方向の誤りも本物です。ケアの判断を記録していたと判明するwikiのページを何気なく削除すること、あるいは「念のため」何もかもを永遠にため込み、データ保護と見つけやすさの負債を作ること。議論は、NHS Records Management Code of Practiceの対象となる記録、つまり臨床記録、ケアと資金の判断、情報ガバナンスの裁定と、法的な保持ではなく新しさのために管理する、ランブックやADRのようなチームの知識の間に、明確な線を引かせるべきです。臨床安全のハザードがなぜ受容されたかを記録するADRのように、両方でありうる、厄介な中間のケースを表に出してください。緊張は、エンジニアが整頓され最新のドキュメンテーションに最適化し、ガバナンスが擁護できる保持に最適化し、二つの本能が反対方向に引くことです。誠実な答えは、誰が保持スケジュールを所有するか、境界がどこに引かれているか、そして特定の記録が、数年後に検視官、規制当局、情報公開請求によって求められたら何が起きるかを述べられます。

5. 私たちの働き方の何が、知識が新鮮なうちにドキュメンテーションを書かせているか。そして私たちはどこで、まだ善意と良い意図に頼っているか。 どのチームも、ドキュメンテーションが重要だと同意しますが、それを英雄的な努力ではなく、既定で起こす仕組みを持つチームははるかに少数です。この問いは、書き留めることが、仕事の流れに組み込まれているか、つまり、ランブックの項目やADRなしには「完了」を認めない完了の定義、変更と同じプルリクエストでレビューされるドキュメンテーション、図が記述する対象の隣にあるドキュメント・アズ・コード。それとも、納品の圧力が出荷を迫るとき、個人が立ち止まって書くことを選ぶのに依存しているかを探ります。インセンティブを誠実に検討してください。システムを6か月後に記憶から後追いで文書化することは、危険な不正確さが生まれる場所なので、価値はほぼ完全に、その瞬間に捕捉することにあります。直近のいくつかの変更を見て、ドキュメンテーションが、知識を持っていた人によってその時に書かれたのか、再構築する誰かによって後から付け足されたのかを問ってください。強い答えは、すでに整っている具体的な仕組みを指し示し、プロセスがまだ記憶と意志力に寄りかかっているギャップを名指しし、それを閉じる計画を持ちます。

6. どの文書も決して捉えない知識、つまり判断と「このトラストは退院を別の方法でコード化していると知っておく必要がある」をどう移すか。そしてそれは、契約者の契約が終わるたびに難しくなるか。 サービスを安全に保つものの多くは暗黙的です。直感、パターン認識、書き下されることに抵抗する、苦労して得た文脈であり、SECIモデルは、ドキュメンテーションだけでは、それを完全には表出化できないという注意喚起です。この問いは、wikiがその仕事をしてくれると想定するのではなく、ペアリング、シャドーイング、ティーチバックのセッション、実践コミュニティを通じて、その知識をどれだけ意図的に広げているかを問います。緊張が最も鋭いのは、契約者と複数のサプライヤーに頼るところで、捕捉が、最後の週に頼まれる好意ではなく、契約上と文化上の期待でない限り、彼らの最も深い知識は、あらゆる契約の終わりに出口から出て行きます。臨床安全、連携、データエンジニアリングといった自分たちの技芸に、確保された時間を持つ生きたギルドがあるか、それともチーム横断の学びが偶然にしか起きないかを議論してください。誠実な答えは、人から人への移転を必要とする本当に暗黙的な知識と、単にまだ捕捉されていない知識を区別し、願望ではなく、ペアリングの当番表、去りゆく契約者のための知識継続計画、活発な実践コミュニティといった、実際の実践を指し示せます。

実践例：医療・ケアの事例#

統合ケアシステム（ICS）が、三つの急性期トラスト、地域サービス、社会的ケアのケース管理システムからデータを引く、共有ケア記録を運営しています。連携は2年前に、主に一人の契約エンジニア「Dev」によって構築され、彼は、二つの記録が同じ人を指すかを決める照合ロジックのあらゆる癖を理解していました。Devの契約は6週間後に終わります。wikiはありますが、最後に実質的に更新されたのは、構築の間でした。

納品リードは、これをバスファクター1のリスクとして扱い、プログラムのリスク登録簿に、自分の名前を所有者として載せます。6週間かけて、彼女は小さな「知識継続」の取り組みに資金を出します。Devは毎朝二人の正規のエンジニアとペアを組み、別れのブレインダンプの代わりに、進めながら表出化します。Devが暗記している失敗モードのランブックを書き、照合ロジックが、なぜ特定の不一致を許容するかを説明するADRを書きます（一見いい加減に見える一つのルールは、元の臨床安全のケースで指摘された、既知の患者安全のハザードを避けるために存在することが判明します）。ドキュメントは、連携のコードと同じGitリポジトリに入り、プルリクエストでレビューされるので、バージョン管理され、最新です。

Devが去って2か月後、ある急性期トラストからのフィードが、夜間に重複した患者記録を生み始めます。Devに会ったことのないオンコールのエンジニアが、ランブックを開き、番号付きの手順に従い、各段階で期待される結果を確認し、1時間以内に正しい照合を復旧します。非難のないインシデント後レビューで、チームはトリガー（トラストがNHS番号をコード化する方法の上流での変更）を見つけ、それを監視アラートとランブックの更新に変えます。数日にわたる、高リスクの慌ただしい対応となり、本物の患者安全インシデントになっていたはずのものは、暗黙知が、それを持つ人がまだそこにいる間に形式知にされたため、文書化された1時間の復旧になりました。

セクター別の視点#

スタートアップ#

デジタルヘルスのスタートアップは、最も高いバスファクターのリスクと、それに対処する最小の余裕の中で生きています。少数のエンジニア、それぞれの頭の中にある深い知識、書くことより出荷を重んじる文化。実用的な動きは、ワークフローに組み込まれた、軽量で安価なドキュメンテーションです。リポジトリ内の短いMarkdownファイルとしてのADR、何かが最初に壊れたときに書かれるランブック、規模が習慣の形成を難しくする前に習慣が形成されるよう、初日からのドキュメント・アズ・コード。創業者は、あらゆるドキュメンテーションを「プロダクト・マーケット・フィットの後」まで延期したい誘惑に抵抗すべきです。臨床プロダクトでの停止、あるいはエビデンス不足による臨床安全やDTAC（Digital Technology Assessment Criteria）の評価の不合格は、存続に関わりうるからです。目標は、磨かれた知識ベースではなく、一人の退職が会社を沈められないようにすることです。

小規模事業者#

確立した小規模な提供者、つまり一般診療所、地域薬局、ケアホーム、単独拠点のクリニックは、大きなトラストと同じ臨床安全と記録保持の義務を負いながら、専任のITやナレッジマネジメントの機能を持たず、それを築く余裕もほとんどありません。ここでは、実践は徹底的に比例的でなければなりません。重要な少数のランブックのための、見つけられる一つの場所（臨床システムをどう復旧するか、共有ケア記録が失敗したとき誰に電話するか）、重要な知識が診療所の管理者や一人の長年勤める看護師にだけ存在しないよう、名前のある所有者の単純な取り決め、そして、法的に保持が求められる法定の記録と、そうでない作業メモの間の明確な線。深刻なリスクは、継続性を装ったバスファクター1です。すべてがどう設定されているかを知る人が、日々の運営も行っており、退職や長期の病気が、安全に不可欠なシステムを運用できる人を、誰も残さないことがありえます。システムがベンダーによって供給・ホストされているところでも、小規模な提供者は、自分のローカルな設定と回避策を書き留めるべきです。サプライヤーは、この組織が実際にプロダクトをどう使うかを文書化しないからです。

大企業#

大規模なNHSのトラスト、ICS、ヘルステックのサプライヤーは、逆の失敗に直面します。SharePoint、Confluence、ネットワークドライブ、メールに散らばった、過剰なドキュメンテーションで、信頼できる唯一の情報源も、十分な見つけやすさもありません。大企業の課題は、情報アーキテクチャ、所有、刈り込みです。各事実をどこでマスター管理するかを決め、所有者を割り当て、重複を廃止し、ナレッジマネジメントを、サービスマネジメントと変更管理につなげること。実践コミュニティは、ここで存在意義を示します。そうしなければ、それぞれが同じ教訓を苦労して学ぶ、何十ものチームにまたがって、パターンを広げるからです。管理すべきリスクは、契約者と複数のサプライヤーの多用です。捕捉が契約上と文化上の期待でない限り、知識は、あらゆる契約の終わりに出口から出て行きます。

政府#

国や地方の公的機関、つまりNHS England、DHSC、UKHSA、地方自治体は、法定の記録管理の義務、情報公開の義務、公的監査の精査のもとで運営されるため、ナレッジマネジメントは、一部は法と公的説明責任の問題です。サービス、資金、政策についての判断は、文書化され、定められた期間保持され、特別委員会、National Audit Officeのレビュー、公的調査のために、何年後でも見つけられなければなりません。主要な調査の最近の歴史は、拙い記録管理が、それ自体でスキャンダルになる様子を示しています。政府は、法定の記録（スケジュールによって保持され、処分される）と、作業上の知識（新しさのために管理される）の間の線を守り、NHS Records Management Code of Practiceを規律をもって適用しなければなりません。透明性が合言葉です。ドキュメンテーションは、いつか一般の人に読まれうるというのが、作業上の想定であるべきです。

よくある失敗パターン#

• ヒーローと、バスファクター1。 システムを「ただ知っている」個人を称えながら、その知識を広げる仕事に資金を出さない。彼らが不在になる日まで効率的に感じられ、その日、安全に不可欠なサービスを運用できる人が誰もいなくなる。
• 書いたきりのドキュメンテーション。 構築中に作られ、二度と触れられず、自信ありげな虚偽へと漂流する文書。古いドキュメントは、人々がそれに基づいて行動するため、ないよりも危険。
• wikiのごみ捨て場。 数千ページ、構造も、所有者も、レビュー日もなく、技術的には存在するが、見つけられも信頼もできない知識。量を価値と取り違えている。
• 作業から遠いドキュメント。 コーディング中に誰も開かない別のツールにあるドキュメンテーションで、現実から乖離することが保証されている。ドキュメント・アズ・コードが解毒剤。
• 教訓の演劇。 文書と、決して閉じられない行動のリストを生むだけのインシデント後レビューで、同じインシデントが再発する。プロセスは改善ではなく儀式になる。
• 記録とメモの混同。 法的に保持が求められたものを削除する、あるいは何もかもを永遠にため込み、データ保護と見つけやすさの負債を作る。どちらも、法定の記録とチームのドキュメンテーションを区別しないことに由来する。
• レビューの場での非難。 失敗の最も近くにいた人を罰するレビューで、全員に本当の原因を隠すよう教え、プロセスが依存する誠実さを破壊する。

成熟度モデル#

チェックリスト#

• すべての重要なシステムに、サービスマニュアル、最新のランブック、重要な判断のADRがある。
• ドキュメンテーションが完了の定義の一部で、変更と同じプルリクエストでレビューされる。
• 各ドメインに名前のある信頼できる唯一の情報源があり、既知の重複は削除またはリダイレクトされている。
• バスファクター1のシステムが、所有者と積極的なクロストレーニング計画とともにリスク登録簿にある。
• ランブックが、それを書かなかった人によって、演習か実際のインシデントでテストされている。
• インシデント後レビューが非難なしで、所有者がいて期限のある、閉じられる行動を生む。
• 知識ベースに、明確な構造、ページの所有者、レビュー日があり、古いページは刈り込まれている。
• チームをまたぐ技芸のための、時間が確保された活発な実践コミュニティが、少なくとも一つある。
• 法定の記録がチームのドキュメンテーションと区別され、正しい保持スケジュールで管理されている。
• 新しく加わった人が、最初の貢献として、最初にぶつかったドキュメンテーションのギャップを直すよう求められる。

主要な情報源#

• NHS England / NHSX, Records Management Code of Practice 2021 — 健康・ケアの記録に関する法定の保持スケジュールとライフサイクルの義務。
• GOV.UK Service Manual（Government Digital Service） — ドキュメンテーションとサービスの運用を含む、デジタルサービスの書き方と運営に関するガイダンス。
• NHS Digital Service Standard — 持続可能で、十分に文書化されたデジタルサービスを構築し維持するための期待。
• Michael Nygard, 「Documenting Architecture Decisions」（2011） — アーキテクチャ決定記録（ADR）の起源となるパターン。
• Google, Site Reliability Engineering — 非難のないインシデント後レビュー（ポストモーテム）、ランブック、運用上の属人リスクの低減。
• Etienne Wenger, Communities of Practice: Learning, Meaning, and Identity（1998） — 実践コミュニティに関する基礎的な文献。
• Nonaka & Takeuchi, The Knowledge-Creating Company（1995） — 暗黙知から形式知への知識変換のSECIモデル。
• Write the Docsコミュニティ — ドキュメント・アズ・コードと、ドキュメンテーションをプロダクトとして扱うことについての実務者のガイダンス。

参考文献#

1. Knowledge management — Wikipedia — https://en.wikipedia.org/wiki/Knowledge_management
2. Tacit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Tacit_knowledge
3. Explicit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Explicit_knowledge
4. SECI model of knowledge dimensions — Wikipedia — https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions
5. Bus factor — Wikipedia — https://en.wikipedia.org/wiki/Bus_factor
6. Runbook — Wikipedia — https://en.wikipedia.org/wiki/Runbook
7. Architectural decision — Wikipedia — https://en.wikipedia.org/wiki/Architectural_decision
8. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
9. Community of practice — Wikipedia — https://en.wikipedia.org/wiki/Community_of_practice
10. Records management — Wikipedia — https://en.wikipedia.org/wiki/Records_management
11. Information architecture — Wikipedia — https://en.wikipedia.org/wiki/Information_architecture
12. Postmortem documentation — Wikipedia — https://en.wikipedia.org/wiki/Postmortem_documentation
13. Onboarding — Wikipedia — https://en.wikipedia.org/wiki/Onboarding
14. Records Management Code of Practice 2021 — NHS England / NHSX — https://www.nhsx.nhs.uk/information-governance/guidance/records-management-code/
15. Service manual — Government Digital Service (GOV.UK) — https://www.gov.uk/service-manual
16. Documenting Architecture Decisions — Michael Nygard — https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
17. Site Reliability Engineering — Google — https://sre.google/books/
18. Write the Docs — docs-as-code guidance — https://www.writethedocs.org/guide/docs-as-code/