ひとりエンジニア体制の属人化を減らす進め方
「うちのエンジニア、来月から体調不良で1ヶ月休みたいと言っている」「唯一の開発者と急に連絡が取れなくなった」——ひとりのエンジニアがプロダクトの全部を見ている体制で、私たちはこうした相談を受けることがあります。その場になって初めて、「その人が抜けたら誰も本番環境を触れない」という事実に気づくケースがほとんどです。
この記事では、ひとりエンジニア体制の属人化を、経営リスクとして具体的に把握する方法と、いきなり2人目を採用しなくても現実的に進められる対策を整理します。
「その人が抜けたら何が止まるか」を具体化する
属人化リスクは抽象的に語られがちですが、実際に経営判断が必要になるのは「その人が1ヶ月不在になったら、業務のどこが止まるか」という具体的な問いです。以下を棚卸しできているか確認してください。
- 本番障害が起きたとき、誰が対応できるか: そのエンジニア以外に、AWS/GCPのコンソールにログインでき、デプロイの手順を知っている人間が社内にいるか
- アクセス権限の所在: 本番サーバー、GitHub Organization、ドメイン・DNS、決済・監視系SaaSのアカウントが、そのエンジニア個人の名義になっていないか。個人アカウントに紐づいている場合、連絡が取れなくなった瞬間にアクセス不能になる
- 進行中の開発の状態: 未完成のブランチ、設計判断が固まっていない機能、なぜその実装を選んだかの理由。これらはコードに残らず、その人の頭の中にしかないことが多い
- 顧客・取引先とのやり取り: 技術的な問い合わせ窓口をそのエンジニアが一手に引き受けている場合、不在中に顧客対応自体が止まる
この4点のうち1つでも「その人以外に分からない」状態なら、休職・退職が起きた瞬間に開発が数週間単位で完全停止するリスクを抱えています。実際に退職が起きてしまった後の対処についてはCTO退職後もプロダクト開発を止めない引き継ぎ方で詳しく解説していますが、本記事はまだ何も起きていない今のうちに、リスクを減らすための内容です。
なぜ「いきなり2人目採用」が現実的でないか
属人化の解決策として真っ先に思いつくのが「エンジニアをもう1人採用する」ことですが、これには構造的な難しさがあります。
- 採用に3〜6ヶ月かかる: 母集団形成から内定・入社まで、良い候補者ほど時間がかかる。その間、属人化リスクは放置される
- オンボーディングにさらに数ヶ月かかる: 採用できても、ドキュメントが薄いコードベースを1人で読み解いて独り立ちするまでには、既存エンジニアの時間を相応に割く必要がある。「属人化を解消するための採用」が「既存エンジニアの負荷を一時的に増やす」という逆説が起きる
- 正社員1人の固定費は重い: 経験のあるエンジニアの採用は年収水準も高く、属人化リスクの解消だけを目的に、この固定費を確定させる意思決定は経営として重い
- 採用してもリスクがゼロにならない: 2人体制でも、片方がすべての領域を1人で抱えている状態(単に「ひとりエンジニア」が「主担当と名ばかりの副担当」になっただけ)は珍しくない
つまり「2人目採用」は正しい解の1つですが、時間もコストもかかる上に、それ単体では属人化を解消しないため、採用と並行して別の手段で穴を埋める必要があります。
属人化を減らす現実的な手段
いきなり体制を厚くできなくても、今のエンジニアが1人のままでも進められる対策があります。
ドキュメント化は「全部」でなく「止まったら困る順」
「ドキュメントを整備しよう」は総論として正しくても、実務では後回しにされ続けます。全体を網羅しようとせず、優先順位をつけて着手するのが現実的です。
- 本番障害の一次対応手順: 誰が・どこを見て・何をすれば復旧できるか。これが無いと、不在中に障害が起きた場合に打つ手がなくなる
- デプロイ手順: 属人的な手作業(SSHして手でコマンドを打つ等)になっていないか。CI/CDでコード化されていれば、そもそも「その人でないとデプロイできない」状態を回避できる
- アクセス権限一覧: どのサービスに誰がどう入れるか。個人アカウント依存を洗い出す
- 「なぜこう作ったか」の設計判断: 全機能を書く必要はなく、今後変更が入りそうな箇所から
この順番で着手すれば、最悪のシナリオ(不在中の障害対応不能)から潰していけます。
ペア作業・コードレビューで「第二の目」を作る
エンジニアが1人しかいなくても、社内の非エンジニア(PM、CEOなど)や外部の技術者に、定期的にコードレビューやペア作業に入ってもらうことで、知識の独占を緩和できます。
- 完全に同じスキルを持つ2人目でなくても、「このコードの意図を説明してもらう」壁打ち相手がいるだけで、暗黙知の言語化が進む
- 週次で30分でも設計判断を説明する場を設けると、ドキュメント化されない知識が減っていく
- 外部の技術顧問やパートナーに月数回のペアプロ・レビューを依頼するのは、正社員採用よりはるかに小さいコストで始められる
段階的な冗長化: 全部でなく「重要な1〜2割」から
属人化の解消を「システム全体を複数人が把握している状態」まで一気に目指すと、コストが際限なく膨らみます。現実的には、事業への影響が大きい機能・障害時に止まると困る機能から、複数人(または社内+外部)が把握している状態を作るのが妥当です。決済・認証・本番インフラ周りは優先度が高く、管理画面の細かい機能は後回しでよい、といった判断です。
外部パートナーで補完するという選択肢
正社員の2人目採用が難しい場合、外部の技術パートナーを「第二の担当者」として並走させる方法があります。ひとりエンジニア体制で使う場合、主に次の役割を担います。
- 定期的なコードレビュー・設計相談を通じて、社内エンジニアの頭の中にある判断を言語化・ドキュメント化する
- 本番障害時のセカンドオピニオン・緊急対応の窓口として、社内エンジニア不在時のバックアップになる
- 社内エンジニアが休職・離脱した場合に、即座に開発を引き継げる状態を事前に作っておく(コードベースを継続的に把握しているため、緊急時のキャッチアップに数週間かかることを避けられる)
この方法が向いているのは、「今すぐ2人目を正社員で雇う予算判断はできないが、属人化リスクは今のうちに減らしたい」という状況です。準委任契約で必要な稼働量だけ確保できるため、正社員採用のような固定費の意思決定を先送りしながら、リスクだけを先に下げられます。
torcheees では、こうした状況に技術顧問・伴走支援(準委任)で入り、定期的なコードレビューと設計相談を通じて属人化を可視化・軽減します。また継続的な保守・運用としてコードベースを把握し続けることで、緊急時にすぐ動けるバックアップ体制を作ることも可能です。属人化した既存プロダクトを外部の目で確認するときに何を見るかは既存プロダクトの改善、外部チームが最初に見る観点にまとめています。まず現状のコードとドキュメントの属人化度合いを確認したい場合は、既存プロダクト改善の診断から始められます。
まとめ
- ひとりエンジニア体制のリスクは「その人が1ヶ月不在になったら何が止まるか」を具体化することで初めて経営判断の対象になる。本番対応・アクセス権限・進行中案件・顧客対応の4点を必ず棚卸しする
- 「2人目をいきなり正社員採用」は時間(3〜6ヶ月+オンボーディング)とコストがかかる上に単体では属人化を解消しないため、ドキュメント化・ペア作業・段階的な冗長化と並行して進める必要がある
- 正社員採用の意思決定を急がなくても、外部の技術パートナーを「第二の担当者」として並走させることで、コードレビューによる知識の言語化と緊急時のバックアップを、準委任契約の範囲で先に確保できる
「エンジニアが1人しかいなくて、抜けたらどうなるか考えると不安」——そう感じている段階でも、torcheees はご相談を受け付けています。お問い合わせから、現状の体制とリスクの具体化、無理のない補完の進め方についてご相談ください。