はじめに
チームで開発していると、だいたい一度はこんな出来事、1度は経験したことがあるのではないでしょうか。
- 「それ、Aさんがまとめてくれてるところだから分からない」
- 「Aさんがいないとリリースできない…」
- 「前も同じエラー出た気がするけど、誰が直したっけ」
この状態になると、「属人化は悪だ」「なくそう」という流れになりがちです。
でも、属人化って本当に全部悪でしょうか。
属人化って、人がいる限りは切っては切れないものだから、無くそうとすると負荷が増えすぎる気もします。
結論から言うと、属人化そのものは悪じゃないと思っています。
悪いのは、手順化・仕様化できるのにしていない属人化 だと思います。
属人化をゼロにすることを目標にすると、現実的にはしんどいし、むしろチームが弱くなることもあります。
時間も無駄にかかってしまいますし、コスパが悪く結局は元通り属人化した状態に戻ることのほうが多いのではないでしょうか。
また、専門性や経験まで「属人化だから」と消しにいくのは、チームの武器を捨てるのと同じだからです。
この記事では、属人化を「良い属人化」と「悪い属人化」に分けて、何が問題で、どこを直せばチームが楽になるのかを整理してみたいと思います。
属人化の“良い/悪い”を分ける
良い属人化
良い属人化とは、複数の知識や経験が混じり合った結果生まれるため、全体共有することが難しいものです。
しかもそれが、単純な手順書にしづらいタイプのものです。
これはチームや個人の資産であり、当然ですが無理に消すべきではありませんし、無理に共有させるもの負荷が増えてしまいます。
特に、人に関連するものは常に変動するため、属人化せざるを得ないものでしょう。
例えば...
- 「メンバーの技術レベル・人となりを理解しタスクを割り振れる」
-> 個々の得意・不得意を把握していて、レビューやタスクの切り方を変えられる。
より具体例：細かいバグを量産しがちな人には“観点付きのToDo”を渡し、逆に設計が得意な人には“仕様の穴出し”を任せて、手戻りを減らす。
- 「仕様の“言外”を読める（業務理解の深さ）」
-> 仕様書に書かれていない“本当に困るポイント”を先回りできる。設計や開発状況、技術負債を総合的に鑑みて、読み取ることができる。
より具体例：ランキングを出したい」という要望に対して、同率・集計頻度・後からの修正（再集計）・DB負荷/キャッシュ・問い合わせ対応まで先回りして確認できる。
- 「やる or やらないの判断がすぐにできる」
-> 全体リソース、技術、ユーザーニーズなどを総合的に判断しながら、成果に直結しない部分を見抜いて、過剰設計や沼を避けられる。
より具体例：今の人員と期限とユーザー価値を見て、多言語化や権限の汎用設計は後回しにして、まず“利用が多い導線だけ”最短実装で出す判断ができる。
--
このような属人化は推奨すべきですし、
逆に言うと、このような属人化を発生させられる人材こそが、より優秀だと言わざるを得ない人だと思います。
そして、このような優秀な人材の複雑性のある属人化まで、資料化・手順化させようとすると負担が極端に増えてしまい、チームの生産性を下げる可能性まであると思います。
悪い属人化
悪い属人化とは、その人がいないと作業や判断が止まり、チームのスループットが落ちる状態です。
一定の範囲でルール・方法が決まっているかつ、変更頻度が多くない、変更範囲が広くないものなどが個人に依存してしまっていることです。
例えば...
- 「リリース手順が“人依存”」
-> 手順が口伝で、誰かがいないと本番リリースができない。
より具体例：「この順番じゃないと失敗する」が暗黙知で、担当者不在だと結局延期になる。
- 「障害対応が“記憶頼み”」
-> 前回の対応が残っていないので、同じ事故で毎回同じ苦労をする。
より具体例：アラートがなるたび、結局「前も直した人」に依頼する形になってしまう。
- 「仕様の解釈が“人の頭の中”」
-> 仕様がドキュメント化されておらず、解釈がその人基準になる。
より具体例：「このステータスの時は表示する/しない」が口頭で、実装者が変わるたびに挙動が揺れる。
- 「情報の所在がバラバラ」
-> 何を見ればいいかが決まっておらず、探すだけで時間が溶ける。
より具体例：過去の意思決定がSlackのDMや個人メモに散らばっていて、引き継ぎ時に再議論が発生する。
--
このような属人化があればすぐに改善を進めるべきですし、この属人化を発生させていると言う自負がある人は今すぐに行動を改めるべきだと考えます。
属人化をゼロにしない。“止まる理由”だけ潰す
大事なのは、属人化をなくすことではなく、チームが止まる理由をなくすことです。
良い属人化は、むしろチームや個人の強みなので積極的に残していい。
一方で悪い属人化は、「止まる」「怖い」「探せない」みたいな状態を作るので、ここだけ手当てするべきです。
この切り分けができると、話がすごく現実的になると思います。
- 専門性や勘所は尊重しつつ
- 手順・判断基準・復旧の“最低限”だけ共有して
- 「人がいないと1ミリも進まない」を減らす
これなら、属人化に対して「理想論」ではなく「実務の改善」として向き合えます。
なぜ“共有できない属人化”は生まれるのか
だいたい原因はこのへんに集約されそうな気がします。
- そもそも属人化を意識していない
- 忙しくて、書くタイミングがない
- 何を書けばいいか分からない
- 完璧にまとめようとして、結局書かない
個人の意識と、仕組みの問題になりがちです。
「共有しよう」という意思を全員が持ちつつ、続けられる形に落とす必要があります。
属人化しないためにやるべきこと
「全部共有しよう」とすると、破綻します。
続けるためには、“共有する範囲”を絞るのが一番効きます。
以下の３つを大事にするのが良さそうです。
- 意識：誰もが "悪い属人化" の意識を徹底すること
- 手順：属人化しないための手順 (フォーマット・格納場所) を用意しておくこと
- 基準：属人化を高い基準にしないこと
割とシンプルで、ただ簡単に属人化しない方法を決めるだけで問題は発生しないと思います。
おわりに
属人化は悪ではないと思います。
専門性や経験がある優秀な人材がいることは、チームにとって価値です。
でも、悪い属人化はチームを止めます。
本人も苦しいし、周りも動けなくなるはずです。
だから、属人化をゼロにするのではなく、まずは「悪い属人化」だけを見つけて、止まる理由を潰す、この方向のほうが、チームとして健全だと思っています。
もしあなたのチームでも「こういう属人化で困った」「こうやって改善した」みたいな話があれば、ぜひ教えてください！！
--
また、株式会社シンシアではたくさんのエンジニアや学生インターンを採用させていただき、一緒に働いています。
※ シンシアにおける働き方の様子はこちら
弊社には年間100人以上のエンジニアの方に応募いただき、技術面接を実施しております。
実務未経験のエンジニアも積極採用しております。
この記事が少しでも学びになったという方は、ぜひ wantedly のストーリーもご覧いただけるととても嬉しいです！