0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

新人プログラマ応援 - みんなで新人を育てよう！
@tetsuya-oooooinパーソルクロステクノロジー株式会社

FinOps をしっかり理解する！

0
Posted at

はじめに

クラウドコスト管理については日頃から触れているつもりでしたが、FinOps を改めて整理してみると「理解しているようで曖昧だった部分」がいくつか見つかりました。

そこで今回、FinOps の基本からフレームワークまでを自習し直し、自分なりにまとめてみました。

最初は「サクッと理解する！」という軽めのタイトルにするつもりでした。しかし、学び直す中で FinOps の範囲が想像以上に広く、深いことに気づき、結果として「しっかり理解するためのまとめ」になりました。そこでタイトルも「しっかり理解する！」に変更しています。

さて一方で、クラウド利用が進むにつれ、多くの組織では次のような課題が表面化します。

  • コストの増減理由がわからない
  • 予算と実績が合わない
  • エンジニアと財務で会話が噛み合わない
  • 最適化の優先順位が決められない

こうした混乱の背景には、クラウド特有の 変動費モデルに組織が十分に適応できていないこと があります。
さらに、FinOps はしばしば「クラウドコスト削減の手法」と誤解されがちですが、本質はまったく異なります。

  • FinOps に対する誤解 (例)
    • FinOps は単なる「コスト削減ツール」の導入だ
    • 月次レポートで金額の増減を眺めるだけで十分だ
    • エンジニアリングの自由度を制限する取り組みだ

FinOps は、クラウド支出を「価値の観点で評価し、意思決定に活かす」ための運用モデル です。財務・エンジニアリング・ビジネスが同じデータを見て、同じ方向に進むための 共通言語とプロセスを提供し、クラウドから得られる価値を最大化すること を目的としています。

クラウドの利用量が増えるほど、支出と成果の関係性を可視化し、意思決定の質を高めることが求められます。

FinOps はそのための実践的なアプローチであり、組織が継続的に最適化を進めるための基盤となります。

FinOps とは

クラウドコスト管理の文脈で語られる FinOps は、「コスト削減手法」ではなく、クラウドの価値を最大化するための運用モデル です。

FinOps の定義

FinOps は、クラウド支出に対する 財務 (Finance)・エンジニアリング (Engineering)・ビジネス の連携を強化し、ビジネス価値を最大化しながらコストを管理するための運用モデル です。

目的 (ゴール)

FinOps の目的は、単なるコスト削減ではなく、クラウド利用から得られる価値を最大化すること です。支出と成果を結び付け、意思決定の質を高めます。

中央チームと分散責任

FinOps は 中央チーム (CoE1 的役割) が推進しますが、実際のコスト責任は 各チーム (プロダクト／エンジニアリング) が持ちます。セキュリティモデルに近い 「共有責任」 の考え方です。

部門横断のコラボレーション

クラウドは秒単位でコストが発生するため、財務・エンジニアリング・ビジネスのリアルタイムな連携 と継続的改善が不可欠です。

可視性とタイムリーなデータ

コストデータは 誰でもアクセス可能かつ迅速 であるべきです。高い可視性と短いフィードバックループが、効率的な行動を促進します。

責任の明確化

全員が自身のクラウド利用に責任を持つ ことが原則です。設計段階からコストを重要な指標として扱います。

価値に基づく意思決定

合計支出ではなく、ユニットエコノミクス2や価値ベースの指標 を用いて、コスト・品質・スピードのトレードオフを判断します。

FinOps の意思決定は、コストだけでなく、品質・スピードとのバランス を前提に行います。
「安くするために遅くする」のではなく、価値を損なわずに最適な構成を選ぶ ことが重要です。

変動費モデルの活用

クラウドの変動費はリスクではなく 価値創出の機会 です。俊敏で反復的な計画と、継続的な最適化が重視されます。

FinOps フレームワーク

FinOps フレームワークは、FinOps を実践するための 運用モデル です。共通の構成要素 (ビルディングブロック) を組み合わせる考え方で、組織ごとに異なる実装が可能 です。

フレームワークは、組織がクラウドの変動費モデルに適応し、継続的に価値を引き出すための共通基盤として機能します。

原則

FinOps フレームワークは、クラウド支出の最適化とビジネス価値の最大化を目的とした 6つの原則 を基盤としています。

FinOps Principles

1. 中央チームが FinOps を推進する

中央の FinOps チームがベスト プラクティスを定義・普及しつつ、各チームが自らのクラウド利用に責任を持つ「共有責任モデル」を採用します。経営層の賛同が不可欠で、契約条件や割引 (リザーブド／コミットメントなど) の最適化は一元管理します。

2. チームは共同作業を行う

財務・エンジニアリング・ビジネス・プロダクトの各チームが、ほぼリアルタイム で連携し、継続的な改善とイノベーションを促進します。

3. FinOps データはアクセスしやすく、タイムリーである

コストと使用量のデータは迅速に共有し、リアルタイム可視化と短いフィードバックループで改善につながる行動を促します。予測・差異分析・ベンチマーク (社内／業界) で改善を継続します。

4. 全員が自身のクラウド使用に責任を持つ

責任はエンジニア／各プロダクトチームへ分散します。設計段階からコストを考慮し、コスト効率の高いアーキテクチャと運用を実践します。

5. 意思決定はクラウドのビジネス価値に基づく

「総コスト」よりも ユニットエコノミクス2や価値ベースの指標 を重視します。コスト・品質・スピードのトレードオフを意識し、クラウドをイノベーションの原動力と捉えます。

6. クラウドの変動コストモデルを活用する

変動コストはリスクではなく価値創出の機会と捉えます。長期・静的計画より、俊敏で反復的な計画 と継続的な最適化を重視します。

ペルソナ

FinOps Personas

1. FinOps は「役割 (ペルソナ)」ごとの協調が前提

FinOps は特定の部署や担当者だけで実践するものではなく、エンジニアリング、財務、ビジネスといった異なる立場 (ペルソナ) が協調して進める運営モデル です。
全員が同じクラウドコストデータを参照しますが、立場によって注目点や判断の仕方は異なります。

2. 主な FinOps ペルソナとその関心領域

:tools: エンジニアリング (Engineering)

エンジニアは、クラウドリソースの利用状況やアーキテクチャに最も近い立場です。
コストを意識した設計や実装を行い、使用量の最適化や無駄なリソース削減を通じて、日々の運用の中でコスト改善に直接貢献 します。

:moneybag: 財務・経理 (Finance)

財務部門は、予算管理やコスト予測、実績の把握を担当します。
クラウドの変動費モデルを前提 に、支出の可視化や予測精度の向上、請求内容の妥当性確認などを行い、組織全体のコストガバナンスを支えます。

:scales: ビジネス・経営・プロダクト (Business / Executive / Product)

経営層やビジネス、プロダクト担当者は、クラウド支出を「コスト」ではなく「投資」として捉えます。
支出がどれだけビジネス価値や成長に結び付いているかを判断 し、コスト・品質・スピードのトレードオフに関する意思決定を行います。

3. ペルソナを理解することの意義

同じ「クラウドコスト」であっても、立場によって次のように見方が異なります。

  • エンジニアは「どう最適化するか」
  • 財務は「どう管理・予測するか」
  • 経営は「ビジネス価値に見合っているか」

FinOps を成功させるためには、ペルソナごとに適切な指標や言葉で情報を共有し、共通理解を作ることが重要 です。

フェーズ

FinOps は、クラウド利用におけるコスト最適化と価値の最大化を継続的に実現するための、反復的な改善ループ として設計されています。

フェーズは 「情報提供 (Inform)」「最適化 (Optimize)」「運用 (Operate)」 の 3 つで構成されており、必ずしも順番に進める必要はありません。組織やチームの状況に応じて、柔軟に適用できる点が特徴です。また、同一組織内でも、チームごとに異なるフェーズに位置する場合があります。

FinOps Phases

各フェーズの要点

1. 情報提供 (Inform)

目的：クラウドコストの可視化と理解の基盤を整えることです。

このフェーズでは、クラウドのコスト、使用量、効率に関するデータソースを特定し、データの割り当て・分析・レポートを行います。これにより、予算編成、利用傾向の予測、KPI やベンチマークの作成、クラウド支出がビジネスにもたらす価値の把握が可能になります。

2. 最適化 (Optimize)

目的：クラウド利用のコスト効率を向上させることです。

情報提供フェーズで得られたデータや分析結果を活用し、料金や使用量の観点から改善ポイントを特定します。無駄なコストの削減や、リソース利用効率の向上を通じて、クラウドの費用対効果を高めていきます。

3. 運用 (Operate)

目的：FinOps を組織に定着させ、継続的改善を実現することです。

このフェーズでは、情報提供および最適化フェーズで得られた成果を基に、FinOps を実務として運用します。具体的には、組織目標に沿ったトレーニングの整備、チーム向けガイドラインの策定、自動化ポリシーの導入、クラウドガバナンス方針の確立、コンプライアンスの監視などを行い、継続的な改善サイクルを回していきます。

成熟度モデル

FinOps 成熟度モデルは、組織が FinOps の機能をどの程度実践できているかを評価・改善するための指針です。クラウド管理の成熟度を段階的に理解し、強化するための構造を提供します。

成熟度は大きく 3 つのステージ (Crawl → Walk → Run) に分かれており、段階が進むにつれてプロセス、自動化、KPI の水準が高度になります。

しかし、必ずしもすべての組織が「Run」ステージに到達することを求めるものではありません。組織の目標や創出したいビジネス価値に応じて、適切な成熟度を目指すことが重要です。

FinOps Maturity Model

3 つのステージ

:baby: Crawl

基本的なプロセスやポリシーが定義され、最低限の KPI が設定されている段階です。FinOps の考え方は理解されていますが、組織全体にはまだ十分に浸透していません。

:walking: Walk

FinOps 機能が組織内で広く理解・実践され、多くの要件がプロセスや自動化でカバーされている段階です。重要な課題やエッジケースが認識され、対応方針が検討されます。

:runner: Run

すべてのチームが FinOps を実践し、高度な自動化と非常に高い KPI を設定して継続的な最適化を行う段階です。困難な課題にも積極的に対応します。

ドメインと機能

FinOps のドメイン (領域) は、クラウドの使用状況やコストを管理・最適化するための活動および知識を大きく分類した枠組み です。FinOps を導入する組織は、特定の領域だけではなく、すべてのドメインにまたがって継続的に取り組むこと が前提とされています。
各ドメインは、日々の実践を具体化するための FinOps の機能 によって構成されています。

これらのドメインと機能は、

可視化 → 価値の定量化 → 最適化 → 組織的な運用

という FinOps の基本サイクルを表しており、クラウドコストを単なる「支出管理」に留めず、ビジネス価値と結び付けて継続的に改善していく ための構造として整理されています。

FinOps Domains

FinOps Capabilities

4 つのドメインと代表的な機能

ここからは、FinOps の 4 つのドメインについて、役割と重要性を順に整理します。

1. クラウドの使用状況とコストを理解する (Inform)

「まずは正しく見える化する」 領域。
FinOps のすべての出発点は、クラウドの利用状況とコストを「正しく・タイムリーに」把握することです。

何をする領域か
  • クラウドの 使用量データ
    • CPU、メモリ、ストレージ、ネットワークなど
  • コストデータ
    • 従量課金、予約系、ライセンス、SaaS 費用など
  • 契約情報
    • 予約インスタンス (Reserved Instances) / 節約プラン (Savings Plans)、ボリュームディスカウント
  • 組織メタデータ
    • タグ、アカウント構造、プロジェクト、事業単位
  • サステナビリティ指標
    • CO2 排出量など

これらを収集し、誰でもアクセスできる状態に整備 します。

なぜ重要か
  • 「どこで何にいくら使っているか」が曖昧だと、最適化も価値評価もできない
  • タグ不備やアカウント構造の混乱は、FinOps の最大のボトルネック
  • データの粒度・鮮度が悪いと、アクションが遅れてコストが膨らむ
ドメイン機能
  • データの取り込み
  • コスト配賦
  • レポートと分析
  • 異常管理
明日からできる小さな一歩
  • タグが付いていないリソース一覧を出してみる
    FinOps の最大のボトルネックは「見えないコスト」なので、まずは「見える化の阻害要因」を 1 つ取り除くことが最も効果的です。

2. ビジネス価値を定量化する (Value)

「クラウドのコストを "価値" と結び付ける」 領域。

何をする領域か
  • コストを 予算 や 事業計画 と紐づける
  • 過去データと将来計画を使って 予測 (Forecast) を行う
  • プロダクトやチームごとの KPI を設定・測定
    • 例：売上 1 円あたりのクラウドコスト
    • 例：1 ユーザーあたりのコスト (ユニットエコノミクス2)
  • 他チームや他社と ベンチマーク を行う
なぜ重要か
  • 「コストが高い＝悪」ではなく、「価値に見合っているか」 が本質
  • FinOps は財務とエンジニアリングの共通言語をつくる取り組み
  • 価値が見えると、経営層の意思決定が速くなる
ドメイン機能
  • 計画と見積もり
  • 予測
  • 予算作成
  • ベンチマーク
  • 単位当たりの経済性
明日からできる小さな一歩
  • 「1 ユーザーあたりのコスト」を計算してみる
    完璧なユニットエコノミクスは不要で、ざっくりでも "価値とコストの関係" を可視化すると、FinOps の本質が一気に掴めます。

3. クラウドの使用状況とコストを最適化する (Optimize)

「ムダを無くし、必要なものを最適な価格で使う」 領域。

何をする領域か
  • リソースの利用率改善
    • 休眠 (Idle) / 非稼働 (Underutilized) の検知と削減
    • スケジューリング (夜間停止など)
    • オートスケールの適正化
  • 料金最適化
    • 予約インスタンス (Reserved Instances) / 節約プラン (Savings Plans) の最適購入
    • スポット利用
    • SaaS ライセンスの棚卸し
  • アーキテクチャ改善
    • サーバレス化、マネージドサービス化
    • ストレージ階層の最適化
  • サステナビリティ最適化
    • CO2 排出量の削減も評価軸に含める
なぜ重要か
  • 最適化は「単発の削減」ではなく 「継続的な改善」
  • 技術的改善 (Engineering) と契約的改善 (Finance) の両輪が必要
  • 価値を損なわずにコストを下げる のが FinOps の流儀

そのため、FinOps の最適化では 「コスト・品質・スピード」のトレードオフ を常に意識します。性能を落として安くするのではなく、ビジネス価値を維持しながら最適な構成を選ぶこと が求められます。

ドメイン機能
  • レートの最適化
  • ライセンスおよび SaaS の最適化
  • ワークロード最適化
  • クラウド アーキテクチャ設計
  • クラウドの持続可能性
明日からできる小さな一歩
  • 休眠 (Idle) リソースを見つけて削除する
    最適化は「大きな削減」よりも「小さな改善の積み重ね」が本質。まずは 1 つだけでもムダを減らすところから始めるのが最も効果的です。

4. FinOps プラクティスを管理する (Operate)

「FinOps を組織に根付かせる」 領域。

何をする領域か
  • FinOps チームの運営
    • CoE1、FinOps Champion3 など
  • プロセス整備
    • タグ運用、予算管理、レビューサイクル
  • 全社への教育・啓蒙
    • FinOps のペルソナへの支援活動
  • 他部門との連携
    • 財務、調達、エンジニアリング、経営層
  • 継続的な改善
    • 成熟度モデルに基づく改善
なぜ重要か
  • FinOps はツール導入ではなく 文化づくり
  • 組織が変わらないと、最適化は一過性で終わる
  • 「人・プロセス・テクノロジー」の三位一体が成功の鍵
ドメイン機能
  • FinOps プラクティスの運用
  • ツールとサービスの活用
  • 成熟度評価
  • 教育と有効化
  • 請求と配賦
  • ワークロードのオンボード
  • クラウド ポリシーとガバナンス
明日からできる小さな一歩
  • FinOps の旗振り役 (担当者) を決める
    役割を明確にするだけで、FinOps の議論が進みやすくなり、改善サイクルの起点が生まれます。
  • 月 1 回 15 分の FinOps ミーティングをカレンダーに入れる
    議題は「今月の気づき」だけでも十分。場をつくることが最初の一歩です。

スコープ

FinOps のスコープは、FinOps フレームワークを 実際の意思決定に使うための整理単位 です。「どのコストを」「どんな目的で」「誰の判断に使うのか」を明確にするための枠組みだと考えると分かりやすいです。

スコープは、クラウドや AI といった 技術そのものではなく、ビジネスの文脈 を起点に定義されます。たとえば「特定プロダクトの収益性を高めたい」「AI 投資の効果を見極めたい」といった目的が、スコープを決める出発点になります。

FinOps Scopes

FinOps フレームワーク全体の中での位置付け

FinOps フレームワークには、

  • ペルソナ (関わる人)
  • ドメイン (活動領域)
  • 機能 (具体的な機能)

という共通の構成要素があります。

スコープは、これらを どの範囲・どの深さで使うかを決める前提条件 です。同じ「可視化」や「予測」を行う場合でも、スコープが変われば、重視する KPI や求められる精度、ガバナンスの強さは変わります。

スコープ設計で大事な考え方

  • スコープは 意思決定の単位 であり、インフラの境界ではありません。
  • 1 つのスコープが複数の技術や環境をまたぐこともあります。
  • 新しいスコープは、より良い意思決定ができる場合にのみ作る べきです。

スコープを増やしすぎると運用が重くなるため、「何の判断に使うのか」が明確であることが重要です。

FinOps を「価値に結びつける」ために

FinOps のスコープは固定的なものではなく、ビジネス目標の達成や状況の変化に応じて見直されます。

コストを管理するためではなく、ビジネスの意思決定を前に進めるために FinOps を使う。そのための土台となる考え方が、FinOps のスコープです。

スコープは「何を判断するか」、技術カテゴリは「どの技術領域で判断するか」を整理するための視点であり、両者を組み合わせることで FinOps の実践範囲が明確になります。

技術カテゴリ

FinOps の技術カテゴリは、組織が IT リソースやサービスに支出する「技術の種類ごと」に、FinOps をどう適用するかを整理した分類 です。各カテゴリーは、調達モデル、課金体系、コスト可視化のしやすさ、運用特性が異なるため、それぞれに適した FinOps の考え方や実践が求められます。

FinOps の技術カテゴリは、単なる技術分類ではなく、

  • FinOps のスコープをどう定義するか
  • どの FinOps の機能が重要か
  • どのペルソナが関与するか
  • 成功を測る KPI・メトリクスは何か
  • 請求・利用データをどう統合するか

といった FinOps 実践の考慮点を、技術領域ごとに整理するための視点 として位置付けられています。

FinOps Technology Categories

5 つのカテゴリ

  • Public Cloud
    クラウドの従量課金を前提に、コスト効率・スケーラビリティ・開発スピードといったビジネス成果と支出を継続的に整合させます。
  • SaaS
    部門単位・分散的に購入されがちな SaaS の支出を可視化し、利用実態に基づく最適化と説明責任を強化します。
  • Data Cloud Platforms
    クエリやジョブなどの利用状況 (ワークロードテレメトリ) を基に、共有コンピュート環境でのコスト管理と意思決定を支援します。
  • Data Center
    オンプレミス環境において、設備投資・キャパシティ計画・利用状況の可視化を通じて、需要と投資の整合を図ります。
  • AI
    AI 特有のコスト複雑性や支出の予測困難性に対応するため、割り当て、予測、最適化、ガバナンスを重視したアプローチを取ります。

共通する考え方

どの技術カテゴリにおいても共通しているのは、FinOps の機能を活用し、利用量・コスト・ビジネス価値を継続的に結び付ける という点です。
また、異なる技術カテゴリのデータは、FOCUS (FinOps Open Cost and Usage Specification)4 を通じて統合し、横断的な可視化や分析を行うことが想定されています。

まとめ

FinOps は、クラウドのビジネス価値を最大化するための 運用フレームワークであり、同時に組織文化の変革を促す実践モデル です。エンジニアリング、財務、ビジネスの各チームが連携し、データに基づいた意思決定を行うことで、クラウドコストに対する説明責任と価値創出を両立させます。

その中核には 6 つの原則があり、個人やチームが自らのクラウド支出に責任を持つ文化を育成することが重視されています。また FinOps フレームワークは、原則、ペルソナ、フェーズ、成熟度モデル、ドメイン、機能といった要素で構成されており、組織の状況に応じて段階的に取り組みを進められる点が特徴です。

クラウド利用が当たり前となった現在、FinOps は単なるコスト削減手法ではなく、クラウド投資から継続的に価値を引き出すための組織的アプローチ として位置付けることが重要です。

また、FinOps フレームワークには スコープ と 技術カテゴリ という視点が加わり、クラウドだけでなく SaaS、データ基盤、AI、オンプレミスなど、多様な技術領域に FinOps を適用するための枠組みが整備されています。

これにより、FinOps は単なるクラウドコスト管理ではなく、組織全体のテクノロジー投資を価値に結び付けるための包括的なアプローチ へと進化しています。

「はじめに」でも触れたように、私自身、FinOps を学び直す中で、クラウドコスト管理を「削減」ではなく「価値創出」として捉える視点の重要性を改めて実感しました。この記事が、FinOps を理解し実践する際の一助になれば幸いです。

参考文献

  1. 「専門知識とベストプラクティスを集約し、組織全体に展開するための中核チーム」のこと。FinOps の文脈では FinOps CoE と呼ばれ、FinOps を組織に根付かせる「推進エンジン」の役割を担う。 ↩ ↩2

  2. 1 単位あたりの価値とコストの関係。クラウド支出をビジネス価値の単位ごとに結びつけて採算性を評価する手法。 ↩ ↩2 ↩3

  3. 組織の中で FinOps を「現場レベルで推進するキーパーソン」のこと。CoE (FinOps チーム) が「中枢」だとすると、Champion は「現場の伝道師・推進者」という位置付け。 ↩

  4. FinOps Foundation が主導する、クラウドや SaaS の利用料 (請求データ) を共通の規格 (標準スキーマ) で統一するオープンソースの技術仕様。 ↩

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?