あっという間に1年が過ぎ去ろうとしています。
今年もGemini(nano banana)/OpenAI/ClaudeによってSREやソフトウェアエンジニアの現場は本当に大きく流れが変わりました。
昨年は補助的なコーディングやデバッグに留まるケースが多かったですが、今では主は生成AIに任せつつ、人間はより上流の役割や最終判断に回ることが多くなりました。
これにより多くのエンジニアリングの現場は体験が向上したと思います。また引き続きそこに対して、企業は大きな投資を実行していくでしょう。
一方で... 開発体験向上に対してどこまで投資していいものなのか... お財布を握る立場からするとちょっと悩ましいものです。
そこで、最近AWS/Amazonが取り組んでいるCTS-SWについて紹介します。
DevEx投資の「正しさ」を、どう測るか？
開発者体験（Developer Experience / DevEx）の改善は、現場にいると効果を実感することが多いです。
- CIが速くなった
- デプロイが安全になった
- オンコールが荒れなくなった
- 調査・検索・ドキュメント参照が楽になった
- 移行やアップグレードが一括で進むようになった
ただ、経営やマネジメント側に回ると、こういう会話はよく散見されます
- 「それって結局、ビジネス価値としてはどれくらい？」
- 「何円ぶん効いたの？」
- 「投資の優先度として他より優先しなくちゃいけないの？例えば人員増やすとかそっちが先じゃないの？」
- 「AIツールやDevExに、どこまで予算を張っていいの？」
言い方として、「DevExを向上したらX倍開発速度があがります！」っていうのも、正直現場からすると違うんだよなという状況です。言いやすいですが。。。
DORA（デプロイ頻度、変更リードタイム等）やSPACE（満足度、認知負荷等）のようなフレームワークはとても有用です。一方で、それらの指標を眺めただけでは「で、いくら儲かったの？ いくら節約できたの？」に変換しづらいのがネックです。
このギャップに真正面から取り組んだのが、AWS/Amazonが紹介している Cost to Serve Software（CTS-SW） です。
CTS-SW: 「ソフトウェア1単位を届けるコスト」
CTS-SWは、ざっくりどういう指標かというと
顧客に届いたソフトウェア（＝顧客が利用できる形でリリースされたもの）を “1単位” 届けるのに、いくらかかったか
「投入（コスト）」と「出力（デリバリー単位）」で、ソフトウェアデリバリー全体を捉える発想になります。
CTS-SW = ソフトウェアを提供する総コスト ÷ デリバリー単位数
ポイントは、デリバリー単位はチームごとに違ってよい、と明確に割り切っている点です。
例えば...分母は以下のような単位で設定することが可能です
- マイクロサービスなら。。。
- デプロイメント（デプロイ回数を単位にするのが自然）数
- モノリスな環境なら。。。：
- Pull Request完了数 / コードレビュー数
- 中央トランクに更新を提供する形なら。。。：
- 顧客に届くコミットの数
など
大事なのは、自分たちのアーキテクチャと開発形態にとって、最も“出力”として妥当な単位に揃えることを重視している点が勘所のようです。
従来の開発に対する指標は正直しんどい（し、実情にあってない）... : 活動基準原価計算の罠
DevEx投資のROIを出そうとすると、ついやりたくなるのが「活動ごとに時間を測って足し上げる」やり方です。
- 1回のビルド短縮で◯分
- 1回のデバッグ短縮で◯分
- 1回の問い合わせ短縮で◯分
⇒ それを全員分足す…
しかし、Amazonにおけるソフトウェア開発は複雑すぎて、各ステップにコストを配賦する 活動基準原価計算（ABC） は破綻しやすい、と判断されました。
理由は単純で、開発プロセスは時間とともに変化し続けますし、しかも生成AIの登場で「仕事のやり方そのもの」が変わっていく状況です。活動を定義し直して、配賦して、追跡して…をやっているうちに前提条件がコロコロ変わって破綻してしまうのです。まさに今、我々の現場で起こってることですね。
だからCTS/CTS-SWは、プロセスを過度に分解せず、投入（コスト）と出力（単位）だけでまず捉える。そこから 逆算して 改善点を探す、という立場を取りいれています。
この割り切りは、SRE/DevOpsの世界観とも相性がいいです。
「細部を追いすぎると運用不能になる」って、みなさん身に覚えがあるはずですよね。
AWSが示した「DevEx→ビジネス価値」の具体例
AWSは、CTS-SWという枠組みにより、ソフトウェアデリバリーの改善が 前年比15.9%のコスト削減につながった、と紹介しています。
ここが重要で、単なる 開発速度向上 ではなく、コスト回避やROIC（投下資本利益率）にも接続できる経済的リターンとして説明できる、としているところです。ROICあると、エンジニアリング全くわからない株主にも説明がしやすいですよね。
さらに、DevEx改善の結果として、次のような指標の改善も示しています。
（ここがDORA/SPACEとも噛み合う部分）
- ビルダー1人あたりの週次本番デプロイ：+18.3%
- デプロイあたりの人的介入：-30.4%
- デプロイあたりのインシデント関連チケット：2022年以降 -32.5%
この並べ方が上手いのです。
「開発/リリーススピード上がりました！」だけだと、現場のモチベーションとしてはめちゃくちゃ重要ですが、財務・監査・経営のレイヤーからするとなかなか伝わりにくいのです。
でも「介入が減り、インシデント関連が減り、その結果としてCTS-SWが下がり、コスト回避として効いた」だと、様々なステークホルダーにも説明がしやすいです。
CTS-SWは悪用される可能性：緊張指標（tension metrics）が必要
CTS-SWはなかなか強い指標ですが、
- “単位あたりコスト”を下げるために、危ない変更を雑に通す
- セキュリティを後回しにする
- 短期的にインシデントを隠す
- 「単位」の定義を都合よくいじる
といった悪用が考えられますので、それを防ぐためにAWSは 緊張指標（tension metrics） とセットで見るといいよと紹介しています。
例えば以下です
- 提供されるビジネス価値:
- コンバージョン率の向上、新機能の収益への影響、サービスコールの削減
- 顧客サイクルタイム:
- 機能リクエストから顧客の使用までの日数、顧客から報告された問題の解決にかかる時間
- 開発スループット:
- 顧客が実際に使用する機能の週当たりの配信数、1日当たりの成功したリリース数
- 品質と信頼性:
- 生産インシデント率、顧客満足度スコア、セキュリティ脆弱性解決時間
- チーム満足度:
- 定着率、エンゲージメント調査、開発プロセスに対する社内満足度
何がCTS-SWを動かすのか？
このあたりも面白いところです
チームベロシティ
開発者1人あたり、毎週マージされるコードレビュー（変更）数のようなもの。
重要なのは 個人指標にしない という姿勢で、「ソフトウェア開発はチームスポーツ」という言い方をしています。
言い換えると、
- レビューが詰まっている
- マージが遅い
- ブランチが長生きする
- 統合が怖い
みたいな状態は、コストとして効いてきます
デリバリーの健全性（介入回数・ロールバック率）
CI/CDが安全で自動化されている、変更安全性のベストプラクティスがあるチームは、CTS-SWが良いとされます
オンコールの割り込み
オンコールの割り込みが増えると、CTS-SWが悪化しやすい
この3つ、要するに
- 統合の流れ（開発→レビュー→マージ）
- 変更安全性（CI/CD・自動化・ロールバック）
- 運用割り込み（ページング・インシデント）
が、ソフトウェアの“単位あたりコスト”を決める主要因になりやすい、という話です。
SREの現場感としては「そりゃそうだよね」なんですが、これを コスト指標のドライバーとしてモデル化しているのが強い感じです。
まとめ：DevExは “気持ちいい” だけで終わらせない
現場としてはどんどん積極的にDevExに投資し続けてほしいです。私もその意見です。
一方でやはり投資継続判断を数字で測っていく、説明責任はついて回るもので、その指標を誤ると投資が止まりかねません。
CTS-SWは、DORA/SPACEのような現場指標を否定するものではなく、むしろそれらを ビジネス成果（コスト/ROIC/投資対効果）へ翻訳するための枠組みです。
例えば、
開発者 1,000人
1人あたり年間コスト 13万ドル（ツール含む）
合計 1.3億ドル
CTS-SWが15%改善 → 約1,950万ドル相当の改善
ソリューション費用 200万ドル
ROI 約10倍
⇒ だから投資し続けよう...
みたいな感じですね。
終わりに:
スリーシェイクにご興味をお持ちいただいた方、ぜひ気軽にカジュアル面談しましょう！