FinOps、何からどう手を付ける？

欧米を中心に広がり、昨今国内でも認知度が高まりつつある「FinOps」について、その基本から本連載では解説していきます。今回は、FinOpsフレームワークの残りの要素、FinOpsのフェーズ(Phases)と成熟度(Maturity)について解説します。「はじめてのFinOps」の過去回はこちらを参照。

3つのフェーズを繰り返すFinOps

これまで連載の第1回ではFinOpsの背景とフレームワークの全体像について解説し、第2回、第3回で、FinOpsフレームワークの要素の1つ、ペルソナ(Personas)を、そして第4回、第5回で、その活動領域と内容を整理したドメイン(Domain)と、ケイパビリティ(Capability)について紹介しました。

このようなペルソナの人たちが、幅広いドメイン内のさまざまなケイパビリティによる活動を行うとして、では何からどう手を付ければよいのでしょうか。そこを導いてくれるのが、フェーズ(Phases)と成熟度(Maturity)です。

FinOpsの活動(ライフサイクル)は大きく、3つのフェーズから構成されます。Inform(可視化)、Optimize(最適化)、そしてOperate(実行)です。直感的には、よくあるPlan-Do-See(計画-実行-振り返り)というサイクルを、See-Plan-Do の順で並べたものと考えていただければ、おおよその雰囲気がつかめるかと思います。

そしてこの、Inform-Optimize-Operateの3つのフェーズはループ状になっており、そのループ(サイクル)を繰り返していく中で、FinOpsの活動はより成熟したものになります。

• 

  FinOps の3つのフェーズ(筆者作成)

それではこの3つのフェーズを、順を追ってみていきましょう。

1. Inform（可視化）

最初のInformフェーズでは、各チームのクラウド支出と、そのような支出に至ったリソースの利用状況を明らかにし、各チームに示すことでコスト意識を醸成します。

各チームのクラウド支出を明らかにするには、組織と予算の構造に合わせてクラウドの支出を対応付ける（割り当てる）必要があります。一般的には、AWSの場合はアカウント（※）の機能を活用して請求自体を分け、さらにその中でも細分化が必要な場合には、リソースへのタグ付けの機能を活用します。

このとき、ネットワークなど組織間で共有するリソースの支出については、例えば組織の大きさやシステム規模などの比率によって按分します。この支出をどこか特定のチーム（FinOpsチームなど）が担うのは望ましくありません。各チームの支出実態を正確に把握できなくなる恐れがあるためです。

また支出の割り当てにあたっては、大口割引（カスタムレート）の考慮やコミットメント割引（連載第5回）の前払い金の償却表示（Amortize）などにより、各チームのコスト削減努力を正しく測れるようにしましょう。

そのうえで、支出のトレンドの分析や、ユニットエコノミクス(※)の考え方に基づいた評価などを行います。

※筆者注：Google Cloudではプロジェクト、Azureではサブスクリプションやリソースグループに相当します。

2. Optimize(最適化)

次のOptimizeフェーズでは、Informフェーズで得られたデータをもとに、現在のクラウドの利用状況の要改善点と改善施策を整理し、次のOperateフェーズで達成すべき目標を設定します。

要改善点と改善施策の整理は、支出の公式に基づき、料金（単価）の低減と、使用量の削減の2つの観点で取り組む必要があります。この2つは、それぞれ取り組み方は異なりますが（連載第5回）、使用量の削減によるコスト回避（将来発生する無駄自体を未然に防ぐこと）を優先しましょう。

3. Operate(実行)

最後のOperateフェーズでは、Optimizeフェーズで整理した改善目標を達成すべく、改善施策を実行します。

どのフェーズから始めるか？

FinOpsのフェーズはループ状になっています。そのためどのフェーズからでも始めることはできますが、Informフェーズから始めることが推奨されています。

現状がどのようになっているのかを正しく把握しないまま活動するのは地図を持たないまま旅に出るのと同じで、行きあたりばったりの対応となってしまい、またコスト意識を醸成しないことには活動が根付かず先細りしてしまうでしょう。

それでは、この3つのフェーズの活動に取り組むにあたって、まずは何からどう始めればよいのでしょうか?

フェーズの定義とケイパビリティ（第4回参照）を重ねてみれば、各フェーズで取り組むことが考えられるものの、やることが沢山あり、山が高すぎて、どこからどう手を付けていいやら…となってしまうかと思います。

Small-start, quick-win で始めてみよう

そこでFinOpsフレームワークでは、crawl（はう）、walk（歩く）、run（走る）の3段階からなる成熟度（Maturity）を定義しており、ケイパビリティごとに、それぞれの成熟度で期待されることの目安を具体的かつ詳細に整理しています（Allocation（割り当て）の例）。

• 

  FinOpsの成熟度(筆者作成)

新生児がいきなり走り出すことはできないのと同じように、FinOpsの活動もいきなり満点を目指すのではなく、（中長期的な大きな目標は持ちながらも）”small-start, quick-win” の考え方で、まずは小さくても素早く実績を積むことが大切です。

その成功体験が皆を前向きにし、実績が周りのチームやリーダーシップの協力取り付けにつながり、さらに大きな実績につながる、そのような好循環を描くことが大切です。

FinOps Foundation のサイトにある “State Of FinOps”（「FinOpsの現状」）のページには各種サーベイの結果が整理されており、世の中の企業団体がそれぞれの成熟度の中でどんな取り組みが出来ているものなのか、実情が示されています。

これらも参考にしながら、FinOpsフレームワークで整理されているさまざま様々なナレッジを拾い読みしながらでも自分流に当てはめ、少しずつでもFinOpsの活動を始めてみましょう。

FinOps実践のポイント：組織文化を変えていくことを意識する

今回は、FinOpsフレームワークの残りの2つの要素、フェーズと成熟度について解説しました。

FinOpsのどのフェーズにおいても重要なことは、実際の作業内容やツールの組み合わせといったことだけでなく、組織全体のクラウド利用に関する考え方、行動を変えて定着させていくということです。

このことは一見「クラウド特有の問題」という考え方に陥りがちですが、実は「自分が望むことを他の人にやってもらうために、どのようにして周りを意識づけしていくか」という古くからある問題に行き着きます。

クラウドに特化した考え方から一歩引いて、本質的な問題に焦点を合あわせてみましょう。働きかける相手は何に困っていて、何に関心があるのか、そして多忙な中でも時間を割いて気持ちよく動いてもらうためには、どうすればよいのでしょうか。

そこでペルソナ(連載第2回)の理解が重要になります。そして、いきなり高いハードルを課すのではなく成功体験を積み上げて活動の輪を大きくしていくために、今回解説した成熟度の考え方が重要になるでしょう。

このようにしてFinOpsを眺めると、FinOpsは「コスト削減のテクニック」といったことからはまた異なる地平が広がっていることがご理解いただけるのではないでしょうか。

ここまで、FinOpsフレームワークについて解説してきました。このFinOpsフレームワークを整備しているFinOps Foundation は年次イベント「FinOps X」を米国サンディエゴで開催しています。

今年は初めて、FinOps Foundation エグゼクティブディレクターのJ.R. Storment氏らも来日し、6月18日(水)に「FinOps X Day Tokyo」が開催されます。日本国内においても FinOps への注目が高まっていることが感じられることかと思います。

最終回の次回は、最近のFinOps Foundationの活動やFinOpsフレームワークと、その展望などについてご紹介します。