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

GCPエンジニアの参画初月は、組織・フォルダ・プロジェクトの階層と権限、費用の現状を読み、変更をどう通すかと誰に相談するかをつかみ、月末に現状の見立てと改善案を出して合意を取るのが基本です。大きな構成の変更は、初月には急がないほうが信頼につながります。

Google Cloudでは、階層の上の設定一つが多くのプロジェクトに効くため、外部から来た人が全体を知らずに変更を入れると影響が読めません。この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画前の準備の一般論は参画前の準備の記事、参画初期の心構えは参画初期の記事で扱っています。

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

1. 現状を読む：階層、権限、ネットワーク、費用、コードの管理状況を把握する
2. 通し方をつかむ：変更のレビューと承認の流れ、相談先、隣のチームとの窓口を知る
3. 見立てを出す：月末に、気になる点と優先順位、次の1〜2か月の進め方を示して合意を取る

初月に「何かを作った」成果がなくても問題はありません。むしろ、現状を正しく読んで、誰もが気づいていなかった危うさを言葉にできると、その後の任される範囲が広がります。

1週目：環境と人から現状を集める

GCPエンジニアとして最初に見るもの

最初の1週間は、変更よりも読むことに時間を使います。見ておきたいのは次のものです。

• リソースの階層：組織・フォルダ・プロジェクトの構成と、本番・検証・チームの分け方
• IAMの付け方：個人に直接付いている権限、グループの使い方、サービスアカウントと鍵の有無
• 組織のポリシー：どんな制限がかかっていて、例外がどこにあるか
• ネットワーク：共有のネットワークの有無、外部との接続、ファイアウォールの決まり
• コードの管理：Terraformなどのコードがどこにあり、実際の環境とずれていないか
• 費用：請求先アカウントの構成、予算とアラート、ラベルの付け方

権限の見直しでは、IAMのロールの推奨機能が参考になります。この機能は最大で直近90日間の権限の使用状況をもとに、付けすぎた権限を示します（2026年10月時点、Google Cloudのドキュメントによる）。ただ、使われていない権限でも、年に数回の作業で必要になるものがあるため、推奨をそのまま反映せず、持ち主に確かめる材料として使います。

関係者と短く話す

窓口の担当者に加え、データ分析やアプリ開発のチーム、セキュリティ担当、費用を見ている人と短く話し、困っていることを聞いておきます。前任者がいる場合は、引き継ぎの資料にない「なぜこうなっているか」を聞けるうちに聞いておきます。引き継ぎの考え方は引き継ぎの記事をご覧ください。

2週目：変更の通し方と報告の形を整える

変更の流れを確かめる

コードの変更をどこでレビューし、誰が承認して、どう反映するのかを確かめます。小さな変更を一つ、正規の流れで通してみると、手順の抜けや、レビューに時間がかかる理由が見えてきます。管理アクティビティの監査ログは常に書き込まれ、無効にできないため（Google Cloudのドキュメントによる）、手作業の変更も記録には残ります。それでも、変更の理由はコードのレビューや作業の記録に自分で残しておきます。

依頼の受け口を一本にする

隣のチームから権限や環境の依頼が直接来る現場では、受け口をチケットなどに一本化し、窓口が優先度を決める形を提案します。初月から依頼を個別に引き受け続けると、作業量が見えないまま膨らみます。

報告の形を窓口と合わせる

週次の報告で、何を、どの粒度で伝えるかを窓口と合わせます。GCPの案件では、作業の進み具合に加えて「影響するプロジェクト」と「費用の変化」を添えると、技術に詳しくない関係者にも伝わりやすくなります。

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

現状の見立てをまとめる

集めた情報から、気になる点を「事故につながりやすいもの」「費用に効くもの」「運用を楽にするもの」に分けて整理します。たとえば、個人に直接付いた広い権限、手元に残っているサービスアカウントの鍵、コードと実際の環境のずれ、使われていないリソースなどです。

改善案は選択肢で出す

見立ては一つの正解として押し付けず、手間と効果の違う選択肢として出します。権限の整理なら「影響の大きい本番から先に進める」「新しく作る環境から決まりを当てはめる」のように並べると、発注側が判断しやすくなります。

費用の見え方を確かめる

予算のアラートが設定されていても、アラートだけの予算は利用や請求を自動では止めません（Google Cloudのドキュメントによる）。費用の急な増加に誰が気づき、誰が対応するのかが決まっていなければ、改善案に含めておきます。

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

移行の案件では、初月のうちに切り替えの日程が決まっていることもあります。その場合は、全体を読むことと並行して、戻し方の手順が用意されているかを優先して確かめます。

データ基盤の案件では、インフラの設定より先に「分析担当がどのデータを、どの権限で見ているか」を把握しておくと、後の権限の整理で揉めにくくなります。BigQueryでは、データアクセスの監査ログが既定で書き込まれる点も他のサービスと違います（Google Cloudのドキュメントによる）。誰がどのデータを読んだかを後から追えるかどうかは、セキュリティ担当がよく気にする点なので、初月のうちに保存先と見られる人を確かめておきます。

コンテナ基盤の案件では、アプリのチームのリリースの頻度と、障害が起きたときに誰が最初に動くのかを先に聞いておきます。インフラ側の変更がリリースの直前に重なると、原因の切り分けが難しくなるためです。

初月に避けたい動き

• 広い権限をそのまま使い続ける：付いた権限が作業に対して広すぎるなら、早めに窓口に伝える
• 前の現場の構成を持ち込む：既存の構成がなぜそうなっているかを聞く前に、作り替えを提案しない
• コードを通さずに手で直す：急ぎでも、手作業の変更はコードとのずれを生む。やむを得ないときは記録と後からの反映をセットにする
• 検証のリソースを放置する：作ったものにはラベルを付け、使い終わったら消す
• 悪い知らせを抱え込む：危うい設定や費用の増加に気づいたら、自分の作業でなくても早めに共有する

範囲の外の依頼が増えてきたときの扱いは業務範囲が変わったときの記事、よくあるつまずきはGCPエンジニアのつまずきやすい点の記事で整理しています。

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

月末には、次の点を自分の側で振り返り、窓口とも認識を合わせます。

1. 自分に付いている権限は、作業に対して広すぎないか
2. 変更の通し方と相談先は、迷わず分かる状態か
3. 見立てと改善の進め方に、発注側の合意が取れているか
4. 隣のチームとの役割の分け方に、食い違いはないか
5. 契約の業務範囲と、実際に頼まれている作業がずれていないか

5つ目でずれが見つかった場合は、2か月目に入る前にエージェントや発注側の窓口と話し合っておくと、後のつまずきを防げます。

よくある質問

前任者がいなくて、資料もほとんどありません。何から始めればよいですか？

まずはリソースの階層とIAMの付け方、請求の構成を自分で読み、一覧にまとめることから始めます。分からない設定は推測で変えず、持ち主のチームに確かめます。まとめた一覧はそのまま発注側にとっての資料になり、初月の成果として示せます。

参画初月から本番の大きな変更を頼まれたら、どうすればよいですか？

急ぎの理由を確かめたうえで、影響するプロジェクトと戻し方を先に整理して伝えます。そのうえで、レビューと承認の流れに乗せて進めることをおすすめします。自分だけの判断で進めないことが、自分を守ることにもつながります。

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

環境が大きい場合、1か月で全体を把握しきれないのは珍しくありません。把握できた範囲とできていない範囲を分けて窓口に伝え、2か月目に優先して読む範囲を合意しておくと、見通しを持って進められます。