開発生産性カンファレンス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日間だった。

RubyKaigi 2024: 熱狂と技術の融合

タイトルは AI に考えてもらいました。

 

2024年の5月15日〜17日に沖縄県那覇市で行われた、RubyKaigi 2024 に参加してきた。

rubykaigi.org

2022年の三重、2023年の松本に引き続き3回目の RubyKaigi。行くたびにとんでもなく"アツい"イベントだなあと思うのだけど、今年もまたとんでもない熱量を感じて帰ってきた。

今年も企業からの派遣という名目で、会社に費用を負担してもらい、仕事として沖縄に赴いた。正直な話、最近 Ruby を全然書いていないので自分が行ってもいいのだろうかと内心思っていたが、最近会社としても個人としても技術広報に力を入れ始めていたので、自分としては今回はその文脈で立ち回ろうかなあなんてことをぼんやり思っていた。

会社としての参加レポは会社の技術ブログに書いたので、ここでは個人的な感想をつらつらと残しておこうと思う。

blog.giftee.dev

 

RubyKaigi は地方で開催されるということもあって前乗りする人が結構な数いる。前乗りと言っても前日とかではなく、なんなら土曜日ぐらいから沖縄にいる人が観測され過ぎて、もう RubyKaigi 始まってるんじゃないかと思うぐらいだった。

自分もしっかり前日に前乗りし、普段出張などない身分なので会社のお金で飛行機に乗る感覚を噛み締めていた。那覇に着いたら雨がすごく、「これ明日以降、天気大丈夫なんだろうか」と不安になったが、結果的に Rubyist パワーで会期中は晴れるという奇跡。なお、Kaigi 直後に沖縄は梅雨入りした模様。

 

今回の宿はホテルではなく Airbnb で一軒家借り上げでの宿泊。現地参加のエンジニア10人がみんなで仲良くひとつ屋根の下。修学旅行感がすごかった。ちなみに1階にリビング、2階が寝室という構成で、夜の飲み会が終わった後リビングでダラダラと話ができるというのが良かった。逆に寝るタイミングを逃し夜をふかしすぎて寝不足になるというデメリットもあった。ちなみに部屋割りは先輩後輩関係なく仁義なきブーサーで決めた。

リビングでダラダラする図

 

 

RubyKaigi は国際カンファレンスなので世界中からいろんな人が集まる。アフリカの先っぽで Ruby 書いてる人がいるってこと、すごい。

 

今年はネックストラップの色で、自身の撮影OK・NGを表明できるようになっていて、ネットに写真をアップされたりしたくない人への配慮がなされていた。とても良い仕組みですね。ブログを書く側としても大変助かる仕様だった。毎年運営がアップデートされ続けててすごい。

ネックストラップ

自社ブース

画像

沖縄式じゃんけんことブーサー

今年は比較的長い時間スポンサーブースに立ってたくさんの Rubyist とお話をさせてもらった。来訪者から「ギフティさん知ってます〜」という言葉をいただく機会が多く、以前に比べて認知度が体感上がってきたかなあ、と嬉しい限りだった。毎年スポンサーブースを出しているので、Ruby 界隈では徐々に認知が獲得できてきたように思う。

その一方で、こういう反応をされるうちはまだまだダメだなあとも思った。「知ってます」という言葉を使われるということは、つまり世間的にまだ認知度が低い企業だと思われているということの裏返し。例えば、メルカリの人に対してわざわざ「メルカリ知ってます」とは言わない。それは知っていて当然だから。うちはまだ知ってて当然の水準にはいけてないということ。まあこれは極端な例だし、そのような驕りはなかったのである意味当然と言えば当然なんだけど。

あとは闇雲に認知を取りたいわけでもないというか、ギフトというサービスもそうなのだけど、ウチがウチがと前面に押し出すのではなく、意味のある認知というか、適度な"間"的なものがないと、よくないなと。

スポンサーしてブースを出しているということは少なからず認知度向上や採用目的もあるわけなんだけど、RubuKaigi はアカデミックかつギークなイベントだと思うので、企業としてはそのコミュニティへの還元が一番の目的なわけで、その辺とのバランスが難しいなあ。

 

話は変わるけど、スポンサーの顔ぶれって毎年そこまで大きく変わらないし、わざわざお金出して RubyKaigi に来る人もなんだかんだ毎年同じなんじゃないかと勝手に思っていたので、回数重ねるごとにブース出展の広報効果って薄れてくんじゃとふと思った。

しかし、ANDPAD さんのアンケート結果によると、（ブースを回っていた人のうち）40％の人が初参加だったとのこと。初参加が40％もいるならやる意味が結構あるのかな。

tech.andpad.co.jp

 

そして、今年もほぼ全ブース回ったけど、どこも趣向が凝らされていて楽しかった。

特にハイドレーションスポンサーの SmartBank さんはインパクト大。ドリンクご馳走様でした。

SmartBank さん

酒豪伝説にもお世話になりました。これのおかげでハブ酒と戦えた。

 

セッション

ぺんさん による「Writing Weird Code」。オープニングキーノートでいきなり魔法を魅せられてるんですが...。RubyKaigi 2022 の TRICK で金魚を見て感動すら覚えたのだけど、今年は Self TRICK とは。ゆらゆら動くクラゲを見ながら、この技術で殴られる感じが RubyKaigi が始まったなあと。オープニングに何を話すのかって、選ぶ側も話す側もそれなりに悩むと思うんだけど、TRICK は Ruby 自体の凄さというより、Ruby 使ってこんな面白いことができるんだぞという、プログラミングの楽しさを思い出させてくれるという意味ですごいいい入りだったなと個人的には思った。

 

あと kaneko さんの「The grand strategy of Ruby Parser」。パーサーの話。相変わらずの早口で日本語なのに話についていくのがむずいw 正直パーサーの技術的な話はわからないのだけど、Ruby としてのパーサーの現在地と未来についての話は面白かった。CRuby のパーサジェネレータは従来の Bison から Lrama にリプレイスされた。そして長期的にはユニバーサルパーサーを提供したいと。

speakerdeck.com

 

Matz のキーノートが良かった話は会社のブログにも書いたので割愛。

夜のお楽しみ

オフィシャルパーティは海辺で BBQ。去年はホテルの大広間だったのにテイスト変わり過ぎw

沖縄のサンセットを見ながら、みんなで肉を焼いて酒を飲むのはエモい。風も強い。

地域 rb の人たちが集まるテーブルにお邪魔させてもらって、roppongi.rb が復活する話などを聞けた。少し前に、SmartBank さんの力で gotanda.rb も復活したし、roppongi と時を同じくして ginza.rb も復活するみたいで、地域コミュニティが盛り上がっているのはすごい良い。

 

2日目の夜はスポンサー各社が様々なドリンクアップを開催してくれており、路頭に迷うことなく Rubyist どうしワイワイできるのが嬉しい。SmartHR さんのドリンクアップに行かせてもらったのだけど、途中で沖縄民謡ライブが行われたりと、開催地沖縄を存分に感じられる飲み会だった。今年のドリンクアップは RubyKaigi 初参加枠を設けている企業が多くて、すごいいいなあと思った。二次会は自社開催のドリンクアップへ。

 

3日目の夜は mov さん主催で国際通りのれん街を貸し切ってのアフターパーティ。

この空間全部を Rubyist が埋め尽くしてるの半端ねぇ...。初っ端からいいペースでハブ酒を何杯かあおって気持ちよくスタート。

ハブ酒で乾杯

スナックスペースもあってカオス。

自由に席を立って移動しやすい仕様になっていてよかった。

 

からの RubyMusicMixin。

IVRy の barometrica さんでブチ上がり。

最高に盛り上がったまま力尽きて退散。

 

三日三晩（前日も合わせると4日間）セッションを聞いて飲んでを繰り返すのは相当な体力がいる。RubyKaigi を全力で楽しみきるには事前の身体作りも重要なのだ。

メシの記憶

ちるりの冷麺

まるたまの味噌汁定食

会場のお弁当

いちぎん食堂のゆし豆腐そば

浮島BASE のソーキそば

花笠食堂のなんとか定食

ジャッキーステーキハウスのステーキ

RubyKaigi を締めるステーキ。

サーターアンダギーを食べ忘れた気がする。

まとめ

RubyKaigi はやっぱりすごい。Ruby 大好きな人たちが1000人以上も集まって3日間、しかも夜通し盛り上がる。楽しくないわけがない。Ruby のコミュニティ力の高さを実感できる。そして（難しすぎる）セッションや他の Rubyist との交流で色々なモチベーションが高まってしまう。そして技術的な未熟さを痛感させられるという意味でもヤバいイベントである。

あと運営がすごい。これだけの巨大なイベントを大きな問題なく遂行できるのすごい。運営スタッフ、そしてスピーカーたちに感謝。


よもやま

帰りの飛行機でキングダムの最新刊でも読んで返るか〜と思って空港の本屋に行ったら...これが離島クオリティ。最後まで沖縄を感じることができたのであった。