財務オペレーションとサステナビリティー

組織ごとに最適なFinOpsストラテジーは異なりますが、FinOpsの実装を成功させるには、常に人材、プロセス、テクノロジーに関する考慮事項を総合的に組み合わせる必要があります。そのため、特定のFinOps戦略や実践方法を設定する前に、組織とその作業方法を理解する必要があります。

FinOpsを運用モデルに統合するための共通要素には、財務チーム、アカウント・チーム、調達チーム、ITチーム、ビジネス・チームなどの利害関係者間のコラボレーションが含まれます。これにより、クラウドの需要、要求されたクラウド・リソースを把握し、クラウド・リソースの使用を最適化するという継続的なライフサイクルが可能になります。さらに、FinOps導入の成功を妨げる知識のサイロ化を防ぐことができます。これは、チームは協力する必要があるという原則の一環としてFinOps基盤によりさらに理解を深められます。

チームが協力してFinOpsをより良く実践し、効率性とイノベーションにおいて継続的な改善を遂げることが不可欠です。機能横断的なチーム間のコラボレーションにより、財務部門はIT部門のスピードと粒度に合わせられるようになり、エンジニアは他の効率性指標と同じようにコストを扱うことができるようになり、クラウドの使用に関する標準化されたガバナンスと管理体制が確立されます」

要約すると、FinOpsの全体的な対応には、標準的な役割、責任、プロセス、メトリクス、ツール、ガバナンス、イネーブルメントを詳述する統合運用モデルが必要不可欠です。

FinOpsは一般的に、動作とプロセスに焦点を当てており、テクノロジー層から独立しています。つまり、インフラストラクチャー、プラットフォーム、ミドルウェア、アプリケーション／サービスの各チームは、すべて同様の要件を適用して、それぞれのソリューション領域で効率化を図ることができます。しかし、組織内の利害関係者は、FinOpsを成功させる上での自分の役割を理解していない可能性があります。

クラウド・ストレージ・コストの最適化や管理など、明確なFinOps目標を設定したり、特定のFinOps目標メトリクスを伝えたりすることで、組織は各利害関係者が自らの業務に適用できる具体的な対策やアクションを導き出すことができます。

この原則は、より良い意思決定を行うために利用できるコスト要因と資産を認識している、コスト意識の高い組織を構築するという目標の広範な一部です。理想的な状態を達成するには、レポートはアクセス可能でタイムリーである必要があるというFinOpsの原則で言及されているように、常にタイムリーなデータを収集して公開する必要があります。これにより、チームは実際の使用状況データに基づいて正しい意思決定を行えるようになります。詳細については、FinOps Foundationの意思決定の原則を参照してください。意思決定はクラウドのビジネス価値に基づいて行われます。

FinOps導入における最も一般的な課題の1つは、ストラテジーと目標をチームの行動に整合させることです。その結果、組織はプロセスとガードレールを実装して、望ましいFinOpsの行動を導く必要があります。例えば、変動コストの管理、ジャストインタイムのリソース調達、リーン・リソース管理などの実践を奨励し、実施する方法を確立します。

このFinOpsガバナンスは、予期せぬ事態にならないように、関係するすべてのチームが定義し、合意する必要があります。ガバナンスはFinOpsのボトルネックではなく、チームが特定のシナリオにあるときにガイドするレーンであることが重要です。

例えば、組織はチームが特定のクリップ・レベルまたは予算ガイドライン以下のクラウド・リソースを自由に選択できる柔軟性を提供するポリシーを開発できます。このようにして、ガバナンスは適切な行動を報い、最も安価なオプションではなくても、特定のクラウド・インスタンス・タイプを選択する真の理由がある可能性があるため、FinOpsはクラウド支出を削減する手段に過ぎないという誤解を解消することができます。FinOpsの文脈における個人の行動の詳細については、FinOps Foundationの原則（「全員がクラウドの使用量に責任を負う」）を参照してください。

FinOpsの成熟度のコンテキストでは、クリティカルな最終状態には、オートメーションを使用して、シナリオに対応するだけでなく、事前にアクションを実行することが含まれます。組織は、分析に基づく自動最適化を目指す必要があります。例えば、適切なツールを使用して、使用状況メトリクス、支出、使用率などを監視します。

FinOps Foundationの原則で定義されているように、「クラウドのコスト変動モデルを活用する」というものです。クラウド支出から最大限の価値を引き出すには、企業がクラウド・コスト・モデルにおけるコスト削減の機会を活用する必要があります。これには、クラウドの料金体系のオプションと使用量割引の比較、購入したインスタンスおよびサービスのクラウド適正化が含まれます。

これを手動の方法で完了するのは難しいため、組織は新しいFinOpsプラクティスを試験的に導入し、拡大する際に自動化バイアスを採用する必要があります。自動化は、概念上のFinOpsフレームワークの以下の要素に焦点を当てる場合があります。

• インストルメンテーション：使用状況を追跡および記録するためのデータ収集を支援するツール。

• タグ付け：使用状況の説明責任のためのツール。

• 調達：契約に関するクラウド固有の慣行を修正し、実施するためのツール。例えば、契約構造、料金体系など。

• レポート/請求：クラウドのコストを追跡、予測、請求するためのツール。

• ソリューションの効率性：ソリューション設計プロセスを最適化するツールと、効率的に設計するための適切に設計されたフレームワーク。

組織の既存のサステナビリティー戦略の一環として、チームが達成を目指す特定のメトリクスや成果がある場合があります。ITに影響を与えないものもありますが、排出削減目標、効率目標、ベンダーの優先事項など、ITおよびクラウドの決定に関連するより広範なガイドラインがあります。チームはこれらの目標を認識するだけでなく、ビジネスやワークロードの性能が影響を受けないよう、クリティカルな要件と目標のバランスもとる必要があります。以下の例を参照してください。

1. ワークロード配置：
   • 排出量の少ないデータセンターを選択する
   • よりレイテンシーの優れたデータセンターを選択する
2. 効率的なハードウェア：
   • コンポーネントを更新して電力消費量を削減する
   • コンポーネントの使用を延長してビジネス価値を向上させる
3. コード効率
   • 独立してスケーラブルなコード機能を実行することで、リソース使用率が低くなる
   • セキュリティーとユーザー・エクスペリエンスに関する考慮事項によりグループ化されたアプリケーションを実行する

この違いを認識することで、チームは意思決定を評価し、競合する優先事項を含む可能性のある視点のバランスを取ることができます。また、ある選択が別の選択よりも重視される場合、推論を備えた目的のある意思決定が生まれます。

クラウドなどの事前開発された「as a Service」機能の利用が増えていることを考えると、組織は、サステナビリティー・バイ・デザインを確保するために、積極的な視点を持つ必要があります。これには、最初から要件を考慮するために、調達ライフサイクルにサステナビリティー目標を適用する必要があります。以下に例を示します。

1. ソリューション設計：再利用と無駄の最小化を促進する効率的な設計を確立します。
2. 要件定義：特定のサステナビリティー基準と認証を満たすための義務を組み込む（例えば、ISOや持続可能な開発目標など）。
3. パートナー／ソリューションの選択：サステナビリティー目標と実績のあるソリューションを優先します。
4. 運用：無駄を削減するためのガバナンスの活用を奨励するなど

サステナビリティーの向上を目指すチームにとって、基本的な出発点は、影響を測定し、追跡することです。これは、さまざまな方法、ツール、プロセスなどを使用して実行できますが、サステナビリティー関連の行動を推進し、進捗状況を測定する方法として、ベースラインを確立することが重要です。

影響は、質的データまたは量的データを介して追跡でき、組織が定義したストラテジー目標と一致します。測定とベンチマーキングに加えて、このタイプのデータは投資決定に不可欠です。チームはさまざまなメトリクスを活用してリソースを正当化し、将来の取り組みを予測することができます。

最後に、インパクト・データは組織の外部にも影響を与える可能性があります。さまざまな政府および非政府のポリシーの一環として、サステナビリティー・データは、規制コンプライアンスを確認し、ESGイニシアチブへの取り組みを伝達するためにますます使用されるようになっています。最終顧客は、このデータを使用してパートナーシップの決定を下すこともできます。

FinOpsの戦略、ポリシー、ガバナンスは、説明責任を負う単一の集中チームによって推進されるべきです。これにより、焦点が最大限に明確になり、FinOpsの成功に不可欠なデータの正確性が促進されます。注：この一元化されたチームは、適切な結果を得るために多数の責任者と協力します。また、クラウドの料金体系交渉の一環として利用できる、より優れた相乗効果も実現します。

デプロイメントでは、タグ付けとアカウント階層をサポートして、使用量の割り当てと可視性を向上させる必要があります。タグ付けは、インスタンスを分類およびグループ化し、チーム、製品、事業単位などの全体的な使用状況の集約を可能にする方法です。例えば、人事、会計、エンジニアリングなどの特定の分野のコスト最適化と可視性向上を可能にするために、ワークロードに担当事業部門を割り当てるための必須タグなどです。

アカウント階層とは、組織の構造を模倣するためのユーザー・アカウントとインスタンス・アカウントの設定を指します。これにより、特定のアカウントと責任ある所有者の間での使用状況のマッピングと追跡が容易になります。

タグ付けとアカウント構造を組み合わせることで、予算や予測に沿って、カテゴリーごとのコストが可視化されます。

展開は、コストと使用量の自動化されたデータを使用できるように、厳選されたITコスト管理ツールと統合する必要があります。他のオブザーバビリティーに重点を置いたユースケースと同様に、データの可用性はボトルネックではなく、代わりにチームはシステム間で財務データを統合し、適切なユーザーに割り当て、FinOpsレポートを作成する方法が制限されることがよくあります。FinOpsのスタートアップ企業の一環として自動化に重点を置くことで、タスクをワークフローの一部として設計できるため、FinOpsの価値を簡単に証明し、チームをより付加価値の高いタスクに専念させることができます。

クラウドのコストが高くなる一般的な要因の1つは、実験のために非実稼働のクラウドのリソースが稼働することです。また、より低階層で十分な場合、ユーザーはクラウド・サービスの最大インスタンスを選択できます。これを防ぐには、ユーザーがクラウド・サービスのリストから自由に選択できる事前承認されたサンドボックス・タイプの環境を実装し、自動再生によって不必要なアップタイムを防ぎます。

これにより、チームはインフラストラクチャーやプラットフォームの機能を試用し、付加価値のない請求を最小限に抑えながらコストを管理することができます。

ミドルウェア/アプリケーション/サービスの種類に応じて、使用コストのきめ細かさとレポート作成を可能にするために、「as a Service」の考え方でデプロイメントを設計する必要があります。

これは、FinOpsを念頭に置いて構築される新しいサービスにとって特に重要です。チームはまず、各層のどのコンポーネントがコスト最適化の適用可能なターゲットかを特定する必要があります。これは、経理および財務チームによって決定された個別の責任者または会計カテゴリーに特定のコンポーネント・サービスをタグ付けまたは割り当てることができるかどうかによって決定されます。次に、コンポーネントには、消費ベースの料金体系を可能にするために、関連するコスト要素を関連付ける必要があります。

標準的な定義、用語、メトリクス、レポートを定義し、チームがこれらの概念を適切に適用して、信頼性の高い成果を生み出せるようにする必要があります。メトリクスは、ベンチマークと意思決定を可能にするため、特にクリティカルです。

組織は、コストを意識した文化を創造し、各チーム・メンバーがFinOpsとは何か、それが組織にどのような影響を与え、正しい成果を達成するためにどのような手順を踏むことができるかを理解する必要があります。これには、フルロードコストを理解し、リソースを適正化するための決定が含まれます。

一般的な出発点は、チームが発生したコストを認識する方法であるショーバックや、発生したコストを正式にチームに請求する必要があるチャージバックを確立することです。これは通常、適切な財務および会計チームと連携して、特定のサービスのコストを集約し、適切な部門に割り当てることで実現されます（リソース別、チーム別、ユーザー別など）。

より広範なFinOps戦略、ポリシー、ガバナンスの一環として、プラットフォーム、アプリケーション、データ、運用、人材と文化などの分野のサステナビリティー目標を定義し、優先順位を付けます。これにより、チームは定量化可能なデータを通じて進捗状況を測定および追跡することができ、個人が何に影響を与えることができるかを理解できるため、ビジネスのあらゆる部分にわたる利害関係者に対してサステナビリティー関連の説明責任を確立することができます。

例：

• プラットフォームとインフラストラクチャー：炭素排出量と環境関連のパッケージングの影響の目標
• アプリケーション：エネルギー使用量の目標
• 人材：人材発掘など、社会的影響の対象

エンタープライズ・アーキテクチャー・チームのために、サステナビリティーの視点を確立します。ビジネス・チームは、クラウド・ソリューションを設計するときにクリティカルなパートナーです。独自の立場で、ワークロードの配置を考慮した、より効率的なソリューション設計を指導し、影響を与えます。

エンタープライズ・アーキテクトが影響を与える可能性のある決定の例には、次のようなものがあります。

• ESGスコアが高いデータセンターの選択、または環境認証を取得しているデータセンターの選択
• インスタンスのサイズが過大にならないように最適なリソースを選択する
• コードを改良して不要なオペレーションを削除したり、プロセスを最小限に抑えたりすることによるソリューション設計の最適化

チームが幅広くアクセスできる主要なメトリクスを備えたサステナビリティー・ダッシュボードを開発・公開しましょう。チームが特定の目標を達成するために必要に応じて方向転換できるように、現在の状況と将来の目標をShowCaseすることに重点を置きます。さらに、これは全体的な影響とサステナビリティー戦略への整合性を理解するためにも重要です。

ダッシュボードは、多くの規制当局や非政府組織が持続可能性の影響と進捗状況を理解するために要求している報告も容易にします。

最後に、ダッシュボードは、サステナビリティーへの取り組みや、目標達成に向けた直接投資の価値を証明するのにも役立ちます。