クラウドアーキテクトの参画初月にやること｜現場で信頼される進め方

クラウドアーキテクトの参画初月は、現状の環境と「誰が何を決めるか」をつかみ、設計の前提を関係者とそろえ、月末に「現状の見立て」と「優先して決めるべき論点」を出して合意を取るところまでを目標にします。最初の1か月で求められるのは、新しい構成を描くことより、このアーキテクトの判断なら任せられると発注側が思える材料を示すことです。

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

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

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

1週目：権限を受け取り、資料と人から現状を集める

最初に権限の受け取り方を決める

アーキテクトは見る範囲が広いため、権限の受け取りで最初につまずきやすい職種です。初日に、何を見る必要があるかの一覧を作り、読み取りだけの権限から依頼します。AWSのIAMのベストプラクティスでは、人の利用は一時的な認証情報を使うこと、多要素認証を求めること、最小限の権限から始めることが推奨されています（2026年10月時点のAWSドキュメントによる）。設計者が自ら強い権限を求めないことは、発注側の安心にもつながります。

読む資料の順番

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

1. クラウドの利用方針・規程：使ってよいサービスやリージョン、データの扱いの決まり
2. アカウント・サブスクリプションの構成：どの単位で分け、誰が管理しているか
3. ネットワークの全体図：拠点、オンプレミス、他のクラウドとのつなぎ方
4. 権限の設計：IDの管理元、役割の分け方、例外の扱い
5. 費用のデータ：月ごとの推移と、大きな割合を占めるサービス
6. 過去の判断の記録・障害の報告：なぜ今の形になったか、何が問題になってきたか

資料が古い、または無いことも多いため、「資料にある構成」と「実際の環境」の差を書き留めていきます。

人から聞くこと

情報システム部門、セキュリティの担当、運用の担当、主な開発チームに、短い時間でよいので話を聞きます。聞くのは「今困っていること」「変えたくないこと」「過去に揉めたこと」です。資料には書かれない事情が、後の設計の前提になります。

2週目：決め方と設計の前提をそろえる

関係者と決裁を一枚にする

方針の決裁者、セキュリティの承認者、費用の承認者、ネットワークの変更を承認する人を書き出し、窓口と確かめます。会議体ごとに何を決める場かも整理しておくと、論点を出したときに、どこに持っていけばよいかが分かります。

設計の前提を言葉にする

止めてよい時間、守るべきデータ、費用の上限、運用に割ける人の数など、設計の前提を一覧にして関係者に確かめます。前提は人によって違うことが多く、ここをそろえずに構成の議論に入ると、後で作り直しになります。

物差しをそろえる

設計の判断を何で測るかも、早めにそろえておきます。AWS Well-Architectedの6つの柱や、Azureのランディングゾーンの考え方のように、発注側がすでに使っている物差しがあれば、それに合わせます。物差しがない場合は、可用性・セキュリティ・費用・運用の手間の4つ程度に絞って提案すると、議論がまとまりやすくなります。

3〜4週目：現状の見立てと論点を出して合意を取る

現状の見立てをまとめる

集めた情報から、構成の全体図、主なリスク、費用の傾向をまとめます。リスクは「起きたら何が困るか」と「どのくらい起きやすいか」で並べ、根拠になった事実を添えます。

先に決めるべき論点を並べる

見立てから、先に決めるべき設計の論点を並べます。たとえば「アカウントの分け方」「IDの管理元」「拠点との接続方式」「ログの集め方」などです。論点ごとに、比べる案、決めないと何が困るか、いつまでに決めたいかを書くと、決裁者が判断しやすくなります。

月末の報告で合意を取る

月末の報告では、見立てと論点の一覧を示し、どの論点から決めるか、次の1〜2か月で何を進めるかを合意します。決まったことは記録に残し、関係者に共有します。

案件の型による重心の違い

移行の案件では、業務部門への聞き取りに時間を多めにとります。どの業務がいつ止められるかは、資料よりも現場の人が知っていることが多いからです。

新しい環境の立ち上げでは、まだ構成が何もないため、現状の調査より前提の確かめに時間を使います。利用方針や費用の上限が決まっていないまま構成を描くと、後から方針と合わずに作り直すことになりがちです。決まっていない前提は、論点の一つとして月末の報告に入れます。

既存環境の見直しでは、資料と実際の環境の差が大きいことが多く、差そのものが重要な発見になります。手作業で作られた設定や、理由の分からない例外は、すぐに直すのではなく、まず経緯を確かめて一覧にします。

稼働の形による違い

週5日の参画なら、1週目に聞き取りを集中させられます。週2〜3日の参画では、聞き取りの予定が先に埋まりにくいため、参画前に窓口へ会いたい人の一覧を送り、日程を押さえてもらうと初月の進みが変わります。リモート中心の案件では、聞き取りの記録を短い文書にして相手に確かめてもらうと、伝え漏れを防げます。

初月に避けたい動き

• 前の現場の構成をそのまま持ち込む：事情が違う環境に同じ形を当てはめると、反発を招きやすくなります
• 強い権限を求める：調査に必要な範囲を超えた権限は、発注側の不安につながります
• 現状を否定する言い方をする：今の形には理由があることが多いため、まず経緯を聞きます
• 決裁者を飛ばして構築の担当と決める：後から覆り、作り直しになることがあります
• 範囲の外の作業を黙って引き受ける：構築や運用の作業を少しずつ抱えると、設計の時間がなくなります。扱いは業務範囲が変わったときの記事をご覧ください

月末の振り返り

月末には、次の点を自分で振り返っておくと、2か月目に入りやすくなります。

1. 現状の構成図と、実際の環境の差を説明できるか
2. 論点ごとに誰が決めるかが分かっているか
3. 設計の前提を関係者とそろえられたか
4. 自分の担う範囲と、構築・運用の担当の範囲が分かれているか
5. 稼働の量と契約の精算の幅に無理がないか

ずれが大きいと感じた点は、早めに窓口に伝えます。つまずきやすい場面はクラウドアーキテクトのつまずきやすい点で整理しています。

よくある質問

初月から設計書を書くことを求められたら、どうすればよいですか？

急ぎの事情があることもあるため、断る必要はありません。ただ、前提がそろっていない段階の設計書は後で直しが増えるため、置いた前提を冒頭に書き、確かめが済んでいない点を未決として残したうえで出すことをおすすめします。

リモートの案件でも、初月は出社したほうがよいですか？

現状調査や関係者への聞き取りは、対面のほうが進みやすいことがあります。契約で決まった働き方の範囲で、出社が役立つ場面があるかを窓口に確かめてみてください。リモートでの進め方はクラウドアーキテクトのリモートの記事で扱っています。

前任のアーキテクトから引き継ぐ場合、何を優先して聞けばよいですか？

決めた事項と、決めかけて止まっている論点、その理由を優先して聞きます。資料に残っていない経緯は、前任者がいるうちにしか聞けません。引き継ぎの進め方は引き継ぎの記事をご覧ください。