2025年振り返り
仕事
今年も仕事頑張ったなあという1年だった。チームのリードエンジニアとしてプロダクト開発全般に責任を持ちつつ、担当しているプロダクトの数も増えて、見る範囲が広がっている。
そして、今年は開発よりも要件整理やチーム間の調整、採用などに割く時間が相対的に増えた。採用に関しては求人票を見直したり、テックブログなど採用にプラスのアセットを積み増したり等々をやっているけど、計画通りに採用を進めるのは中々難しい。中々というか超難しい。エンジニア採用市場、苛烈すぎやしないですかね。。まあでも採用は長期戦なので、しっかりアセット積むなりして採用競争力上げていくしかないと思う。
それから、AI ツールが色々出てきて、開発のやり方が大きく変わってしまった感じ。1年中ずっと AI の話題で持ちきりだったよね。ホットエントリとか Zenn や Qiita などのトレンドが全部 AI 関連の記事になってしまい、流石にちょっと食傷気味だった。AI ツールも目まぐるしく新しいものが出てきてもうわけわからなかった。他社の事例とかを見るとめっちゃ使い倒してて、自分はあんまり AI 使いこなせてないなあとなるなどした。
自分の開発作業そのものはどうなったかというと、そもそも最近あんまりコード書く仕事していなくてアレなんだけど、それでも自分の出すアウトプットの7割ぐらいは AI が書いているぐらいの感覚があった。いかに AI に精度高いコードを書いてもらうか、という視点になるので、開発のやり方そのものがガラッと変わってしまったなという感覚。世の中の仕組みがブレイキングチェンジされている真っ只中な気がするけど、それに適応できるのかという不安もちょっとだけある。自分がジュニアの時に AI が出てこなくてよかったかも。
自分の市場価値（生み出せる価値）的なものが尚更よくわからなくなる1年だった。自分自身のキャリアについてもっと向き合わねば。
カンファレンス、イベント参加
- EMConf JP 2025
- 自分はマネジメントにそこまで高い関心があるわけではないけど、イベント自体はめっちゃ楽しめた
- チェキとかアンカンファレンスとかイベント自体に偶発的な要素が色々とあって、趣向が凝らされていていいなと思った
- RubyKaigi 2025
- Kaigi on Rails 2025
- 同僚が登壇する（すごい！）ので応援に行った
- GoConference 2025
- セッションと並行してワークショップがたくさん開催されていたのもよかった（自分参加してないけど）
- 開発生産性 Conference
- 去年に引き続き2年連続で現地参加
- 去年の参加人数が2100人だったのに、今年は3800人って熱高まりすぎでしょ
- オープニングキーノートが Kent Beck で、クロージングキーノートが t-wada さんなのはアツすぎる
- 2025年は AI の話で持ちきりだった
- 去年までは開発生産性の測定、組織ビルド、生産性向上のためのツール、自動テスト、プラットフォームエンジニアリング...みたいなテーマの登壇が多かった気がするけど、今年はほぼ AI 絡み
- 当然と言えば当然
- t-wada さんが言っていた、抽象度が一段上がるだけなのだろうか？、という部分は大変興味深くて、個人的にはそうなっていくだろうなあと思う
- 自然言語で指示を出し、それがコードに変換されるだけ
- アーキテクチャ Conference 2025
- サム・ニューマンが「マイクロサービスが最適解か？」というタイトルで話すのがめっちゃいい
- あとグラレコよかった
対外的なアウトプット
本業が忙しくてあまり時間が割けなかったけど（言い訳）、何本か記事を書いた。
- 会社技術ブログ4本
- 会社採用広報ブログ1本
- Zenn
- はてなブログ1本
勉強会登壇も2回ほどした。五反田勤務の者として、Gotanda.rb は一回登壇しとかねば、という気持ちが回収できた。
- テックブログ運営 井戸端会議〜2025年を走り切るために〜
- ギフティの技術ブログ 再出発とこれから
- LT 抽選落ちで飛び込み登壇だった
- Gotanda.rb#63
その他
- 走
- 今年もランニングは続けられて、トータル800km走った
- 特に10〜12月は毎月100km以上走れた
- 一回あたり10kmとか問題なく走れるようになってきた
- ペースも1kmあたり4分半前後で安定してきた
- 夏が暑すぎて全然距離伸びないのが課題
- 歩
- 壁
- ボルダリング始めようかなと思って、年始に2回ぐらい行って、その後行くのが面倒くさくなって結局それ以降行かずじまい
- 面倒というか、ベースの筋肉無さすぎてある程度鍛えないと中々思うように登れなくてそのハードルを越えられなかった
- シューズ買わなくてよかった
- 逆にシューズ買ってたら、使わないともったいない精神でもっと行ったのかも？
- ボルダリング始めようかなと思って、年始に2回ぐらい行って、その後行くのが面倒くさくなって結局それ以降行かずじまい
- 山
結
振り返りはちゃんと年内のうちに書こうね（戒め）
EMConf JP 2025 の感想を書いて熱を増幅させていく
EMConf JP 2025 に参加してきた。
初開催のカンファレンスで、どんな感じなんだろうなーと思いながら参加したけど、EMではなくエンジニアである自分の視点でもめっちゃ楽しめた。
EM のカンファレンスなので、当然 EM の人向けの内容で、来ている人の7割ぐらいは EM ロールの方だったのかな？
EMConf JP 2025 #emconf_jp カケハシのブースにお越しいただいた皆さん、ありがとうございました！
— カケハシ技術広報 (@kakehashi_dev) 2025年2月27日
「あなたの伸びしろはどこですか？」のアンケート結果はこちらとなりました。皆さんそれぞれの伸びしろについて深く話すきっかけとなり、大変有意義な時間となりました。 pic.twitter.com/9askSAZJvs
EM はスーパーマンじゃない
EM ってエンジニアのマネジメントではなく、エンジニアリングのマネジメントをすることを指すよねと。つまり、マネジメントの対象は人に限らず、エンジニアリングという行為そのものという話。
オープニングキーノートの広木さんの話では、エンジニアリングの4つのPとして以下が挙げられていた。
- ピープルマネジメント
- プラットフォームマネジメント
- プロジェクトマネジメント
- プロダクトマネジメント
で、これ全部できないといけないのかというとそんなことない。
マネジメントの元の意味は「なんとかすること」なので、「価値を実現する」ために「なんとかする」ことができれば良い。 自分でできなければ、それができる人なりモノなりを調達すればいい。
クロージングキーノートの岩瀬さんの話でも
How はチームに任せて、自分は周りのブロッカーを外し続ける
と言っていた。
自分でなんでもできる必要性はないものの、ものの見方がプレーヤーとは全然異なる気がするのでそこらへんの視座の上げ方がむずそうだなあと思った。 今まで制約だったものが変数になるはずなので、より言い訳が効かなくなるというか。だからこそ面白いのかもしれない。
また、「できる」必要はないけど「わかる」必要はある、という話もあって、4つのPのどこかだけに強い興味がある、という状態だと限られた状況下での EM としてしか機能しなくなるんだろう。
それって結局何でも屋じゃないか！！笑というツッコミを入れつつ、 自分は割とジェネラリストタイプであれもこれも知ってみたくなるタイプなのでそこはあんまり懸念がないんだけど、一方で「わかる」の基準ってなんなんだろうって思った。色々やってるとどうしても広く浅くになりがちなので、どこまでわかってればそれを「なんとかできる」状態になっていると言えるのか、みたいな。うーん難しい。未知のことはわからないので、そういうものが出てきた時に「わかろうとする姿勢」のほうが大事なのかも。
エンジニアリングと経営を繋ぐ
エンジニアリングの意思決定を経営とどう繋ぐかというのは、EM の重要な役割の1つだと感じた。
EMとして技術戦略の決定をいかに経営という視点とアラインを取っていくかという話は開発生産性カンファレンスなんかでもよく取り上げられており、世の中のいろんな会社で悩んでいることなのかなと思う。
結局その決定って儲かる（PLにポジティブ）んですか？とか技術的負債の解消って事業的に意味があるんですか？というのは技術的意思決定の永遠の課題だと思う。
日々、テックリードとして意思決定する際もチラチラと頭をよぎることがあるけど、EM になるとよりそういう部分と密に絡んだ判断が増えていくのかなと思う。 そうした部分をどう要素分解して言語化してやっていくか、という話が聞けて参考になった。
プレイングマネージャーの葛藤と可能性
プレイングマネージャーについて話すセッションもいくつかあった。
多くのエンジニアにとって、マネージャーになることでエンジニアリングから遠ざかることへの不安は大きい。そもそもモノづくりがしたくてエンジニアになった人が多いため、人のマネジメントに専念することへの抵抗感は自然なものだろう。自分もその一人だ。
しかし、エンジニアリングとマネジメントを両立させるプレイングマネージャーという選択肢も確かに存在する。
プレイングマネージャーの難しさは、エンジニアリングとマネジメントという異なる性質の業務をバランスよく行うことにあると思うが、その両方の視点を持つことで、技術的な意思決定とビジネス的な判断をより適切に結びつけられる可能性もある。
また、完全なマネージャーへの移行を望まないエンジニアにとって、プレイングマネージャーは魅力的なキャリアパスの一つとなりうる。 ただし、両方の責務が中途半端にならずに両立させていかないと意味がないので、うまく頭をスイッチングさせながらやっていかないといけないのがすごい大変そうだ。
プレイングマネージャーという役割の難しさと同時に、その可能性についても考えさせられた。
増幅と触媒
今回のカンファレンスのテーマが「増幅」と「触媒」だった。
前日譚では「循環」というワードも出てきており、このカンファレンスを起点に知識や熱がコミュニティを通して増幅していくことを狙ったとのこと。
弊社ギフティも「キモチが循環する社会」というのをタグラインとして掲げていたりして、循環というところには個人的にそれなりに思い入れがあり、いいテーマだなあと感じた次第。 薄い内容かもしれないけどこの感想も増幅の一助になればなと思う。
まとめ
様々なセッションやブースでの話を通して、EM というものの役割として、明確に定義されたものはなくて、各社の EM の定義自体が割と色々だなと改めて思った。なので、自分の組織における EM だったり、それが対象としている問題領域だったりを改めて確認するというか、考えてみようかなという良いきっかけになった。一口に EM と言っても今の組織に必要なケイパビリティを備えるために EM を定義する必要がある。
ただ、どの EM も結局レバレッジの効くことをやっている、というところは変わらない気はする。個人のアウトプットではなく、自分の働きかける周囲全体のアウトプットを上げていく活動をするというのが大事。あとはその力点をその時々でどこに置くか、なのかな。
自分はまだエンジニアとして現場の急先鋒的な動き方をしたいなと思っているけど、それはそうとマネジメントについて考えさせられる良いイベントだったなあと思う。
ソフトウェアエンジニアと抽象
抽象化、それは人類だけに与えられた力。
「アドレナリンジャンキー」の冒頭にこのようなことが書いてある。
抽象化は人間独特のものだ。私たちはいつ何どきでも、目覚めているかぎりは抽象化を行っている。しかし、ずっとそうしてきたわけではない。有史以前のいつか、はじめて抽象化が行われた瞬間があったはずだ。原始の人類が何かを見つめ、なんとなく見覚えがあるなと思い、突然 "ああ、またアレだ！" とひらめいた瞬間が。それが最初の抽象化である。その瞬間から、何もかもが変わった。人はこの地球上に解放された。
実際には人間以外の動物も抽象を認識できることはあるらしいが、これほど高度に抽象化という能力を利用しているのは人間だけである。
抽象の定義
多くの物や事柄や具体的な概念から、それらの範囲の全部に共通な属性を抜き出し、これを一般的な概念としてとらえること。
ソフトウェアエンジニアと抽象
ソフトウェアエンジニアをやっていると抽象に触れる機会は多い。むしろ設計というのは如何に抽象を見出すか、がほぼほぼであるという見方さえある。モジュールやクラス、関数を定義する際、そこには必ずと言っていいほど抽象の概念が出てくる。
なぜ抽象を使うことがソフトウェア開発で重要なのか。
ソフトウェアというのは変更容易だからソフトなのであり、ソフトであるためには抽象を使って個々のパーツを交換可能にしておくことが大事になってくるからだ。抽象を見出し、インターフェースによってパーツ同士を疎結合にすることで、具体を知らずに済む。それは交換可能性を提供し、また認知負荷のコントロールを可能にする。抽象化しておくことで、扱う具象が増えた際に最小限のコストでその増加に対応することができるようになる。プログラムを書くとき、エンジニアは個々のデータや手続きを単純化し、モジュールやクラス、関数といった抽象的な構造にまとめる。この過程では、どの部分を共通化し、どの部分を分離するべきかを見極める力が試される。
コードの具体的な話でいうと、GoF のデザインパターンの Abstract Factory パターンが想像しやすいのではないだろうか。
また、具体と抽象を行き来することについての重要性は色んな分野で言われているが、「アーキテクトの教科書」の著者も最近このような記事を書いている。
抽象化のレベルが高まれば、システム全体の可読性や保守性が向上する。一方で、過度な抽象化はコードを複雑化させ、現実の問題から乖離するリスクもある。例えば、すべてを汎用的に設計しようとするあまり、具体的なユースケースに対応できない状況に陥ることも少なくない。 抽象化のバランスを見極めるというのが大事なのである。
ビジネスパーソンと抽象
エンジニアもキャリアを積む過程で、チームをリードするようになり、マネジメントの領域に入っていく人も少なくない。
時に、ビジネスパーソンとして役職が上がっていくと、扱う問題の抽象度が上がると言われることがよくある。これは間違いではないが、曖昧であることと抽象であることを混同している場合がよくある。 抽象的であることと曖昧であることは全く違うことであるにも関わらず、不確実性が高く曖昧なことを指して抽象的と表現するケースが多いような気がする。
例えば、マネージャーの仕事は抽象度が高くて難しい、という話をよく耳にするが、それも曖昧な側面を指して使われるケースが多いように思う。
部下一人一人の性格に合わせてマネジメント行動を変えないといけない、というのは個別具体にズームインしており、抽象というよりむしろ具体を考えるアクションである。
一方で、どの部下にも普遍的に適用できるマネジメント法則を見出し実行するのは抽象的な行為である。管理する部下の数が増えれば増えるほど共通項が狭まっていくので、そうしたことを定義する難易度は上がる。
システムにだけ向き合っていたのとは対照的に、人間や市場という変数の多いものを対象に取って、ズームインとズームアウトの双方の頭の切り替えをしながら対応しないといけない、それがマネジメントの難しさではないだろうか。
抽象を定義するのが難しいのは、何をどの程度の範囲で抽象化するかを定義するのか悩ましいからで、多くは対象とする具象のサンプル数が足りていない（つまり横方向への情報不足）ことに起因する。例えば、会社の行動指針を考える場合、成果を出している社員が取っている行動の中から共通項を見出して、これをやれば成功するという事柄を指針として定義するというようなことをやる。この際、対象社員が3人なのと100人なのとでは、共通項の確からしさが変わってくる。対象が多ければ多いほど確度の高い行動指針が定義できる（その過程で表現としての曖昧さが出てくることはあるが、それは必ずしもわかりづらいこととイコールではない）。
一方で曖昧なことの難しさは対象自体の情報量の不足（つまり縦方向への情報不足）から発生する。 マネジメントの対象が自分の思うように動いてくれないというのは、その対象の観察が甘いからで、物事が抽象的であることとは無関係である。まずは曖昧な部分を減らし、確実な部分を増やさなければいけない。そのため、マネジメントの領域では頻繁な 1 on 1 を行い、対象をより深く観察するのが良いプラクティスとして成立している。
つまり、難しさの対象をちゃんと特定して、それに応じた対応をしようという話である。
まとめ
ソフトウェアエンジニアにとって、抽象化とは単なる技術ではなく、問題解決の根幹にある哲学であり、日々の実践そのものである。 それを正しく使いこなすことで、現実世界の複雑さを制御し、新たな価値を生み出すシステム/組織を構築することができる。
開発生産性カンファレンス2024に行って思ったこと
2024年6月28日、29日に虎ノ門ヒルズフォーラムで開催された開発生産性カンファレンス2024に行ってきた。
dev-productivity-con.findy-code.io
3行でまとめると
- 開発生産性を含む DevEx の重要性
- 開発生産性をどのようにビジネスアウトカムに結びつけるか
- 開発生産性を向上させるための組織作り、プラットフォームエンジニアリングと越境性
がとても大事。
開発生産性カンファレンスとは
Findy さん主催の開発生産性に関する大規模カンファレンスイベント。
昨年7月の開催では、“開発生産性とは何か” をテーマに、 その定義や進め方について切り開かれました。
2024年は、事業インパクトにつながる開発生産性の捉え方や進め方、 具体的な生産性向上に向けた施策についてもう一歩踏み出します。
今年のテーマは生産性向上に向けたより具体的な施策についてらしい。
去年の申し込みは600人程度だったのが、今年はなんと2000人の申し込みらしい。流行っているな、開発生産性。
参加者の属性
ちなみに来場者の属性内訳はこんな感じらしい。CxO、役員クラスが15％って結構すごい。
現場の開発者というより、組織の生産性に関心があるリーダー/マネージャー層が割合としては多そう。 セッション登壇者も現場のエンジニアというより、何かしらをマネージングしている人が多い印象だった。
ブース
スポンサーブースが37社ぐらいあってスタンプラリー回るのが楽しかった。 開発生産性の改善に力を入れている企業と、開発生産性を上げるためのプロダクトを作っている企業がたくさんいた。
開発生産性という答えのない領域だからこそ、ブースで色々と各社の話を聞けるのは貴重な機会だった。スポンサーするだけあって流石にどの会社も4keysなどのメトリクスをしっかりと計測して改善を回していたのが印象的だった。
テーマがテーマだけに来場者の幅が広いからか、ブースに行くと「職種はエンジニアですか？」って聞かれがちで、名札にエンジニアって書いておいた方が良かったな。
各ブースのアンケートの回答も実に興味深い。
【 #開発生産性con_findy 利用ツールアンケート結果】
— Findy Tools ファインディ【公式】 (@findy_tools) 2024年7月1日
6/28,29に行われた開発生産性Conferenceでの利用ツールを聞いたアンケートの最終結果です！📝
1500枚以上のシールが集まり、従業員数に応じてシールの色分けがされています
501名以上：赤色🔴
101名以上：青色🔵
11名以上：緑色🟢… pic.twitter.com/ycwb02pQ4n
開発生産性カンファレンス Day2です！カケハシはヘルステックスタートアップということを知っていただきたく、藥袋を模したオリジナルの袋に入れてラムネをお渡ししております。カケハシ箸🥢のプレゼントやアンケートも実施しておりますので是非お立ち寄りください。#開発生産性con_findy pic.twitter.com/N9e9gbgMu4
— カケハシ技術広報 (@kakehashi_dev) 2024年6月29日
ビズリーチブースでのケイパビリティについてのアンケートは、300名以上の方にご回答いただきました🙌
— VISIONAL ENGINEERING / ビジョナル・エンジニアリング (@VISIONAL_ENG) 2024年6月29日
色は2色ですが、回答いただいた方それぞれに背景があり大変興味深かったです。2日間ありがとうございました！
・黄：取り組んでいて効果的だった
・青：これから頑張りたい#開発生産性con_findy pic.twitter.com/t6UKU8zwo3
2日間、ブースにお越しくださりありがとうございました！
— hacomono Developers / hacomono プロダクトチーム公式 (@hacomono_Dev) 2024年6月29日
250名ほどの方に、シールを貼っていただきました。
職種ごとに左右に寄ったり、傾向が出ていて、振り返りをするのが楽しみです！
本当にありがとうございました🙌#hacomono #開発生産性con_findy pic.twitter.com/BYgBjVLYyY
ビットキーさんのブースにも寄らせていただきました☺️
— hacomono Developers / hacomono プロダクトチーム公式 (@hacomono_Dev) 2024年6月28日
開発組織のいろんな悩みが、、、👀#開発生産性con_findy#bitkey#hacomono pic.twitter.com/OjIlQgYkH7
セッションの感想
テスラ、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
マイクロサービスを構築する中でプラットフォームエンジニアリングがどのように振る舞うかを、具体的なチップスも踏まえて話してくれた。
- 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タイムも長く取られており、会場に行って良かったなあと思った（着くの遅くてサテライトの方だったけど）。
- 開発生産性に関するフレームワークにはそれぞれ強み弱みがあるので適切に使う
- 組織の生産性指標から DevEx へのシフト
- DevEx とは
- 開発者体験
- https://tech.findy.co.jp/entry/2024/06/27/090000
- 組織としてのメトリクスではなく、開発者の認知負荷やフリクション、フィードバックループ
- DevEx とは
- テクノロジー面、カルチャー面、コミュニケーション面で打ち手を考える
- 経営陣をどう説得すればいいのか
- 全体のプロセス、安全性
- データよりもストーリーを語る
「実践チームトポロジー：プラットフォーム性とイネーブリング性の戦略」
https://dev-productivity-con.findy-code.io/2024?m=2024/m/BTQjY70w
タイミーがチームトポロジーの考え方をどのように組織に取り入れているか、というお話。赤澤さんのベシャリが相変わらずうまく、眠くなる隙がない。
ケイパビリティの不足とリソースの不足を混同しないという点と、プラットフォームが行き過ぎるとストリームアラインドチームが自己完結しなくなるので、イネイブリングも大事だよね、というのはなるほどだった。 ここでもやはり各チームの越境性が大事というのがポイントだった。
「開発生産性を上げる改善」って儲かるの？に答えられるようにする
https://dev-productivity-con.findy-code.io/2024?m=2024/m/IVK0ezXg
管理者視点だと細かいことは気にしてなくて、良きタイミングで意図したものが出てくればそれでいい。ので本質的には開発生産性なんて意識しないのだけど現実そうはならない。結局見ている情報のレイヤーが違って、誰が何をどう翻訳してコミュニケーションを取るか、というのが整理されていてとても良かった。
- なぜ開発生産性を意識するのか
- 信頼が積み上がれば、開発生産性は気にならなくなる
- 管理者視点では予定通りモノが出てくればあとはどうでもいい
- エンジニアの見積もりを信じて計画を作る
- なのに毎回遅れる、なぜ遅れるのかはわからない
- 開発側からすると遅れた事実は認識しやすいが、なぜ遅れたかは数値化しにくい
- 事業責任者側からすると、狙ったタイミングでモノが出てくるか
- 思い通りにいかないと優先度を細かく決めたくなる
- そうなると内部改善の優先度は上がりづらくなる
- 具体的な説明をする
- リファクタリングしたいという言葉を使わない
- 具体的に何やるかわからない、終わりがない
- テスト書くのかなんなのか具体的にする
- リファクタリングしたいという言葉を使わない
- どのフローの話か、どのプロセスの話か、どのレイヤーの話か、生産性を上げて何がしたいのか
- エンジニアは自分の操作可能なプロセスを見がちだが、全体を見ないといけない
- スループット、コスト、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
久しぶりに twada さんの講演を聞いたけど、テストサイズで戦略的に自動テストを書いていく、というのはなるほどと思った。
- なぜ自動テストを書くか
- 素早く躊躇なく変化し続ける力を得るため
- アイスクリームコーンのアンチパターン
- そもそもユニットテスト、インテグレーションテスト、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 に参加してきた。
2022年の三重、2023年の松本に引き続き3回目の RubyKaigi。行くたびにとんでもなく"アツい"イベントだなあと思うのだけど、今年もまたとんでもない熱量を感じて帰ってきた。
今年も企業からの派遣という名目で、会社に費用を負担してもらい、仕事として沖縄に赴いた。正直な話、最近 Ruby を全然書いていないので自分が行ってもいいのだろうかと内心思っていたが、最近会社としても個人としても技術広報に力を入れ始めていたので、自分としては今回はその文脈で立ち回ろうかなあなんてことをぼんやり思っていた。
会社としての参加レポは会社の技術ブログに書いたので、ここでは個人的な感想をつらつらと残しておこうと思う。
RubyKaigi は地方で開催されるということもあって前乗りする人が結構な数いる。前乗りと言っても前日とかではなく、なんなら土曜日ぐらいから沖縄にいる人が観測され過ぎて、もう RubyKaigi 始まってるんじゃないかと思うぐらいだった。
自分もしっかり前日に前乗りし、普段出張などない身分なので会社のお金で飛行機に乗る感覚を噛み締めていた。那覇に着いたら雨がすごく、「これ明日以降、天気大丈夫なんだろうか」と不安になったが、結果的に Rubyist パワーで会期中は晴れるという奇跡。なお、Kaigi 直後に沖縄は梅雨入りした模様。
今回の宿はホテルではなく Airbnb で一軒家借り上げでの宿泊。現地参加のエンジニア10人がみんなで仲良くひとつ屋根の下。修学旅行感がすごかった。ちなみに1階にリビング、2階が寝室という構成で、夜の飲み会が終わった後リビングでダラダラと話ができるというのが良かった。逆に寝るタイミングを逃し夜をふかしすぎて寝不足になるというデメリットもあった。ちなみに部屋割りは先輩後輩関係なく仁義なきブーサーで決めた。
I'm in okinawa⭐️ pic.twitter.com/kRNjkZur53
— なかりょー / giftee エンジニア (@nakaryo79) 2024年5月14日
RubyKaigi は国際カンファレンスなので世界中からいろんな人が集まる。アフリカの先っぽで Ruby 書いてる人がいるってこと、すごい。
今年はネックストラップの色で、自身の撮影OK・NGを表明できるようになっていて、ネットに写真をアップされたりしたくない人への配慮がなされていた。とても良い仕組みですね。ブログを書く側としても大変助かる仕様だった。毎年運営がアップデートされ続けててすごい。
自社ブース
今年は比較的長い時間スポンサーブースに立ってたくさんの Rubyist とお話をさせてもらった。来訪者から「ギフティさん知ってます〜」という言葉をいただく機会が多く、以前に比べて認知度が体感上がってきたかなあ、と嬉しい限りだった。毎年スポンサーブースを出しているので、Ruby 界隈では徐々に認知が獲得できてきたように思う。
その一方で、こういう反応をされるうちはまだまだダメだなあとも思った。「知ってます」という言葉を使われるということは、つまり世間的にまだ認知度が低い企業だと思われているということの裏返し。例えば、メルカリの人に対してわざわざ「メルカリ知ってます」とは言わない。それは知っていて当然だから。うちはまだ知ってて当然の水準にはいけてないということ。まあこれは極端な例だし、そのような驕りはなかったのである意味当然と言えば当然なんだけど。
あとは闇雲に認知を取りたいわけでもないというか、ギフトというサービスもそうなのだけど、ウチがウチがと前面に押し出すのではなく、意味のある認知というか、適度な"間"的なものがないと、よくないなと。
スポンサーしてブースを出しているということは少なからず認知度向上や採用目的もあるわけなんだけど、RubuKaigi はアカデミックかつギークなイベントだと思うので、企業としてはそのコミュニティへの還元が一番の目的なわけで、その辺とのバランスが難しいなあ。
話は変わるけど、スポンサーの顔ぶれって毎年そこまで大きく変わらないし、わざわざお金出して RubyKaigi に来る人もなんだかんだ毎年同じなんじゃないかと勝手に思っていたので、回数重ねるごとにブース出展の広報効果って薄れてくんじゃとふと思った。
しかし、ANDPAD さんのアンケート結果によると、（ブースを回っていた人のうち）40％の人が初参加だったとのこと。初参加が40％もいるならやる意味が結構あるのかな。
そして、今年もほぼ全ブース回ったけど、どこも趣向が凝らされていて楽しかった。
特にハイドレーションスポンサーの SmartBank さんはインパクト大。ドリンクご馳走様でした。
酒豪伝説にもお世話になりました。これのおかげでハブ酒と戦えた。
酒豪伝説、目の付け所が良すぎて好き#rubykaigi #IVRy pic.twitter.com/Yps4tH1qyu
— なかりょー / giftee エンジニア (@nakaryo79) 2024年5月17日
セッション
ぺんさん による「Writing Weird Code」。オープニングキーノートでいきなり魔法を魅せられてるんですが...。RubyKaigi 2022 の TRICK で金魚を見て感動すら覚えたのだけど、今年は Self TRICK とは。ゆらゆら動くクラゲを見ながら、この技術で殴られる感じが RubyKaigi が始まったなあと。オープニングに何を話すのかって、選ぶ側も話す側もそれなりに悩むと思うんだけど、TRICK は Ruby 自体の凄さというより、Ruby 使ってこんな面白いことができるんだぞという、プログラミングの楽しさを思い出させてくれるという意味ですごいいい入りだったなと個人的には思った。
あと kaneko さんの「The grand strategy of Ruby Parser」。パーサーの話。相変わらずの早口で日本語なのに話についていくのがむずいw 正直パーサーの技術的な話はわからないのだけど、Ruby としてのパーサーの現在地と未来についての話は面白かった。CRuby のパーサジェネレータは従来の Bison から Lrama にリプレイスされた。そして長期的にはユニバーサルパーサーを提供したいと。
Matz のキーノートが良かった話は会社のブログにも書いたので割愛。
夜のお楽しみ
オフィシャルパーティは海辺で BBQ。去年はホテルの大広間だったのにテイスト変わり過ぎw
沖縄のサンセットを見ながら、みんなで肉を焼いて酒を飲むのはエモい。風も強い。
地域 rb の人たちが集まるテーブルにお邪魔させてもらって、roppongi.rb が復活する話などを聞けた。少し前に、SmartBank さんの力で gotanda.rb も復活したし、roppongi と時を同じくして ginza.rb も復活するみたいで、地域コミュニティが盛り上がっているのはすごい良い。
Official party #rubyfriends #rubykaigi pic.twitter.com/qH2NiCIht4
— Toshio Maki (@Kirika_K2) 2024年5月15日
2日目の夜はスポンサー各社が様々なドリンクアップを開催してくれており、路頭に迷うことなく Rubyist どうしワイワイできるのが嬉しい。SmartHR さんのドリンクアップに行かせてもらったのだけど、途中で沖縄民謡ライブが行われたりと、開催地沖縄を存分に感じられる飲み会だった。今年のドリンクアップは RubyKaigi 初参加枠を設けている企業が多くて、すごいいいなあと思った。二次会は自社開催のドリンクアップへ。
3日目の夜は mov さん主催で国際通りのれん街を貸し切ってのアフターパーティ。
この空間全部を Rubyist が埋め尽くしてるの半端ねぇ...。初っ端からいいペースでハブ酒を何杯かあおって気持ちよくスタート。
スナックスペースもあってカオス。
自由に席を立って移動しやすい仕様になっていてよかった。
#rubykaigi #rubyfriends pic.twitter.com/27aLWsm9Te
— Masaki Nagasawa (@nagas4wa) 2024年5月17日
からの RubyMusicMixin。
IVRy の barometrica さんでブチ上がり。
最高に盛り上がったまま力尽きて退散。
三日三晩（前日も合わせると4日間）セッションを聞いて飲んでを繰り返すのは相当な体力がいる。RubyKaigi を全力で楽しみきるには事前の身体作りも重要なのだ。
メシの記憶
RubyKaigi を締めるステーキ。
サーターアンダギーを食べ忘れた気がする。
まとめ
RubyKaigi はやっぱりすごい。Ruby 大好きな人たちが1000人以上も集まって3日間、しかも夜通し盛り上がる。楽しくないわけがない。Ruby のコミュニティ力の高さを実感できる。そして（難しすぎる）セッションや他の Rubyist との交流で色々なモチベーションが高まってしまう。そして技術的な未熟さを痛感させられるという意味でもヤバいイベントである。
あと運営がすごい。これだけの巨大なイベントを大きな問題なく遂行できるのすごい。運営スタッフ、そしてスピーカーたちに感謝。
よもやま
帰りの飛行機でキングダムの最新刊でも読んで返るか〜と思って空港の本屋に行ったら...これが離島クオリティ。最後まで沖縄を感じることができたのであった。
