ホーム > 制作実績 > 「サイトごとに作り直す」をやめる。 複数のサイトを展開できる共通基盤を構築。

「サイトごとに作り直す」をやめる。
複数のサイトを展開できる共通基盤を構築。

戦略コンサルティング企業 ヘッドレスCMS基盤開発

プロジェクト概要

新しいサイトを1つ立ち上げるたびに、システムをカスタマイズする。
その状態を続けていては増え続けるサイトの数に開発体制がいずれ追いつかなくなる——。

そんな課題を抱えていたのは、複数の地域向けに情報サイトを展開してきた企業さまです。
ルート・シーはサイトごとに個別最適化されていた仕組みを見直し、1つの基盤から複数のサイトを展開できる新しいCMS基盤を構築。
サイト開発の工数と負荷を抑えながら、今後の地域展開をスピーディーに進められる仕組みを実装しました。

 

課題
  • 新規サイトを立ち上げるたびシステムをカスタマイズ
  • エンジニアリソースが不足し、サイト構築が追いつかない
実施内容
  • 1つの共通基盤から複数サイトを展開できる仕組みを構築
  • サイト数の増加に応じて段階的に拡張できるサーバー構成を設計
  • 外部サービスとのAPI連携など拡張性のある機能を用意
  • 展開のための勉強会を実施
成果
  • サイトごとにシステムをカスタマイズする工程を削減
  • 従来より短い工期で新規サイトを提案できる体制を構築
  • 仕様を共通化し、提案・制作双方の業務負荷を軽減

複数のサイトを手がけていた戦略コンサルティングさま

複数の地域向けに情報サイトを制作・運営していた戦略コンサルティングさま。地域ごとに異なる情報発信のニーズに応えるため、個々にカスタマイズしたサイトを立ち上げてきました。
しかし、サイトの数を増やす先にある壁が立ちはだかるようになりました。

 

サイトを1つ増やすたびに、システムをカスタマイズしていた

サイトごとに個別最適化されたシステムを構築することで、新規サイトの制作はその都度エンジニアの手を大きく必要とする作業になっていました。
特に大きな課題となっていたのがエンジニアリソースの不足です。1件ごとにシステムを構築する体制のままでは開発のスピードも人手も追いつきません。

「新しいシステムを一から作るのではなく、これまで培ってきた仕組みを土台に次のサイトへつなげられないか」—— それがお客さまからいただいたご相談の出発点でした。

 

サイトごとの違いは、実は「見た目」が中心だった

話を伺っていくなかで見えてきたのは、サイトごとの違いの多くが「見た目」の部分にあり、仕組みとしては共通化できる部分が多いということでした。
サイトごとにトップページの見せ方やビジュアルは異なります。
しかし「サービス紹介」「事例紹介」「ニュース・お知らせ」「特集コンテンツ」など、ページ構成や機能には多くの共通点があります。

これまでのシステムはその「共通している部分」までサイトごとに個別に作り直していました。つまり、課題の本質はエンジニア不足そのものではなく、共通化できる仕組みを共通化できていなかったことにありました。

 

「サイトを作る」のではなく「サイトが生まれる仕組みを作る」

そこでルート・シーが考えたのは「サイトを作る」のではなく「サイトが生まれる仕組みを作る」という発想の転換でした。
1つの基盤となるシステムを軸に据え、そこから必要なサイトを展開させていく構造へとつくり替える。この考え方をもとに、具体的な仕組みづくりを進めていきました。

 

POINT 01:ヘッドレスCMSで、複数サイトを展開できる共通基盤を構築

これまでのようにサイトの数だけシステムを作るのではなく、1つの基盤を軸に機能を拡張し、そこから複数のサイトを構築できる仕組みを新たに設計しました。
また、お客さまからは「特定の言語やフレームワークに縛られず、フロントエンドを中心とした開発にしたい」というご要望もいただいていました。

そこで採用したのがユーザーが見るサイト画面と管理側の仕組みを分離する「ヘッドレスCMS」です。
管理側はPHP Laravel、ユーザー側はNuxt という技術基盤を用いることで、各サイトではフロントエンドでの改変を中心とするアーキテクチャとし、デザインやレイアウトはサイトごとに自由に変更できる一方、管理画面の仕様は全サイト共通にすることで開発の効率と拡張のしやすさを両立させました。

一方で、共通の基盤を持つということは後から特定のサイトだけに特化した機能を追加することが難しくなるという側面も持ちます。
そのため「どこまでを基盤側で共通化するのか」「どこからをサイトごとの個別対応にするのか」お客さまと何度もすり合わせながら設計を進めました。

POINT 02:API連携や構造化データにも対応できる、拡張性のある設計に

基盤を共通化しても、サイトごとの個別要望がなくなるわけではありません。外部サービスとのAPI連携や標準機能にない情報を管理画面から編集できる機能など、拡張の余地はあらかじめ残す設計にしました。

また、将来的な検索環境の変化も見据え、検索エンジンだけでなくAIにも情報の内容を正しく認識されやすくするため、新着情報や特集記事などに構造化データを出力する仕組みを導入しました。基盤としての一貫性を保ちながら、機能面での厚みも持たせています。

POINT 03:仕組みをつくるだけでなく、展開できる体制まで整える

新しい仕組みはこれまでとルールが異なります。デザインやレイアウトなどはサイトごとに柔軟に変更できる一方、管理画面の仕様はシステム全体で共通のためカスタマイズ性は低くなります。
この違いをエンドクライアントへ提案する段階できちんと説明できていないと、制作が進んだ後になって「思っていたのと違う」という手戻りが生まれてしまいます。

そこで、ルート・シーは新しい基盤が完成したタイミングでお客さまと合同での勉強会を開催しました。
「基盤の考え方」「できること・できないこと」を具体例やワイヤーフレームを交えながら共有し、お客さまがエンドクライアントへ自信を持って提案できる体制づくりまでサポートしました。
あわせて、複数のサイトを今後展開していくことを見据え、サーバー構成やインフラもサイト数の増加にあわせて段階的に拡張できる設計を構築しています。

 

標準パッケージ化がスピード感のある納品を可能に

共通の標準パッケージを開発したことにより、納品までの工期を短縮した提案も可能になりました。
1つのサイトのための開発ではなく、次のサイト、その次のサイトのための土台をつくれたことがこの取り組みにおける一番の変化です。

また、共通の基盤を軸にする仕組みへと切り替えたことで、仕様に対する共通認識が生まれ、業務の効率化と設計負荷の軽減につながりました。
今後はこの基盤をさらに育てながら、開発にかかる工数や工期を、より一層短縮していくことを目指して運用を続けていきます。

 

複数のサイトを展開する事業にも応用できる仕組み

今回構築したような共通基盤の考え方はこの事例に限ったものではありません。
共通する機能を持ちながらそれぞれ異なるwebサイトを複数展開している事業であれば、同じ発想を応用できます。

例えば、

  • ブランドや商品・サービスごとにサイトを展開するメーカーや小売企業
  • 店舗・施設・拠点ごとに情報ページを持つ飲食店やホテル、医療・介護施設
  • マンションや住宅など、物件ごとにサイトを展開する不動産・住宅会社
  • 学部やキャンパスごとに個別サイトを持つ学校法人・教育機関
  • グループ会社や事業部門ごとにサイトを分けて運用する多角化企業

といった事業では、次のような課題が生まれやすい傾向があります。

  • サイトが増えるたびに、似たようなシステムを一から開発している
  • 複数サイトの更新・改修・管理が大きな負担になっている
  • 今後さらにサイトを増やしたいが、現在の開発体制では追いつかない

こうした課題に心当たりがある場合、今回のように「共通化できる部分を仕組みとして切り出し、個別に対応すべき部分は柔軟に残す」という設計の考え方は業種を問わず応用できるはずです。

 

本質的な課題を見つけ、ビジネスの成長へつなげる

今回、ルート・シーが向き合ったのは「エンジニアリソースが足りない」という表面的な課題だけではありません。
なぜ、サイトが増えるたびに開発負荷が増えるのか。その根本にあったのが、共通化できる仕組みまでサイトごとに作り直していたことでした。
そこで、1つのサイトをつくるのではなく、次のサイト、その次のサイトへと展開できる基盤そのものを構築しました。

依頼されたものをつくるだけではなく、課題の根っこまで考え、その先の成果につながる仕組みまで実装する。
ルート・シーは、そんな開発・制作を大切にしています。
同じような課題に心当たりのある方は、ぜひ一度ご相談ください。

お問い合わせはこちら