開発期間わずか3日間。この驚異的なスピードで、マルチテナント型ECプラットフォーム「ec-plus1」は産み落とされました。
現代のエンジニアリングにおいて、「爆速開発」はしばしば「技術的負債の積み上げ」と同義に捉えられがちです。しかし、AIツールを駆使したこのプロジェクトが証明したのは、スピードとは「定義の速さ」であり、ボトルネックはコーディングではなく「標榜するアーキテクチャの解像度」にあるという事実です。
この記事では、単なるスピードアップの手法ではなく、3年後、5年後の事業成長に耐えうる「驚くほど論理的な設計指針」の舞台裏を、プロダクト・アーキテクトの視点から紐解きます。
テイクアウェイ 1：スピードの代償を管理する「戦略的負債」という考え方
3日間という極限のタイムボックスにおいて、私たちは「アーキテクチャを期限付きの資産」と定義しました。すべての非機能要件を初日に満たすことは不可能です。そこで重要になるのが、何を優先し、何を「意図的な負債」として管理するかという戦略的判断です。
ec-plus1では、負債を「インフラ・UX・運用・戦略拡張」という4つの柱で構造化し、単なる「未実装」ではなく「次フェーズの実行計画」へと昇華させました。
この爆速開発の代償として、非機能要件の細部や長期的な拡張性、運用の完全自動化といった領域には、意図的な技術的負債が積み残されている。（「残存課題および次フェーズ検討事項集約レポート」より引用）
この姿勢の肝は、負債を「見えないゴミ」にせず、ビジネスロジックの検証を最優先するための「投資」として言語化した点にあります。
テイクアウェイ 2：データ構造の「真実」は常にSKUにある
ECシステムにおいて、データの整合性は信頼の根幹です。ec-plus1のデータアーキテクチャでは、商品（Product）と販売単位（ProductSku）の責務を厳格に分離し、「何が正本か」を定義しました。
特筆すべきは、直感的な便利さをあえて否定した以下のルールです。
- SKUが唯一の正本: 販売価格（
selling_price）と在庫数（stock）の真実はSKUテーブルにのみ存在する。 - Productは動的キャッシュ:
products.priceはアクティブなSKUの「最小価格（min）」、products.stockは「合計在庫（sum）」の写しに過ぎない。
この設計において、products テーブルの価格や在庫カラムに対する直接的なSQL更新は「厳禁」です。データの整合性を守るため、更新は常に syncLegacySkuSnapshot() という同期ロジックを介さなければなりません。後方互換性と検索性を維持しつつ、データの真実性を守り抜く、アーキテクトとしての「譲れない一線」がここにあります。
テイクアウェイ 3：マルチテナントを守り抜く「ドメイン解決」の壁
複数のブランドが同居するマルチテナント環境において、他ブランドのデータ混入はシステム上の死を意味します。ec-plus1では、「インフラをゲートキーパーにする」という思想のもと、二段構えの防壁を構築しました。
- ResolveSite（ドメイン層）: Hostヘッダから
is_verified = trueであるドメインを特定し、サイトコンテキストを確定させる。 - site.owner（アプリケーション層）: 特定されたサイトのオーナー権限を検証する。
この二重の壁により、ショッピングカート内の商品混入さえもアーキテクチャレベルで遮断しています。セキュリティを「実装者の注意」に委ねるのではなく、システムが物理的に他者のデータに触れられない構造を優先したのです。
テイクアウェイ 4：「監査ログ」はデバッグ用ではなく、ビジネスの証跡である
「誰が、いつ、何を、どう変えたか」。金銭や在庫を扱うシステムにおいて、この説明責任（Accountability）は機能そのものよりも重要です。 ec-plus1では、システム監査ログを「エンタープライズ領域で戦うための競争優位性」と位置づけています。
アプリケーション障害調査用の通常ログではなく、誰が / いつ / 何を / どのように変更したか を説明するための業務監査ログを指す。（「監査ログ仕様」より引用）
すべての重要操作は、変更前（before）と変更後（after）の値をJSON形式で保存します。これにより、エンジニア向けのログビューアーをビジネスの紛争解決に流用するという「よくある間違い」を排除し、システムそのものが事業の証拠能力を持つ設計としました。
テイクアウェイ 5：GitHubは「コード置き場」ではなく「意思決定の正本」
チーム開発において、仕様がSlackや口頭の記憶に依存した瞬間に、プロダクトの寿命はカウントダウンを始めます。ec-plus1の運用哲学は極めてストイックです。
「GitHub上で見えない知識は、実務上は存在しないものとして扱う」
- No Issue, No Work: すべての変更はIssueを起点とし、そこには背景、スコープ、そして明確な完了条件（DoD）が明記されなければならない。
- Executable Specification: GitHubはタスク管理ツールではなく、仕様の「実行可能な正本」である。
- 学習エンジンとしてのSpike: 未知の領域は「Spike（調査Issue）」によってリスクを最小化し、その結論を次のドキュメントやIssueへと繋げる。
ドキュメントの更新は「付随業務」ではなく、機能実装の一部です。この「GitHub Operating Model」こそが、爆速開発をカオスから救う唯一の規律となります。
テイクアウェイ 6：BladeからNext.jsへ。実利を取る「ハイブリッド移行」の選択
フロントエンドのアーキテクチャ選択において、私たちは「純粋主義」よりも「実利」を取りました。ユーザー価値に直結する部分から段階的にモダン化する、現実的なハイブリッド構成です。
- Next.js（カタログ・フロント）: 購入率を左右する「商品一覧」「商品詳細」「カート」を担当。高いレスポンス性能とUXを実現。
- Blade（チェックアウト・管理）: セキュリティと複雑なビジネスロジックが絡む「注文確認・完了」「管理画面」を維持。
この二つのスタックを繋ぐのが、Laravel Sanctumを用いたSPA Cookie認証です。.ec-plus1.iplusone.co.jp のような共通ドメインを利用することで、Next.jsのショッピング体験からBladeの決済フローへと、ユーザーをシームレスに誘導します。高トラフィックな「買い物」と、高セキュリティな「決済」の境界線を、技術的にスマートに処理した選択と言えます。
結論：2026年を見据えた「事業成長プラットフォーム」への進化
ec-plus1の3日間での構築は、単なるECサイトの立ち上げではありません。それは、コスメ事業を起点としつつも、将来的にあらゆる商流を飲み込む「インフラ」への第一歩です。
AI時代の開発において、私たちは「爆速で立ち上げ、堅牢に育てる」という二律背反を、揺るぎない設計思想によって解決しました。技術のトレンドは移り変わりますが、データ構造の整合性や意思決定の証跡を守るという本質は変わりません。
最後に、あなたに問いかけます。
あなたのプロダクトに、3年後も耐えられる「正本」はありますか？それとも、ただの機能の積み上げですか？
補足すると、MVP開発、第２フェーズ、第３フェーズ、第４フェーズと計画した、当初はMVP開発のみを3日としてスタートしたのだが、結果的には第4フェーズまで完了させてしまったということ！
