クラウドの請求額は分かっても、「どの部門が利用し、誰が改善を決めるのか」が曖昧だと、費用の報告だけで会議が終わってしまいます。FinOpsを始めるときは、費用の見える化に加えて、利用の目的と変更の責任者を結び付けます。
FinOpsは、技術・財務・事業の担当者が協力し、データに基づいて技術投資の事業価値と費用への責任を管理する取り組みです。この記事では、運用中のクラウドを対象に、費用配賦、予測、改善の進め方を整理します。
FinOpsとは：費用を事業の判断につなげる取り組み
FinOps Foundationは、FinOpsを技術の事業価値を最大化するための運用フレームワークと文化的な実践と定義しています。対象はクラウドに限りませんが、ここではクラウド利用費に絞ります。目的は、必要な性能や事業の成果を踏まえて支出を判断できる状態を作ることです。
同財団の整理では、取り組みは次の3段階を繰り返します。
| 段階 | 意味 | クラウド費用で取り組むことの例 |
|---|---|---|
| Inform | 状況を把握する | 利用費を部門やサービスに対応付ける |
| Optimize | 改善案を選ぶ | 利用量や料金条件の見直し候補を比較する |
| Operate | 実行し改善を続ける | 承認した変更を実施し、結果を次の判断に戻す |
一度の削減作業で完了する仕組みではなく、把握・改善案の検討・実行を反復します。
以下の担当分担、会議頻度、確認表は、この考え方を企業で使うための編集上の運用例です。特定企業の実績や必須の標準手順を示すものではありません。
1．費用の責任者と変更の実行者を決める
最初に一つのサービスや部門を対象に選び、費用を判断する人と、設定変更を実行する人を記入します。少人数の組織では兼任しても構いませんが、誰が何を承認するかは分けて残します。
| 担当 | 決めること | 持ち寄る情報 |
|---|---|---|
| 事業・利用部門 | 必要な機能、利用拡大の予定、予算超過を受け入れるか | 利用目的、事業量、今後の施策 |
| 技術・運用担当 | 変更案、影響の確認方法、実施と切り戻し | 構成、利用状況、性能・可用性の要件 |
| 経理・財務担当 | 集計基準、予算との比較方法、部門負担の扱い | 請求額、予算、締め処理の条件 |
| 取りまとめ役 | 課題の担当割り当て、期限、次回の確認 | 未配賦費用、改善一覧、判断待ちの項目 |
「支払っている部門が、そのまま停止を判断できる」とは限りません。例えば共通基盤の費用を事業部へ配賦しても、変更前には基盤の運用担当と利用部門で影響を確認する運用にします。
外部へ作業を委託する場合も、変更案を作る範囲、実行を承認する自社担当、結果を報告する期限を決めておきます。クラウド運用全体の分担は、クラウドの責任共有モデルと自社に残る運用も参考にしてください。
2．費用を直接費・共有費・未配賦に分ける
配賦とは、費用を部門やサービスなどに割り当てることです。FinOps Foundationでは、アカウント構造、タグ、ラベルなどを使って費用を対応付ける考え方を示しています。共有費用には、固定配分、比例配分、利用状況を表す指標に基づく配分などがあります。
最初からすべてを部門へ割り振るより、次の3区分を明示してルールを合意する進め方を勧めます。
| 区分 | 分け方の例 | 決めておくこと |
|---|---|---|
| 直接費 | 専用アカウントやサービス名で対象を特定 | 負担部門と技術担当 |
| 共有費 | 共通基盤を利用量や合意した比率で配分 | 配分の根拠、見直す時期 |
| 未配賦 | 担当や用途を特定できない費用として残す | 調査担当と解消期限 |
共有費は、実測できる利用量があれば、その値を配分の候補にします。取得できない場合は、暫定的な比率と見直し日を記録してください。未配賦分を説明なく各部門へ均等に混ぜる運用は避けます。
また、最初は部門別の費用を共有するところまでとし、社内の予算振替や負担処理に使う段階は財務担当と別途合意すると、試行範囲を明確にできます。
3．総額・単位当たり費用・予測を一緒に見る
月額だけで評価すると、利用が増えたことによる費用増と、同じ仕事に余分な費用がかかっている状態を区別できません。FinOps FoundationのUnit Economicsでは、取引、顧客、サービスリクエストなどの単位で費用を捉える指標を扱っています。
例えば注文処理を対象にするなら、「対象費用÷同じ期間の処理件数」を見る方法があります。次は計算方法を示す仮定の例です。
| 月 | 対象費用 | 処理件数 | 1件当たり費用 |
|---|---|---|---|
| 前月 | 100万円 | 10万件 | 10円 |
| 当月 | 120万円 | 15万件 | 8円 |
総額は20％増えていますが、1件当たり費用は20％下がっています。この比較だけで最適と断定せず、予算内か、品質を維持できているかも併せて判断します。
比較する前に、共有費を含むか、値引きをどう扱うか、どの期間・サービスを対象にするかをそろえます。処理件数の定義も固定し、集計対象の変更があれば比較表に注記してください。
翌月の予測には、当月実績に加えて、利用増減の予定、新規リリース、一時的な移行作業、決定済みの変更を記入します。単純に当月額を延長する場合でも、「利用量は横ばい」などの前提を残すと、実績との差を振り返れます。
4．改善案に承認者・期限・確認方法を付ける
改善一覧は、金額の大きさだけで並べず、業務への影響と実行の条件を付けて比較します。次の表を会議のたたき台にしてください。
| 改善候補 | 実行前に確かめること | 実行後に確認すること |
|---|---|---|
| 利用していないリソースの停止 | 所有者、依存先、再開の必要性 | 請求への反映と業務影響 |
| 構成や容量の見直し | 繁忙時の負荷、必要性能、戻し方 | 費用と応答時間・エラーの変化 |
| 契約・料金条件の見直し | 対象範囲、適用条件、利用見通し | 実際の適用状況と総支出 |
| 共有費の配分ルールの変更 | 関係部門の合意、変更理由 | 部門間の比較可能性 |
配分ルールを変えてある部門の負担が減っても、それだけでは会社全体の費用削減にはなりません。報告では、総支出の変化と部門間の負担変更を分けて記載します。
各候補には、実行担当、承認者、期限、期待する効果、確認日を付けます。見込みの効果は実績と区別し、変更後の費用を確認する際には利用量や集計条件の変化も確認してください。
最初の改善サイクルで埋める確認表
まず一つの対象で以下を埋め、月次会議で継続して見直す形から始められます。想定外の費用増については、月次を待たずに連絡する条件と担当を別に決めます。
| 確認項目 | 自社で記入する内容 |
|---|---|
| 対象 | サービス名、アカウント、対象期間：＿＿ |
| 費用の判断者 | 利用部門の責任者、財務の確認者：＿＿ |
| 技術の実行者 | 変更担当、承認者：＿＿ |
| 配賦 | 直接費の判別方法、共有費の比率と根拠：＿＿ |
| 未配賦 | 金額、調査担当、解消期限：＿＿ |
| 指標 | 総額、単位当たり費用、守る品質条件：＿＿ |
| 予測 | 翌月の見込額、利用増減などの前提：＿＿ |
| 次の改善 | 一つ選んだ施策、期限、確認方法：＿＿ |
| 費用増への対応 | 連絡条件、通知先、判断期限：＿＿ |
| 次回確認 | 開催日、必要なデータ、持ち寄る担当：＿＿ |
担当が決まらない項目は、取りまとめ役が合意を取る課題として残します。FinOpsの最初の到達点は、請求額を眺める状態から、費用の理由と次の行動を関係者で決められる状態へ進むことです。