開発の属人化を見える化する。担当人数より代わりに実行できるかを見る

開発の属人化を見える化するとき、担当者の人数を数えるだけでは足りません。見るべきなのは、請求設定、リリース、データ復元といった業務ごとに、主担当以外の人が必要な情報と権限を得て、判断を含む一連の作業を完了できるかです。

僕なら、手順書や説明、二人分の担当名だけでは「代替実行可能」にしません。代替候補が安全な環境か管理された実務で作業し、停止条件、相談先、失敗時の戻し方まで確認して初めて、代わりを任せられると判定します。

ただし、すべての業務を同じ型で試すわけではありません。請求設定には承認経路、リリースにはロールバック、復元には復元後の確認が要ります。平時にどこまで確認できれば「任せられる」とするのかを業務別に決めることが、退職の話が出る前にできる属人化対策です。

開発の属人化は「業務」単位で見える化する

「開発が分かる人が二人いる」会社でも、請求先や支払い方法を変更できるのは一人だけ、ということがあります。反対に、担当者が一人でも、別の人が必要な権限を取得でき、確認済みの手順に沿って実行し、異常時に止めて相談できるなら、知識集中の危険は小さくできます。組織図や担当人数だけでは、この違いが見えません。

Googleの知識共有に関する解説は、重要情報を一人だけが利用できる状態を、ボトルネックになる単一障害点と説明しています。専門家が作業を抱えると、ほかの人は学べず、知識と責任が専門家へ蓄積します。2026年10月3日時点で確認した一般原則から、「その人しか完了できない業務は何か」を点検の起点にします。

業務名は、完了を判定できる粒度にします。「インフラ」や「バックエンド」では範囲が広すぎます。「本番へリリースする」「失敗したリリースを戻す」「バックアップから復元する」「請求先を変更する」なら、どこからどこまでを代替候補が行うのかが分かります。大きな領域名で一括りにすると、一部だけ経験した人を領域全体の代替者だと誤認しやすくなります。

文書の有無も出発点にすぎません。同じ解説では、文書は一対一の会話より広く共有できる一方、更新コストがあり、人の知識と相互補完するものだとされています。一つの共有方法では賄えません。「手順書あり」だけで点検を終えると、古い画面、暗黙の判断、取得できない権限が隠れます。

台帳には、代替候補が止まる理由まで記入する

次の項目は、出典の一般原則を自社の点検へ置き換えた僕の実務案で、公式資料所定の分類や義務ではありません。台帳は詳しいマニュアルにせず、経営者が未充足条件を読める索引にします。

• 対象：業務名、完了とみなす状態
• 人：主担当、代替候補、停止時のエスカレーション先
• 実行条件：手順の所在と最終確認、必要な権限・認証手段、直近の実行確認
• 失敗への備え：ロールバックまたは復旧条件
• 結果：判定、未充足条件、次に確認する人

この並びなら、「代替者なし」に加え、「候補者はいるが権限がない」「権限はあるが未実行」「異常時の判断先がない」を分けられます。経営者が決めるのは、どの未充足条件をいつ、誰の確認で解消するかです。

判定も三つに絞ります。「代替実行可能」は、代替候補の操作記録があり、停止条件と相談先、戻し方または復旧条件まで確認済みの状態です。「条件付き」は、手順や候補者はいるものの、実行確認、権限、判断条件のどれかが欠ける状態です。「代替不可」は、候補者がいないか、必要情報へ到達できず、主担当なしでは着手できない状態とします。

この判定方法は出典所定の等級ではなく、知識を実行へつなぐ考え方に基づく僕の提案です。Google SREのオンコール解説にある新チームの事例では、オンコール前に本番ジョブの操作、問題のあるリリースのロールバック、監視の利用、構成要素と依存関係の説明を練習し、デバッグや影響緩和もラボで実行しています。また、責任とエスカレーション条件を確認し、移管元のシフトを見た後、新チームを主担当、移管元をバックアップにする段階を踏んでいます。2026年10月3日時点の確認です。

請求設定・リリース・復元の記入例

三つの業務を同じ「手順書あり」で評価すると、判断の違いを落とします。次の記入例は出典の一般原則を自社向けに置き換えたもので、原典所定の分類・義務や特定製品の仕様ではありません。自社の契約、権限設計、環境に合わせて条件を置き換えてください。

請求設定では、操作に加えて、変更してよい条件の判断が要ります。承認する人と実行する人を台帳上で分け、代替候補がどこで承認を求めるのかを明記します。認証情報そのものは台帳に記載しません。正規の方法で必要な権限を取得できるかを確認対象にします。

リリースでは、公開手順と中止・ロールバック条件の両方が重要です。Google SREのプレイブックは、アラートの重大度と影響、デバッグ案、影響緩和と解決の行動を記します。本番環境が変われば詳細は古くなるため、チームで最低限の構造化項目を決めることも勧めています。2026年10月3日時点の考え方に照らすと、台帳には長い手順でなく、手順の所在と最終確認、停止条件を残すほうが更新漏れを発見しやすくなります。

復元では、「バックアップがある」と「別の人が復元できる」を分けます。Google Cloudの障害復旧テスト指針は、定期テストにリリースのロールバックとバックアップからの復元を含めています。外部依存関係を特定し、テスト前に手動ロールバック手順、必要なIAMロール、ポリシー、権限を確認するよう求めています。更新日は2024年12月30日で、2026年10月3日に確認しました。自社では、必要権限、依存先、復元後の確認を環境に合わせて具体化します。

「条件付き」を残したまま、主担当と代替候補を入れ替える

台帳を埋めた直後に、すべてを代替可能に見せる必要はありません。むしろ「条件付き」を残すことに意味があります。権限不足なら権限設計の確認、未実施なら安全な環境での操作、判断条件不明なら主担当との合意、という次の行動へつながるからです。未充足条件が空欄の「条件付き」は、保留の言い換えにすぎません。

実行確認は、主担当が横で全部操作する形では判定できません。代替候補が手順を読み、自分で操作と判断を進めます。安全な環境を用意できない業務では、承認済みの低リスクな変更を選び、主担当がバックアップとして見守ります。操作を引き取るのは、決めた停止条件に達したときです。完了後は、迷った箇所、実画面との差、使えなかった権限、相談した判断を台帳へ戻します。この進め方はGoogle SREの事例にあるシャドー、主担当、バックアップという一般原則を基にした実務提案で、公式の移管手順を義務づけるものではありません。

優先するのは、停止時に経営判断や顧客対応まで止まる業務です。技術的な難度順では、請求設定のような業務が漏れる可能性があります。影響は経営と技術の間で確認します。論点を経営者が決められる形へ直す役割は、経営と技術をつなぐ人がいないと、会議は決まらないでも整理しています。

台帳の更新者や判定者が空席なら、技術顧問や伴走支援、CTO代行で知見を補う選択肢もあります。ただし、作業も判断も外部へ移して新たな属人化を作ってはいけません。社内に残す決定と外部へ任せる範囲は、CTO代行に任せる技術の意思決定を踏まえて先に区切ります。

最初から全システムを棚卸しする必要はありません。請求設定、リリース、復元を一行ずつ書き、主担当以外がどこまで実行できるかを確認します。手順があっても権限がない、説明だけで未実行なら「条件付き」、主担当なしでは着手できないなら「代替不可」です。

未充足条件を一つ選び、代替候補を主担当、従来の主担当をバックアップにして確認します。担当人数では見えなかった属人化が、誰が、どの業務の、どの条件で止まるのかに変わります。そこまで見える化できれば、平時にも次に解消すべき知識集中を決められます。