学習しながらアーキテクチャを進化させていくためのモノレポ

Transcript

1. 学習しながらアーキテクチャを進化させ
   ていくためのモノレポ
   Hirotaka Miyagi / MH4GF
   2023/10/06 モノレポへの移行 LT- 生産性の高いアーキテクチャに向
   けた第一歩
   1
   

   View Slide

2. Hirotaka Miyagi / @MH4GF
   最近はフロントエンド多め
   ROUTE06, inc.
   フルリモートワークの会社で北海道から沖縄までメン
   バーが活動しています！
   自己紹介
   2
   

   View Slide

3. フロントエンドをポリレポからモノレポに移行した話
   立ち上げ期のプロダクトでリポジトリを分けるか迷った場合、まずモノレポを選択して適切
   な境界を模索する手もある
   学習やチームのスケールの過程、モノレポの限界により将来的にポリレポに戻すことも考え
   られる
   TL;DR
   3
   

   View Slide

4. エンタープライズ向けのマルチテナント型SaaS
   現在開発中のプロダクトは商取引におけるクラウド EDI のドメインにフォーカス
   フルスクラッチとSaaSの中間のテーラーメイドの領域を狙い、カスタマイズ性が強み
   Plain
   4
   

   View Slide

5. 複数のテナント(お客様固有の環境)がPlain上に構築され、お客様のニーズに合わせカスタマ
   イズされたプロダクトを提供する
   UIデザイン・機能の利用可否・入力するフィールド・外部データ連携など
   実現方法には開発者がフルスクラッチで書く⇔お客様が画面上でカスタマイズを自由に選択
   できる まで粒度があり、それぞれトレードオフがある
   さらにEDIというドメインの難易度の高さ
   Plainのカスタマイズ性
   5
   

   View Slide

6. 「カスタマイズ」という言葉に内包される幅広さがあり、要件の定義や設計が難しい
   まず数社導入・開発が決まったため、そのお客様向けの開発を進めながら解像度を高めてい
   きたい
   Plainのカスタマイズ性
   6
   

   View Slide

7. 現在はフロントエンド・バックエンドのような技術領域でチームを切っている
   フロントエンドにはFeatureチームとPlatformチームの2チーム
   Plainと関わるチーム
   7
   

   View Slide

8. 戦略
   Featureチーム ... テナントのリポジトリで業務要件を達成するアプリケーションを実装
   Platformチーム
   基盤のリポジトリでテナントに関わらずPlainを利用する上で必要になる基盤とな
   るコードをnpm private packageで提供
   サービステンプレートとしてテナント立ち上げに必要なコード群が生成できるよ
   うなツールを提供: npx @route06/create_next_app
   今優先して取り組むこと
   初期テナントへの提供の完遂を優先し、ドメインの理解と実装を進める
   テナントの分離がコードレベルで確実に行われている
   複数テナントの運用を見据え、リポジトリ間のパッケージ共有をチームが学習する
   1. テナントと基盤のコードでリポジトリを分離する
   8
   

   View Slide

9. 起きた課題
   直近の開発における調整の多さ ... ドメインの機能を実装するために基盤の実装も必要
   で、結果的に2つのリポジトリを変更しなければいけなくなる
   npm private packageによる分離は立ち上げフェーズの今本当に適切なのか？
   組織のスケーラビリティ ... この構成では各テナントに対して保守する開発チームが必
   要になり、テナントを増加させるためにはチームのスケールが必要になる
   1. テナントと基盤のコードでリポジトリを分離する
   9
   

   View Slide

10. 起きた課題の振り返り
    今の0→1のフェーズで考えるべきは境界の探索容易性なのかも？
    1. テナントと基盤のコードでリポジトリを分離する
    10
    

    View Slide

11. パッケージマネージャが提供するWorkspace機能を利用することで、package.jsonを一つ
    のモジュール単位としてパッケージ分割が可能
    npm, yarn, pnpm, bunなど主要なパッケージマネージャで提供
    Plainでは元々利用していたものの、これをより活用すれば前述の問題は解消できるのでは
    と考えた
    JavaScriptにおけるモノレポの実現
    11
    

    View Slide

12. 戦略
    pnpm workspaceを利用し、各機能をパッケージという単位でモジュール分割する
    Featureチーム ... 統合したリポジトリで業務要件を達成するアプリケーションを実装
    Platformチーム ... 統合したリポジトリでドメインに依存しない基盤機能・非機能要件
    を実装
    今優先して取り組むこと
    初期テナントの完遂を優先し、ドメインの学習やモデリング・実装を進める
    逆コンウェイ戦略での境界の探索
    一度優先度を下げたこと
    リポジトリ間のパッケージ共有の学習
    2. モノレポへの統合
    12
    

    View Slide

13. リポジトリを分けnpm private packageとして利用する形と比べ1つのリポジトリで開発が
    可能なため、開発スピードの向上に繋がった
    とはいえパッケージ単位でのモジュール分割はしているため、ゆるく依存関係の定義ができ
    ている
    複数テナントの同居によって考慮しなければならない課題がわかったときや、事業としての
    大きな転換があった際にも、パッケージとして分離しておくことで大多数のコードを変更す
    ることなく利用できる
    例としてNext.jsからViteによるSPAに切り替えた際も、認証パッケージとルーティング
    だけ再実装したのみで、他の機能は変更せずに済んだ
    将来的にパッケージを別リポジトリに分離することも可能
    pnpm workspaceを利用したモジュール分割
    13
    

    View Slide

14. CODEOWNERSを利用して各パッケージごとにチームをアサイン・オーナーを明示するこ
    とで、PRで自動的にオーナーにレビュー依頼が設定される
    これにより、一つのPRで複数のチームにレビューが設定される状況は境界の定義が適切で
    ない黄色信号と捉えることができ、境界の調整を促す
    実装を進めながらリファクタリングの過程でパッケージの統廃合を進めている
    今後チームのスケールによって分割したり、新たな機能が実装されるとしても境界の調整が
    しやすい状態は強みとなる
    逆コンウェイ戦略での境界の探索容易性
    14
    

    View Slide

15. 複数テナントの情報が 1 つのリポジトリに同居するため、issue や PR などの管理が煩雑に
    なる可能性がある
    pnpm workspaceの学習コストは高いと感じており、新規参加メンバーのオンボーディング
    の改善は必要
    モノレポそのものの複雑さ(各種開発ツールでモノレポの設定が必要になる・Branch
    Protectionの設定がしづらい等)
    → 今後の学習次第でポリレポに戻す可能性はあるが、現在は境界の探索容易性を重視している
    残る課題
    15
    

    View Slide

16. pnpm workspace実践ノウハウ - Speaker Deck
    pnpm workspaceの運用中に起きた課題とその解決策をまとめたスライドです
    Plainのフロントエンドにおける技術選定(2023年8月版) - ROUTE06 Tech Blog
    モノレポを中心としたその他の技術選定全体についてまとめています
    全社ワークスペースにGitHubを選んだROUTE06の開発生産性 - Findy Engineer Lab - ファ
    インディエンジニアラボ
    ROUTE06では、開発業務以外のメンバーも含め全員がGitHubを利用しています
    Related Links
    16
    

    View Slide