6/28(金)、29(土)に虎ノ門ヒルズで行われた開発生産性カンファレンスというイベントに参加してきました。

今年の開発生産性カンファレンスのテーマは、「開発生産性とビジネスインパクトをつなぐこと」です。

システムの運用課題や技術的負債の解消の効果をビジネスインパクト（ROIなど）に繋げて説明し切ることは難しいと思いますが、そのヒントになりそうなセッションがいくつかあったと思うので紹介しようと思います！

登壇した方の資料はこちらのnoteでまとめられているのでぜひ確認してみてください！

Day1で印象に残ったセッション

テスラ、Redwood Materialsにみるビジネスグロースに貢献するエンジニア組織とは

なんと言っても注目は元TeslaCTOのJ.B. Straubelさんのセッションです。とても学びになることを聞けたのですが、肝心の中身は記事化NGのようなので紹介できないのが残念です。

開発生産性向上のための監視運用の改善

このセッションでは、DMM.comにおける監視運用の改善について聞くことができました。

DMM.comは多岐にわたるプロダクトでさまざまな監視ツールを使っていたそうですが、New Relicに統一して管理コストを下げたそうです。他にも、監視設定をセルフマネジメント化して監視設定変更のリードタイムを削減してました。また、オブザーバビリティとは少しずれますが、障害対応発生時のSlack通知にRunbookのドキュメントリンクを貼ることで、障害対応負荷が特定の人に偏らないようにしたりしていました。

このRunbookの仕組みは、社内のお問い合わせ対応の属人性を解消するにも転用できるところがあるなと学びになりました。

他にも、New Relicを通して、デプロイ後の変化とか不用意なAWSコスト増とかをダッシュボードで確認できるので、自分のリリースによる影響とかを普段から意識できるのがとても良いなと思いました。

DMM.comさんはこの取り組みの結果、2020年から2023年時点の間で障害件数が73%削減できたらしいです。凄すぎる。

顧客価値向上による開発生産性向上

tably 代表取締役の及川 卓也さんによるプロダクトマネジメントに関するセッションでした。

顧客価値を高める領域は3つあり、それぞれを使い分ける必要があるようです。

• 当たり前品質：品質を高めすぎても顧客価値にはつながらない

• 一元品質：高めれば高めるほど顧客価値が高まる

• 魅力品質：当たれば顧客価値が高まる

現在の自分のタスクがどの領域で顧客価値を高めようとしているのかによって投入する時間や完成クオリティを考えていこうと思いました。

バリューストリームの最適化！計画最適化 AI 企業におけるプロダクト戦略を通した開発生産性の向上

VSM分析を使ってボトルネック（リードタイム長期化の原因）を特定してチームトポロジーを考える。その実現のために必要なシステムアーキテクチャを考え直す。みたいな流れが参考になりました。

システムアーキテクチャ = ソリューションと言われているのが腹落ちした感じがして良かったです。

エムスリー vs ラクスル エンジニアは事業KPIにどう向き合うのか？

個人的にDay1のベストオブセッションでした。エムスリーの取締役 CTOの山崎さんと、ラクスルの上級執行役員 CTOの竹内さんがROIという視点から開発生産性についてディスカッションをしてくれました。

プロダクト開発におけるROIについて

エムスリー山崎さん：Returnがどれくらい大きいかファーストで取り組む領域を決めていく。

ラクスル竹内さん：Return大切はAgree。それに加えてInvestmentをいかに小さくしてどれだけ多くの打席に立つのかが重要。開発生産性の向上については長期的視点でInvestmentを小さくすることにつながる。エンジニアが足りていないので特に開発生産性を高めてInvestmentを小さくすることが大事。グロースフェーズでは長期目線で技術的負債はできるだけ解消（投資）しながら進めていきたいところ。そのために計測は必須。

エムスリー山崎さん：チームは適切なサイズがある。MVP作ってPMFにのせるためのチームサイズはマジックナンバー7の±2名（PdM、PM、QA、エンジニア4 ~ 2人）でやり切る。PMF乗り越えて、グロースさせるフェーズでどうやってReturnとInvestmentをコントロールするのかが大事。機能開発が間に合わないから人員追加していきたいけど、そこをなんとか7名のままでやり切る方法を模索していく。7名でも回るように開発生産性への投資とPMFの質（ユーザの心を掴みきること）が大事。

事業責任者・PdMの方々とエンジニア組織の責務への考え方

ラクスル竹内さん：ビジネスプロセスの詳細を把握して、何がペインポイントで何を解消したらReturnが立つのか、もしくは構造が変わるのか、構造をどう変えて価値を生むのかを意識する。ここをエンジニアのOKRにする。

エムスリー山崎さん：エンジニアも正面から事業KPIに向き合うべき。エンジニアの目標は事業達成。そこを目指すために2つやることがある。一つ目は個人個人の評価を工夫する。二つ目はチームリーダーの責務を正しく設定する。個人個人の評価については、2割は事業成績で評価し、8割はエンジニアリング面での工夫（生産性向上の取り組みとかアーキテクチャ設計とか）を評価する。チームリーダーはCTOの認識を持って、その事業に責任を持つ経営陣の一角として扱う。間に執行役員とか管理職が入らないようにする。EMとかテックリードとなると狭い範囲の生産性になってしまう。CTOだと最終的なアウトカムに責任を持たないといけないから、事業部CTOみたいな役割を与える。

エムスリー山崎さん：エンジニアチームをビジネスサイドが言っていることを実行するチームにしてしまうとうまくいかない。PdMはビジネスサイド、エンジニアサイド、経営サイド、顧客等、どの方面に対してもうまくいくように翻訳（調整）してくれるのでめちゃくちゃ大事。

私の感想

エンジニアが事業KPIに向かうとなったら、やっぱり責務とか視座から変えていかないといけないなと思いました。

あとは、開発生産性にどれくらい注力するかの決定方法として、PMFしたあとのグロースフェーズで追加投資をせずに回しきるくらいの開発生産性を目指すという考え方が参考になった。めっちゃむずいと思いますが。

開発生産性への投資の意義は、「ROIのIを小さく維持できて、より多く打席に立てるようになること」というのが一番しっくりきました。

Day2で印象に残ったセッション

Mastering Developer Experience: A Roadmap to Success

あの「LeanとDevOpsの科学」の著者のNicoleさんの世界最高峰のKeynoteです。今回話されたテーマはDevX向上のために何から着手すべきか？です。

※Nicoleさんはあえて開発生産性ではなく、開発生産性を含むDevX（開発者体験）を強調していました。

優先度付けの基準について

• 制約要因になっているかどうか

• ステークホルダーへのインパクトについて様々な視点からみる

• 既に投資（着手）しているかどうか

• 完了までの時間

• グローバルなアクションか、ローカルなアクションか（企業単位かチーム単位か）

• 改善の相乗効果

上記の基準は一般的なものですが、これに「リモートワーク」とか「LLM」みたいなトレンド要因も含めていくとより洗練されると言っていました。

開発者体験の向上に向けたプラン作成について

テクノロジー面、カルチャー面、コミュニケーション面でプランを考える必要があると述べていました。

Technical details（すぐ考えられる）

Cultural details（時間をかけて考える）

Communication plan（心理的安全性を重視）

一番印象的だったのは、「Tech influences culture」というフレーズです。テクノロジーが組織の思考様式や行動に影響を与えるという考え方です。私の頭の中では、「テクノロジー」と「カルチャー&コミュニケーション」がつながっておらず別軸で考えていたんですが、この言葉を聞いてハッとしました。

今までは、「この新しい技術入れたら生産性上がりそうかもしれない」くらいのテンションで考えていましたが、それによって変わるカルチャーやコミュニケーションも意識することが大事だと気付かされました。

3軸を別で動かしていくのではなく、3軸つなげたストーリーとしてプランを立てられるようになりたいと思いました。

「Tech influences culture」に関する論文があるらしいので見てみようと思いました。

Metrics-informed development; theory and practice

元Spotify EMの方のKeynoteで、開発にメトリクスをどう活用していくかの理論と実践の話をしてくれました。

個人的に好きだったのが、Metrics Dependency Graphです。

メトリクスには先行指標（Build TimeやTest Flakinessなど）と遅行指標（App Rating, Recruitment consts, Profit）があり、それぞれ特性があります。

• 先行指標

  • アクションに紐付けやすい、ノイズが多い

• 遅行指標

  • 安定している、ビジネス上の目的、フィードバックループに時間的遅れが生じる

先行指標と遅行指標の両方を満たすものはないというのが課題。ただ、dependency graphのように先行指標を遅行指標に繋げていくことはできるので、どの先行指標を追いかけるかという意思決定をしていく。

ちなみに、先行指標がnoisyというのはハックが可能だからです。本質的なアプローチじゃない方法で先行指標を追いかけても、遅行指標につながっていかないので、カルチャーが大事だよと言っていました。

もしくは、追いかける先行指標に健全化指標も加えてずれない方法でやっていくのが良いかもしれないけど何になるのかはわからないなぁ。

4 Keysだと、ベロシティ系の指標のデプロイ頻度とリードタイムに対して、品質系の（健全化）指標のMTTRと変更失敗率を加えてるのでカッチリしているイメージ。だけど、これだけだとビジネス目標のoutcomeとかimpactといった遅行指標に対しての健全化指標ではない気がするからやっぱりカルチャーなのかなぁ。現実的かどうかわからないけど、North Star Metricsを使うのもありかもしれない。

仮説検証生産性とプロダクトグロースサイクル

あの「エンジニアリング組織論への招待」の著者の広木大地さんが、「プロダクトマネジメント領域における生産性評価の難しさとそれに向き合うための方法」について話してくれました。控えめにいって天才がすぎました。

色々な前提を揃えながら話を進めていったからこそ腹落ちできたので、ここで断片的に共有するのはやめておきます。

一つだけ学びを共有しておくと、セッションの最後の方で触れられていた期待付加価値と実現付加価値をどう接続するのかについてです。

これにはNorth Star Metrics(NSM)が重要だと述べられていました。NSMとは直接的な利益は生まないけど、ユーザエンゲージメントを通じて長期的な価値提供につながるだろうと判断できるものです。スラックでいうメッセージ送信数、Zoomでいう総MTG時間のような数値です。

そしてこのNSMを伸ばすためのグロースサイクルをシステム思考的に考えて、そのグロースサイクルの健全性をKPI評価するということです。グロースサイクルの要素間の繋がりは、非自明な仮説的な関係性になるようです。

グロースサイクルについて気になる方は、弊社にもグロースモデルというものが定義されているので参考にしてみてください！

爆速開発文化を支えるProduct Engineerの開発生産性向上の取り組み

「開発が爆速で進んでいる組織のカギな何だろう？」と気になっていましたが自分なりに答えを見つけることができました。

それは「アウトカム重視」 ✖️ 「越境マインド」 ✖️ 「圧倒的な型化」だと思います。

越境については、プロダクトエンジニアが顧客ヒアリングを行うなどビジネスサイドにも越境するのでコミュニケーションコストが減りますし、一次情報を獲得できるので無駄なものを作るリスクも減ります。

型化については、アウトカムの予測値計算、優先度決定基準、顧客理解方法、体験の作り込みフェーズのアクション、レビュー等の型がかなりかっちり作られていました。

ちなみに、アウトカムの予測値が0のもの（技術的負債の返済とか）については、「改善デー」を作ることで定期的にタスク消化しているようでした。

意思決定基準が揃えられているというのが圧倒的な速度を生み出しているんだろうなと思いました。またその型を浸透させるための前提として、「LayerXのプロダクトエンジニアに求めること」も明確に定義しているというのが強いなと思いました。

開発生産性の観点から考える自動テスト

最後のセッションは@t_wadaさんによる、自動テストに関する話でした！

さすがとしか言えないですが、かなり哲学的な内容で興奮しました。

自動テストにおける目指すところ（生産性が高い状態）とは信頼性の高い実行結果に短い時間で到達する状態を保つことです。

このために、偽陽性とか偽陰性とかFlakyなテストとかを無くしていきテストの結果を疑わなくて良い状態にすることや、DBやネットワークアクセスとかを限定してテストサイズを小さく保つことで高速にするみたいな工夫が大事になります。

テストに関しては、現場レベルですぐに取り組める内容だと思うので明日から実行に移していきたいですね。

まとめ

そもそも、開発生産性とビジネスインパクトをつなぐのが難しいのは構造的な理由があります。それは開発生産性を測る指標はビジネスインパクトを測る指標の先行指標であるという関係性です。

今年のセッションでは、開発生産性とビジネスインパクトの間の指標であるアウトカムの生産性（期待付加価値の生産性）を測るという方法が提案されていました。（広木大地さんのセッション）

別の視点での「開発生産性とビジネスインパクトをつなぐ方法」はエムスリーとラクスルのセッションで話されていた「ROI視点で考えること」も個人的にスキでした。「Investmentを小さく維持して何回も打席に立つという経営方針を満たすために、エンジニアが開発生産性の向上に投資することが大事」というのは事業会社の本質的な視点が含まれていると思います。

そして開発生産性向上施策をどう優先順位付けして進めていくかについては、NicoleさんのKeynoteで言われていたように、一般的な指標に加えて「リモートワーク」や「LLM」等のトレンドを含めて考慮する必要があることがわかりました。

実行プランの作成においては、個別の施策を進めていくのではなくテクノロジー、カルチャー、コミュニケーションの3要素の相互作用を意識した上でじっくり作成していく必要があるようです。

実行フェーズでは、SPECEやDORAや4Keys等のMetricsで計測していきながらフィードバックサイクルを素早く回していくことが大事だとわかりました。

より全体的な視点で開発生産性というテーマを捉えられるようになったのがよかったです。めっちゃ濃い内容で楽しかったです。これから業務にどう活かしていくかはマストで考えていきたいです。

参考文献