@stormcat24 です。先日社内で各部署からパネラーを招き開発生産性に関する勉強会を開催したところ、参加者から「技術的負債のことを経営陣に理解してもらうコツはありますか？」という質問がありました。
また、本日開催の開発生産性Conferenceにおいての基調講演で、「LeanとDevOpsの科学」の著者であるNicole Forsgren氏が登壇しましたが、こちらのセッションでもQ&Aでも同様の質問が出ていました。
当方もサイバーエージェントにおいて開発生産性を向上する横軸部署の長として、このトピックについては一家言があるため、改めて一つの考えを表明しておきたいと思います。
経営資源と説明責任
開発生産性の改善にコミットするということは、言い換えれば「通常の事業開発に当てられている経営資源を切り崩す」ということです。
これは経営の意思決定の一つであるため、生産性改善活動の大義名分と対価について、説明する責任が生じます。
技術者であれば、生産性向上の活動が自分たちの開発体験にどのような影響を及ぼすかを理解することは難しくはありません。
しかし、エンジニアリングへの理解が乏しい経営層にとって、開発体験の向上がプロダクトの価値向上や経営にどうポジティブに作用するかはイメージしづらいものです。
どのように理解を得ていくか
経営層に対して、生産性向上活動をどのように合意形成を取って進めていくべきか。各社それぞれの事情を抱えているため、どう対話していくか悩みがあるかと思います。
経営層にどれだけの認識があるか
Four KeysやSPACEフレームワークなど、様々なメソッドが生まれる中で、ある程度のファクトは伝えやすくなってきました。
しかし、「LeanとDevOpsの科学」を読んでいるような経営者であれば、継続的な改善に投資すべきだみたいな話は理解されやすいですが、そうでない人の方が多いでしょう。かといって「LeanとDevOpsの科学」を読めというのもハードルが高いです。
可視化して重要性理解してくれる経営者はそもそもエンジニアリングへの理解高いので、理解低い奴には刺さらない罠がある#開発生産性con_findy
— す (@stormcat24) July 13, 2023
なるべく、経営者が改善活動を自分ごととして考えてもらうにはどうすべきでしょうか。
Four Keysの難しさ
技術者にとっても自分たちの生産性がどのようなレベルにあるのか、肌感ではなく具体的な数字として判断したいという欲求もあり、Four Keysは一つの潮流となりました。DORAのレポートにもあるように、リリース頻度やリードタイムのスコアが良ければ良い開発パフォーマンスを発揮する組織であると示されています。
しかし、Four Keysを可視化して改善していくという活動だけでは、十分に経営層に対してその価値を示すことが難しい。実際の事業数値にこれらの活動が寄与できているか見えにくいからです。
生産性の変革の成果を数値化
Google Cloudが出しているエントリに、DevOpsの変革によってどれだけの価値創出ができているか？という視点で成果を数値化するという手法があります。これは、生産性の変革がどれだけのビジネスインパクトがあるかを実際に数値として算出するものです。
①不要な作業削減で得られる価値
Value gained by avoiding unnecessary reworkは単純に活動によってどれだけの作業が削減され、コストとしてどれくらいのインパクトがあるかを示します。
改善の影響を享受する人員数 x 給与 x 1.5(利益乗数) x 作業削減率
②新しい機能へ再投資することで得られる価値
Value gained by reinvesting time in new featuresは、削減できた時間を新たな開発に投資することで得られる価値を示します。「確実に得られる」というよりは「得られうる」という表現の方が適切かとは思います。
回復時間 x 施策数/年 x ビジネスライン x 1/3(アイデア成功率) x 1%(アイデアインパク)ト x プラダクトの事業規模（金額）
③ダウンタイムの削減によるコスト削減
Cost saving by avoiding downtime avoidedはダウンタイムでどれだけの損失が生まれているかを示します。つまり、これを回避するもしくは改善することはそれだけの価値がある改善であると言えます。
リリース数/年 x Four Keysに応じた変更失敗率 x MTTR x 1時間あたりの売上損失
Amazon等のテックジャイアントに当てはめて算出することに言及した記事もあり、具体例として参考になります。
Queue-it
弊社もメディアやゲーム、広告といった事業を主軸に展開していますが、いずれのドメインも事業のKPIが生産性の変革やダウンタイムに左右されるものです。これは生産性の変革は、開発者体験だけではなく事業やプロダクトにも大きく寄与できるということを示しました。
①については、実現する改善施策（ソリューションやツール等）がどれだけのROIを出すかを示すものでもあるので、弊部署では施策別に算出しています。
また、この算出手法は、現時点での開発生産性を評価することだけに使うことはもったいないです。もし、現時点での生産性がFour KeysにおけるMediumパフォーマーだとした場合、②と③が今後の変革でHighやEliteに到達した場合にどれだけの伸びしろがあり、インパクトを出せるか？ということを示して説明の材料として活用もできます。
弊部署は中長期視点で開発者向けの仕事をしてますが、その活動をするための投資判断の材料として、このような図を示し、経営層とコミュニケーションしています。
「平時」の生産性と「有事」の生産性
暴論ですが、開発生産性向上の活動が無くても事業開発は回っていきます。どれだけ開発にフラストレーションがあっても、プロダクトのグロースや売上によって事業は癒やされてしまうので、後回しにされがちです。
ただ、事業を進める上で許容してきた技術的負債は確実に開発組織を蝕み、大規模なセキュリティインシデントといった外部要因によって開発の足を引っ張られることもあります。
近年ではCodecov問題への対処で、多くの開発組織を通常開発の手を止めざるを得なかったかと思います。もし、迅速なトークンを無効化やローテートの仕組み、監査ログのトレーシングによる影響範囲の特定の仕組みが整備されていれば、短いダウンタイムで業務に復帰できたはずです。このような有事の際に、継続的な生産性へのコミットが効いてきますが、残念ながら多くの経営層は（技術者自身もそうかもしれないが）、お尻に火がついてからでないとその重要性に気付けないのです。
最近ではこのことを「平時の生産性と有事の生産性」と呼んでいます。リリーススケジュールを十分に遵守できていれば、生産性は問題ないと思ってしまいがちですが、有事を考えた場合はどうでしょう？
この件は、「【サイバーエージェント×サイボウズ】専任チームによる開発生産性向上に向けたトライ」においても言及させてもらっています。
経営層との信頼も風が吹けば揺らぐ
経営層のこの活動に対する理解が乏しくても、開発責任者と経営層の信頼関係がある場合はGOサインが出ることもあります。技術者としては信頼してもらってありがたい話ですが、これは若干危ういと感じています。
今は市況も厳しく、突然風が吹いて事業活動が吹き飛ぶかもしれません。事業が順調だからこそ経営者との信頼も成り立つのであって、それの前提が揺らいだときに真っ先に切られうるのは開発生産性にコミットする我々です。どれだけ対人での信頼関係があっても抗えないでしょう。
生産性改善の大義名分や、どのように経営にポジティブな影響を及ぼすか、自分たちの存在価値とは何なのか。一任されるのであれば、必ずプロダクト開発や経営へのアウトカムを示すこと。それを技術者と経営層がタッグを組んで継続的に続けていくことが良い開発組織への第一歩と考えます。
