※この記事はClaudeの活用や技術の変化を否定するものではありません。また個人の感想であり、他の人物団体とは一切関係ありません。
イントロ
Webシステムの開発プロジェクトで開発をしていると、技術担当チームが「開発資産をmonorepo構成で管理します」と言い始めた。
monorepo構成とは、それまでbackの開発資産で1つのリポジトリ、front資産で1つのリポジトリ、テスト用資産で1リポジトリ・・・と複数のリポジトリ（ポリリポジトリ）で管理していた開発資産を、すべて含んだ1つのリポジトリ（モノリポジトリ）で管理するリポジトリ構成のことらしい。
開発環境を新規構築するとき、開発者はそれぞれのリポジトリを適当に用意したディレクトリに個別にクローンしていた。それを1つのリポジトリに纏めることで「このプロジェクトに必要な資材はすべてここにあるよ」状態となり、環境構築手順が簡略化される。
また、このプロジェクトではClaudeCodeを開発補助として導入していたが、これまでは別途共有されたClaude.mdやSkillsをそのディレクトリ内に配置していたところを、monorepo構成にしたリポジトリの最上位に置くことで、すべての開発者が最新のSkills等を共有できる。そしてClaudeCodeがそのシステム全体の資産を俯瞰して見ることができるため、ClaudeCodeと非常に相性が良い。
移行作業自体は技術担当チームが主導して殆どしてくれたこともあり、スムーズに行われた。しかし、これにより開発チームに混乱が生じた。この経験を通じて得られた知見を共有したい。
前提
プロジェクト概要
- アジャイル開発
- 開発者は約20名（そこそこ多いと思っている）
- 山場は越えたものの開発は継続中
開発体制
このプロジェクトで開発者は主に以下4つのリポジトリを扱っていた。
- 設計書
- front
- back
- e2e（playwright）
そして、次のような体制で開発を行っていた。
- 開発する機能毎（例：○○登録機能）にチケットを作成し、front担当、back担当がアサインされる。
- 設計を行ったあと、front担当、back担当はそれぞれマージリクエストを作成し、単体テストまでを完了させる。またe2eのシナリオも作成する。
- それぞれ単体テストが完了したら、開発者はfront、backの開発ブランチをチェックアウトし、e2eをローカル環境で実施する。
- 問題なければテスト環境にその開発ブランチでデプロイを行い、最終チェックの後にreleaseブランチへマージされる。
混乱
back / front の開発分担が難しい
1機能1ブランチで開発を進めるという方針はmonorepoになっても変わらないが、そのため複数人で1機能を開発するというときback担当、front担当と別れて開発することが難しい。
それぞれback用、front用とブランチを分けて開発を進めると、両方が単体までテスト完了したあとに合わせて疎通確認することができなくなり、またreleaseブランチにマージするまでe2eも行えなくなる。テストが完了していない変更をreleaseに入れるわけにもいかないので、工夫が必要になる。
1機能単位で一度ブランチを作成し、そこから枝分かれするようにback、front、e2eと分ければ開発は行えるが、結局そのブランチにマージするまで、e2eやる前に軽く疎通しておきたいな...ということができず、複数人で開発することがとても面倒になった。
開発スピードの低下
では、複数人で分担せずback、front通貫して1担当者が1ブランチで開発する方針にすればよいかと言われるとそれも難しい。当然分担できなければ1人で書くコード量も増加し、backとfrontがそれぞれ同じ開発量があるとするなら、開発の着手～完了までの期間は単純計算で倍となる。
もちろん、1機能単位に着く人数も半減するので、開いた人間がそれぞれ別の機能を担当し、より多くの機能を同時並行で開発することで最終的なゴールは一緒になるが、「これは早めに開発してほしいんだけど...」というような依頼には応えられなくなり、また同時並行するブランチの量も多くなり、ブランチ管理が困難になる。
チーム内でも多くの機能が同時並行して進むと、お互いの開発内容、進捗の把握が困難となり、思わぬ場所でコンフリクトのリスクを背負うことになる。
コードレビューに負荷がかかる
1ブランチにすべての開発資産の変更が入るため、マージリクエストには大量の差分が表示される。back単位、front単位で開発ができた段階でレビュー依頼を出すにしても、差分が多いと目が滑る。
近年（2026年3月現在）ではコードレビューや機能レビューも含めてAIに任せたり、なんならハーネスエンジニアリングという概念が出てくるほどClaude活用の革新が顕著だが、このプロジェクトはそこそこ息が長く、そこまでシフトすることはできなかった。
また顧客がいてリリース期限がカツカツなプロジェクトにおいて、技術シフトに失敗し、品質が担保できなかったら元も子もないという現実問題もある。そのため、既存の「人間の目で確認する」という方法で品質を担保してきたプロジェクトではこの問題を脱却できなかった。
顛末
とりあえず、releaseからブランチを1つ切って設計書を作成し（親）、そこからさらにback、front、e2eと3つブランチを作成し（子）複数人で開発するような体制をとった。
この方法で開発者視点では特に「back-frontの疎通確認を親にマージするまで行えない」という点が非常に厄介で、対処療法ではあるが、ローカルにリポジトリを複数cloneしてそれぞれback用、front用のブランチをチェックアウトするという至極不便な対応をした。
感想
規模が大きいプロジェクトであればこそ、Claudeを活用して効率よく開発し、一定の品質を保てるようにしたいので、Claude活用のためmonorepoにするということ自体は良かったが、途中で移行するということが良くなったと感じている。開発初期からそういう構成、それに適した要員計画をしていたらこのような混乱は生じなかったと思う。
AI活用の革新スピードが速すぎて追いつくのもやっとであるが、プロジェクトの途中で体制を変えてまで追いこうとすることと、開発者に開発体制の変更の負担を強いることはトレードオフ（革新が成功すれば儲けものだがそうとも限らない）だと思うので、現実問題をしっかりと把握し、プロジェクト単位で体制を固定したまま進めるという舵切りをしたり、移行を決断するなら必要によっては開発作業を完全に停止してでも移行期間を設けて、落ち着いて移行することが必要なのではないだろうか。