Columnお役立ちコラム

企画フェーズは目的とペルソナ設計が命

田中智子さん（仮名）がこの物語の主人公です。
ある日、部長から突然こう言われたそうです。

「今度のWebサイトのリニューアル、田中さんに任せるから」

「えっ…私が？」

Webの専門知識もそこまでない田中さん。
でもマーケティング部の責任者ということで、サイト全体の企画からベンダーとのやり取りまで、すべて仕切ることに。

ここから、田中さんの“Webリニューアル奮闘記”が始まります。

Web制作のスタートは「目的の言語化」

Webサイトの制作は、デザインやシステムから始めるものではありません。
一番最初にやるべきことは「このサイトで何を実現したいのか」を明文化することです。

企業サイトなのか、サービス紹介サイトなのか。
商品購入につなげたいのか、問い合わせを増やしたいのか。

目的がブレると、どんなにお金をかけても効果が出ない「かっこいいだけのWebサイト」になってしまいます。
しかも、そのブレはあとでサイト構成や導線設計にも悪影響を及ぼします。

ペルソナとカスタマージャーニーはセットで考える

目的がはっきりしたら、次は「誰のためのサイトなのか」を定義していきます。
ここで必要になるのが「ペルソナ設計」です。

ペルソナとは、サービスを利用してほしい理想的な顧客像を“ひとりの人物”として描き出すもの。

たとえば「30代女性・子育て中・情報収集はInstagram中心・時短志向」など、具体的に落とし込みます。
この情報をもとに、コンテンツの順序やナビゲーション設計が決まってきます。ただし、ペルソナだけで終わらせてはいけません。
その人物がどういう過程でサイトにたどり着き、どう行動するか──それを「カスタマージャーニー」として描き出すと、より立体的になります。

社内ヒアリングは“部署別の視点”がカギ

筆者もよく聞かれるのが、「社内の誰にヒアリングすればいいですか？」という質問です。
答えはズバリ、「営業・広報・技術」の3部署です。

• 営業：お客さんと一番近い立場。現場の“リアルな声”が取れる。
  
• 広報：ブランドメッセージや会社の空気感を言語化してくれる。
  
• 技術・システム部門：セキュリティやCMS制限など、見落としがちな“実装の壁”を早期に把握できる。
  

それぞれが持つ情報はバラバラですが、これを“企画フェーズ”でまとめておくと、後の段階でブレにくくなります。
しかも、社内全体が「このプロジェクトは自分ごと」として参加してくれるようになります。

ありがちな失敗例：「誰向けか曖昧」なまま進める

実際にありがちなのが、「ターゲットが曖昧なまま制作が進行してしまうケース」です。

筆者の過去の案件でも、経営陣の「とにかく格好よく！」という声だけでデザインを決めたプロジェクトがありました。
結果として、ユーザーが本当に知りたかった情報が見つけにくくなり、問い合わせ数はむしろ減ってしまいました。

Webサイトは「社内の自己満足の場」ではなく、「ユーザーの行動を導く装置」です。
そのためにも、企画フェーズの“言語化”と“理解の共有”が最も重要になります。

構成と設計で9割が決まる！要件定義のコツ

Webサイト制作において「設計が9割」ってよく言われます。
実は、ほんとにその通りです。

デザインやコーディングはあくまで“形にする工程”なので、土台がグラついてたら全部が崩れます。
この章では、田中智子さん（仮名）のように社内で責任者を任された方が**実務で役立つ「設計と要件定義の具体策」**をしっかりお伝えします。

要件定義は「やりたい」と「できる」のすり合わせ

要件定義とは、「サイトでやりたいこと」と「技術的・人的にできること」をすり合わせる作業のことです。

田中智子さんのように社内で要件をまとめる立場になると、上司からは「あれも入れたい」「この機能もつけよう」と希望がわんさか飛んできます。

でも、それらを全部のせすると開発コストもスケジュールも爆発します。

なので、「誰が何の目的で使うのか？」を軸に、優先順位をはっきりさせることが超重要です。
欲しい機能やページを「MUST／WANT／OPTION」で分類すると、制作会社との話もかなりスムーズになります。

サイトマップとワイヤーフレームの違いとは？

設計フェーズに入ると、サイトマップとワイヤーフレームという2つのキーワードが登場します。
初心者の方だと混同しやすいんですが、意味も使い方も全然違うものなんです。

• サイトマップ（構成図）：ページの階層構造を示した図。Webサイト全体の“骨組み”にあたる。
  
• ワイヤーフレーム：各ページ内の要素（メニュー、見出し、ボタン等）の“配置図”。
  

たとえるなら、サイトマップは「マンションの設計図」、ワイヤーフレームは「各部屋の家具配置図」みたいなイメージです。
ここを明確にすることで、後工程のデザイン・コーディングも迷わず進められます。

要件定義から設計図へ：業務フローを公開！

以下が、筆者が実務で使っている設計フローの一例です。

• 要件シートの作成（目的・機能・必要ページをまとめる）
  
• サイトマップ作成（ページ構成・階層・導線の設計）
  
• ワイヤーフレーム作成（主要ページだけでもOK）
  
• 社内での承認フロー（上層部・関係部門に説明）
  

この時点で「誰に、何を、どう伝えるか」がクリアになっていれば、制作会社に渡す資料としても十分に戦えるレベルになります。

サイト構成の基本は「王道3ページ」

サイトの構成って、実はそんなに難しくありません。
特にコーポレートサイトやサービス紹介サイトなら、王道の3ページ構成から考えればOKです。

• トップページ：会社やサービスの顔。流入からの導線設計が重要。
  
• サービス紹介ページ：訪問者が本当に知りたい情報をまとめる場所。
  
• お問い合わせページ：コンバージョン（行動）につなげるための出口。
  

ここに「会社概要」や「FAQ」などを追加していく形で設計していくと、自然とサイト全体がまとまっていきます。
あれもこれもと詰め込むより、「ユーザーの行動動線」を軸に設計する方が断然うまくいきます。

スマホファーストは設計段階から考えるべし

2025年現在、ほとんどのWebサイトはスマホ経由の閲覧が主流です。
にもかかわらず、設計段階でスマホ表示を軽視してしまうケース、まだまだあります。

筆者が推奨しているのはモバイルファースト設計です。

つまり、最初から「スマホでどう見せるか？」を基準に設計する。余計な要素を削ぎ落とし、必要最低限の情報を整理してからPC版に展開していく。
この順番が、結果的にユーザーにもやさしく、開発効率も良くなります。

デザイン工程は目的とユーザー視点で決まる

デザインって聞くと、「センスがいい人の仕事でしょ？」と思われがちなんですが……それ、ぜんぜん違います。

筆者はプロのWebコーダーとして何十件も現場に関わってきましたが、デザインはセンスじゃなくて戦略の言語化です。
しかも、戦略の軸にあるのは「目的」と「ユーザー視点」。

この章では、田中智子さん（仮名）のようにWeb制作を任されたけど「デザインってどう関わればいいの？」と迷う人のために、実務で役立つ考え方を整理していきます。

デザインは「情報設計をどう見せるか」の手段

まず最初にお伝えしたいのが、「デザインは表面的な装飾じゃない」ということ。
伝えたい情報を、誰に・どう見せるかを設計する手段です。

たとえば、企業サイトで「採用」を重視したい場合。
ファーストビューに社員の笑顔や社内風景を配置するのは、ただの“おしゃれ”じゃなくて情報の優先順位を視覚化しているわけです。

目的がしっかり言語化されていれば、自然とデザインに一貫性が出ます。
逆に、「とりあえずかっこよく」では、あとで破綻します。

“雰囲気”は言葉じゃなく素材で伝える

制作会社や外部デザイナーとやり取りするとき、「このサイト、どういう雰囲気にしたいか」って必ず聞かれます。

このとき、言葉だけで伝えるのは危険です。
「スタイリッシュに」「ナチュラルで」「信頼感のある感じ」……抽象的すぎて、受け取り手によってイメージが変わっちゃいます。

筆者がよくおすすめするのは、参考サイト集とムードボードの活用。

• 気に入ったデザインのURLを5～10個ほどピックアップ
  
• 配色、写真、余白感、レイアウトのどこが好きかを一言添える
  
• それをGoogleスライドやNotionに貼って共有
  

これだけでも、イメージのすり合わせ精度がかなり上がります。

色とフォントは“好き”じゃなくて“快適さ”で選ぶ

「好きな色で作りたい」って気持ち、すごくよく分かります。
でもWebデザインにおいては、「誰にとって心地よいか」が最優先。

たとえば、医療系のサイトで黒背景＋蛍光色の文字だと、読みにくくて不安になります。
反対に、ECサイトならコントラストを強めて「買いたい」気持ちを後押しする配色が有効です。

フォントも同様。
日本語は明朝体よりゴシック体の方がスマホでも視認性が高いことが多く、可読性を意識するのが基本です。

NG例：「もっとオシャレに」だけでは伝わらない

制作会社やデザイナーにフィードバックするとき、「なんかイマイチ」「もっとオシャレにして」とだけ伝えてませんか？

これ、最も伝わらないフィードバックの代表です。
なぜなら、“どこが・なぜ”が抜けてるからです。

たとえば、「トップの画像が伝えたい印象とズレている」「この色だと堅い印象になりすぎる」など、“目的とのギャップ”を理由として説明すると、一気に精度が上がります。デザインは感性の仕事に見えて、ロジックで進めた方が迷いがなくなるんです。

修正指示には“言語化された理由”を添える

修正指示を出すときは、できるだけ「感覚」ではなく「理由」を添えるようにしましょう。

たとえば、
「メインビジュアルのテキストが読みにくい → 背景とのコントラストが足りないため」
「CTAボタンが目立たない → 他の要素と視覚的な差が少ない」

このように“なぜそう感じるのか”を明確にすると、制作側も納得しやすく、対応も早くなります。
これは筆者の経験上100％断言できます。

コーディングと公開の裏側、何が起きてる？

田中智子さん（仮名）のようにWeb制作の進行管理を任されたとき、
「コーディングって、何をしてるのかサッパリわからない…」ってこと、あるあるです。

でも安心してください。
コードが書けなくても、工程の“仕組み”を知っておくだけで、確認力も信頼度もグッと上がります。

この章では、制作の最終局面となる「コーディング」と「公開」について、実務視点で舞台裏をご案内します。

コーディングとは、設計図を動かす職人技

コーディングというのは、企画・設計・デザインで決めた設計図を、実際にWeb上で動くカタチに落とし込む作業です。

ここで主に使われるのが「HTML」「CSS」「JavaScript」という言語たち。
それぞれの役割はざっくりこんな感じです。

• HTML：Webページの骨組み（見出しや段落、画像の配置など）
  
• CSS：その骨組みにデザインを着せる（色・サイズ・配置など）
  
• JavaScript：ページに動きをつける（ボタンを押したら表示が変わるなど）
  

つまり、コーディングって、料理でいえば設計図（レシピ）を見ながら材料を切って、火加減を調整して、皿に盛る作業みたいなものです。
派手じゃないけど、ここが一番丁寧さと正確さが問われます。

CMSって結局なに？ざっくり解説

最近のWebサイトでは、更新作業の効率化のためにCMS（コンテンツマネジメントシステム）が使われることが多くなっています。

一番有名なのは「WordPress（ワードプレス）」というCMSで、世界中のWebサイトの4割以上で使われていると言われています。

CMSのメリットは、コーディングの知識がなくてもページ更新ができるところ。
画像の差し替えや、テキスト修正もブラウザ上で完結します。

田中智子さんのような担当者にとっては、納品後の「自分たちで触れる範囲」が広がるのがCMSの魅力です。

外注・制作会社と確認すべきチェックポイント

コーディングが進みはじめると、非エンジニアの田中智子さんにもやってほしい「確認ポイント」があります。
それがこの3つ。

• レスポンシブ対応（スマホ・タブレット・PCで表示が最適化されるか）
  
• 主要ブラウザでの表示チェック（Chrome、Safari、Edge、Firefox）
  
• 表示速度や画像の読み込み最適化（Lighthouseなどのツール活用）
  

特にスマホ表示は多くの訪問ユーザーにとってのファーストビューになるため、
ボタンが小さすぎないか、テキストが読みやすいかなど、実機でのチェックが大切です。

公開前にチェックするべき“地味だけど大事”なこと

いざ公開直前になると、焦って忘れがちなポイントがいくつもあります。
下記の項目は、最終チェックリストとして保存推奨です。

• リンク切れがないか（内部・外部リンク）
  
• 画像が正しく表示されているか（特にスマホ）
  
• テキストに誤字脱字がないか
  
• SEO初期設定（タイトルタグ・メタディスクリプション・alt属性など）
  
• OGP設定（SNSでシェアされたときの画像やタイトル）
  

地味ですが、このあたりを押さえるだけで、「ちゃんとしてる感」がぐっとアップします。
細かい気遣いが、結果的に成果に直結するんです。

公開して終わり…じゃなくて、ここがスタートライン

よくある誤解が「サイト公開＝プロジェクト完了」というもの。
でも、実際はここからが本番です。

アクセス解析を導入してユーザーの行動を見たり、
改善ポイントを洗い出してページのABテストをしたり、
「どう運用するか」が成果を左右します。

田中智子さんのように、社内で責任者を担う方こそ、公開後の“育てる視点”を持っておくと、プロジェクトの成功率がグッと上がります。

今回は、普段は見えにくい「コーディングと公開」の裏側を紹介しました。
実際の工程がわかると、「ただ任せる」のではなく、「自分もプロジェクトの一員として関われる」感覚が出てくるはずです。次はいよいよ最終章。
田中智子さんのプロジェクトの“まとめとその後”をお届けします！

まとめと感想｜田中智子さんの一歩が変わる

ここまで、田中智子さん（仮名）がWebサイトリニューアルの責任者として歩んできたステップを一緒にたどってきました。
最初は「え？ 私が担当…？」と戸惑っていた田中さんも、
今では「全体の流れ」がつかめたことで、関係者との調整もずいぶんラクになったそうです。

Web制作は「全体像」が見えれば怖くない

Webサイト制作って、たしかに専門用語や工程が多くて取っつきにくいところがあります。
でも、全体の流れを6つのステップに分解して順に見ていけば、不安はどんどん小さくなります。

• 企画（目的とペルソナを決める）
  
• 設計（要件定義・構成・ワイヤーフレーム）
  
• デザイン（ユーザー視点で伝える）
  
• コーディング（設計図を形にする）
  
• テスト（動作・表示・SEOを確認）
  
• 公開・運用（育てて成果に変える）
  

どの段階でも、必要なのは「自分で全部やること」じゃなくて、内容を理解して、正しく関わることなんです。

最初に立ち返る。「誰のため？ なぜ作る？」

どんなにステップが進んでいても、常に振り返ってほしいのがこの問いです。

• 誰に届けるためのサイトか？
  
• どんな行動をしてもらいたいのか？
  
• 企業として、何を一番伝えたいのか？
  

この軸がブレてしまうと、完成したサイトもなんだかぼんやりした存在になってしまいます。
でも、この軸さえ守れていれば、多少のデザイン変更や構成見直しもブレないまま進められます。

実際に筆者も、設計や開発の最中に何度も「そもそも目的って何だったっけ？」と立ち返ることがあります。
それが“いいWebサイト”になる第一条件なんです。

“非エンジニア責任者”こそ、流れを知って強くなる

田中智子さんのように、マーケティング部や広報などの“非エンジニア”がプロジェクト責任者になるケース、今ほんとに増えてます。
でもそれって、Web制作が「専門家だけの仕事」から「組織全体の課題解決ツール」になってきた証拠なんですよね。

コーディングができなくても、Figmaが触れなくても大丈夫。
大切なのは、「流れを知って判断できること」「共通言語で話せること」。
それだけで、ベンダーとの関係性も、社内の巻き込み力も段違いに変わってきます。

最後に。この記事を読んだあなたが、次にやるべきこと

さて、ここまで読んできたあなたには、もう「Web制作ってよくわからないし不安…」とは言わせません（笑）

でも、読んだだけで終わらせずに、今このタイミングで“次の一歩”を踏み出すことが一番大切です。
たとえばこんなアクション、今からできます：

• 企画フェーズ用のペルソナシートを1つ作ってみる
  
• 社内メンバーにヒアリングをはじめてみる
  
• サイトマップのラフ案をNotionやスプレッドシートで描いてみる
  
• 制作会社との打ち合わせに「質問リスト」を用意して臨む
  

小さな一歩でかまいません。
それが、Webサイトを“作る”ことじゃなくて、“動かす”ことにつながります。

最後に筆者から

Web制作は、全体の流れを知ってしまえば、そんなに怖いものではありません。
むしろ、社内を巻き込んで「一つの目的に向かって走るチーム作り」のチャンスにもなります。

田中智子さんのように、初めての挑戦でも堂々と進めるために。
この記事が少しでも背中を押せたなら、筆者としてもうれしいかぎりです。

Webサイトづくり、ぜひ楽しんでくださいね！