Site icon Tips Note by TAM

質の高いスタイルガイドを作成するために考えておくべきこと

yasuda

TAMでは規模の大きな企業さまと仕事をすることが多いので、スタイルガイドを使った案件も比較的多いです。
数百ページ規模のサイトのスタイルガイドを作成してきましたが、考え方が少しずつ固まってきました。そして、この考え方はコードを書く人だけがもっていればいいわけではなく、ディレクターやデザイナー、部分的にはクライアント（発注者）にも共有しておく必要があると感じています。

この記事を読んだあとに、スタイルガイドを作るうえで考えておくべきことを知り、全員のスタート地点を揃えることができればいいなと思っています。
コーディングの知識がないとわからない箇所もありますが、冒頭にコーディング担当者以外に向けた要約を入れているので安心してください。

内容は以下のようになっています。

スタイルガイドを使うメリットとデメリットを共有する

スタイルガイドはページ単位の工数を下げるための全体最適化の手法です。
スタイルガイドには「一定のパターンの範囲でページを作っていく」という前提条件があります。

「ページごとに改修をしたい」「製品ごとにデザインを大きく変えたい」「このページだけ余白を変えたい」といったイレギュラーが多いのであれば、スタイルガイドを使うのは最適でないかもしれません。もしくは、スタイルガイドを適応するページとそうでないページをわけて考える必要があるかもしれません。

制作者（ディレクター、デザイナー、エンジニア）は、上記のような認識を共有してからスタイルガイドを作っていかないと、本来のメリットを充分に活かせず、デザインにもコーディングにも制限がかかって、充分な品質を保てなくなってしまうかもしれません。
そもそもスタイルガイドを使うべきか？はまず考えておく必要があります。

コーディング前に情報設計とデザインを固めておく

ここからは少し具体的な進め方を説明します。

ページの量産までにスタイルガイドを固める

スタイルガイドに限らずコードは仕様の変更や追加を積み重ねるごとに乱雑（俗に言うコードが壊れた状態）になる確率が上がります。乱雑なコードは保守がしにくくなり、運用のしにくさに繋がります。リニューアルでもないとコードの整理をするタイミングを作ることはできないので、数年単位で運用しにくさが続くので避けたいところです。

スケジュールが厳しいからといって、モジュールが曖昧なままでページの量産を進めると、情報設計やデザインの変更があったときに、HTMLの修正が増えて逆に工数がかかってしまうことになりかねません。
スタイルガイドはいわば「かけ算」のようなもので、ちゃんと作れば1ページに対する工数は減らすことができます。あせらずに、確実にスタイルガイドを作ることが大切です。

とはいえ、量産や組み込みのようなアサインやスケジュールの調整は必要ですよね。ページの量産はいつ始められると考えたらいいでしょうか？
僕は以下の2つのタイミングがあるかなと思います。

  1. 理想：モジュールのコーディングがすべてできたとき。
  2. 現実：すべてのモジュールコーディングはできていないが、CSSやJSや共通ファイル（SSIやインクルードなど）で対応が可能な状態。

スケジュールが厳しい場合でも、少なくとも2の状態にもっていけるように逆算して進めることで、手戻りを最小限に抑えることができると思います。今がどの状態かはエンジニアがいちばん把握できるので、そのコントロールはエンジニアが率先していくといいです。

モジュールの棚卸しをする

スタイルガイドを構成するモジュールは一覧化しておきます。全体像を把握することで、モジュールの重複を避けたり、モジュールの仕様を明確にします。簡易なID（H-2Aは見出し2のAや、NAV-AはナビゲーションのA など） も振っておきます。
ここではディレクターとクライアントがおもに作業することになります。

ツールは「Cacoo」や「Adobe XD」のような簡易なものを使ってモジュール一覧を作るといいと思います。クライアントやディレクターはデザインツールに詳しくない場合も多いので、なるべく簡単に使えるツールを選んでおくといいですね。

具体的なビジュアルは後回しでいいので、「どんなモジュールが必要か？」「そのモジュールはどんな情報が必須か？任意の情報はあるか？」といった情報設計を全員でしていきます。そして、デザインやコーディング時に想定されることを共有して話し合います。
例えば、「こういうレイアウトのパターンが必要であれば、別のモジュールにしておいたほうが修正の対応がしやすい」「CMS側で出し分けるのかフロントエンド側で処理するのか？」「リンク範囲はどこまで？」「この2つの色はどういうときに使い分けるのか？」といったことです。
そして、それを元にデザイナーにデザインを作成・修正してもらいます。

モジュールの影響範囲を決める（ディレクター・エンジニア向け）

ここではおもにディレクターとエンジニアが考えておくべきモジュールの影響範囲について説明します。
ディレクターとエンジニア以外の方は、同じような見た目のモジュールでも、使うための条件があったり、別のモジュールとして作ったほうがいい場合があることを把握できればOKです。

コーディングをする上でいちばん難しくて重要なことは適切な名前をつけることです。名前が適切に付けられれば、コードが乱雑になるのを防ぐことができます。そして適切な名前はエンジニアだけでは決められません。
ディレクター（とデザイナー）はエンジニアと一緒に「そのモジュールはどんな場所で、どんなときに使うのか？」「そのモジュールに名前をつけるとしたら何が適切なのか？」を考えてみてください。それはエンジニアがいつも考えていることで、それが決まればコーディングの7割は終わったようなものです。

影響範囲に応じてモジュール名に名前空間をつける（エンジニア向け）

ここではおもにエンジニアが考えておくべきモジュールの名前空間について説明します。エンジニア以外の方は、最終的にそのモジュールでできることと、できないことを把握できればOKです。

モジュール名が.ModuleAや.ModuleB-redのようになることもあります。できれば.NewsListや.Heading-brandのように連番や見た目を含まない名前にしたいですが、情報設計がそうなっているのであればそれに従いましょう。もちろん相談はするべきですが、コード上でだけ名前を変えるのは避けてください。

ただ、同じような名前のモジュールが増えてしまい、「どんなときに、どこで使うものなのか」が把握しにくくなってしまうこともあります。
それが「サイト全体で共通なのか」「ホームページでだけ使うのか」「あるカテゴリだけで使うのか」といった影響範囲を、「モジュールの影響範囲を決める」でしっかりと把握して決めておきましょう。

「モジュールを組み合わせない」ということも覚えておいてください。組み合わせ始めると、小さな調整がHTML側で発生して管理しきれなくなります。レスポンシブにも対応しにくいです。
モジュールは基本的に組み合わせて使うのではなく、そのモジュール単体で完結するように大きな粒度で考えます。
例えば以下の2つの基準で粒度を決めてみてください。

  • 見出しや順序ありリストのように縦に配置していく小さなパーツ
  • 左に画像、右にテキストやリンクのように一定のパターンをもったブロック（パーツの組み合わせ）

ブロックをできるだけ作ってパターン化していくと、HTMLの修正を減らすことができるので手戻りを少なくすることができます。これ実はけっこう重要なことだったりします。

影響範囲を決めたらモジュール名にも反映します。
命名規則やルールにはECSSという考え方を取り入れています（公式ドキュメントは英語なので、考え方を日本語でQiitaにまとめています）。ECSSはOOCSSやSMACSS、BEMのようなCSS設計手法のエッセンスを取り入れながら、管理のしやすさを目指している手法です。
例えば、モジュール名は以下のようになります。

// ホームページでだけ使われるモジュールA
.home-ModuleA {}

// サイト全体で使われる順序ありのリスト
.sw-ListOrder {}

// サイト共通のグローバルナビ
.st-GlobalNav {}

// ウィジウィグ内のスタイル
. wisywig-Area {}

.home-（home-page、ホームページの）や.sw-（site-wide、サイト全体の）のような名前空間をつけることで、影響範囲をモジュール名で示しています。名前は長くなりますが、モジュール名の重複をさらに避けることができるので名前付けが楽になります。

JSの処理も基本的に名前空間ごとに書いていきます。同じ処理をなんども書くことになりますが、処理が複雑になりにくい（例外を条件分岐でわけることが減る）ので、結果的に管理がしやすくなると思います。もちろん.js-のような名前空間で共通の処理を作ることも可能です。

レイアウト専用のモジュールを作る（デザイナー・エンジニア向け）

ここではおもにデザイナーとエンジニアが考えておくべきモジュールの配置について説明します。
デザイナーとエンジニア以外の方は、スタイルガイドはモジュールだけではなくレイアウトのルールも決める必要があることが把握できればOKです。
デザイナーとエンジニアはどのようなレイアウトパターンがあればいいのかデザイン面とコード面で話し合ってください。

モジュールには基本的に上下のマージンを持たせないようにしておきます。何もしないとモジュール同士が上下にベタッと引っ付く状態ですね。
そのかわりに、レイアウト専用のモジュールを作って余白やグリッドを作ります。コーディング時に若干の手間がありますが、モジュールとレイアウトを分離したほうが管理がしやすく、イレギュラーが起きにくくなります。

注意するのはグリッドシステムです。Bootstrapのような上下に余白がつかないグリッドシステムはコンテンツ内で使うには不向きです。
例えば、スマホでは1カラムでPCでは2カラムに指定した場合にスマホで要素がくっついてしまいます。グリッドの中のモジュール自体に余白をつけると、PCの時に余分な余白が付いてしまいます。
1カラムではカラムの間に上下方向の余白がつき、2カラム以上ではカラムの間の左右方向に余白がつくようなレイアウトモジュールを作っておくと、レイアウトを柔軟に指定できます。

縦の余白を考慮したレスポンシブなグリッドシステム

ただし、（レイアウトではない）モジュールにグリッドシステムを含めたほうがいい場合もあります。そのモジュール特有の余白をつけるかもしれませんし、カラム数によってフォントサイズを変えることもあるかもしれません。

スタイルガイドの余白の設計は最初に決めておきましょう。あとから決めるということは、HTMLを修正することにつながるので、量産ページが増えるごとに手戻りが増えてしまいます。
まずは、以下のようなレイアウトモジュールを考えるといいでしょう。

  • ヘッダー、メインコンテンツ、サイドバー、フッターのような大枠のレイアウト
  • 横幅を制限するレイアウト（max-widthを使用する）
  • 見出しとセクションで使われるアウトラインのレイアウト（上下のmarginで余白をとることが多い）
  • アウトラインよりも大きな単位のレイアウト（上下のpaddingで余白をとることが多い）
  • グリッドシステム
  • テキストやモジュールで使われる余白
  • ボタンをレイアウトするためのパターン

余白設計は以前スライドを作っているので参考にしてください。

スタイルガイドを作成しやすい開発環境を作っておく（エンジニア向け）

ここではおもにエンジニアが考えておくべきスタイルガイドの開発環境について説明します。
エンジニア以外の方は、完成したスタイルガイドが自分たちの立場から見て使いやすいかを考えてエンジニアにフィードバックしてみてください。
例えば、「スタイルガイド内のコード表示部分が大きいのでモジュールが探しにくい」とディレクターからフィードバックがありました。
スタイルガイドはプロジェクトに関わる全員が使いやすいようにする必要があります。

他にもIDだけだと探しにくいこともあるので、モジュールを分類分けしておくといいです。僕は以下のようにわけることが多いです。

  • Global：ヘッダーやフッターのようなサイト全体で使われる要素
  • Layout：グリッドやコンポーネントの余白指定などのレイアウトパターン
  • Navigation：メインナビゲーションやフッターのナビゲーション、ページネーションやパンくずリストなどのユーザーを誘導することが目的とする要素
  • Image：ロゴやメインビジュアル、アバターやサムネイルや背景画像などの画像
  • Icon：用途やカテゴリーを端的に示す画像です。虫眼鏡、ソーシャルアイコン、矢印、ハンバーガーボタンなどです。
  • Form：入力エリア、Selectメニュー、チェックボックス、ラジオボタンのような、ユーザーが操作するフォーム要素
  • Button：オンオフやページ遷移、表示や非表示といった操作の切り替えに使われる要素
  • Heading：ページタイトルや見出し
  • Text：文章やラベルのようなテキスト要素
  • Link：テキストリンク
  • List：順序付きや定義リストなどのHTMLで定義されているリスト要素や、一覧や表といった形式であらわされている要素
  • Block：見出しや画像、テキストなどが1つのまとめりになっているエリア
  • InteractiveComponent：アコーディオン、タブ、カルーセル、オフキャンバスのようなユーザーの操作で稼働する要素
  • Media：ビデオやオーディオのようなリッチメディア要素
  • ThirdPartyComponent：サイト製作者側がすべてをコントロールすることができないサービス
  • Advertising：広告
  • Messaging：警告メッセージ、エラーメッセージ、ローディング、ポップアップのようなユーザーに何らかのメッセージを伝える要素

スタイルガイドはスタイルガイドジェネレーターを使って、自動的に生成されるようにしておきます。
個人的には「aigis」というツールをよく使っています（2018年2月現在、2017年9月15日以降メンテナンスがされていない状態ですので注意してください。）。

ある案件では、環境の整備が間に合わず、手作業でスタイルガイドを作ることになりましたが、メンテナンスが手間で、変更したくないという気持ちになってしまった経験があります。
スタイルガイドは最新の状態に更新し続けやすいようにしておきましょう。「スタイルガイドには書かれていないけど実はこんなモジュールがある」という状態になると、思わぬところでスタイルの上書きが発生したり、似たようなモジュールを作ってしまうことになります。

まとめ

スタイルガイドをどのように作っていくのか少し想像できたでしょうか？
今までスタイルガイドを作ったことがない方や、デザインやコーディングをしない方には「こんなに考えないといけないの？」「作りながら決めたらいいんじゃないの？」と感じたかもしれませんが、これらは考えておいたほうがいいです。
なぜなら、過去に高確率で発生した失敗を防ぐための対応策だからです。逆に言うと、公開後に「考えておいてよかった！」と感じたことでもあります。

開発環境やコードに関しては、GitHubに「Website Template」というテンプレートをあげていますので、参考にしてみてください。

さいごに、今回の内容を短くリストアップしました。スタイルガイドを作るときに、このリストを見返してみてください。

  • スタイルガイドのメリットとデメリットの認識を全員であわせる。
  • 制作者全員でモジュールの仕様を決める。どんな要素が入って、どんなページで使われる？
  • モジュールの名前は情報設計とビジュアルデザインによって決める。
  • モジュールは共通化しすぎない。必要なのは今最適化されたスタイルガイドではなく、何年も楽にメンテナンスできるスタイルガイド。
  • モジュールのコーディングをする前にスタイルガイドのクオリティのほとんどが決まる。何度も議論を重ねて作りあげていく。
  • ページの量産ができるように逆算してスタイルガイドを作っていく。スタイルガイドが機能すれば工数は減り、機能しなければ工数は増える。
  • メンテナンスは必須。メンテナンスしやすい環境を整えておく。