個人開発者が1人で複数のプロジェクトやコミュニティを運営する話は、SNSやdev.toなどの開発者コミュニティでよく見かけます。ハンドルネームを使い分け、複数のサービスを並行して立ち上げる働き方自体は珍しくありません。ただしこの「1人で全部回す」構造が、チーム開発のクラウド移行プロジェクトに紛れ込むと、思わぬ障害対応の遅延を招くことがあります。
オンプレミス（自社データセンターに物理サーバーを置いて運用する形態）からクラウドへの移行を担当しているインフラ担当者、あるいは移行後の監視体制を引き継いだSREの方に向けて、見落とされがちな「属人化」の落とし穴を整理しました。すでに移行が完了したプロジェクトでも、該当しないか確認する価値はあると思います。
何が起きるか：知識が1人に集中した状態での障害対応
クラウド移行プロジェクトは、立ち上げ時に特定の担当者が設計から構築まで一手に引き受けるケースが少なくありません。
個人開発者が複数のハンドルネームでプロジェクトを使い分けるように、1人のエンジニアがAWSのアカウント構成、Terraformのコード、監視ダッシュボードの設定をすべて把握している状態です。
立ち上げ直後は効率的に見えますが、その担当者が異動・退職・長期休暇に入った瞬間、障害発生時の初動が大幅に遅れます。
アラートは鳴っているのに、誰もどのサービスがどのVPC（仮想プライベートクラウド、クラウド上に論理的に隔離されたネットワーク空間）に属しているか分からない、という状況は実際に起こり得ます。
影響範囲はインシデント対応時間だけにとどまりません。コスト最適化の判断も遅れます。
「このRDSインスタンスは何のために存在するか」を説明できる人がいなければ、不要なリソースを削除する決断もできず、クラウド利用料が膨らみ続けます。
なぜ起きるか：設計意図がコードやドキュメントに残らない
原因を段階的に分解すると、まず「移行スピード優先」という判断があります。
期限のあるプロジェクトでは、ドキュメント作成より先にリソースを作ってしまう判断が優先されがちです。
次に「IaC（Infrastructure as Code、インフラ構成をコードで管理する手法）の導入が部分的」という段階があります。
TerraformやCloudFormationを使っていても、緊急対応で手動変更（コンソールからのポチポチ作業）を加えた箇所があると、コードと実際の構成がずれていきます。
このズレを「ドリフト」と呼びますが、ドリフトが蓄積すると、コードを見ても現状を正確に把握できなくなります。
最後に「監視設計がメトリクス収集止まりで、アラートの意味づけが担当者の頭の中にしかない」という段階です。
CloudWatchやDatadogでアラートルールを設定しても、「なぜこの閾値なのか」「鳴ったら誰が何をすべきか」がRunbook（障害対応手順書）に落とし込まれていなければ、担当者不在時に機能しません。
自分のプロジェクトが該当するか確認する方法
該当するかどうかは、いくつかの確認作業で判断できます。
IaCカバレッジの確認
Terraformを使っている場合、実際のクラウド環境との差分を確認します。
terraform plan -detailed-exitcode終了コードが2の場合、コードと実環境にドリフトがあります。該当するリソースが多いほど、属人化のリスクが高いと判断できます。
AWSを使っている場合は、コンソールの「Config」サービスでリソースの変更履歴を確認し、誰がいつ手動変更したかを洗い出す方法もあります。
監視設定の「意味」が記録されているか確認
アラートルールの定義ファイル（CloudWatch AlarmsのJSON定義やDatadogのモニター設定）を開き、説明欄やアノテーションが空欄になっていないか確認します。
aws cloudwatch describe-alarms --alarm-names "your-alarm-name" --query "MetricAlarms[].AlarmDescription"ここが空、または「CPU high」のような簡素な記述のみの場合、対応手順が担当者の記憶に依存している可能性が高いです。
オーナーシップの分散度を確認
リソースのタグ（Owner、Team、CostCenterなど）が設定されているかを確認します。
aws resourcegroupstaggingapi get-resources --tag-filters Key=Ownerタグなしリソースが大量に出てくる場合、誰が責任を持っているか不明なリソースが放置されている状態です。
対策の手順
確認の結果、属人化の兆候が見つかった場合の対処手順です。
- ドリフトの棚卸し: terraform plan の差分を1つずつレビューし、意図的な手動変更かミスかを仕分けする
- タグ付けルールの強制: AWS Organizationsのタグポリシー、またはTerraformのrequired_tags相当の仕組みで新規リソースにOwner / Teamタグを必須化する
- Runbookの作成: 既存のアラートごとに「発生条件」「影響範囲」「一次対応手順」「エスカレーション先」をドキュメント化する。すべてを一度に作るのが難しい場合は、過去3ヶ月で発報回数が多いアラートから着手する
- IaC化の優先順位付け: 手動構築が残っている領域のうち、変更頻度が高いものから順にTerraform化する。変更頻度はCloudTrailのイベント履歴で確認できる
- 定期的なオンコール訓練: 本来の担当者以外がRunbookだけを見て対応できるか、月1回程度のペースで模擬対応を行う
これらは一度にすべて終わらせる必要はありません。まずはドリフトの棚卸しとタグ付けの2つから着手すると、現状把握の負担が小さく始めやすいです。
まとめ
個人開発者が複数のプロジェクトを1人で管理する身軽さは、学習や副業としては有効な働き方です。
一方でチームが運用するクラウド基盤に同じ構造が持ち込まれると、障害対応の初動遅延やコスト管理の停滞という形で表面化します。
まずはterraform plan -detailed-exitcodeでドリフトの有無を確認し、リソースタグの充足率を調べるところから始めてみてください。
その結果次第で、Runbook整備とIaC化のどちらを優先すべきか、具体的な判断がしやすくなります。