属人化解消をどう仕組み化するか——ナレッジの形式知化と再現性
「属人化はよくない」と分かっていて、マニュアルも作った。それなのに、半年後にはまた同じ人にしか聞けない状態に戻っている——という経験はないだろうか。
属人化対策の多くは、対策を「打った瞬間」で満足してしまう。ドキュメントを1回書く、引き継ぎ会を1回開く。だが属人化は一度の施策では解消されない。日々の業務が回り続ける限り、放っておけば知識はまた個人の中に偏っていく。必要なのは一度きりの対策ではなく、放っておいても形式知化が進む仕組みだ。
- 属人化リスクを数字で可視化する「バス係数」という考え方
- 一度きりの対策で終わらせない、仕組み化の4ステップ
- 「個人攻撃」と受け取られない伝え方の具体例
なぜ属人化対策は「打った瞬間」で終わるのか
属人化はなぜ起きる？ノウハウを組織の資産にする4つのアプローチで整理した通り、属人化の原因は短期的効率性の追求・育成コストの負担・時間的余裕の欠如といった構造的なものだ。この構造そのものは、ドキュメントを1回書いたところで変わらない。
だから対策の多くは「打った瞬間」がピークになる。あとは下降するだけだ。マニュアルは更新されなくなり、引き継ぎ会の内容は次の異動までに忘れられる。属人化対策を一度きりのプロジェクトとして扱う限り、この揺り戻しは避けられない。
あたま「マニュアルを作りました」で対策を終えてしまうと、半年後には元の状態に戻っています。作ることより、作り続ける仕組みの方が重要です。
属人化リスクを数字で見る——バス係数という考え方
対策が続かない理由のもう一つは、リスクが「感覚」でしか語られていないことにある。「あの業務、ちょっと属人化してるよね」という会話はよくあるが、それがどれだけ危険な状態なのかは誰も数字で示していない。
ソフトウェア開発の世界には「バス係数（Bus Factor）」という考え方がある。その業務・プロジェクトを止めるために、離脱・不在になる必要がある人数を示す指標だ。「その人が急にいなくなったら（バスに轢かれたら）どうなるか」という思考実験に由来する。
バス係数が1というのは、たった1人が抜けただけで業務が止まる状態を指す。最も危険な状態だ。値が大きいほど安全とされ、明確な業界標準はないものの、実務では「最低2〜3人が同じ業務を習得している状態」が一つの目安として語られる。
この指標が便利なのは、「なんとなく心配」という感覚を「あと何人育てば安全か」という具体的な行動目標に変換できる点にある。元々はソフトウェア工学の指標だが、システム障害復旧の目標時間（RTO/RPO）のような考え方と結びつければ、「この業務が止まったら何時間で支障が出るか」という形で一般業務にも応用しやすい。
仕組み化の4ステップ——記録・共有・評価・入れ替え
数字でリスクを可視化した後、実際にバス係数を上げていくには、次の4ステップを仕組みとして組み込む必要がある。単発の施策ではなく、日々の業務フローの中に埋め込む。
- 形式知化：本業を進める過程で、記録が自動的に残るようにする
- 共有：残った記録を、担当者以外も参照できる場所に置く
- 評価への組み込み：共有する行動そのものを評価制度に反映する
- ローテーション：定期的に担当を入れ替え、複数人が同じ業務を経験する機会を作る
この中で最初のハードルになるのが①の形式知化だ。「業務のついでに手順書を書いてください」という依頼は、たいてい後回しにされる。本業とは別の負担として認識される限り、記録は続かない。
「本業のついでに記録が残る」仕組みを作った話
研究現場でこの壁にぶつかったとき、筆者が実際に作ったのは、業務そのものにナレッジ蓄積の機能を組み込むという方法だった。
あたま研究データのグラフ作成を手伝うAIツールに、対話内容を自動で要約してwikiページ化する機能を組み込みました。研究者は「グラフを作ってほしい」とAIに依頼するだけで、本来の目的（グラフ作成）を達成できます。ただし、その過程でのやり取り——どんなデータをどう可視化したか、なぜその軸を選んだか——が、頼まれなくても自動的に記録として蓄積されていきます。
ここでのポイントは、「記録を残してください」と別途頼んでいない点にある。仕事の効率化そのものが目的で、データの蓄積はその副産物として設計されている。属人化対策を独立したタスクにすると必ず後回しにされるが、本業の道具に組み込んでしまえば、使うだけで形式知化が進む。
「記録のためのツール」ではなく「本業のためのツールに記録機能を足す」という順番が肝心だ。逆にすると、使われないツールが増えるだけになる。
「個人攻撃」と受け取られない伝え方
仕組みを作っても、それを導入する際の伝え方を誤ると、当事者には「あなたのやり方が問題だ」という個人攻撃として受け取られかねない。属人化対策がしばしば反発を招くのは、この伝え方に原因があることが多い。
筆者が意識しているのは、特定の誰かを名指しせず、リスクそのものを全員に共通する話として扱うことだ。
あたま「あなたが抜けたら困るから」ではなく、「どの人材もそれぞれの強みを持っているので、誰が抜けても組織にとって損失になる」という前提で話すようにしています。属人化対策は、特定の人の欠点を直す話ではなく、誰にでも起こりうるリスクに備える話です。
バス係数という数字も、この伝え方と相性がいい。「あなたのやり方に問題がある」ではなく「このチームのバス係数は現在1です」という中立的な事実として提示できるからだ。指摘の矛先が個人ではなく、チームの構造そのものに向く。
まとめ
属人化対策が続かないのは、リスクが感覚でしか語られず、対策が一度きりの施策で終わってしまうからだ。バス係数という考え方でリスクを数字に変え、本業のついでに記録が残る仕組みを作り、共有・評価・ローテーションまでを日々の業務フローに組み込む。そして、その仕組みを導入する際は、特定の個人ではなくチーム全体のリスクとして伝える。
一度きりの「マニュアル化プロジェクト」ではなく、放っておいても形式知化が進む仕組みへ——自分のチームでは、どのステップから手を付けられるだろうか。
あたまこの記事が役に立てば嬉しいです。よかったら他の記事も見てみてくださいね。
関連記事
コメント