開発生産性カンファレンス2024に行って思ったこと

2024年6月28日、29日に虎ノ門ヒルズフォーラムで開催された開発生産性カンファレンス2024に行ってきた。

dev-productivity-con.findy-code.io

3行でまとめると

  • 開発生産性を含む DevEx の重要性
  • 開発生産性をどのようにビジネスアウトカムに結びつけるか
  • 開発生産性を向上させるための組織作り、プラットフォームエンジニアリングと越境性

がとても大事。

開発生産性カンファレンスとは

Findy さん主催の開発生産性に関する大規模カンファレンスイベント。

昨年7月の開催では、“開発生産性とは何か” をテーマに、 その定義や進め方について切り開かれました。

2024年は、事業インパクトにつながる開発生産性の捉え方や進め方、 具体的な生産性向上に向けた施策についてもう一歩踏み出します。

今年のテーマは生産性向上に向けたより具体的な施策についてらしい。

去年の申し込みは600人程度だったのが、今年はなんと2000人の申し込みらしい。流行っているな、開発生産性。

参加者の属性

ちなみに来場者の属性内訳はこんな感じらしい。CxO、役員クラスが15％って結構すごい。

現場の開発者というより、組織の生産性に関心があるリーダー/マネージャー層が割合としては多そう。 セッション登壇者も現場のエンジニアというより、何かしらをマネージングしている人が多い印象だった。

ブース

スポンサーブースが37社ぐらいあってスタンプラリー回るのが楽しかった。 開発生産性の改善に力を入れている企業と、開発生産性を上げるためのプロダクトを作っている企業がたくさんいた。

開発生産性という答えのない領域だからこそ、ブースで色々と各社の話を聞けるのは貴重な機会だった。スポンサーするだけあって流石にどの会社も4keysなどのメトリクスをしっかりと計測して改善を回していたのが印象的だった。

テーマがテーマだけに来場者の幅が広いからか、ブースに行くと「職種はエンジニアですか？」って聞かれがちで、名札にエンジニアって書いておいた方が良かったな。

各ブースのアンケートの回答も実に興味深い。

セッションの感想

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

このセッションは来場者のみの限定セッションなので詳しいことは書けないのだけど、J.B さんは意外と当たり前のことを言ってるなと思った。しかし、当たり前が一番難しいのも事実。言うは易く行うは難しというやつ。 こういう貴重な話が聞けるのでぜひみんな現地に来よう！

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

https://dev-productivity-con.findy-code.io/2024?m=2024/m/OQoR_bNh

  • 開発生産性とは投資に対するリターン
    • 対象が何か、使われないソフトウェアに対して生産性を上げても意味がない
    • 初めからゴミだと思って作ってる人はいない
    • いかに価値のあるものを見極めるか
  • プロダクトエンジニアリングとプラットフォームエンジニアリング
    • プラットフォームエンジニアリングにもプロダクトマネージャーが必要
    • お互いの越境性も大事
  • 事業価値と顧客価値、これはトレードオフではない
    • 両立することができる

マイクロサービスの現場からプラットフォームエンジニアリングの可能性を探る！

https://dev-productivity-con.findy-code.io/2024?m=2024/m/KXkTWNZO

speakerdeck.com

speakerdeck.com

マイクロサービスを構築する中でプラットフォームエンジニアリングがどのように振る舞うかを、具体的なチップスも踏まえて話してくれた。

  • Platform as a Product
    • 開発者が求めているものを理解するコミュニケーションが大事
  • オンボーディングが楽になるようにドキュメンティング
  • 現場の課題と向き合う
  • マイクロサービスはむずい、デメリットもたくさんある
  • 車輪の再発明を防ぐために情報共有のしくみがあるとよい

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

https://dev-productivity-con.findy-code.io/2024?m=2024/m/J-DI2YMu

殴り合いと抱擁の40分。

前半は ROI で何を重視するかの話。エムスリー山崎さんは圧倒的にR重視。Rがあれば全てを帳消しにできる。一方で、ラクスル竹内さんは I を小さくなるようコントロールして打席に立つ回数が重要だと。R ももちろん大事だけど必ずヒットするわけじゃないから生産性上げて打数を増やすのも大事。

主題であったエンジニアが事業KPIにどう向き合うかに関しては、エムスリーは正面から向き合う。エンジニアがいないと事業が成り立たないということはエンジニアの目的は事業達成にある。小規模であってもチームのリーダーは実質その事業部の CTO なんだという。VPoE などの中間管理職が入り込む余地がなく、事業と直接対面してもらう。そうすることでエラスティックで自己組織的な組織ができる。

Mastering Developer Experience: A Roadmap to Success

https://dev-productivity-con.findy-code.io/2024?m=2024/m/5SRSpFqp

「LeanとDevOpsの科学」の著者である Nicole さんの基調講演。「LeanとDevOpsの科学」は開発生産性の世界では必読の一冊であり、その著者の話を直接聞けるのはすごい貴重な機会。Q&Aタイムも長く取られており、会場に行って良かったなあと思った（着くの遅くてサテライトの方だったけど）。

「実践チームトポロジー：プラットフォーム性とイネーブリング性の戦略」

https://dev-productivity-con.findy-code.io/2024?m=2024/m/BTQjY70w

speakerdeck.com

タイミーがチームトポロジーの考え方をどのように組織に取り入れているか、というお話。赤澤さんのベシャリが相変わらずうまく、眠くなる隙がない。

ケイパビリティの不足とリソースの不足を混同しないという点と、プラットフォームが行き過ぎるとストリームアラインドチームが自己完結しなくなるので、イネイブリングも大事だよね、というのはなるほどだった。 ここでもやはり各チームの越境性が大事というのがポイントだった。

「開発生産性を上げる改善」って儲かるの？に答えられるようにする

https://dev-productivity-con.findy-code.io/2024?m=2024/m/IVK0ezXg

speakerdeck.com

管理者視点だと細かいことは気にしてなくて、良きタイミングで意図したものが出てくればそれでいい。ので本質的には開発生産性なんて意識しないのだけど現実そうはならない。結局見ている情報のレイヤーが違って、誰が何をどう翻訳してコミュニケーションを取るか、というのが整理されていてとても良かった。

  • なぜ開発生産性を意識するのか
    • 信頼が積み上がれば、開発生産性は気にならなくなる
    • 管理者視点では予定通りモノが出てくればあとはどうでもいい
    • エンジニアの見積もりを信じて計画を作る
    • なのに毎回遅れる、なぜ遅れるのかはわからない
    • 開発側からすると遅れた事実は認識しやすいが、なぜ遅れたかは数値化しにくい
  • 事業責任者側からすると、狙ったタイミングでモノが出てくるか
    • 思い通りにいかないと優先度を細かく決めたくなる
    • そうなると内部改善の優先度は上がりづらくなる
  • 具体的な説明をする
    • リファクタリングしたいという言葉を使わない
      • 具体的に何やるかわからない、終わりがない
    • テスト書くのかなんなのか具体的にする
  • どのフローの話か、どのプロセスの話か、どのレイヤーの話か、生産性を上げて何がしたいのか
  • エンジニアは自分の操作可能なプロセスを見がちだが、全体を見ないといけない
  • スループット、コスト、PL、レイヤーによって気にする数字が違う

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

https://dev-productivity-con.findy-code.io/2024?m=2024/m/J3sc_nxJ

https://gamma.app/docs/-necbojc9wcdk8yw

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

https://dev-productivity-con.findy-code.io/2024?m=2024/m/qbq5bFLd

speakerdeck.com

久しぶりに twada さんの講演を聞いたけど、テストサイズで戦略的に自動テストを書いていく、というのはなるほどと思った。

  • なぜ自動テストを書くか
    • 素早く躊躇なく変化し続ける力を得るため
  • アイスクリームコーンのアンチパターン
    • E2E が多くなり実装工数も増え、フレイキーで信頼性が欠如する
    • これらはテストの分類の解釈がブレがちで正しく議論できていない
      • モックせず本物の DB を使ったテストはユニットテストなのかインテグレーションテストなのか、とか
  • そもそもユニットテスト、インテグレーションテスト、E2Eテストという分類は適切ではない
  • Small、Medium、Large と、サイズで分類する方が理にかなっている
  • その上で、いかにサイズダウンさせていくかが大事
    • サイズが小さい方がメンテナビリティが高く、信頼でき、早く実行できる
  • テストダブルを使うとテストサイズを下げることができる
  • 自動テストを増やすことが開発者に根拠のある自信を与える

全体の感想

開発生産性について話す、考えることはすごく難しい。そもそも開発生産性といったときにそれが何を意味しているのかが不明瞭というのがある。今年のセッションでもまず「開発生産性とは何か」を定義してから本題に入る方が結構いた。

Nicole さんのキーノートにもあったけど、開発生産性といっても色々な切り口があるが、DevEx へのシフトを意識していかないといけない。組織としてのメトリクスに加えて、現場の開発者体験がどのようになっているかが重要だと。「LeanとDevOpsの科学」にもハイパフォーマーな組織の方が社員エンゲージメントも高く、離職率も低い的なことが書いてあった気がする。社員のエンゲージメントがないと組織に持続可能性がなくなるので、なんならそこが一番大事まである。そういう組織であること自体が採用競争力にもなる。

そして、開発生産性をビジネス上のアウトカムにどう繋げるのか、それを開発者がどの程度意識するのか、というのも難しい点の一つ。今年はこの点に踏み込んだ内容を話すセッションがたくさんあった気がする。個人的には営利企業であり、テック企業なのであれば、開発生産性の高さが利益とユーザー価値に直結するわけであるから、生産者としてのエンジニアがそれを意識するのは自然のことだと思う一方で、ビジネス KPI を追いすぎるとダークパターンのような邪悪な発想に陥るリスクがあるのもまた事実。この辺は広木さんのセッションでも話があったけど、North Star Metrics を売り上げではなく課題解決量に置いておくというのがポイントになってくる。エンジニアがどの程度意識するのかについては DMM の石垣さんのセッションが参考になる部分が多かった。

また、生産性向上における組織づくりの話では、チームトポロジーやプラットフォームエンジニアリングのようなトピックがよく出ていた。「LeanとDevOpsの科学」だけでなく「チームトポロジー」も必修科目なぐらい引用されていたように思う。それから、プロダクトエンジニアリングとは別にプラットフォームエンジニアリングを育てていくというのも、及川さんのセッションはじめ色々なところで話されていた。ある程度組織が大きくなると構造化が必要で、プラットフォームエンジニアリングの必要性が高まる。その際に越境性を忘れてはいけないというの大事なポイント。事業ごとに縦に割って、技術ごとに横にも割ると結構チームが細分化していくし、細分化すればするほど役割が明確になって逆に情報連携が弱くなったり間に落ちるボールを拾いづらくなったりするので、何かしらの仕組みで解決できるといいんだろうなあ。

他にもソフトウェア・エンジニアリング・インテリジェンスやら、DORAv2 やら様々なトピックやトレンドに触れることができてとても楽しかった。すごく勉強になった2日間だった。