Series #1｜本稿は概念と枠組みの共有。具体実装は #2・#3 へ。
TL;DR
・6年以上の成長で Next.js の進化に追従するコストが増え、開発速度と知識分散に課題が見え始めた
・管理画面を段階的に刷新し、技術的負債を計画的に解消しながら高速な開発体制を構築（ユーザー影響は最小化）
・初期は AI 活用や新技術の前提を楽観視し、計画をリベース。以降は機能オーナーシップ/コロケーション設計、外部知見、ドキュメント/テスト強化で並行開発できる自律的なチームへ
はじめに
こんにちは。Global teamのセクション長をしている近藤です。
現在管理画面をリプレイスするプロジェクトを主に推進しており、全体判断は私（近藤）、技術判断はテックリード（Aleksei）が担い、必要に応じて連携しながら進めています。
Commune は6年以上続くプロダクトです。初期から Next.js を採用し、当時は日本語の情報を発信する有志サイトにコントリビュートをしていた時期もありました。しかしその間に Next.js は大きく進化し、私たちのコードベースとの間には広いギャップが生まれてしまいました。
このギャップは単なる技術的な遅れにとどまらず、開発速度の低下、コードの属人化傾向、新機能追加時の影響予測の難しさ、そして新メンバーのオンボーディングに必要な時間として、プロダクト開発全体に影響を及ぼしていました。部分的な修正では吸収しきれないこれらの課題に直面し、「緩やかな移行ではもう追いつけない」と判断しました。
そこで私たちは 管理画面の刷新 から着手することにしました。これは単なる「負債返済」ではなく、高速なプロダクト開発の実現と、属人化しづらい技術スタックによる人材流動性の確保を目的とした、未来に向けた投資 です。
そして、リプレイスを進める中で気づいたのは、これらの目標を達成するには技術的な刷新だけでは不十分だということでした。持続的な開発と進化ができる状態を実現するには、エンジニアがアーキテクチャを理解し、学びを広げ、チームに共有していく──そんな自律性と協調性の文化を育てることが不可欠でした。この認識が、プロジェクトの重要な目標のひとつとなったのです。
本記事もその一環として、現時点での私たちの試行錯誤と学びを共有します。
プロジェクトの経緯
スタートラインと初期の判断
最初に取り掛かっているのは 管理画面 です。ユーザー画面と比べて複雑度や求められる要件が限定的だったため、新しい実装を試しやすいと判断しました。レガシーと新コードを並行させ、段階的に置き換える安全策を選びました。とはいえ、管理画面においても対象の機能は大きな括りで30項目以上あり、細分化するとリプレイス対象の機能はもっとあります。
途中、体制変更に伴ってオーナーシップを私へ移管しました。
プロジェクトの停滞と要因分析
プロジェクトは開始から約1年が経過していたものの、当初の締切には間に合っていませんでした。その背景には二つの要因があります。
-
AI 自動化への過信
開発を加速させようと AI に頼りましたが、仕様は想像以上に複雑で、自動生成だけでは対応できませんでした。その結果、当初の計画よりもプロジェクトは停滞してしまいました。
-
技術的負債の顕在化
App Router の事例も少なく、ベストと言える状態を探れるほど知見が持てていない中で、Next.js や React Server Components の理解が深くない状態で実装した箇所があり、不適切なコードが残ってしまいました。
またテストはUIやコンポーネントの修正や仕様変更が落ち着いてから実装する予定だったため、テストカバレッジが十分とは言えませんでした。
立て直しへの着手
この状況を受けて、私たちは以下の三つの施策を実行しました。
- 基本方針の正式な定義：データフェッチ、コンポーネント構造といった基本方針を明文化し、Next.js の機能を直感的に使えるよう整備
- テスト戦略の根本的見直し：数十に及ぶ管理画面を手動で検証し続けるのは非効率であり、継続的な改善を安全に進めるためにも自動テストの導入が必須となりました
- ドキュメントによる合意形成の仕組み化：PdM／QA と「リリース可能な状態」を定義し、ドキュメントで合意を残す仕組みを導入
- 実装するエンジニアが仕様を文章化し、PdM／QA がレビューして合意
- 合意の記録を残して後から参照できるようにする
- 自分の言葉で仕様をまとめることで理解を深める
こうして「合意済みのガイドラインに沿って進められる」体制を整えました。
並行開発体制への転換
最も重要だったのは、ページ単位のオーナーシップを明確にし、エンジニアが非同期で並行開発できる体制へ移行したことです。従来の「1ページを複数人で分担」するやり方から、「1ページ=1オーナー」を原則としました。
この方針の狙いは明確です。速度感を持ってプロジェクトを進めるためには、複数のエンジニアが互いをブロックすることなく、同時並行で作業できる環境が不可欠だったからです。
ただし、このプロジェクトにおいては既存実装を置き換えるのが目的であり、早期の価値検証よりもリソース効率を優先するトレードオフを理解した上での意思決定でした。
しかし並行開発には課題もあります。特に以下の二点が問題になりえました。
- 権限の曖昧さ：各エンジニアがどこまで独自に判断してよいのか不明確だと、決断が遅れたり、逆に全体最適を損なう判断をしてしまう
- 設計の不統一：各自が独立して実装すると、アーキテクチャの一貫性が失われ、長期的な保守性が低下する
これらの課題に対処するため、全体最適のためのガイドライン整備、テストの標準化、そして外部知見の導入による設計指針の確立を同時に進めました。次のセクションで詳しく説明します。
裁量と責任の「切り出し」──設計戦略と組織戦略の一致
コロケーション志向への転換
プロジェクトの立て直しにあたり、アーキテクチャ戦略を大きく見直しました。当初はレイヤー志向の設計で進めようとしていましたが、コロケーション志向に方向転換したのです。
コロケーション志向とは、関連するコード（コンポーネント、ロジック、テスト、型定義など）を機能単位で同じ場所にまとめる設計思想です。これにより、ある機能を担当するエンジニアは、その機能に関するすべてのコードを一箇所で把握し、変更できるようになります。
この設計戦略の転換は、組織戦略とも一致しました。機能ごとに担当エンジニアを明確にアサインし、各自が独立して作業できるようにしたのです。
- 担当者がステークホルダーと直接合意を取り、ドキュメントに残す
- マネジメントを介さずに意思決定できる仕組みを導入
- 全体判断は私、技術判断はテックリード（Aleksei）が担い、必要に応じて連携
これにより「自分はどこまで決めてよいのか」が明確になり、各自が主体的に動けるようになりました。
トレードオフへの対処
機能軸でのアサインは並行開発を可能にする一方、設計の統一性を失いやすいというトレードオフがあります。この課題に対して、二つの戦略を採りました。
- 外部知見の導入とテックリード主導のガイドライン（後述）
- 設計議論への積極的な参加とレビュー体制
チームメンバーは、「設計戦略と組織戦略の不一致から来る学習コスト」──つまり、機能横断的な技術調整や、レイヤーをまたいだ複雑なコミュニケーション──に時間を取られることなく、機能に関する関係者との調整と実装にリソースを集中できるようになりました。
一般的に「裁量」に時間を割けないのは、こうした余計な仕事に取られるリソースが大きいからです。設計戦略と組織戦略を一致させることで、この問題を大きく軽減できました。
ドキュメント文化の定着
思わぬ副産物もありました。英語が不慣れなメンバーがいたこと、そして非同期コミュニケーションの必要性が、結果的にドキュメント文化を強くしたのです。
合意や仕様を必ず文章で残す習慣が自然に根付き、言語力に左右されず、誰もが同じ前提で議論・実装できる環境が生まれました。時差や勤務時間の違いを越えて、チーム全体が同じ情報にアクセスできるようになったのです。
結果として、このアーキテクチャの見直しは約1ヶ月で完了しました。設計戦略と組織戦略を一致させたことで、余計な調整コストをかけずに進められました。設計は実際に運用して磨かれていくものであり、完了したことが成果ではないことは理解しつつも、業務も遂行しながら短期間で納得のいく設計を完了し、運用を始められたことはチームの成果として誇りに思います。
外部知見の導入
課題のひとつは App Router に関する知見不足 でした。そこで 業務委託技術アドバイザーとして akfm さんに協力いただき、Next.js のベストプラクティスを取り込みました。
特に大きかったのは、akfm さんが示してくれた 「Next.js の考え方」 が設計議論の指標になったことです。なぜその設計を選ぶのかを著書を前提知識として理解したり議論できるようになり、合意形成がとてもスムーズになりました。
また、私たちが苦戦していたフロントエンドのテスト戦略についても、akfm さんの知識が大きな助けになりました。どのレベルでテストを書くべきか、何をテストすべきか──これらの判断基準が明確になったことで、テストの導入が加速しました。
一方で私たちにはドメイン知識があります。フレームワークの知識とドメイン理解を組み合わせ、チームにとって最適な形を模索できたのは大きな成果でした。
特にトレードオフをどう判断するかという場面では、akfm さんの柔軟な姿勢が助けになりました。理想論だけでなく現実的な判断を下すことで、設計上の迷いが減り、決断のスピードが上がりました。
自律と当事者意識を育てる仕組み
このプロジェクトは、単なる負債返済ではなく 自律と当事者意識を育てる仕組みづくりでもありました。
機能単位での開発とオーナーシップにより、エンジニア一人ひとりが意思決定に関わり、責任を持つ経験を積めるようになりました。これが自律性を育てます。
同時に、アーキテクチャの知見を組織全体に広げることで、当事者意識を育てることも重視しました。
- エンジニアがアーキテクチャを理解する
- 思考を広げる
- 学びを共有し、組織に伝える
アーキテクチャは誰か一人の専権事項ではなく、レビューや共創を通じて磨かれるべきものです。今回の取り組みを通じて、知見が少しずつチームに広がり、組織の文化として根付いていく手応えを感じています。
戦略の振り返りと今後の展望
このプロジェクトは、大きな裁量が求められるものでした。強引に進めざるを得ない場面もあり、「この進め方だと嫌われるのでは」と不安になることもありました。けれど実際には コミューンの仲間の優しさに支えられ、多くの人が実務面でも精神面でも後押ししてくれました。強引さを理解し見守ってくれたマネージャーにも深く感謝しています。
また、アーキテクチャを見直したことで AI との相性が高まったとも感じています。定量的な成果はまだですが、既存実装の活用精度や文脈理解が向上し、AI を使った開発体験は確実に改善しました。このテーマについては、改めて別の記事にまとめたいと思います。
振り返ってみると、多少こじつけに聞こえるかもしれませんが──人もアーキテクチャも、責務をどこまで担うのかをはっきり示したことで、自律的に動けるようになったのだと思います。組織構造の工夫と、アーキテクチャを feature 単位に切り分けた設計。両者が重なり合うことで、チームは以前よりも独立して動きながらも全体として進める体制を築くことができました。
謝辞
このプロジェクトは、本当に多くの人の力で前に進み続けています。厳しい制約の中でも手を止めず、移行を推進してくれた仲間に、まず心から感謝します。
特に、App Router やコロケーションの設計について安定した指針を示してくださった akfm さん、技術面の方向性を引っ張ってくれたテックリードの Aleksei、また、プロジェクトを自立的に推進してくれたプロジェクトメンバーには心から感謝をします。
そして最後に、日々の変化を受け入れ、フィードバックを積み重ねてくれたすべてのエンジニアに、改めてお礼を言いたいと思います。
もちろん、このプロジェクトはまだ道半ばです。成功かどうかを語るには早いですが、確かに言えるのは、ここまでの試行錯誤がチームの成長につながっていること。そして、この流れを止めずに引き続き前に進めていきたいということです。
次回予告
本稿（#1）では、「自律」という視点で組織とアーキテクチャを捉え直し、管理画面刷新に取り組んだ経緯を紹介しました。
続く #2、#3 は Aleksei による記事です。テーマは以下のとおり。
- #2：アーキテクチャ方針（レイヤードからフィーチャー単位／コロケーションへ）
- #3：テストと運用の枠組み（品質担保とリリースを支える仕組み）
シリーズ全体を通じて、「自律を育てる組織とアーキテクチャ」の全体像を共有していきます。
コミューンでは、私たちと一緒に働く仲間を募集しています！少しでもコミューンの開発組織や職場環境に興味をお持ちの方、ぜひカジュアル面談でお話ししましょう。
