端末の設定に合わせて配色を切り替えるダークモードは、対応するサイトが増えています。ただし企業サイトの場合、対応の必要性は商材と訪問者の性質によって大きく変わります。
対応すると確認する画面が実質的に倍になります。配色、写真、図版、影の表現をそれぞれ2通り用意し、両方で検証する必要があるためです。この工数に見合うかを先に判断してください。
この記事では、対応が必要な条件、色を反転させるだけでは成立しない理由、部分的に対応する方法、そして確認すべき箇所を整理します。
この記事でわかること
・対応すると確認する画面が実質的に倍になる
・必要性は訪問者の利用状況で決まる
・色を反転させるだけでは成立しない
・写真と図版が最も崩れやすい
・部分的に対応する選択肢がある
・対応しない判断も明示的に行う
対応すると確認する画面が倍になる
工数が増えるのは、デザインだけでなく検証の側です。
| 工程 | 増える内容 |
|---|---|
| 配色の設計 | 2通りの組み合わせを決める |
| 写真の準備 | 背景が明るい画像の扱いを決める |
| 図版の作成 | 線や背景を切り替え可能にする |
| 実装 | 切り替えの仕組みを入れる |
| 検証 | 全ページを2通りで確認する |
| 運用 | 追加のたびに2通りで確認する |
最も負担が大きいのは最後の行です。公開後にページを追加するたび、2通りの確認が必要になります。運用の体制がないと、片方だけ崩れた状態が放置されます。
運用のしやすさは更新しやすい企業サイトの作り方|CMS選定と運用設計のポイント、一貫性の保ち方はUIの一貫性はなぜ成果に効くのか|崩れる原因と、揃えるべき範囲を参照してください。
増えるのはデザインより検証と運用の工数。
追加のたびに2通りの確認が必要になる。
必要性は訪問者の利用状況で決まる
対応の価値は、訪問者がどのような状況でサイトを見るかによって変わります。
| 状況 | 対応の価値 | 理由 |
|---|---|---|
| 長時間読む(記事、資料) | 高い | 目の負担が軽減される |
| 夜間や暗所での閲覧が多い | 高い | 明るい画面がまぶしい |
| 繰り返し訪れる | 中程度 | 設定が反映される体験が続く |
| 数分で判断して離れる | 低い | 効果を体感する時間がない |
| 日中の業務中に見る | 低い | 明るい環境で見ている |
企業サイトの多くは、下2行に該当します。検討中に数回訪れて数分ずつ見るという使われ方では、対応の効果を体感する場面がほとんどありません。
一方、記事を継続して読ませる構成であれば、対応の価値が出てきます。
長時間読ませるサイトでは価値がある。
数分で判断して離れるサイトでは効果が薄い。
色を反転させるだけでは成立しない
明るい配色をそのまま反転すると、読みにくく、印象も変わります。
- 暗い背景に白い文字を置くと、文字が滲んで見える(太さを下げる調整が要る)
- 彩度の高い色は、暗い背景で強く目立ちすぎる
- 影による立体感が効かなくなる(明るさの差で表現し直す)
- 明度差を保っても、実際の見え方は変わる
- ブランドの色が、暗い背景では別の印象になる
結果として、2通りの配色をそれぞれ設計する必要があります。反転の自動処理で済ませると、可読性が落ちます。明度差の基準は配色のコントラスト比の基準|WCAGの数値と、実務での使い方を参照してください。
反転の自動処理では可読性が落ちる。
2通りの配色を、それぞれ設計する必要がある。
写真と図版が最も崩れやすい
配色は調整できても、素材の側は簡単に切り替えられません。
| 素材 | 起きる問題 | 対応 |
|---|---|---|
| 背景が白い写真 | 白い四角が浮いて見える | 背景を透過するか、切り抜く |
| 黒い線の図版 | 背景に溶けて見えなくなる | 2通り用意する |
| ロゴ | 暗い背景で判別できない | 背景が濃い場合の形を用意する |
| スクリーンショット | 明るいまま浮く | 枠を付けるか、両方用意する |
| アイコン | 色が沈む | 明度を調整した版を作る |
特にスクリーンショットは対処が難しい箇所です。元の画面が明るい配色である以上、暗い背景では浮きます。枠や余白で違和感を減らす方法が現実的です。
ロゴの展開についてはロゴの種類と選び方|社名だけか、シンボルを持つかで運用が変わるを参照してください。
配色より、写真と図版のほうが対処が難しい。
スクリーンショットは浮くため、枠や余白で調整する。
部分的に対応する選択肢
全ページを対応させる以外に、範囲を限定する方法があります。
| 範囲 | 対象 | 工数 |
|---|---|---|
| 記事ページのみ | 長時間読む箇所 | 小さい |
| 主要ページのみ | トップと事業紹介 | 中程度 |
| 全ページ | サイト全体 | 大きい |
| 対応しない | 従来どおり | なし |
記事ページだけの対応は、費用対効果が読みやすい選択です。長時間読む箇所に絞れば、素材の問題も限定されます。ただしページ間で挙動が変わるため、その点は許容できるかを確認してください。
記事ページだけに絞ると、費用対効果が読みやすい。
ページ間で挙動が変わることは許容できるか確認する。
対応しない判断も明示的に行う
対応しない場合でも、暗い設定の端末で見たときの状態は確認してください。
- 端末を暗い設定にして、主要なページを開く
- 意図せず一部だけ暗くなっていないか確認する
- 入力欄の文字が見えなくなっていないか確認する
- 問題があれば、明るい配色に固定する指定を入れる
- その判断を記録に残す
意図せず一部だけ切り替わる状態が、最も見づらくなります。特に入力欄は、端末側の設定で見た目が変わることがあります。対応しないなら、明示的に固定するほうが安全です。
フォームの確認は入力フォームの離脱率を改善するデザインの工夫|商談化まで見た設計も参照してください。
意図せず一部だけ切り替わる状態が最も見づらい。
対応しないなら、明るい配色に固定する指定を入れる。
確認すべき箇所
対応する場合、崩れが出やすい箇所を優先して確認してください。
| 箇所 | 確認する内容 |
|---|---|
| 入力欄とボタン | 文字と背景の明度差 |
| 表 | 罫線が見えるか |
| リンク | 本文と区別できるか |
| エラー表示 | 警告色が沈んでいないか |
| 写真の周囲 | 白い縁が出ていないか |
| 印刷時 | 暗い配色のまま印刷されないか |
印刷の確認は見落とされがちです。暗い配色のまま印刷されると、インクを大量に消費し読めない紙が出ます。印刷用の指定を別に用意してください。
入力欄、表、リンクの明度差を優先して確認する。
印刷時に暗い配色のまま出力されないか確認する。
他の要素との順序
デザインの各要素には依存関係があり、決める順序が結果を左右します。この要素が全体のどこに位置するかはWebデザインの構成要素はどの順で決めるかを参照してください。
よくある失敗
色を自動で反転させて済ませる
可読性が落ちます。2通りの配色をそれぞれ設計してください。
写真と図版の対応を後回しにする
配色より対処が難しい箇所です。素材の準備を含めて工数を見積もってください。
運用の体制を決めずに対応する
追加のたびに2通りの確認が必要です。体制がないと片方が崩れたまま残ります。
対応しない場合に何も確認しない
意図せず一部だけ切り替わることがあります。明示的に固定してください。
印刷時の見え方を確認しない
暗い配色のまま印刷されると、読めない紙が出ます。
よくある質問
対応していないと評価が下がりますか
検索での評価に直接影響するという公式の記載はありません。ただし読みにくい状態が放置されていれば、離脱として現れます。対応の有無より、どちらの設定でも問題なく読めることが重要です。
切り替えるボタンを設置すべきですか
端末の設定に従うだけでも成立します。ボタンを置く場合、選択を記憶する仕組みが必要になり、実装が増えます。まず端末設定への追従から始めるのが現実的です。
既存サイトに後から追加できますか
可能ですが、配色が変数として整理されていない場合、全ページの見直しに近い工数がかかります。次のリニューアルで検討するほうが効率的なこともあります。
どのくらいの割合の人が使っていますか
端末や年齢層によって差があり、一律の数値は示せません。自社サイトの利用状況を推定したい場合、アクセス解析で判別できるかを確認してください。ただし取得できないこともあります。
メールマガジンでも対応が必要ですか
メールのアプリが独自に配色を変えることがあり、意図と異なる表示になる場合があります。特に画像の背景が白い場合に浮きます。配信前に、暗い設定の端末で確認してください。
まとめ
ダークモード対応は、対応するサイトが増えている一方で、企業サイトにおける必要性は商材と訪問者の性質によって大きく変わります。対応すると確認する画面が実質的に倍になり、特に公開後はページを追加するたびに2通りの確認が必要になります。運用の体制がないと、片方だけ崩れた状態が放置されます。
価値が出るのは、記事のように長時間読ませる箇所や、夜間の閲覧が多い場合です。逆に、検討中に数回訪れて数分ずつ見るという使われ方では、効果を体感する場面がほとんどありません。多くの企業サイトは後者に該当します。
また、明るい配色をそのまま反転させるだけでは成立しません。暗い背景に白い文字を置くと文字が滲んで見え、彩度の高い色は強く目立ちすぎます。配色以上に対処が難しいのは写真と図版で、背景が白い画像は四角く浮き、黒い線の図版は背景に溶けます。対応しない判断をする場合も、暗い設定の端末で意図せず一部だけ切り替わっていないかは確認してください。
当社ではホームページ制作において、対応範囲の判断からご相談いただけます。デザイン面の検討はデザイン制作とあわせてご相談ください。
制作会社によって使用するデザインツールは異なります。発注する立場でこの違いが影響するのは、成果ではなく引き継ぎと確認の方法です。
どのツールを使っても、作れるものに大きな差はありません。差が出るのは、確認をどう行うか、データを引き継げるか、複数人で作業できるかといった運用面です。
この記事では、発注側に影響する観点、契約時に確認すべき項目、ツールを指定すべき場合、そして指定しないほうがよい場合を整理します。ツールの仕様や提供条件は変更されるため、詳細は公式の情報を確認してください。
この記事でわかること
・成果への影響は小さく、運用への影響が大きい
・確認すべきは確認方法と引き継ぎ
・ツールを指定すべき場合は限られる
・指定すると選べる制作会社が減る
・契約時に確認する項目
・移行を前提にしない設計にする
成果への影響は小さい
ツールの違いが公開後の成果に与える影響は限定的です。
| 観点 | ツールによる差 | 実際に影響するもの |
|---|---|---|
| デザインの質 | 小さい | 担当者の力量と要件の明確さ |
| 表示速度 | なし | 実装の方法と画像の扱い |
| 成約率 | なし | 情報設計と導線 |
| 確認のしやすさ | 大きい | 共有と指摘の方法 |
| 引き継ぎやすさ | 大きい | データの形式と説明 |
制作会社を選ぶ基準として、使用ツールの優先度は低くなります。実績、対応範囲、進め方のほうが影響します。
選定の観点はデザイン制作会社の選び方|見積り比較で確認すべきポイントを参照してください。
成果に影響するのは、ツールではなく担当者と要件の明確さ。
ツールが影響するのは、確認と引き継ぎの運用面。
確認方法への影響
発注側が実感するのは、デザインをどう見せてもらうかの違いです。
| 方式 | 発注側の負担 | 指摘のしやすさ |
|---|---|---|
| ブラウザで開いて確認 | 小さい | 該当箇所に直接書ける |
| 画像として送付 | 小さい | 位置を文章で伝える必要がある |
| 専用ソフトが必要 | 大きい | 導入の手間がかかる |
| 印刷して確認 | 中程度 | 実際の見え方が分からない |
ブラウザで開けて、該当箇所にコメントできる方式が最も負担が小さくなります。ツールの名称より、この形式で確認できるかを聞いてください。
確認の進め方はFigmaを発注側が使えるようになる意味|確認と指示のために覚える範囲を参照してください。
ツール名より、確認の形式を聞く。
該当箇所にコメントできる方式が、最も負担が小さい。
ツールを指定すべき場合は限られる
発注側からツールを指定する合理性があるのは、次の場合です。
- 社内に既存のデータがあり、それを引き継ぐ必要がある
- 社内で編集する予定があり、担当者が特定のツールしか使えない
- 複数の制作会社に依頼し、データを共有する必要がある
- 既に社内で契約しており、追加費用が発生しない
これらに該当しないなら、指定する必要はありません。制作会社が慣れたツールを使うほうが、作業の効率も品質も安定します。
既存データの引き継ぎや社内編集の予定がある場合のみ指定する。
該当しないなら、慣れたツールを使ってもらうほうがよい。
指定すると選べる制作会社が減る
ツールを条件にすると、候補が狭まります。
| 指定した場合 | 起きること |
|---|---|
| 対応できる会社が限られる | 選択肢が減る |
| 慣れていない会社が受注する | 作業効率が落ちる |
| 追加の費用が発生する | 契約の負担が増える |
| 対応可能でも品質が落ちる | 使い慣れていないため |
ツールを条件にして候補を減らすより、実績と進め方で選ぶほうが結果につながります。指定する場合は、その理由が費用と選択肢の減少に見合うかを確認してください。
ツールを条件にすると、候補が狭まる。
指定する理由が、選択肢の減少に見合うかを確認する。
契約時に確認する項目
ツール名より重要なのは、次の項目です。
- 制作したデータの所有者は誰か
- 契約終了時にデータを受け取れるか
- 受け取る形式は何か
- 他のツールで開けるデータも提供されるか
- 使用している外部の素材の利用条件はどうなるか
- 説明や規定は文書として残るか
データを受け取れても、開けなければ意味がありません。次の制作会社が扱える形式で提供されるかを確認してください。特に画像や書体の素材は、利用条件が引き継げないことがあります。
データを受け取れても、開けなければ意味がない。
外部素材の利用条件が引き継げるかも確認する。
移行を前提にしない設計にする
ツール間の完全な移行は難しいため、移行しなくても困らない状態を作ってください。
| 残すもの | 形式 | 理由 |
|---|---|---|
| 使用している色の値 | 文書 | どのツールでも再現できる |
| 書体の名称と太さ | 文書 | 同上 |
| 余白の基準値 | 文書 | 同上 |
| 部品の使い分けの基準 | 文書 | 意図が引き継げる |
| 画面の完成イメージ | 画像 | ツールに依存しない |
設計の意図が文書として残っていれば、ツールが変わっても再現できます。編集可能なデータが引き継げなくても、作り直す判断ができます。
文書化の範囲はブランドガイドラインの作り方|どこまで決めれば運用が回るかを参照してください。
設計の意図が文書として残っていれば、ツールが変わっても再現できる。
移行できることより、移行しなくても困らない状態を目指す。
社内で編集する場合の判断
社内での編集を予定している場合、別の観点が必要になります。
| 確認項目 | 理由 |
|---|---|
| 担当者が使えるか | 習得の時間が必要になる |
| 費用が継続的に発生するか | 利用形態によって変わる |
| 編集する範囲はどこか | 全部か、一部か |
| 誤って壊した場合に戻せるか | 履歴の機能があるか |
| 担当者が変わった場合はどうするか | 属人化を避ける |
社内で編集する範囲は、必要最小限に絞ってください。範囲が広いほど、習得の負担と事故の可能性が増えます。実務では、更新頻度の高い一部だけを社内で扱う形が現実的です。
サイトの更新体制は更新しやすい企業サイトの作り方|CMS選定と運用設計のポイント、内製化の判断はAIがあればデザインの外注は不要になるのか|依頼する側が判断すべきことを参照してください。
社内で編集する範囲は、必要最小限に絞る。
範囲が広いほど、習得の負担と事故の可能性が増える。
工程全体の中で見る
この工程の前後には、情報の分類と構造の設計があります。全体の流れは情報設計(IA)とは?わかりやすいサイト構成の作り方を参照してください。
よくある失敗
ツール名で制作会社を選ぶ
成果への影響は小さくなります。実績と進め方で選んでください。
理由なくツールを指定する
候補が減り、慣れていない会社が受注すると効率が落ちます。
データの所有者を確認しない
契約終了時に引き継げないことがあります。契約時に明確にしてください。
受け取る形式を確認しない
データを受け取れても、次の会社が開けなければ意味がありません。
設計の意図を文書に残さない
ツールが変わると再現できなくなります。色や余白の基準値は文書で残してください。
よくある質問
制作会社にツールを聞く必要はありますか
ツール名そのものより、確認をどのように行うか、データをどう受け取れるかを聞いてください。この2点が分かれば、名称は重要ではありません。
複数の会社に分けて依頼する場合はどうすべきですか
データを共有する必要があるなら、揃えたほうが効率的です。ただし各社が別々の範囲を担当し、成果物として画像や実装を受け取るだけなら、揃える必要はありません。
古いツールで作られた既存データはどうすべきですか
そのまま引き継ぐか、作り直すかの判断になります。移行に工数がかかる場合、次のリニューアルで作り直すほうが結果的に安くなることがあります。設計の意図が文書で残っていれば、作り直しの負担は小さくなります。
社内で編集できるようにすべきですか
更新頻度によります。頻繁に更新する箇所があるなら価値がありますが、年に数回であれば依頼するほうが総額は下がります。習得と維持の負担も考慮してください。
ツールの費用は誰が負担しますか
通常は制作会社ですが、社内で編集する場合は自社の負担になります。利用形態と条件は変更されることがあるため、契約前に確認してください。
まとめ
制作会社が使用するデザインツールの違いは、発注する立場では成果にほとんど影響しません。デザインの質は担当者の力量と要件の明確さで決まり、表示速度や成約率は実装と情報設計で決まります。ツールが影響するのは、確認をどう行うか、データを引き継げるかという運用面です。
したがって制作会社に聞くべきはツール名ではなく、確認をどのように行うか、そしてデータをどう受け取れるかの2点です。ブラウザで開けて該当箇所にコメントできる方式であれば、発注側の負担は小さくなります。またデータを受け取れても次の会社が開けなければ意味がないため、形式まで確認してください。
発注側からツールを指定する合理性があるのは、既存データの引き継ぎや社内編集の予定がある場合に限られます。指定すると対応できる会社が減り、慣れていない会社が受注すれば効率も品質も落ちます。より重要なのは、色や余白の基準値、部品の使い分けといった設計の意図を文書として残しておくことです。これがあれば、ツールが変わっても再現できます。移行できることより、移行しなくても困らない状態を目指してください。
当社ではデザイン制作において、引き継ぎを前提とした進め方をご提案しています。既存データの扱いはお問い合わせよりご相談ください。
デザインの画面をつないで、実際に触れる状態にしたものをプロトタイプと呼びます。静止した画面を見るより、遷移や操作の流れを確認できる利点があります。
ただし作り込むほど工数がかかります。全画面の全操作を再現すると、実装に近い手間が発生します。それでいて、実装しないと分からないことは残ります。
この記事では、確認できる範囲、確認できないこと、目的から範囲を決める方法、そして発注側の関わり方を整理します。
この記事でわかること
・確認できるのは遷移と操作の流れ
・実装しないと分からないことは残る
・作る範囲は、確認したいことから決める
・全画面を再現する必要はない
・発注側は主要な導線だけ確認すれば足りる
・確認は実機で行う
確認できるのは遷移と操作の流れ
プロトタイプで判断できるのは、静止画では分からない動きの部分です。
| 確認できること | 静止画では | 有効性 |
|---|---|---|
| 画面の遷移順 | 分からない | 高い |
| 目的までの手数 | 数えにくい | 高い |
| 戻る操作の挙動 | 分からない | 高い |
| 選択肢を選んだ後の変化 | 分からない | 中程度 |
| 開閉する要素の見え方 | 分からない | 中程度 |
最も価値があるのは、目的までの手数を体感できることです。画面ごとに見ると問題なくても、通しで操作すると手数が多いと分かることがあります。
静止画では分からない、遷移と手数を確認できる。
画面ごとでは問題なくても、通すと手数が見える。
実装しないと分からないことは残る
プロトタイプで再現できない要素があります。これらは実装後に確認するしかありません。
| 確認できないこと | 理由 | 対応 |
|---|---|---|
| 実際の表示速度 | 読み込みが発生しない | 実装後に確認 |
| 実データでの見え方 | 想定の文字数で作られている | 長い内容で確認 |
| 入力時の挙動 | 実際の入力ができない | 実装後に確認 |
| 画面幅ごとの変化 | 固定の幅で作られる | 実装後に確認 |
| エラー時の表示 | 再現されないことが多い | 設計として別途確認 |
実データでの見え方は、特に見落とされます。プロトタイプでちょうど良く見えた見出しが、実際の文言で何行にもなることがあります。
表示速度、実データ、入力の挙動は再現できない。
実データでの見え方は特に見落とされる。
作る範囲は確認したいことから決める
何を確認したいかによって、必要な作り込みの度合いが変わります。
| 確認したいこと | 必要な範囲 | 工数 |
|---|---|---|
| 全体の構成 | 主要ページの遷移のみ | 小さい |
| 問い合わせまでの導線 | その経路の画面のみ | 小さい |
| 操作の分かりやすさ | 対象の操作を含む画面 | 中程度 |
| 利用者による検証 | 検証する経路を実際に動く形で | 中程度 |
| 全機能の確認 | 全画面と全操作 | 大きい |
最後の行を選ぶ理由は、ほとんどの場合ありません。実装に近い工数をかけるなら、実装してから確認するほうが確実です。
確認したいことに必要な範囲だけを作る。
全画面を再現するなら、実装したほうが確実。
利用者に触ってもらう場合の作り方
検証に使う場合は、検証する経路だけが動けば足ります。
- 検証したい行動を決める(例:問い合わせまで進む)
- その経路に必要な画面だけを用意する
- 経路上の操作だけをつなぐ
- 経路外を押した場合の挙動を決めておく
- 実機で動くことを確認してから実施する
経路外を押されたときに何も起きないと、参加者が戸惑います。「この先は今回の対象外です」と伝えるか、事前に説明してください。検証の進め方はユーザビリティテストのやり方|低コストで始める実践手順を参照してください。
検証する経路だけが動けば足りる。
経路外を押されたときの扱いを決めておく。
発注側は主要な導線だけ確認する
発注する立場では、すべての画面を確認する必要はありません。
- 訪問から問い合わせまでの経路
- 料金を確認してから戻る経路
- スマートフォンでの主要な操作
- 自社で更新する予定のページ
確認すべきは、成果に直結する経路です。その経路で手数が多い、迷う箇所があると感じたら、その時点で指摘してください。実装後の修正は費用が大きくなります。
指摘の方法はFigmaを発注側が使えるようになる意味|確認と指示のために覚える範囲を参照してください。
成果に直結する経路だけを確認すれば足りる。
実装後の修正は費用が大きくなる。
確認は実機で行う
パソコンの画面で見るだけでは、実際の操作感が分かりません。
| 確認方法 | 分かること | 限界 |
|---|---|---|
| パソコンで見る | 遷移の順序 | 指での操作感が分からない |
| スマートフォンで触る | 実際の操作感 | 速度は分からない |
| 複数人で触る | 迷う箇所の傾向 | 手間がかかる |
スマートフォン向けの設計は、必ず実機で触ってください。押しにくさや、指が届かない位置は、画面上では分かりません。操作性はスマホで押しやすいボタンの設計|大きさより間隔が誤タップを決めるを参照してください。
スマートフォン向けは必ず実機で触る。
押しにくさや到達範囲は、画面上では分からない。
作り込みすぎない判断
動きを細かく作り込むと、本来確認したいことから注意がそれます。
| 状態 | 起きること | 対応 |
|---|---|---|
| 動きが凝っている | 動きの評価に議論が向く | 確認の目的を明示する |
| 全画面が動く | 確認に時間がかかる | 経路を絞る |
| 実装と誤解される | そのまま実装できると思われる | 位置づけを説明する |
| 修正のたびに作り直し | 工数が膨らむ | 確定後に作る |
構成が固まる前に作ると、修正のたびに作り直しになります。ワイヤーフレームの段階で構成を固め、その後に作るほうが無駄がありません。
構成の固め方はワイヤーフレームの作り方|構成を固めてからデザインに進むを参照してください。
構成が固まる前に作ると、修正のたびに作り直しになる。
動きを凝ると、確認したいことから注意がそれる。
工程全体の中で見る
この工程の前後には、情報の分類と構造の設計があります。全体の流れは情報設計(IA)とは?わかりやすいサイト構成の作り方を参照してください。
よくある失敗
全画面を再現しようとする
実装に近い工数がかかります。確認したいことに必要な範囲だけを作ってください。
構成が固まる前に作る
修正のたびに作り直しになります。ワイヤーフレームで構成を固めてから作ってください。
パソコンの画面だけで確認する
指での操作感が分かりません。スマートフォン向けは実機で触ってください。
プロトタイプで実データを想定しない
実際の文言で見出しが何行にもなることがあります。長い内容でも確認してください。
動きを凝りすぎる
動きの評価に議論が向き、確認したいことから注意がそれます。
よくある質問
必ず作るべきですか
必須ではありません。ページ数が少なく遷移が単純なサイトでは、静止画の確認で足りることもあります。手数が多い、判断が分かれる導線がある場合に価値が出ます。
実装の代わりになりますか
なりません。表示速度、実データでの見え方、入力時の挙動、画面幅ごとの変化は再現できません。これらは実装後に確認する必要があります。
発注側でも作れますか
作ることはできますが、必要性は低いと考えられます。確認と指示に集中するほうが、時間の使い方として効率的です。
プロトタイプの費用は別途かかりますか
制作会社によって、含まれる場合と別途になる場合があります。範囲によって工数が変わるため、どこまで作るかを事前に合意してください。
修正の依頼はどう伝えればよいですか
該当する画面にコメントを付け、目的を書いてください。「手数が多い」という指摘であれば、どの操作を減らしたいかまで伝えると、代替案が出やすくなります。
まとめ
プロトタイプは、デザインの画面をつないで実際に触れる状態にしたものです。静止した画面では分からない遷移の順序、目的までの手数、戻る操作の挙動を確認できます。最も価値があるのは手数を体感できることで、画面ごとに見ると問題なくても通しで操作すると手数が多いと分かることがあります。
ただし作り込むほど工数がかかり、それでいて実装しないと分からないことは残ります。表示速度、実データでの見え方、入力時の挙動、画面幅ごとの変化は再現できません。特に実データでの見え方は見落とされやすく、プロトタイプでちょうど良く見えた見出しが実際の文言で何行にもなることがあります。
したがって作る範囲は、確認したいことから決めてください。全体の構成を見たいなら主要ページの遷移だけ、問い合わせまでの導線を確認したいならその経路だけで足ります。全画面と全操作を再現するなら、実装に近い工数をかけることになり、それなら実装してから確認するほうが確実です。また構成が固まる前に作ると修正のたびに作り直しになるため、ワイヤーフレームで構成を固めてから着手してください。
当社ではホームページ制作において、確認しやすい進め方をご提案しています。デザイン面の検討はデザイン制作とあわせてご相談ください。
ネットショップの制作費用を調べると、金額に大きな幅があります。これは同じものに対する価格差ではなく、構築の方法そのものが違うためです。
既製のサービスを使う場合と、独自に作る場合では初期費用も維持費も、できることも変わります。方法を決めずに見積もりを取ると、比較できない数字が並びます。
この記事では、構築方法ごとの違い、費用が上がる要因、追加費用が出やすい箇所、そして判断の順序を整理します。金額は事業者や条件によって変わるため、具体的な数字は見積もりで確認してください。
この記事でわかること
・費用の幅は、構築方法の違いによる
・既製サービスは初期が小さく、制約がある
・独自構築は自由だが、維持費も自社で負う
・デザインの費用は、独自性の度合いで変わる
・追加費用が出やすい箇所を事前に確認する
・判断は売上規模と運用体制で決まる
費用の幅は構築方法の違い
まず方法によって費用の構造が変わることを把握してください。
| 構築方法 | 初期費用 | 維持費 | 見た目の自由度 |
|---|---|---|---|
| 既製サービスの標準機能 | 小さい | 月額が中心 | 制約が大きい |
| 既製サービスを調整 | 中程度 | 月額+調整分 | 中程度 |
| 自社サイトに機能を追加 | 中程度 | 保守費 | 高い |
| 独自に構築 | 大きい | 保守費が大きい | 制限なし |
下にいくほど自由度は上がりますが、維持の負担も自社が負います。売上規模に対して過剰な方法を選ぶと、維持費が利益を圧迫します。
作るか買うかの判断は業務システムは作るか、買うか|既製で足りる条件と、作る判断の分岐点の考え方が応用できます。
自由度が上がるほど、維持の負担も自社が負う。
売上規模に対して過剰な方法は、維持費が利益を圧迫する。
デザイン費用は独自性の度合いで変わる
同じ構築方法でも、デザインをどこまで独自にするかで費用が変わります。
| デザインの範囲 | 費用 | 適する状況 |
|---|---|---|
| 既製の雛形をそのまま使う | 最小 | まず始めたい |
| 色と写真だけ変える | 小さい | ブランドの主張が弱くてよい |
| 主要ページを独自に作る | 中程度 | トップと商品ページで差をつけたい |
| 全ページを独自に作る | 大きい | ブランドが購入理由になる |
商品で選ばれる商材では、デザインへの投資は優先度が下がります。逆にブランドが購入理由になる商材では、投資に見合います。何で選ばれているかを確認してから決めてください。
商品で選ばれるなら、デザイン投資の優先度は下がる。
ブランドが購入理由なら、投資に見合う。
追加費用が出やすい箇所
見積もりの範囲外になりやすい項目があります。事前に確認してください。
- 商品データの登録(点数が多いと大きな作業になる)
- 商品画像の撮影と加工
- 商品説明の文章作成
- 既存データの移行
- 決済や配送の設定
- 公開後の初期不具合の対応
- スマートフォン向けの個別調整
特に商品データの登録は、点数によって工数が大きく変わります。自社で行うか依頼するかで総額が変わるため、範囲を明確にしてください。
見積もりの読み方はWeb制作の見積書の読み方|同じ金額が別の買い物になる理由を参照してください。
商品データの登録と画像の準備が、費用を左右する。
自社で行うか依頼するかで総額が変わる。
維持にかかる費用を含めて比較する
初期費用だけで比較すると、数年後の総額が逆転することがあります。
| 費用の種類 | 既製サービス | 独自構築 |
|---|---|---|
| 初期 | 小さい | 大きい |
| 月額の利用料 | 発生する | サーバー費用 |
| 決済手数料 | サービス規定 | 契約先による |
| 保守と更新 | 提供元が行う | 自社または委託 |
| 機能追加 | 提供元の対応を待つ | 自社で判断できる |
| セキュリティ対応 | 提供元が行う | 自社で負う |
独自構築では、セキュリティの対応も自社の責任になります。決済情報を扱うため、この負担は小さくありません。体制がない場合、既製サービスのほうが安全です。
3年から5年の総額で比較する。
独自構築ではセキュリティの責任も自社が負う。
判断は売上規模と運用体制で決まる
方法を選ぶ順序は、次のとおりです。
- 想定する月商と商品点数を出す
- 運用に割ける人員と時間を確認する
- 既製サービスの標準機能で足りるかを確認する
- 足りない機能が、売上に直結するかを判断する
- 直結するなら調整や独自構築を検討する
- 直結しないなら、既製の範囲で始める
足りない機能があっても、それが売上に直結しないなら後回しで構いません。始めてみて必要性が確認できてから投資するほうが、無駄が少なくなります。
足りない機能が売上に直結するかで判断する。
必要性を確認してから投資するほうが無駄が少ない。
先に決めておくと見積もりが比較できる
複数社から見積もりを取る場合、前提を揃えないと比較できません。
| 伝えること | 揃えないと起きること |
|---|---|
| 構築方法の希望 | 方法が違い、金額が比較できない |
| 商品点数 | 登録作業の見積もりが変わる |
| デザインの範囲 | 独自性の度合いで大きく変わる |
| 必要な決済方法 | 後から追加費用になる |
| 公開希望日 | 対応可否が変わる |
| 運用の担当者 | 更新のしやすさの設計が変わる |
同じ条件を伝えれば、金額の差が何によるものか分かります。条件が違うまま比較すると、安いところが範囲を狭く見積もっているだけということがあります。
制作会社の選び方はデザイン制作会社の選び方|見積り比較で確認すべきポイントを参照してください。
前提を揃えないと、金額の差が何によるものか分からない。
安い見積もりは、範囲が狭いだけのことがある。
公開後に費用が必要になる箇所
制作費だけを見ていると、公開後の負担を見落とします。
- 商品の追加と更新にかかる作業
- 季節ごとの見せ方の変更
- 決済や配送の条件変更への対応
- 不具合の修正
- 集客のための広告や施策
作っただけでは売れません。集客の費用を確保していないと、公開後に動きがない状態が続きます。制作費と集客費の配分を、最初に決めてください。
購入率の改善はECサイトのデザインで購入率を上げる方法|段階別の改善手順を参照してください。
作っただけでは売れない。集客の費用を確保する。
制作費と集客費の配分を最初に決める。
よくある失敗
構築方法を決めずに見積もりを取る
比較できない数字が並びます。方法の希望を伝えてください。
初期費用だけで比較する
維持費を含めた総額で逆転することがあります。3年から5年で比較してください。
商品データの登録を範囲に含めない
点数によっては大きな作業になります。誰が行うかを明確にしてください。
売上規模に対して過剰な方法を選ぶ
維持費が利益を圧迫します。既製の範囲で始めて、必要性を確認してから投資してください。
集客の費用を確保しない
作っただけでは売れません。制作費と集客費の配分を最初に決めてください。
よくある質問
最も安く始める方法は何ですか
既製サービスの標準機能と雛形をそのまま使う方法です。ただし見た目の制約があり、他社と似た印象になります。まず売れるかを確認する段階では、この方法から始めて問題ありません。
後から構築方法を変えられますか
可能ですが、作り直しに近い工数がかかります。商品データや顧客データの移行も必要です。将来の規模がある程度読める場合、最初から見込んで選ぶほうが総額は下がります。
デザインは後から変えられますか
構築方法によります。既製サービスでは変更の範囲に制約があり、独自構築では自由に変えられます。ただしどちらも費用は発生します。
モールに出すのとどちらがよいですか
目的が違います。モールは集客力がある一方、手数料と価格競争があります。自社サイトは集客を自前で行う必要がありますが、顧客との関係を持てます。併用する事業者も多くあります。
スマートフォン対応は別料金ですか
多くの場合は含まれますが、個別の調整は別になることがあります。特に購入手続きの操作性は成果に直結するため、どこまで含まれるかを確認してください。確認すべき箇所はECサイトのスマホ対応で見るべき箇所|購入までの各段階で起きる離脱を参照してください。
まとめ
ネットショップの制作費用に大きな幅があるのは、同じものに対する価格差ではなく構築の方法そのものが違うためです。既製サービスの標準機能を使う場合と独自に構築する場合では、初期費用も維持費もできることも変わります。方法を決めずに見積もりを取ると、比較できない数字が並びます。
判断の順序としては、想定する月商と商品点数、運用に割ける体制を確認し、既製サービスの標準機能で足りるかを見ます。足りない機能があっても、それが売上に直結しないなら後回しで構いません。始めてみて必要性が確認できてから投資するほうが、無駄が少なくなります。売上規模に対して過剰な方法を選ぶと、維持費が利益を圧迫します。
また比較は初期費用ではなく、3年から5年の総額で行ってください。独自構築ではセキュリティの対応も自社の責任になり、決済情報を扱う以上この負担は小さくありません。そして見落としやすいのが、商品データの登録と画像の準備、そして公開後の集客費用です。作っただけでは売れないため、制作費と集客費の配分を最初に決めておく必要があります。
当社ではホームページ制作において、規模に応じた構築方法のご提案をしています。見積もりの前提整理はお問い合わせよりご相談ください。
コンポーネントライブラリは、ボタンやフォームといった部品を、実装済みの状態でまとめておく仕組みです。新しいページを作るとき、既存の部品を組み合わせれば済むため、制作の速度が上がります。
ただし作ること自体は難しくありません。難しいのは維持することです。使われずに放置されたライブラリは、実際のサイトと乖離していきます。乖離すると誰も参照しなくなり、結局その場で新しく作られます。
この記事では、効果が出る条件、既製のものを使う判断、作る前に決めること、そして発注時に確認すべき点を整理します。
この記事でわかること
・作ることより、維持することが難しい
・効果が出るのは、ページを継続的に追加する場合
・既製のものを使う判断もある
・作る前に、更新する人と手順を決める
・実際のサイトと乖離すると使われなくなる
・発注側は、引き継げるかを確認する
作ることより維持することが難しい
ライブラリが機能しなくなる原因は、ほとんどが維持されないことです。
| 起きること | 原因 | 結果 |
|---|---|---|
| 実際のサイトと見た目が違う | サイト側だけ変更した | 参照されなくなる |
| 使い方が分からない | 説明がない | その場で作られる |
| 部品が足りない | 追加されない | 個別に実装される |
| 古い部品が残る | 整理されない | どれが正しいか不明 |
特に多いのは、急ぎの案件でサイト側だけ直し、ライブラリを更新しないパターンです。これが数回続くと乖離が固定化し、ライブラリは使われなくなります。
機能しなくなる原因は、維持されないこと。
サイト側だけ直す運用が続くと、乖離が固定化する。
効果が出るのは継続的に追加する場合
投資に見合うかは、今後どれだけページを追加するかで決まります。
| 状況 | 効果 | 判断 |
|---|---|---|
| 定期的にページを追加する | 高い | 作る価値がある |
| 複数のサイトで共通の部品を使う | 高い | 作る価値がある |
| 担当者が複数いる | 高い | 品質のばらつきを防げる |
| 公開後ほとんど追加しない | 低い | 作らなくてよい |
| 1人で全て作る | 低い | 本人の記憶で足りる |
ページを追加しないサイトでは、ライブラリを作っても使う機会がありません。制作費が上がるだけになります。
今後のページ追加の見込みで判断する。
追加しないサイトでは、使う機会自体がない。
既製のものを使う判断もある
自社専用のものを作る以外に、既に公開されている部品群を使う選択肢があります。
| 方法 | 初期の手間 | 見た目の自由度 | 維持の負担 |
|---|---|---|---|
| 自社で作る | 大きい | 高い | 自社で負う |
| 既製のものを使う | 小さい | 制約がある | 提供元が更新する |
| 既製のものを調整する | 中程度 | 中程度 | 調整分は自社で負う |
ブランドとしての見た目にこだわりが強くない場合、既製のものを使うほうが早く安くなります。ただし他社と似た見た目になること、提供元の方針変更に影響されることは前提になります。
作るか買うかの判断は業務システムは作るか、買うか|既製で足りる条件と、作る判断の分岐点の考え方が応用できます。
見た目のこだわりが強くなければ、既製のものが早い。
他社と似ること、提供元の方針に影響されることが前提。
作る前に決めること
着手する前に、次の項目を決めてください。これらが曖昧なまま作ると、維持されません。
- 誰が更新するか(担当者と、その人が離れた場合の代替)
- どのタイミングで更新するか(案件のたび、定期など)
- サイト側だけ変更してよい場合はあるか
- 部品を追加する基準(何回使われたら部品にするか)
- 使わなくなった部品を削除する手順
- 説明をどこに、どの粒度で書くか
特に3つ目が重要です。急ぎの案件でサイト側だけ直すことを認めるなら、後でライブラリへ反映する手順まで決めておく必要があります。
更新する人と、更新のタイミングを先に決める。
サイト側だけ直した場合の反映手順まで決めておく。
説明がないと使われない
部品が用意されていても、使い方が分からなければ、その場で作られます。
- どのような場面で使う部品かを書く
- 似た部品がある場合、使い分けの基準を書く
- 変更してよい箇所と、変更してはいけない箇所を示す
- 実際の表示例を置く
- 使ってはいけない例も示す
使い分けの基準がないと、担当者ごとに判断が変わります。結果として、同じ場面で違う部品が使われ、一貫性が崩れます。
一貫性が崩れる原因はUIの一貫性はなぜ成果に効くのか|崩れる原因と、揃えるべき範囲を参照してください。
使い方の説明がないと、その場で作られる。
使い分けの基準がないと、担当者ごとに判断が変わる。
発注側は引き継げるかを確認する
制作を外部に依頼する場合、ライブラリの扱いを契約時に確認してください。
| 確認項目 | 確認しない場合 |
|---|---|
| データと実装の所有者 | 変更時に引き継げない |
| 使用している外部の部品 | 利用条件が引き継げない |
| 説明の有無と場所 | 次の担当者が使えない |
| 更新の依頼にかかる費用 | 維持費が想定外になる |
| 自社で更新できる範囲 | 毎回依頼が必要になる |
ライブラリがあること自体は、引き継げることを意味しません。説明がなければ、次の制作会社は結局作り直します。契約時の確認事項はデザイン制作会社の選び方|見積り比較で確認すべきポイントを参照してください。
あること自体は、引き継げることを意味しない。
所有者と説明の有無を、契約時に確認する。
小さく始めて増やす
最初から網羅しようとすると、公開が遅れ、使われない部品も増えます。
- 実際に複数箇所で使われている要素を数える
- 3回以上使われているものだけを部品にする
- 使う場面と使い分けの基準を書く
- 新しいページを作る際、既存で足りるか確認する
- 足りない場合のみ追加し、その都度説明を書く
使用回数を基準にすると、必要なものだけが残ります。予想で作った部品は使われないことが多く、管理の対象が増えるだけです。
実際に複数回使われている要素だけを部品にする。
予想で作った部品は使われないことが多い。
他の要素との順序
デザインの各要素には依存関係があり、決める順序が結果を左右します。この要素が全体のどこに位置するかはWebデザインの構成要素はどの順で決めるかを参照してください。
よくある失敗
作って終わりにする
維持されないと、実際のサイトと乖離します。更新の担当と手順を決めてください。
ページを追加しないサイトで作る
使う機会がありません。今後の追加の見込みで判断してください。
説明を書かない
使い方が分からず、その場で作られます。使い分けの基準まで書いてください。
最初から網羅しようとする
公開が遅れ、使われない部品が増えます。使用回数を基準に絞ってください。
引き継ぎの前提を確認しない
あること自体は引き継げることを意味しません。所有者と説明の有無を確認してください。
よくある質問
デザイン側の部品と実装側の部品は分けるべきですか
対応関係が説明できる状態が理想です。完全に一致させることは難しいため、どのデザイン部品がどの実装部品に対応するかを記録してください。デザイン側の判断はデザインの部品化はどこまでやるべきか|更新の手間と初期工数の分岐点を参照してください。
どのくらいの規模から必要ですか
ページ数より、追加の頻度で判断してください。10ページでも毎月追加するなら効果が出ますし、50ページでも追加しないなら使う機会がありません。
既製のものを使うと他社と似ませんか
似る可能性はあります。ただし部品そのものより、配色、書体、写真、文章のほうが印象に影響します。既製の部品を使いつつ、これらで差をつける方法があります。
維持できなくなった場合はどうすべきですか
乖離が大きい状態で残すより、現状のサイトに合わせて作り直すか、使用を止めるかを判断してください。誤った内容が参照される状態が最も問題です。
分類の枠組みは必要ですか
規模によります。部品数が少なければ、一覧できる状態で足ります。増えてきた段階で分類を検討してください。考え方はアトミックデザインは導入すべきか|粒度で分ける考え方と、合わない場合を参照してください。
まとめ
コンポーネントライブラリは、ボタンやフォームといった部品を実装済みの状態でまとめておく仕組みです。新しいページを作るとき既存の部品を組み合わせれば済むため、制作の速度と一貫性が上がります。ただし作ること自体は難しくなく、難しいのは維持することです。
機能しなくなる原因は、ほとんどが維持されないことにあります。特に多いのは、急ぎの案件でサイト側だけを直し、ライブラリを更新しないパターンです。これが数回続くと乖離が固定化し、誰も参照しなくなります。したがって着手する前に、誰が、どのタイミングで更新するか、そしてサイト側だけ変更した場合にどう反映するかまで決めておく必要があります。
また、部品が用意されていても使い方が分からなければ、その場で新しく作られます。どのような場面で使うか、似た部品がある場合の使い分けの基準まで書いてください。着手の仕方としては、最初から網羅しようとせず、実際に3回以上使われている要素だけを部品にする進め方が現実的です。予想で作った部品は使われないことが多く、管理の対象が増えるだけになります。
当社ではホームページ制作において、運用を前提とした構築をご提案しています。既存サイトの整理はお問い合わせよりご相談ください。
アトミックデザインは、画面を構成する要素を最小の部品から画面全体まで、5段階の粒度に分けて考える設計の枠組みです。部品を組み合わせて画面を作るという考え方を、明確な階層で整理したものといえます。
有効なのは大規模で継続的に開発するサービスです。一方、企業サイトのように規模が限られる場合、分類の境界を議論する時間のほうが大きくなることがあります。
この記事では、5段階の内容、成立する条件、判断に迷う典型例、そして簡略化した運用の方法を整理します。
この記事でわかること
・5段階の粒度で部品を分類する枠組み
・成立するのは規模が大きく、継続的に開発する場合
・境界の判断に時間がかかる
・企業サイトでは簡略化した運用が現実的
・分類の議論より、再利用できることが目的
・導入の判断は規模と体制で決まる
5段階の粒度
要素を小さいものから大きいものへ、5段階に分けます。
| 段階 | 内容 | 例 |
|---|---|---|
| 最小の部品 | それ以上分割できない要素 | ボタン、入力欄、見出し |
| 組み合わせ | 最小の部品を組んだ小さな塊 | 検索欄(入力欄とボタン) |
| まとまり | 画面の一区画として機能する塊 | ヘッダー、記事一覧 |
| 雛形 | 配置を決めた枠組み | 中身の入っていない画面構成 |
| 画面 | 実際の内容を入れた状態 | 完成した各ページ |
下の段階から積み上げることで、部品の再利用が進むという考え方です。また雛形と画面を分けることで、構成と内容を分離して検討できます。
小さい部品から積み上げて画面を作る枠組み。
構成と内容を分けて検討できる利点がある。
成立するのは規模が大きい場合
この枠組みの利点が出るのは、特定の条件がそろった場合です。
| 条件 | 成立するか | 理由 |
|---|---|---|
| 画面数が多い | する | 再利用の機会が多い |
| 継続的に機能を追加する | する | 積み上げた部品が効く |
| 複数人で開発する | する | 共通の言葉が必要 |
| 数ページの企業サイト | しにくい | 再利用の機会が少ない |
| 一度作って更新しない | しない | 積み上げる意味がない |
| 1人で作る | しにくい | 分類を共有する相手がいない |
再利用の機会と、関わる人数が判断の軸になります。どちらも小さい場合、分類の枠組みを導入しても管理の手間が増えるだけです。
再利用の機会と関わる人数が、判断の軸になる。
どちらも小さければ、手間が増えるだけになる。
境界の判断に時間がかかる
この枠組みで最も問題になるのは、どの段階に分類するかの判断です。
- アイコン付きのボタンは、最小の部品か組み合わせか
- 見出しと本文の組は、組み合わせかまとまりか
- サイドバーは、まとまりか雛形の一部か
- 同じ要素でも、使われる場所で段階が変わるように見える
この議論に時間を使っても、成果物は変わりません。分類は目的ではなく手段です。判断に迷う要素が出たら、チーム内で決めて記録し、以降は同じ扱いにする。この運用のほうが実務的です。
境界の議論に時間を使っても、成果物は変わらない。
迷ったら決めて記録し、以降は同じ扱いにする。
企業サイトでは簡略化した運用が現実的
規模が限られる場合、段階を減らした運用で目的を果たせます。
| 簡略化した分類 | 内容 | 十分な規模 |
|---|---|---|
| 部品 | ボタン、入力欄、見出しなど | 全規模 |
| ブロック | ヘッダー、一覧、フォームなど | 10ページ以上 |
| ページ | 完成した画面 | 全規模 |
3段階あれば、再利用と一貫性という目的は達成できます。5段階に分けることが目的ではありません。
部品化の判断はデザインの部品化はどこまでやるべきか|更新の手間と初期工数の分岐点を参照してください。
3段階でも、再利用と一貫性は達成できる。
5段階に分けること自体は目的ではない。
分類より再利用できることが目的
枠組みを導入する目的を見失わないでください。
| 目的 | 達成されているかの確認 |
|---|---|
| 同じ要素を作り直さない | 似た部品が重複していないか |
| 変更が一箇所で済む | 修正が全使用箇所に反映されるか |
| 一貫性が保たれる | 同じ役割の要素が同じ形か |
| 新規追加が速い | 既存の部品を組み合わせて作れるか |
分類が整っていても、これらが達成されていないなら意味がありません。逆に分類が簡略でも達成されていれば十分です。
目的は再利用と一貫性であり、分類そのものではない。
分類が整っていても、目的が達成されていなければ意味がない。
導入の判断は規模と体制で決まる
導入するかどうかは、次の順で確認してください。
- 画面数と、今後の追加の見込みを確認する
- 関わる人数と、担当の交代の可能性を確認する
- 更新の頻度を確認する
- 3つとも小さいなら、簡略化した分類で足りる
- いずれかが大きいなら、体系的な導入を検討する
担当の交代がある場合、分類の枠組みは共通言語として機能します。ただし説明を残さないと、次の担当者は意図を読み取れません。枠組みを導入するなら、判断の記録もセットで必要です。
画面の構成そのものの検討はワイヤーフレームの作り方|構成を固めてからデザインに進む、情報の分類は情報設計(IA)とは?わかりやすいサイト構成の作り方を参照してください。
画面数、人数、更新頻度の3つで判断する。
導入するなら、判断の記録もセットで残す。
他の要素との順序
デザインの各要素には依存関係があり、決める順序が結果を左右します。この要素が全体のどこに位置するかはWebデザインの構成要素はどの順で決めるかを参照してください。
よくある失敗
小規模なサイトに体系的に導入する
再利用の機会が少なく、管理の手間だけが増えます。簡略化した分類で足ります。
分類の議論に時間を使う
成果物は変わりません。迷ったら決めて記録し、以降は同じ扱いにしてください。
5段階に分けること自体を目的にする
目的は再利用と一貫性です。3段階でも達成できます。
判断の記録を残さない
担当が変わると意図が読み取れず、分類が崩れます。
分類が整っていることで満足する
似た部品の重複がないか、修正が一箇所で済むかを確認してください。
よくある質問
デザインシステムとは違うものですか
アトミックデザインは部品を粒度で分類する考え方であり、デザインシステムは規定と部品を含む仕組み全体を指します。分類の枠組みとして、デザインシステムの中で使われることがあります。全体像はデザインシステムとは?導入するメリットと作り方の基本を参照してください。
実装側も同じ分類にすべきですか
そろえられると連携しやすくなります。ただし実装側の都合で分割の単位が変わることもあります。完全に一致させることより、対応関係が説明できる状態を優先してください。
既存サイトに後から適用できますか
可能ですが、既存の要素を分類し直す工数がかかります。リニューアルのタイミングで導入するほうが現実的です。
命名はどうすべきですか
段階の名称をそのまま使うか、自社で分かりやすい名前にするかは自由です。重要なのは、チーム内で同じ言葉が同じものを指すことです。外部の呼称にこだわる必要はありません。
導入しない場合、何を代わりにすべきですか
部品として登録する要素を決め、命名規則を統一するだけでも一貫性は保てます。実装側で使い回す部品群としての整理はコンポーネントライブラリとは|制作を効率化する仕組みと、作る前に決めることを参照してください。
まとめ
アトミックデザインは、画面を構成する要素を最小の部品から画面全体まで5段階の粒度に分けて考える枠組みです。下の段階から積み上げることで再利用が進み、構成と内容を分離して検討できる利点があります。ただしこの利点が出るのは、画面数が多く、継続的に開発し、複数人が関わる場合に限られます。
数ページの企業サイトで体系的に導入すると、再利用の機会が少ないため管理の手間だけが増えます。またこの枠組みで最も問題になるのは、どの段階に分類するかの判断です。アイコン付きのボタンは最小の部品か組み合わせか、といった議論に時間を使っても成果物は変わりません。分類は目的ではなく手段です。
規模が限られる場合、部品、ブロック、ページという3段階に簡略化しても、再利用と一貫性という目的は達成できます。確認すべきは分類の整い方ではなく、似た部品が重複していないか、修正が一箇所で済むか、新規追加が既存の組み合わせで作れるかです。これらが達成されていれば、分類が簡略でも十分です。
当社ではホームページ制作において、規模に応じた設計をご提案しています。既存サイトの整理はお問い合わせよりご相談ください。
デザインツールには、繰り返し使う要素を部品として登録する仕組みがあります。一度登録すれば、元を修正するだけで使用箇所すべてに反映されます。
ただし登録には手間がかかります。どのような状態の違いがあるか、どこを変更可能にするかを設計する必要があるためです。この初期工数は、後の更新回数で回収する構造になっています。更新しないサイトでは、回収できません。
この記事では、部品化が回収できる条件、部品にすべき要素とそうでない要素、規模による判断、そして発注側が確認すべき点を整理します。
この記事でわかること
・初期工数を、後の更新回数で回収する仕組み
・更新しないサイトでは回収できない
・部品にすべきは、繰り返し使い変更が波及する要素
・細かく分けすぎると管理が破綻する
・発注側は更新のしやすさで判断する
・引き継ぎの前提を確認しておく
初期工数を更新回数で回収する
部品化は投資であり、回収の見込みがあるかで判断します。
| 状況 | 初期工数 | 回収の見込み |
|---|---|---|
| ページ数が多く、共通要素も多い | 大きい | 高い |
| 更新が頻繁 | 大きい | 高い |
| ページ数が少なく、更新もしない | 大きい | 低い |
| 公開後すぐに作り直す予定 | 大きい | なし |
| 同じ構成のページを量産する | 中程度 | 高い |
数ページで更新予定もないサイトに部品化を持ち込むと、制作費だけが上がります。逆に、ページ数が多く共通要素が繰り返される場合、修正のたびに全ページを直す手間が消えます。
部品化は初期投資。更新回数で回収する。
小規模で更新しないサイトでは、費用だけが増える。
部品にすべき要素とそうでない要素
すべてを部品にする必要はありません。判断の基準は、繰り返し使うかと、変更が波及するかです。
| 要素 | 部品にすべきか | 理由 |
|---|---|---|
| ボタン | する | 全ページで使い、形を統一する必要がある |
| ヘッダー、フッター | する | 変更が全ページに波及する |
| 入力欄 | する | 形式が複数あり、統一が必要 |
| 一覧の項目 | する | 同じ形で繰り返される |
| 1ページにしかない図 | しない | 再利用がない |
| キャンペーン用の装飾 | しない | 期間限定で撤去する |
1箇所でしか使わない要素を部品にすると、管理の対象が増えるだけです。再利用の見込みがあるものに限定してください。
統一の意義はUIの一貫性はなぜ成果に効くのか|崩れる原因と、揃えるべき範囲を参照してください。
繰り返し使い、変更が波及する要素に限定する。
1箇所だけの要素を部品にすると、管理対象が増えるだけ。
細かく分けすぎると管理が破綻する
分割の粒度は細かいほど良いわけではありません。
- 細かく分けるほど、組み合わせの数が増える
- どの部品を使うべきか、判断に時間がかかる
- 似た部品が複数生まれ、どれが正しいか分からなくなる
- 命名の規則がないと、探せなくなる
- 担当者が変わると、意図が引き継がれない
部品の数が増えたら、統合できないかを定期的に確認してください。似た部品が複数ある状態は、一貫性を保つという目的から外れています。
粒度の考え方はアトミックデザインは導入すべきか|粒度で分ける考え方と、合わない場合を参照してください。
細かく分けるほど、組み合わせと判断の手間が増える。
似た部品が複数ある状態は、目的から外れている。
発注側は更新のしやすさで判断する
発注する立場では、部品化の技術的な内容より、更新できるかどうかを確認してください。
- 公開後、誰がどの範囲を更新するかを確認する
- その範囲が、専門知識なしで更新できるかを確認する
- 更新のたびに制作会社への依頼が必要な箇所を把握する
- その依頼にかかる費用と期間を確認する
- 自社で更新したい箇所があれば、事前に伝える
部品化されていても、更新に専門知識が必要なら自社では触れません。デザイン側の部品化と、公開後の更新のしやすさは別の話です。運用面は更新しやすい企業サイトの作り方|CMS選定と運用設計のポイントを参照してください。
デザインの部品化と、公開後の更新のしやすさは別。
誰がどの範囲を更新するかを、事前に確認する。
引き継ぎの前提を確認しておく
制作会社を変更する場合、部品の設計が引き継げるかが問題になります。
| 確認項目 | 確認しない場合 | 対応 |
|---|---|---|
| データの所有者 | 引き継げないことがある | 契約時に明確にする |
| 部品の命名規則 | 意図が読み取れない | 説明を残してもらう |
| 使用しているツール | 移行できないことがある | 事前に確認する |
| 外部の素材の利用条件 | 使い続けられない | 範囲を確認する |
部品として整理されていても、意図の説明がなければ次の担当者は使えません。命名の規則と、使い分けの基準を文書として残してもらってください。
契約時の確認事項はデザイン制作会社の選び方|見積り比較で確認すべきポイントを参照してください。
整理されていても、説明がなければ引き継げない。
命名規則と使い分けの基準を文書で残してもらう。
規模別の現実的な進め方
規模によって、適した水準が変わります。
| 規模 | 推奨する水準 | 理由 |
|---|---|---|
| 数ページ | ボタンと入力欄のみ | それ以上は回収できない |
| 10ページ前後 | ヘッダー、フッター、繰り返し要素 | 更新の手間が減る |
| 数十ページ以上 | 体系的に整理する | 手作業では一貫性を保てない |
| 継続的に追加する | 規定を文書化する | 担当者が変わっても維持できる |
最初から完璧な体系を作ろうとすると、公開が遅れます。まず頻出する要素だけを部品にし、運用しながら追加する進め方が現実的です。
体系化の判断はデザインシステムとは?導入するメリットと作り方の基本を参照してください。
最初から完璧を目指すと、公開が遅れる。
頻出する要素から始め、運用しながら追加する。
他の要素との順序
デザインの各要素には依存関係があり、決める順序が結果を左右します。この要素が全体のどこに位置するかはWebデザインの構成要素はどの順で決めるかを参照してください。
よくある失敗
小規模なサイトで体系的に部品化する
初期工数を回収できません。更新回数から判断してください。
1箇所でしか使わない要素を部品にする
管理対象が増えるだけです。再利用の見込みがあるものに限定してください。
細かく分けすぎる
組み合わせの数が増え、どれを使うか判断できなくなります。
命名規則を決めずに増やす
探せなくなり、似た部品が重複します。規則を先に決めてください。
公開後の更新のしやすさを確認しない
デザインの部品化と、自社で更新できるかは別の話です。
よくある質問
部品化すると制作費は安くなりますか
初期の制作費は上がることが多くなります。安くなるのは、公開後の修正費用です。ページ数が多く更新が続く場合に、総額で下回ります。短期で作り直す予定があるなら、初期費用が上がるだけになります。
既存サイトを後から部品化できますか
可能ですが、作り直しに近い工数がかかることがあります。次のリニューアルのタイミングで導入するほうが現実的です。
発注側が部品の構造を理解する必要はありますか
構造そのものを理解する必要はありません。確認すべきは、公開後に自社で更新できる範囲と、依頼が必要な範囲です。
ツールが変わったら作り直しになりますか
ツール間で完全に移行できるとは限りません。長期的に使うサイトでは、この点を契約時に確認してください。データの所有者と、移行の可否を明確にしておくことが重要です。
部品を増やしすぎた場合はどうすべきですか
似た部品を統合してください。統合すると使用箇所の見た目が変わる可能性があるため、影響範囲を確認したうえで進めます。定期的な棚卸しを予定に入れておくと、増えすぎる前に対処できます。
まとめ
デザインの部品化は、初期工数を後の更新回数で回収する仕組みです。一度登録すれば元の修正が使用箇所すべてに反映されますが、その登録には状態の違いや変更可能な箇所を設計する手間がかかります。したがってページ数が少なく更新予定もないサイトでは、制作費だけが上がる結果になります。
部品にすべき要素の基準は、繰り返し使うかと、変更が波及するかです。ボタン、ヘッダー、フッター、入力欄のように全ページで使われる要素は部品化の効果が大きく、1ページにしかない図やキャンペーン用の装飾は対象になりません。また細かく分けるほど良いわけでもありません。分割が細かいと組み合わせの数が増え、どの部品を使うべきか判断に時間がかかります。
発注する立場で確認すべきは、部品化の技術的な内容ではなく、公開後に誰がどの範囲を更新できるかです。デザイン側が部品化されていても、更新に専門知識が必要なら自社では触れません。加えて、制作会社を変更する可能性を考えると、データの所有者と命名規則の文書化を契約時に明確にしておくことが重要になります。
当社ではデザイン制作において、規模に応じた進め方をご提案しています。運用体制を含めた検討はホームページ制作とあわせてご相談ください。
制作会社からデザインの確認をFigmaで依頼されることが増えています。発注側がこのツールを覚える目的は、自分でデザインを作ることではありません。確認と指示を正確に行うためです。
この目的であれば、覚えるべき操作はごく限られます。画面を見る、拡大縮小する、該当箇所にコメントを付ける。この3つができれば、やり取りの精度は大きく上がります。
この記事では、発注側が覚えるべき範囲、指摘の書き方、権限の扱い、そして覚えなくてよい範囲を整理します。機能の名称や操作は変更されるため、実際の操作は公式のヘルプで確認してください。
この記事でわかること
・目的は作ることではなく、確認と指示
・覚えるべき操作は3つに絞れる
・指摘は該当箇所に直接付ける
・権限は閲覧とコメントで足りる
・編集権限を持つと事故が起きる
・口頭やメールでの指示より精度が上がる
目的は作ることではなく確認と指示
発注側がツールを使う場面は、ほぼ確認と指摘に限られます。
| 場面 | 必要な操作 | 覚える必要性 |
|---|---|---|
| デザインを見る | 開く、拡大縮小、移動 | 必須 |
| 修正を依頼する | コメントを付ける | 必須 |
| 過去の版と比べる | 履歴を見る | あると便利 |
| 色や文字を確認する | 要素の情報を見る | あると便利 |
| デザインを作る | 作図の操作全般 | 不要 |
| 部品を管理する | コンポーネントの操作 | 不要 |
下2行は制作側の作業であり、発注側が覚える必要はありません。中途半端に触ると、意図せず要素を動かしてしまうことがあります。
発注側が使うのは、見ることと指摘することだけ。
作図や部品管理は制作側の作業。
覚えるべき操作は3つ
確認と指示に必要な操作は、次の3つです。
- 共有されたリンクを開く(ソフトの導入なしにブラウザで見られる)
- 拡大縮小と移動(全体を見る、細部を確認する)
- コメントを付ける(該当箇所を指定して書き込む)
この3つで、確認と指摘は完結します。操作の名称や配置は更新によって変わるため、細かい手順を覚えるより、この3つができる状態を目指してください。
開く、拡大縮小、コメントの3つで完結する。
細かい手順より、3つができる状態を目指す。
指摘は該当箇所に直接付ける
最も効果が大きいのは、指摘を該当箇所に直接書けることです。
| 指摘の方法 | 伝わり方 | 問題 |
|---|---|---|
| 該当箇所にコメント | 位置が明確 | 少ない |
| メールで文章のみ | どこの話か不明確 | 特定に時間がかかる |
| 電話で口頭 | 記録が残らない | 認識のずれが起きる |
| 画面を撮影して送る | 位置は分かる | やり取りが分断される |
「上のほうのボタンをもう少し目立たせてほしい」という指摘は、該当箇所に付いていれば一意に伝わります。文章だけだと、どのボタンか確認する往復が発生します。
制作のやり取り全般はデザインカンプの作り方と進め方|制作会社とのやり取りをスムーズにを参照してください。
該当箇所に付けたコメントは、位置が一意に伝わる。
文章だけの指摘は、特定のための往復が発生する。
指摘の書き方で手戻りが変わる
指摘の内容によって、修正が1回で済むか、往復するかが変わります。
| 書き方 | 例 | 結果 |
|---|---|---|
| 結論だけ | ここを直してほしい | 何をどうするか分からない |
| 指示だけ | 赤くしてほしい | 意図が伝わらず、他も崩れる |
| 理由と目的 | 問い合わせを増やしたいので目立たせたい | 手段を提案してもらえる |
| 理由と代替案 | 目立たせたい。色か大きさで | 判断が速い |
手段ではなく目的を書くと、専門的な判断を活かせます。色を変えるより配置を変えるほうが有効な場合もあります。目的が伝わっていれば、その提案が出てきます。
手段ではなく目的を書くと、専門的な提案が得られる。
指示だけを出すと、他の箇所が崩れることがある。
権限は閲覧とコメントで足りる
共有される権限には段階があります。発注側は編集権限を持たないほうが安全です。
| 権限 | できること | 発注側での必要性 |
|---|---|---|
| 閲覧のみ | 見る | 最低限 |
| コメント可 | 見る、指摘する | 推奨 |
| 編集可 | 変更できる | 不要 |
編集権限があると、確認中に誤って要素を動かすことがあります。気づかないまま制作が進むと、原因の特定に時間がかかります。コメント可の権限を依頼してください。
編集権限は不要。コメント可で足りる。
誤操作は気づかれにくく、原因の特定に時間がかかる。
覚えなくてよい範囲
次の内容は、制作を依頼する立場では不要です。
- 図形やテキストを作る操作
- 部品として登録し、再利用する仕組み
- 画面遷移を設定する操作
- 配色や書体の一括管理
- 他のツールとの連携設定
これらを覚えると、制作の内容は理解しやすくなります。ただし確認と指示という目的には不要です。時間をかけるなら、伝えたいことを言語化する側に使うほうが効果が出ます。
構成そのものの確認はワイヤーフレームの作り方|構成を固めてからデザインに進む、制作全体の工程はサイト制作の進め方|発注から公開までの工程と発注者側の作業を参照してください。
作図と部品管理は、確認と指示には不要。
時間をかけるなら、目的の言語化に使う。
社内での共有方法
確認に複数名が関わる場合、進め方を決めておくと混乱しません。
- 確認する人の範囲を決める
- 全員がコメントを付けるか、窓口を1名にするかを決める
- 指摘の期限を決める
- 矛盾する指摘が出た場合の判断者を決める
- 確定した内容を、どこに記録するかを決める
複数名が自由にコメントすると、矛盾する指摘が並びます。制作側はどちらに従うか判断できません。判断者を決めておいてください。
デザインの良し悪しを判断する軸はCVRを改善するデザイン要素とは?押さえるべき7つのポイントが参考になります。
複数名が指摘すると、矛盾が発生する。
判断者と期限を先に決めておく。
工程全体の中で見る
この工程の前後には、情報の分類と構造の設計があります。全体の流れは情報設計(IA)とは?わかりやすいサイト構成の作り方を参照してください。
よくある失敗
編集権限を受け取る
確認中に誤って要素を動かすことがあります。コメント可の権限を依頼してください。
メールや電話だけで指摘する
どこの話か特定するための往復が発生します。該当箇所にコメントしてください。
手段だけを指示する
意図が伝わらず、他の箇所が崩れることがあります。目的を書いてください。
複数名が自由にコメントする
矛盾する指摘が並び、制作側が判断できません。判断者を決めてください。
作図の操作まで覚えようとする
確認と指示には不要です。目的の言語化に時間を使うほうが効果が出ます。
よくある質問
導入は必要ですか
確認するだけであれば、共有されたリンクをブラウザで開けば足りることが多くなります。制作会社に確認してください。
費用はかかりますか
利用形態によって変わり、条件も変更されることがあります。確認とコメントの範囲でどうなるかは、制作会社または公式の情報で確認してください。
印刷して確認してもよいですか
全体の把握には有効ですが、指摘は画面上で行うことを推奨します。印刷では実際の色や、画面幅による変化が確認できません。また指摘の位置を伝えるための往復が発生します。
スマートフォンでの見え方も確認できますか
画面幅ごとのデザインが用意されていれば確認できます。用意されていない場合は、制作会社に依頼してください。実機での確認も併せて行うと確実です。
過去の版に戻せますか
履歴の機能があります。ただし発注側が操作する必要はありません。前の状態を確認したい場合は、制作会社に依頼してください。
まとめ
発注側がデザインツールを覚える目的は、自分でデザインを作ることではありません。確認と指示を正確に行うためです。この目的であれば、覚えるべき操作は開く、拡大縮小する、コメントを付けるという3つに絞れます。作図や部品管理は制作側の作業であり、中途半端に触ると意図せず要素を動かす事故につながります。
最も効果が大きいのは、指摘を該当箇所に直接書けることです。「上のほうのボタンをもう少し目立たせてほしい」という指摘も、該当箇所に付いていれば一意に伝わります。文章だけの指摘では、どの要素の話かを特定するための往復が発生します。
また指摘の書き方によって、修正が1回で済むか往復するかが変わります。手段ではなく目的を書いてください。色を変えるより配置を変えるほうが有効な場合もあり、目的が伝わっていればその提案が出てきます。そして権限は編集可ではなくコメント可を依頼してください。誤操作は気づかれにくく、原因の特定に時間がかかります。
当社ではデザイン制作において、確認のしやすい進め方をご提案しています。制作全体の流れはホームページ制作とあわせてご相談ください。
コーポレートサイトのリニューアルで、流行のデザインを取り入れたいという要望はよく出ます。しかし企業サイトで信頼を判断する要素は、見た目より情報の側にあります。
訪問者が確認するのは、どこにある会社か、何をしているか、誰がやっているか、実績があるかです。これらが分からないサイトは、どれだけ洗練されていても判断材料になりません。
この記事では、信頼が判断される要素、流行を採用してよい範囲、寿命の長い判断、そして数年間更新できる設計にする方法を整理します。
この記事でわかること
・信頼は見た目ではなく情報で判断される
・流行には寿命があり、更新の負担になる
・採用してよいのは実装の手法、避けるべきは表現の様式
・寿命の長い判断を先に固める
・更新できない設計は数年で古びる
・評価は印象ではなく問い合わせで行う
信頼は見た目ではなく情報で判断される
企業サイトを訪れた人が確認する項目は、おおむね決まっています。
| 確認される項目 | 理由 | 不足すると |
|---|---|---|
| 所在地と連絡先 | 実体があるかの確認 | 実在性を疑われる |
| 事業内容 | 何をする会社か | 依頼できるか判断できない |
| 実績や取引先 | 経験の裏付け | 任せてよいか分からない |
| 代表者と沿革 | 組織の性格 | 規模感がつかめない |
| 採用情報 | 組織の状態 | 成長性が読めない |
これらが揃っていないサイトは、デザインの質に関わらず判断材料になりません。逆に情報が揃っていれば、装飾が控えめでも判断できます。
何を載せるかの整理は会社案内サイトで信頼感を作る方法|見た目より先に埋めるべき情報を参照してください。
訪問者が確認するのは、実体・事業内容・実績・組織。
情報が揃っていれば、装飾が控えめでも判断できる。
流行には寿命があり更新の負担になる
デザインの流行は数年で入れ替わります。強く特徴づけた表現ほど、古びたときの印象が強くなります。
| 採用したもの | 寿命 | 古びたときの影響 |
|---|---|---|
| 特徴的な装飾表現 | 短い | 時代が特定される |
| 過度な動き | 短い | 重く古い印象になる |
| 読みやすい書体と余白 | 長い | 古びにくい |
| 情報の構造 | 長い | 内容次第で維持できる |
| 色の設計 | 中程度 | ブランドに紐づけば長い |
コーポレートサイトは数年単位で使うものです。短い寿命の表現を全面に使うと、次のリニューアルまでの後半は古びた状態で運用することになります。
特徴的な表現ほど、古びたときに時代が特定される。
数年使う前提なら、寿命の長い判断を優先する。
採用してよいのは実装の手法
流行と呼ばれるものには、表現の様式と実装の手法が混在しています。後者は取り入れる価値があります。
- 画面幅に応じた最適化は、手法として定着している
- 画像の読み込みを遅らせる実装は、表示速度に効く
- 配色の切り替えに対応する実装は、閲覧環境への配慮
- 一方、特定の装飾表現は数年で入れ替わる
- 動きの多用も、流行によって評価が変わる
利用者の環境や体験に関わる手法は、流行ではなく改善です。これらは積極的に取り入れてよい領域です。表示速度の改善はサイトの表示速度を改善する優先順位|何から手をつけるかを参照してください。
利用者の体験に関わる手法は、流行ではなく改善。
装飾の様式は入れ替わる。全面に使わない。
寿命の長い判断を先に固める
デザインの検討に入る前に、次の項目を決めてください。これらは数年変わりません。
- 誰に向けたサイトか(顧客、採用、投資家、取引先)
- その人が最初に確認したい情報は何か
- サイトで達成したいことは何か(問い合わせ、認知、採用)
- 更新する人は誰で、どの頻度で更新するか
- ブランドとして守るべき表現の規定はあるか
特に4つ目を決めないと、更新されないサイトになります。凝った構成にすると更新に専門知識が必要になり、結果として情報が古いまま放置されます。
運用設計は更新しやすい企業サイトの作り方|CMS選定と運用設計のポイントを参照してください。
対象、目的、更新体制を先に決める。
更新できない構成にすると、情報が古いまま残る。
更新できない設計は数年で古びる
サイトが古く見える原因は、デザインより情報の古さであることが多くなります。
| 古びる箇所 | 原因 | 対策 |
|---|---|---|
| お知らせが数年前で止まる | 更新の体制がない | 更新頻度を決めて運用に組み込む |
| 実績が更新されない | 追加の手順が複雑 | 追加しやすい構成にする |
| 社員の写真が入れ替わる | 撮り直しが必要 | 個人に依存しない構成にする |
| 制度や表記が古い | 確認の機会がない | 定期的な点検を予定に入れる |
最も印象に影響するのは、お知らせの最終更新日です。数年前で止まっていると、事業が動いていない印象を与えます。更新できないなら、日付を表示しない構成にする判断もあります。
古く見える原因は、デザインより情報の古さ。
更新できないなら、日付を出さない構成も選択肢。
競合との差別化は表現ではなく内容で
同業のサイトが似た構成になるのは、訪問者が確認する項目が同じだからです。
| 差別化の方法 | 有効性 | 理由 |
|---|---|---|
| 装飾で目立たせる | 低い | 情報が同じなら判断は変わらない |
| 独自の実績を示す | 高い | 他社にない事実 |
| 対応範囲を明確にする | 高い | できないことも書く |
| 進め方を具体的に書く | 高い | 依頼後が想像できる |
| 担当者の考え方を示す | 中程度 | 相性の判断材料になる |
できないことを書くのは、有効な差別化です。対応範囲を明示すると、合わない依頼が減り、合う依頼の質が上がります。競合の調べ方は競合サイト分析のやり方|何を見て、どう自社の判断に変えるかを参照してください。
同業のサイトが似るのは、確認される項目が同じだから。
できないことを書くのは、有効な差別化になる。
評価は印象ではなく問い合わせで行う
リニューアルの成否は社内の印象ではなく、行動の変化で判断してください。
| 見る指標 | 分かること | 比較の方法 |
|---|---|---|
| 問い合わせ数 | 成果 | リニューアル前後で比較 |
| 問い合わせの質 | 対象との一致 | 商談化率で見る |
| 採用応募数 | 採用面の成果 | 同上 |
| 会社名での検索数 | 認知の変化 | 期間で比較 |
| 社内の評価 | 印象 | 成果とは別に扱う |
問い合わせ数が変わらなくても、質が上がっていれば成功です。対応範囲を明示した結果、合わない依頼が減ることがあります。数だけで判断しないでください。
数が変わらなくても、質が上がっていれば成功。
社内の印象評価は、成果とは分けて扱う。
よくある失敗
流行の表現を全面に使う
数年で古びます。コーポレートサイトは長く使うものです。
情報を揃えずにデザインを検討する
訪問者が確認する項目が欠けていると、装飾では補えません。
更新体制を決めずに凝った構成にする
更新に専門知識が必要になり、情報が古いまま放置されます。
装飾で競合と差別化しようとする
情報が同じなら判断は変わりません。内容で差をつけてください。
社内の印象だけで評価する
問い合わせ数と質の変化で判断してください。
よくある質問
デザイン性は不要ということですか
不要ではありません。読みにくい、探しにくい状態は判断の妨げになります。ただし装飾を加えることと、判断しやすくすることは別です。優先順位として、情報の整理が先になります。
どのくらいの周期でリニューアルすべきですか
周期で決めるより、目的との乖離で判断してください。事業内容が変わった、対象が変わった、更新できず情報が古い。こうした状態が該当します。進め方はコーポレートサイトリニューアルの進め方|失敗しない依頼手順を参照してください。
動きは入れないほうがよいですか
状態の変化を伝える動きは有効です。装飾としての動きは、流行の影響を受けやすく、表示速度にも影響します。目的のある動きに限定してください。
写真は必ず必要ですか
実体を示す意味で有効です。ただし質の低い写真や、実態と異なる写真は逆効果になります。撮影が難しい場合、無理に人物写真を使うより、事業内容が伝わる情報を充実させるほうが判断につながります。
採用も兼ねる場合はどう設計すべきですか
求職者と顧客では確認したい情報が違います。同じサイト内で導線を分け、それぞれに必要な情報を配置してください。構成は採用サイトに入れるべきコンテンツ|応募につながる情報の順序を参照してください。
まとめ
コーポレートサイトで信頼を判断する要素は、見た目より情報の側にあります。訪問者が確認するのは、どこにある会社か、何をしているか、実績があるか、誰がやっているかです。これらが揃っていないサイトは、どれだけ洗練されていても判断材料になりません。逆に情報が揃っていれば、装飾が控えめでも判断できます。
デザインの流行には寿命があります。コーポレートサイトは数年単位で使うものであり、特徴的な表現を全面に使うと、次のリニューアルまでの後半は古びた状態で運用することになります。ただし流行と呼ばれるものには、表現の様式と実装の手法が混在しています。画面幅への対応や表示速度の改善といった、利用者の体験に関わる手法は流行ではなく改善であり、取り入れる価値があります。
そしてサイトが古く見える原因は、デザインより情報の古さであることが多くなります。お知らせが数年前で止まっている、実績が更新されていない。こうした状態は、事業が動いていない印象を与えます。デザインの検討に入る前に、誰が、どの頻度で更新するかを決めてください。凝った構成にすると更新に専門知識が必要になり、結果として情報が古いまま放置されます。
当社ではホームページ制作において、情報設計から更新体制までを含めてご相談いただけます。デザイン面の検討はデザイン制作とあわせてご相談ください。
同じ内容のページがサイト内に複数あると「重複コンテンツで順位が下がる」と説明されることがありますが、これは正確ではありません。意図せず生じた重複に対して罰則が科されるわけではありません。
実際に起きるのは評価の分散です。外部からのリンクやサイト内のリンクが複数の URL に分かれると、そのどれもが本来の評価に届きません。加えて、検索結果に表示される URL が想定と違うものになり、アクセス解析の数値も分かれます。
この記事では、意図せず重複が生まれる仕組み、正規 URL を伝える方法とその効果の強さ、指定しても無視される条件、そして統合すべきか残すべきかの判断を整理します。
この記事でわかること
・重複そのものに罰則はない。分散が問題
・URLの揺れで意図せず重複が生まれる
・正規URLを伝える3つの方法と効果の強さ
・指定しても無視される条件
・統合するか、残すかの判断
・やってはいけない扱い方
重複そのものではなく、分散が問題になる
Google は、重複または類似するページがある場合に正規 URL を指定する理由として、検索結果に表示したい URL を指定できること、類似ページのシグナルを統合できること、指標を集約できること、クロールの時間を節約できることを挙げています。
つまり正規 URL の指定は、順位を上げるための操作ではなく、本来1つに集まるべき評価が分かれている状態を直す作業です。
| 起きること | 具体的な影響 |
|---|---|
| 外部リンクの評価が分かれる | 被リンクを受けた URL と、表示させたい URL が違う |
| サイト内リンクの評価が分かれる | 同じページを指すリンクが複数の URL に散る |
| 表示される URL が想定と違う | パラメータ付きの URL が検索結果に出る |
| 解析の数値が分かれる | 同じページのアクセス数が複数行に分割される |
| クロールの時間が浪費される | 新しいページの発見が遅くなる |
なお Google は、正規 URL の指定は推奨であって必須ではないとしています。指定がなくても、Google が客観的に最適な URL を判断します。小規模なサイトでは、そもそも対応が不要なことも多くあります。
重複に罰則はない。評価とアクセス数が複数URLに分散することが問題。
正規URLの指定は推奨であって必須ではない。規模によっては不要。
意図せず重複が生まれる典型パターン
多くの重複は、記事を二重に書いたことではなくURLの揺れから生まれます。同じページに複数の入口ができている状態です。
| パターン | 例 | 対処 |
|---|---|---|
| 末尾のスラッシュの有無 | /page と /page/ | どちらかに転送する |
| wwwの有無 | example.com と www.example.com | どちらかに転送する |
| httpとhttps | http:// と https:// | httpsへ転送する |
| 広告等のパラメータ | ?gclid= や ?utm_source= | 正規URLを指定する |
| 並び替え・絞り込み | ?sort=price など | 正規URLを指定する |
| 印刷用ページ | /print/ など | 正規URLを指定する |
| 同じ商品の色違いページ | 内容がほぼ同じ | 統合するか正規URLを指定する |
上から3つは転送で解決すべきもので、正規 URL の指定より確実です。4行目以降は、そのページ自体に存在意義があるため、転送せず正規 URL を指定します。
計測用のパラメータ設計はUTMパラメータの設計と命名規則|流入元を正しく計測する方法を参照してください。
正規URLを伝える3つの方法
Google は、正規化に対する効果が高い順に3つの方法を挙げています。順序に意味があります。
- リダイレクト:転送先が正規ページであるという強いシグナル。重複ページを廃止するときに使う
- rel=”canonical” の指定:指定した URL が正規であるという強いシグナル。ページを残したまま使える
- サイトマップに含める:正規であることを示すが、シグナルとしては弱い
複数を組み合わせると、希望する URL が表示される可能性が高くなります。ただし、方法ごとに違う URL を正規として指定してはいけません。サイトマップで A を、canonical で B を指定するような状態は避けてください。
また、正規ページ自身にも自分を指す canonical を入れることが推奨されています。自己参照と呼ばれる設定で、多くの CMS では標準で出力されます。
| 方法 | 向いている場面 | 注意点 |
|---|---|---|
| リダイレクト | 重複ページを残す必要がない | 残したいページには使えない |
| canonical(HTML) | ページを残したまま統合したい | HTMLページにしか使えない |
| canonical(HTTPヘッダー) | PDFなどHTML以外のファイル | 設定にサーバー側の作業が必要 |
| サイトマップ | 大規模サイトで一括管理したい | シグナルとしては弱い |
指定しても無視される条件
canonical は指示ではなくシグナルです。次の条件では、指定しても正規化に使われません。
- hreflang、lang、media、type 属性を持つ canonical:代替バージョンを示す用途とみなされ、正規化には使われない
- URLフラグメント(#以降)を含む指定:Google は通常フラグメントをサポートしていない
- HTTPヘッダーとHTML要素で違うURLを指定している:矛盾するため、どちらが採用されるか分からない
- JavaScriptで canonical を書き換えている:HTMLソースの記述と食い違うと判定が不安定になる
- 指定先の内容が大きく違う:内容が異なるページを正規として指定しても採用されにくい
4番目は実務で起きやすい問題です。クライアントサイドで描画しているサイトでは、canonical を HTML ソースコードに書き、JavaScript で変更しないことが推奨されています。HTML で設定できない場合は、HTML からは外して JavaScript でのみ設定するほうが、情報が明確になります。
指定と違うページが正規として選ばれた場合、Search Console のページレポートに「重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」と表示されます。この表示が出たら、内容の重複そのものを解消する必要があります。
canonical は指示ではなくシグナル。無視されることがある。
指定と違うページが選ばれたら、内容の重複そのものを解消する。
統合するか、残すかの判断
記事やサービスページが似ている場合は、正規 URL の指定より前に統合すべきかどうかを判断してください。
| 状態 | 判断 | 手順 |
|---|---|---|
| 検索意図が同じ。内容も重なる | 統合する | 残す側に内容を寄せ、片方から転送する |
| 検索意図は同じだが、対象読者が違う | 角度を変えて残す | 見出しと導入を書き分け、相互にリンクする |
| 語は違うが検索結果の顔ぶれが重なる | 統合する | 同上 |
| 語も検索結果も違う | 両方残す | 相互にリンクする |
| どちらも順位がついていない | 統合する | 1本に集約したほうが上がりやすい |
| 片方が上位、片方が圏外 | 統合する | 上位側に寄せ、圏外側から転送する |
判断に迷ったら、2つの語で実際に検索し、上位10件の顔ぶれが半分以上重なるかを見てください。重なるなら、検索エンジンは同じ質問として扱っています。同じ記事にすべきです。
統合する場合は、必ず転送を設定してください。ページを削除するだけにすると、それまでの評価と外部リンクが失われます。手順はURLを変えるときのリダイレクト|評価を落とさない手順と、やってはいけない転送を参照してください。
やってはいけない扱い方
Google が明確に推奨していない方法があります。いずれも実務でよく見かけます。
| やってしまいがちな対処 | 何が起きるか |
|---|---|
| robots.txt でブロックする | 許可されていない URL でも、内容なしで登録される場合がある。重複の判定もできなくなる |
| URL削除ツールを使う | その URL のすべてのバージョンが検索で非表示になる |
| noindex で正規ページの選択を妨げる | そのページが検索から完全にブロックされる |
| 方法ごとに違う URL を正規指定する | どれが採用されるか分からなくなる |
| 重複 URL のほうにサイト内リンクを張る | 希望する正規 URL が伝わりにくくなる |
5行目は見落とされがちです。サイト内でリンクするときは、重複 URL ではなく正規 URL に一貫してリンクしてください。正規版にしたい URL へ一貫してリンクすることで、希望が伝わりやすくなります。
多言語のページを持つ場合は、hreflang を使うときに同じ言語の正規ページを指定してください。同じ言語のページがない場合は、最適な代替言語のページを指定します。
確認する手順
重複の状態は、次の順で点検できます。
- Search Console のページレポートを開く:登録されていない理由の一覧を見る
- 「代替ページ(適切な canonical タグあり)」の件数を見る:意図した設定なら正常
- 「重複しています」の項目を開く:指定と違うページが選ばれているものを抽出する
- URL 検査で個別に確認する:ユーザーが指定した正規 URL と、Google が選択した正規 URL を突き合わせる
- 食い違っているものだけ対処する:内容の統合か、canonical の修正
4番目の画面では、こちらが指定した URL と、Google が実際に選んだ URL の両方が表示されます。ここが一致していれば対処は不要です。登録状況の切り分け全般はページがインデックスされない原因と確認の順序|検索に出ない状態を切り分けるを参照してください。
よくある失敗
重複を罰則だと思って慌てる
意図せず生じた重複に罰則はありません。起きるのは評価と数値の分散です。落ち着いて優先順位をつけてください。
robots.txt で重複ページを隠す
ブロックしても登録される場合があり、重複の判定もできなくなります。canonical を使ってください。
すべての重複に対処しようとする
小規模なサイトでは、指定がなくても適切な URL が選ばれます。Search Console で実際に食い違っているものだけを直してください。
統合せずに canonical だけで済ませる
検索意図が同じ記事が2本ある状態は、canonical では解決しません。内容を1本に寄せてください。
削除だけして転送しない
それまでの評価と外部リンクが失われます。統合時は必ず転送を設定してください。
よくある質問
他社サイトに自社の記事を転載された場合はどうなりますか
転載元と転載先のどちらが正規として扱われるかは、Google の判断になります。自社側の対策としては、公開日が明確であること、サイト内から一貫してリンクされていること、独自の情報が含まれていることが有効です。悪質な場合は削除の申し立てという手段もあります。
同じ商品を色違いでページ分けしています。統合すべきですか
色ごとに検索されているなら残す価値があります。検索されていないなら1ページにまとめ、色は選択肢として持たせるほうが管理しやすくなります。商品ページの設計は商品ページのデザインで購入率は変わるのか|見せる順序と、離脱を生む要素を参照してください。
パラメータ付きのURLは全部対処が必要ですか
必須ではありません。ただし広告用のパラメータが検索結果に表示されている、解析で数値が分かれているといった実害があるなら、canonical で正規 URL を指定してください。
canonical を設定してからどのくらいで反映されますか
再度クロールされるまで反映されません。数日から数週間かかります。URL 検査で登録をリクエストすると早まる場合がありますが、確実ではありません。
CMSを使っていてHTMLを編集できません
多くの CMS には、検索エンジン向けの設定画面から正規 URL を指定する仕組みが用意されています。WordPress であれば SEO 関連のプラグインで設定できることが一般的です。CMS の選定と運用設計は更新しやすい企業サイトの作り方|CMS選定と運用設計のポイントを参照してください。
まとめ
似た内容のページが複数あること自体に、罰則はありません。実際に起きるのは、外部リンクとサイト内リンクの評価が複数の URL に分かれること、検索結果に想定と違う URL が表示されること、解析の数値が分割されることです。直すべきなのはこの分散であって、重複という状態そのものではありません。
対処の順序は明確です。末尾スラッシュ、www、https のような URL の揺れは転送で解決します。パラメータや絞り込みのように、ページ自体に存在意義があるものは canonical で正規 URL を指定します。そして記事やサービスページの内容が重なっている場合は、canonical ではなく統合を検討してください。canonical は URL の重複を解決する手段であって、同じ質問に答える記事が2本ある状態は解決しません。
最後に、対処する範囲を広げすぎないでください。Google は正規 URL の指定を推奨としていますが、必須とはしていません。小規模なサイトであれば、指定がなくても適切な URL が選ばれます。Search Console のページレポートで、指定と実際の選択が食い違っているものだけを抽出し、そこに絞って直すのが最も費用対効果の高い進め方です。
当社ではホームページ制作において、サイト構造の整理とURL設計をご相談いただけます。自社サイトの状態を点検したい場合は、資料をダウンロードのうえご活用ください。