🌊

事業成長の裏の開発チームの記録と今後

sasaki

2025/07/23に公開

 1. はじめに：その個別開発、あなたのチームの「悪夢」になっていませんか？

顧客ごとに微妙に違う要件、そのたびにフォークされ増え続けるリポジトリ、コピペで少しずつ汚染されていくコード、そして深夜まで続くデプロイ作業…これは、かつての私たちのチームが直面していた現実です。
もしこの記事を読んでいるあなたが、同じような「個別開発の沼」でもがき苦しんでいるなら、この話はきっとお役に立てるはずです。
これは、私たちが個別開発という「悪夢」から脱出し、カンリーホームページをCMS化[1]することで、導入案件数を16案件から約100案件へとスケールさせた技術的意思決定の記録です。
この記事では、その裏側にあった
大きな方針転換を支えた3つの判断軸
急成長を支えた地道な技術的カイゼン
守りと攻めを両立させたプロダクトグロース
の全てを、包み隠さずお話しします。

 2. The Pain - 個別開発がもたらした「16案件の壁」私たちのサービスがまだ16案件ほどのお客様に支えられていた頃、カンリーホームページは1社1社個別開発で開発するのが当たり前でした。一見、お客様に寄り添った柔軟な対応に思えますが、その裏側で開発チームは深刻な課題を抱えていました。

絶望的な開発速度： 1案件導入するのに平均で 約100人日 もかかっていました。

雪だるま式の開発・保守コスト： 案件ごとに 相当数 の工数が発生し、共通の仕様変更を16個のリポジトリ全てに適用する「メンテナンス地獄」が常態化していました。

品質のばらつきと属人化： 担当者によって実装が異なり、コードの品質は不安定。「Aさんしか分からない」案件も生まれ始めていました。
メンバーは疲弊し、チームの士気は下がる一方。私たちは「このままではスケールしない。これ以上の案件数の壁は越えられない」という、明確な限界を感じていました。

 3. The Pivot - 我々がCMS化を決断した3つの理由
この状況を打破するため、私たちは「個別開発から脱却し、管理画面からカンリーホームページを生成できるCMSを開発する」という、大きな今後の成長に大きく寄与する決断をしました。この意思決定の背景には、3つの重要な判断軸がありました。

 ① ビジネス要件：『速度』がすべてを解決する当時、私たちの市場ではサービスの導入スピードが競争力の源泉でした。私たちは、「個社ごとの120点のカスタマイズ」よりも「標準化された機能を、開発工数5人日で提供できること」に価値があると判断し、「速度」を最優先事項としてCMS化へと舵を切りました。

 ② コスト：開発工数の大幅な削減と品質向上という副次的効果個別開発をしていた時には、バグがある場合それぞれのリポジトリでそれぞれ修正する必要がありましたが、CMS化をすることで、共通の処理を用いるためバグがあった場合はその箇所を修正するだけで解消することができます。また、追加機能の開発が必要な場合も共通で使われる機能を開発するため今までと比べると大幅に開発コストを減らすことができるだけでなく、プロダクトの品質についても大幅に改善することが期待されました。

 ③ 将来性：50社、100社を見据えた『仕組み』への投資CMSの開発は短期的に見れば大きな投資です。しかし私たちは、この投資を「未来への資産」だと捉えました。「個別開発は"負債"を生み、CMS化は"資産"を生む」。この思想で、中長期的なスケーラビリティを優先しました。

 4. The Gain - CMS化がもたらした劇的な変化チーム一丸となってCMSをリリースした結果、私たちの世界は一変しました。

導入案件数： 3年で 16案件 → 約100案件 へと急増。

開発工数： 平均約100人日 かかっていたものが、約20人日 に短縮。

開発リソース： 導入作業はディレクターでも可能になり、エンジニアの工数は5人日程に。
しかし、CMS化はゴールではありませんでした。それは、約100案件という規模を支えるための、新たな戦いの始まりだったのです。

 5. The Grind - 約100案件を支える地道なカイゼンとプロダクトグロースCMSという「幹」はできましたが、約100案件のお客様に安定してサービスを届け、さらに事業を成長させるためには、無数の「枝葉」を育て、幹自体を強くする必要がありました。

 ① スケールに耐える『運用』の仕組み化約100案件分のフロントエンドが存在する状況は、新たな「メンテナンス地獄」を生む可能性がありました。そこで、私たちは2つの仕組みを導入しました。
フロントエンドのコアライブラリ化： Next.js で構築したフロントエンドの共通機能（検索ロジック、UIコンポーネント等）を切り出し、プライベートなnpmパッケージとしてライブラリ化しました。各社の package.json はこのコアライブラリを参照するだけ。これにより、修正はライブラリのバージョンを上げるだけで全社に反映できるようになり、品質の均一化と開発効率の劇的な向上を実現しました。

運用の自動化： さらに、GitHubActionsを用いて、コアライブラリのバージョンアップを自動でプルリクエスト作成からE2Eテストを挟みデプロイする仕組みを構築。これにより、数十のリポジトリのバージョン追従作業から解放され、運用コストを大幅に削減できました。

 ② パフォーマンスとの終わりなき戦い導入案件数の増加は、システムの負荷という形でダイレクトに跳ね返ってきます。私たちは地道なパフォーマンス改善を続けました。

フロントエンド負荷軽減： 特に負荷の高かった地図検索機能では、多数の店舗ピンを一気に描画するのをやめ、地図のズームレベルに応じて店舗情報を集約する「クラスター表示」を導入。これにより、表示速度を劇的に改善し、ユーザー体験を損なわずにフロントエンドの負荷を抑えることに成功しました。

バックエンド負荷軽減： DBに対しても、地道なクエリ改善を繰り返しました。EXPLAIN で実行計画を確認してはインデックスを追加し、N+1問題を一つずつ潰していく。こうした泥臭い作業の積み重ねが、約100案件が同時にアクセスしても耐えうる安定した基盤を築いたのです。

 ③ 守りながら攻める『プロダクトグロース』こうした「守り」の改善と並行して、私たちは「攻め」の手も緩めませんでした。運用改善で生み出されたリソースを新機能開発に投資し、新しいフォーマットや、新たな機能を次々とリリース。これがフックとなり、これまでとは違うニーズを持つ新たなお客様の獲得にも繋がり、事業の成長をさらに加速させることができました。

 6. The Next Step - 約100案件を支えるアーキテクチャのその先へ地道な改善を重ねてきましたが、約100案件という規模は、現在のモノリシックなCMSアーキテクチャに新たな課題を突きつけています。パフォーマンスのボトルネック、1つの障害が全顧客

に影響するリスク…。
今のアーキテクチャのままでは、200社、500社という次のステージには行けません。
そこで私たちは今、次の成長を見据えてリアーキテクチャも含め新たな基盤構築の検討を開始しています。また、今後の事業成長に耐えうるシステムでありながら、お客様の理想から入ったプロダクトを実現するにはどうするべきなのか、未来を見据えたエキサイティングな議論が続いています。

 7. まとめ個別開発の沼から抜け出すための「CMS化」という大きな決断。そして、その成長を支えるための、フロントエンドのライブラリ化や地道なパフォーマンス改善といった無数の「地道なカイゼン」。
事業の成長は、一つの大きな花火だけで成し遂げられるものではありません。大きな方針転換と、日々の泥臭い改善の両輪があってこそ、真のスケールが実現できるのだと、私たちはこの経験から学びました。
この記事が、同じように事業と技術の課題に直面している誰かの、次の一歩を踏み出す勇気となれば幸いです。

脚注
弊社では管理画面でホームページの項目を自在に登録・編集できるようなシステムを構築しています。 ↩︎