属人化は避けるべきものと語られることが多いですが、すべての局面で同じ扱いをすると判断を誤ります。本記事では、なぜ属人化が発生するのか、どの段階で有効に働くのか、そしてどこで手放すべきかを整理します。新規開発やPoCの現場で迷いやすいポイントに絞って書いています。
立ち上げ期は共有より意思決定が速さを生む
新規開発の初期は、仕様や前提が流動的です。設計の前提が日単位で変わることも珍しくありません。この段階で役割分担や詳細なドキュメント整備を優先すると、共有のための説明や合意に時間が取られます。
その結果、開発の進行は安定しますが、試行回数が減ります。試行回数が減ると、正しい方向にたどり着くまでの時間が伸びます。
一方で、特定の個人が設計・実装・判断をまとめて担う形は、判断の往復が減ります。前提が揺れている状況では、この短縮がそのまま速度になります。属人化は、このフェーズでは速度を買う手段として機能します。
属人化が効く条件は責任の引き受けにある
ただし、属人化が機能する前提があります。負荷と評価をマネジメントが引き受けることです。
意思決定が集中すると、作業量だけでなく心理的な負荷も集中します。さらに、周囲から見えにくい判断が増えるため、評価も曖昧になりやすいです。
ここが整理されていない状態では、属人化は速度ではなく無理に変わります。短期的には進んで見えても、持続しません。属人化を戦術として使う場合は、負荷の偏りと評価の見え方を同時に扱う必要があります。
グロース期に入ると依存がボトルネックになる
機能が揃い、利用が増え始めると、開発の性質が変わります。変更の影響範囲が広がり、レビューや障害対応、仕様判断の頻度が上がります。
この段階でも属人化が残っていると、判断の待ち時間が増えます。最初は「この人がいるから速い」だった状態が、「この人がいないと止まる」に変わります。
ここで問題になるのは能力ではなく、依存の集中です。処理能力の高い個人でも、並列に対応できる量には限界があります。結果として、全体のスループットが下がります。
現場で起きやすい詰まり方のパターン
よく見られるのは、レビュー待ちが積み上がるケースです。設計の意図が共有されていないため、特定の個人しか判断できません。
また、障害対応でも同様の現象が起きます。原因の見当がつく人が限られるため、調査の初動が遅れます。
仕様変更も同じです。過去の判断の背景が共有されていないため、小さな変更でも確認に時間がかかります。
これらは個人の能力とは関係なく、情報の持ち方が偏っていることで起きます。属人化は速度を生みますが、同時に情報の偏在も生みます。
剥がすタイミングは依存の広がりで判断する
属人化を解消するタイミングは、人数や期間ではなく、依存の広がりで見ると判断しやすくなります。
レビューや判断が特定の人に集まり始めたか。障害対応の初動がその人待ちになっていないか。仕様変更のたびに確認が必要になっていないか。
こうした兆候が出てきた段階で、設計の意図や判断の基準を外に出していく必要があります。ドキュメント化やレビューの分散は、この段階で初めて意味を持ちます。早すぎるとコストが勝り、遅すぎると詰まりが発生します。
属人化は価値を下げるのではなく次に回す準備になる
属人化を解消することは、その人の価値を下げることではありません。むしろ、次の立ち上げや難所に移れる状態を作ります。
特定の領域に固定され続けると、組織全体として新しい挑戦に人を回せなくなります。属人化を剥がすことは、個人の知見を組織の資産に変換する作業でもあります。
まとめ：速度と持続性を切り替える前提を持つ
属人化は避けるべきかどうかではなく、いつ使い、いつ手放すかという視点で見るのがよかろうと思います。
立ち上げ期では速度を優先し、グロース期では持続性を優先する。この切り替えを前提として持てるかどうかが、開発の詰まりやすさに影響します。
計画を伴う属人化は選択ですが、計画のない属人化は後で調整が難しくなります。状況に応じて扱いを変える前提を持つと、現場は判断しやすくなります。
おわりに
X（旧Twitter）やBlueskyを中心に日々発信しております。
ご興味をお持ちいただけましたら、ぜひ弊社Webサイトや私のXもご覧いただけますと幸甚でございます。
https://www.tatsu-mi-systemsolution.jp/
https://x.com/itchie_tatsumi
https://bsky.app/profile/itchie-tatsumi.bsky.social
