制作会社・デザイン会社が"公開で止まる"理由と実装パートナーの使い方

デザインはきれいに仕上がった。UIも完成している。なのに、いつになっても公開されない。こういう状況は、制作会社やデザイン会社に発注したプロジェクトで起きやすい。

原因は制作会社の「できる範囲」と、発注者の「できると思っていた範囲」のズレだ。これは誰が悪いという話ではなく、構造的に起きやすい問題だ。

なぜデザイン会社は「公開」で止まるのか

デザイン会社・Web制作会社の強みはUI/UXの設計と、見た目の実装にある。Figmaでのデザイン、HTML/CSS、フロントエンドのコーディングまでは高品質でこなせる。

問題は「公開する」に必要な要素がそこで終わらないことだ。

本番公開には以下が必要になる。

• 認証機能（誰がログインできるか）
• バックエンドのロジック（データの保存・処理）
• データベースの設計と接続
• 本番サーバーの構築とデプロイ
• 環境変数の管理
• セキュリティ設定
• エラー監視の仕組み

これらは「開発エンジニア」の領域であり、UI専門の制作会社がカバーしていないことが多い。会社によっては「フルスタックで対応できます」と言うが、実際には外部のエンジニアに再委託していたり、対応できるエンジニアが1人しかいなかったりする。

止まる3つの典型シナリオ

シナリオ1：制作会社に頼んだら、デザインだけ上がってきた

「Webサービスを作りたい」という依頼を制作会社にしたが、納品物がFigmaファイルと静的なHTMLだった。データの保存や認証は「実装は別途ご相談」になる。

このケースは契約時の認識齟齬が原因だ。発注者は「動くサービス」を期待し、制作会社は「デザインと静的ページ」を成果物として理解していた。

シナリオ2：フロントエンドはできたが、バックエンドが空

フロントエンドは動いているように見えるが、データが実際には保存されておらず、ログインも本物ではない。ボタンを押せばページ遷移するが、そのデータは架空のものだ。

「デモとして動く」状態と「本番として動く」状態の差がここにある。バックエンドのAPI、DB接続、認証のすべてを別途実装する必要がある。

シナリオ3：動いているが、本番環境がない

ローカル環境またはデモ環境では動くが、本番公開のためのサーバー設定が終わっていない。ドメイン取得、SSL証明書の設定、環境変数の本番用設定、デプロイパイプラインの構築、どれかが抜けていて「あとちょっと」が続いている。

実装パートナーの役割

実装パートナーとは、制作会社が作ったデザインやフロントエンドを受け取り、本番公開できる状態まで仕上げるエンジニアリングのパートナーだ。

具体的にカバーする範囲は以下になる。

• 認証・権限の実装： ClerkやSupabaseを使ったログイン・サインアップ・権限管理
• バックエンドAPI： Next.jsのServer Actions・API Routes、データの処理ロジック
• データベース： Supabaseのテーブル設計、RLS設定、CRUD実装
• 本番デプロイ： Vercelへの本番デプロイ、環境変数の設定、ドメイン接続
• セキュリティ： SQLインジェクション対策、CSRF対策、セキュリティヘッダーの設定
• 監視・運用： Sentryのエラー監視、ログ設計、バックアップ設定

制作会社が「最初の70%」を担い、実装パートナーが「残りの30%」を埋める。この分業が機能すると、プロジェクトが公開まで一気に進む。

本番公開の「最後の30%」についてはこちらの記事で詳しく解説している。

ハンドオフの実際の流れ

制作会社から実装パートナーへの引き渡し（ハンドオフ）は、以下の流れが機能しやすい。

Step 1：制作会社が渡すもの

• Figmaファイル（全画面・全状態のデザイン）
• フロントエンドのコード（GitHubリポジトリ）
• 画面一覧と画面の説明
• 権限・ロールの定義（管理者・一般ユーザーなど）

Step 2：実装パートナーが受け取ってやること

• コードの現状確認と技術的負債の洗い出し
• バックエンドアーキテクチャの設計
• DBスキーマの設計・実装
• 認証・権限の実装
• フロントエンドとバックエンドの接続

Step 3：本番公開前の確認

• 本番環境でのテスト
• セキュリティチェック
• パフォーマンス確認
• 引き継ぎドキュメントの作成

この流れをスムーズにするためには、Step 1の「制作会社が渡すもの」が揃っているかどうかが鍵になる。特に「権限・ロールの定義」は事前に決まっていないと、バックエンド実装のスコープが大きくブレる。

2社に発注するブリーフの書き方

制作会社と実装パートナーに別々に発注する場合、「それぞれの担当範囲」を明確に書かなければ、どちらも「相手がやると思っていた」という状態になる。

ブリーフに必ず含めるべき項目：

• 制作会社の担当範囲： デザイン（Figma）、フロントエンドコーディング（静的または最低限の動作）
• 実装パートナーの担当範囲： 認証、DB、バックエンドAPI、本番デプロイ、監視
• 引き渡し基準： 「制作会社からのFigmaとフロントコードが揃った段階で実装パートナーが着手する」
• 共有リポジトリ： 両者がアクセスできるGitHubリポジトリを最初から用意する
• コミュニケーション手段： Slack・Notion等でのやり取りルールを決める

コストの実際の割り振り

デザインと実装の費用配分は、プロジェクトの複雑さによるが、一般的な目安は以下の通りだ。

つまり、実装パートナーの担当は全体の50〜60%になることが多い。「デザインを頼んだら完成すると思っていた」という認識だと、予算の後半で大きな追加費用が発生する。

デザイン会社が「フルスタック対応できる」と言うときのレッドフラグ

以下のような状況は、依存するリスクがある。

• フルスタック担当が1名しかいない（その人が抜けるとプロジェクトが止まる）
• バックエンドの事例や実績が見せてもらえない
• セキュリティやDB設計の話を持ち出すと「問題ありません」しか言わない
• 本番運用後のサポート体制が不明確

見た目のポートフォリオだけでなく、「本番で動いているサービスの実績」を確認することが重要だ。見積もりをブレさせないための事前整理についてはこちらも参照。