CMSやショップが、ツールではなくボトルネックになったとき。
コンテンツやカタログが最初に選んだ製品に収まらなくなった企業のためのLaravel CMSとECプラットフォーム。そして、既製のプラットフォームのほうが適しているときの正直な答え。
ツールがコストになり始める場所
プラットフォームはまだ動いています。その周りのすべてが手作業になっただけで。
これらのうち2つ以上が当てはまるなら、制約はチームではなくデータモデルです。
- コンテンツモデルがビジネスと合っていない
- 売っているものはページではないのに、CMSはページしか知らない。本当の構造は命名規則、スプレッドシート、あるいは誰かの頭の中にあります。
- プラグインがクリティカルパスを握っている
- 価格、在庫、チェックアウトのロジックが、誰も個別にアップグレードできない拡張機能に散らばっている。アップグレードは先送りされ、リスクが積み上がります。
- 日常的な変更に開発者が必要
- キャンペーン、ルールの変更、属性の修正。それぞれが、前に行列のあるチケットになります。
- システムを手作業で突き合わせている
- 注文、在庫、顧客をショップ、ERP、倉庫の間でコピーしている。誰かがエクスポートし、誰かがインポートし、誰かが確認します。
01
02
03
04
構築するもの
プラットフォームが使い続けられるために正しく作るべき5つのこと。
- あなたのドメインをモデル化したCMS
- 実際に管理しているオブジェクトから、その関係、状態、検証ルールとともに構築します。近似するために曲げられたテーマではなく。
- EC：商品、注文、クーポン、コンテンツ
- 回避策なしのバリエーション、セット商品、構成可能な商品。現場が認識している状態を持つ注文ライフサイクル。プラグインではなくルールとしてのクーポン、プロモーション、契約価格。コンテンツと商品をひとつの画面で。
- 一日中それを使う人のために作られた管理画面
- 実際の組織を映したロール、一括編集とフィルタ済みビュー、下書き、プレビュー、予約公開、ビジネス用語での検証、監査証跡。日常的な作業に開発者が必要なら、その画面は未完成です。
- 構築の制約としてのパフォーマンスとテクニカルSEO
- サーバーサイドレンダリング、実際のデータ量に合わせたキャッシュ、ファセットナビゲーションにも耐えるcanonicalとページネーションの処理。リプラットフォームでは、リダイレクトはリリース後ではなく前にマッピングします。
- 引き渡しではなく、進化型の保守
- 壊れてはいけない経路へのテスト、初日からの監視、そしてマイグレーションになるまで先送りするのではなく計画されたアップグレード。
構築してきたもの
あなたのために作るプラットフォームを、私たち自身が運用しています。
ロゴのポートフォリオではありません。規制業種の組織のための仕事の多くは、合意した守秘義務のために名前を出せません。ここにあるのは実在する3つのもので、それぞれどこまで自分で確かめられるかを明記しています。
- Automobili Zupi、ディーラーのバックオフィス
- 公開URL： automobilizupi.it: イタリア語と英語の2言語プラットフォーム。公開部分は検索付きの車両カタログ、中古車査定依頼、ローン相談。重要なのは、顧客、テンプレートから生成される契約書、支払い、ロール、権限、マーケットプレイスへの掲載エクスポートのために毎日使われているバックオフィスです。
- 開発を続けているカスタムCMS
- 私たちは毎回プラグインを組み合わせるのではなく、独自のCMSを構築・保守しています。だからここでは、ドメイン固有のコンテンツモデルが研究課題ではなく出発点になります。社内ソフトウェアなので訪問できるものはありません。代わりに管理画面のウォークスルーをご依頼ください。
- ECストア
- 同じスタックで構築・運用している小売のカタログとチェックアウト。商品、注文、コンテンツを、開発者のいない小さなチームがひとつの画面から管理しています。
稼働中、公開
自社製
小売
要望リストではなく、制約を持ってきてください。
セットアップのうち、壊れている部分やチームを止めている部分を送ってください。技術的な見立てをお返しします。「私たちは必要ない」という答えも含めて。
正直な見極め
カスタムプラットフォームが不要なとき。
カスタムはShopify、WooCommerce、WordPressの上位版ではありません。取引です。パッケージ製品なら回避策で対処するはずのモデルに合わせる代わりに、コードを所有する。それが割に合うのは、モデルが本当にあなた固有のものであるときだけです。
パッケージ製品が正しい選択なのは…
- カタログが標準的：商品、バリエーション、価格、在庫、ひとつのチェックアウト。
- 配送、税、決済がすでにエコシステムでカバーされている。
- 市場投入の速さが適合より重要で、回避策が許容できる。
- 社内に技術的な持ち主がおらず、継続的なエンジニアリングの予算枠もない。
- 差別化要因はブランド、品揃え、マーケティングであって、仕組みではない。
カスタムプラットフォームが割に合い始めるのは…
- リリースのたびに、パッケージ製品のモデルに合わせるための回避策がまたひとつ増える。
- 価格や注文のロジックが差別化要因：契約、見積もり、承認、レンタル、サブスクリプション。
- ERP、PIM、物流、レガシー連携が本当の複雑さを担っている。
- 業務が管理画面に依存しており、汎用のものがボトルネックになっている。
- コンプライアンス、データレジデンシー、監査可能性のためにスタック全体の制御が必要。
- 拡張機能のスタックがリスク：安全にアップグレードするには可動部品が多すぎる。
| 決めること | パッケージ製品 | カスタムプラットフォーム |
|---|---|---|
| モデルへの適合 | プロセスを製品に合わせ、ギャップを慣習と拡張機能で吸収する。 | 製品がプロセスの周りに構築される。ギャップは回避策ではなく設計上の判断。 |
| コストの形 | 初期は低く、ライセンス、アプリ、ギャップが生む手作業に分散する。 | 初期は高く、構築とその後のエンジニアリングに集中する。 |
| 誰に依存するか | ベンダーと拡張機能の作者、彼らのロードマップ。 | コードを読めるどのチームでも。リポジトリはあなたが持つ。 |
| ルールの変更 | 製品がサポートする範囲内では速く、その外では脆い。 | 製品が許す範囲ではなく、エンジニアリングの能力で決まる。 |
| 妥当な次の一歩 | そのまま使い、予算を品揃え、コンテンツ、集客に使う。 | まずドメインモデルを定義し、それからビジネスロジックを担う部分を構築する。 |
案件の進み方
コードの前にモデリング、引き渡しの前に本番。
アセスメント
プラットフォーム、データ、連携、そして管理画面で毎日誰が何をしているか。成果物：何を残すべきか、カスタムが妥当かどうかの書面での見立て。
ドメインモデル
インターフェースを設計する前に、エンティティ、関係、状態、ルールをその持ち主と合意します。このステップが、2年後に管理画面が自明に感じるか恣意的に感じるかを決めます。
段階的な構築
実際の環境に届くスライスを、壊れてはいけない経路へのテスト付きで。旧システムは、新システムがトラフィックに値するようになるまで本番のままです。
移行とリリース
コンテンツ、カタログ、注文履歴を照合チェック付きで移行。切り替え前にリダイレクトを配置し、ロールバック経路を用意します。
進化
監視、計画されたアップグレード、生きたバックログ。作ったチームが運用するチームでなくても済むように、ドキュメントを書きます。
技術FAQ
プロジェクトを決める質問。
既存のCMSを適応させる代わりに、なぜカスタムCMSを作るのですか？
コンテンツモデルが製品そのものであるときだけです。汎用CMSはページ、投稿、フィールドビルダーを提供します。それで足りるなら、それを使ってください。カスタムが安くなるのは、編集者が扱うオブジェクトがページではなく（セッションと座席を持つ講座、空き期間を持つ物件、互換パーツから構成される製品）、パッケージの答えがどれもプラグインと回避策の組み合わせになるときです。
ShopifyやWooCommerceのほうが良い答えなのはいつですか？
よくあることで、最初の打ち合わせでそう申し上げます。標準的なカタログに標準的なチェックアウト、配送、税なら、それを作り直すのは解決済みの問題にお金を使うことです。カスタムが意味を持つのは、ビジネスロジックが差別化要因のとき。契約価格、倉庫やチャネルをまたぐ在庫、見積もりから注文への流れ、サブスクリプションやレンタルの仕組み、あるいは本当の複雑さを担うERPと物流の層です。
他社が作ったプラットフォームを引き継げますか？
はい。書き直しの提案ではなくアセスメントから始めます。コードベース、データモデル、デプロイ経路、テストカバレッジを読み、何を残して安全か、何がリスクかを報告します。引き継いだシステムの多くは、依存関係のアップグレード、重要経路へのテスト、そして電話に出る誰かがいれば十分です。書き直しがあるなら、現行システムを本番に置いたまま段階的に行います。
リプラットフォームでSEOはどう扱いますか？
最後のチェックリストではなく、データ移行の問題として。リリース前に、インデックスされるすべてのURLを棚卸しし、恒久リダイレクトで対応先にマッピングし、すでに順位を持つパターンを維持します。加えて、サーバーサイドレンダリング、構造化データ、canonicalとページネーションの処理、実際のカタログから生成するサイトマップ、そして貴社のテンプレートとデータ量で測定したCore Web Vitals。
リリース後はどうなりますか？
案件は引き渡し日ではなく、継続的な変化を中心に組まれています。初日からの監視とエラー追跡、計画されたアップグレード、そして最初の構築と同じレビューとテストのプロセスを通じた新機能。いずれにせよ、リポジトリ、インフラ定義、ドキュメントはお渡しします。
なぜLaravelですか？
採用市場が大きく、アップグレード経路が予測でき、地味だが重要な部分（キュー、スケジュールジョブ、認可、検証、マイグレーション、テスト）に一級の答えを持つ成熟したPHPフレームワークだからです。私たちを別のチームに替えるときも、一般的なスキルセットで採用できるということでもあります。
お問い合わせ
プラットフォームについて、実際に作る人と話しましょう。
フォームの自動返信ではなく、エンジニアが一通の返事を書きます。お役に立てない案件なら、最初の打ち合わせでそう申し上げます。
- 拠点
- イタリア · チェコ · 日本