トピック6.5 — テクノロジーコストの管理とクラウドFinOps

医療・ケアにおいて、テクノロジーの運用コストは、誰かが見ていようといまいと、毎時間費やされる公金です。したがって、そのコストを管理すること、特にクラウドでは、年次の財務の作業ではなく、スチュワードシップの運用上の規律です。

医療・ケアにおいてなぜ重要か#

NHSのテクノロジーの歴史の大半において、お金は一度だけ費やされました。サーバー、ストレージアレイ、ライセンスを購入し、資産計上し、それはラックの中で、5年間静かに減価償却されました。コストは見えて、限られ、おおむね固定されていました。クラウドコンピューティングが、そのモデルを壊しました。いまや、メーターは継続的に回り、請求額は日ごとに変わり、エンジニアによる何千もの小さな判断が本物のお金を動かし、請求書は、支出がすでに終わった1か月後に届きます。祝日の週末に動き続けていた誤設定のジョブ、誰も止めなかったテスト環境、静かに膨らむストレージのバケット。それぞれが、リアルタイムで漏れる公金です。

これが医療・ケアで重要なのは、通常の倹約を超えた三つの理由からです。第一に、それは、信託されて保有される公金です。遊休の計算資源や重複したソフトウェアのライセンスに費やされるあらゆるポンドは、ケアに費やされなかったポンドであり、あなたは、監査人、取締役会、そして最終的には国民に対して、それに説明責任を負います（トピック6.4 — ガバナンスと保証参照）。第二に、お金は特有の規則に従います。NHSの予算は、資本と収益の間で厳しく分けられ、資産の購入からサービスの賃借への移行は、一方を他方へと静かに変換します。財務取締役を不意打ちしうる、予算上の帰結を伴う技術的な判断です。第三に、管理されないコストは、変装した安全と継続性のリスクです。驚きの請求書を恐れるチームは、レジリエンスを過少に用意し、パッチを遅らせ、あるいは安全なサービスが必要とする環境を運用する余裕を持てません。

その失敗パターンは特徴的で、よく見られます。組織は、節約を期待してクラウドに移行し、移行を祝い、そして18か月後、請求額が、置き換えたデータセンターより大きいことを発見し、その理由を誰も言えません。問題は、技術であることはめったにありません。誰も運用コストを、生きた規律として所有していないことです。エンジニアは納品の速さを最適化し、財務は単一の不透明な請求書を見て、設計上の判断とそのコストの間のフィードバックのループは、決して閉じません。本トピックは、そのループを閉じることについてです。

中核概念#

クラウドコンピューティングは、サーバー、ストレージ、データベース、ネットワークという計算資源を、所有する機器ではなく、オンデマンドで従量課金のサービスとして提供します。その決定的な商務上の特徴は弾力性です。数分でキャパシティを獲得し、解放でき、消費したものにだけ支払います。その同じ弾力性が、コスト管理を難しくする理由です。クラウドとレガシーの技術アーキテクチャはトピック4.0で扱います（トピック4.0 — 技術アーキテクチャ、クラウド、レガシーシステム参照）。本トピックが扱うのは、そのアーキテクチャが稼働したあとのコストに何が起きるかです。

中心的な会計上の変化は、資本的支出（capex）、つまり、固定資産を取得するために費やされ、その後何年かにわたって減価償却されるお金から、営業費用（opex）、つまりサービスを運用する継続的なコストへの移行です。サーバーを購入するのはcapexで、同等のクラウドのキャパシティを借りるのはopexです。NHSでは、これは中立的な簿記上の詳細ではありません。資本と収益は、別々に配分され、別々に管理され、ほとんど互換性がないため、支出をcapexからopexへ移すことは、一つの圧力を和らげながら、別の圧力を生みます。これらの選択の前もっての評価、つまりFive Case Modelや資本と収益の基本は、財務管理とビジネスケースに属します（トピック6.0 — 財務管理とビジネスケース参照）。本トピックは、ビジネスケースが終わり、メーターが始まるところから引き継ぎます。

FinOpsは、「クラウド財務オペレーション」の短縮形で、エンジニアリング、財務、事業のチームを結びつけ、クラウドのコストを、共有された、データに基づく責任として管理する、運用の規律です。Linux Foundationの一部であるFinOps Foundationによって推進され、通常、三つの反復的なフェーズを持つライフサイクルとして説明されます。Inform（配分と報告を通じて、何が、なぜ費やされているかを全員に見えるようにする）、Optimize（その可視性に基づいて、無駄を排除し、より安く買うために行動する）、Operate（コストの意識を日常の働き方とガバナンスに組み込む）。FinOpsは、意図して、単なるコスト削減ではありません。その目標は、クラウド支出の1ポンドごとの事業価値を最大化することで、リターンが正当化するため、ときには、より多く支出することを意味します。

二つの配分の仕組みが、コストを見えるようにします。ショーバックは、各チームやサービスに、そのテクノロジーの消費がいくらかかるかを、透明性と行動の変化のために、お金を動かさずに報告します。チャージバックはさらに進んで、消費する部門の予算から、実際にコストを回収します。共有サービスのコストを、それを消費するコストセンターに割り当てる、内部のコスト配分の一形態です。どちらもタグ付けに依存します。あらゆるクラウドのリソースに、メタデータ（サービス、チーム、環境、患者に面するか否か）のラベルを付け、区別のない請求書を意味のある行に分割できるようにします。

さらに三つの考え方が、本トピックを貫きます。総所有コスト（TCO）は、テクノロジーの全生涯にわたる、直接および間接の完全なコストで、ライセンスや計算資源だけでなく、その周りの人、連携、サポート、退出、廃止を含みます。ソフトウェア資産管理（SAM）は、組織が所有し、借りているソフトウェアを追跡し最適化する規律で、ますます、SaaSのサブスクリプションと、静かに更新されるユーザーごとのソフトウェアライセンスに支配されています。そしてユニットエコノミクスは、コストを、組織が気にかけるものに対する比率、つまり患者あたり、予約あたり、紹介あたり、API呼び出しあたりで表し、増える請求書を、真空の中ではなく、増える価値に照らして判断できるようにします。負荷に合わせてキャパシティを自動で調整するオートスケーリングと、ITILのより広い財務管理の実践は、運用上の梃子として、これらと並びます。

ベストプラクティス#

1. 削減しようとする前に、コストを見えるようにする。まずInformである。 誰にも見えないものは管理できず、既定のクラウドの請求書は、1か月遅れて届く単一の不透明な数字です。サービス、チーム、環境、そして可能なら臨床サービス別に分解された、ほぼリアルタイムのコストの可視性を確立し、設計の判断を行う人々が、それらの判断のコストを、四半期ではなく数日で見られるようにします。可視性だけで、行動は変わります。自分たちの支出を見られるチームは、中央の財務報告が決して捉えなかったであろう無駄を、日常的に見つけます。

2. すべてにタグを付け、タグのない支出を欠陥として扱う。 コストの配分は、その下のメタデータと同じだけ優れています。タグのないリソースは、帰属させられず、疑問を呈せず、取り戻せないお金です。必須のタグ付けの標準、つまり所有者、サービス、環境、コストセンター、データの分類を合意し、非準拠のリソースが作成時にフラグ付けまたはブロックされるよう、自動化された方針で徹底し、適切に配分された支出の割合を、見出しの指標として報告します。医療の文脈では、ワークロードが、患者に面するか、臨床上重要かをタグ付けすることで、残りを最適化するときに、適切なものを守ることもできます。

3. ショーバックかチャージバックかを意図して選び、説明責任に合わせる。 ショーバックは、コストの意識を穏やかに築き、ほとんどの組織にとって適切な出発点であり、チャージバックは、本物の予算上の帰結を生みますが、成熟した配分と、数字を擁護する政治的な意思を必要とします。どんな行動を生みたいのか、つまり意識か、本物の財務上の所有かを決め、不安定なデータでの時期尚早なチャージバックが、取り組み全体の信用を損なう紛争を生むことを認めてください。どちらを選んでも、目的は、チームの判断が、自分のものと認識する予算に目に見えて影響する、閉じたループです。

4. 無駄を容赦なく排除する。適正サイズ化、スケジュール、削除。 ほとんどの環境で、クラウド支出の大きな部分は、純粋な無駄です。過剰にプロビジョニングされたインスタンス、大きすぎるデータベース、孤立したストレージ、そして9時から5時のチームのために24時間動く本番以外の環境。推測したピークではなく、観測された負荷に合わせてリソースを適正サイズにし、開発とテストの環境を夜間と週末に停止するようスケジュールし、ストレージとスナップショットにライフサイクルを設けて、何も永遠に蓄積されないようにします。これは、利用できる最も速く、最もリスクの低い節約であり、自動化すれば毎月繰り返されます。

5. 予測可能なベースラインには、コミットしたキャパシティを購入する。 クラウドの提供者は、リザーブドインスタンス、セービングプラン、コミットした利用の合意を通じた、1年または3年のコミットメントと引き換えに、しばしば大幅な割引を提供し、医療サービスの安定したベースライン（中核の電子患者記録、常時稼働する連携エンジン）は、まさにこれらの仕組みが報いる、予測可能な負荷です。安定した利用を分析し、割引を得るためにそれにコミットし、その上の変動するピークには、オンデマンドやオートスケールのキャパシティを残します。すでに再設計して不要になったキャパシティをロックインしないよう、コミットメントを定期的にレビューし、購入を調達と商務の同僚と調整します（トピック6.3 — 調達と商務参照）。

6. SaaSとライセンスの乱立を、クラウドの計算資源と同じくらい意図して管理する。 クラウドの請求書は見えますが、部門のカードで購入された20のSaaSのサブスクリプション、退職者に割り当てられたままのユーザーごとのライセンス、同じ仕事をする重なったツールは見えず、それでも合わせると、しばしばインフラの支出に匹敵します。ソフトウェアのサブスクリプションと権利の生きた台帳を維持し、ライセンスを実際の名前のあるユーザーと利用に照らして突き合わせ、使われないものを解約またはダウングレードし、重複するツールを統合します。ここでのソフトウェア資産管理は、コストの規律であると同時に、セキュリティの規律でもあります。未知のSaaSは、管理されないデータの流れでもあるからです（トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティ参照）。

7. 請求書の大きさではなく、ユニットエコノミクスでコストを判断する。 増える請求書が自動的に悪いわけでも、減る請求書が自動的に良いわけでもありません。重要なのは、届けられる価値に対するコストです。臨床的・運用的に意味のあるユニットコストの指標、つまりモニタリングされた患者あたり、予約あたり、処理された紹介あたり、1,000回のAPI呼び出しあたりのコストを定義し、時間とともに追跡して、効率を単なる成長から区別し、その分の価値を本当に稼いでいる支出を擁護できるようにします（トピック6.2 — 便益実現と価値マネジメントおよびトピック10.1 — KPI参照）。ユニットエコノミクスは、運用コストを、サービスのヘルスエコノミクスのケースに結びつけ直す方法でもあります（トピック6.1 — ヘルスエコノミクス参照）。

8. 退出を含め、環境全体にわたる総所有コストで考える。 プラットフォームの定価は、その生涯コストのほんの一部です。連携、データ移行、サポート職員、研修、データ転送料金、そして最終的に離れるコストは、すべて、その像に含まれます。現実的な寿命にわたる総所有コストで選択肢を評価し、データ転送料金や、退出のコストを上げる独自のサービスに特に警戒し、ロックインが、今日は無料に見えても、将来のコストであることを思い出してください（ロックインの契約上の側面は調達が所有します。トピック6.3 — 調達と商務参照）。TCOの視点は、組織が、運用が静かに高価な、安いプラットフォームを自画自賛するのも防ぎます。

9. コストをエンジニアリングとガバナンスに組み込み、継続的に機能させる。 FinOpsは、四半期ごとの片づけのキャンペーンであるときに失敗し、コストが、設計レビュー、アーキテクチャの判断、デリバリーのパイプラインで、常設の考慮事項であるときに成功します（トピック3.6 — DevOpsとエンジニアリングの卓越性参照）。チームにコストの予算と異常のアラートを与え、重要なアーキテクチャの判断に見積もりのコスト影響を入れ、暴走したジョブが、翌月の請求書ではなく数時間で捕捉されるよう、自動のアラートと厳しい支出のガードレールを設定します。Operateのフェーズの目標は、コストの意識が、外部の監査ではなく、通常のエンジニアリングの衛生になることです。

10. コストだけでなく、臨床的な価値と持続可能性とのバランスを取る。 最も安い選択肢が、常に正しいとは限りません。レジリエンスを取り除き、パッチを遅らせ、あるいは患者に面するサービスを劣化させる積極的な節約は、お金を、誤った方向のリスクと交換しています。コストの判断を、臨床的な価値と、炭素に対して明示的に比較考量してください。無駄として排除する計算資源は、回避される排出でもあり、コストと持続可能性の最適化は、しばしば同じ方向を向きます（トピック8.5 — 持続可能性とネットゼロ参照）。コストの圧力が、安全を静かに損なうに任せるのではなく、トレードオフを見えるようにし、所有してください。

チームで話し合うための問い#

1. 私たちのテクノロジーの運用コストを、実際に誰が所有しているか。そして、その所有者は、それを変えるための可視性と権限の両方を持っているか。 これが重要なのは、所有者のいないコストが、チェックされずに増えるコストだからです。エンジニアは納品を最適化し、財務は一つの請求書を見て、その間のギャップに誰も説明責任を負いません。コストの所有が、エンジニアリングの判断に影響できない中央の財務チームにあるのか、請求書を見られないエンジニアにあるのか、理想的には、両方にまたがる共同の能力にあるのかを議論します。所有者が実際に行動できるかを探ります。遊休の環境を止められるか、タグのないリソースをブロックできるか、不必要に高価な設計を拒否できるか。それとも、お金が費やされたあとに報告できるだけか。医療特有の緊張を考えます。コストの所有者は、節約の名のもとに、臨床安全や継続性を損なうことが決してあってはならず、ではそのガードレールはどこにあるのか。良く誠実な答えは、特定の説明責任のある所有者または場を挙げ、それがほぼリアルタイムの可視性と本物の意思決定権を持つことを確認し、今日の答えが「請求書が届いて、私たちが支払うだけ」であるところを率直に認めます。

2. 私たちのクラウドとソフトウェアの支出のどれだけが、本当に価値を届けているか。そして、どうやってそれを知るか。 ほとんどの組織はこれに答えられません。総額の請求書は追跡しても、それが買う価値は追跡しないため、あらゆるコストが、等しく正当化される、あるいは等しく疑わしく見えるからです。支出を、臨床的または運用的な何か、つまり患者あたり、予約あたり、API呼び出しあたりのコストに結びつける、ユニットコストの指標があるのか、上がっていく区別のない数字しかないのかを話し合います。コスト削減と価値の間のトレードオフを表に出します。目的は、最小の請求書ではなく、最良のリターンであり、それは、明らかにそれを稼ぐサービスに、ときにより多く支出することを意味します。支出のどれだけが、測定可能な無駄、つまり遊休の環境、過剰にプロビジョニングされたインスタンス、退職者のライセンスで、どれだけが本当に生産的な負荷かを考え、その割合にどれだけ自信があるかについて誠実になります。良い答えは、エビデンスで無駄を価値から区別し、少なくともいくつかの本物のユニットエコノミクスの指標を持ち、小さな請求書が自動的により良いという反射に抵抗します。

3. 支出を資本から営業費用へ移したとき（あるいは移すとき）、予算上・長期的な帰結を誰が理解していたか。 capexからopexへの移行は、しばしば純粋に技術的な移行として扱われますが、それは、お金がどの予算から出るかを変え、一回限りのコストを恒久的に繰り返すものに変換し、組織を何年にもわたる増え続ける負債へ、静かにコミットさせえます。コミットする前に、財務とデジタルのチームが共同でこれをモデル化したか、つまり誰かが、複数年のopexの軌跡、退出のコスト、そしてNHSが厳しく管理する資本と収益のバランスへの影響を描き出したかを議論します。誠実さの罠を考えます。クラウドの移行は、しばしば、規律あるコスト管理を前提とした節約で売り込まれ、それが決して実現しません。あなたのビジネスケースは、実際に築いたFinOpsの能力に基づいていたか。繰り返される請求書が、それに資金を出す予算より速く増えたとき何が起き、そのとき誰が説明責任を負うかを探ります。良い答えは、移行の速さを最適化する技術チームに、財務があとから帰結を発見させるのではなく、財務とデジタルが、ライフサイクル全体について一緒に推論していることを示します（トピック6.0 — 財務管理とビジネスケース参照）。

4. 暴走したコストが、翌月の請求書ではなく、数時間で捕捉されると、どれだけ確信できるか。 従量課金のクラウドの決定的なハザードは、誤りとその発見の間の遅延です。誤設定のジョブ、誤った過剰プロビジョニング、動き続けるテスト環境は、月次の請求書がそれを明らかにするまで、何週間も静かに公金を燃やしえます。行動できる人々に結びつけられた、異常のアラートと厳しい支出のガードレールがあるのか、検知の仕組みが、1か月遅れて届く請求書だけなのかを話し合います。本当に無駄を止めるガードレールと、誤ったタイミングで正当な臨床のワークロードを絞めるほど積極的な統制のバランスを探ります。狼少年のアラートはすぐに無視され、安全なサービスをブロックするガードレールは、それが防ぐ支出より悪いからです。午前2時に異常のアラートを受け取るのは誰か、そして、患者に面する何かを壊すことを恐れずに、それに行動する権限と自信の両方を持っているかを考えます。良い答えは、時間で測られる、テストされた検知と対応のループを説明し、誰がそれを所有するかを挙げ、過去の驚きのうち、請求書が届いて初めて見つかったものがいくつあったかについて誠実です。

5. 私たちは、見えないソフトウェアにどれだけ支払っているか。そして、誰も使わないツールのサブスクリプションが更新されたら、誰が気づくか。 クラウドの計算資源の請求書は、少なくとも見えますが、部門のカードで購入されたSaaSのサブスクリプション、退職者に割り当てられたままのユーザーごとのライセンス、同じ仕事をする重なるツールの乱立は見えず、それでも合わせると、しばしばインフラの支出に匹敵します。実際の名前のあるユーザーと突き合わされた、ソフトウェアの権利の生きた台帳を持っているのか、全体像を誰も所有しないために、更新が黙って通過しているのかを話し合います。コストの側面だけでなく、セキュリティの側面も表に出します。未知のSaaSは、管理されないデータの流れでもあるため、影のソフトウェアは、お金の漏れであると同時に、情報ガバナンスのギャップです（トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティ参照）。これが起きる組織的な理由を考えます。分権化された予算と簡単なカード払いが、ソフトウェアを入手することを摩擦なしにし、廃止することをほぼ不可能にし、誰かが総額に説明責任を負うために、何が変わらなければならないか。良い答えは、環境のソフトウェア支出のどれだけが本当に対応づけられているかを認め、意図したツールを、蓄積した乱立から区別し、実際に何かを解約した突き合わせを示せます。

6. コストの圧力と臨床安全が、反対方向に引くとき、どうやって安全が勝つことを確実にするか。そして、そうなったことを証明できるか。 本トピックのあらゆる最適化の梃子、つまり適正サイズ化、停止、支出の先送り、最も安い選択肢の購入は、不注意に適用されれば、レジリエンスを取り除き、パッチを遅らせ、あるいは患者に面するサービスを劣化させ、まさに誤った方向で、お金をリスクと交換しえます。コストの判断が、明示的な安全のチェックを伴っているか、つまり臨床上重要とタグ付けされたワークロードが、何かが触れる前に別途レビューされるのか、コストの目標が、安全を静かに見えなく損なうに任されているのかを議論します。通常、対立するのではなく整合する、持続可能性の側面を考えます。無駄として排除された計算資源は、回避された炭素でもあり、コストとネットゼロの最適化は、しばしば同じ方向を向きます（トピック8.5 — 持続可能性とネットゼロ参照）。しかし、両者が乖離し、何かが譲らなければならないケースについて、誠実になってください。節約の目標とレジリエンスの要件が衝突したとき、誰が線を守るか、そのトレードオフが、目に見えて所有されるのか、予算の圧力の下で静かに行われるのかを探ります。良い答えは、安全と継続性を、コストが覆してはならない制約として扱い、請求書が増えると曲がる、述べられた価値だけでなく、それを徹底する本物の仕組みを示します。

実践例：医療・ケアの事例#

Northmarsh統合ケアシステムは、分析プラットフォーム、いくつかの患者に面するサービス、大規模なデータレイクを、2年かけてパブリッククラウドへ移行しました。置き換える老朽化したデータセンターに対して、ささやかな節約を約束するビジネスケースによって資金が出されました。移行は期限どおりに納品され、祝われました。18か月後、月次のクラウドの請求書は、ビジネスケースの数字のほぼ2倍で推移し、四半期ごとに増えており、財務取締役が、デジタルチームに増加を説明するよう求めたとき、誰もその数字を分解できませんでした。請求書は、提供者からの一行で、その下のどれにもタグが付いていませんでした。

取締役会は、一律のコスト削減の命令ではなく、小さなFinOpsの取り組みを委託しました。その最初の仕事はInformでした。チームは、コストの可視化ツールを立ち上げ、タグ付けの標準を義務づけ、6週間かけて、リソースにタグを遡って付け、それらを所有するサービスと突き合わせました。現れた像は、見慣れたものでした。データサイエンスチームの開発とテストの環境、つまり大きく高価なインスタンスは、誰も使わない夜間と週末を含め、継続的に動いていました。移行されたデータレイクは、ライフサイクルの方針なしに、プレミアムのストレージへそのまま移されていたため、5年分の置き換えられたスナップショットが、満額で蓄積していました。三つの別々のチームが、異なる予算で購入された、重なるSaaSのアナリティクスのツールに支払っていました。そして、移行中に誤設定されたバッチジョブが、何か月も、同じデータセットを毎晩再処理していました。

Optimizeのフェーズは、意図してリスクによって段階化されました。本番以外の環境は、勤務時間外に停止するようスケジュールされ、臨床への影響がまったくないまま、大きな繰り返しの金額を節約しました。ストレージは階層化され、ライフサイクルが与えられ、古いスナップショットが自動で期限切れになりました。常時稼働する患者に面するサービスの、安定したベースラインの負荷が分析され、調達の同僚と交渉した、3年のコミットした利用の割引でカバーされました。重複するSaaSのツールは、一つに統合されました。決定的に、患者に面する、あるいは臨床上重要なワークロードに何かが触れる前に、そのタグが、別個の慎重なレビューのためにフラグを立てました。コストが、安全やレジリエンスを覆すことは、決して許されませんでした。

そして、最も重要なOperateが来ました。各サービスチームには、月次のショーバック報告書とコストの予算が与えられ、異常のアラートが、突然の跳ね上がりを数時間以内にフラグ付けするよう結びつけられ、新しい設計が、見積もりの運用コストを伴うよう、軽量なコストのチェックが、アーキテクチャレビューのチェックリストに加えられました。2四半期のうちに、請求書は元のデータセンターのベースラインを下回り、さらに重要なことに、謎ではなくなりました。あらゆるポンドが、サービスに帰属でき、ICSは、いまや、分析プラットフォームの、アクティブユーザーあたりのコストを報告し、それを価値として擁護できました。節約は本物でしたが、持続的な勝利は、閉じたループでした。判断が、目に見え、所有される、財務上の帰結を持つようになったのです。

セクター別の視点#

スタートアップ#

デジタルヘルスのスタートアップにとって、クラウドのコストは生き残りの算術です。それはしばしば単独で最大のインフラの行であり、バーンレートが、滑走路を直接決めます。創業時の優位性は、FinOpsの規律を、最初のコミットから組み込めることです。初日からのタグ付け、あらゆるエンジニアが見るコストのダッシュボード、そして、投資家が精査する中核の事業指標として追跡される、ユニットエコノミクス（一人の患者や一人の顧客にサービスを提供するコスト）。リスクは、早すぎる過剰な最適化、つまり、まだ小さい請求書から数ペンスを削るために、乏しいエンジニアリングの時間を費やすこと、あるいは、アーキテクチャが安定する前に、長期のコミットメントにロックインすることです。拡大する規律は文化的なものです。コストを、財務の後回しではなく、プロダクトの指標として扱い、スタートアップがNHSの契約を勝ち取ったときに、そのサービス提供コストがすでに知られ、擁護できるようにします。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニック、小規模なヘルステックのサプライヤーは、大きなトラストと同じ従量課金のクラウドとSaaSの請求書を支払いますが、それらを管理する専任のFinOpsやITの能力はないため、実践的な優先事項は、完全な規律ではなく、少数のレバレッジの高い習慣です。現実的な成果は、明らかな無駄の排除（使われていないものを止め、古いストレージを削除する）、何も気づかれずに更新されないよう、あらゆるサブスクリプションとライセンスを更新日とともに挙げた簡単なリストを保つこと、そして小さな組織が簡単にほどけない、長期のコミットメントやロックインへの警戒です。コストの可視性は、通常、リアルタイムのダッシュボードではなく、提供者のコンソールを月に一度見ることを意味し、環境の多くは、誰か他の人が運用するために選ばれたSaaSかもしれないため、規律は、インフラの調整から、サブスクリプションの管理と契約の読み込みへ移ります。避けられない緊張は、大きな組織と同じ情報ガバナンスと継続性の義務が適用される一方で、現金が厳しく人員が薄いため、お金を節約するために、パッチを遅らせたり、レジリエンスを落としたりする誘惑が現実だということです。そのためここでも、安全をコストと交換しないという明確なルールが重要で、理想的には、小さな提供者がクラウドとライセンスの価格を単独で交渉しないよう、共有またはフレームワークでの購入に支えられます（トピック4.1 — プラットフォームと共有サービス参照）。

大企業#

大規模なNHSトラストやICSは、広がった環境、つまりレガシーのデータセンター、複数のクラウドのアカウント、数十の予算にまたがって購入された何百ものSaaSのサブスクリプションを運用し、その課題は、規模での調整と配分です。現実的な目標は、ボトルネックにならずに、連合したチームに可視性とガードレールを与える、中央のFinOpsの能力です。共通のタグ付けの標準、あらゆるサービスへのショーバック、中央で交渉されるコミットした利用の購入、アーキテクチャのガバナンスに組み込まれたコスト。最も難しい問題は、通常、技術的ではなく組織的なものです。異なる言語を話し、異なる取締役に報告するエンジニアリングと財務に、真実の単一のビューを共有させることです。この規模での最大の成果は、単一のサービスの英雄的な最適化ではなく、一貫して適用される少数の環境全体の規律（タグ付け、無駄の排除、コミットした利用、SaaSの合理化）から生まれ、コストの作業は、臨床安全や継続性を決して損なわないよう、明示的に境界づけられなければなりません。

政府#

国の機関、つまりNHS England、権限移譲された保健省、共有サービスの組織は、あらゆる提供者が運営するコストの環境を形づくります。その梃子は集約です。個々のトラストが、それぞれ弱い立場から交渉しなくて済むよう、国のクラウドとライセンスの合意を交渉し、グッドプラクティスが既定になるよう、FinOpsとTCOのガイダンスを公表し、より多くの組織が使うほどユニットコストが下がる共有プラットフォームを構築すること（トピック4.1 — プラットフォームと共有サービス参照）。政府はまた、capexからopexへの移行を非常に重大にする、資本と収益のルールを所有し、予算の配分と柔軟化の仕方を通じて、その摩擦を和らげたり悪化させたりできます。その説明責任は、システム全体の費用対効果について、議会と国民に対するものであるため、組織間でコストを透明で比較可能にし、コストの圧力が、患者が受けるサービスの不公平を静かに広げないようにする責務を負います。

よくある失敗パターン#

• 謎の請求書。 単一の不透明な請求書が毎月届き、誰もそれを分解できず、疑問が呈される頃には、お金はとうに費やされている。他の何よりも先に、タグ付けとほぼリアルタイムの可視性で直す。
• リフト・アンド・シフトのあとで驚く。 サーバーをそのままクラウドへ移行し、フルサイズで24時間動かし続け、クラウドの経済性が魔法のように現れることを期待する。クラウドがお金を節約するのは、その弾力性を使うときだけである。適正サイズ化し、スケジュールし、スケールする。
• コスト管理ではなくコスト削減。 1四半期お金を節約し、レジリエンスを損ない、根底の行動を何も変えないため静かに元に戻る、一度限りのパニックの削減。FinOpsは、キャンペーンではなく、継続的なループである。
• 安全を最適化して失う。 コストの目標を達成するために、冗長性を止め、パッチを遅らせ、臨床サービスを過少にプロビジョニングする。コストの判断は、臨床的な価値と明示的に比較考量されなければならず、それを決して覆してはならない。
• 影の中のSaaS。 部門のカードでの数十のサブスクリプション、退職者にまだ割り当てられているライセンス、一つの仕事をする三つのツール。クラウドの請求書にないため、見えない。生きたソフトウェア台帳を保ち、突き合わせる。
• 時期尚早なチャージバック。 未成熟で争いのある配分データを使って、チームからコストを回収し、取り組み全体の信用を損なう議論を生む。ショーバックから始め、お金を動かす前に、データ品質を勝ち取る。
• 盲目的なコミット。 6か月後に再設計して不要になるキャパシティの3年のリザベーションを購入する、あるいは、安定したベースラインにコミットメントを購入せず、永遠にオンデマンドの満額を支払い続ける。コミットメントを、本当に予測可能な負荷に合わせ、見直す。

成熟度モデル#

チェックリスト#

• クラウドとテクノロジーの支出が、サービスとチーム別に分解されて、設計の判断を行う人々に、ほぼリアルタイムで見える。
• 必須のタグ付けの標準が自動で徹底され、適切に配分された支出の割合が追跡される指標になっている。
• ショーバック（成熟していればチャージバック）が、各サービスに、そのテクノロジーが消費するものの、認識できるビューを与えている。
• 本番以外の環境が勤務時間外に停止するようスケジュールされ、リソースが観測された負荷に適正サイズ化され、ストレージにライフサイクルがある。
• 予測可能なベースラインが、コミットした利用またはリザーブドキャパシティの割引でカバーされ、定期的にレビューされている。
• 生きたソフトウェア資産台帳が、SaaSのサブスクリプションとライセンスを、実際のユーザーと利用に照らして突き合わせている。
• ユニットコストの指標（患者、予約、紹介、API呼び出しあたりのコスト）が定義され、価値に対して追跡されている。
• 選択肢が、データ転送料金と退出のコストを含む、現実的な寿命にわたる総所有コストで評価されている。
• コストへの影響がアーキテクチャレビューの常設項目であり、自動のガードレールと異常のアラートが、暴走した支出を数時間で捕捉する。
• 患者に面する、あるいは臨床上重要なワークロードに影響するコストの判断が、別途レビューされ、安全、レジリエンス、持続可能性を決して覆さない。
• 財務とデジタルが、大きなコミットメントの前に、複数年の繰り返しの負債を含む、capexからopexへの軌跡を共同でモデル化している。

主要な情報源#

• FinOps Foundation — FinOps Framework（Inform / Optimise / Operateのライフサイクル、原則、能力、ペルソナ） — クラウド財務オペレーションの、認められた知識体系。
• HM Treasury — The Green Book（評価と測定）と、資本的支出と収益的（リソース）支出の区別に関する、公的支出の規則。
• NHS England — クラウド、テクノロジー、デジタル支出のガイダンス。クラウドの採用と、NHSのデジタル投資における資本と収益の扱いを含む。
• クラウド提供者のWell-Architectedのコスト最適化のガイダンス — AWS Well-Architected Cost Optimization Pillar、Microsoft Azure Well-Architected Framework (Cost Optimization)、Google Cloud Architecture Framework (Cost optimization)。
• AXELOS / PeopleCert — ITIL 4、IT financial managementの実践（ITサービスの予算編成、会計、課金）。
• Technology Business Management (TBM) Council — テクノロジー支出を透明に算出し管理するための、TBMの分類法と標準。

参考文献#

1. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
2. Capital expenditure — Wikipedia — https://en.wikipedia.org/wiki/Capital_expenditure
3. Operating expense — Wikipedia — https://en.wikipedia.org/wiki/Operating_expense
4. Cost allocation — Wikipedia — https://en.wikipedia.org/wiki/Cost_allocation
5. Cost centre — Wikipedia — https://en.wikipedia.org/wiki/Cost_centre_(business)
6. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
7. Software asset management — Wikipedia — https://en.wikipedia.org/wiki/Software_asset_management
8. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
9. Software license — Wikipedia — https://en.wikipedia.org/wiki/Software_license
10. Autoscaling — Wikipedia — https://en.wikipedia.org/wiki/Autoscaling
11. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
12. Unit cost — Wikipedia — https://en.wikipedia.org/wiki/Unit_cost
13. FinOps Foundation — FinOps Framework — FinOps Foundation (Linux Foundation) — https://www.finops.org/framework/
14. HM Treasury — The Green Book: appraisal and evaluation in central government — GOV.UK — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government
15. NHS England — Cloud and technology guidance — NHS England — https://www.england.nhs.uk/
16. Amazon Web Services — Well-Architected Framework: Cost Optimization Pillar — AWS — https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html
17. Microsoft — Azure Well-Architected Framework: Cost Optimization — Microsoft Learn — https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/
18. Technology Business Management Council — TBM Framework and taxonomy — TBM Council — https://www.tbmcouncil.org/