開発の改善はKPIに翻訳しなければいけないのか

  omuomugin   日記  

自分が社会人になってからずっと答えの出ない問いの1つが 「開発の改善 (例えばリファクタリングなど) は KPI (売上など) に翻訳して説明する必要があるのか、ないのか」 である。

この土日は割と暇だったり、こういうことを考えるきっかけもあったので整理してみている。
あくまでも現段階での自分の考えのスナップショットのつもりである。

大前提として、プロのソフトウェアエンジニアはビジネスの実現のためにモノを作る職業だと考えているのでこの問いは 「エンジニアが好き好んで新技術の導入する or しない」 とかではなくあくまでも ビジネスに貢献するという目的を持った上で説明責任として1つ1つの改善をKPIに翻訳して説明する必要があるのか？ である。

なのでちょっと昔に流行ってた「エンジニアに自由を！」みたいな議論をしたいわけではない。
勘違いされがちなので前置きを丁寧めにしてみた。

ちなみに自分の中での結論は今のところ
開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない
である。

この辺りの背景にある考えを噛み砕いていく。

「正しいもの」を「正しく作る」

まず自分は、 プロダクト開発 = 「正しいもの」を「正しく作る」 でも書いたようにプロダクト開発は 「正しいもの」を「正しく作る」という2つのフェーズが存在すると思っている。

さらにいうと、 The Zendesk Triple Diamond でも紹介されているようにある機能を開発するにあたっては、 Problem (問題定義), Solution (提供すべき機能、ユーザー体験), Development (開発) という3つの段階があって、 「正しいもの」 というのは、Problem と Solution の領域であり 正しい問題定義をした上で正しい解決策を提案する ことだと考えている。(もちろん古き悪きウォーターフォールの話をするつもりはなく、段階が分かれているが全ての段階において何かしらの関わり方をすべきという前提がある。)

そしてまさに 正しい問題定義をした上で正しい解決策を提案する というのが KPI (売上など) を改善する直接的な方法である考えている。

したがって、いわゆる PdM や PO などの行動が KPI (売上など) を中心に行動を考え、全ての行動が KPI (売上など) にインパクトを与えるという考えは自然に思うし、評価などにもそういった指標が含まれるべきだと思う。

一方開発は、 「正しく作る」 というところに専門性を発揮している職能だと考えている。
ではここにビジネスから求められていることはなんだろうか？

持続的に早く、安全にデリバリーする

ここで 4 Key Metrics (参考) を改めて思い出してみる。
4 Key Metrics は、Throughput 指標として Lead Time と Deploy Frequency 、Stability 指標として Mean Time to Repair と Change Failure Rate がある。
ここで細かい指標が何かをあえて説明することはしないが、雑にまとめてしまうと 「早く、安全にデリバリーする」 ということがプロダクトとして重要であるということを主張していると自分は捉えている。

また Code That Fits in Your Head: Heuristics for Software Engineering という本の中では、

(意訳)
現代においては保守性は持続性と置き換えて考えた方がいいのではないか

という主張がある。自分もこれに賛成で 4 Key Metrics と合わせて 「持続的に早く、安全にデリバリーする」 というのが現代の開発組織 (プロダクト組織全体) にビジネスから求められていることだと思っている。

ではどれくらい「持続的」で「早く」て「安全」である必要があるのだろうか。
結論は「可能な限り」(つまり青天井) だと考えている。

しかし当然これらを現実の世界で達成することはできない。
ではせめて 様々なプラクティスやツールを用いてこの状態に近づけるために改善していきたい のである。

このことから現段階における自分の考えは、冒頭の結論で述べたように
開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない
であり、行動が必ずしも売上に直接的な寄与をしなくても良いと思っている。
より正確には我々の職能は 「持続的に早く、安全にデリバリーする」 を実現することでビジネスに対して貢献できるのでこれを改善していくという目的で良くて、その改善がどの程度売上に寄与するかを定量的に翻訳する必要はないと思っている。
(近年はデータエンジニアなどアルゴリズムそのものを創出することを価値としたエンジニアも多いので全てにおいて翻訳する必要がないとは思っておらず、必ずしも翻訳する必要がないという主張をしているだけである。)

そして「持続的」、「早く」、「安全」のどこをどの程度改善していくかのトレードオフを考えるというところにビジネスへの深い理解が必要となると考えている。
このどういう課題を優先して解決するとプロダクト全体としての利を追求することができるのかという部分がまさにビジネスマンとしてのエンジニアの価値発揮ポイントなのかなと思ったりもする。

最後に自分が好きな本の1つである、 EMPOWERED - ORDINARY PEOPLE, EXTRAORDINARY PRODUCTS での主張を引用しておく

Because of that, in most companies, technology teams exist to serve the bussiness. That is very often the exact phrase you will hear. But even if they aren’t explicit about it, the different parts of “the bussiness” end up driving what is actually build by the product teams.
In contrast, in strong product companies, technology is not an expense, it is the bussiness. Technology enables and powers the products and services we provide to our customers. Technology allows us to solve problems for our customers in ways that are just now possible.

自分の解釈では、現代において開発組織というのはビジネスの実現の担い手 ( Enabler ) であることが求められていると考えている。

(余談) Lyft は単一のアプリを100人以上で作っている

自分がモバイルアプリのエンジニアをメインにしていたときに Lyft Mobile の podcast をよく聞いていたのだが当時 iOS アプリは 120人 で開発していたり、 2500モジュールほどあったようである。
実際 Lyft iOS tooling infrastructure summary 2022 の資料の中でも 2022年時点で以下のような規模で開発しているとある - 月に140人ほどがコミットしていて、週に240コミット程度ある - 2500モジュール

日本国内も含めてモバイルアプリにおけるマルチモジュールの構造は一般的になりつつあったりするがその目的をシャープに語れるエンジニアはそんなに多くない印象がある。

この Lyft の例は逆コンウェイ戦略を実にちゃんと体現していると自分は思っていて 100人以上 でアプリを早く (単純なスピードも並列数も上げて) 作っていくには各個別の機能の独立性を高めていき少人数が並列して1つのアプリケーションを作っていくしかないのであると想像する。
（マルチモジュール化をすること自体を売上換算する考え方ではやや遠回りをしていたのではなかろうかとも思ってしまう。)

これは例えばマイクロサービス (マイクロサービスの場合にはシステム的な可用性などの恩恵も大きくあるが) などでも同じで 持続的に並列数を無限に近づけていきながらも 0秒 に開発速度を近づけていき、しかも不具合やパフォーマンス悪化を0に近づけていくにはどうすべきか という手段として複雑なアーキテクチャなどの導入、改善をしていってるんじゃないかなというのが自分の考察である。