5.4 エンジニアリングのコストと単位経済性

概要と動機

本トピックは第5部を明示的に財務的な方向に向けます。財務のステークホルダーが直接使える言葉でエンジニアリングのコストをどう表現するか、そして不透明な集計された部門の予算項目としてではなく、単位経済性、アウトプットや利用の意味のある単位あたりで表現されたコストをどう構築するかです。エンジニアリングのコストは通常、ソフトウェア主導の組織において最大の制御可能な支出項目ですが、それにもかかわらず、財務機能によって最もよく理解されていないことが頻繁にあり、何がそれを動かしているか、あるいはそれが成長とともにどうスケールするかについてほとんど可視性のない単一の大きな数字として報告されます。本トピックは、そのギャップを埋めるために存在します。なぜなら、「このシステムを運用するのに私たちにいくらかかるか」や「成長するにつれて私たちのコストはどうスケールするか」という問いに具体的な財務的な言葉で答えられないエンジニアリングのリーダーは、すべての予算の会話において本物の不利な立場にいるからです。

本トピックが推奨する特定の規律、単位経済性は、総人員コストや総クラウド支出としてだけではなく、デプロイあたり、サービスを受けた顧客あたり、処理された取引あたり、あるいはビジネスにとって実際に重要な別の単位あたりでコストを表現することを意味します。この枠組みの変更は、トピック1.3の産出より成果の原則に直接つながります。総コストの数字が下がっているのは、それがより少ない顧客にサービスを提供することから来ているなら、自動的に良いことではありません。そして総コストの数字が上がっているのは、それが比例してはるかに多くの顧客にサービスを提供することから来ているなら、自動的に悪いことではありません。単位経済性は、コストのトレンドを単に可視化するだけでなく、解釈可能にするものです。

大規模なチームにとって、本トピックの規律は、エンジニアリングの財務をブラックボックスから、判読可能で管理可能なシステムに変えるものです。企業組織は単位経済性を使って、異なる製品、プラットフォーム、あるいはチームのコスト効率を公平な基準で比較します。政府組織は同じ規律を使って財政責任を実証し、時間とともに市民一人あたりのコストを削減するインフラ投資のための証拠に基づいた事例を作ります。

重要な原則

総コストだけでは分母なしに解釈できない。 単位経済性、意味のある単位あたりのコストは、不透明な数字を実行可能なトレンドに変えます。
本物のビジネスあるいは使命の価値を反映する単位を選んでください。 恣意的な、あるいはゲーミングしやすい分母ではありません。
コストには複数の構成要素がある。人員、インフラ、ツールです。 それぞれ異なるコストの要因と異なる引くべきレバーを持つため、別々に追跡してください。
FinOpsの実践は、本書が提供と品質の指標にもたらすのと同じ厳密さをクラウドのコストにもたらす。 コストを避けられない不透明な既定事項としてではなく、測定可能で管理可能なものとして扱ってください。
下がる総コストは自動的に良いわけではなく、上がる総コストは自動的に悪いわけではない。 同時に単位の尺度に何が起きたかを確認せずにはです。

推奨事項

恣意的な分母ではなく、実際に提供された価値を反映する単位を選ぶ

あなたの単位経済性の計算のための単位を、ビジネスあるいは使命の価値を本物に追跡するものとして選んでください。サービスを受けた顧客あたりのコスト、処理された取引あたりのコスト、デプロイあたりのコスト、あるいは公共部門のサービスについて処理された市民とのやり取りあたりのコストです。比率を良く見せるために容易に膨らまされる、提供された本物の外部の価値単位に対応しない、内部の主に裁量的な件数のような分母を避けてください。

人員、インフラ、ツールのコストを分離する

エンジニアリングのコストには、異なる要因と異なるレバーを持つ少なくとも三つの別個の構成要素があります。人員コスト(給与、福利厚生、短期的には主に固定的)、インフラコスト(クラウド支出、利用とともに主に変動的でエンジニアリングの実践を通じて直接最適化可能)、そしてツールとライセンスのコスト(しばしば席あたりあるいは利用階層あたりの固定コスト)です。これらを一つの混合された合計としてではなく別々に追跡してください。本物の成長とともにスケールするインフラによって引き起こされた上昇する総コストは、管理されていないツールの拡散によって引き起こされた同じ総上昇とはまったく異なる対応を必要とするからです。

クラウドインフラのコストに特にFinOpsの規律を適用する

FinOpsは、エンジニアリング、財務、ビジネスのチーム間の機能横断的な協働を通じて、変動するクラウド支出に財務的な説明責任をもたらす規律です。その中核的な実践を直接適用してください。コストの帰属のためにクラウドリソースをチームとサービスでタグ付けし、定期的なペースで予算に対する支出を見直し、インフラのコスト効率(実際の利用単位あたりのコスト)を、単に受け入れる避けられない固定オーバーヘッドとしてではなく、意図的に最適化する価値のあるエンジニアリングの指標として扱ってください。

時間をかけて単位コストのトレンドを追跡し、動きを明示的に調査する

単一の単位コストのスナップショットは、そのトレンドよりも有用性が低いです。プラットフォームが成熟しスケールするにつれてサービスを受けた顧客あたりのコストは下がっているでしょうか(本物の効率性の向上の兆候)、それとも上がっているでしょうか(蓄積する非効率性、より高い保守コストを引き起こす技術的負債、あるいはよりリソース集約的なセグメントへのサービスを受ける顧客のミックスの変化の兆候)。説明なしに数字を報告するのではなく、重要な単位コストのトレンドの変化を明示的に調査してください。

コストデータを本書の他の場所にある技術的負債と品質の指標に結びつける

単位あたりの上昇するインフラあるいは保守コストは、時に蓄積された技術的負債(トピック4.5)あるいは複雑さのホットスポットの増殖(トピック4.1、トピック4.3)の直接的で測定可能な結果です。非効率なコードパス、冗長なインフラ、最適化の不十分なクエリはすべて最終的に上昇した単位コストとして現れます。上昇する単位コストを、第4部のチャーンと複雑さのシグナルと並んで、あなたの負債の優先順位づけの議論への一つの入力として使ってください。測定された測定可能なコストへの影響を実証した負債の項目は、定量化されていない品質の苦情だけよりも是正への投資のための強い事例を作るからです。

トレードオフ:長所と短所

アプローチ	長所	短所
総コストのみの報告	単純、予算が通常どのように配分されるかと一致する	分母なしには解釈できない。効率性のトレンドを隠す
適切に選ばれた分母を持つ単位経済性	解釈可能、実行可能、時間とチームを横断して比較可能	本物に意味がありゲーミングしにくい単位を選ぶための注意が必要
混合されたコスト報告(人員、インフラ、ツールを組み合わせる)	単純な単一の数字	どの特定のコストの要因が実際に変化していて、なぜかを曖昧にする
分離されたコストの構成要素	与えられたコストのトレンドに対して引くべき正しいレバーを明らかにする	より詳細なコストの帰属と追跡のインフラが必要

中心にある緊張関係は単純さと実行可能性です。単一の総コストの数字は報告しやすく、多くの組織がすでに予算を配分する方法と一致しますが、何がコストの変化を引き起こしているか、そしてそれらの変化が本物の効率性を反映しているか本物の成長を反映しているかの両方を曖昧にします。この緊張を解消するには、本トピックが推奨する幾分より複雑な単位経済性と構成要素を分離した報告に投資してください。結果として得られる実行可能性、コストが動いたときにどのレバーを正確に引くべきかを知ることは、最小規模を超えるすべての組織にとって、穏やかな追加の追跡の労力に見合う価値があるからです。

チームで話し合うべき問い

私たちは意味のある単位(顧客、取引、デプロイ)あたりのエンジニアリングのコストを追跡しているでしょうか、それとも不透明な合計としてだけでしょうか。合計だけが存在するなら、あなたのコストのトレンドを本物に解釈可能にする単位を特定し、それを追跡し始めるために何が必要かを話し合ってください。
私たちは現在のコストを人員、インフラ、ツールの構成要素に分離できるでしょうか、そして私たちは最近の変化のどれが何を引き起こしているかを知っているでしょうか。実際のコストの内訳が存在するならそれを取り出し、この問いに自信を持って答えるのに十分詳細であるかを確認してください。
私たちはクラウドインフラのコストにFinOpsのタグ付けと帰属の実践を適用したでしょうか、それとも単一の帰属されていない項目でしょうか。 支出が特定のチームやサービスに帰属させられないなら、本物の帰属への最初のステップがどのようなものかを話し合ってください。
私たちの単位コストのトレンドは最近どちらかの方向に大きく動いたでしょうか、そして私たちはなぜかを知っているでしょうか。 存在するなら実際の最近の動きを調査し、自信を持ってそれを説明できるか、それとも謎のままかを確認してください。
私たちの現在のインフラコストのトレンドは、第4部からの技術的負債あるいは複雑さのホットスポットのシグナルのどれかと相関しているでしょうか。これらのデータソースを明示的に相互参照し、負債是正のビジネスケースを強化できる結びつきが現れるかを確認してください。
もし明日財務のステークホルダーに「もう一人顧客にサービスを提供するのに私たちにいくらかかるか」と尋ねられたら、自信を持って答えられるでしょうか。この具体的で実用的な問いは、あなたの単位経済性が実際に構築され準備ができているか、それとも単なる理論的な願望かを検証します。

業種別の視点

スタートアップ。 単位経済性は早期に非常に重要です。なぜなら、投資家も創業者も、追加の顧客一人にサービスを提供するコストが持続可能性に向かっているか、それともスケールできないビジネスモデルに向かっているかを知る必要があるからです。会社が正式なFinOpsのツールを正当化できるほど大きくなるまで待つのではなく、たとえ大まかな見積もりであっても、非常に早期からこれを追跡してください。

中小企業。 クラウドプロバイダーの請求ダッシュボードは通常、専任のFinOpsのツールなしに十分な基本的なコストの可視性を提供します。主な規律は、総請求額だけを孤立して見るのではなく、分別のある単位(顧客あたりのコストあるいは取引あたりのコスト)を選び、定期的にトレンドを確認することです。

企業。 FinOpsの実践と分離されたコスト構成要素の追跡は、この規模で不可欠です。クラウド支出は多くのチームにわたって広がる非常に大きな、しばしば十分に精査されていない予算項目を表すことがあるからです。適切なコストの帰属のタグ付けと専任のコストレビューのペースに投資し、単位経済性を使って異なる製品ラインやプラットフォームのコスト効率を公平に比較してください。

政府。 財政責任と実証可能なコスト効率は、予算の正当化と公共の説明責任に直接関連します。市民一人あたりのコスト、あるいは処理された取引あたりのコストとして表現された単位経済性は、生の総支出額よりも予算委員会にとってしばしばはるかに説得力があり解釈可能な指標であり、時間とともに単位あたりのコストを削減するインフラ投資のビジネスケースを直接支持します。

事例

企業。 あるソフトウェア・アズ・ア・サービス会社の財務チームは、数四半期連続で上昇する総クラウドインフラ支出に警戒していて、当初は非効率性あるいは無駄を想定していました。単位経済性の分析、アクティブな顧客あたりのコストは、総支出が上昇していたにもかかわらず、単位コストが実際には着実に下がっていたことを示しました。なぜなら、顧客数がインフラのコストよりも速く成長していたからであり、これは総支出だけを見ることで覆い隠された本物の効率性の改善でした。この枠組みの変更は、財務の会話を「なぜエンジニアリングはより多く支出しているのか」から「どうすればこの効率的なスケーリングを持続できるか」に移し、本物に健全な成長主導の支出を標的にしていたであろう不必要で潜在的に有害なコスト削減の義務を回避した、より生産的な議論になりました。

政府。 ある州政府のデジタルサービス機関は、置き換えようとしていたレガシーのオンプレミスシステムとコストを比較する予算委員会に対して、継続的なクラウドインフラ投資を正当化するよう求められました。単位経済性の分析、処理された市民の取引あたりのコストは、新しいクラウドベースのシステムの単位コストが、より高い名目上の総支出にもかかわらず、レガシーシステムのものよりも実質的に低いことを示しました。なぜなら、新しいシステムは同じあるいはより低い総インフラ予算ではるかに高い取引量を処理していたからです。このより解釈しにくい総支出の比較ではなく、この単位コストの比較が、継続的かつ拡大されたクラウド投資のための成功した事例の中心的な証拠になりました。

ビジネスケース:動機、ROI、総所有コスト

厳密な単位経済性からの見返りは、すべての財務のステークホルダーが最終的に尋ねる問い、この支出は効率的か、そしてそれは持続可能にスケールしているかへの、擁護可能で解釈可能な答えです。上記の企業の例は、これを誤ることのリスクを示しています。総支出のみのビューは、単位ベースではより少なくではなくより効率的になりつつあった支出に対する、不必要で逆効果なコスト削減の義務をほとんど引き起こすところでした。

総所有コストには、コストの帰属のツール(FinOpsのタグ付けの実践)と、コストの構成要素を分離し時間をかけて単位のトレンドを追跡する分析的な規律が含まれます。その投資は、情報不足の総コストのビューだけに基づいて重要な予算決定を下すリスク、実際には効率的だった支出を削減すること、あるいは本物に非効率になりつつあった支出を捕捉できないことと比較して、穏やかなものです。

アンチパターンと落とし穴

分母なしに総コストを報告する。 解釈できず、コストが効率的にスケールしているか非効率的にスケールしているかを隠します。
コストの計算のためにゲーミングしやすい、あるいは恣意的な単位を選ぶ。 情報を与えるというよりも良く見せる比率を生み出します。
人員、インフラ、ツールのコストを一つの数字に混合する。 どの特定の要因が実際に変化していて、どのレバーがそれに対処するかを曖昧にします。
クラウドコストの帰属(FinOpsのタグ付け)がない。 チームあるいはサービスのレベルでインフラの支出を事実上管理も説明責任もないままにします。
単位のトレンドを確認せずに総コストの変化に反応する。 本物に効率的な成長主導の支出に対して不必要なコスト削減の義務を引き起こす可能性があります。
コストのトレンドを技術的負債あるいは複雑さのデータに一度も結びつけない。 負債是正への投資のための定量化され強化された事例を見逃します。

成熟度モデル

レベル1、開始: エンジニアリングのコストは、単位経済性や構成要素の分離なしに、単に不透明な合計として報告されています。
レベル2、発展: いくつかのコストの内訳が存在しますが、単位経済性は一貫性がなく、クラウドコストの帰属はほぼ存在しません。
レベル3、標準化: 適切に選ばれた分母を持つ単位経済性が一貫して追跡され、組織全体でコストが人員、インフラ、ツールの構成要素に分離されています。
レベル4、管理: FinOpsの帰属とレビューの実践が確立され、単位コストのトレンドが積極的に調査され、技術的負債と品質のシグナルに結びつけられています。
レベル5、最適化: 組織は財務のステークホルダーからの詳細な単位コストの問いに自信を持って答えることができ、コストのデータが最高レベルでエンジニアリングの投資決定と予算の正当化の両方に直接情報を与えています。

議論のためのアイデア

どの単位が私たちのコストのトレンドを本物に解釈可能にし、私たちはそれを追跡しているでしょうか。
最近のコストの変化を人員、インフラ、ツールの構成要素に分離できるでしょうか。
私たちのインフラ支出のどの部分かが現在特定のチームやサービスに帰属させられていないでしょうか。
私たちの単位コストのトレンドは最近動いたでしょうか、そして私たちはなぜかを知っているでしょうか。
どこで上昇する単位コストが対処されていない技術的負債の症状である可能性があるでしょうか。

主な要点

単位経済性、意味のある価値の単位あたりのコストは、不透明な総コストの数字を解釈可能で実行可能なトレンドに変えます。
本物のビジネスあるいは使命の価値を反映する単位を選び、ゲーミングしやすいあるいは恣意的な分母を避けてください。
コストを人員、インフラ、ツールの構成要素に分離してください。それぞれ異なる要因と異なるレバーを持つからです。
クラウドインフラのコストに特にFinOpsの規律を適用してください。帰属のタグ付けと定期的なレビューを含みます。
下がる総コストは自動的に良いわけではなく、上がる総コストは自動的に悪いわけではありません。 それと並んで単位のトレンドを確認せずにはです。

参考文献とさらなる読書

Cloud FinOps, J.R. Storment、Mike Fuller 著。
Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。
Site Reliability Engineering, Betsy Beyer、Chris Jones、Jennifer Petoff、Niall Richard Murphy 編。
FinOps財団のFinOpsフレームワーク、finops.org。