制作会社のディレクターが泣いて喜ぶ、気の利いたコンポーネント設計5選

はじめに

「見出しの文言を差し替えたら、スマホ表示でレイアウトが崩れた」「同じ修正を10ページ分、1つずつ依頼する羽目になった」。コーディングを外注しているディレクターの方なら、一度は経験があるのではないでしょうか。

こうした手戻りの原因は、コーダーの作業が遅いからでも、指示書の書き方が悪いからでもありません。多くの場合、納品されたコードの「コンポーネント設計」に問題があります。逆に言えば、設計の行き届いたコーディングパートナーと組めば、修正ラリーは驚くほど減ります。

筆者は制作会社さまからコーディングを継続してお預かりする立場で仕事をしています。その現場感から、ディレクターの仕事が楽になる「気の利いたコンポーネント設計」の共通点を5つに整理し、コードが読めなくても外注先の品質を見分けられるチェックポイントまで紹介します。

コンポーネント設計とは？サイトを「規格部材」で組み立てる考え方

コンポーネント設計とは、Webサイトを「ページの集まり」ではなく「部品（コンポーネント）の集まり」として捉え、ボタン・見出し・カードといった部品を先に作り、それを組み合わせてページを構成する考え方です。

家づくりに例えると分かりやすくなります。柱や窓を1本ずつ現場で手作りする家は、職人の腕次第で品質がばらつき、後から修理しようにも同じ部材が手に入りません。一方、規格化された部材で組み立てる家は品質が安定し、交換も増築も簡単です。コンポーネント設計は、Webサイトを後者のやり方で作る技術だとお考えください。

部品の集合としてページを組み立てる

たとえば「お知らせカード」という部品を1つ作っておきます。すると、トップページの新着3件にも、お知らせ一覧の20件にも、記事下の関連コンテンツにも、同じ部品を呼び出すだけで済みます。見た目が自然に揃い、実装スピードも上がります。

部品には大きさの段階があります。ボタンのような最小単位、それを含むカード、カードを並べたセクション、という入れ子の関係です。この粒度の分け方を体系化したものがAtomic Designと呼ばれる有名な手法ですが、名前を覚える必要はありません。大事なのは「どこまでが使い回す共通部品で、どこからがそのページだけの一点物か」を、デザインの段階でコーダーと合意しておくことです。ここが決まっていると見積もりの精度が上がり、後出しの追加費用も減ります。

なぜ設計の質が修正ラリーの数を決めるのか

部品化されていないコードでは、同じ見た目のボタンがページごとに別々に書かれています。たとえば10ページのサイトで、1ページあたり3か所にボタンが置かれていれば、それだけで30か所。「ボタンの角丸をやめたい」という1行の指示が、30回の手作業に化けます。

人が30回同じ作業をすれば、どこかで必ず漏れます。そして数日後、「4ページ目のボタンが直っていません」という差し戻しが届く。ディレクターの体感としては「またコーダーのミスか」ですが、実態はミスではなく、30回繰り返さなければ直せない構造そのものが原因です。つまり、修正ラリーの多さはコミュニケーションの問題ではなく、コードの保守性の問題なのです。

ディレクターが泣いて喜ぶ、気の利いたコンポーネント設計5選

ここからが本題です。「このコーダーさんと組むと楽だ」と言っていただける設計には、いくつかの共通点があります。

1. カンプの呼び名と一致する命名

気の利いた設計では、デザインカンプや指示書で使われる呼び名と、コード上の部品名が一致しています。ディレクターが「料金表カードの余白を広げてください」と伝えれば、コーダーは price-card という名前の部品を探すだけ。呼び名を頭の中で翻訳する手間がなくなり、指示の取り違えも起きません。

命名ルールの代表格がBEMです。名前は難しそうですが、考え方は住所表記と同じです。Block（部品そのもの＝建物名）、Element（部品の中の要素＝部屋番号）、Modifier（色違いやサイズ違い＝同じ間取りの別仕様）の3階層で名前を組み立てます。「料金表カードの、中の、見出し」が price-card__title になる、という具合です。ディレクターがコードを読める必要はありませんが、「その部品を一意に名指しできる状態か」は品質の分かれ目になります。

2. 文字量が変わっても崩れない設計

公開後、テキストは必ず変わります。キャッチコピーが2行になる、お知らせのタイトルが長くなる、英語のサービス名が入る。気の利いたコンポーネントは、文字量が想定の倍になってもレイアウトが崩れないよう、余白と折り返しがあらかじめ設計されています。

崩れる実装の典型は、デザインカンプに書かれた文言の長さに合わせて高さや幅を固定してしまうケースです。カンプでは1行だった見出しが実運用で3行になり、下の要素と重なる。スマホでボタンの文字が折り返して、ボタンだけ縦に伸びる。いずれも公開後に必ず起きることで、想定しておけば防げます。店舗のメニュー表にたとえるなら、料理名が長くなるたびに作り直す表ではなく、どんな料理名でも収まる書式を最初に決めておくイメージです。

3. 1か所直せば全部直る共通化と、あえて分ける判断

色・余白・角丸・フォントサイズといった値を変数（デザイントークン）で一元管理していれば、「サイト全体のメインカラーを変えたい」という要望も1か所の修正で済みます。季節ごとにキーカラーを変えるようなサイトでは、この差が運用コストに直結します。

ただし、何でも共通化すればよいわけではありません。トップページ専用のファーストビューのような一点物まで無理に共通部品にすると、そこを直したときに無関係なページが崩れる、という逆の事故が起きます。共通化する部品と一点物を意図して区別しているかに、コーダーの経験の差がはっきり出ます。発注時に「ここはトップ専用です」と伝えておくだけでも、設計の精度は上がります。

4. 更新担当が触れるCMSブロック化

納品後にお知らせや実績を更新するのは、コーダーではなくクライアントの担当者です。ここを見落とすと、公開直後から「文字を1行足したい」という依頼が制作会社に舞い込み続けます。

WordPressであれば、コンポーネントを管理画面から選んで使えるブロックやパターンとして登録しておけば、担当者が自分で同じ体裁の要素を追加できます。実績紹介のカードも、料金表の行も、選んで文字を入れ替えるだけです。運用フェーズで手が離れる状態を作れると、ディレクターがクライアントに「更新はご自身でできます」と提案でき、保守契約の中身も前向きな内容に変えられます。

5. 納品時のコンポーネント一覧表

どんな部品があり、どのページで使われているか。この一覧表（スタイルガイド）が1枚あるだけで、次の改修時に「どこを触るとどこに影響するか」がすぐ分かります。

効いてくるのは半年後です。追加ページの見積もりを出すとき、既存部品の組み合わせで作れると分かれば即答できます。担当コーダーが変わったときの引き継ぎも、一覧表があるかないかで初動が数日変わります。増築のとき、設計図が残っている家と残っていない家のどちらの工事見積もりが早いかを考えれば、その価値は明らかです。

コードが読めなくてもできる、設計品質の見分け方

ここまで読んで「理屈は分かったが、発注前に見抜けるのか」と思われたかもしれません。結論から言えば、コードを開かずに判断する方法があります。

発注前に聞いておきたい2つの質問

1つ目は「クラスの命名はどんなルールで付けていますか？」。BEMなど具体的な規則名と、それを選んでいる理由がセットで返ってくれば、設計を言語化できているコーダーです。逆に「案件ごとに分かりやすい名前で付けています」という答えなら、途中で担当が変わったときに読み解けないコードになる可能性があります。

2つ目は「納品後、私たちの側で更新する箇所はどこになりますか？」。この質問に、更新頻度の高いパーツを挙げてブロック化の提案まで返ってくる相手は、運用フェーズを想像して実装する人です。コーディング外注の品質差は、技術力より「納品後を考えているかどうか」に表れます。

納品物を受け取ったときの簡単チェック

検収時には、次の3つを試してみてください。①ブラウザの幅をゆっくり縮めて、スマホ幅とPC幅の中間で崩れないか。②テスト環境で見出しや本文を長文に差し替えて、レイアウトが保たれるか。③同じ役割の部品が、別のページでも本当に同じ見た目か。

とくに②は重要です。長文を流し込んで崩れないなら、文字量の変化を想定して作られた証拠であり、公開後の更新にも耐えます。3つとも特別な知識もツールも要らず、5分あれば終わります。

まとめ

コンポーネント設計とは、サイトを部品単位で組み立てる考え方であり、その質は修正ラリーの数に直結します。気の利いた設計の共通点は、①カンプと一致する命名、②文字量が変わっても崩れない余白設計、③1か所で全体に効く共通化と一点物の区別、④更新担当が触れるCMSブロック化、⑤納品時のコンポーネント一覧表、の5つでした。

すべてを一度に確認しようとする必要はありません。発注前の「命名ルールの質問」と、検収時の「長文を流し込むテスト」。この2つだけでも、パートナー選びの精度は大きく変わります。次の案件から、ぜひ試してみてください。

よくある質問

コンポーネント設計とAtomic Designは何が違いますか？

Atomic Designはコンポーネント設計を実践するための代表的な手法の1つで、部品を原子・分子など5段階の粒度に分類する考え方です。すべての案件に5段階が必要なわけではなく、中小規模のサイトでは2〜3段階に簡略化して運用するのが実務的です。

CSS設計手法（BEM・FLOCSSなど）はどれを選べばよいですか？

中小規模サイトの受託制作であればBEMが第一候補です。採用実績が多く、途中から別のコーダーが引き継いでも読みやすい点が強みです。ただし手法の優劣よりも、1つのルールをサイト全体で一貫させることのほうが重要です。

WordPressサイトでもコンポーネント設計はできますか？

できます。同期パターン（旧・再利用ブロック）やカスタムブロックとしてコンポーネントを登録すれば、管理画面から同じ部品を何度でも呼び出せます。テーマ側のテンプレートパーツ化と組み合わせるのが定番の構成です。

すでに公開済みのサイトを、後からコンポーネント化できますか？

可能ですが、全ページの作り直しは費用対効果が合わないことが多いです。お知らせ・実績・スタッフ紹介など更新頻度の高いパーツだけを優先してブロック化する部分改修が現実的です。

コンポーネント設計を頼むと制作費は高くなりますか？

初期の設計工数は多少増えますが、ページ数が増えるほど1ページあたりの実装コストは下がります。公開後の修正依頼が減る分も含めると、数ページ規模を超える案件では総額が下がるケースが一般的です。