3つ目の課題は、既存のAWS環境を前任者から引き継ぐ、という場面です。切り分けでも権限設計でもなく、環境全体を棚卸しする課題を、同じ共通UIに載せられるかを試しました。3つの中で、一番ステップ数が多く、一番悩んだ課題でもあります。
環境調査は、得意分野に引っぱられる
このシリーズの出発点は、第1回で書いた「出身分野によって見る場所が違う」という話でした。環境調査は、その差がとくにはっきり出る課題だと思います。全体を見るはずの作業なのに、無意識のうちに自分の得意な場所ばかり深く見てしまうからです。
ネットワーク出身の人は、VPCや経路をまず丁寧に見ます。セキュリティ出身の人は、公開設定や監査ログに目が行きます。運用出身の人は監視やバックアップを、開発出身の人は動いているリソースや構成を先に確認します。
どれも大事なのに、どれか一つの視点だけでは環境全体を理解できません。得意分野は深く、それ以外は浅く。この凸凹が、引き継ぎではそのまま抜け漏れになります。引き継いだ側が、あとになって「そこは聞いていない」と気づく、というやつです。だからこの課題は、特定の得意分野に偏らず、環境全体の確認観点を並べることを狙いました。
15ステップで全体を棚卸しする
想定は、複数アカウントから成る既存環境を引き継ぐ場面です。構成資料は一部古く、管理者権限の利用経路もはっきりしない。そんな、実際にありがちな状態から、次の担当者へ説明できる状態まで持っていきます。
- 引き継ぎ対象と目的の確認
- AWSアカウント・Organizations構成の確認
- 管理者アクセス経路の確認
- ネットワーク全体像の確認
- 主要リソースとサービス一覧の確認
- ログ・監査設定の確認
- セキュリティサービスの確認
- 監視・通知の確認
- バックアップ・復旧方針の確認
- コスト・契約・ライセンスの確認
- 定常作業と運用ルールの確認
- 未解決課題・リスクの整理
- 証跡と引き継ぎ資料の確認
- 完了報告
- 完了
アカウント管理から始めて、ネットワーク、ログとセキュリティ、監視、バックアップ、コスト、運用ルールへと広げ、最後に未解決課題をまとめて引き継ぎ資料に落とす、という流れです。どの得意分野の人が担当しても、この一覧をたどれば主要な観点は一通り通る、という状態を目指しました。ステップ2のアカウント・Organizations構成では所有メールやrootの状況まで、ステップ6のログ・監査ではCloudTrailやConfigの有効範囲まで、というように、見落としやすい足元も項目に入れています。
「確認済み」「対象外」「未確認」を分ける
この課題で一番悩んで、一番こだわったのが、不明点の扱いです。環境調査では、その場で答えが出ないことが山ほどあります。前任者に聞かないと分からないこと、資料が古くて確認できないこと。ここを雑に扱うと、引き継ぎの質が一気に落ちます。
そこで、状態を三つに分けられるようにしました。
- 確認済み: 実際に見て、結果を証跡として残せたもの。
- 対象外: そもそも存在しない要素。たとえば専用線を使っていない環境なら、その項目は「対象外」と記録し、判断を「該当なし」にします。
- 未確認: 今は分からないが、放置してはいけないもの。
大事なのは、対象外と未確認をはっきり分けることです。「無い」のと「まだ確認できていない」のは、引き継ぎ先にとって意味がまったく違います。前者は安心材料ですが、後者は宿題です。ここを一緒くたに空欄で済ませてしまうと、引き継いだ人は「無いのか、見落としたのか」の区別がつかず、また一から確認し直すことになります。
未確認は、宿題として引き継げる形で残す
未確認をただ空欄にすると、後から見た人には判断がつきません。そこで、未確認の項目には「確認先・期限・担当」を添えて残せるようにしました。誰に聞けば分かるのか、いつまでに、誰がやるのか。ここまで書けて、初めて引き継ぎになると考えました。宿題を、宿題だと分かる形で渡す、ということです。
各ステップには、この「未確認の残し方」の案内を、入力欄のヒントとして共通で置いています。書き方に迷わないようにするためです。そして12番目のステップでは、各ステップで出た未確認や気になった点を一か所に集約します。課題が無ければ「なし」と明記させます。集約された宿題リストが、そのまま次の担当者への申し送りになります。バラバラに散らばっていた不明点が、最後に一枚のリストにまとまる、という流れです。
空欄のままでは完了できない
ここでも、前の課題と同じ完了制約が効いています。必須の証跡が空欄で、正常か異常か（あるいは対象外か）の記録が無いステップは、完了にできません。「分からないから飛ばす」ができないようにしてあります。環境調査で一番怖いのは、この「なんとなく飛ばし」だからです。
分からないなら「未確認（確認先・期限・担当）」と書く。存在しないなら「対象外」と書く。どちらかを必ず残さないと先に進めない。この制約が、棚卸しの取りこぼしを防ぐ役割を担っています。要求された完了必須項目――アカウント一覧、管理者アクセス経路、ネットワーク、ログ、セキュリティ、監視先、バックアップ方針、定常作業、未解決課題、引き継ぎ先――は、それぞれ対応するステップの必須証跡に紐づけました。
この課題でも、AWSは変更しない
引き継ぎのための調査なので、当然ですが環境そのものは変更しません。ロール変更も設定変更もリソース削除も、監査サービスの有効化さえも行わず、すべて確認・記録・判断だけにとどめます。調査の途中で「ついでに直しておこう」とやってしまうと、それ自体が引き継ぎの妨げになるからです。この「AWS環境を変更しません」という注意は、画面の上部に常時表示するようにしました。この常時表示は、じつは3つの課題すべてに共通で効く改善で、この課題を作るときに入れたものです。
作ってみて感じたこと
15ステップは、3つの課題の中で一番長くなりました。作っている途中で「多すぎないか」と何度か迷いましたが、削ると環境の一部が見えなくなるので、この長さに落ち着きました。それでも、環境全体を一つの流れとして並べてみると、自分の得意分野の外側にどれだけ確認項目があるかが可視化されて、作りながら自分の勉強にもなりました。
同時に、これは「観点の一覧」であって、実際の調査の深さまでは踏み込めていません。各項目をどこまで掘るかは、結局は担当者の判断に委ねられます。抜け漏れを減らす枠は作れても、中身の濃さまでは保証できない、というのが今の正直なところです。枠を渡すことと、中身を埋めることは、別の仕事なのだと思います。
次回は、3つの課題を貫く「次へを押せない仕組み」――進捗保存と完了制約を、もう少し踏み込んで書きます。