Noidaのテックハブに足を踏み入れれば、エンドツーエンドのウェブソリューションを約束するエージェンシーが数多く存在することに気づくでしょう。彼らのピッチデック（提案資料）は印象的で、セールスチームは自信に満ち溢れています。しかし、表面を少し掘り下げてみると、見慣れたパターンが浮かび上がってきます。洗練されたインターフェースであなたを驚かせたポートフォリオの裏には、たった一つのデータベースクエリを書くのにも苦労するチームが隠れているかもしれません。あるいは、LaravelやNode.jsを誇示しているショップが、2003年のスプレッドシートのようなユーザー体験を提供することもあるでしょう。クライアントがこの不一致に気づくのは、通常、契約が締結され、手付金が支払われ、プロジェクトがすでに迷走し始めてからなのです。その時には、すでに手遅れなのです。
このような混乱は避けられます。まずは、ウェブデザインとウェブ開発は異なる専門分野であることを理解することから始めてください。この二つを混同している人物を雇うことは、予算を浪費するへの近道です。
ピクセルとプロダクションの間の溝
ウェブデザインは、サイトがどのように見え、どのように感じられるかを扱うものです。デザイナーは、階層、ホワイトスペース、色彩心理学、そしてランディングページからチェックアウトや問い合わせフォームに至るユーザーの動線について考えます。彼らはFigmaやAdobe XDといったツールを使用します。最終的な成果物は、静的な画面セットやクリック可能なプロトタイプです。それは「ビジョン」を示すものであり、フォームデータを収集したり、決済を処理したり、数千人の同時訪問者にページを配信したりするものではありません。それは建物ではなく、設計図なのです。
ウェブ開発は、エンジニアリングのフェーズです。開発者はその設計図を受け取り、ブラウザでレンダリングされるHTML、CSS、JavaScriptを記述します。プロジェクトの要件に応じて、バックエンドのロジックを構築し、サーバーを設定し、データベーススキーマを設計し、決済ゲートウェイ、配送API、認証プロバイダーなどのサードパーティサービスを統合します。成果物は、実際に動作するライブURLです。
これら二つの世界は、異なる言語を話しています。デザイナーは、ボタンが親しみやすいものかどうかを心配します。開発者は、ネットワークの遅延がある中で、その同じボタンが正しくAPIコールをトリガーするかどうかを心配します。どちらの懸念も重要です。しかし、片方の言語しか話せないエージェンシーは、もう半分を未完成のままにしてしまうでしょう。
「フルサービス」という蜃気楼
Noidaのエージェンシー市場は混雑しており、競争は激しいものです。そのため、企業は当然のように、設計からデプロイまで「すべて行います」と主張します。しかし、現実はしばしば不均衡です。あるショップには、才能あるビジュアルデザイナーが3人いる一方で、パートタイムでコードを書くジュニア開発者が1人しかいないかもしれません。あるいはその逆で、タイポグラフィを後回しにするような、優秀なエンジニアばかりというケースもあります。どちらの不均衡も、クライアントにとって利益にはなりません。
リスクは単なる見た目の問題にとどまりません。デザイン重視のチームは、レスポンシブに対応させるのが悪夢のように難しい、豪華なモックアップを作成するかもしれません。開発重視のチームは、汎用的な管理画面テンプレートを製品に貼り付け、それを「ブランド化されたもの」と呼ぶかもしれません。この乖離は、ユーザー受け入れテスト（UAT）の段階で初めて明らかになります。サイトが承認されたコンセプトとは似ても似つかないものであること、あるいは、そもそもそのコンセプトが実現不可能であったことに気づくのです。
本質を見抜くための3つの質問
契約書にサインする前に、以下の質問を使って、そのエージェンシーが本当に両方の技術を網羅しているかどうかをテストしてください。
「設計と構築の両方を行ったサイトを3つ見せてください」 片方の作業しか担当していない例は受け入れないでください。可能であれば、Figmaファイルと実際のGitリポジトリを見せるよう求めてください。開発の途中でデザイン変更があった場合、どのように対処したかを尋ねてください。もし彼らが言葉に詰まるようなら、プロセスの片方を外注しているか、自分たちの役割を誇張している可能性が高いです。
「公開後、CMSの管理権限は誰が持つのか？」 これは当たり前のことのように聞こえますが、公開の興奮の中で見落とされがちです。初日から、コンテンツ管理システムに対する明確な認証情報、ドキュメント、および制御権が必要です。一部のエージェンシーは、独自のセットアップを使用して、クライアントを自社のホスティングに縛り付けたり、軽微なテキスト更新のたびに料金を請求したりすることがあります。所有権については早い段階で確立しておきましょう。
「8ヶ月後に新しいページタイプを追加する場合、どのようなプロセスになりますか？」 これにより、サイトがどれほど深く考え抜かれて設計されているかが分かります。脆弱なコードベースでは、小さな構造変更のたびに開発者の介入が必要になります。適切に構築されたサイトであれば、マーケティングチームがチケットを発行することなく、CMSを通じて新しいランディングページのレイアウトを柔軟に作成できます。もしエージェンシーがこの質問に困惑するようなら、彼らの開発プロセスは長期的な保守性ではなく、ローンチ（公開）をもって終了してしまっているのでしょう。
CMSの盲点
多くのプロジェクトが、公開後に静かに失敗していくのは、まさにここなのです。
クライアントはホームページのヒーローセクションに執着し、日々のワークフローを忘れがちです。ローンチから6週間後、営業チームは価格を更新したいと考えています。コンテンツマネージャーはケーススタディを公開する必要があります。人事責任者は3つの新しい求人情報を掲載したいと考えています。もしこれらを追加するたびにサポートチケットを発行し、開発者がPHPテンプレートを編集するのを2営業日待たなければならないとしたら、あなたのウェブサイトはすでにボトルネックになっています。
だからこそ、CMSファースト戦略が重要なのです。コンテンツ管理システム（CMS）は、最後に付け足すものではなく、最初のヒアリングの段階から議論の対象に含まれているべきです。あなたのチームは、コードに触れることなく、テキストを編集し、画像を入れ替え、新しいページを公開できなければなりません。もしエージェンシーが、ローンチ後に誰がコンテンツを管理するのかを尋ねてこなかったとしたら、彼らはあなたの運用の実態を考えていなかったということです。
2つのチームが「ゼロ」になる時
一部の企業は、デザインと開発の分断を解決するために、別々のベンダーを雇おうとします。見た目や雰囲気のためにデリーのデザインスタジオを呼び、そのファイルをビルドのためにノイダの開発会社に渡すといった具合です。書類上では、全員が専門家です。しかし実際には、意図の齟齬が次々と発生します。
静的な画面では、レスポンシブな挙動を説明できません。モックアップでは、検索結果がゼロだった場合に何が起こるかを指定していません。ホバー状態、ローディングスケルトン、エラーメッセージ、あるいは空の状態（empty states）についても記述されていません。開発者は意図を推測しなければならず、多くの場合、その推測は外れます。すると、デザイナーがステージングサイトを確認して「壊れている」と宣言します。開発者は「デザインが不完全だった」と反論します。クライアントは手戻りの費用を支払い、その間、2つのチームはSlackのスレッドやメールのやり取りの中で、何週間も議論を続けて時間を浪費します。
そのコストは単なる金銭的なものだけではありません。それは「勢い」の喪失です。製品のローンチは遅れ、マーケティングカレンダーは停滞します。あなたのチームが本来存在すべきではなかったギャップを埋めるのに奔走している間に、競合他社はより速く動き出します。
引き継ぎの真のコスト
もしあなたがこの記事を読んでいるフリーランスなら、これらは決して理論上の話ではありません。おそらく、あなたはすでにその残骸を引き継いできた経験があるはずです。クライアントのFigmaファイルを開いたものの、モバイル用のブレイクポイントがない20枚ものアートボードを見つけたこともあったでしょう。前の開発者がデザイナーと一度も打ち合わせをしていなかったために、すべてのコンテンツフィールドがハードコードされているバックエンドを目の当たりにしたこともあるでしょう。2日間の修正作業として見積もったものが、実際にはコンテンツアーキテクチャ全体の再構築が必要だと判明したこともあるはずです。
これらのギャップを埋めるには多大なコストがかかります。なぜなら、それらは単なる技術的な問題ではないからです。それらは、コードの中に凍結された「コミュニケーションの失敗」なのです。
まとめ
ウェブサイトはロゴではありません。それは、ビジュアルとインフラの両方を通じて、あなたのビジネスを顧客とつなぐ「生きたシステム」です。エージェンシーを雇う前に、その方程式のどちら半分を実際に買おうとしているのかを理解してください。彼らのプロセスを精査し、エンドツーエンドの責任（ownership）を証明するよう求め、テープカット（完成）の後までCMSを無視することを拒否してください。ローンチ当日を生き延びるプロジェクトとは、8ヶ月後の火曜日、誰にも電話することなく価格を変更する必要がある時を見据えて計画されたプロジェクトなのです。