この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに

社内でAzureの導入が決定しプロジェクトが立ち上がった。既存のオンプレミス環境に存在するシステムの移行先としてパブリッククラウドであるAzureが選ばれたようだ。あなたはそのプロジェクトの計画の策定を任命されたが、Azureを利用した経験はなくこれから調査が必要になっている。どうやって計画を立てていこうか？

・・・

本記事ではこれからAzure導入する計画を検討していく際の、最初の足掛かりとして役に立つ情報を記載しました。
従来のオンプレミス機器の導入プロジェクトとは異なり、Azure(クラウド)導入ならではの特徴や考慮ポイントがあります。予めそれらを抑えることでプロジェクト計画の見通しを立てられるほか、リスクの軽減やメリットを最大限に活かせる可能性があると考えています。

※今回のケースではすでに移行先としてクラウドが選ばれており、さらにクラウドの中でもAzureが選ばれている状態です。計画を立てる前の立上げにおいてクラウドを選定する検討が本来は入りますが、本記事ではこちらの部分は取り扱いません。

プロジェクトの計画について

本記事におけるプロジェクトマネジメントのフローは、プロジェクトマネジメント標準であるPIMBOKガイド第6版のプロセスフローを参考にしています。
以下はPIMBOKガイドのプロセスフローの概念図です。

上記フローにおける “計画” において検討が必要なことについて記載しています。
計画の検討に重要な要素としては、プロジェクトベースラインと呼ばれる　”スケジュール”　”コスト”　”スコープ”　の３つが挙げられます。
それぞれが表す意味を以下に示します。

スコープ	成果物や作業の総称。ステークホルダーのニーズを確認、要求事項を収集してスコープを定義し、最終的にWBSまで落とし込む。
スケジュール	何をやるか(アクティビティ)を定めてそれぞれどういった順番でどのくらいの時間をかけるのか検討し、最終的にスケジュールを作成する。
コスト	アクティビティを完了されるために必要な資源(人件費等)および運用にかかるコストを検討する。

次にAzure導入の特徴・考慮事項を挙げていきますが、それぞれスケジュール・コスト・スコープにどう影響するかを記載していきます。

※図の”立上げ”～”終結”をプロセスと呼んでいるが本来はプロセス群と呼ばれます。PIMBOKガイドに定められた49種類のプロセスのいずれも5つのプロセス群に含まれています。

Azure導入の特徴・考慮ポイント

PoC(概念検証)がしやすい

PoCを実施する目的は、ステークホルダーの期待をコントロールするためと言えます。
早期にプロトタイプを作成しステークホルダーに利用してもらうことでフィードバックを得ることができ、後続の本格導入に向けたスコープを決めやすくなります。
Azureは次の点でPoCが実施しやすい環境であると言えます。

① 利用開始までの時間が短い
Azureには様々な購入方法がありますが、Azure Webサイトで購入する場合には申し込み後即時利用が可能となります。
弊社はMicrosoft クラウド ソリューション プロバイダー (CSP) パートナーとしてAzureを提供させていただいておりますが、1週間以内にご用意可能です。

プロジェクト計画においては調達の期間を短く設定することができるため主に”スケジュール”に影響します。物理機器を調達する場合にはある程度設計を固めて最低限スペックを決める必要がありますがAzureの調達においてはその必要はありません。

※参考情報
[Azure の柔軟な購入オプションのご紹介]
https://azure.microsoft.com/ja-jp/pricing/purchase-options/

② 従量課金制である
Azureは利用した分だけ課金が発生します。PoC実施期間であればその間に作成したリソースが稼働した分だけ請求されるため、必要な分だけお金を支払って無駄をなくすことができます。
発生が見込まれるコストは公式の料金計算ツールにてある程度試算することができます。
プロジェクト計画においては今後発生する費用を予測する際の材料にできるため、主に”コスト”に影響します。

※参考情報
料金計算ツール
https://azure.microsoft.com/ja-jp/pricing/calculator/

責任分界点が存在する

従来のオンプレミスでは自身が全責任を持って運用を行う必要がありました。
Azureにおいては責任の一部は事業者、つまりマイクロソフトに移譲されます。
責任が以上される範囲は下図の通りIaaS、PaaS、SaaSのサービスごとで異なっていますが、データ・デバイス(エンドポイント)・アカウントについてはサービスに関係なく自身が責任を負います。

[クラウドにおける共同責任]
https://docs.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility

プロジェクト計画においては自身の責任に当たる部分について検討が必要になるため、主に”スコープ”に影響します。
例えば非機能要件についてはサービスによって検討内容、つまりスコープが異なってくることになります。

頻繁に更新が行われる

Azureはパブリッククラウドであり日々更新が行われ、新機能のリリースや古い機能の廃止などが発生します。自身が利用している機能については通知を受信できるようにしておき、通知があった場合には対応の可否を検討する必要があります。
プロジェクト計画においてはあらかじめリスクとして把握しておき、ステークホルダーの理解を得ておく必要があります。

※参考情報
[Azure の更新情報]
https://azure.microsoft.com/ja-jp/updates/

おわりに

Azureの導入というテーマでプロジェクト計画の足掛かりとなるような内容を記載しました。
“はじめに”にも記載した通りプロジェクト立上げ時については別途記載していきたいと思います。