Rindrics Mumbles logo

Rindrics Mumbles

Organizational efficiencyとProduct and feature deliveryは何が違うのか

“CNCF Platforms White Paper” に紛らわしい箇所があったが、自分なりに理解できた気がするので、思考の整理を兼ねて言語化しておく。

扱うテーマは “How to measure the success of platforms”: プラットフォームの成功を客観的・定量的に計測するためのガイドラインの部分1。

ここで推奨されている計測対象は、下記の3カテゴリに分かれている。

カテゴリ 指標
User satisfaction and productivity アクティブユーザーと定着率、NPS、SPACE
Organizational efficiency 各種のレイテンシ（後述）
Product and feature delivery DORA の（旧）4指標2

当初、第二カテゴリと第三カテゴリの違いがいまいち腑に落ちなかった。 “Organizational efficiency” も “Product and feature delivery” も、要は効率に関する計測として一括りにできるようにも思えてしまい、別カテゴリとされる理由がわからなかった。

それぞれについて少し注意深く読んでみると、両者の違いは、「計測しているイベントの性質」および「誰が誰を待たせているか」にあるような気がする。

“Product and feature delivery” で計測するDORAの4指標はいずれも、反復的なデリバリー性能を示すものだ:

  • Deployment Frequency
  • Lead Time for Changes
  • Change Failure Rate
  • Time to Restore Service

一方で、“Organizational efficiency” とされる下記の3指標は、いずれも何かが初めて実現されるまでの時間に関するメトリクスであることがわかる:

指標 観点 支配的な要因
Latency from request to fulfillment of a service or capability, such as a database or test environment 開発リソース セルフサービス化の度合い
Latency to build and deploy a brand new service into production サービス ゴールデンパスとテンプレートの整備度
Time for a new user to submit their first code changes to their product ヒト ドキュメント・権限・開発環境の整備度

これらの理解をふまえると、両カテゴリは概ね下記のように表現しても良いと思う:

  • Organizational efficiency: プラットフォームが顧客である開発者を待たせている時間3
  • Product and feature delivery: 組織がエンドユーザーを待たせている時間

それぞれを計測した場合の効果については、たぶん下記のような整理になるのではと思う:

  • 程度の差ではあるが、プラットフォームチームの取組みの効果を純粋に見たいのであれば、実装やレビューの所要時間の影響を受ける “Product and feature delivery” に比べて、“Organizational efficiency” のほうが適しているだろう
  • ただし、プラットフォームチームの取組みは組織としてのバリューストリームに関わるものになっていないとまずい。原文にもあるように “Product and feature delivery” のほうが “true measure of the success of a platform” だ。ここを外してしまうと、プラットフォームが “an expense quite disconnected from their primary value streams” と見なされがちになる4

本記事を書きながら、2年ほど前に組織メトリクスに関する一過性ブーム的な盛り上がりがあったことを思い出していた。 最近は落ち着いてきた（飽きる企業が出てきた？）ように思うが、当時は組織メトリクスに対して、計測するだけで何かが起こるかのような、過度の期待があったのではないかと想像する。 組織メトリクスは、それぞれのカテゴリが何を映しているのかを踏まえた上で、必要な情報を得るための普通の手段として運用したらいい。

  1. 執筆時点では “platform engineering white paper” で検索すると、旧サイトのドキュメント（新サイトのv1相当）がトップに出てきてしまう。本記事の大半はこのあたりの事情を知らずに旧サイトのv1を読んで書いたのだが、執筆時点の最新版であるv1.1においても “How to measure the success of platforms” の内容は同一だった ↩︎

  2. 原文が参照しているDORAの指標は2019年ごろのものなので（原文で参照されているのはこちらだが、内容的にはこちらのほうが適当に思える）、“time to restore service” の改称や第5メトリクスの追加・分類軸の変更（ref）は反映されていない。 これらは次の版で取り込まれるのかもしれない ↩︎

  3. もっとも、二つ目の “Latency to build and deploy a brand new service into production” と三つ目の “Time for a new user to submit their first code changes to their product"については、実装やコードレビューの所要時間も含まれうる ↩︎

  4. ちなみに、プラットフォームの利用は個人・チーム・組織の性能を向上させる一方で、“throughput” と “stability” の各指標を低下させることが報告されている（ref） ↩︎