AWSエンジニアの参画初月にやること｜現場で信頼される進め方

AWSエンジニアの参画初月は、権限と接続を整え、アカウント・ネットワーク・IaCで管理されている範囲・運用の流れをつかみ、月末に「現状の見立て」と「改善の案」を出して合意を取るところまでを目標にします。最初の1か月で求められるのは、大きな変更を入れることより、このエンジニアに本番を触らせて大丈夫だと発注側が判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、AWSエンジニアならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：権限を整え、構成を読む

権限と接続を確かめる

最初の数日は、アカウントに入る方法、付与された権限、本番と検証の区別を確かめることから始めます。リモートでの接続の方法はAWSエンジニアのリモートの記事で整理しているので、ここでは初月に気をつけたい点に絞ります。

• 本番と検証で、入るアカウントや使う権限が分かれているか
• 付いている権限が、作業に必要な範囲より広すぎないか
• 多要素認証が設定されているか

AWSのIAMの公式のベストプラクティスでも、作業に必要な権限だけを付ける「最小権限」や、人が使う場合の一時的な認証情報、多要素認証が勧められています。権限が広すぎると感じたら、自分から絞る提案をすると、外部の人として信頼を得やすくなります。

AWSエンジニアとして最初に読むもの

次の順で目を通すと、全体像をつかみやすくなります。

1. 構成図と設計書：アカウントの分け方、ネットワーク、主なサービスのつながり
2. IaCのリポジトリ：どこまでがコードで管理されているか、モジュールの分け方、適用の手順
3. 監視とアラートの設定：何を見ていて、誰に通知が届くか
4. 直近の障害の記録と変更の履歴：何が起きやすく、どう直してきたか
5. 運用の手順書：定型作業、障害時の連絡の流れ、作業の時間帯の決まり

読みながら、「図ではこうなっているが、実際のアカウントでは違いそう」という点を書き留めておきます。画面で見た設定とコードの差は、後の改善案の大事な材料になります。この段階では結論を出さず、仮説としてためておきます。

関係者と短く話す

資料だけでは分からないのが、人の見方です。発注側の基盤の責任者、開発チームのリーダー、運用の担当、セキュリティの担当と、それぞれ短い時間で話す機会をもらいます。聞くことは、「今の基盤で一番気になっていること」「うまく回っていること」「この役割に期待すること」の3つに絞ると、相手の負担になりません。

2週目：小さな変更を、正しい流れで一つ通す

変更の流れを自分で一度たどる

2週目には、影響の小さい変更を一つ、現場の決まった流れに沿って通します。タグの付け直し、監視の閾値の調整、ドキュメントの修正など、何でもかまいません。コードの修正、実行計画の共有、レビュー、承認、適用、結果の報告という流れを一度たどると、本番の変更の入れ方が体で分かり、発注側も変更の進め方を確かめられます。

報告の形を責任者と合わせる

発注側の責任者に、どの頻度で、どの粒度の報告がほしいかを確かめ、初回の報告を出します。報告には、やったことに加えて「判断してほしいこと」と「気づいた危うい点」を先に書くと読まれやすくなります。

運用と障害対応の線を確かめる

障害が起きたときに、自分がどこまで対応するのか、夜間や休日の連絡は来るのか、誰に引き継ぐのかを確かめます。ここがあいまいなままだと、初めての障害のときに動き方を迷います。

3〜4週目：見立てを出し、改善に合意を取る

現状の見立てをまとめる

1〜2週目で集めた情報をもとに、現状の見立てをまとめます。中身は次のとおりです。

• コードで管理されている範囲と、されていない範囲
• 権限、公開設定、ログ、バックアップなどで危うい点
• 費用で気になる点（使われていないリソースなど）
• 監視や障害対応で抜けている点

AWSは、基盤そのものの保護はAWSが担い、OSの更新や権限、データの管理などは利用者が担う、という責任の分け方（責任共有モデル）を公開しています。利用者の側で設定すべき項目に抜けがないかという視点で見ると、見立ての漏れが減ります。

改善の案は優先順位で出す

気づいた点を一度にすべて直そうとすると、現場の負担が大きくなり、「前の担当を否定された」と受け取られやすくなります。危うさの大きさと手間で並べ、どれから手をつけるかを責任者に選んでもらう形にします。自分として推す順番があれば、その理由を添えます。

次の1〜2か月の作業計画を引く

合意した内容をもとに、次の1〜2か月の作業計画を作り、関係者に共有します。ここまでできれば、初月の役割は十分に果たせています。

案件の型によって初月の重心は変わる

同じAWSの案件でも、型によって初月に力を入れる場所が違います。

移行の案件

オンプレミスからの移行では、AWSの側より先に、現行環境の調べに重心を置きます。サーバー同士の依存関係、止められない業務の時間帯、切り替えの制約を把握し、月末には移行の方式と順番の案を出せることを目指します。

新規構築の案件

まだ環境がない段階で入る場合は、アカウントの分け方、ネットワーク、権限、IaCの書き方の決まりを関係者と言葉で合わせることが初月の中心になります。後から直しにくい部分を最初に決めるため、決めた理由を記録に残しておきます。

運用・改善の案件

既に動いている基盤では、障害の記録と監視の設定を読み、運用の流れに早く入ることが大切です。初月のうちに定型の作業を一通り経験し、繰り返しの手作業や抜けている監視を、改善の候補として一覧にしておきます。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは業務範囲が変わったときの記事、AWSエンジニアがつまずきやすい場面はAWSエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• 責任者に、現状の見立てと改善の案を伝えられたか
• 変更の流れと承認者が、自分の中ではっきりしているか
• 障害時の自分の役割と連絡の流れを確かめられたか
• 付いている権限が、作業に必要な範囲に合っているか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 稼働時間の記録が残っているか（夜間の作業を含む）

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。引き継ぎの資料を受け取る側として気をつけたい点は引き継ぎの記事も参考になります。

よくある質問

構成図や設計書がほとんどありません。何から始めればよいですか？

IaCのコードと実際のアカウントの設定から、自分用の構成の一覧を作るのが近道です。そのうえで、基盤の責任者と運用の担当に、今一番気になっていることを聞いてください。資料がない状態そのものも、現状の見立ての一部として報告に含めておくとよいでしょう。

参画初月に本番の障害が起きたら、どう動けばよいですか？

まず、障害時の自分の役割と連絡の流れに沿って動きます。役割がまだ決まっていない場合は、勝手に本番を触らず、調べた事実と取れる手を責任者に伝えて判断を仰ぎます。その経験をもとに、障害時の役割をあらためて確かめておくと、次から迷わずに済みます。

1か月たっても全体像がつかめません。どうすればよいですか？

アカウントやサービスの多い基盤では、1か月で全体をつかみきれないこともあります。その場合は、分かっている範囲と分かっていない範囲を分けて報告し、残りをいつまでに確かめるかの予定を示してください。分からない点を隠したまま改善案を出すより、範囲を区切って示すほうが信頼されます。