Azureエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

Azureエンジニアのフリーランス案件の仕事は、オンプレミスからの移行、ランディングゾーンとガバナンスの整備、Entra IDを中心としたIDの整備、アプリの実行基盤とIaC、運用の改善の5つにおおむね分けられます。どの案件でも、手を動かす時間と同じくらい、変更の影響を見積もり、申請と合意を取る時間を使うのがAzureの案件の特徴です。

Azureは社内のActive DirectoryやMicrosoft 365と一体で使われることが多く、発注元は情報システム部門であることが目立ちます。この記事では、案件の種類ごとに1日と1か月の流れ、関わる相手、成果物を整理します。求められるスキルはAzureエンジニアのスキルの記事、報酬の決まり方はAzureエンジニアの報酬の記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

案件の種類は「どの層を触るか」で分かれる

Azureの案件は、作業がリソース・サブスクリプション・管理グループ・テナントのどの層に及ぶかで、進め方が大きく変わります。下の層ほど影響が広く、作業の前の調整が増えます。

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

移行案件の仕事

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

午前は、移行対象のサーバーやデータベースの一覧を見ながら、アプリの担当者に依存関係や停止できる時間帯を聞き取ります。午後は、移行先の構成を決め、検証用の環境で移し替えを試します。夕方は、課題と決まったことを移行管理表に残します。

Microsoftの移行サービスであるAzure Migrateは、現行環境の検出、Azureへの移行の可否や費用の見積もり、サーバー間の依存関係の分析、実際の移行までを支援するとされています。こうした道具を使いながら、どの順番で、いつ、どう戻せるようにして移すかを決めるのが中心です。

1か月の単位では、月の前半に調査と計画、後半に検証と本番の切り替えという波ができやすくなります。本番の切り替えは業務への影響を避けるため、夜間や休日に行うことがあります。

成果物

現行環境の調査結果、移行対象の一覧と移行の順番、移行後の構成図、切り替えの手順書と戻し方の手順、切り替え後の確認の結果などです。

ランディングゾーン・ガバナンス整備の仕事

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

部署ごとにサブスクリプションが増えた組織で、全体の統制を整える案件です。Microsoftの説明では、ランディングゾーンは、組織全体のガバナンスやセキュリティ、共通の仕組みを担う「プラットフォーム」と、各システムを置く「ワークロード」の領域で構成され、管理グループの階層にポリシーを当てて統制します。

1日の多くは、設計の打ち合わせと文書づくりです。管理グループの切り方、命名やタグのルール、禁止する設定のポリシーなどの案をつくり、セキュリティ部門や各事業部に説明します。月の単位では、案を固める期間、検証用の管理グループで試す期間、本番に段階的に当てる期間と進みます。

ポリシーを当てると、既存の環境が規則に合わない状態として表に出ることがあります。どこから直すかの優先順位を、各部署と相談しながら決めていく調整が続きます。

成果物

管理グループとサブスクリプションの設計書、ポリシーとロールの一覧、命名とタグのルール、新しいサブスクリプションを払い出す手順、各部署向けの説明資料などです。

ID整備の仕事

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

Entra IDを中心に、多要素認証や条件付きアクセス、社内のActive Directoryとの同期、権限の棚卸しなどを進める案件です。設定を一つ変えるだけで社員全員のサインインに影響することがあるため、少人数で試してから対象を広げる段階的な進め方が基本になります。

1日の中では、設定の設計と検証に加えて、ヘルプデスクやMicrosoft 365の管理者との打ち合わせ、社員向けの周知文の確認に時間を使います。1か月の単位では、対象のグループを少しずつ広げ、問い合わせの内容を見て設定を調整する流れが続きます。

成果物

認証方式と条件付きアクセスの設計書、権限の棚卸しの結果と見直し案、展開の計画と対象の一覧、社員向けの手順書、問い合わせ対応の想定集などです。

アプリ基盤・IaCの仕事

開発チームから出る案件です。App ServiceやAKS、関数などアプリの実行環境を整え、BicepやTerraformで構成をコードにし、デプロイのパイプラインをつくります。1日の流れは開発チームの進め方に近く、朝の短い打ち合わせ、コードのレビュー、環境の変更、開発者からの相談への対応が中心です。

情報システム部門の案件に比べると、文書や申請は少なめで、変更を小さく頻繁に出す働き方になりやすい傾向があります。一方で、社内のネットワークやIDのルールは情報システム部門が持っていることが多く、その窓口とのやり取りが必要になります。成果物は、IaCのコード、パイプラインの定義、環境の構成図、運用の手順書などです。

運用改善の仕事

稼働中のAzure環境で、監視の設計、バックアップの見直し、費用の削減、パッチの適用の仕組みづくりなどを担う案件です。定型の運用作業が中心の案件もあれば、運用の仕組み自体を見直す案件もあります。

前者は手順書どおりの作業と報告が中心で、後者は現状の課題を洗い出し、改善の案をつくって合意を取る仕事が中心です。案件票では区別がつきにくいため、面談で「変更の判断は誰がするか」を聞くと、どちらの仕事かが見えます。

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

1. 変更の申請と承認：作業の前に、影響の範囲、手順、戻し方を書いて承認を取る
2. 権限の受け取り：取引先のテナントにゲストとして招かれ、必要なときだけ強い権限を使う形が増えている
3. 記録：ポータルで変えた設定をコードや手順書に戻し、後から来た人が追えるようにする
4. 報告：作業の結果と、気づいたリスクを、決める人に分かる言葉で伝える

フリーランスならではの仕事として、自分の稼働の記録もあります。夜間や休日の切り替え作業が入る案件では、その時間の扱いを含めて日々つけておきましょう。精算の仕組みは精算幅の記事、働く場所や権限の受け取り方はAzureエンジニアのリモート案件の記事をご覧ください。

よくある質問

Azureの案件は、手を動かす時間より会議や文書の時間が長いですか？

情報システム部門の案件では、設計書や変更の申請、関係部署への説明の比重が大きくなりがちです。開発チームの案件では、コードを書いて環境を変える時間が長くなります。どちらの比重が大きいかは、発注する部署で見当がつきます。

Microsoft 365の管理も仕事に含まれますか？

ID整備の案件では、Entra IDの設定がMicrosoft 365の利用に直結するため、関わることがあります。ただ、アカウントの発行やライセンスの付け替えなどの定型作業が契約の範囲に入るかは案件によって違うので、参画前に確かめておくと安心です。

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

テナントと管理グループの構成、付与された権限、変更の申請の流れ、関係する部署の把握から始めるのが一般的です。初月の進め方はAzureエンジニアの参画初月にやることで詳しく解説します。