数か月前、私はAttribute™のプロダクトチームに加わりました。それ以来、クラウドコストからビジネス成果を読み解く面白さにすっかり夢中になり、以前の自分がどう働いていたのか思い出すのも難しいほどです。
それでもこの記事のため、そして読者のみなさんのために、記憶を掘り起こして、Attribute™が今提供している機能を切実に必要としていた頃を振り返ってみます。前職で経験した、いくつかの象徴的な場面をご紹介します。
R&Dのジレンマ:機能要望と見えない領域
数年前、私はテクニカルプロダクトマネージャーとしてR&Dチームと働いていました。顧客からの機能要望を受け取り、開発パイプラインに乗せていくのが仕事でした。
意思決定のプロセスは?一見シンプルに思えました。プロダクトマネージャーが、ビジネス指標の王様であるARR(年間経常収益)をもとに要望の優先順位を決める、というやり方です。
ARRが極めて重要な指標であることは間違いありません。しかし、それは物語の片面、つまり顧客から得られる売上しか語っていません。同じくらい重要なのは、そこから見えない側面、すなわちその顧客にどれだけのコストがかかっているかです。私たちのようなクラウド依存度の高いマルチテナント環境では、なおさらでした。
当時、これを正確に測る手段はありませんでした。機能要望の優先順位付けは、目隠しで迷路を進むようなものだったのです。どれだけのR&Dリソースを投じるべきか?どの大口顧客の要望から手を付けるべきか?顧客単位のクラウドコストが見えないままでは、これらの判断は常に不完全でした。
Attribute™があれば、顧客ごとの詳細なコストデータで、このパズルの欠けたピースを埋められたはずです。
機能の「めでたしめでたし」は、本当にハッピーエンド?
それから数年後、私はバックエンド開発者兼スクワッドリーダーになっていました。次のような場面、心当たりはありませんか?
真新しい機能のコードを書き、ローカルでテストし、QAへ渡し、プロダクト受け入れテストに進め、段階的にリリース。あとは祝杯を上げるだけ。新機能がついに本番稼働です!
ですが、ここに落とし穴があります。機能を「めでたしめでたし」と送り出す前に、私たちがしばしば忘れてしまう大事な問いがあるのです。それは、この機能はいくらかかっているのか?ということ。
もちろん、テスト段階でコストを予測するのは難しいでしょう(顧客がその機能をどう使うかを事前に見通すのは困難です)。しかし、少なくともリリース後にその機能のコストをモニタリングすべきではないでしょうか?共有リソース前提の現代の環境では、Attribute™のようなツールなしにこれを実現するのはほぼ不可能です。
Attribute™は先進的なテクノロジーによって、新機能にかかるクラウド費用を自動で特定します。
APIコールの氾濫:一件一件が積み重なる
APIコールの話をしましょう。現代のシステムを陰で支える、小さな縁の下の力持ち(あるいは厄介者?)たちです。前職のAdTech業界では、あらゆる場所で静かに事業を回していました。
当時、APIコールは事業運営の要でした。Meta、Google、TikTokといった広告プラットフォームへクライアントのキャンペーンをアップロードしたり、広告主、MMP、その他のソースからデータを取得したりするために活用していました。これらのコールと、その結果を保存するストレージには、当然コストがかかります。
問題は、一件一件のAPIコールに実際いくらかかっているのか、私たちは正確には把握できていなかったことです。Attribute™があれば、すべてのAPIコールのコストを突き止め、ワークロードや機能ごとの「主犯」まで洗い出せたはずです。
あの頃、Attribute™があったなら…
振り返ってみると、Attribute™があれば、当時の私の判断はどれほど的確でインパクトのあるものになっていたか、と思います。機能要望の優先順位付け、新機能のコスト管理、暴走するAPIコールの抑制。どの重要な局面でも、Attribute™は状況を一変させる存在になり得たはずです。
今、このツールを作るチームの一員として、かつての自分が直面した課題を他の方が避けられるよう手助けできることを、心から嬉しく思っています。クラウド利用の真のコストを知ることは、ビジネスにとってプラスというだけでなく、プロダクト、エンジニアリング、オペレーションに携わるすべての人にとって大きな武器になるからです。