スタイルガイド

スタイルガイドの存在は今となっては新しいものではなく，多くの事例やツールが公開されています。斉藤氏はスタイルガイドをいくつか紹介しました。

• GitHubのStyleguide：社外にスタイルガイドを公開した，はじめての会社だと考えているとのこと。
• スターバックスのStyle Guide：スターバックスのブランドを守るために作られている。完全に手作り。
• MailChimp's pattern library：細かいところまで設計されているのと，MailChimpそのものがかなり優秀なデザイナーが集まっている会社なので，すごく参考になる資料。
• Website Style Guide Resources：Anna Debenham氏とBrad Frost氏によるスタイルガイドを含めたリソースサイト。ゲストも出演しているPodcastも参考になる。

スタイルガイドを書くためのツール

これらのスタイルガイドのような文書は最大の弱点を持っているとし，それは文書が嘘をつくことだと斉藤氏は指摘します。「⁠Webサイトは変化の激しい生きものなので，仕方がない部分もある。嘘を回避するうえで重要なのはツール」と話しました。

スタイルガイドを生成するツールは，もはや数えきれないくらいに存在しています。多くのツールでは，CSS上のコメントにMarkdown形式で説明を書いたり，HTMLのスニペットを書いたりして生成します。

斉藤氏は，数あるスタイルガイドの中でも，とても頻繁に更新されているプロジェクトとして次の3つを紹介しました（Website Style Guide Resourcesにもたくさんツールが紹介されているとのこと⁠）⁠。

• Knyle Style Sheets（KSS⁠）⁠：元GitHubで働いていたKyle Neath氏が作ったもの。Rubyで書かれている。このおかげでこの後に続くツールがたくさん出てきたとのこと。
• kss-node：Node.jsで書かれたKSS。
• Hologram：カスタマイズ性が高く，様々なことを簡単に更新することができる。その代わりにコードもたくさん書く必要がある。Rubyで書かれている。

まだ導入していない人はどれか一つで構わないので，試してみると良いとし，斉藤氏は「人は実際に見えるもの，動くものに対して意見を言いやすい。ブラウザ上で動作するスタイルガイドの元にした議論は非常にしやすいもものだと」と述べました。後述するプロトタイプの作成を加速させるのもスタイルガイドの役割だとしました。

また，スタイルガイドはドキュメントとしても有用ですが，それよりもサイトのUIの現状を別にコピーして組み合わせたり，変形させたりするために欠かすことができないツールだと指摘しました。

プロトタイプ

ブラウザ上でデザインする際，一貫して伝えたいメッセージは「プロトタイプをさっさと作れ」ということと語る斉藤氏。この言葉は，斉藤氏自身が好きなUNIX哲学の3つ目だと話します。

そして，「⁠モックアップをきれいにコーディングするだけでなく，アニメーションやインタラクション全体を見通すことができるプロトタイプは，フロントエンドエンジニアにとって有用なワークフロー。どれくらいすばやく議論の元となるプロトタイプを作れるのか。プロトタイプの質問に対する答えにこそ，スキルや経験みたいな本質があるのかなと思っている」と述べました。

プロトタイプの作成を加速させるツールも多く存在しています。斉藤氏はいろいろなツールを試したそうですが，もっともしっくりしたツールはHTML，CSS，JavaScriptだったとし，そこで欠かせないというツールを紹介しました。

• BrowserSync：エディタで保存すると，ブラウザ上でリロードしてくれる単純なツール。Node.jsで動作する。あるブラウザ上での操作を複数ブラウザに反映させることができる機能を持っていて，とても有用。
• JS Bin：HTML，CSS，JSを記述できるエディタと，プレビュー機能がついているWebサービス（競合が多い中でJS Binを使っている理由として，作者のRemy Sharpが好きなことを挙げていました⁠）⁠。思いつきな実験的な実装とか，ごく簡単なデモを行うために利用しているとのこと。
• Google Chrome Canary：開発者ツール上でファイルを直接編集しながら微調整することはよくある。

プログレッシブエンハンスメントとWebの連続性

斉藤氏が次に話題として挙げたのが，フロントエンド界隈で現在進行形で熱いトピックだと言う，プログレッシブエンハンスメント（Progressive enhancement）です。

このプログレッシブエンハンスメントの本質については，元MozillaのエバンジェリストChristian Heilmann氏がエスカレーターに関する洞察を元に説明してると紹介しました。ここでの説明は，エスカレーターとしての階を移動するという目的に対して，最低限の機能は壊れないことです。つまり，常に階段としてフォールバックしています。一方，エレベーターは壊れたらただの箱です。もし中に入っていたら最悪の場合外に出ることもできません。この大きな違いは，プログレッシブエンハンスメントそのものだと指摘します。

Webという大きい視点でも似たようなことが起こってきたと話します。

「ブラウザやデバイス，ネットワークなどの環境はどれも不確かなものが多いにもかかわらず，HTML，CSS，JSはこれまで20年間ほど途切れることなくWebを支えきってきた。頼りなく感じることも多いが，そのおかげで時代や変化に応じてWebは形を変え多くの変化に対応してきた。しかしJavaやFlashのプラットフォームはWebを覆い尽くすだけの力もユーザもあったのに，残念ながらそうはならかなった」（⁠斉藤氏）

これはJeremy Keith氏が言った通り，Webがプラットフォームではなくて，連続性を持つものだからというのが理由だと言います。JavaやFlashのプラットフォームはそこに乗るか乗らないかの2択しかありませんが，Webはデジタルの世界らしくないもっとあやふやな連続性を持っているからだと説明しました。そして斉藤氏は，「⁠Webをそのものがコアの価値を失くことなく徐々に機能を拡張してきた。Webそのものがプログレッシブエンハンスメントしてきたという結果なのではないか」と述べました。

プログレッシブエンハンスメントのための戦略

斉藤氏は，プロダクトが提供する機能をどういう戦略でプログレッシブエンハンスメントしていくべきかを検討するのはフロントエンドエンジニア独壇場だと考えています。それには，いくつかの戦略があります。プロジェクトによって異なるがと注意しつつ，2つの戦略を紹介しました。

1つは，“⁠cut the mustrad⁠”という戦略です。この言葉をプログレッシブエンハンスメントの文脈で利用したのはBBC News developers blogで，エンハンスメントを受けられる最低限の基準に準拠するブラウザを調べるためのテクニックです。JavaScriptは次のようになります。

if('querySelector' in document
     && 'localStorage' in window
     && 'addEventListener' in window) {
     // モダンブラウザ
     }

斉藤氏曰く，なかなか潔い書き方だとのこと。ちなみに，BBCだけではなくThe Guardianでも利用されています。

もう1つは，“⁠grade components, not browsers⁠”という戦略です。これは，ブラウザごとに体験レイヤーを評価するのではなく，コンポーネントごとに体験レイヤーを評価するという考え方です。ニュースサイトのthe Boston Globeをレスポンシブ対応したfilament groupで採用し始めています。

例えば，次のような，とある観光地にあるにある建物を紹介するコンポーネントを考えた場合，その地図の見せ方として次のパターンが検討できます。

1. ［地図を見る］ボタンをクリックして，外部サイトで地図を見てもらう。
2. ［地図を見る］ボタン自体は削除して，Ajaxを使ってコンポーネント内にインタラクティブマップ（Google Mapsなど）を配置する。
3. CSS Transformsも使えるのであれば，［⁠地図を見る］ボタンををクリックした時に，コンテンツサイズを変えずに全域にインタラクティブマップを表示する。

このようにコンポーネントごとに体験レイヤーを評価していきます。

斉藤氏は，「⁠一見すると，これまで通りブラウザごとに体験レイヤーを評価するのと同じようにみえますが，ブラウザごとに評価することはページやシステム全体の体験のレイヤーを評価するというインテグレーションテストになっています。他方，コンポートネント単位の評価はユニットテストと同じと考えることができます」と説明しました。また，「⁠わたし自身がコンポーネントを組み合わせてシステムをデザインするたちなので，このアプローチは好き」であると述べました。