ボトルネック #04：コスト効率

主要なコストドライバーの特定

主要なコスト要因の特定から始めることが重要です。まず、コスト最適化チームは関連する請求書を収集する必要があります。これらは、クラウドプロバイダーおよびSaaSプロバイダーからのものになります。スプレッドシート、BIツール、Jupyter Notebookなど、分析ツールを使用してコストを分類することが役立ちます。さまざまな次元で集計してコストを分析することで、最大の効果を達成するための作業の特定と優先順位付けに役立つ独自の洞察が得られます。たとえば

**アプリケーション/システム:** 一部のアプリケーション/システムは、他のシステムよりもコストに大きく寄与することがあります。タグ付けは、コストをさまざまなシステムに関連付けるのに役立ち、作業に関与するチームを特定するのに役立ちます。

**コンピューティング vs ストレージ vs ネットワーク:** 一般的に、コンピューティングコストはストレージコストよりも高くなる傾向があり、ネットワーク転送料は予想以上に高コストになることがあります。これは、ホスティング戦略またはアーキテクチャの変更が役立つかどうかを特定するのに役立ちます。

**事前本番環境 vs 本番環境:** 事前本番環境のコストは、本番環境のコストよりもかなり低くなければなりません。しかし、事前本番環境ではアクセス制御が緩んでいる傾向があるため、予想以上にコストが高くなることは珍しくありません。これは、非本番環境にデータが蓄積されすぎている、または一時的またはPoCインフラストラクチャのクリーンアップが不足していることを示している可能性があります。

**運用 vs 分析:** 企業の運用システムのコストが分析システムのコストと比べてどの程度であるべきかという経験則はありませんが、エンジニアリングリーダーは、実際の支出と比較して適切な比率を特定するために、企業における運用環境と分析環境の規模と価値を把握しておく必要があります。

**サービス/機能プロバイダー:** プロジェクト管理、製品ロードマッピング、監視、インシデント管理、開発ツールなど、エンジニアリングリーダーは、使用中のツールのサブスクリプションとライセンスの数、およびそのコストに驚くことがよくあります。これは、統合の機会を特定するのに役立ち、交渉力とコスト削減にもつながる可能性があります。

ドライバーのインベントリとその関連コストの結果により、コスト最適化チームは、どのタイプのコストが最も高く、企業のアーキテクチャがどのようにそれらに影響を与えているかをよりよく理解できるようになります。この演習は、過去3～6ヶ月のコストなど、履歴データを使用してコストの変化と特定の製品または技術的な決定を関連付けることで、根本原因を特定する際にさらに効果的です。

主要なコストドライバーに対するコスト削減レバーの特定

コスト、トレンド、およびその推進要因を特定した後、次の質問は、コストを削減するためにどのような調整策を使用できるかということです。より一般的な方法の一部を以下に示します。もちろん、以下のリストは網羅的なものではなく、適切な調整策は多くの場合、状況によって大きく異なります。

**サイズ変更:** サイズ変更とは、ワークロードのリソース構成を利用率に近づけることです。

エンジニアは、ワークロードに必要なリソース構成を確認するために、多くの場合見積もりを実行します。ワークロードが時間とともに進化するにつれて、初期の見積もりは、初期の仮定が正しかったか、またはまだ適用できるかどうかを確認するために、フォローアップされることはめったになく、潜在的に利用率の低いリソースが残される可能性があります。

VMまたはコンテナ化されたワークロードのサイズを変更するには、プロビジョニングされたものと比較して、CPU、メモリ、ディスクなどの利用率を比較します。より抽象的なレベルでは、Azure SynapseやDynamoDBなどのマネージドサービスには、プロビジョニングされたインフラストラクチャの独自のユニットと、リソースの過小利用を強調する独自の監視ツールがあります。一部のツールは、特定のワークロードに対して最適なリソース構成を推奨するまでになっています。

リソースの割り当てを厳密に削減することなく、リソース構成を変更することでコストを削減する方法があります。クラウドプロバイダーには複数のインスタンスタイプがあり、通常、複数のインスタンスタイプが異なる価格帯で特定のリソース要件を満たすことができます。たとえば、AWSでは、新しいバージョンは一般的に安価であり、t3.smallはt2.smallよりも約10％安価です。またはAzureでは、紙面上の仕様は高いように見えますが、EシリーズはDシリーズよりも安価です。私たちは、クライアントがEシリーズに切り替えることでVMコストを30％削減するのを支援しました。

最後のヒントとして、特定のワークロードのサイズ変更を行う際に、コスト最適化チームは事前に購入したコミットメントを常に把握しておく必要があります。予約インスタンスなどの事前購入コミットメントは、特定のインスタンスタイプまたはファミリに関連付けられているため、特定のワークロードのインスタンスタイプを変更することでその特定のワークロードのコストを削減できる場合でも、予約インスタンスコミットメントの一部が未使用または無駄になる可能性があります。

**エフェメラルインフラストラクチャの使用:** コンピューティングリソースは、必要な時間よりも長く動作することがよくあります。たとえば、特定のタイムゾーンで作業するデータサイエンティストが使用する対話型データ分析クラスタは、データサイエンティストの勤務時間外に使用されない場合でも、24時間365日稼働している可能性があります。同様に、エンジニアが作業に使用しているにもかかわらず、開発環境が毎日終日稼働しているのを目撃してきました。

多くのマネージドサービスは、実際に使用したコンピューティング時間に対してのみ料金を支払うことを保証する自動終了またはサーバーレスコンピューティングオプションを提供しています。これらはすべて、覚えておくべき便利な調整策です。VMやディスクなどの他の、よりインフラストラクチャレベルのリソースについては、設定された基準（例：X分のアイドル時間）に基づいて、リソースのシャットダウンまたはクリーンアップを自動化できます。

エンジニアリングチームは、エフェメラルコンピューティングをさらに採用する方法として、FaaSへの移行を検討する可能性があります。これは、大幅なアーキテクチャの変更と成熟した開発者エクスペリエンスプラットフォームを必要とする重大な取り組みであるため、注意深く検討する必要があります。私たちは、FaaSに飛び込むことで多くの不要な複雑さを導入した企業を見てきました（極端な例：lambda pinball）。

**スポットインスタンスの活用:** スポットインスタンスの単位コストは、オンデマンドインスタンスよりも最大約70％低くなる可能性があります。もちろん、欠点としては、クラウドプロバイダーが短時間でスポットインスタンスを要求できるため、そこで実行されているワークロードが中断されるリスクがあります。したがって、クラウドプロバイダーは一般的に、ステートレスなWebサービス、CI/CDワークロード、アドホックな分析クラスタなど、中断からより簡単に復旧できるワークロードにスポットインスタンスを使用することを推奨しています。

上記のワークロードタイプの場合でも、中断からの復旧には時間がかかります。特定のワークロードが時間制約されている場合、スポットインスタンスは最適な選択肢ではない可能性があります。逆に、時間制約がそれほど厳しくない事前本番環境には、スポットインスタンスが簡単に適合する可能性があります。

**コミットメントベースの価格設定の活用:** スタートアップ企業が規模に達し、使用パターンを明確に理解している場合、チームが契約にコミットメントベースの価格設定を取り入れることをお勧めします。オンデマンド価格は、通常、事前購入コミットメントで得られる価格よりも高くなります。ただし、スケールアップの場合でも、使用パターンが安定していない、より実験的な製品やサービスには、オンデマンド価格設定が依然として役立つ可能性があります。

コミットメントベースの価格設定には複数の種類があります。これらはすべてオンデマンド価格よりも割引価格で提供されますが、特性が異なります。クラウドインフラストラクチャの場合、予約インスタンスは一般的に、特定のインスタンスタイプまたはファミリに関連付けられた使用量のコミットメントです。セービングプランは、時間あたりの特定のリソース（例：コンピューティング）単位の使用量に関連付けられた使用量のコミットメントです。どちらも1年から3年のコミットメント期間を提供しています。ほとんどのマネージドサービスにも、独自のコミットメントベースの価格設定バージョンがあります。

アーキテクチャ設計： マイクロサービスの普及に伴い、企業はより細かい粒度のアーキテクチャアプローチを採用しています。デジタルネイティブ企業の中期段階において、60個のサービスに遭遇することは珍しくありません。

しかし、消費者視点で設計されていないAPIは、消費者がそのデータの小さな部分しか必要としない場合でも、大量のペイロードを消費者に送信します。さらに、一部のサービスは、特定のタスクを独立して実行できる代わりに、分散モノリスを形成し、タスクを完了するために他のサービスへの複数回の呼び出しを必要とします。これらのシナリオで示されているように、ドメイン境界の不適切さや複雑すぎるアーキテクチャは、高いネットワークコストとして現れる可能性があります。

システム間のドメイン境界を改善するためにアーキテクチャやマイクロサービス設計をリファクタリングすることは大規模なプロジェクトになりますが、コスト削減以外にも、多くの点で長期的な大きな影響を与えます。そのような取り組みを始める準備ができていない組織や、これらのアーキテクチャの問題によるコストへの影響に対処するための戦術的なアプローチを探している組織は、戦略的なキャッシングを使用して、通信の頻度を最小限に抑えることができます。

データのアーカイブと保持ポリシーの適用： どのストレージシステムにおいても、ホット層は純粋なストレージにとって最も高価な層です。あまり頻繁に使用されないデータについては、クール層、コールド層、またはアーカイブ層に配置してコストを抑えることを検討してください。

まず、アクセスパターンを確認することが重要です。私たちのチームの1つは、大量のデータをコールド層に保存していたにもかかわらず、ストレージコストが増加しているプロジェクトに遭遇しました。プロジェクトチームは、コールド層に配置したデータに頻繁にアクセスしていたことに気づかず、それがコスト増加につながっていました。

重複ツールの統合： サービスプロバイダーの観点からコスト要因を列挙する際に、コスト最適化チームは、会社が同じカテゴリ（例：監視）内で複数のツールに対して料金を支払っていることに気づいたり、あるいは特定のツールを実際に使用しているチームがあるかどうか疑問に思ったりする可能性があります。未使用のリソース/ツールを削除し、カテゴリ内の重複ツールを統合することは、間違いなくコスト削減のもう一つの手段です。

統合後の使用量によっては、より有利な価格帯を利用できるようになったり、交渉力が高まったりすることで、さらなるコスト削減が期待できます。

努力と影響度に基づいた優先順位付け

コスト削減の可能性のある機会には、2つの重要な特性があります。潜在的な影響（潜在的なコスト削減の規模）と、それらを現実のものにするために必要な努力のレベルです。

会社が迅速にコスト削減を必要とする場合、50,000ドルかかるカテゴリから10％削減することは、5,000ドルかかるカテゴリから10％削減することよりも自然に効果があります。

しかし、コスト削減の機会は、実現するために異なるレベルの努力を必要とします。最適なサイズ変更やコミットメントベースの価格設定の利用などの構成変更よりも、コードやアーキテクチャの変更を必要とする機会もあります。必要な労力を正しく理解するために、コスト最適化チームは関連チームからの意見を得る必要があります。

図2：クライアントの優先順位付け演習からの出力例（異なる会社で行われた場合、異なる結果が得られる可能性があります）

この演習の終わりには、コスト最適化チームは、潜在的なコスト削減、実現するための努力、そして実装までのリードタイムに関連する遅延コスト（低/高）を伴う機会のリストを作成する必要があります。より複雑な機会については、後で説明するように、適切な財務分析を指定する必要があります。次に、コスト最適化チームは、イニシアチブを支援するリーダーとレビューを行い、どの機会に取り組むかを優先順位付けし、実行に必要なリソース要求を行います。

コスト最適化チームは、必要な行動と理由（潜在的な影響と優先順位）について十分な文脈を与えた後、影響を受ける製品およびプラットフォームチームと協力して実行するのが理想的です。ただし、必要に応じて、コスト最適化チームは能力やガイダンスを提供することができます。実行が進むにつれて、チームは、実現した節約と予想された節約、およびビジネスの優先順位からの学びに基づいて優先順位を再設定する必要があります。

コスト管理の責任の分散

削減フェーズでは、関連チームと協力して優先順位付けされたコスト削減の機会を実行するコスト最適化チームを編成することをお勧めします。最適化されたコストレベルを維持するには、コスト管理の責任をコスト最適化チームからそれぞれのチームに移す必要があります。

私たちが協力してきたほとんどのスタートアップは、（プラットフォームエンジニアリング製品チームを含む）製品チームモデルを採用しており、多くのチームは自分が所有するシステムをよく理解しています。製品チームは、製品を実行するために必要なカスタムソフトウェアと、機能に必要な独自のサードパーティシステムを所有しています。プラットフォームチームは、提供する機能に関連するシステムを所有します。これは、CI/CDや監視などの技術的な機能、または支払いなどの再利用可能なビジネス機能である可能性があります。

しかし、組織化されたスタートアップでも、組織の再編や自然減により、時間とともに一部のシステムが、時には静かに、孤児化されることがあります。

チームが所有権の境界をどの程度明確に理解しているかを検証するために、スタートアップは保有するシステムと既存の所有権の割り当てを確認できます。多くの組織では、この情報はサービスカタログなどの永続的な資産として既に管理されており、チームとレビューしてその最新性を検証する必要があります。

そのようなサービスカタログがない組織は、まずテクノロジーランドスケープのスナップショットを作成し（システムをリストアップするか、C4モデルなどでシステムを視覚化することなど）、チームと協力して各コンポーネントにそれぞれの所有者をタグ付けすることで始めることができます。長期的に見ると、サービスカタログ（本格的なポータルではなく、文書でも構いません）のようなリビングアーティファクトに移行するのが最善です。

理想的には、このプロセスを通じて、特定された孤児システムには所有者が割り当てられます。現実的には、ビジネスの重要性、コストへの影響、その他の側面に基づいて優先順位を付けることが妥当です。

次に、チームリーダー（エンジニアリングマネージャー、テクニカルリード、プロダクトリード）は、チームが所有するシステムのコストについて責任を負う必要があります。これは、最初に、既存の儀式（毎月の同期、四半期ごとのレビューなど）に織り込むことができる合理的な頻度でコストを確認するという期待になる可能性があります。最終的には、コスト指標をこれらのチームのKPIに組み込む必要があります。

コストを前面に出すことで、組織の能力が構築され、誰もが自分の意思決定のコストへの影響について考え、マネージャーがセキュリティや品質と同じように責任を負うべきであるというメッセージを送信するのに役立ちます。

しかし、セキュリティや品質と同様に、コストの考慮事項の二次的な影響を認識する必要があります。チームは過度に倹約すべきではありません。コストに関する意思決定を行う際には、関連する会社のリーダーに相談することができます。多くの場合、特に実験的な機能の場合、スタートアップでは、市場投入までの時間を短縮することを意味する場合、追加コストが発生する技術的負債を引き受けることが理にかなっています。重要なのは、コストの上昇傾向を察知し、修正する規律を持つことです。

チームレベルに責任を委任することが重要ですが、一括購入コミットメントの交渉や全体的なテクノロジーポートフォリオの最適化など、一部のコスト管理アクションは、より広範な組織のコンテキストを考慮してのみ最適に実行できます。したがって、コストの責任は、チームをまたがって、製品グループレベルでも負う必要があります。

コストの可視化

望ましいレベルの分散型責任を支援するために、システムを実行するコストを報告し、所有する組織レベル（チーム、製品グループ）に帰属させる必要があります。これを実現する方法は、サービスの種類によって異なります。たとえば、クラウドインフラストラクチャまたはサービスはタグ階層を使用して所有者に帰属させることができますが、共有Kubernetesクラスタで実行されるワークロードは、ラベル、名前空間、またはサービス名を使用して帰属させることができます（Kubernetes固有のコスト監視ツールを使用すると、ラベル、名前空間、サービス名に基づいて共有Kubernetesクラスタのコストをチームに分割できます）。

すべてのサービスまたはインフラストラクチャコンポーネントを製品またはチームに完全に帰属させることは困難ですが、レポートを検出可能で、理解可能で、実行可能にすることが重要です。これにより、エンジニアは技術的な意思決定のコストへの影響を理解し、リーダーはコース修正が必要かどうかを確認できます。

これらのレポートの詳細レベルは重要です。対象読者がチームレベルに近い場合、より詳細なデータを含め、より頻繁にレポートを更新することが役立ちます。チームは日々の開発作業中にコストに影響を与える決定を行うため、四半期ごとのレポートと比較して、2週間ごとまたは月ごとのレポートの方が方向転換の兆候をより迅速に示すことができます。

チームレベル以上のリーダーにとっては、より大きなトレンドを検出し、契約構造またはテクノロジー戦略の変更が必要かどうかを理解することに重点が置かれています。レポートは「主要なコスト要因を理解する」で説明されているものなどのさまざまな次元全体でコストを集計する可能性がありますが、レポートは一般的にチームレベルのレポートほど頻繁に更新する必要はありません。

チームが正しい行動を容易に取れるようにする

コスト管理においてしばしば見過ごされるのは、人々が期待どおりに行動すること、つまりテクノロジーランドスケープの一部のコストについて責任を負うことを容易にすることです。厳格なガバナンスプロセスを作成するのではなく、望ましい行動と結果を可能にすることを目指します。最も簡単な方法が最も費用対効果が高い場合、技術者は自然にベストプラクティスに従います。

望ましい結果を簡単に達成できる環境を作るために、ナッジ（促し）を活用できます。リチャード・セイラーは著書「ナッジ」でこのテーマを詳しく論じています。彼の例で、無制限のセルフサービスコンピューティングの良いアナロジーとなるものがあります。「トレーレス食堂」。食堂の管理者は食品廃棄物の削減に強い関心を寄せてきました。余分な食べ物が残されたり、使われずに余るナプキンが多く積み重ねられるトレーの容易さを目の当たりにしたニューヨーク州アルフレッド大学の好奇心旺盛な管理者と学生たちは、2日間にわたってトレーレス方式をテストしました。トレーが提供されなかった場合、飲食物の廃棄量は30～50％減少しました！

Backstage 開発者ポータルは、人々に正しい行動を促すツールの良い例です。テンプレートの使用は、エンジニアをゴールデンパス（Spotify版の舗装された道）へと導きます。また、ドキュメントのスコアカードにより、エンジニアが属性を追加して、より有用で読みやすいものにするよう促します。

コスト効率を改善するためのナッジの適用例を以下に示します。

テクノロジーポートフォリオの見直しとガバナンス

組織のテクノロジポートフォリオは、社内システムとサードパーティツール、言語、フレームワークで構成されています。ポートフォリオ内のアイテムが多くなるほど、組織の責任範囲が大きくなり、財政的投資と認知的負担の両方の点でコストが高くなります。テクノロジポートフォリオ内の各アイテムは当初、特定の理由で導入されましたが、これらの理由は時間の経過とともに無効になったり、無関係になったりする可能性があります。したがって、断片化を減らす方法でテクノロジポートフォリオを管理することで、コスト削減に役立ちます。

スタートアップのテクノロジポートフォリオを管理するための最初のステップは、保有しているシステムとその機能を把握することです。これを行うことで、機能の重複を特定し、冗長なシステムやツールを特定することが容易になります。例えば、ポートフォリオ内の複数のシステムが独自のCMS実装を持っている場合や、スタートアップがチーム全体でCI/CD機能を提供するために複数のツールが使用されていることを発見する場合があります。

ポートフォリオの最新の状態を十分に理解したら、チームはポートフォリオの最適化に役立ついくつかのツールを頻繁に利用しています。

ウォードリーマップを使用すると、エンジニアリングリーダーは、ビジネスをサポートするテクノロジー機能、ユーザー/顧客に対する可視性、進化の段階（実験段階であるか、かなり成熟しているがビジネスに特化しているか、コモディティであるか）を視覚化できます。これにより、これらの機能がビジネスにとってどれほど差別化されているか、投資の変更が必要かどうかについての議論が開かれます。ウォードリーマップは、チームがポートフォリオを見直し、低コストの「購入」オプションが時間の経過とともに魅力的になっているにもかかわらず、社内で開発および維持されている機能を特定するのに役立っています。

もう1つの便利なツールは、言語、サードパーティツール、プラットフォームのためのテクノロジーレーダーです。

テクノロジーレーダー自体はThoughtworksの業界出版物ですが、このモデルはZalandoなどの複数の組織によって、言語とツールの統合された状況を伝えるために使用されてきました。組織内のエンジニアに安全な言語/ツールの選択、推奨されないもの、実験段階にあるテクノロジーを伝えることで、エンジニアを望ましい方向に導き、断片化を防ぎ、コスト削減に役立ちます。Build Your Own RadarツールキットやBackstage Tech Radar Pluginなど、カスタムテクノロジーレーダーを開始するための方法は複数あります。

テクノロジポートフォリオの変更や主要なアーキテクチャ変更を検討する際には、財務パートナーと協力して、潜在的な投資収益率（ROI）に関する財務分析を実施することが重要です。財務分析における主な考慮事項は、変更の実装にかかる人件費、交換する場合のツール自体の費用、新しいアプローチによる潜在的な効率の向上または損失、現状維持のコストです。この分析は、影響を受けるのは変更を実装しているチームだけではないため、人件費と影響の点で組織全体に及ぶ必要があります。

当社のクライアントの1社は、現在のツールの費用変動が懸念され、管理が煩雑だったため、新しい可観測性ツールへの移行を検討していました。新しいベンダーからの見積もり、予想される人件費の見積もり、選択した期間におけるコスト削減の分析などを含む慎重な検討の結果、クライアントはROIがマイナスであったため、現在のツールを使い続けることを決定しました。

料金の最適化

クラウドおよびSaaSサービスプロバイダーは、コミットメント（例：予約インスタンスまたは節約プランの購入）と規模に対して顧客に報酬を与えます。ただし、実際の使用量が推定値と一致しない場合、一括購入プランは負債になる可能性があります。長期的なコミットメントは、会社のシステム、ユーザー、市場機会が契約条件よりも速く進化して変化するため、リスクが増加します。当社のクライアントの1社はAWS（コンピューティング節約プラン）と3年間の契約を締結しましたが、1年後、システムの一部を廃止することを決定し、その結果、コミットされたプランが十分に利用されなくなりました。

逆もまた真です。会社が常にコミット不足であれば、常にリソースに対してより高い価格を支払っています。これは、ビジネスがどのようにこのリスクを管理したいかについての注意深いバランスと継続的な話し合いが必要です。

ほとんどのSaaS製品は、会社にアカウントマネージャーを割り当てており、最適な価格を得るために利用可能な契約構造を伝えることができます。割引を要求しても害はありません。一部のSaaSプロバイダーは、参照可能なクライアントになることや、製品のベータ版に関するフィードバックを提供することなど、無形のメリットと引き換えに割引を提供します。アカウントマネージャーは会社の使用状況を追跡し、より良い選択肢があれば通知するため、定期的にアカウントマネージャーと会うことをお勧めします。

組織（または部門）のレート最適化に関する責任を統合することで、複数のチームにわたって責任を委任するよりも効率的な購買戦略が可能になります。組織の規模は、会社全体の規模の経済を最も有効にする価格モデルを管理するために、FinOpsチームへの投資を正当化する場合があります。