monorepo.pdf

Transcript

1. モノレポの真価は AIの情報アクセスコストにある suzuito / 株式会社カウシェ
2. ⾃⼰紹介 • 株式会社カウシェ • バックエンドエンジニア • カウシェファーム (農園ゲーム) の機能開発‧保守運⽤を担当 • エンジニア歴15年 • 2026/01にカウシェへ⼊社
3. 今⽇話すこと • カウシェのモノレポ (歴史と現状) • モノレポのメリット • モノレポのデメリット • まとめ ⼀⾔で... AIが普及した今、「全部1つのレポにある」ことの価値が⼀気に上がった！
4. カウシェのモノレポ (歴史と現状)
5. カウシェの モノレポ 2023年代 レポジトリ⼀覧 • kauche-app(BE) • kauche-mobile(iOS) • kauche-android(Android) • kauche-terraform(Infra) • kauche-ope-frontend(Web/社内向け管理画⾯) • kauche-partner-frontend(Web/出品者向け管理画⾯) • kauche-farm-frontend(Web/カウシェファーム) • その他 昔はマルチレポだった！
6. カウシェの モノレポ モノレポ移⾏プロジェクト • (2025/04)最初、iOSレポとAndroidレポを統合することから始まる ◦ 当時AI⽂脈はなく、ネイティブアプリエンジニアがiOSとAndroidを両⽅触れるようにするため だった。 • 💡AIとの相性が良いことに気づく ◦ AIへ⼊⼒する情報量が⼤きいほど、より多くの⽂脈を踏まえた実装を出⼒する • 現在の組織規模なら、モノレポの旨味も享受できるはず‧‧‧ • (2025/07)全部をモノレポに統合するPrjが始まる
7. カウシェの モノレポ 現在 レポジトリ⼀覧 • kauche-app(iOS,Android,BE,Infra,Web) • kauche-deployment(Cloud Run YAMLの保存場所) ◦ ※もうすぐkauche-appへ統合予定 モノレポになりました！
8. カウシェの モノレポ 現在
9. モノレポのメリット 〜モノレポが功を奏した事例〜
10. メリット 事例紹介① 不具合の原因調査 「⽔くみ」機能の不具合 Farm は WebView(React) / Native (Swift / Kotlin) / API(Go) から成る Farmチーム 配属2週⽬。NativeApp知識不⾜。午後から全社 会(仕事できない) → Claude Code へ 雑に原因調査を依頼 原因: Android側のとある変更の副作⽤で、WebViewリロー ドのタイミング が変わったこと
11. メリット 事例紹介① なぜ原因特定できた？ • カウシェの全履歴が Git に１本化されている ◦ フェーズ(設計/実装/保守) x レイヤー(BE/FE/Infra/NativeApp) x リリース が全部 Git に紐づく ◦ → AIがこの履歴を 頑張って追ってくれる (Gitの履歴を追うための SubAgent による) • 症状に「プラットフォーム」のヒント(Androidだけで起きている) ◦ →モノレポなので、Androidのコードに0ステップで到達(clone / 権限不要) • AIが⼈間の知識ギャップを埋めた ◦ → Swift / Kotlin 読めなくても、AI が 代読 してくれる
12. メリット 事例紹介② ⼊出⼒が１レポで完結すると開発体験が良い • カウシェの開発フロー(3ステップ) ◦ Design Docの作成 ← AIと⼀緒に + AIレビュー + ⼈間レビュー ◦ 実装計画の作成 ← AIと⼀緒に + AIレビュー + ⼈間レビュー ◦ 実装 ← AIがやる + AIレビュー • 各ステップとも Claude Code に進めてもらう ◦ 草案作成 → 壁打ち → コミット/プッシュ/PR作成/レビュー対応 補⾜: Farmチームでは１機能を１⼈が FE + BE 両⽅担当
13. メリット 事例紹介② なぜ開発体験が良いのか？ • ステップ(1)の⼊⼒以外、全部レポ経由 • 全情報が１レポにあるので、Claude Codeが勝⼿に情報を集めて⾃⾛ • 結果 ◦ 端末を開いて Claude Code と会話するだけで進む ◦ レポ外へのアクセス不要 → 速い ◦ → 開発体験がすごく良い ステップ 入力(どこから？) 出力(どこへ？) (1) DesignDoc作成 PRD / お客様問合せ / 過去の Design 等 (レポ外) Design Doc → レポ (2) 実装計画作成 Design Doc (レポ) 実装計画 → レポ (3) 実装 Design Doc + 実装計画 (レポ) ソースコード → レポ
14. メリット 事例①と②を振り返る • 共通点 ◦ 全レイヤー / 全履歴が１レポにある ◦ → 情報のアクセスコストがゼロ ◦ → 💡新参者でも知らない領域でも素早く動ける 事例① 事例② 主役メリット 履歴の集約 (時間軸) 情報の同居 (空間軸) 何が効いた 「昨日 / Android だけ」のヒントを 全レイヤーの履歴に当てて１発抽 出 入出力が全部レポ経由 → Claude Codeが情報を集めて自走 副次的な効用 知らない領域をAIが代読 会話だけで開発が進む
15. モノレポのデメリット 〜どんな⼯夫をしているか〜
16. デメリット 正直⾔ってあまりデメリットを感じてないが‧‧‧ • ⼊社５ヶ⽉だからかもしれない‧‧‧あるいは • 多分、２つの理由から ◦ (A) 先⼈たちの努⼒ で、デメリットが解消されている。 ◦ (B) カウシェがまだ⼩さい ため、デメリットが顕在化していない。 ここから先は仮説。 「先⼈がどんな努⼒をしたか」「規模はどの程度か」 を考えることを、デメリットを考えることのヒントとしたい
17. デメリット解消 (A) 先⼈たちの努⼒ - 構造の把握 モノレポは階層‧ファイルが増え、レポの構造が分かりにくく、全体を把握しにく くなりがち 先⼈たちの対策が、構造‧全体感の把握を助けている。 • CLAUDE.md で地図化 - 21ファイル (どこに何があるか / 規約) • docs/ を書く⽂化 - 全800以上のファイル (頻繁に更新) • API 仕様ファーストな開発 - protoに記述 (仕様=コードなので腐らない) これらは AI が情報へアクセスする上でも効く
18. デメリット解消 (A) 先⼈たちの努⼒ - CI管理 複雑になりがちなCIへの対策: • 差分ビルド設定 - 172ワークフロー ◦ paths フィルターで変更したサービスの CI だけ起動 • マージの承認ルール - 複数の仕組みを組み合わせている ◦ upsidr/merge-gatekeeper ◦ PRに設定できる「承認⼈数」 ◦ Claude Code を⽤いた⾃動レビュー 〜 ⾃動承認
19. デメリットに 未遭遇なだけ？ (B) カウシェはまだ規模が⼩さい 規模が⼩さいとは: • レポは930MB • Farmのソースコードを触ったのは直近１週間で20⼈以下 • エンジニア数50⼈以下 • 「カウシェ」という１つのアプリを提供するためのソースコードだけ
20. まとめ メリット側: • 全レイヤー (Web/BE/Mobile/API/Infra)も、全履歴も、１レポに集約 • → AI の 情報アクセスコストがゼロ • → Claude Code が 勝⼿にレポから情報を集めて⾃⾛ • → 新参者でも、知らない領域でも 素早く動ける • → 開発者体験がすごく良い デメリット側: • (A) 先⼈たちの努⼒ - CLAUDE.md地図 / docs⽂化 / API仕様ファースト / pathsフィルター • (B) まだ規模が⼩さい - モノレポのコストはまだ顕在化していない