このブログでは、ソフトウェア開発の生産性指標に変わってデファクトとなった「DORAメトリクス」について触れます。State of DevOps Report と LeanとDevOpsの科学[Accelerate] という研究結果が導き出した、開発チームのパフォーマンスを評価するための2属性、品質（安定性）とスピード（スループット）を解説します。この指標は Four Keys と呼ばれ、これらの計測によって開発チームは真の自己管理を手に入れることができます。全3回（前編・中編・後編）の中編。
前回のブログは
ビズリーチでは、プロダクト組織が進むべきゴールに向かうための「計器飛行」を実現すべく、その土台となるSODA構想（SODA : Software Outcome Delivery Architecture）を進めています。
前回の「前編」では、プロダクト組織における「計器飛行」を実現するための方法について述べました。航空管制官と経営者・パイロットと開発チームそれぞれの類似点、ウェイポイントの役割、プロダクトにおけるロードマップとマイルストーンの重要性について説明しました。
| 1 | プロダクト・ロードマップを描き、そこから計画を立てる |
|---|---|
| 2 | 重要な指標を特定し自動で計測できるように仕込む |
さて、今回は 「2.重要な指標を特定し自動で計測できるように仕込む」 を実行する際の「計測」を阻む、エンジニアが抱く苦手意識とその背景にある問題をについて考察します。
エンジニアが抱く計測への苦手意識
経営者や上位マネジャーは、「自分たちの開発チームは、生産性が高いのだろうか？」という点に重大な関心を向け続けます。なぜなら、ビジネスにおける利益の源泉は、ユーザーにプロダクトを速く届けてベネフィットを達成することだと十分理解しているからです。
一方、エンジニアは基本的に 計測に対して慎重な姿勢 を取ることがあります。上司から突然「あなたの生産性を明らかにしてください」と言われると、 少し戸惑いを感じるのです 。
なぜなら、パフォーマンスに関係のない指標や、場合によっては有害な指標を計測させられる可能性があり、そのことに恐れを抱くからだと思います。
ソフトウェア開発では度々、トップダウンで様々な指標（メトリクス）を計測させられ、疲弊する現場というものが生まれていました。これは、ソフトウェアにおける有効な指標（メトリクス）を特定することが難しく、間違った指標（メトリクス）で計測、もしくは当てずっぽう大量の指標（メトリクス）を計測してしまうことがあるからです。どうして、このような事が起きやすいのでしょうか。生産性指標を例に、その要因をいくつか探ってみましょう。
【理由1】エンジニアはナレッジワーカー（知識労働者）である
エンジニアやデザイナーはナレッジワーカーであり、知識に基づく考え方がイノベーションの源泉となります。この用語は、経営学者ピーター・ドラッカーによって提唱され、世界的に広く使われているもので、「知識労働者」とも呼ばれています。
ナレッジワーカーの意味とは？反対語や条件などを交えご紹介 | BizHint（ビズヒント）- クラウド活用と生産性向上の専門サイト
ソフトウェア開発において計測指標を見つけることが難しい理由は、生産性が単純な作業量や速度だけで測れるものではないからです。生産性は、与えられたリソースや時間を使ってどれだけの成果を生み出すことができるかという効率性を示します。しかし、ソフトウェア開発の場合、ナレッジワーカーである開発者の「考える」ことが重要な要素であり、単純な作業量や速度では捉えきれない複雑さが存在します。このため、生産性を評価するための一貫した指標が容易に見つけられず、各状況やコンテキストに応じて適切な指標を選択することが求められます。
また、ソフトウェア開発には、要件定義、設計、コーディング、テスト、デバッグなど多くの工程が含まれます。これらの工程は、さまざまな技能や知識を必要とするため、測定することが単純でないことも挙げられます。
【理由2】「書いたコードの量」は生産性とは限らない
プログラミングでは、1000行のコードよりも10行で問題が解決できる方が好ましく、コード量が少ない方が生産性が高い可能性があります。
さらに、誰にも理解できない1行のコードよりも、理解しやすく保守も容易な数行のコードの方が、生産性と保守性が高い可能性があります。適切なコード量は存在しますが、「行数」を用いて生産性を測定することは意味がありません。（ただし、品質の指標としては役立ちます。）
【理由3】「ベロシティ(速度)」は生産性とは限らない
アジャイル開発では、開発チームのキャパシティを予測する際に「ベロシティ（速度）」がよく計測されます。しかしながら、ベロシティは過去の成果を基にした相対的な尺度であるため、生産性の客観的な指標としては不適切です。
【理由4】「リソース効率」は生産性とは限らない
優れたエンジニアやデザイナーを多く働かせることで、生産性が向上するでしょうか？これは複雑な問題です。そもそも生産性には、「スループット的速さ」と「リードタイム的速さ」という異なる観点が存在し、それぞれ異なる対策が必要です。
昔のソフトウェア開発期間は年単位でしたので、リソースの効率(メンバー1人あたりの利用率)を上げることで速くなる「スループット的速さ」を重視していました。しかし、今は状況の変化に合わせて細かくフィーチャーをリリースできる能力である「リードタイム的速さ」が重視されています。
この話は非常に長くなるため、興味のある方は以下の本をぜひ読んでみてください。
This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント
一方、「プロダクトと価値」に費やす時間の割合を示す「オンプロダクト指標」は、開発チームメンバーが働く時間全体に占める割合として重要です。ただし、オンプロダクト指標とリソース効率の相関関係は弱いとされています。
エンジニアやデザイナーも人間ですから、「ゆとり（Slack）」が重要です。業務では予期せぬ仕事や計画変更が生じることがありますが、そのためにも「ゆとり」の確保があることで生産性は向上すると言われています。
さらに、日常業務で工数をぎりぎりに使ってしまうと、実験や勉強、練習の時間がなくなり、人々の成長が妨げられてしまいます。このテーマに関しては、ソフトウェア業界の巨匠であるTom DeMarcoが本を出版しており、ぜひ読むことをお勧めします。
ここまで、プロダクト組織における計測指標が難しい理由について述べてきました。
多くのプロダクト組織がこの「計測指標の難しさ」に直面しているのではないでしょうか。だからといって、計測を諦めてしまうと、自己管理や自己組織化の機会を逃すことになります。
このような状況がプロダクト組織のマネジメントを難しくする一旦と言えるでしょう。
なお、開発生産性については、エンジニアリング組織論の著者である広木大地さんのブログで更に深い考察がなされていますので参考にしてください。
開発生産性について議論する前に知っておきたいこと - Qiita
完璧で単純な答えはない
「計測して意味あるの？」という問いに対する完璧で単純な答えはありません。
指標（メトリクス）の計測は、昔から様々なアプローチが取られてきました。そして、ソフトウェアエンジニアリングの歴史においては、Tom DeMarco のとても有名な格言……というより呪言があります。
それは
「計測できないものは制御できない」 “You can’t control what you can’t measure.”
と言うものです。
昔の人はこれに共感し、ありとあらゆるメトリクスを収集しまくりました。
👉🏻 ところで「計測できないものは○○できない」という言葉にはいくつもの派生が存在します。Peter F Drucker 言ってたとか、William Edwards Deming 言ってたことになっていますが、引用元が提示されていない場合は怪しいので注意してください。Tom DeMarco の上記の言葉は、下記の本で本当に書いています。 ”Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982)
インターネットが普及していなかった時代、「伝統的な日本の大企業」では多種多様なメトリクスを（上司や他部門のだれかに言われ、しぶしぶ）計測し、それをマクロだらけのExcel（昔は共同編集ができない！）やAccessでごにょごにょと分析させられ、「品質なんたら部門」に提出する……といった時代が長く続きました。
開発で忙しいのに、理由も聞かされず毎週データの提出を求められた経験から、ベテランのエンジニアほど「計測」と聞いただけで眉をひそめる人は少なくないと思います。
2009年7月、Tom DeMarco がIEEE Software誌7月8月合併号に、衝撃的な記事を寄稿しました。タイトルは ”Software Engineering: An Idea Whose Time Has Come and Gone?（ソフトウェアエンジニアリング：その考えは、もう終わったことなのか？）”
ここで Tom DeMarco は以下のように述べています。
「計測できないものは制御できない」 このセリフには本当の真実が含まれているのですが、私はこのセリフを使うことに違和感を覚えるようになりました。 (中略*)* 例えば、過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算通りに終わらせることができないことで自らを苦しめてきました。 (Tom DeMarco, 2009)
この文章は当時、Tom DeMarco 自身が「測定できないものは制御できない｣は誤りだったと認めた！ということで業界に衝撃が走りました。
Tom DeMarco は「時間を守ったり予算内に納めること」よりも、 ソフトウェアの力で世界を変えるようなプロダクトを生み出すことの方が重要 であることに気づいたと述べています。
しかし、先ほども申し上げたように、それは決して至上命題ではなかったはずです。もっと重要なのは、世界を変えるような、あるいは企業やビジネスのあり方を変えるようなソフトウェアを作るという「変革」です。 (Tom DeMarco, 2009)
ソフトウェア開発はそれほど進化していない？
「継続的デリバリー」を提唱したDavid Farleyは著書”Modern Software Engineering : Doing What Works to Build Better Software Faster”のなかでこう言っています。
私の印象では、ソフトウェア産業は学ぶことも進化することもなかなかできないで苦闘しているように見えます。この相対的な停滞は、コードを実行するハードウェアのとてつもない進化によって見えなくされているのです。
【引用：Farley, D.(2022), 長尾高弘 (訳). 継続的デリバリーのソフトウェア工学: もっと早く、もっと良いソフトウェアを作るための秘訣 (Nagao, T., Trans.). 日経BP社. (Original work published 2021) p.69】
継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣
上記のTom DeMarco が反省していた 2009年。
実は「ビズリーチ」サービスが誕生した年です（2009年4月開始）。iPhone 3GSも2009年に誕生しました。（私が初めて手にしたiPhone）
2009年からのハードウェア進化を確認するために、14年前の iPhone 3GSと現時点で最新のiPhone 14 Pro の性能を比較してみましょう。
| 項目 | iPhone 3GS | iPhone 14 Pro |
|---|---|---|
| 発売年月 | 2009年6月 | 2022年9月 |
| ディスプレイサイズ | 3.5インチ | 6.1インチ |
| 解像度 | 320 x 480ピクセル | 1170 x 2532ピクセル |
| プロセッサー | ARM Cortex-A8 (600MHz) | Apple A16 Bionic (3GHz) |
| RAM容量 | 256MB | 6GB |
| ストレージ容量 | 8GB/16GB/32GB | 128GB/256GB/512GB/1TB |
| カメラ画素数（背面） | 3MP（オートフォーカス） | 12MP（広角・望遠・超広角・LiDARスキャナー） |
| カメラ画素数（前面） | 無し | 12MP（TrueDepthカメラ） |
| バッテリー容量 | 1219mAh（5時間通話） | 3095mAh（22時間通話） |
一方、ソフトウェア開発の進化はどうでしょうか。
私がソフトウェア開発業界に参加してから30年以上が経ちます。最初はZ80アセンブラ言語から始め、すぐにアセンブリコードをC言語に移植するムーブメントが起こりました。その後、C言語でオブジェクト指向設計を実現しようと試みているうちに、オブジェクト指向のプログラミング言語であるJavaが登場しました。
これまでのソフトウェアの進化を振り返ってみても、それ以外には特筆すべきことはないようです。ハードウェアとネットワークの進化に比べると、ソフトウェアの進化はそれほど大きくないと言えます。
GPT(Generative Pre-trained Transformer)のような、高度な自然言語処理や生成タスクを行うAIが急速に進化したのも、NVIDIAが開発した高性能なGPUがAI分野で広く利用されたからとも言えます。
ソフトウェアの開発ツールも進化していますが、やっぱり、背後ではハードウェアの進化が大きく寄与しています。現代において、ソフトウェア開発の生産性を向上させたいと考えたとき、手っ取り早いのは「道具」を変えることです。
- 新型のPC（Mac）を購入するか、最高スペックにする
- PCの台数を増やす（人員も増やす）
- 高性能のサーバーに買い替える
- クラウドのCPU物理コア数を増やす
- インターネットの回線を速く（太く）する
などの対策は、すぐ思い浮かぶことでしょう。
これらの事例から、ソフトウェア開発において「不変的なもの」と「変化の激しいもの」の相対性が把握しにくいことが分かります。特に、「開発プロセスの影響」は明確になりにくいです。
このような状況ですので、エンジニアが「計測する」ことの意義を見いだすのが難しいことは、分からなくありません。
だが、役立つ指標はある
日本のプロダクト組織では、未だに「ウォーターフォール」アプローチが多く、ちょっとした問題が発生すると手戻りが多い状況が続いています。
また、たとえ「スクラム」に取り組んでいても「フルタイムのスクラムマスターを置けない」といった悩みを抱えるチームは少なくありません。
果たして、開発プロセスやプロジェクトマネジメントを上手く実践していると「思えている」エンジニア・マネジャーはどの程度いるのでしょうか。
そもそも、マネジメントという「行い」については、良い・悪いを判断するほどのエビデンス（証拠）がないことが多いと思います。つまり、以下の問いについては計測しない限り答えることができません。
- ウォーターフォールを使っているから、開発が【速い or 遅い】
- スクラムをやっているから、開発が【速い or 遅い】
冒頭で述べたように、ソフトウェア開発の生産性指標を正確に測定することは、非常に難しいものです。しかし、生産性以外で役立つ指標が存在することが示唆されています。
その指標とは、DORAメトリクスと呼ばれる「State of DevOps Report」並びに「LeanとDevOpsの科学 [Accelerate]」です。
LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)
これらの指標は、ソフトウェア開発における品質やスピードといった要素を評価する方法を提供します。そして、開発チームのパフォーマンスを評価するためのたった2つの属性、
- 品質（安定性）
- スピード（スループット）
を用いて評価します。そして、それぞれ2つずつある計測指標は Four Keys と呼ばれています。
- 平均サービス回復時間(MTRS)
- 平均失敗率
- リードタイム
- デプロイ頻度
これらの指標によって、高パフォーマンスチームと低パフォーマンスチームの行動様式の相関関係が明らかになり、開発チーム自身がその行動様式（27のケイパビリティ）を改善することができます。これによって、開発チームは自己管理が可能となります。
このAccelerateアプローチが画期的なのは、開発チームは計測した値について、第三者からあれこれ指図される必要がないところです。自分たちが計測した Four Keys という証拠にもとづいて、チームの行動様式に変更（実験）を加えるのです。その変更によって、パフォーマンスの針（計測値）はどちらかに動きます。
これこそが「計器飛行」です。
別の言い方をすれば、開発チームの自己管理が可能となります。こうすることで、Four Keys という計測指標は開発チームのためのもの、ひいては自分自身のための計測になります。
Tom DeMarco はIEEE Software誌の記事の最後で、こう締めくくっています。
ソフトウェア開発は、今も昔も、どこか実験的である。 実際のソフトウェアの構築はそれほど実験的ではありませんが、その構想は実験的です。そして、この点にこそ私たちの焦点が当てられるべきでしょう。私たちは常にここに焦点を当てるべきでした。(Tom DeMarco, 2009)
さすがは、我らの Tom DeMarco 先生です。
次回のブログでは
ここまで、なぜエンジニアが「計測」と聞くと眉をひそめてしまうか、その背景について考察しました。ソフトウェア開発における生産性の指標が難しいという問題がある一方、DORAメトリクスと呼ばれる指標が開発チームの行動様式を評価する方法を提供しており、新しい計測指標の時代が訪れているという話でした。
次回は、いよいよビズリーチのプロダクト組織における「計器飛行」を実現するためのSODA構想について解説したいと思います。
