こんにちは。PharmaXの上野(@ueniki)です。
2024年10月31日、PharmaXはFindy Team+ Award 2024のSmall Divの部（エンジニア組織が50人未満）を受賞しました！
この賞は開発生産性向上に関して優れた取り組みを行った企業に贈られるものです。
この賞も今年で3年目を迎え、開発生産性という言葉が何となく日本のIT企業に受け入れられてきているように感じます。
特にスタートアップで、ソフトウェア開発に携わっている方は、一度は"開発生産性"という言葉を聞いたことがあるのではないでしょうか。
ですが、開発生産性という言葉自体は聞いたことがあるものの、よく分かっていないという言葉を聞くことも少なくはありません。
"開発生産性向上"というと、響きは素晴らしいものの、本当に意義のある活動なのでしょうか？
「そもそも開発生産性とは何なのか？」
「開発生産性を向上させて何になるの？」
という基本的な疑問だけではなく、
特に経営者の方からは、
「エンジニアは開発生産性が向上したって言うけど、本当に開発速度が上がっているようには感じない。開発ロードマップは達成できていないじゃないか！」
「開発生産性上げるための活動にそこまで時間を割いたからといって、本当にビジネス上の数値が向上するの？」
という一歩踏み込んだ疑問と苛立ちの声も聞こえてきます。
今回は、そんな「経営者から見た"開発生産性向上"の違和感」に向き合いたいと思います。
開発生産性向上を目指す上で注意すべき落とし穴や、議論上の注意事項について一緒に考えていきたいと考えています。
特に、
- これから開発生産性を可視化して改善活動に取り組もうとしてるEMやテックリードの方
- すでに開発生産性を可視化しているが、イマイチ使いこなせていないように感じるチームに所属しているエンジニアの方
- エンジニアチームはすでに開発生産性向上に取り組んでいるが、どんな意義があるのかピンときていない経営者の方
にお読みいただければ参考になるかと思います。
細かい用語の定義やポイントは他の方の記事に譲っているところもありますが、非エンジニアの経営者やマネージャーの方にも概要は掴んでいただける記事になっているかと思います。
ただし、ある程度のアジャイル開発やスクラムの知識を前提としており、専門用語や概念すべてを丁寧に解説できていないことはご了承ください。
Four keysとは何か
開発生産性の指標として最も知られているのがFour keysという下記の4つの指標です。
Findy Team+ Awardもおそらく（Four keysだけではないにしろ）Four keysを中心に受賞企業が決められているはずです。
- デプロイの頻度：変更を本番環境にデプロイ、あるいはエンドユーザーにリリースした頻度
- 変更のリードタイム：変更のコミットから、本番環境で正常に実行されるまでの時間
- 変更失敗率：デプロイによって本番環境で障害が発生する割合
- サービス復元時間：本番環境での障害から復元までにかかる時間
ざっくり言えば、デプロイの頻度と変更のリードタイムは速度の指標であり、変更障害率とサービス復元時間は安定性の指標です。
『LeanとDevOpsの科学』という本で広く知られることになりました。
ですが、このFour keysの意味するところが初心者には分かりづらい。
結論から言えば、非エンジニアの方は、Four keysはあくまでデリバリーの健全性の指標ぐらいに捉えるのがよいのではないかと私は考えています。
Four keysが高い水準を保てていることは自体は良いことですが、それだけでデリバリーに関わるすべての課題が解決するわけではないと捉えるのが適切です。
では、なぜ、デリバリーの"健全性の指標"程度のものを向上させるのに躍起になる必要があるのでしょうか？
なぜ、そのような指標で優れている開発チームが良いチームのように言われてしまうのでしょうか？
その謎を紐解いて行きましょう。
まずはリソース効率ではなく、フロー効率向上にフォーカスすることが重要
フロー効率を向上させることの意義
現代のソフトウェア企業では、アジャイルに価値検証する開発スタイルが好まれます。
これは、変化の速いビジネス環境に対応し、素早く価値検証を行う必要があるからです。
（なんだか、この10数年ぐらい耳にタコができるぐらい聞いたフレーズですね 笑）
下記の図はアジャイルで段階的なデリバリースタイルを表した有名な図です。
アジャイルなプロダクト開発的な発想としては、自動車の「乗って移動できるという価値」を軸に考えます。
「乗って移動できるという価値」は常に届けつつ、スケートボード、キックボード、自転車、バイク、自動車のように段階的にプロダクトを進化させるという発想でデリバリーして行きます。
（例がアバウトすぎて、顧客は自動車が欲しいのにスケートボードをリリースされてもさすがになぁ、、、という気もしなくもないですが、あくまでイメージです 笑）
The Myth of Incremental Development
確かにこの方法では、最終的な完成系に至るまでの総コストは大きくなってしまいます。
プロダクトのあるべき方向性が見えるたびに毎回設計をし直して、開発して、テストしてリリースしてという作業を繰り返す必要があるからです。
ですが、価値の単位を小さく分けて提供していくことができるので、アジャイルに価値を検証することが可能になります。
このようなモダンなソフトウェア開発スタイルは、"リソース効率"よりも"フロー効率"を重視した考え方だと言うことが出来ます。
「リソース効率重視 or フロー効率重視」の考え方については、詳しくは下記の記事を参考にしてください。
まずフロー効率を上昇させ、その後にリソース効率も重視していきましょうという考え方が紹介されています
ここで言う「フロー効率が良い状態」というのは、次々と価値あるプロダクトや機能が届けられている状態です。
価値が届けられるまでのリードタイムが短い状況とも言えます。
フロー効率を向上させるには、開発プロセス内の無駄や待ち時間を削減し、効率的な作業フローの構築する必要があります。
フロー効率のこれ以上の詳しい説明は省略しますが、なんとなくの概念はお分かりいただけるかと思います。
フロー効率重視の開発スタイルでは、単位時間あたりにどれだけ価値を届けられるかを重視して、価値を分割しながら届けます。
つまり、フロー効率を重視すれば、下記の右図のように機能が段階的かつ継続的にデリバリーされている状態になります。
『「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由』
Four keysはこのフロー効率に重きを置いた指標です。
特にデプロイ数やリードタイムは、直接的にフロー効率と結びつく概念です。
プロダクトは段階的にリリースされており、価値は分割しながら届いているのでフロー効率が良い状態であれば、基本的にはデプロイ数が多く、リードタイムが短くなる傾向にあります。
プロセス内の無駄や待ち時間も削減できているということにもなるでしょう。
確かに作るもの（上図でいうところの自動車）が決まっていて、それをリリースすればビジネス的な成功が約束されているのであれば、
それを一直線に作ることがリソース効率的に最も良く、
最終成果物が作られるまでの時間も短くなります。
ですが、最初に企画したものがそのままの形で成功することなど滅多にありません。
リリースしたプロダクトがそのまますぐに成功して、世界を制するというのは夢物語なのです。
そこで、現代のソフトウェア企業では段階的に早期に最低限の機能が提供できるスタイルが重要視される、
つまり、モダンな開発チームがまず向き合うべきは、「チームはフロー効率が高い状態を保てているのか？」という問いであるということです。
この観点では、Four keysのデプロイ数やリードタイムが、フロー効率良く開発できているかを評価する重要な指標だと言えるというのもご納得いただけるでしょう。
そして、変更失敗率やサービス復元時間は、健全な形でフロー効率が高まっているかを評価するための安定性の指標です。
つまり、フロー効率だけ高まって品質が低下していては意味がないので、安定性の指標も見る必要があるということです。
この速度と安定性の2つの要素は、決してトレードオフの関係にあるものではありません。実際に高い能力を発揮するチームは、開発スピードと安定性の両方が高レベルにあると言われています。
フロー効率の指標の落とし穴
作業粒度を小さくしてすれば、デプロイ数やPR数を増加させることは案外簡単にできてしまう点には注意が必要です。
つまり、デプロイ数やPR数といった指標を見かけ上増加させようとして、作業粒度を無駄に細かくすることは可能です。このような指標のハックのために、作業粒度を小さくすること自体が目的化してしまっては意味がありません。
しかし、一般的には、作業サイズを細かくし、早めにレビューを受け、こまめにリリースすることは、開発の品質を上げる上で良いことが多いとされます。
レビューもしやすくなりますし、小さな粒度で確認し合うことで認識の齟齬も少なくなります。
小さな単位でリリースすることができれば、デプロイ失敗率も下がる可能性が高いので、安全に開発・リリースできるということにも繋がります。
成果物をエンジニア以外のメンバーがこまめに確認することができるようにもなるので、チーム全体で認識の齟齬を減らせるということにも繋がります。
ですが、勘の良い方は、ここで別の疑問が思い浮かぶはずです。
それは、デプロイ数やPR数が増加したからと言って、結局の開発のアウトプット量（ここで言いたいのは生産量のような概念でしょう）が増えているとは限らないのではないか？
という疑問です。
フロー効率を向上させるべきなのはなんとなく分かった。
小さな単位でどんどんリリースできれば安全だし、すぐに顧客の反応を見ることができるので、開発サイズを小さくすること自体は問題ない。
だが、本当に"ある期間内のアウトプットの総量"は増えているのか？
というわけです。
この問題については後ほど再考するにしましょう。
開発生産性向上の議論ではあくまで"開発チームの生産性"の議論をしていることが多いことに気をつける
ここまでは、アジャイルなプロダクト開発にとって、フロー効率を向上させることには価値があることを述べてきました。
そして、Four keysを用いれば、「フロー効率高く安定してデリバリーできているか？」を評価することができそうだということもご説明しました。
ですが、ここまでの議論は前提として、「価値あるものを届けることが出来ている」のであればという重要な仮定を置いていています。
アジャイルに開発する上で、フロー効率を向上させることに意味があるのは、「価値あるものを届けることが出来ている」場合のみです。
価値のないものをどれだけリリースしていてもプロダクトの付加価値を積み上げたことにはなりません。
リリースした結果、プロダクトや機能に価値がなかったということが明らかになること自体は、自分たちの仮説が間違っていたということを検証できたという意味で、決して無意味なことではないかもしれません。
ですが、当然ながら、価値のないものをどれだけ素早く継続的にリリースしたところで、企業が競争に勝つことは出来ません。
そもそものこの記事の対象である「開発生産性」に立ち返れば、本当に「価値あるものを届けることが出来ているのか？」という観点を無視することはできません。
無価値なものをどれだけ生み出したところで生産的ではないからです。
ここで、改めて「開発生産性とは何か？」について考えましょう。
広木大地氏の著書『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』では、開発生産性には下図の3階層（3レベル）があるとしています。
『開発生産性について議論する前に知っておきたいこと』
広木さんの下記の記事も分かりやすいので参考にしてください。
- レベル1）仕事量の生産性：その仕事の価値や売上貢献などはいったん置いておいて、作業量としてどの程度の仕事をこなすことができたのかを評価する生産性
- レベル2）期待付加価値の生産性：「期待される価値がどの程度リリースできたのか」を評価する生産性
- レベル3）実現付加価値の生産性：売上やKPIなど、実際のサービスに対する具体的な貢献を評価する生産性
上図にも対応が記載されていますが、
- レベル1は開発チームの生産性
- レベル2はプロダクト開発組織全体の生産性
- レベル3は事業部全体の生産性
に対応します。
Four keysなどのほとんどの開発生産性指標がフォーカスしているのは、あくまでレベル1の生産性です。
誤解のないようにお伝えすると、レベル1の生産性は開発チームの生産性となってはいるものの、エンジニアだけの努力で改善するものではありません。
例えば、要件が十分にドキュメンテーションされていて、ゴールが明確であるか、考慮漏れがないか、といったようなことはレベル1の生産性にダイレクトに影響します。
エンジニアだけではなく、プロダクトマネージャーやデザイナーとの高度なコラボレーションが求められます。
最終アウトプットが開発チームの仕事量になるので、"開発チームの生産性"というスコープとして捉えているということです。
もちろんレベル2の期待付加価値やレベル3の実現付加価値の生産性の向上にも、当然取り組むべきです。
ただしそれには、ビジネス上の戦略の正しさやプロダクトの提供価値の研ぎ澄ませが必要になり、一石二鳥では行きません。
エンジニアリングだけでなく、プロダクトマネジメント、デザイン、QA、営業など、さまざまな職種の人たちが連携し、ユーザーに価値を提供する営みすべて改善しなければなりません。
開発生産性向上の取り組みにおいてコントロールしやすいのは、あくまでエンジニアリング周辺です。
本来的には、プロダクトの提供価値が向上し、ビジネス上のKPIが上がることが重要なのはその通りですが、
価値ある機能を企画し、開発、リリースし、ビジネス上のKPIが向上するまでには、エンジニアリング以外にも様々な要因が絡み合うため、エンジニアリングからは少し距離があります。
開発生産性向上の取り組みとして、レベル1の生産性にフォーカスするのは、コントロールしやすいスコープにフォーカスしようというある種の割り切りの姿勢がそこにはあります。
実際、素晴らしい施策が企画されてもなかなかリリースされなければ元も子もありません。
開発チームの生産性が高い状態に保てているということは、来たバックログを常に最高のフロー効率でリリースすることができるということです。
素早くリリースされれば、仮に施策が間違っていたとしても、すぐに路線変更を行うことができます。
レベル1の生産性を高めることは、まさに素早く価値提供できるチームになる第一歩と言えるのではないでしょうか。
短期でベロシティを上げようとするのはアンチパターン
ここまで来て改めて、上記で保留した「フロー効率を向上させたからといって、本当に"ある期間内のアウトプットの総量"は増えているのか？」という問いに向き合いましょう。
この問いの背景にあるのは、ある期間内のデプロイ数が増えたところで、合計の"生産量"が上がっていなければ、本当の意味で生産性が向上したとは言えないのではないか？という考えです。
ビジネス的には、ある期間にリリースされた機能の数やその難易度の総量（ある期間を経てのプロダクトの変化量）を見たくなるのが人の性でしょう。
要は、一定の期間内によりたくさんの機能や大きな機能を作れるようになっていなければ、生産性が向上したと言うにはも物足りないということでしょう。
もう少し突き詰めていけば、ある時期までにこれだけの機能群をリリースすることを顧客に約束しているといったことや、ある時期までにこれだけの機能をリリースしていなければ投資家に成果をアピールできないという"ロードマップ思考"のようなものが背景にある気がします。
特にスタートアップの経営陣は、資金調達のスケジュールなどから逆算して開発スケジュールを捉えるので、ロードマップ思考で考えがちです。
それ自体は何も間違ったことではありません。
本当に目標の時期までにロードマップを達成できるのか？、あるいは達成確度は高まっているのか？が経営陣に取って関心事であり、そのためには"生産量"が増えているかが重要であるというわけです。
その上で、
「開発生産性向上とは、最終的には、開発チームのデリバリー量＝ベロシティを上げることなんだな」
と考えるのは、スクラムを少し学んだ方によくある勘違いです。
ベロシティとはスプリントの期間内で完了できたタスクのストーリーポイントの合計値です。
前提として、ストーリーポイントは「かかる工数」の指標ではありません。
ベロシティをスクラムにおける"デリバリー量"と捉え、向上させるべき指標だと安易に考えしてまうのはよくある勘違いです。
ここでは詳細には取り上げませんが、ストーリーポイントは、あくまでタスクの難易度、規模、複雑性を反映する指標です。
「かかる工数」の指標ではないので、ストーリーポイントの合計を"量"として捉えるのは正しくありません。
工数ではなく、なぜそのような曖昧な？数値を見積もりの材料にするのかは下記の記事を参考にしてください。
「"デリバリー量"であるベロシティを上げることが開発生産性を向上させることだ」と考えるのは誤りである一方で、
ベロシティはチームがスプリント内に受け入れられるキャパシティを表してはいるので、ベロシティが高い方が望ましいという発想自体は決して間違ってはいません。
経営陣が、
「開発生産性を向上させると言うなら生産量を上げろ！ベロシティを上げるんだ！！（そして、速く開発ロードマップを達成しろ！）」
と言いたくなるのも無理からぬことです。
私も気持ちはよく分かります。
しかし、ベロシティをアウトプット量と捉え、短期に上げようとすることはむしろアンチパターンです。
ベロシティを上げることそのものが目的になってしまうと、ベロシティをハックする圧力が必ずかかってしまいます。
極端な話、ストーリーポイントの見積もりを大きくすればベロシティは簡単に上げることが出来ます。
わざとそんなズルいことをする人はいないとしても、ベロシティを上げようと焦ってしまうと、知らず知らずのうちにそのような圧力がかかってしまうものです。
まずはベロシティを高い水準で安定させることが重要です。
なぜベロシティを安定させることが重要なのかといえば、そのスプリント内でこなせるタスクの総量の目安が分かるからです。
当然、リリーススケジュールの予想もある程度正確になってきます。
そして、"自分たちのチームにとって"高い水準でベロシティを安定させることは、実はそれだけで十分に難しい目標です。
もちろん、ベロシティには他の要因も影響するので一概には言えませんが、Four Keysなどの指標が高いレベルで安定していれば、ベロシティが安定する土台は固まりつつあります。
（※Four Keysが安定していても、例えば、チームとして取り組んだことのないようなドメインの開発の場合、見積もり精度が低下してベロシティが不安定になることは考えられます。）
ベロシティが安定し、チームの地力が徐々に高まっていけば、自ずとベロシティは上がっていくはずです。
まずはベロシティを安定させ、その上で"健全に"ベロシティを向上させることを目指しましょうということです。
「チームのベロシティを上げる vs. 安定させる」の話は、下記の記事がよくまとまっていて分かりやすかったので、参考にしてみてください。
Four keysが高い水準を保っていて、ベロシティが安定していれば、開発チームがフロー効率の高い状態を維持できているということです。
つまり、やはりFour keysやベロシティはあくまでデリバリーの健全性を測る指標だと考えるぐらいが妥当だということになります。
ベロシティの良くない使い方については下記の記事によくまとまっているので参考にしていただければと思います。
スクラムとフロー効率とロードマップ
上記のようにベロシティはデリバリー量ではないので、開発ロードマップの時間軸を達成できるのかの見積もりに使うのは適切ではありません。
スクラムというのは、ロードマップが達成できるかどうかに答えを与えるためのフレームワークではないのです。
これは、スクラムが悪いということではなく、あくまでフォーカスの違いです。
スクラムは、スプリントの度に価値をインクリメントし、その過程を振り返って検査し、適応・調整するという学習プロセスにフォーカスしたフレームワークです。
スプリントごとにバックログの優先順を見直すこともできるため、プロダクトの軌道修正にも柔軟に対応することができます。
結局のところ、ロードマップを達成できそうかどうかをどうしても知りたければ、別の方法でざっくり見積もるしかないというのが私の理解です。
ちなみに、フロー効率やFour keysという概念もスクラムがもともと重要視している概念ではありません。
フロー効率やFour keysを重視すべきという考え方は、スクラムとも馴染むため、後付で取り入れられた概念であり、スクラムがもともとの思想においてフロー効率を高めるべきと述べているわけでもありません。
効率性を重視するあまり本来重要なプロダクトの価値にフォーカスできなくなってしまうという指摘もあるので注意が必要です。
結局、開発生産性における「アウトプット」とは何か？その謎を解明するため、我々調査隊はアマゾンの奥地へと向かったーー
ここまで話してきて、
開発生産性に階層があることも分かったし、これまで見てきた指標にもメリデメがあることは理解した。
でも、もっとズバッと"開発生産性"を表すような、難しい議論や注釈も必要なく「これこそまさに開発生産性だね！」と人類皆が同意できるような指標が欲しいんだ！！
という欲張りな方もいらっしゃることでしょう。
Four keysやベロシティよりも、もっとズバッと"開発生産性"を表すのことのできる指標は本当に存在しないのでしょうか。
上記の広木さんの記事『開発生産性について議論する前に知っておきたいこと』では、アウトプットのパターンとして下記のようなものが挙げられると考察されています。
ソースコード量(SLOC)
ファンクションポイント量(ベロシティ)
プルリクエスト量
ストーリーポイント量
期待付加価値の量
NSM( North Star Metrics )やKPIへの貢献
売上や粗利益額
ですが、どれもメリット・デメリットがあって、最適なアウトプット指標は何か？ということに結論は付いていません。（なんということでしょう、、、）
ここまで来てちゃぶ台を返すようですが、開発生産性が高いかどうかを判断するには、最終的にはプロダクトの提供価値が向上し、ビジネス上のKPIが上がったかどうかまで考える必要があるということなのでしょう。
急に暴論を言うようですが、逆を返せば、ビジネス上のKPIが向上し、売上と利益が向上し続けていれば、レベル1の開発チームの生産性がどうであろうと"良いチーム"と言ってしまっても、差し支えないのかもしれません。（エンジニアの皆さん、どうか怒らないでください）
結局のところ、我々がビジネスの現場で戦っている以上、いくら開発生産性向上の議論をしたとしても、最終的には、ビジネス上のKPIが上がらなければ誰も満足はしません。
この資本主義の社会において、企業の価値とはその企業が生み出した経済的な価値の総量でしかないのですから当たり前といえば当たり前です。
では、改めてFour keysなどの指標には意味がないのかと言われれば、やはりそんなこともありません。
開発チームが常にベスト尽くすことができ、無駄な工程に煩わされることなくデリバリーできているか？を確認する指標にはなります。
チームが正しくコラボレーションし、各エンジニアが自分たちの実力を出し切ることができていれば、
厳しいビジネスの世界で競争優位な状態にはなっていると言えるのではないでしょうか。
当然、エンジニア全員が気持ちよく全力で仕事ができている状態とも言えるので、エンジニア体験もよくなり、エンジニアが長く定着してくれるチームにもなっていることでしょう。
学習サイクルの中で各エンジニアのレベルが向上し、長期的には強く速いチームになっていくという好循環が生まれていきます。
つまり、Four keysなどの指標が高い水準にあり開発チームの生産性が高ければ、必ずビジネスが成功するわけではないものの、アジャイルに価値検証ができ、成功確率が高まった状態だとは言えるのではないか？
ということです。
所詮、我々人類にできることは、開発生産性について語るときのスコープ（3階層のうちどれか）を明確にし、
その中で各指標のメリデメを理解しながら、生産性を評価し、改善し続けることだけなのでしょう。
まとめ
今回は、「経営者から見た開発生産性の違和感に向き合う」というテーマでまとめてみました。
結局のところ、あらゆるステークホルダーのすべての疑問や違和感を解決するような便利な生産性指標など存在しないという結論でした。
開発生産性の議論に限らず、すべての指標にはスコープがあり、ある観点からの評価を反映しているだけに過ぎません。
どの観点を重要視するかで使うべき指標も変わります。
そこには、この観点から見ればこういう状態であり、この観点から見ればこういう状態であるという議論があるだけです。
そして、特に開発生産性の議論において重要視されるFour keysは、デリバリーしているメンバー以外にはどうしても理解しづらい概念であることをみてきました。
Four keysの意味するところもよく分からなければ、向上した時にどのようなメリットがあるのかもイメージしづらいというなかなか困った指標なのでした。
さらに、開発チームがフォーカスしやすいのはレベル1(からせいぜいレベル2）の生産性であり、その生産性向上だけでは、必ずしもビジネス上の価値には繋がらないという悲しい現実にも向き合いました。
だからといって、レベル1の開発チームの生産性向上に取り組まなくてもいいとうことにはならないという考えも述べました。
ただし、Four keysやベロシティのような指標を向上させることそのものが目標になってしまっては意味がないという指摘があることにも注意してください。
デリバリープロセスの改善やチーム文化の強化によって、結果的にこれらの指標が上がることが望ましいのです。
このあたりの注意事項については、下記の資料によくまとまっているので、参考にしていただければ幸いです。
このように概念も理解しづらく、取り扱いにも注意が必要な開発生産性ですが、この記事が少しでも多くの方の理解の一助となり、建設的な議論が行われる土台になることを願っています！
宣伝
PharmaXではエンジニアを中心に積極的に採用中です！
少しでも弊社に興味を持っていただけましたらご応募お持ちしております！
PharmaXエンジニアチームのテックブログです。エンジニアメンバーが、PharmaXの事業を通じて得た技術的な知見や、チームマネジメントについての知見を共有します。 PharmaXエンジニアチームやメンバーの雰囲気が分かるような記事は、note（note.com/pharmax）もご覧ください。
Discussion