開発組織まわりで最近考えているあれこれ

Transcript

1. 開発組織まわりで最近考え 開発組織まわりで最近考え ているあれこれ ているあれこれ 2025/06/01 @vividmuimui 1
2. このスライドはなにか このスライドはなにか 社内LT 発表用のものです 「こんなエンジニア組織にしたい」 「こんなことを考えている」とい うテーマで書いたものです 網羅性や粒度はおいて、LT らしくザーッと書き出したものです AI に関する話はないです 2
3. 目指すエンジニア組織 目指すエンジニア組織 『プロダクトの成長をリードする開発組織』 ・ エンジニアとして、ただコードを書くのではなく、プロダクトの成長を技 術で引っ張っていく ・ そのために、ユーザーの課題に向き合い、スピードと品質のバランスを取 りながら、拡張性のある設計を追求する ・ 短期的な開発効率だけでなく、内部品質の向上や、持続的な成長を見据え たものづくりを大切にする ・ 変化を楽しみ、プロダクトをもっとよくするために主体的に動く 3
4. チーム編成 チーム編成 専門性で分離することは基本想定していない たとえば、 「フロントエンド」 「バックエンド」 「インフラ」 チームとしても、専任としてもわけない 1 つの機能を作るときに一人のエンジニアが基本は全部作る もちろん得意不得意はあって良い 4
5. 技術選定/ アーキテクチャの戦略 技術選定/ アーキテクチャの戦略 組織/ プロダクトにおいて必要 > メンテできるか > 使いたい 「〇〇言語流行ってるからやりましょう」 「イケてる組織はマ イクロサービスだからウチもマイクロサービスにしましょう」 みたいな選択をすることはない メンテできるかはとても重要 導入することもコストかかるが、それを運用していく のが最もコストが掛かる。 逆に、導入コストや撤廃のコスト・影響範囲が小さい のであればガシガシ試したら良い 生産性や保守性・採用力などに寄与するか チームの技術力や人数・組織構造などにマッチするか レガシーなものを使い続けることもない。必要に応じてちゃんとモ ダンに合わせていく 5
6. モノリス／モジュラーモノリス／マ モノリス／モジュラーモノリス／マ イクロサービス イクロサービス コンウェイの法則・逆コンウェイの法則 1,2 チームで分割する程度の規模であれば、モノリス・モジュラモノ リスで十分 事業ニーズ・人の拡大がなければマイクロサービスにすることはない 一番避けたいのは、負債化するマイクロサービス マイクロサービス風の分散システム 組織構造が設計されていないマイクロサービス 6
7. viva ベンダーロックイン viva ベンダーロックイン 人が少ない中でそこまで気にしてられない。将来考える サーバーレスに寄せれるならそのほうが良いと思っている Observability とかもモノリス前提なのであまり気にしない クラウドやDatadog でよしなにやってくれる部分も多いの で、まずは最低限それに乗っかる程度 ※ ここはプロダクト・チームの現況に合わせた判断が強いです 7
8. 監視系 監視系 インフラ監視はDatadog エラー監視はSentry/Rollbar オンコールとかは今はそこまでの規模ではないので考えない 基本みんな対応すべき 「自分が書いたコードじゃないのでわからないで、自分は対 応しません」はNG ※ ここはプロダクト・チームの現況に合わせた判断が強いです 8
9. データ分析/ 解約/ ログ データ分析/ 解約/ ログ これはちゃんと設計する必要がある 失ったデータは戻せないので。 顧客情報・個人情報は解約でちゃんと消さないといけない でも、データ分析として必要な情報は残しておく必要がある DWH はBigQuery にしたい。Google Spreadsheet/Looker とも連携で きるので。 9
10. BI ツール BI ツール redash/metabase と、looker/aws quicksight などを用途によって使 い分けれると良い気がしている エンジニアが調査する用、KPI 確認のダッシュボード用など もっと言えば、リアルタイムのデータを見たいものと、過去の分も含 めて長期間みたいもの・いろんなデータ突合させてみたいもの 10
11. テスト テスト 基本はテスティングピラミッドに。シンプルなモノリスシステムなの で。 ただ、今はE2E/VRT を充実させる。 自動テストがない＆フロントエンドのライブラリやCSS もガ ッツリリファクタリングしたいという状態なので。 将来的にもVRT はあったほうが良いと思っている Vibe Coding にも役立つはず 11
12. テストの書き方 テストの書き方 世の中に良い資料あるので読んで。本もたくさん出てる。 Rails Developers Meetup 2019で、再び綺麗なテストコード の書き方について発表した リーダブルテストコード / #vstat テストコードにはテストの意図を込めよう(2025年版) #retechtalk https://blog.willnet.in/entry/2019/03/27/092642 https://speakerdeck.com/jnchito/number-vstat https://speakerdeck.com/nihonbuson/put-the- intent-of-the-test-2025 12
13. テストの書き方2 テストの書き方2 書くよりも読む時間のほうが長いので、基本DRY にしない でも、そのテストファイル内でメソッドを作るのは普通にや ったら良いので積極的にやるべき そのテストで必要な条件やパラメータは、そのテスト内で明 示的に過不足なく書くのが大事 ある1 つのテストを変更するために修正したときに、 他のテストに影響がないように。 外部サービス以外は基本モックしない。DB もちゃんとローカルに用 意する Googleのソフトウェアエンジニアリング 「分離より現実に即することを優先せよ」 「我々が現実的なテストを優先するのは、テスト対象 システムが正常に動作しているという点での信頼をよ り多くもたらすのが、現実的なテストだからである。 」 https://www.oreilly.co.jp/books/9784873119656/ 13
14. コードレビュー コードレビュー 伝わるコードレビュー という本とてもおすすめ Google's Engineering Practices documentation もおすすめ https://www.shoeisha.co.jp/book/detail/9784798186009 https://google.github.io/eng-practices/ 14
15. コミットの粒度/ メッセージ/PR タイ コミットの粒度/ メッセージ/PR タイ トル トル 10年後、プログラムを動かし続けるために。伊藤淳一が考える「良 いコミット、悪いコミット」 よいコミットメッセージ・よくないコミットメッセージ Gitのコミットメッセージの書き方 https://levtech.jp/media/article/column/detail_586/ https://tech-blog.yayoi-kk.co.jp/entry/2017/03/13/132014 https://postd.cc/how-to-write-a-git-commit-message/ 15
16. ライブラリ更新 ライブラリ更新 常に更新する。毎週の頻度で当番制でやる 小さくマージしてったほうが確認が楽 Dependabot やRenovate を使う 16
17. ドキュメント ドキュメント 書かないもの 詳細設計書・DB 定義書・テスト仕様書など、コードと重複す るもの 最新性が保てないもの 書くもの 意思決定の履歴。ADR など 非エンジニアとも共有すべき要件や業務フロー システム全体像や構成（概要図・構成図） 原則 コードが正 必要があればコードから自動生成する ドキュメントを書くこと自体が目的にならないようにする 17
18. 文化 文化 朝会よりも夕会が良い。人が増えたら両方 朝会だと「昨日の続きで〇〇やります。 」で終わってしまうこ とが多い。もしくは、10 分以上の朝会をやりがちになる 夕会であれば「今日〇〇やったけどうまくいかなかった」と いう課題が出てくるので、翌日に回さず問題を発見解決しや すい 振り返りを定期的にやろう 「チームをより良くするためには・生産性を上げるには」と いうような目的はちゃんとはっきりさせてやろう 月1 改善Day 普段だとどうしても後回しになりがちな、でも時間があった らやりたいやつを自由にやる。開発環境改善・生産性向上・ DX 向上につながる作業を集中してやる日 PR 共有回 チームの知識の共有 18
19. そのた色々 そのた色々 ボーイスカウトは当然やろう 12FactorApp とかDevOps のfour keys とかの文脈のは取り入れていこ う。基礎として大事なプラクティスが多い 何事にもわかりやすい正解というのはないので、意志と意図を持っ て判断する リリース後のことをちゃんと考えよう。とくに設計・レビューのタ イミング。抜けがちなので。 監査 問い合わせ調査 KPI のための集計・データ分析 19
20. そのた色々2 そのた色々2 DB ・URL の設計は最初に共有・レビューしよう 機械ができることは機械にやってもらう CI/CD 当然やろう CI 例 自動テスト以外にも色々やろう linter/formatter, 脆弱性解析, typo, detect secret な ど reviewdog, danger AI レビュー 20
21. 好きな資料/ 本 好きな資料/ 本 とても好きな資料: 20140131 万葉帰社日発表 チーム積み重ね 好きな本: Team Geek 好きな本: 仕事は楽しいかね？ https://www.slideshare.net/tatsuosakurai/20140131- accumulation-ofteam https://www.oreilly.co.jp/books/9784873116303/ https://eijipress.co.jp/products/2351 21
22. さいごに さいごに あくまで2025/06 時点での考えてることの一部です 網羅はしていないし、考えが変わることもあります 状況やチームによって柔軟に変えるものだとも思っています 22
23. 再掲: 目指すエンジニア組織 再掲: 目指すエンジニア組織 『プロダクトの成長をリードする開発組織』 ・ エンジニアとして、ただコードを書くのではなく、プロダクトの成長を技 術で引っ張っていく ・ そのために、ユーザーの課題に向き合い、スピードと品質のバランスを取 りながら、拡張性のある設計を追求する ・ 短期的な開発効率だけでなく、内部品質の向上や、持続的な成長を見据え たものづくりを大切にする ・ 変化を楽しみ、プロダクトをもっとよくするために主体的に動く 23