クラウドアーキテクトのフリーランス案件の仕事内容｜案件の種類と働き方

フリーランスのクラウドアーキテクトの仕事は、要件を数字にし、選択肢を比べ、決めたことを文書とルールにして、作る人と使う人に渡すことです。ただ、全体の方針を決める案件か、共通基盤を作る案件か、移行を計画する案件かで、1日の時間の使い方も、向き合う相手も、手元に残る成果物も大きく変わります。

この記事では、クラウドアーキテクトの案件を5つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。報酬の決まり方はクラウドアーキテクトの報酬の記事、求められるスキルはクラウドアーキテクトのスキルの記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「決める範囲」と「局面」で変わる

クラウドアーキテクトの募集は、肩書きが同じでも中身の幅が広い職種です。違いを生むのは主に次の2つです。

• 決める範囲：会社全体のクラウドの使い方か、複数のチームが使う共通の土台か、一つのシステムの構成か
• 局面：方針を決める前か、土台を作る最中か、移行の最中か、すでに動いている環境の見直しか

この2つを掛け合わせると、フリーランスの案件はおおむね次の5種類に分けられます。

以下の流れは典型的な例です。時間の配分は案件ごとに違うため、目安として読んでください。

全体方針・使い分けを決める案件

1日・1か月の流れ（例）

立ち上げの数週間は、既存のシステムや契約、運用の体制を調べることに多くの時間を使います。部門ごとの聞き取り、資料の読み込み、今の費用や障害の記録の確認が続きます。その後は、クラウドの使い分けや移行の優先順位について選択肢を並べ、評価の物差しをそろえて比べる作業に移ります。

1か月の単位では、週次で情報システム部門の責任者と論点をすり合わせ、月に一度ほど経営層や部門長が出る場で方針の案を示して判断を仰ぐ、という形がよく見られます。

成果物

現状の調査結果、評価の物差しと選択肢の比較、クラウドの使い分けの方針書、移行の順番と体制の案、判断の記録（なぜその案を選んだか）などです。読み手が経営層や他部門になるため、技術の細部より判断の理由と影響を短く示す資料の比重が大きくなります。

共通基盤を設計する案件

1日・1か月の流れ（例）

複数のチームが使うアカウントやサブスクリプション、プロジェクトの分け方、IDと権限、ネットワークの接続、ログの集め方、ガードレール（守るべきルールを仕組みで強制する設定）を設計します。午前は基盤チームと設計の論点を詰め、午後はセキュリティ担当や利用するチームの代表と、ルールの厳しさと使いやすさの折り合いを話し合う、といった1日になりやすい案件です。

設計した内容をIaC（コードによる構成管理）で作る段階では、構築担当が書いたコードの差分をレビューし、設計とずれていないかを確かめます。案件によっては自分でコードを書く範囲まで含まれます。

成果物

基盤の設計書、アカウントや権限の設計表、ネットワーク構成図、ルールの一覧と例外の扱い、利用するチーム向けの手引き、IaCのレビュー記録などです。各クラウドの考え方はAWSの仕事内容、Azureの仕事内容、Google Cloudの仕事内容でも整理しています。

移行計画の案件

1日・1か月の流れ（例）

最初は、移行の対象となるシステムの棚卸しが中心です。システムごとに、構成、つながっている先、止められる時間、データの量、保守の期限などを集め、移行の方式（そのまま載せ替えるか、作り直すか、やめるか）を判断する材料にします。業務システムの担当者や運用チームへの聞き取りが1日の多くを占めます。

計画が固まると、移行の順番と切り替えの手順、戻す手順を決め、リハーサルの結果を見て計画を直していきます。切り替えの日が近づくと、関係者との確認の回数が増え、夜間や休日の作業に立ち会う案件もあります。

成果物

移行対象の一覧、方式の判断表、移行の全体計画、切り替えと戻しの手順、リハーサルの結果と課題の一覧などです。移行は最後までやり切ったかどうかが評価に直結するため、途中の判断を記録に残しておくことが大切です。

設計レビュー・助言の案件

1日・1か月の流れ（例）

各プロジェクトが作った設計書を読み、全社の方針や共通基盤のルールに合っているか、可用性や費用、権限の観点で問題がないかを点検します。決まった曜日にレビュー会を開き、指摘と代替案を示す形が多く、週2〜3日の稼働でも成り立ちやすい案件です。

1か月の単位では、レビューで繰り返し出る指摘をまとめ、設計の指針や手引きに反映する仕事が入ることもあります。

成果物

レビューの指摘票、代替案の説明、設計の指針の改訂案などです。助言の案件は成果物の範囲があいまいになりやすいため、会議への出席だけか、文書まで作るのかを契約前に確かめておきましょう。短い稼働での進め方はクラウドアーキテクトの週2〜3日・副業案件で解説しています。

費用の見直しの案件

1日・1か月の流れ（例）

利用料の明細やタグの付け方を分析し、費用が増えている原因をチームやサービスごとに切り分けます。削減の案は、契約の割引の使い方、使っていない資源の整理、構成の見直しなど性質が違うため、効果と手間、業務への影響を並べて示します。

月の単位では、予算の担当や各チームの責任者と、前月の実績と削減の進み具合を確かめる場が定期的にあります。費用を誰が負担し、誰が見るかというルールづくりまで担うこともあります。

成果物

費用の分析結果、削減案の比較、タグ付けや予算のルール、月次の費用報告の型などです。

どの案件にも共通する仕事

種類が違っても、次の仕事はほぼすべての案件にあります。

1. 要件を数字にする：止められる時間、戻すまでの時間、利用者の数、予算の上限などを聞き出し、設計の前提にする
2. 選択肢を比べる：一つの案だけを示さず、比べた案と捨てた理由を残す
3. 判断を記録する：決めたこと、決めた人、前提を一か所に残し、後から来た人も追えるようにする
4. 作る人に渡す：設計の意図を構築担当や運用チームが誤解しない形で伝える

フリーランスならではの仕事として、自分の稼働と成果物の報告もあります。準委任の契約では作業の時間や内容を報告し、請負に近い契約では納める成果物の範囲がはっきりしている必要があります。違いは準委任と請負の記事をご覧ください。

働く場所と稼働の形

方針書づくりや設計レビュー、費用の分析は文書中心のため、リモートで進めやすい仕事です。一方、立ち上げ時の現状調査や方針の合意の場、移行の切り替えでは出社や現地での立ち会いを求められやすくなります。詳しくはクラウドアーキテクトのリモート案件の記事をご覧ください。

稼働日数は、全体方針や共通基盤、移行計画の案件は週5日が多く、設計レビューや助言、費用の見直しでは週2〜3日の募集も見られます。

よくある質問

クラウドアーキテクトの案件では、自分で構築作業もしますか？

案件によります。方針策定や助言の案件では、構築はほとんど担わないことが多い一方、共通基盤の案件では、IaCのレビューや一部のコードを書く作業まで含まれることがあります。どこまで手を動かす想定かは、稼働の見込みに影響するため参画前に確かめましょう。

一つのクラウドの経験だけでも、アーキテクトの案件に入れますか？

共通基盤の設計や移行計画、設計レビューは、一つのクラウドの深い経験で入れる案件が多くあります。複数のクラウドの使い分けを決める全体方針の案件では、比べて判断した経験を求められやすくなります。

参画して最初の1か月は何をすることが多いですか？

関係者と決める範囲の把握、既存の設計書や方針の読み込み、判断の場と報告の流れの確認から始めるのが一般的です。初月の進め方はクラウドアーキテクトの参画初月にやることで解説します。