属人化をどう解消し、学びをチームや組織の共有知にするか？

実践者の問い（pq-21）。取り込み済みの文献のうち 10 本から拾った 11 件の事例と知見にもとづく。ここに無い打ち手が存在しないという意味ではない。

結論（TL;DR）

属人化の解消や、学びの共有知化の打ち手を、条件をそろえて比べ、効果を確かめた文献は、今回読んだ範囲では見つかっていません。読めたのは、英国の政府機関のチーム、オープンソースのコミュニティ、事業者の部門が、自分たちの経験を書いたブログや議事録です。属人化の解消を目的にした記事は少なく、知識の引き継ぎや共有を、取り組みの副次的な効果として書いたものが中心です。いずれも筆者の自己評価で、記録は 11 件です。

知識を広げる手段としては、ペアプログラミングとモブプログラミングの例が多くあります。英国歳入関税庁の開発者向けポータルのチームは、関わる人が大きく変わるなかで、ペアプログラミングを続け、ペアを組み替えるようにしました。筆者は、質と知識の引き継ぎの両方に役立ったと書いています。英国政府デジタルサービスの二つのチームも、モブを使っています。一つは、新人が加わり新しいアプリを始める時期に始め、誰もが学べたと書きます。もう一つは、各自が書いて分かりにくくなったテストコードをモブで書き直し、全員が理解して合意した状態にできたと書きます。ほかに、新人が増えたチームの隔週の学習会と、見習いの開発者に経験者がペアになる進め方の例があります。いずれも、依存がどれだけ減ったかは測られていません。

引き継ぎが進まなかった例もあります。Kubernetes の広く使われたコントローラは、ごく少数の人が時間外に保守していました。後任は増えず、終了が告知されました。Wikimedia の検索チームの振り返りでは、基盤を作った人が別の部署に移りました。引き継ぎ先は見つからず、チームが保守を続けていました。Kubernetes の SIG Docs の共同チェアは、手順書があっても、リリースには経験者の知識が要り、担い手が代わると知識が消えうると見ています。一方、Wikimedia のツールでは、保守者を公募したところ、名乗り出た人がいました。共同保守の形で課題は閉じ、その後は書かれていません。

仕組みを立て直した例もあります。Red Hat の IT 部門は、所有を抱えたまま優先が移り、使われなくなった社内ツールを、社内公開と貢献の受け入れの決まりで立て直しました。筆者は、中核でない貢献者からの貢献の割合が 27% から 78% に増えたと書いています。数値は筆者の報告で、前後の条件は揃っていません。

特定の人にしかできなかった仕事を複数人に広げ、依存の減り方を追った報告は、この範囲にはありません。ペアやモブなどの手段を、導入の前後やほかのやり方と比べた報告も、見つかっていません。1 チームで得た学びを、組織の共有知にして続いたかを追った事例も、確かめられていません。

打ち手と事例

HMRC の開発者向けポータルのチームは、関わる人が大きく変わるなかでペアプログラミングを続け、知識の引き継ぎに役立ったと書いている（組み替えを忘れないよう壁にペアリング表を貼った） ［The Developer Hub is Live!（2018）］

• 状況: HMRC（英国の歳入関税庁）の開発者向けポータルは、外部の開発者が HMRC の API を使えるようにするサービスである。チームは三年のあいだに、デリバリーリード、アーキテクト、ビジネスアナリスト、開発者などの多くの人が関わり、事務所の移転やクラウドの乗り換えもあった。筆者は、これを累計の人数として挙げていて、関わる人が変わり続けたことを、知識の継続を考える背景として書いている。ビジネスアナリストの筆者は、ベータ版を終えた時点での教訓の一つとして、変化への対応を挙げている。
• やったこと: チームはペアプログラミングを続け、ペアを組み替えるようにした。ペアを組むのが好きな開発者もいれば、あまり好まない開発者もいる。そのため、意識して続ける努力が要るという。誰が最近だれとペアを組んだかが見えるように、ペアリング表（マトリクス）を壁に貼り、情報ラジエーターとした。あわせて、働き方や役立つ知識を書き留めるために Wiki を使っている。
• 起きたこと: 筆者は、ペアプログラミングがソフトウェアの質と、知識の引き継ぎの両方に役立ったと書いている。 Wiki は対面の会話の代わりにはならないが、新しく入った人が早く慣れるのに役立つとも書いている。一方で、Wiki は更新を忘れやすく、書いたことを読み返さないこともある。そのため、互いに規律を守るよう声をかけ合う必要があるという。ペアの組み替えが特定の人への仕事の偏りをどれだけ減らしたかを、調べた記述は無い（結果の記述なし）。
• 注意点: 一人の筆者による教訓の振り返りで、効果を測った記述は無い。筆者は属人化の解消を目的に挙げておらず、変化の多いチームでの知識の引き継ぎとして書いている。ペアリング表を貼ったことと、知識の引き継ぎがうまくいったことの因果は、確かめられていない。ペアを好まない人がいるという記述はあるが、その人たちにどう対応したかは書かれていない。政府機関の一つのチームの経験で、他の組織に当てはまるかは分からない。
• 根拠: 経験報告／単一チーム。文献: The Developer Hub is Live!（2018）。文献の種類: ブログ・実践者。位置: Lesson 1: Things change（ペアプログラミング、ペアリング表、Wiki の段落）。保存版: http://web.archive.org/web/20260515050711/https://lifeathmrc.blog.gov.uk/2018/10/18/the-developer-hub-is-live/。確認の根拠: 原典

GOV.UK の Custom Formats チームは、新人を迎えたのを機にモブプログラミングを始め、知識の共有が進んだと書いている ［Our top 12 mob programming tips and thoughts（2016）］

• 状況: GOV.UK の Custom Formats チームの開発者が書いた記事である。チームには経験の浅い開発者が二人入ったところで、新しいアプリをゼロから作る予定もあった。アジャイルコーチ（Woody Zuill）の訪問を受け、疑問を聞いたうえで、試す価値があると判断した。
• やったこと: 開発者が同じストーリーに、一台のコンピュータを囲んで同時に取り組んだ。一人が操作役になり、残りが指示役になる。最初は決まりが無かったが、のちに操作役を決まった間隔で交代し、休みも挟む構成に整えた。新人を同時にコードベースへ慣れさせる狙いがあった。
• 起きたこと: 筆者は、誰もがセッションで何かを学べると書いている。経験者が考え方を説明するので、新人へのメンタリングの機会にもなったという。最初は分からないことを見せるのをためらっていたが、経験の差を問わず、分からないと言いやすくなったと書いている。筆者は、一緒にストーリーに取り組むことで、次のストーリーを受け持つときや、メンバーが不在のときに、開発者がより多くの文脈を持てると書いている。速さの利点の節には、開発者が約束でセッションから抜けても、他の人が続けられたので作業が止まらなかった、という記述もある（筆者は速さの利点として書いているが、特定の人が抜けても止まらない点で、この悩みに関わる）。属人化の度合いを測ったり、実際に誰かが不在になった場面を挙げたりした記述は無い（結果の記述なし）。
• 注意点: チームの開発者による自己評価で、効果を測った記述は無い。不在時の継続や文脈の共有は、体験した利点として書かれているが、具体的な出来事や回数は書かれていない。同じ記事は、モブが全員に向くわけではなく、小さなストーリーや調査には向きにくいとも書いている。記事の題にあるコツの列挙は、チームの学びを助言の形にしたもので、この記録には含めていない。政府機関の一つのチームの経験で、他の組織に当てはまるかは分からない。
• 根拠: 経験報告／単一チーム。文献: Our top 12 mob programming tips and thoughts（2016）。文献の種類: ブログ・実践者。位置: Why we started mobbing / How we mob / 4 benefits of mobbing の 1（Our developers learn more）・2（Knowledge is shared）・3（We can move faster）。保存版: http://web.archive.org/web/20260420033708/https://technology.blog.gov.uk/2016/09/08/our-top-12-mob-programming-tips-and-thoughts/。確認の根拠: 原典

Digital Marketplace の開発者は、各自が書いて保守しにくくなったテストコードをモブで書き直し、全員が理解して合意した状態にできたと書いている ［Using mob programming to solve a problem（2016）］

• 状況: Digital Marketplace は、英国政府デジタルサービス（GDS）のサービスである。筆者はその開発者の一人である。 Digital Outcomes and Specialists の公開に向けた重い試験の時期に、利用者の操作を確かめるテストコードが、保守しにくく開発者にとって面倒なものになっていることに気づいた。筆者は、アプリ本体を作るのに長くかかり、テストコードを急いで書く誘惑があったと書いている。実際にそうなっていたかは、筆者の推測である。一人が書いた部分を次の人が受け継ぐとき、前の人の作業が、いつも分かるとは限らなかった。開発者はそれぞれ小さな変更を足し、共通のやり方を決めなかったので、コードは大きくなるほど分かりにくくなった。
• やったこと: チームはテストコードの書き直しを、モブプログラミングで進めた。一人が入力し、もう一人が進行役になり、残りが必要に応じて意見を出す。数分ごとに役割を交代し、嫌がる人に役割を押しつけないようにした。筆者は、ずっとモブで続ける予定ではなかったと書いている。ただ、集団で書き直せば、あとからプロジェクトに戻る開発者が、経緯と設計を理解できると考えた。
• 起きたこと: 筆者は、書き直しを最初は遅く感じたと書いている。進め方に慣れて方向が定まると、勢いがついたという。結果として、全員が理解し、合意したコードがまとまったという。問題の原因は、チームが始めた時点でプロジェクトの共通理解を持っていなかったことだと筆者は見ていて、最初から全員で取り組む方法が合っていたと書いている。コメント欄では、筆者が、コアのアプリのコードでも知識を広げるためにモブをしたと答えている。一方で、モブが常に効率的かは証明できておらず、普段は個人で書くことが標準だとも答えている。あとから入った人が書き直しの経緯を理解できたかは、書かれていない（結果の記述なし）。
• 注意点: チームの開発者による自己評価で、効果を測った記述は無い。筆者は属人化そのものではなく、各自が別々に書いて分かりにくくなったコードの立て直しとして書いている。コメント欄では、文書を残さなくなる点と、内向的な人に向くかが指摘された。筆者は、モブは任意参加で、普段は個人で書くことが多いと答えている。政府機関の一つのチームの経験で、他の組織に当てはまるかは分からない。
• 根拠: 経験報告／単一チーム。文献: Using mob programming to solve a problem（2016）。文献の種類: ブログ・実践者。位置: Testing shouldn’t be testing / Ready, steady, mob / Could we fix it? Yes, we could / Mobbing: another form of collaboration の各節と、筆者のコメント欄への返信。保存版: https://web.archive.org/web/20260309061815/https://gds.blog.gov.uk/2016/09/01/using-mob-programming-to-solve-a-problem/。確認の根拠: 原典

GOV.UK Verify の技術チームは、新人が増えたなかで定期的な学習会を開き、抜けていた知識の一部を埋める助けになったと書いている ［The technical team working together through group learning（2016）］

• 状況: GOV.UK Verify は、英国政府の本人確認サービスである。筆者はその技術チームの二人で、少し前の記事でモブプログラミングを書いたチームでもある。チームには数か月のあいだに多くの新人が入り、開発者と運用の担当者を合わせて大所帯になっていた。筆者は、これだけ大きいと全員と一緒に働く機会が得にくいと書いている。アジャイルの実践者（Woody Zuill）が、自分のチームは毎朝学ぶ時間を取っていると話したのが、きっかけである。
• やったこと: チームは隔週で半日を使い、全員で学ぶ時間を取るようにした。最初の二回は、暗号解読のパズルと、状態機械の実装を、モブの形で解いた。操作役と指示役を数分ごとに交代し、全員が順に回る。三回目は、参加者が議題を出して選ぶアンカンファレンスにした。開発者と運用の担当者が集まり、アーキテクチャ、メッセージの暗号と署名、インフラの道具の使い分け、リリースの流れなどを話した。新人のために、なぜ今のインフラやアーキテクチャになっているかの背景を話す回も含めた。
• 起きたこと: 筆者は、背景を話す回が、長く続いてきた進め方を見直す機会になり、全員が持つ知識の抜けの一部を埋める助けになったと書いている。普段は一緒に働かない開発者と運用の担当者が組めたことも、良かった点に挙げている。開発者の一人が紹介した道具の内容の一部を、若手向けの Unix の入門講座に使い始めているという。一方で、決め方が曖昧な状態機械の課題では、成果より進め方の議論が増えた。そのため、課題は明確なほうが向くと整理し、次回は小さな目標を積み上げる形にしたいと書いている。この会が特定の人への依存をどれだけ減らしたかを、測った記述は無い（結果の記述なし）。
• 注意点: チームの二人の筆者による自己評価で、効果を測った記述は無い。筆者は属人化の解消を目的に挙げておらず、新人が増えたチームの知識の底上げと、チーム内の交流として書いている。学習会で得た知識が、のちの仕事で実際に使われたかは書かれていない。政府機関の一つのチームの経験で、他の組織に当てはまるかは分からない。
• 根拠: 経験報告／単一チーム。文献: The technical team working together through group learning（2016）。文献の種類: ブログ・実践者。位置: The first two group learning sessions / A technical team unconference / Unconference summary and findings / Feedback from the team の各節。保存版: https://web.archive.org/web/20260511145159/https://identityassurance.blog.gov.uk/2016/09/16/the-technical-team-working-together-through-group-learning/。確認の根拠: 原典

Kubernetes の SIG Docs は、リリース担当が手順書を改善し続け、貢献者の一人を新しいチェアに迎えたと書いている。筆者は、閉じた知識が減っていると見ている ［Reviewing 2019 in Docs（2020）］

• 状況: SIG Docs は、Kubernetes の文書を扱うコミュニティの作業グループである。筆者は共同チェアの一人で、前年を振り返る記事を書いている。この記事によると、チェアの交代が短い期間に続いていた。四半期ごとのリリースには、文書の側の作業があり、リリースの担当は回ごとに入れ替わる。
• やったこと: リリースの担当とそのチームが、回を重ねるごとに文書のリリース手順書を少しずつ直していた。筆者は、各回が前の回よりよい支えを次の担当に残す習慣が定着していると書いている。新しいチェアには、一年ほど文書に貢献し、あるリリースの文書担当を務めた人を迎えた。
• 起きたこと: 筆者は、手順書の改善を重ねたことで、前年よりリリースの文書の側が良くなったと書いている。さらに、手順書の改善は文書を良くし、閉じた知識を減らしている、と筆者は見ている。これは 2020 年の見通しを述べる節の文である。チェアの交代は円満だったが、入れ替わりが短い期間に多く、後任の育成に時間がかかると書いている。手順書の改善が属人化をどの程度減らしたかを、測った記述は無い（結果の記述なし）。
• 注意点: 筆者はチェアの一人であり、自分たちの活動の振り返りである。手順書の改善と閉じた知識の減少の関係は、筆者の見立てで、確かめられていない。引用した文は、2020 年の見通しを述べる節にある。筆者はその節で、予測の一部は外れるだろうと断っていて、観察された効果の測定ではない。この記事は、人手が足りない問題を訴えることが主な目的で、改善の事例は背景として書かれている。コミュニティの話で、組織の値は最も近いものを当てた。
• 根拠: 経験報告／複数チーム。文献: Reviewing 2019 in Docs（2020）。文献の種類: ブログ・実践者。位置: The good の節（リリースの文書と、新しいチェアの段落）と Effects in 2020 の Release support remains strong の項。保存版: https://web.archive.org/web/20261007134449/https://kubernetes.io/blog/2020/01/21/reviewing-2019-in-docs/。確認の根拠: 原典
• 原文: “This mostly takes the form of iterative improvements to the docs release playbook, producing better documentation and reducing siloed knowledge.”

検索チームが、ログ基盤を作った人が別の部署へ移ったあとも保守を続けていて、引き継ぎ先が見つからないことをふりかえりで話した ［Wikimedia Discovery/Meetings/Search retrospective 2017-03-28（2017）］

• 状況: Wikimedia の Discovery 部門の検索チームは、検索のプロダクトを作るチームである。そのチームが、ログを集めて調べる基盤（ELK の構成）を持っていた。この基盤は、ログを一つずつ探す手間を省くために、別の技術者が作ったものだった。その技術者は、別のチームや役職へ移り、その職務に合わなくなった。基盤の保守は、検索チームに残った。検索チームの技術者は、検索エンジンの更新に合わせてこの基盤を動かすために、直近の二週間の作業時間の少なくとも半分を使ったと述べた。別の参加者は、基盤には専任の担当者が要ると述べ、別の発言で、脆いとも述べた。議題としては、技術的には筋が通るが、製品チームが基盤を持つのは変で範囲外に感じる、という項目が票を集めた。
• やったこと: チームは、ふりかえりで、この悩みを投票で話題に選んだ。ある参加者は、運用チームが持つべきだと述べた。専任の担当者の採用を求める話があるらしい、という伝聞も出た。求めるチームについては、運用だろうかという質問が出ただけで、答えは書かれていない。議論の流れは、引き継ぎ先がないので、誰も引き取らない間は検索チームが持つ、という発言に落ち着いた。合意や行動項目としては記録されていない。参加者の一人は、誰も引き取らない仕事が回される「ホットポテト」の状態が一般に起きている、と述べた。
• 起きたこと: 結果の記述なし。 この議事録の行動項目には、基盤の引き継ぎに関するものがない。その後に誰かが引き取ったか、検索チームの負担がどう変わったかは、この資料には書かれていない（結果の記述なし）。
• 注意点: 振り返りの議事録で、当事者が自分たちの状況を話した記録である。基盤を作った人が離れたあとに、保守が誰の仕事か決まらないまま残った例で、解消した例ではない。属人化への対処を試した記録ではなく、担当者の不在で引き取り手がいない状態が話題になっただけである。この記録の relation は option で、状況の材料として扱う。運用チームの側の見方は、検索チームの参加者を通した伝聞しかない。時間の割合などの数値は、参加者の発言であり、記録として測ったものではない。一つの部門の一つの基盤の話で、他の組織に当てはまるかは書かれていない。
• 根拠: 経験報告／複数チーム。文献: Wikimedia Discovery/Meetings/Search retrospective 2017-03-28（2017）。文献の種類: ウェブページ・実践者。位置: 節 Technology と節 Discussion（Logstash を製品チームが持つことへの問いと、その議論）、節 Action items。保存版: https://web.archive.org/web/20240619134223/https://www.mediawiki.org/wiki/Wikimedia_Discovery/Meetings/Search_retrospective_2017-03-28。確認の根拠: 原典
• 原文: “There is nobody to hand it off to.”

Kubernetes の広く使われた Ingress NGINX は、保守を担う人が増えないまま終了が告知された（告知であり、検証された報告ではない） ［Ingress NGINX Retirement（2025）］

• 状況: Ingress NGINX は、Kubernetes のクラスタに入ってくる通信を振り分けるコントローラである。 Kubernetes の初期に、API の実装例として作られた。機能の幅と柔軟さ、特定のクラウドに縛られないことから広く使われ、多くのホスト型の基盤や利用者のクラスタに入っていた。記事の筆者は Kubernetes のセキュリティ対応委員会の一員で、SIG Network とともに終了を告知している。
• やったこと: 筆者は、このプロジェクトが長年、足りないか、ぎりぎりの保守体制で続いてきたと書いている。開発をするのは、ごく少数の人だけで、仕事の後や週末の自分の時間を使っていたという。前年に保守者が終了の方針を示し、後継のコントローラを作る計画を出したが、手伝う人は増えなかったと書いている。 SIG Network と委員会は、支援を探す努力を尽くしたうえで、保守を終える判断をした。終了後は、リリースも不具合の修正も脆弱性への対応も行わず、リポジトリは読み取り専用になる。
• 起きたこと: 筆者は、人気があっても保守の担い手が増えず、保守を続けられなくなったと書いている。既存の導入先は壊れず、配布物も残るが、新しい修正は出なくなる。利用者には、別の仕組みへの移行を勧めている。属人化を事前にどう減らせたかの記述は無く、依存を減らせなかった結果として終了に至った経緯だけが書かれている。
• 注意点: 告知であり、検証された報告ではない。保守が難しくなった背景として、機能の幅・技術的負債・セキュリティ上の問題が挙げられているが、保守者が増えなかった理由は書かれていない。属人化だけの結果とは言えない。 relation は option にした。依存を減らせなかったときに何が起きたかの材料で、悩みの前提に反する事例ではない。後継の計画に人が集まらなかったことは書かれているが、保守者を増やすための具体的な働きかけの中身は書かれていない。オープンソースのプロジェクトの話で、スクラムチームにそのまま当てはまるとは限らない。組織の値は最も近いものを当てたもので、実際には一つのプロジェクトの話である。
• 根拠: 経験報告／大規模な組織。文献: Ingress NGINX Retirement: What You Need to Know（2025）。文献の種類: ブログ・実践者。位置: History and Challenges の節（保守体制の段落）と Current State and Next Steps の節。保存版: https://web.archive.org/web/20260929104525/https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/。確認の根拠: 原典
• 原文: “Despite the project’s popularity among users, Ingress NGINX has always struggled with insufficient or barely-sufficient maintainership.”

保守に苦労していたツールの保守者を課題管理で公募し、名乗り出た人が現れて、共同で保守する形で閉じた ［T376072 The EditGroups tool needs new maintainer(s)（2024）］

• 状況: EditGroups は、Wikidata と Wikimedia Commons で、ボットによる編集のまとまりを取り消すために使われるツールである。保守していた開発者は、保守に苦労していると書いた。不具合の報告がしばらく残り、ツールが動かないと、コミュニティの取り消しの作業が重くなるという。ツールには、運用で気を付けることが残っていた。作業の担い手が強制終了されて取り消しが途中で止まる問題や、他の wiki へ広げるための取得方式の移行などである。
• やったこと: 開発者は、課題管理に「新しい保守者が必要」という課題を立てて、手を貸してくれる人を公募した。ツールのテストが厚く、文書も整っていることを、書き添えた。残っている問題の一覧も、コメントで示した。最初の応募までは間が空いた。応募のあと、開発者は、メールで連絡して、コードを一緒に読む通話をする案を示した。通話では、小さな変更を実際に行い、デプロイまでできることを確かめる、という段取りだった。その後、別の関心のある人が名乗り出て、関心のある人たちと一緒に保守してよいと書いた。開発者は課題を解決済みにして閉じた。
• 起きたこと: 課題は、協力者が現れた形で「解決済み」として閉じられた。その後、共同の保守が続いたか、取り消しの作業の重さが減ったかは、この課題には書かれていない。最初に応募した人が、実際にコードの案内を受けて保守に加わったかも、書かれていない。
• 注意点: 課題管理の議論の記録で、保守者本人の自己申告にもとづく。「解決済み」は、名乗り出た人が現れたという意味で、引き継ぎが完了して運用が安定したことを示すものではない。公募が実を結んだ要因は、書かれていない。テストや文書の整備が応募の後押しになったかは、確かめられていない。保守者が一人だったとは明記されていない。一つのツールの例で、他のツールに当てはまるかは書かれていない。共同保守に至った経過の記録であり、属人化を計画的に解消した例ではない。
• 根拠: 経験報告／大規模な組織。文献: T376072 The EditGroups tool needs new maintainer(s)（2024）。文献の種類: ウェブページ・実践者。位置: タスク T376072 の説明と、コメント（2025 年 2 月の応募と保守者の返信、同年 5 月の共同保守の申し出と、課題を解決済みにしたとき）。保存版: https://web.archive.org/web/20260615030909/https://phabricator.wikimedia.org/T376072。確認の根拠: 原典
• 原文: “would welcome help from other maintainers”

使われなくなった社内の基盤ツールを、別の道具に乗り換えたうえで、社内公開と貢献の受け入れの決まりで育て直し、利用者が開発に加わる形に変えた ［How inner sourcing saved our IT department（2018）］

• 状況: Red Hat の IT 部門では、クラウド基盤の整備チームが、AWS 上の基盤を同じやり方で用意する標準の道具を作った。別の運用チームが、その道具を使って基盤を用意した。道具は初めの要件を満たしたが、使う技術者のどのチームも、使いにくいと感じた。道具のコードと必要なデータは、多くの人が入りにくいリポジトリに置かれていた。変更を受け付ける標準の手順はなく、文書も乏しかった。整備チームは、別の仕事へ優先を移したが、道具の所有は手放さなかった。そのため、不具合の修正や改善が遅れた。やがて多くの技術者が使うのを拒み、基盤を用意する仕事が、ごく少数の技術者に集まった。筆者は、この部門の技術者である。筆者は、根にあったのは、みんなで共有の道具を育てる場を作れなかったことだと振り返っている。
• やったこと: 部門は、関係するチームを全部呼ぶ緊急の会合を開いた。意見は割れ、その場では決まらなかった。そこで、異なる案の支持者が、期限を決めてチームをまたいで試作を作り、共同体が見比べることにした。選ばれたのは、Ansible を使った道具で、のちに Ansicloud と呼ばれた。その後、数か月は少数の技術者が育てたが、アクセスの手続きが古く、人によって方向もずれた。必須と望ましい目標の一覧を作り、課題の記録を公開した。社内の誰でもコードを読めて複製できるようにし、信頼できる貢献者の権限も取りやすくした。さらに、事業上の責任者と、受け入れを決める中核の貢献者の集まりを決めた。道具の目的と使い方の README と、貢献の仕方と受け入れの条件を書いた文書を用意し、貢献を検証する継続的な試験の仕組みも作り始めた。
• 起きたこと: 筆者は、閉じた開発から社内公開の開発への移行で、数えられる改善があったと書く。中核でない貢献者からの貢献の割合は、27% から 78% に増えたと書き、利用者が道具の開発を進めていると述べる。ほかに、一週間あたりの変更の数と貢献者の数も増えたと書く。新しいサービスの用意の速さの改善は、新しい道具に乗り換えた後の成果として、別に書かれている。
• 注意点: 当事者が自分の部門のことを書いた自己申告の記事で、筆者の所属する Red Hat の運営する媒体に載っている。数値は筆者の報告で、前後の比較の条件（期間、人員、道具の成熟度）は揃えられていない。改善を社内公開の仕組みだけに帰せない。共通の目標、試作の合意、新しい道具の選定が並行して進んでいる。属人化の解消を目的にした記事ではなく、閉じた開発から社内公開の開発への移行として書かれている。仕組みのあとも、受け入れを決める中核の集まりと責任者は残り、所有が全くなくなったわけではない。この仕組みがその後も続いたかは書かれていない。一つの組織の一つの道具の話で、他の組織に当てはまるかは書かれていない。
• 根拠: 経験報告／大規模な組織。文献: How inner sourcing saved our IT department（2018）。文献の種類: ブログ・実践者。位置: 節 The challenge（所有を手放さないまま優先が移った記述）、節 Crisis point、節 Returning to openness、節 Why it matters。保存版: https://web.archive.org/web/20260213225331/https://opensource.com/open-organization/18/1/open-orgs-and-inner-source-it。確認の根拠: 原典
• 原文: “The percentage of contributions from non-core committers has grown from 27% to 78%; the users of the toolset are driving its development.”

DWP の技術部門は、見習いの開発者に経験者をペアにつける進め方を標準にし、経験者同士のペアでも学び合えたと語っている ［DWP pair programming in action（2015）］

• 状況: DWP（英国の労働年金省）の技術部門は、増やしたい開発者の数に対して、人手が足りなかった。話し手の技術部門の担当者は、契約の開発者は数に限りがあり、正社員を採るだけでは足りないと語っている。そこで開発の育成拠点を作り、学校を出たばかりの人を見習いとして迎え、数か月の集中的な研修のあとに、各案件へ送り出していた。動画の書き起こしを載せたブログで、話し手は後に退職している。
• やったこと: 話し手は、研修を通る人ごとに、経験のある開発者がペアになる必要があると話している。話し手は、ペアプログラミングを標準の進め方だと説明している。経験者同士を組ませても、うまくいくと話している。
• 起きたこと: 話し手は、見習いとのペアがうまくいっていると語っている。経験者同士でも、互いに学び、理由を問い合うので、うまくいくという。最初に試した人は、たいていよい経験だと感じて続けるとも語っている。ブログの冒頭には、話し手の退職後もペアプログラミングの活動が続いているという注記がある。属人化や知識の偏りが減ったかを、測った記述は無い（結果の記述なし）。
• 注意点: 話し手の自己評価を載せた短い書き起こしで、効果を測った記述は無い。話し手は属人化の解消ではなく、見習いの育成と人手の確保を目的に語っている。見習いを毎年迎えていると話しているが、そのうち何人にペアがついたか、どの案件に広がったか、どんな工夫で続いたかは書かれていない。政府機関の一つの部門の経験で、他の組織に当てはまるかは分からない。
• 根拠: 経験報告／大規模な組織。文献: DWP pair programming in action（2015）。文献の種類: ブログ・実践者。位置: ページ冒頭の注記（話し手の退職後も活動が続く）と、動画の書き起こし本文（見習いと経験者のペア、経験者同士のペア）。保存版: https://web.archive.org/web/20260517235024/https://dwpdigital.blog.gov.uk/2015/11/19/dwp-pair-programming-in-action/。確認の根拠: 原典

前提に反する事例

Kubernetes の SIG Docs の共同チェアは、手順書があってもリリースには経験者の支えが要り、担い手が代わると重要な知識が消えうると見ている ［Reviewing 2019 in Docs（2020）］

• 状況: SIG Docs では、チェアの交代が短い期間に続いていた。チェアの役割は、文書の作成と生成、情報設計、翻訳、リリースの運営、サイトの開発、CI、コミュニティの運営など、広い分野の知識を要する。筆者はこの状況について、複数の人がいないと続かない役割だと書いている。
• やったこと: 筆者は、現状の観察と、当時の状況が続いたら起こりそうな影響の予測を書いている。現状の観察として、手順書が整っていても、各リリースは新しい形で壊れ、診断には慣れた人の知識が要るという。予測として、担い手が役割や仕事を変えると、特定の知識を持つ人に相談できなくなることを挙げている。具体例として、リファレンスの生成とチェアの運営を挙げている。対策として筆者が求めているのは、専任の技術文書の書き手を雇うことである。
• 起きたこと: 結果の記述なし。 各リリースに経験者の知識が要るという部分は現状の観察で、知識が消えるという部分は筆者の予測であり、起きたことの報告ではない（結果の記述なし）。筆者は、手順書が整っている現時点でも、毎回のリリースにチェアなどの経験者の支えが要ると書いている。
• 注意点: 筆者自身が、予測の一部は間違っているだろうと断っている。属人化の解消策を試した結果ではなく、リスクの見立てである。筆者の主張の中心は人員の確保で、知識の共有の工夫そのものではない。コミュニティの話で、組織の値は最も近いものを当てた。
• 根拠: 経験報告／複数チーム。文献: Reviewing 2019 in Docs（2020）。文献の種類: ブログ・実践者。位置: The not so good の節（チェアの交代の段落）と Effects in 2020 の節（Current levels of function aren’t self-sustaining と Critical knowledge vanishes の項）。保存版: https://web.archive.org/web/20261007134449/https://kubernetes.io/blog/2020/01/21/reviewing-2019-in-docs/。確認の根拠: 原典
• 原文: “Without fail, each release breaks in new and unexpected ways, and it requires familiarity and expertise to diagnose and resolve.”

調査から分かっていること

今回読んだ範囲では、見つかっていない。

探した範囲の文献には見つからなかったこと

次のことは、この問いのために探した範囲の文献には見つかりませんでした。「研究が無い」という意味ではありません。

• 特定の人にしかできなかった仕事を、複数人ができるようにした過程と、その後の依存の減り方を、観察や記録で追った事例。（探した範囲: 収集ラウンド 3 回・読んだ文献 105 本）
• ペア・モブ・Wiki・当番などの知識共有の手段を、導入の前後やほかのやり方と比べ、知識の引き継ぎや不在時の継続への効果を確かめた報告。（探した範囲: 収集ラウンド 3 回・読んだ文献 105 本）
• 1 チームで得た学びを、ほかのチームや組織の共有知にした事例と、その仕組みが続いたかを追った報告。（探した範囲: 収集ラウンド 3 回・読んだ文献 105 本）

出典一覧

文献	年	ライセンス	記録の数
DWP pair programming in action	2015	Open Government Licence v3.0	1
Using mob programming to solve a problem	2016	Open Government Licence v3.0	1
Our top 12 mob programming tips and thoughts	2016	Open Government Licence v3.0	1
The Developer Hub is Live!	2018	Open Government Licence v3.0	1
The technical team working together through group learning	2016	Open Government Licence v3.0	1
Ingress NGINX Retirement: What You Need to Know	2025	CC BY 4.0	1
Reviewing 2019 in Docs	2020	CC BY 4.0	2
Wikimedia Discovery/Meetings/Search retrospective 2017-03-28	2017	CC BY-SA 4.0	1
How inner sourcing saved our IT department	2018	CC BY-SA 4.0	1
T376072 The EditGroups tool needs new maintainer(s)	2024	CC BY-SA 4.0	1

Contains public sector information licensed under the Open Government Licence v3.0.

---

🔍 妥当性検証レポート（クリックして展開）

• 総合判定: ✅ 合格 (スコア: 100/100)
• 評価の前提: 結論（TL;DR）を、このページに載せた事例と知見だけに照らして評価した
• 形式論理検証: PASS
• LLM批判的評価（agy: gemini-3.8-flash-high）: Faithfulness 5.0/5, Relevance 5.0/5

評価コメント:

• Faithfulness（忠実性: 5/5）: 前提コンテキストに含まれる11件の事例（ペアプログラミング、モブプログラミング、定期的な学習会、手順書の継続的改善、引き継ぎの失敗・放置、プロジェクトの終了告知、ツールの公募、社内公開と貢献ルールの整備など）を正確に踏まえています。また、各事例における「効果を客観的に測定した記述がないこと」「当事者の自己評価にとどまること」「属人化解消そのものを主目的にしていないこと」といった注意点・限界事項も漏れなく反映されており、コンテキスト外の俗説や根拠のない断定は一切見られません。 - Relevance（関連性: 5/5）: 「属人化をどう解消し、学びを共有知にするか」という問いに対し、コンテキストから読み取れる実践的なアプローチ（ペアプロ/モブプロ、学習会、インナーソース化など）を整理して提示しています。同時に、引き継ぎが進まなかった失敗事例や「手順書があっても経験者が不在になれば知識が失われうる」という前提に反する事例も対置し、安易な解決策を断定せずにエビデンスの現状と限界を論理的に示しており、質問の核心に極めて的確に答えています。

---

関連する用語

• ペアプログラミング
• モブプログラミング
• ナレッジマネジメント
• クロスファンクショナル