「デザインは気に入ってもらえたのに、いざ実装となると“ここは難しいですね…”と言われてしまう」。そんな経験、ありませんか？
実はその多くが、CMSやECサイトの“見えない仕組み”を知らないまま進めてしまうことが原因です。
デザイン上は自然でも、システム側では「触れない場所」「変更できない構造」が必ずあります。
この記事では、制作前に押さえておくべきポイントを“チェックリスト形式”で整理します。
どこを確認すればよいかが明確になるので、「実現できないデザイン」を避け、安心して制作を進めるためのヒントが手に入ります。
1. 「実現できないデザイン」が起きる理由とは？
「このデザイン、CMSだと難しいですね…」
そんな言葉を、提出後のタイミングで急にコーダーから告げられた経験はありませんか？
クライアントの前では堂々としていたのに、裏でひそかに焦りがこみ上げてくる──
実はこれ、デザイナーさんたちが“よく経験するパターン”なんです。
（1）三者の前提がズレたまま、静かに制作が始まってしまう
多くのトラブルは、「デザイナー・クライアント・コーダーが同じ方向を向いていない」まま走り出したときに起こります。
たとえば、こんなやり取り。
クライアント「デザインめちゃくちゃ良いです！これで進めましょう」
デザイナー「ありがとうございます！では制作に入りますね」
——数日後——
コーダー「えっと…この部分、CMSの仕様的に触れないんですよね…」
デザイナー「（え…先に言って…？）」
こんなふうに、
• クライアントは“CMSの制限を知らない”
• デザイナーは“多分できるだろう”と思っている
• コーダーは“相談されていないので詳細まで見ていない”
という三者三様の誤解を抱えたまま進行してしまうのが典型的な構造です。
とくに ECサイトやCMS案件では、ヘッダー・カート・検索まわり・ユーザー編集領域など、「自由に触ってはいけないエリア」「仕組み的に固定されているエリア」が必ず存在します。
デザイン上は自然でも、システム側はまったく別のルールで動いている──このギャップこそが、“実現できないデザイン”の正体です。
（2）CMSは“借り物の家”──自由度が違うという前提
静的LPでは、要素を自由に配置し、細かく動きをつけることも可能です。しかしCMSは、例えるなら「大家さんのいる家を借りて暮らす」状態。
• 壁（テンプレート）が勝手に変えられない
• 配線（機能）が特定の位置に固定されている
• 階段（ナビゲーション）を勝手に作り替えられない
こうした制限があるため、「見た目の自由度」と「実装できる自由度」は別物と理解しておく必要があります。
ここを押さえているデザイナーさんは、制作前から「このCMSの環境だと、どういう動き方をするんだろう？」と自然に想像する癖がついているので、リスク察知が早いです。
（3）すべてを理解する必要はない。でも“調べる姿勢”だけは必須
CMSのすべてを理解するのは、プロのコーダーでも不可能です。
ですが、
• 管理画面を見る
• 公式ドキュメントを確認する
• 問い合わせて仕様を聞く
• YouTubeなどで解説動画を探して見る
といった 「環境を調べる姿勢」 を持つだけで、避けられるトラブルは一気に減ります。
たとえば既存サイトの案件では、管理画面を少し触るだけで…
• どこが編集可能か
• どこが固定領域か
• どこがシステム側で管理されているのか
ほとんど把握できます。
そして、もしあなたに相談できるコーダーがいれば、気になるポイントをまとめて聞けるので、判断スピードも精度もガツンと上がります。
「全部理解しよう」ではなく、「環境を確認して、必要な部分を聞く」。
この姿勢こそが、実現できないデザインを避けるための最初のステップです。
2. CMS・ECサイトで特に注意すべき技術的ポイント
CMS案件、とくにWordPressやEC追加のある案件では、「テーマの自由度」や「共通部分の作りやすさ」を正しく判断できるかが、後工程のトラブル回避に直結します。
ここでは、デザイナーさんが受注前の段階で押さえておくべき3つの視点を、実際の現場例も交えて整理します。
（1）WordPressテーマ構造が自由度を左右する
WordPressはとても柔軟なCMSですが、その自由度はテーマごとに大きく違うのが現実です。
■ 受注前に必ずチェックしておきたいこと
・テーマは新規で選べるのか？
・既存テーマを変更できるのか？
・すでに運用中で“テーマ変更できない案件”ではないか？
・ログイン情報をもらえるか？（＝中を確認できるか）
テーマによっては「カスタマイズ前提」で自由度が高いものもあれば、反対に「ほぼ固定レイアウト」で自由に変更しづらいものもあります。
デザイナー:「このLP、ファーストビューに大きな動画を置きたいんです」
コーダー:「いま使っているテーマのトップは固定ページじゃなく、独自テンプレートですね…動画は入りますが、位置の自由度は限られます」
ログイン情報があるだけで、「どこまで再現できるのか」「どの程度の工数になるのか」の精度が段違いに上がります。
（2）「わからないから気にしない」が最も危険
CMSに苦手意識がある方は慎重なので問題が起きにくい一方、実はもっとも危ないのは――
「WordPressはよく知らないけど、デザインだけ整えばOK！」というタイプ。
なぜ危険かというと、
• 見えない制約が存在していることに気づけない
• 自由度の高いデザインを無自覚に作り、後で破綻しやすい
• 専属コーダーがいないと、誰もリスクに気づかないまま進行する
「トップページの動きは完璧にできたのに、固定ページのレイアウトがテーマの仕組みと合わなくて、全部作り直しに…。途中で“あ、このテーマはそういう作りだったのか”と知りました」
これは本当によくあるケースです。「知らない部分にこそ、もっとも大きなリスクが潜んでいる」――CMS案件の鉄則です。
（3）デザイナーさんが必ず確認しておきたい“共通部分”のデザイン
HTMLソースを読み、テーマ名や作りから仕様を推測できるのは、WordPressに慣れているコーダーだからこそできる判断です。
デザイナーさんが押さえるべきポイントは、もっとシンプルです。
■ 共通部分に“盛り込みすぎない”
共通部分とは…
・ヘッダー
・フッター
・サイドバー
・パンくず
・ページタイトル
・共通レイアウト領域
ここに複雑な装飾や特殊レイアウトを入れすぎると、以下の問題が起きがちです。
■ よくある問題
• テーマの構造と合わず、実装が極端に難しくなる
• 変更するとサイト全体に影響し、工数が跳ね上がる
• 一部だけデザインが合うが、他ページで崩れる
デザイナー:「ヘッダーの中にスライダーと複数段のナビを入れたいです」
コーダー:「このテーマはヘッダーが固定領域で、編集できるのはロゴとナビだけなんです…入れられなくはないですが、全ページに影響が出るので工数がかなり増えます」
共通部分は “派手にしないほど実装が安定する”と覚えておくと役立ちます。
3. デザイン前に必ず確認したい実装難易度チェックリスト
デザインを始める前に、「どこが実装の山場になるのか」 を把握できるかどうかで、案件全体の負担が大きく変わります。
ここでは、デザイナーさんが受注前に必ずチェックしておきたい“実装難易度の見極めポイント”を整理します。
（1）動的コンテンツの有無を最優先で確認する
まず最初に確認すべきは “動的コンテンツがあるかどうか” です。
■ 動的コンテンツがあると何が変わる？
• CMS（WordPress等）が必要になる可能性が高い
• デザインの自由度に制約が出る
• コーディングの工数・見積もりに大きく影響する
■ アニメーションは「数」ではなく「複雑性」で難易度が決まる
アニメーションも、どれだけ要素を分割するか で工数が大幅に変わります。
例えば…
• 一枚画像 → 配置して終わり
• 一部分だけ動かす → 動かす要素を切り出して正確に位置合わせ
• さらに複数パーツ → パズルのように組み合わせて動かす
特にLPはアニメーションが増えがちなので、「これは静止画でいける？」「分割が必要？」の見極めが最重要ポイントになります。
（2）動的要素の実装責任を見落とさない
最近のLPや企業サイトでは、“見た目はシンプルなのに裏側は自動更新” というケースが増えています。
よくある例：
• 新着情報が勝手に増えていく
• 実績を管理画面から追加すると自動で並ぶ
• ブログやSNSを読み込む
ここでの落とし穴は…
■「デザインだけすればOK」では済まない現実
一度受注すれば、その動作を成立させるための実装責任はデザイナー側にも発生します。
クライアントの要望が、
「自分で更新できるようにしたい」
「情報が自動で増えてほしい」
などであれば、それはすべて “動的コンテンツ扱い” です。
■ 受注前の必須確認ポイント
「ここはコーダーが実装できる仕様か？」
「更新方法はクライアント任せか、自動か？」
「管理画面での編集が必要か？」
受注前にこれを確認しておかないと、後で大きく響いてきます。
（3）実装難易度を見極めるチェックリスト
以下の４点をデザイン前に確認するだけで、“避けられるトラブル”が一気に減ります。
■ 必ずチェックしたい項目
①クライアントが更新すると内容が変わる部分はあるか？
→ 自動更新・投稿機能・カスタム投稿の判断材料に
②SNS・外部ブログなど、他サイトと連携する箇所はあるか？
→ API連携が必要になる可能性
③アニメーションや動きが必要なパーツはどこか？
→ 分割の有無・複雑度の判断材料
④ユーザーの操作で表示や動作が変わる部分があるか？
→ タブ、アコーディオン、フィルタリングなどのUI要素
■ こうして見えてくるもの
• 工数
• スケジュール
• デザイン可能範囲
• 実装に必要な技術レベル
これらを“受注前”に見極められるだけで、後工程でのトラブルや手戻りが大幅に減り、クライアントとのやり取りもスムーズになります。
4. プラグイン・ライブラリ選定時に押さえるべき注意点
プラグインやライブラリは、便利な“魔法ツール”のように見えますよね。ですが、相性を間違えると 「そのデザイン、そもそも実現できなかった…」という悲劇を引き起こしやすい領域でもあります。
ここでは、受注前に知っておくだけで大きなトラブルを避けられる、プラグイン選定の最重要ポイントをまとめます。
（1）まず確認したいのは「互換性」と「有料・無料の違い」
よくあるケースとして…
デザイナー「参考サイトのあの機能、これ使えば再現できるかな？」
コーダー「そのプラグイン、今回のCMSでは動かないですよ」
こんな“すれ違い”は日常茶飯事です。
■ 最優先すべきは“互換性”
• そのプラグインは今回のCMSで使える？
• バージョンの組み合わせで問題は出ない？
• EC用？LP用？特定テーマ専用？
使えないものは、どんなに魅力的でも使えません。
例えば…
• EC CUBEの決済モジュール → WordPressでは動かない
• WordPressの人気プラグイン → 他CMSでは利用不可
• 同じWordPressでもテーマやPHP版で動作が変わる
互換性は「一番最初に確認すべき項目」です。
■ 「有料・無料」の違いも見落としやすいポイント
参考サイトは、
• 有料プラグインで高機能を実現している
• カスタム開発で独自機能を追加している
ことが多く、クライアントの予算では再現できないこともあります。
つまり、“同じように見えても、同じ仕組みとは限らない”この前提を持つだけで、受注ミスを大幅に減らせます。
（2）プラグインは「交換すればOK」ではない
ここは、私がコーダーとして何度も経験してきた“本当に注意すべき落とし穴”です。
■ 実例：FAQプラグインの差し替えで起きた惨事
PHPのバージョンアップをきっかけに、
• これまで安定して使えていたFAQプラグインが突然不具合
• 修正まで待てず別プラグインに一時差し替え
• しかしデザイン仕様がまったく違い、コーディングをほぼやり直し
• さらに登録済みFAQのデータ移行作業まで発生
“交換するだけで済む”なんてことは、ほぼありません。
■ プラグインの構造は“ブラックボックス”の塊
• HTML構造が違う
• CSSの初期値が違う
• 出力パターンが違う
• データの保持方式が違う
見た目は似ていても、裏側は別物です。だから「乗り換えればOK」という発想は非常に危険です。
（3）受注前に必ず踏みたいプラグイン・ライブラリ選定チェック
デザイナーさんが受注前に確認できるシンプルな流れを提示します。
■ 選定チェックリスト
1. 静止画像以外のクライアント要望から、必要な機能を洗い出す
例：FAQ、スライダー、投稿一覧、検索、フォーム など
2. それを実現できるライブラリ・プラグインを事前に調べる
（見た目ではなく“機能”をベースに探す）
3. 候補が今回の実装環境で使えるか、コーダーに必ず確認する
（互換性 / 保守性 / 安全性 / 将来バージョンで問題が出ないか）
この3ステップを受注前に踏むだけで、「あとで実現できないと気づく」 という最悪の事態をほぼ回避できます。
5. サーバー環境・管理体制をヒアリングするためのチェック項目
サーバー環境の話は、どうしても“技術寄り”に見えるので、苦手意識を持たれがちです。
でも実は、ここを押さえておかないとデザインそのものが実現しないケースが本当に多いんです。
「サーバーって正直よくわからない…」そんなデザイナーさんほど、ここで紹介する視点を持つだけでトラブル確率が一気に下がります。
（1）最優先で確認すべきは「PHPバージョン」
受注前のチェックで最も大事なのが PHPバージョン です。
理由はシンプルで、PHPは“WordPressを含むCMS全体を動かすエンジン”だからです。
■ PHPが古いと、現実に起こる問題
エンジンが古いと、当然こんな不具合が起こります。
• CMS本体が正常に動かない
• プラグインやライブラリがインストールできない
• インストールできても一部機能が動かない
• 既存プラグインがエラーを起こして新機能が動作しない
さらに厄介なのは…
■ PHPは「サーバー会社が勝手に上げてくれない」
クライアントが自分で切り替えないと永遠に放置されます。
実際、
• 5年前のPHP
• セキュリティサポート切れのバージョン
こういった状態が“珍しくありません”。
だからこそ、「受注前に PHP が確認できるか」が実装可否の分岐点になります。
（2）PHPが古いと本当に起きるトラブル
これは“机上のリスク”ではなく、制作現場で何度も起きているものです。
■ 実際のトラブル例
1. プラグインがインストールできない／動かない
例：「最新PHP前提のプラグイン」がエラー停止
2. 既存プラグインがそもそもエラー状態
新しく追加したプラグインも巻き込んで動かない
3. セキュリティリスクが高まる
古いバージョンほど脆弱性が放置されている
そしてこれらは、受注後に判明した瞬間、『できません』『追加費用が必要です』につながる典型パターン。
デザイナーさんが悪いわけではなく、“事前に聞いていなかっただけ”で発生してしまう問題です。
（3）受注前に必ずヒアリングしたい項目（サーバー & 機能要件チェックリスト）
クライアント自身が「動的機能」に気づいていないケースが非常に多いので、こちらから丁寧に確認していくことが大事です。
以下は、LP制作を例に「最低限聞いておくべき項目」を整理したものです。
▼サーバー・システム関連のヒアリング項目
• 現在の PHPバージョン（確認できる？切り替え可能？）
• サーバー管理者は誰？（クライアント／他社／不明）
• WordPressは既にインストール済みか
• 複数インストールされていないか（意外と多い）
• セキュリティ設定（FW・アクセス制限）の有無
• テーマ変更が可能か／既存テーマ固定か
▼機能要件（動的コンテンツ・ユーザー操作）
• お問い合わせフォームの要不要
• 外部サービス（スプレッドシート等）への連携は必要？
• スライダーやアコーディオンなどの動的UI
• モバイルメニュー（ドロワー）の要否
• 離脱防止ポップアップ
• クリックで拡大する画像表示（Fancybox等）
• カウントダウンタイマー
• 他サイトとの連携（RSS、SNS、API）
• 新着情報やブログ一覧の表示
（４）事前確認が、実装可否を正しく判断する唯一の方法
ここまでの項目を受注前に聞けていれば、
• 必要なプラグイン
• 動的コンテンツの量と難易度
• サーバー環境が耐えられるかどうか
これらが“正確に”判断できます。
もし専属のコーダーがいるなら、ヒアリング項目の作り方そのものを相談するのもおすすめです。デザイナーが見落としやすいポイントを必ず補完してくれます。
6. 正しい見積もりと安全な受注のために、コーダーに相談すべきタイミング
（1）受注前に確認できなくても、「受注直後すぐに」環境チェックが必要な理由
受注前にサーバーやCMSのバージョンをすべて確認できれば最高です。
でも現場では、クライアントが「サーバーは後で設定します」「とりあえずデザインから進めてください」と言ってくるケースも本当に多いですよね。
ただ、この流れには大きな落とし穴があります。
デザイン完成後にサーバー環境が古いと判明すると、次のような問題がほぼ確実に発生します。
• PHPバージョンを上げる作業が別途必要になる
• バージョン変更によって既存プラグインがエラーを起こす
• その対応コストや追加作業範囲が曖昧で、トラブルに直結する
特に注意したいのが、LP設置先のサーバーに既存のWordPressサイトが入っている場合です。
PHPのバージョンは“サーバー全体”に影響するため、LPだけでなく、既存サイトのテーマやプラグインが突然動かなくなるリスクもあります。
だからこそ、受注直後の環境確認は「デザイナーの守りの一手」なんです。
これはクライアントのためでもありますが、デザイナーさん自身の負担を減らすためでもあります。
（2）受注前に入手できると安全度が跳ね上がる最低限の情報
以下の2つは、可能なら受注前に、無理でも受注した瞬間に必ず依頼したい項目です。
・サーバー管理画面のログイン情報
・CMS（WordPressなど）の管理画面ログイン情報
この情報がないまま制作を進めると、「あとで環境が原因の手戻り」がほぼ確定してしまいます。
しかも、サーバー環境の問題は一見デザインに無関係に見えるため、クライアントからすると“理解されづらい”トラブルに発展しがち。
だからこそ、早めに環境情報を押さえて、制作のスタート地点を安全にしておくことが重要です。
（3）コーダーに相談して得られるのは「答え」だけでなく、正しい条件設定
コーダーに相談することは、「できる・できない」を聞くことが目的ではありません。
本当に得たいものは次の2つです。
①実装可否の明確化
• 条件付きで可能
• テーマ変更が必須
• 有料プラグインが必要
• サーバー設定を変更しなければならない
…といった前提条件まで含めて明確にしましょう。
②条件を踏まえた、正確な見積もり
前提条件が変われば費用も変わります。コーダーが示す「実現のために必要な作業」は、そのまま見積もりの根拠になります。
デザイナーさんにとって大切なのは、これらの「条件」と「理由」をメモしてクライアントに説明できるようにしておくことです。
専門的な部分はすべて理解する必要はありません。でも、背景を言葉として伝えられるだけで、クライアントの納得度が大きく変わります。
7. デザイナーさんが安心して制作に集中するためのチーム体制づくり
（1）「技術の不安を抱えたままデザインしない」ための仕組みを作る
デザインの手が止まるとき、多くの場合その原因は“技術の不確実性”です。
「この動きは再現できる？」「この仕様は問題ない？」そんな迷いを抱えながら作業すると、判断が遅れ、修正が増え、ストレスも蓄積していきます。
このストレスをゼロに近づける一番の方法は、技術的な相談を気軽に投げられる相手を確保しておくこと。
専属コーダーや技術パートナーがそばにいるだけで、判断スピードは驚くほど変わりますし、精神的な安心感が段違いです。
（2）デザイナーとコーダーの間で“早めに流すべき情報”
安心して制作を進めるには、情報が正しい順序で流れる仕組みが必要です。
特に次の情報は、デザイナー側で抱え込まず、早い段階で共有するとプロジェクトが一気に安定します。
• クライアントの要望（動き・外部連携・動的コンテンツ）
• 想定している構造案やレイアウト案
• 参考サイトで気になった演出や機能
• 使用を検討しているプラグインやライブラリ
• サーバー／CMSログイン情報
これらを早めに共有することで、コーダー側が実装可否や作業工数をスムーズに判断でき、あとからデザインを作り直す…といった手戻りも確実に減っていきます。
（3）「わからないことを放置しない」文化をチームに根づかせる
プロジェクトで一番避けたいのは、「よくわからないけど、多分いけるだろう」という状態で作業が進行してしまうこと。
この“なんとなくのまま進める”が、後半の大炎上に直結します。
だからこそ、不明点が出たら次の3つを徹底できる文化をつくることが重要です。
1. わからない点は必ずコーダーに相談する
2. 不確定要素はクライアントに事実ベースで説明する
3. 実装可否が曖昧なままデザインを確定させない
この3つがチームの共通ルールとして機能するだけで、制作全体の安定度はグッと上がります。
（4）継続して依頼できる“信頼コーダー”を確保するメリット
毎回その場でコーダーを探すスタイルでは、関係構築から始める必要があり、コミュニケーションのズレも起きやすくなります。
でも、継続して依頼できる専属コーダーや技術パートナーがいると、得られるメリットは非常に大きいものばかりです。
• 過去案件との比較で実装可否を素早く判断してもらえる
• あなたの得意・不得意を理解した上で提案がもらえる
• 技術判断が一貫するため品質が安定する
• 小さな疑問も気軽に相談できるようになり、トラブルが激減
「困ったらこの人に聞けば大丈夫」という状態は、デザイナーさんにとって精神的な“安全基地”。
結果として、制作に集中する時間も増え、クオリティも自然に上がっていきます。
8. まとめ
（1）「実現できないデザイン」は、ほとんどが“事前のひと手間”で防げる
お伝えしてきた通り、デザインが実装でつまずく原因のほとんどは、環境・仕様・技術条件を確認しないまま進めてしまうことにあります。
裏を返せば——
• CMSの仕様
• テーマの構造
• サーバー環境
• 動きや外部連携などの動的要件
• プラグインの互換性
これらを受注前に軽くチェックしておくだけで、後半のトラブルは驚くほど減ります。
“事前確認＝プロジェクトの保険”と捉えておくと、判断が格段に楽になります。
（2）全部理解する必要はない。ただし“不明点を放置しない姿勢”だけは必須
サーバーやCMSの仕組みを完全に理解する必要はありません。
ただし、「自分が知らない部分には必ずリスクがある」という意識だけは持っておきたいところです。
技術的にあいまいなままデザインを固めてしまうと、あとから大幅な修正が発生し、クライアントとの信頼関係にも影響します。
不明点が出たら立ち止まり、コーダーに確認する。この一歩だけでプロジェクトの安定性は大きく変わってきます。
（3）安心して制作に集中できるのは“専属コーダー”がそばにいるから
この記事で最も伝えたい結論は、「デザイナーは専属コーダーと組むことで安心して制作に集中できる」ということです。
環境確認、実装可否、プラグインの選定、サーバー要件、見積もりの根拠づくり……
これらはすべて技術職の領域。デザイナーが一人で抱える必要はありません。
相談できるコーダーがいるだけで、
• 判断がブレなくなる
• 品質が安定する
• 手戻りが減る
• 受注の安全性が上がる
といったメリットが自然に生まれます。
（4）技術リスクを早期に察知できるデザイナーは、クライアントに選ばれる
最終的にクライアントが信頼するのは、「完璧なデザインスキル」よりも“リスクを察知し、適切な技術者と連携して安全に進められる力” です。
そのために大切なのは、
1. できる／できないを明確に判断できる
2. なぜその判断になるのか説明できる
3. 必要に応じて専門家と協力できる
この3点を押さえておきましょう。
これは経験年数ではなく、“正しい姿勢”によって自然に身についていく力です。
