新米エンジニアが放置PRという小さな種と戦うアプリを開発して見えた、横断的開発で大きな収穫を得るまでのレバレッジ戦略

KomeKaigi2025 で登壇した内容となります。

新米エンジニアが放置PRという小さな種と戦うアプリを開発して見えた、横断的開発で大きな収穫を得るまでのレバレッジ戦略

Transcript

1. 1 新⽶エンジニアが放置PRという ⼩さな種と戦うアプリを開発して⾒えた 横断的開発で⼤きな収穫を得るまでの レバレッジ戦略 はるおつ @haruotsu_hy KomeKaigi2025 2025.11.01
2. 2 ⾃⼰紹介 横⼭ 遥⼄ はるおつ • @haruotsu_hy/@haruotsu • 新卒2年⽬新⽶エンジニア • Go、Rubyをよく触ります。 • 呼吸をするようにドメインを買っています。 • 初のカンファレンス登壇となります！緊張！よろしくお願いします！
3. 新⽶エンジニア 3 新⽶エンジニア
4. 新⽶としてこうなりたい 4 • ⾃分のチームを超えて、組織全体の困りごとをシュッと 解決してくれる⼈がいる。かっこいい。 • 会社の困りごとを解決しながら、それがOSSとして会社を 超えて、⻑期的に使われるものを作っている。 • これになりてぇ...！ 新⽶としてこうなりたい
5. 新⽶としてこうなりたい 5 会社の中でみんなに知られる バーン！とやりたい
6. アプリやOSSとして、よく使われているものはどんなものだろうか？ 6 アプリやOSSとして、よく使われている ものはどんなものだろうか？
8. 私が思う、広く使われるツールの共通点 8 • レバレッジが効いていること ◦ ⼀度の開発で、多くの⼈‧組織に価値を提供する ◦ 他にないアイディアで、⻑期間使われる ◦ 個別の問題ではなく、構造的な問題を解決する • 横断的な価値を持っている ◦ 特定のチーム‧組織に限定されない ◦ 技術領域または職種を超えて使うことができる ◦ 様々なユースケースに対応している 私が思う、広く使われるツールの共通点
9. 実際どうか 9 実際どうか Kubernetes、Terraformの例 • レバレッジ ◦ コンテナのデプロイ、スケーリング、管理を自動化 ◦ インフラをコードで記述し、一度書けば複数環境で同じ構成を展開できる ◦ 宣言的な設定で、あるべき状態を定義するだけで運用可能 ◦ 手動オペレーションを大幅に削減しながら、大規模運用を実現 • 横断的 ◦ クラウドプロバイダー、オンプレ、ハイブリット環境で利用可能 ◦ 言語やフレームワークに依存しない ◦ 開発、ステージング、本番など、複数環境を統一的に管理できる ◦ インフラエンジニア、 SRE、Webエンジニアなど職種を超えて利用可能
10. ⼀⽅でこんなことはありませんか? 10 実際どうか Slack、Notionの例 • レバレッジ ◦ 一度の投稿で数百人に同時に情報伝達可能 ◦ 継続的にナレッジが蓄積される ◦ 一度作成したテンプレートを組織全体で再利用可能 ◦ リンクで情報を相互接続し、構造的な知識体系を構築 • 横断的 ◦ エンジニア、営業、マーケティング、人事など全職種で利用 ◦ テキスト、音声、ビデオなど多様なコミュニケーション形式 ◦ 個人のメモから部署の戦略文書まで幅広く対応 ◦ タスク管理、議事録、仕様書など様々なユースケースに適用
11. ⼀⽅でこんなことはありませんか? 11 • レバレッジが効いていること ◦ ⼀度の開発で、多くの⼈‧組織に価値を提供する ◦ 他にないアイディアで、⻑期間使われる ◦ 個別の問題ではなく、構造的な問題を解決する • 横断的な価値を持っている ◦ 特定のチーム‧組織に限定されない ◦ 技術領域または職種を超えて使うことができる ◦ 様々なユースケースに対応している レバレッジ戦略と横断的開発を ⽶作のOSSをベースにして、新 ⽶としてやってみた
12. ⼀⽅でこんなことはありませんか? レバレッジと横断性を 掛け合わせながら バーンとやってみる 12
13. ⼀⽅でこんなことはありませんか? 13 ⽇常の課題、トイルはなんだろう？
14. ⽇々開発⽣産性は上がっていく 14 ⽇々開発⽣産性は上がっていく！ https://claude.ai/ https://developers.openai.com/codex/cli https://www.cursor.com/ https://github.com/features/copilot
15. ⼀⽅でこんなことはありませんか? 15 • このPR誰かレビューしてください！ • だれも引き受けてくれない‧‧‧！？ • (2時間後...) 〇〇さん可能であれば‧‧‧！ • 修正 → レビューのサイクルが遅くて全然merge できない‧‧‧ • 私ばかりレビューしているな‧‧‧ ⼀⽅で‧‧‧
16. 実際 16 実際 コードを書く テストする レビューする 開発生産性が上がりめっちゃ早くなった 大AI時代、超高速な仮説検証 を行う上で、 レビューがボトルネック になっていた。 遅い！ 超少人数のチームや、距離感の近いチームの方が、 PR作成から デプロイまでのリードタイムが早かった (Forkeys) どうにかするぞ・・・！
17. レバレッジ、横断性を意識する 17 レバレッジ、横断性を意識する 「表面的な問題 → 構造的な問題」に落とし込む 表面的な問題 構造的な問題 レビュワーが決まらない レビュワーの属人化、 誰かが拾うという心理状態 PRが放置されて、声かけをする リマイド機能の不在 チームごとに運用が違う 設定が難しい Actionsでエンジニアが書く必要がある 柔軟性がかけている あとでPR依頼すればいいや 相手をメンションする心理的不安 営業時間 将来のレバレッジ、横断性を視野に入れた自動化と構造化で解決する
18. slack-review-notify 18 • GitHubにラベルが付くと通知 • レビュワーのランダムアサイン • スレッドで定期リマインド • レビュワー変更 • レビュー後⾃動通知 • 定期リマインド • 営業時間考慮 • スラッシュコマンドでの設定変更 slack-review-notify https://github.com/haruotsu/slack-review-notify
19. 局所最適をしてしまったフェーズ1 局所最適をしてしまったフェーズ1 19 • エンジニアはhoge-devチャンネル、 デザイナーはhoge-designチャンネルに いる想定 • ラベルはneeds-reviewで固定 • タスクごとにチャンネルを分けている想定 ランダムアサイン、定期リマインド、豊富なスラッシュコマンド → チームメンバーから好評！レビュー速度も明らかに早くなった！ しかし...
20. DB設計 20 • 「うちのチームでも使いたい！」 • 「同じチャンネルで別の人メンションしたい！」 • 「needs-review以外も使いたい！」 • 「営業時間外にもひたすらリマインドされて 押すのが申し訳ない...」 局所最適だった設計が、横断的ニーズに答えることができない ...！
21. DB設計 制約と影響から構造的な問題への転換 21 制約 影響 1チャンネル1設定 複数用途に対応できない ラベル名が固定 チームごとの運用に合わせられない 営業時間がない、固定のタイムゾーン 心理的不安の増加&レビュー漏れの増幅 日本でしか使えない レビュー完了後にもボタン or声かけが必要 作業の中断、時間のロス 個々のチームの問題を、使う人全体の構造的な問題に昇華させて考える → 見えてくるレバレッジ・横断可能性
22. DB設計 横断的価値への転換 22 • ラベルごとに複数設定を持てる ようにする • チャンネルとラベルで一意性担保 • ラベルも過度な正規化を避ける データモデルの再設計 スケーラビリティの第一歩
23. 営業時間対応 営業時間対応 23 レビューしていないと、お尻が叩かれる → ありがたいけど、業務時間外はうるさい → 見れる時に見て速デプロイ、もちろんタイムゾーンの変更も可能に ユーザ体験の最適化 、入れるだけで付加価値を与えるレバレッジ力、利用者横断の意識
24. 実装⾯ 実装⾯でレバレッジと横断性のある実装 24 • 再利用可能な共通コンポーネント ◦ 単一責任の原則に基づいた設計 ◦ インタフェースに依存 • 汎用的な設計パターン ◦ レイヤードアーキテクチャ ◦ 共通の処理フローを定義し、詳細は各実装に委譲 • 保守・運用が楽なコード ◦ 変更の影響が明示的・最小的 ◦ 新規コントリビュータの参入障壁を下げる
25. 営業時間対応 ⾃⾝の実装においてもレバレッジと横断性を意識 25 Slackボタンってどう書くの？ → 呼びたいポイント各所で気合いのjsonを書く • 再利用可能な共通コンポーネント🙅 • 汎用的な設計パターン🙅 • 保守・運用が楽なコード🙅 • バグの温床 • 読みづらい • 変更が多岐に渡る • 書き方わからんから参入できない ...
26. 再利⽤ 再利⽤可能なものは共通化する！ 26 レシーバで自身を返すことで、メソッドチェーン化 • 再利用可能な共通コンポーネント • 複雑なオブジェクト生成を段階表現 • 型安全 • 影響範囲が最小 • 誰でも組める。すぐに作れる
27. どうなったか 27
28. 改善 改善 28 軸 初期 (4月) 中期 (6月) 現在 (10月) 実装軸 局所最適 レバレッジ横断展開 改善サイクル 組織軸 2リポジトリ 58リポジトリ 全社+OSS 技術軸 MVP実装 スケーラブル設計 拡張可能なアーキテクチャ 小さな発見 → 大きなリターン 時期 平均対応時間 中央値 導入前 10時間54分 9時間22分 導入後 1時間51分 25分 • レビューせずに1日放置することがなくなった • だれがレビューするかに迷いが生じない レバレッジと横断力の強さを実感
29. まとめと振り返り 29
30. まとめと振り返り 実装を通して⾒えたレバレッジ‧横断的価値 30 • 一度の投資で複数の領域・境界を超えてに効果が波及する開発 ◦ 単一チーム → 事業部 → 全社 → 社外 (OSS)へと展開可能 ◦ 継続的な開発効率を向上させる開発 • 個別の問題解決ではなく、構造的・システム的な解決 ◦ ボトルネックの解消・トイルを削減する開発 • 属人化を減らし、再現可能にする開発 ◦ 適切な共通コンポーネント、設計パターン ◦ 継続的な開発効率を加速させる実装
31. レビューサイクルの改善 新⽶だからこそできたこと、やれたこと 31 • 当たり前を疑う力 ◦ ベテランには「そういうもの」とされていたものに疑える ◦ 新鮮な視点での問題発見能力 (小さな種を見つける力 ) ◦ 日常に蔓延する小さな違和感を大切にする • 小さく始められる ◦ 大体、やっていき、にのっていきしてもらえる ◦ MVP思考で価値を検証 できる • レバレッジ・横断的視点 ◦ 個別最適に留まらず、チーム・組織全体に波及する取り組みがしやすい
32. ⼀⽅でこんなことはありませんか? 32 レバレッジと横断⼒で ⼩さな種から⼤きな収穫へ！
33. 33 Thank you! スター⭐、コントリビュートお待ちしています。 KomeKaigi2025に感謝！ ぜひAsk The Speakerや懇親会でお話ししましょう！