大規模なクラウド移行における重要業績評価指標 (KPI) の重要性

重要業績評価指標 (KPI) は、特定の分野でどの程度の業績を上げているかを理解するのに役立つ定量的な測定値です。例えば、インシデント管理の観点からは、インシデント発生後の復旧にかかる時間を把握するために、平均復旧時間を測定することができます。

大規模な企業の移行プロジェクト (データセンターの撤収や 500 台以上のサーバーの移行など) は、通常、数年とは言わないまでも、数カ月に及ぶことがあります。このような期間がかかることを加味し、移行の初期段階で KPI を定義し、移行作業を監視してリスクや問題を浮き彫りにすることが重要です。

この記事では、大規模なエンタープライズ・クラウド移行を主導している方、または移行計画の初期段階にある方を対象としています。KPI の重要性と、移行プログラムの KPI を決定し測定する方法について説明します。

大規模な移行をモニタリングするために、なぜ KPI が重要なのか？

大規模な AWS 移行において、KPI が価値を持つ主な理由は4 つあります。

目標とするビジネス成果に焦点を当て続ける
複数の意思決定の一元的な可視化
データ駆動型の意思決定
プログラムの健全性の把握

目標とするビジネス成果に焦点を当て続ける

大規模なクラウド移行では、セキュリティ、インフラ、運用、ビジネス、財務、アプリケーションなど、さまざまなチームがさまざまな段階で関与することになります。各チームでクラウド移行の動機は異なるかもしれませんが、目標とするビジネス成果にフォーカスすることが重要です。組織全体で KPI を明確にし、組織内で共有することで、すべてのチームが全体的な目標について足並みをそろえ、その貢献度を測定することができます。さらに、KPI をチームの目標に変えることで、望ましい行動を促すことができます。

たとえば、全体の目標が総所有コスト (TCO) の削減である場合、予測されるアプリケーション使用量と実際の使用量を関連付ける KPI を作成します。支出の予測については、Migration Evaluator のデータ、またはビジネスケースを活用することができます。実際の支出については、AWS Cost and Usage Reports からのデータを利用できます。この KPI を表示するダッシュボードをチーム間で共有することで、移行に関わるチームに対してコスト削減の重要性を強調することができます。

複数の意思決定の一元的な可視化

大規模な移行では、さまざまな意思決定が必要になります。これらの決定の多くは、集中管理されたプログラムではなく、アプリケーションの要件をより詳細に理解しているアプリケーションチームが行うことになります。しかし、これらの決定は、移行プロジェクト全体とその効果に大きな影響を与える可能性があります。前述の TCO の例に基づいて、アプリケーションチームは、Amazon Elastic Compute Cloud (Amazon EC2) のインスタンスタイプ (例: m5.large) やAWS Lambda 関数のメモリ割り当て (例: 6144 MB) を選択することができます。インスタンスタイプや Lambda 関数に割り当てるメモリが必要以上に大きいと、AWS でのコスト上昇につながります。KPI を定義し測定することで、プログラムが目標とするビジネス成果を達成するための道筋から外れていないかを確認できます。さらに、プログラムが KPI に対してネガティブな傾向を示している場合は、深く掘り下げたレビューの後に講じるアクションを特定するのに役立ちます。

データ駆動型の意思決定

移行に関する重要なデータポイントを取得し評価することで、データに基づいた意思決定を行うことができます。意思決定をサポートするデータがない場合でも、新しいアプローチをトライアルで実施し、KPI への影響をモニタリングすることができます。新しいアプローチが KPI にマイナスの影響を与える場合、得られた最新のデータに基づいて、アプローチを迅速に適応させることができます。もし、KPI を積極的にモニターしていなければ、その決定がもたらすマイナスの影響に気づくまでに時間がかかるでしょう。

例えば、データセンター運営会社との契約更新に伴う多額のコストを回避するために、特定の期日までにデータセンターから撤退する必要がある場合があります。移行速度を KPI (月ごとに移行したサーバやアプリケーションの数) としてトラッキングすることで、残りの資産を期限までに移行するにあたって、予定通りに進んでいるかどうかを予測することが可能になります。資産が移行された日付の記録など、移行の追跡を一元化することが必要です。これにより、「月に何台のサーバーを移行しているのか」、「必要な期間内に移行を完了できる見込みはあるのか」といった重要な質問に答えることができます。もし予定より遅れていることに気づいたら、是正措置を取り、移行速度への影響をモニターすることができます。

プログラムの健全性の把握

いったん移行に関する KPI が定義されれば、プログラムの健全性の追跡と報告もデータ駆動型になります。例えば、20 ヶ月以内に10,000 台のサーバーを移行するとします。この場合、現在の移行速度 (1 ヶ月あたりのサーバー移行台数) に関するデータを使用して、必要な目標を達成できそうかどうかを推定することが可能です。上記の例では、プロジェクトが要求される目標を達成するためには、1 ヶ月あたり最低500 台のサーバーを移行する必要があります。プログラムの健全性評価指標の他の例としては、次のようなものがあります。

特定のアプローチでアプリケーションを移行するために必要なリソースの労力。これは、プロジェクトトラッキングツール (従業員のタイムシートなど) を通じて測定される。これによって、さまざまなチーム間で必要な労力のバランスをとることができる。
移行の各フェーズに費やされた平均時間。これは、ワークフローツールによって測定される。これにより、どのフェーズに最も時間がかかるかを予測し、プロセスの加速を深く掘り下げることができる。たとえば、リソースのボトルネックにより、セキュリティレビューのプロセスに多大な時間がかかっている可能性がある。

KPI の決定と測定

移行プログラムに関連する KPI には、通常 2 種類があります。

移行を実施することで期待されるビジネス価値に沿った KPI : 長期的なものであり、移行プログラムの枠を超えるもの(例：クラウドリソースの総所有コストの削減)。
プロジェクトに沿った KPI : プロジェクトが完了すれば、測定する要件はなくなる(例：月間のサーバー移行台数)。

上記の2 種類の KPI は、プログラムが期待される価値を提供しているかどうかを検証し、プログラムの制約内で移行が完了することを確認するために役立ちます。KPI を決定する際には、目標とする成果から逆算して、正しい変数を測定していることを確認するとよいでしょう。例えば、総所有コストを削減するために AWS に移行するのであれば、KPI の一部としてコストを測定していることを確認します。

ビジネスレベルのKPI

ビジネスレベルの KPI を理解するためには、目標とするビジネス成果から逆算することが重要です。移行の対象となるビジネス成果が複数あるケースがあるため、複数の KPI が必要になる可能性があります。目標に対して組織のリーダーを一致させるために、KPI を複数組織間で共有することをお勧めします。

例えば、運用の安定性を高めるために AWS に移行するのであれば、運用能力を測る具体的な KPI を決定することから始めるとよいでしょう。これには、サービスの可用性と合意したサービス・レベル・アグリーメント (SLA) の比較、四半期ごとの計画外停止回数、問題解決までの平均時間など、さまざまな項目が考えられます。これを理解していると、比較ができるように、AWS での測定方法を定義することができます。この詳細については、運用状態の把握のドキュメントを読むことをお勧めします。

プロジェクトレベルのKPI

プロジェクトレベルの KPI を測定するためには、移行プロジェクトがどのような制約の下で運用されているかを理解する必要があります。よくある例としては、データセンターの統合や撤退は、特定の期日までに行わなければならないという制約があります。そのため、この日までにすべての資産を移行しなければなりません。要求された移行速度に対する達成された移行速度を測定することで、移行プロジェクトの健全性を示す指標を得ることができます。

KPIを測定する

図1：Amazon Quicksight で大規模な移行を行う際の主要な指標のグラフを表示した、移行健全性ダッシュボードの一例

KPI が決まったら、どのように測定するのかを理解することが重要です。ここでの目標は、人手を介さずに必要なデータを取得できる完全自動化されたメカニズムを目指すことです。また、自動化されたデータソースを使用してダッシュボードを作成すると、データ更新担当の人手の作業に依存しないため、データソースの整合性が高まります。例えば、AWS Cost and Usage Reports をAmazon Quicksight に取り込んで視覚化し、コストベースの KPI を報告する自動ダッシュボードを構築することができます。あるいは、もしお客様が Cloud Migration Factory on AWS Solution を使用しているのであれば、取得した移行データを使用して、現在の移行速度を提示することができます。

最後に、これらの KPI をチームの目標にすることで、ビジネス全体に望ましいアクションを推進することができるかどうかを検討します。例えば、各アプリケーションチームに対して、1 ヶ月あたり5 つのアプリケーションを移行するという目標を設定することができます。

大規模なクラウド移行に推奨される KPI

移行したサーバー/アプリケーションの総数と、まだ移行予定となっているサーバー/アプリケーション数との比較
一定期間内に移行されたサーバー/アプリケーションの数 (例：移行速度)
各移行パターンでワークロードを移行するのに必要なリソース時間
カットオーバーが遅延したワークロードの数
移行がロールバックされたワークロードの数
ワークロードの移行前後の総所有コスト
移行戦略へのマッピング (例：7 R)
移行前後で四半期ごとに行われたアプリケーションリリース数

まとめ

この記事では、KPI がなぜ重要なのか、クラウド移行における KPI の決定方法、KPI の測定方法、そして大規模なクラウド移行に推奨される KPI について概説しました。

重要なことを確実に測定するため、移行に必要な KPI を決定するための時間を割くことをお勧めします。一度定義され、複数組織間で共有された KPI は、移行をサポートするチームメンバーの行動に影響を与えることになります。

できる限り人間の介在を少なくし、自動的にデータを収集し、表示する方法を検討します。これにより、全体的な労力を削減し、ヒューマンエラーの可能性を排除することができるでしょう。

著者について

この記事は、ソリューションアーキテクトの平岩梨果が翻訳を担当しました。原文はこちらです。

Amazon Web Services ブログ