制作会社のディレクターが喜ぶコンポーネント設計の5つの条件

はじめに

制作会社でディレクターをされている方から、こんな相談をいただくことがあります。「公開後に『ボタンの文言を変えたい』『事例をひとつ足したい』という依頼が来るたびに、コーダーへ戻して見積もりを取っている。クライアントには待ってもらい、社内では工数が積み上がる」。修正そのものは数分で終わるのに、やり取りのほうに時間がかかっている状態です。

原因の多くは、ページが「1枚の絵」として作られていることにあります。見出し、カード、ボタンといった要素が、ページごとに少しずつ違う形で組まれていると、ひとつ直すたびに全ページを確認しなければなりません。逆に、要素を「部品」として設計し、同じ部品を全ページで使い回していれば、直す場所は1か所で済みます。

この記事では、ディレクターの手元で運用が完結する「気の利いたコンポーネント設計」の条件を5つに整理します。書いているのは、制作会社の外注コーダーとして案件をお受けしている立場からです。コードの書き方ではなく、ディレクターがコーダーに「こう作ってほしい」と伝えるための判断基準としてお読みください。

コンポーネント設計とは何か

コンポーネント設計とは、Webサイトを構成する要素を「使い回せる部品」として定義し、ページはその部品を並べて作る、という考え方です。家づくりにたとえると、窓やドアを現場で一枚ずつ手作りするのではなく、寸法の揃った規格品を用意しておき、間取りに合わせて配置していく方法にあたります。

部品として設計するメリットは、修正の影響範囲がはっきりすることです。「カード」という部品の角丸を変えれば、サイト内のすべてのカードが同時に変わります。ページごとに作り込んだサイトでは、同じ変更に対して1ページずつ手作業が必要になり、見落としも起きます。

ただし、部品化しただけでは運用は楽になりません。部品の作り方が悪ければ、「部品化しているのにページごとに作り直している」状態になり、かえって保守が難しくなります。 ディレクターが押さえるべきは、コンポーネントという言葉そのものではなく、「どんな部品なら更新のたびにコーダーへ戻らずに済むか」という基準です。

更新のたびにコーダーへ戻ってくるサイトの共通点

コーダーとして案件を引き継ぐと、修正のたびに工数がかさむサイトには共通点があります。ディレクターの立場でチェックできる兆候として、3つ挙げます。

ひとつめは、似た部品が少しずつ違う形で複数あることです。「ボタン」がページによって高さや余白が違う、「カード」が3種類あるのに使い分けの基準がない、という状態です。ボタンの色を変えたいだけなのに、どのボタンを直すのか確認するところから始まります。

ふたつめは、文字数が変わると崩れることです。デザインカンプの文言がそのまま前提になっていて、見出しが2行になった途端にレイアウトが崩れる部品は、運用の現場で最も多く手戻りを生みます。クライアントが入力した文言に合わせてコーダーが調整する、という流れが固定化します。

みっつめは、編集画面で触れる範囲が決まっていないことです。WordPressの編集画面で、どこまでがディレクターの変えてよい場所で、どこからがコーダーの領域なのかが曖昧なままになっています。すると、触って壊すのが怖いという理由で、結局すべてをコーダーへ戻すことになります。問題は修正の難しさではなく、「誰がどこまで触ってよいか」が設計されていないことです。

気の利いたコンポーネント設計の5つの条件

ここからが本題です。制作会社の外注案件で、納品後の修正依頼が減った設計に共通していた条件を5つにまとめます。ディレクターがコーダーへ依頼するときの確認項目として使えるように書きます。

条件1：部品の種類を絞り、違いは「差し替え」で吸収する

部品は種類が少ないほど運用しやすくなります。目安として、コーポレートサイトなら部品の種類は20前後に収まるのが健全です。見出し、本文、ボタン、カード、画像とテキストの組み合わせ、お知らせ一覧、CTA、といった単位です。20前後という数字は、後述する部品表がA4で1〜2枚に収まり、新しく担当になったディレクターが半日で全体を把握できる上限として置いています。

大切なのは、「青いボタン」「白いボタン」「大きいボタン」を別々の部品にしないことです。部品は1種類にして、色や大きさは設定で切り替える。 店舗運営でいえば、メニューの品数を増やすのではなく、同じ料理にサイズと辛さの選択肢を付ける考え方です。品数が増えるほど仕込みも在庫管理も重くなるのと同じで、部品の種類が増えるほど修正の確認箇所が増えます。

コーダーへの依頼としては、「バリエーションは新しい部品を作らず、既存部品の設定として追加してほしい」と伝えるだけで、設計の方向が大きく変わります。

条件2：名前を見れば用途が分かる

部品の名前は、コードの中だけでなく、WordPressの編集画面やデザインデータでも同じ名前で通します。「カード（事例）」「カード（サービス）」のように、ディレクターが日本語で呼んでいる名前と、コーダーがコードで付けている名前が一対一で対応している状態が理想です。

名前が揃っていると、修正依頼の文面が短くなります。「トップの真ん中あたりの四角いやつ」ではなく「サービスカードの3枚目」と書けば、コーダーは確認なしで着手できます。逆に名前が揃っていないと、修正のたびにスクリーンショットを撮って場所を説明するやり取りが発生します。

ディレクターが決めるべきことは、部品の名前を最初に一覧にしておくことです。コーダー側は、その一覧に合わせて命名すればよいだけになります。

条件3：文字数が2倍になっても、空でも崩れない

デザインカンプの文言は、ほとんどの場合「収まりのよい長さ」で書かれています。実際の運用では、見出しが2行になり、ボタンの文言が「詳しく見る」から「サービスの詳細を確認する」に伸び、事例が1件しかない月もあります。

部品は、文言が最短でも最長でも、件数が0でも崩れないように作っておく必要があります。これはコーダーが「文字数を2倍にしたとき」「空にしたとき」「件数を1件と9件にしたとき」の3パターンで表示を確認する、という作業で担保できます。1件と9件を選ぶ理由は、1件では中央寄せか左寄せかの判断が表に出て、9件では3列で割り切れない最後の行の見え方が表に出るからです。崩れやすい条件を先に踏んでおくと、公開後に想定外の件数で崩れることが減ります。納品前のチェック項目として、ディレクターから「文字数を変えた状態のスクリーンショットも添えてほしい」と依頼するのが確実です。

この確認を省くと、公開後にクライアントが入力した文言で崩れ、「文言を短くしてください」とクライアントへお願いする流れになります。クライアントから見れば、伝えたいことを削らされる体験です。文字数に合わせてデザインを守るのはコーダーの仕事で、デザインに合わせて文字数を削るのはクライアントの仕事ではありません。

条件4：WordPressの編集画面から逆算して設計する

部品の設計は、コードの都合ではなく、ディレクターやクライアントが触る編集画面の側から考えます。WordPressのブロックエディターであれば、部品はブロックパターンとして登録します。そのうえで、変えてよい場所（文言・画像・リンク先）だけを編集できるようにし、構造や余白は触れないように固定します。

編集画面で変えられる範囲を限定するのは、不親切ではなく親切です。家でいえば、住む人が自由に変えてよいのは家具や照明で、柱や配管には触らないように仕切られているからこそ、安心して模様替えができます。触ってよい範囲が明確な編集画面は、「壊すのが怖い」という理由でコーダーへ戻す件数を減らします。

コーダーへ依頼するときは、「この部品で、ディレクターが変える項目はこの3つ」と、編集項目を先に決めて渡します。コードの構造は、その編集項目を満たす形でコーダーが決めればよいことになります。

条件5：例外はページ固有の部品として隔離する

どんなに整理しても、「トップページだけ特別なレイアウトにしたい」「キャンペーンページだけ色を変えたい」という要望は出ます。ここで共通部品に例外を足し始めると、部品の種類が増殖して条件1が崩れます。

例外は、共通部品を改造するのではなく、そのページ専用の部品として別に作ります。名前にも「トップ専用」「キャンペーン専用」と分かる印を付けておきます。専用部品は多少コードが重複してもかまいません。共通部品に例外を混ぜて全ページに影響させるより、専用部品として隔離したほうが、あとで消すのも変えるのも簡単です。

ディレクターとしては、例外の要望が出たときに「これは共通で使う可能性があるか、このページだけか」を判断してコーダーに伝えると、設計の判断が速くなります。

納品時に「部品表」を添えると担当が変わっても止まらない

5つの条件を満たした設計を、運用の現場で生かすために、納品時に添えてほしいものがあります。部品の一覧表、いわば「部品表」です。建築でいう仕様書と同じで、どの部品が、どのページで、何を編集できるかを1枚にまとめたものです。

部品表に載せる項目は4つで足ります。部品の名前、用途、編集画面で変えられる項目、使われているページです。たとえば1行はこのようになります。「サービスカード｜サービスの紹介｜見出し・説明文・画像・リンク先｜トップ、サービス一覧」。20前後の部品なら、A4で1〜2枚に収まります。

部品表があると、担当ディレクターが変わっても、クライアントの担当者が変わっても、「どこを触れば何が変わるか」が引き継がれます。修正依頼を受けたときも、部品表を見て「これは編集画面で完結する」「これはコーダーへ依頼する」の切り分けが、ディレクターの手元でできるようになります。コーダーへ戻す件数が減るのは、コードが良いからだけではなく、「戻さなくてよい」と判断できる材料が手元にあるからです。

コーダーへの依頼は「納品時に部品表を付けてほしい」の一言で足ります。設計の段階から部品表を意識して作ると、条件1から条件5も自然に満たされる、というのが実務での実感です。

よくある質問

コンポーネント設計を依頼すると、制作費や納期は増えますか。

初回の制作では、部品の設計と文字数検証の分だけ工数がわずかに増えます。ただし量産ページの実装は速くなるため、5ページを超えるサイトでは全体の工数はほぼ変わらないというのが経験上の感覚です。公開後の修正で見積もりが発生する回数が減る分、運用期間を含めた総コストは下がります。

デザイナーがカンプを作る段階で、コンポーネント設計を意識してもらう必要はありますか。

あると理想的ですが、必須ではありません。カンプがページ単位で作られていても、コーダー側で共通部品を抽出して設計できます。ただし、同じ役割の要素がページごとに微妙に違うデザインになっている場合は、どれに統一するかをディレクターが判断する場面が出ます。

既に公開しているサイトを、あとからコンポーネント設計に作り直せますか。

可能ですが、全面リニューアルに近い工数になります。現実的なのは、修正依頼が多い部品（お知らせ一覧、事例カード、CTAなど）から順に部品化していく方法です。まず部品表を作って現状を棚卸しし、修正頻度の高いものから着手します。

WordPress以外のCMSや静的HTMLでも、同じ考え方は使えますか。

使えます。5つの条件はCMSに依存しない設計の基準です。静的HTMLの場合は編集画面がないため、条件4は「コーダーが修正するときに触る範囲を限定する」という意味に読み替えます。部品表はどの環境でも有効です。

部品の種類が20前後という目安を超えたら、どうすればよいですか。

まず、色や大きさだけが違う部品を1つにまとめられないかを確認します。次に、1ページでしか使っていない部品を「ページ専用」として別枠に移します。この2つの整理で、共通部品は多くの場合20前後に収まります。

まとめ

制作会社のディレクターが喜ぶコンポーネント設計とは、公開後の修正がコーダーへ戻らず、編集画面の中で完結する設計です。条件は5つでした。

そして納品時には、部品の名前・用途・編集項目・使用ページをまとめた部品表を添えてもらいます。

次のアクションは、いま進行中の案件のコーダーへの依頼文に、次の3行を足すことです。「バリエーションは既存部品の設定で」「文字数を変えたスクリーンショットも添付」「納品時に部品表を」。この3行で設計の向きが変わり、公開後のやり取りが目に見えて減ります。