クライアントから資料をもらい、いざ手を動かそうとしたところで止まる。どのページが必要で、どう並べればいいのか。デザインカンプを描き始めてから「このページ、そもそも要りましたっけ」と気づいて巻き戻る。フリーランスのWeb制作者が最も工数を溶かすのは、実装ではなく設計を飛ばしたときです。サイト設計とは、決めることではなく決めた理由を残す工程。この記事では、ヒアリングから情報設計、階層とURLのルール、ワイヤーフレームへの落とし込み、そして設計フェーズを契約上どう守るかまでを順に整理します。
サイト設計とは何か｜要件定義とデザインの間にある工程
サイト設計という言葉は現場によって指す範囲が違います。混乱の原因はここにあるので、まず前後の工程との境界をはっきりさせておきます。
要件定義・サイト設計・デザインは、決めることが違う
要件定義は「何のために作るか」を決める工程。デザインは「どう見せるか」を決める工程。その間にあるサイト設計は「どんなページを、どう並べ、それぞれに何を載せるか」を決める工程です。
| 工程 | 主な成果物 | ここで決めること |
|---|---|---|
| 要件定義 | 要件定義書・見積書 | サイトの目的、対象ユーザー、予算、公開時期 |
| サイト設計（情報設計） | ページ一覧、サイトマップ、ワイヤーフレーム | 必要なページ、階層構造、各ページの構成要素 |
| デザイン | デザインカンプ | 配色、書体、余白、トーン |
| 実装・構築 | ソースコード、CMS設定 | 挙動、更新のしやすさ、公開後の運用 |
設計を飛ばすと、必ず後工程で跳ね返る
設計を省いてデザインから入ると、次のような形で必ず戻ってきます。
- デザイン確認の場で「このページも必要だった」と発覚し、範囲が膨らむ
- ページ同士の関係が定まらず、ナビゲーションが後付けの継ぎ接ぎになる
- 公開直前にURLの構造を変えることになり、実装をやり直す
- 「なぜこの並びなのか」を説明できず、クライアントの好みで構造が崩れる
設計フェーズの本質的な価値は、正解を出すことではありません。後から誰かが「なぜこうなっているのか」と問うたときに、答えが残っている状態をつくることです。理由が残っていれば、前提が変わったときに構造を安全に組み替えられます。
設計の前にクライアントから引き出す5つの情報
設計は、材料が揃っていなければ始められません。しかしクライアントは「何を伝えるべきか」を知りません。こちらから具体的に聞き出す必要があります。
1｜サイトの目的と、達成したかどうかの判定方法
「認知を広げたい」で止めず、何がどうなれば成功なのかまで踏み込みます。問い合わせ件数なのか、採用応募なのか、既存顧客の問い合わせ削減なのか。この一点で、トップページに何を置くかが変わります。
2｜想定ユーザーと、その人の現在地
属性ではなく、サイトに訪れる直前に何をしていた人かを聞きます。検索して初めて社名を知った人と、名刺を受け取って確認しに来た人では、必要な情報の順番がまるで違います。
3｜既存サイトの資産と負債
リニューアル案件では、既存ページのうち何が読まれ、何が読まれていないかを確認します。アクセス解析の閲覧権限を早い段階でもらえるかどうかが、設計の精度を大きく左右します。
4｜公開後の運用体制
誰が、どのくらいの頻度で更新するのか。更新担当者が1人でパソコン操作に不慣れなら、更新頻度の高いページを増やす設計は破綻します。運用できない構造は、設計として失敗です。
5｜動かせない制約条件
公開日、予算、既存システムとの連携、ドメインの扱い。これらは設計の自由度を直接縛ります。最後に発覚すると全てが壊れるため、最初に確認します。
| 聞くこと | 質問の例 | 設計への影響 |
|---|---|---|
| 目的と判定基準 | 公開半年後、何がどうなっていれば成功ですか | トップページの最上部に置く要素が決まる |
| ユーザーの現在地 | 訪問者は御社をどこで知って来ますか | 導線の起点と、必要な説明の深さが決まる |
| 既存の資産 | 今よく読まれているページはどれですか | 残すページ、統合するページの判断ができる |
| 運用体制 | 公開後は誰が、月に何回更新しますか | CMS化する範囲と階層の深さが決まる |
| 制約条件 | 絶対に動かせない条件は何ですか | 設計の選択肢そのものが絞られる |
情報設計の手順｜棚卸しからサイトマップまで4ステップ
材料が揃ったら、情報を構造に変えていきます。いきなりサイトマップを描き始めるのではなく、必ず棚卸しから入ります。
- 棚卸し：載せる可能性のある情報を、粒度を気にせず全て書き出す
- グルーピング：似たものを寄せ、グループに名前をつける
- 階層化：グループ間の親子関係と優先順位を決める
- サイトマップ化：ページ単位に落とし、一覧表として固定する
ステップ1｜情報の棚卸しは、削らずに広げる
この段階で取捨選択を始めると、無意識に既存サイトの構造をなぞってしまいます。既存ページ、営業資料、よくある問い合わせ、社内にしかない情報まで、まずは全て並べます。
ステップ2｜グルーピングは「作り手の都合」で切らない
最も陥りやすい失敗が、組織図をそのままサイト構造にしてしまうことです。訪問者は部署名を知りません。分類の軸は、作り手の都合ではなく訪問者の探し方に合わせます。付箋やカードに情報を書き出し、実際に並べ替えてみると、グループの切れ目が見えてきます。
ステップ3｜階層化では、優先順位を必ず一列に並べる
「どれも重要です」というクライアントの言葉を、そのまま受け取ってはいけません。同列に並んだ要素は、結局どれも目に入りません。順位を1位から並べきる作業に、クライアントを巻き込みます。
ステップ4｜サイトマップは、一覧表として固定する
図としてのサイトマップは全体像の共有に向きますが、実装と見積りの基準になるのは表形式のページ一覧です。ページ名、階層、URL、目的、担当、参照元の情報源を列に持たせておくと、そのまま進行管理表として使えます。
ページ一覧が確定した瞬間が、見積りとスケジュールを固定できる唯一のタイミングです。ここを曖昧にしたまま次に進むと、以降の追加要望に対して「当初の範囲外です」と言う根拠を失います。
階層・URL・ナビゲーションの設計ルール
構造が見えてきたら、実装に耐えるルールへ落とします。ここで決めたことは、公開後に変更するコストが跳ね上がるため、慎重に固めます。
階層は浅く、ただし「浅ければ良い」ではない
目的のページまで少ないクリック数でたどり着けるほうがよい、というのは制作現場で長く共有されてきた目安です。ただしこれは絶対的な法則ではありません。階層を無理に浅くしようとして、トップページのメニュー項目が20個並べば、かえって選べなくなります。階層の深さと、一画面あたりの選択肢の数は、トレードオフの関係にあります。
URLは構造を映し、短く、そして変えない
URLは公開後に変えると、外部からのリンクも、既存の評価も断ち切ることになります。日付や社内コードのように後から意味を失うものは含めず、階層構造をそのまま反映した短い文字列にします。
ナビゲーションは「今どこにいるか」に答えるもの
ナビゲーションの役割は、行き先を並べることだけではありません。訪問者が現在地を把握し、来た道を戻れる状態をつくることが本質です。パンくずリストや、現在地の強調表示が効くのはこのためです。
| 対象 | 設計のルール | よくある失敗 |
|---|---|---|
| 階層 | 深さと選択肢の数のバランスで決める | 浅さを優先し、メニュー項目が過剰になる |
| URL | 階層を反映し、短く、公開後は変えない | 日付や連番を含め、後から意味を失う |
| グローバルナビ | 訪問者の目的単位で並べる | 社内の組織名や部署名をそのまま使う |
| パンくず | 階層構造と完全に一致させる | 導線の履歴と混同し、階層とずれる |
| フッター | 網羅性を担保し、探し漏れを受け止める | グローバルナビの単なる複製になる |
こうした設計判断は、経験した案件の規模や業種の幅に比例して精度が上がります。要件定義から関われる案件に継続的に入れるかどうかは、フリーランスにとってスキルの伸びを左右する条件です。
フリーランスエージェント9社を比較｜案件の幅・単価・サポートの違い ›ワイヤーフレームへの落とし込みと、やってはいけないこと
サイトマップが縦の構造だとすれば、ワイヤーフレームは各ページの中身、つまり横の構造です。ここで決めるのは配置と優先順位であって、見た目ではありません。
ワイヤーフレームで決めること、決めないこと
| ワイヤーフレームで決めること | ここでは決めないこと |
|---|---|
| 要素の配置と、上から下への優先順位 | 配色、書体、装飾のトーン |
| 各要素に入る情報の種類と、おおよその分量 | 写真やイラストの最終的な選定 |
| 次のページへの導線と、その文言 | アニメーションや細かな動きの表現 |
| 画面幅が狭いときの並び替え方針 | 余白の具体的な数値 |
失敗1｜ワイヤーフレームでデザインを始めてしまう
枠線を整え、色を置き始めた瞬間から、クライアントの意識は構造ではなく見た目に移ります。「このボタンの色が気になります」という感想が返ってきたら、それはワイヤーフレームが作り込まれすぎているサインです。
失敗2｜仮の文字を入れたまま合意してしまう
意味のないダミー文字で埋めたまま承認をもらうと、実際の原稿が入った途端に破綻します。少なくとも見出しと導線の文言は、実際に使う文言の案を入れておきます。文章の長さは、そのままレイアウトの制約条件です。
失敗3｜画面幅が狭いときの想定を後回しにする
多くのサイトで、訪問の主戦場は狭い画面です。広い画面での配置だけを決めて進めると、実装段階で要素の優先順位を決め直すことになります。要素の縦一列の並び順は、設計段階で確定させておきます。
ワイヤーフレームの段階で発生する「ページを1枚追加したい」「この要素も入れたい」という要望は、実装工数に直結します。追加が当初の作業範囲に含まれるのか、別途の見積りになるのかは、設計フェーズに入る前に契約で明確にしておく必要があります。
設計フェーズを守る｜提出物・合意形成・契約上の注意
設計は、成果物が目に見えにくい工程です。だからこそ、フリーランスにとっては報酬が削られやすく、無限の修正に飲み込まれやすい場所でもあります。
提出物と、承認をもらうタイミングを分ける
ページ一覧とワイヤーフレームを一度にまとめて出すと、クライアントは両方を同時に判断できません。まずページ一覧で承認をもらい、それを固定してからワイヤーフレームに進む。この二段階を守るだけで、手戻りの範囲は劇的に小さくなります。
修正回数と、範囲外要望の線引きを先に決める
「修正は3回まで」「ページ追加は1枚あたり別途見積り」のように、着手前に基準を文字にしておきます。基準がない状態で断ると角が立ちますが、事前の合意があれば単なる確認作業になります。
確認しておきたいチェックリスト
- 設計フェーズの報酬が、実装費と分けて計上されているか
- ページ一覧の承認をもって、範囲が確定する旨が書かれているか
- 修正回数の上限と、上限を超えた場合の扱い
- 成果物（サイトマップ・ワイヤーフレーム）の著作権と二次利用の範囲
- 案件が途中で中止になった場合、既に完了した工程の報酬はどうなるか
- 報酬の支払期日と、検収の条件
2024年11月に施行されたフリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）により、発注事業者には業務の内容や報酬額などの取引条件を書面等で明示する義務が課されています。報酬の支払期日は原則として成果物を受領した日から起算して60日以内、一定の継続的な業務委託を中途解除する際は原則30日前までの予告が必要とされています。ただし、個別の契約が法の適用対象にあたるか、成果物の権利がどちらに帰属するかといった判断は事情によって異なります。契約書の内容に不安がある場合は、弁護士や関係する相談窓口など専門家への相談を検討してください。
まとめ｜設計とは、決めた理由を残す工程である
優れたサイト設計は、完成物を見ただけでは評価されません。評価されるのは、公開の半年後、クライアントが「ここに新しいページを足したい」と言い出したときです。設計に理由が残っていれば、構造を壊さずに足せます。残っていなければ、その場しのぎの継ぎ足しが始まり、サイトは少しずつ崩れていきます。
サイト設計は、要件定義とデザインの間で「どんなページを、どう並べ、何を載せるか」を決める工程。着手前に、目的と判定基準・ユーザーの現在地・既存の資産・運用体制・制約条件の5つを引き出す。情報設計は棚卸し、グルーピング、階層化、サイトマップ化の4ステップで進め、分類は作り手の都合ではなく訪問者の探し方に合わせる。階層の浅さと選択肢の数はトレードオフであり、URLは公開後に変えない。ワイヤーフレームでは配置と優先順位だけを決め、見た目には踏み込まない。そして設計フェーズは、ページ一覧の承認・修正回数・権利帰属を契約で固めることで守る。
設計の判断力は、扱った案件の規模と業種の幅がそのまま蓄積になります。実装だけを切り出して請ける案件が続くと、設計の経験は増えません。上流から関われる案件に届く環境にいるかどうかを、一度確認してみる価値があります。
