News Observation Lab for Future
主任開発者が退職したときのリスクと対策
主任開発者が突然不在になると、システムの運用やビジネス継続性に深刻な影響が出る可能性があります。本稿では、キーパーソン依存のリスクを洗い出し、具体的な対策と実践的な手順をご紹介します。
主な懸念事項
- 本番環境へのデプロイができるか
- 失敗したリリースのロールバックが可能か
- クラウドインフラやデータベースへアクセスできるか
- バックアップの復元やシークレットのローテーションができるか
- DNS・ドメイン管理やベンダーアカウントへのアクセスができるか
- インシデント対応やアーキテクチャの依存関係を説明できるか
依存関係を可視化するチェックリスト
以下の項目が未チェックであれば、調査・改善が必要です。
- 本番展開
- ロールバック
- クラウドインフラへのアクセス
- バックアップ復元
- 本番データベースへのアクセス
- シークレット／認証情報のローテーション
- DNS とドメイン管理
- ソース管理
- アクセス監視システム
- 重要ベンダーアカウントの管理
- 主要アーキテクチャの依存関係説明
- 本番インシデント対応
実践的な Runbook の例
- 承認済みリリースブランチ／タグを確認
- CI チェックが合格していることを確認
- 保留中のデータベース移行を確認
- デプロイをトリガーし、ログを監視
- 本番環境で煙テスト（Smoke Test）を実施
- 監視・ヘルスチェックを検証
- 失敗時はロールバック手順を実行
インフラと知識の分散化
インフラ情報は個人の頭の中に閉じ込めず、簡易マップや IaC（Infrastructure as Code）で共有します。また、以下の要素についても文書化し、複数人がアクセスできる状態にします。
- クラウドリソース一覧と構成
- ネットワーク設定とデータベース位置
- ストレージバケットとバックアップ方式
- 監視アラートとレガシーリソースの理由
ベンダーアカウントと認証情報の管理
会社所有のアカウントであること、管理者が複数いること、MFA が個人端末に依存しないこと、リカバリ情報が社内で管理されていることを確認します。
所有権とバックアップ所有者のマトリックス
| システム／タスク | 主要所有者 | バックアップ所有者 | ドキュメント有無 |
|---|---|---|---|
| 本番展開 | 主任開発者 | シニア開発者 | あり |
| インフラストラクチャ | プラットフォームエンジニア | リード開発者 | あり |
| データベース復旧 | DBA／バックエンドリード | シニアバックエンド開発者 | あり |
継続的なクロストレーニングの重要性
定期的に別エンジニアにリリースやインフラ変更を実施させ、ランブックを更新します。これにより、個人依存から組織全体の回復力へとシフトできます。
まとめ
主任開発者が不在になっても業務が止まらないように、依存関係の可視化、文書化、複数人による所有権、定期的なテストとクロストレーニングを徹底しましょう。
元記事: https://dev.to/ksoft_technologies_33f7f6/what-happens-if-your-lead-developer-resigns-tomorrow-24fd