サイトリニューアルの思想と手法 コンテンツファースト、モバイルファースト、スタティックサイト

当サイトをリニューアルしました。これ自体はとても小さなプロジェクトですが、より大きなプロジェクトに向けての「スタディ」（習作）になっています。ここでいったん考えや学びを整理しておくことには意味があると考えました。

〔註：「長すぎる」(tl;dr)と思った方は、末尾の思想と手法のまとめだけでもご覧ください〕

成長するアーキテクチャ

いきなり奇妙に聴こえるかもしれませんが、今回の「リニューアル」は、決して「完成」していません。もちろん「公開できる状態になった」と判断したからこそ公開しているわけですが、まだまだ手を入れたいところも残っています。

では、なぜ「完成」する前に公開したのかと言えば、それは私が

• 成長するアーキテクチャは良いアーキテクチャだ
• 成長を止めないアーキテクチャが良いアーキテクチャだ
• アーキテクチャは決して「完成」しないものだ

と考えているからです。

なぜなら、作ってみないと分からないことも多いし、作ってから「やりたいこと」が変わることも多いからです。

私は「ある程度の完成度」になった時点で早めにリリースし、フィードバックを受けながら改善していくことを良しとします。これはアジャイルソフトウェア開発の思想に通じます。

コンテンツ・ファースト

このサイトの目的は「私の思いや考えを伝えること」です。その目的のために、コンテンツを引立てる設計を心がけました。このような設計思想を一般的に「コンテンツ・ファースト」と呼びます¹ 。

「コンテンツを引立てる」という目的を達成するためには、様々な設計方針が考えられます。今回私は「ありきたり」「特徴のない」「アノニマス²」なデザインを目指しました。

ユーザーがナビゲーションに迷うような「独創的」なUIデザインをしてしまうと、肝心のコンテンツに集中してもらうことができません。したがって、「普通こういうものは、この辺りにある」というユーザーの期待を裏切らない、「ありきたり」なデザインがよいと考えました。

お知らせの一本化

新たなサイト構造は、

1. ブログ(Blog)
2. 活動報告(Activity)
3. ポッドキャスト(Podcast)
4. 自己紹介(About)

という4つのカテゴリからなります。

リニューアルの目的のうちの一つは、このように「お知らせを一本化すること」でした。簡単に言えば「ブログっぽく」したかったのです。

そのため、外部サイト(Tumblr)にあったポッドキャストコンテンツも、当サイトに移しました³。

コンテンツの移植

今回のサイトリニューアルでは、以前のコンテンツを引き継ぎました。「引き継いだ」と口で言うのは簡単ですが、実際には膨大な手作業が発生しました：

• 全コンテンツの棚卸し、剪定（不要なコンテンツの破棄）
• 全コンテンツのサムネイル画像の制作
• 全コンテンツのタイトルと概要文に手入れ
• 引用画像の出典表記に漏れがないか点検・修正
• ディレクトリ構造の変更とリダイレクトの設定
• リンク切れの点検と修正
• 全ポッドキャストエントリの移植

このような（個人サイトとしては）大量の編集作業が大変でした。機械的な繰り返し作業については、正規表現などを活用して自動処理することができました。しかし、自動化できない「手作業」も膨大に発生しました。かなりのコストです。とはいえ、こういった作業も「コンテンツの価値を維持するための必要コスト」だと考えました。

マテリアル・オネスティ

ウェブページはHTMLで出来ています。私は「HTMLの素材感」をそのまま出したようなデザインが、わりと好きです。こういったデザインスタイルは、マテリアル・オネスティ（素材に忠実であること）という概念と関係しています。

例えば、ブラウザのデフォルト動作を「否定」して「上書き」するような設計は、アクセシビリティやユーザビリティのうえで好ましくありません。勝手な「自分流」のウェブデザインよりも、「ウェブらしいデザイン」のほうが良いデザインだと考えています。

ネイティブアプリを模倣したようなデザインも、私好みではありません。いわゆるスキューオモーフィック(skeuomorphic)なデザインは好ましく思っていません。

ウェブに向いていない視覚表現（例えば縦組みなど）も避けたいと思います。「文字組みを画像化することで見た目を固定する」といった手法も拒否します。なんとか「見た目」は意図通りになるかもしれませんが、「見た目以外の部分」が犠牲になってしまうからです。

素材（マテリアル）としてのウェブの特性は、「見える部分」だけでなく、「見えない部分」にもあります。つまり、HTMLマークアップによるセマンティクスと、それによって実現されるマシン・リーダビリティが重要なのです。

ウェブサイトの設計においては、「見えない部分」をケアすることが重要です。そのことは、これから説明する「アクセシビリティ」や「プログレッシブ・エンハンスメント」にも直結します。

アクセシビリティ

コンテンツ・ファーストという設計思想の延長で、「あらゆるデバイスからアクセスできること」を重視しました。この考え方を「アクセシビリティ・ファースト」といいます。

私が書く文章の中には、「5年後、10年後に誰かが読んだときにも役に立って欲しい」と願いつつ書いたものが少なくありません。ただし、そんな未来には、きっとコンテンツにアクセスするための環境やデバイスも、いまとは様変わりしていることでしょう。

未知のデバイスのために、あらかじめ備えておきたい。そのための指針となるのがウェブ・アクセシビリティの各種ガイドラインです。とくにウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 2.0が有名です。それらのガイドラインを意識しながら設計し、下記のテストを行いました：

• HTML Markup Validator（マークアップの検査）
• Accessibility Developer Tools（各種の機械的な検査）
• modern.ie（多様なブラウザでの表示確認）
• iOSのVoiceOver（スクリーンリーダー）
• Mac OS XのVoiceOver（スクリーンリーダー）
• Contrast Ratio（カラーコントラストの検査）

本格的なアクセシビリティテストではありませんし、WCAGのレベルAにも達していません⁴。しかし、アクセシビリティへの取り組みは、決して完璧でなくても、やらないよりはましです。「アクセシビリティ・ファースト」だからといって「レベルAの達成が必須」などと窮屈に考えるよりは、やれるところから手を付けていくほうが前向きです。

それに、WCAGのレベルAを目標にするとしても、最初のリリース時から達成する必要もないのです。アジャイルソフトウェア開発の考え方で、リリース後に少しずつ達成度を上げていってもいいのですから。

モバイル・ファースト

「モバイル・ファースト」という設計アプローチも少し意識しました。

従来のウェブ制作では「PC向けデザインを元にモバイル対応する」という順序が普通でした。一方、モバイル・ファーストでは「モバイル向けデザインを元にPC対応する」という順序で制作します。

そのメリットとして下記の3点が指摘されています：

1. いま最も普及しているデバイスがスマートフォンなので、PCよりもスマートフォンにおける使いやすさを優先するのは当然です。
2. 「画面サイズの小ささ」などの制約が、設計者に「フォーカスすること」を促します。厳しい制約が「このサイトで最も重視すべきことは何か」を考えさせるのです。
3. 最新のウェブ技術でサイトを制作するなら、そのターゲットはモバイルデバイスになるでしょう。PCユーザーの多くがまだ古いブラウザを利用しているのに対して、モバイルユーザーのほうが比較的新しいブラウザを利用しています。

これらがモバイル・ファースト・アプローチの利点だとされています。

プログレッシブ・エンハンスメント

今回のリニューアルでは「モバイル・ファースト」の考え方を取り入れつつ、しかし「たまたま現時点で普及しているに過ぎないモバイルデバイス」に対して最適化し過ぎないことも心がけました。要するにバランスを取ったわけです。

モバイル・ファーストという考え方は、あくまで「いま普及しているモバイルデバイスを重視する」という考え方です。しかし、将来にわたってモバイルデバイスが最普及デバイスであり続けるとは限りません。

また、「モバイルデバイスなら最新ウェブ技術を利用しやすいので、モバイル・ファーストに制作する」という考え方が行き過ぎれば、「低機能デバイスからはアクセスしずらいコンテンツ」が出来上がってしまうおそれもあります。

私の目的は「コンテンツを長寿にすること」ですから、プログレッシブ・エンハンスメントという考え方を意識しました。これは「原則としてどんな閲覧環境からでも最低限利用できるようにしたうえで、段階的に高機能な実装を適用していく」という考え方です。

実際、スタイルシートやJavaSciptを無効にしても、このサイトはそれなりに利用できるはずです。また、10年後のユーザーがこのサイトのコンテンツを利用できる可能性も、十分に高いと考えています。

インブラウザー・デザイン

インブラウザー・デザイン手法は、コンテンツ・ファーストやアクセシビリティ・ファーストといった思想と相性の良い手法です。プロジェクトの全工程に渡り、「インブラウザー」（ブラウザー内）で確認しながらデザインします。そのプロセスを説明します。

最初に、静的サイトジェネレーターJekyllのテンプレート構造を慎重にデザインしました⁵。レイアウトとマークアップの骨格を手でササッとスケッチし、それをすぐにHTMLとスタイルシートで再現し、PCとモバイルデバイスのブラウザで、レスポンシブな動作を確認します。これを何度も繰り返すプロトタイピングを行いました。

次に、コンテンツを移植しました。前述の通り大量の作業であり、最も時間を要した工程です。コンテンツのタイトル、概要文、サムネイル画像などを「インブラウザー」で何度も確認しながら整えていきました。

コンテンツを投入したら、次は視覚的なデザインです。CSSフレームワークBittersを使って、レイアウトやタイポグラフィをカスタマイズしていきました⁶。配色に際してはHUE/360と配色の見本帳を利用しました。

以上がデザインプロセスの全体像です。最初から様々なデバイスのブラウザや、各種のツールでテストしながら制作したので、レスポンシブなモバイル対応や、アクセシビリティ品質の確保にも、さほど苦労しませんでした⁷。もしもこのような検証を、制作プロセスの後半で行っていたとしたら、大量の手戻りで苦労していたことでしょう。

さきほど私は「ウェブサイトの設計においては、見えない部分へのケアがまず大事で、見える部分はその次だ」と述べました。そのような順序で物事を進めるためには、インブラウザー・デザイン手法にならざるを得ないのです。ちなみに、デザインカンプは一つも作りませんでした。

コンテンツを大事に取り扱い、アクセシビリティを担保しながら、レスポンシブにモバイル対応もする。インブラウザー・デザイン手法なら、これらを低コストで実現できます。

静的サイト

コンテンツを10年単位でロングライフ（長寿）にするために、メンテナンス・フリーにしようと思いました。

WordPress等の動的システムを導入すると、しばしばメンテナンス作業が発生します⁸。一方、静的サイトならば基本的にメンテナンスフリーです。

静的サイトはメンテナンスフリーなだけでなく、ポータブル（移動しやすい）でもあります。単にファイルをコピーするだけで、サイトの「移動」や「ミラーリング」や「アーカイブ」が簡単にできます。

実際、このサイトのリニューアル前のコピーはAmazon S3にアーカイブしてあります。この「旧サイト」は、Amazon S3が存在し、かつ利用料金を支払い続けている限り、ずっとアクセス可能です。例えば私の死後も、クレジットカードと口座が生きている限り、サイトは存在し続けます⁹。

また、新サイト（このサイト）をホストしているGitHub Pagesは無料です。GitHub Pagesがどれほど長く続くサービスかは分かりませんが、このサービスが続く限り、このサイトが存在し続ける可能性は高いと期待できます¹⁰。

GitHub Pages

このサイトの制作には静的サイトジェネレーターJekyllを採用しました。また、サイトはGitHub Pagesによってホストされています。

GitHub Pagesのメリットはいくつかあります：

• FTPなどの転送作業が不要です。ソースをcommitしてGitHubにpushすれば、サイトに編集内容が反映されます。どうせGitは使うわけですから、サイト更新のための余計な手間が省けます¹¹。
• 静的サイトジェネレーターの中でも特に人気の高いJekyllが採用されています。長期的に利用していく上での安心材料になります。
• 無料でウェブサイトをホストしてくれます。独自ドメインも利用できます。設定も簡単です。
• ブラウザだけでもサイトの更新ができます。

最後の点について補足しておきます。一般的に「静的サイトジェネレーター」で作られたサイトは、ブラウザだけで更新することができません。しかし、GitHub Pagesの場合、ブラウザでGitHub上のソースを編集すれば、サイトを更新できます¹²。いつか「急に更新しなければならない事態」が生じたときには、この機能に助けられるかもしれません。

アーキテクチャ

このサイトのシステムアーキテクチャは下図のようになっています：

また、システムアーキテクチャの構成要素は下記の通りです：

• Bourbon: Sass mixinライブラリ
• Neat: Bourbonによるレスポンシブグリッドフレームワーク
• Bitters: BourbonとNeatによるCSSフレームワーク
• GitHub Pages: Jekyll対応のホスティングサービス
• Jekyll: 静的サイトジェネレーター
• Liquid: Jekyllで採用されているテンプレートエンジン
• Sass: Jekyllで採用されているCSS拡張言語

このアーキテクチャによって、コンテンツ・ファーストの思想を実装しました。この手法には、より大きなプロジェクトにも適用できるスケーラビリティ（拡大可能性）があるはずです。

もちろん、このままでは大きなプロジェクトに適用できません。しかし、Jekyll、GitHub Pages、Bittersといった「固有名詞」は入れ替え可能です。アーキテクチャを抽象的に考える場合、そういった固有名詞は、さほど重要ではありません：

さらに、前提条件が少し違うプロジェクトでも、その前提条件にあわせてアーキテクチャを変更すれば大丈夫です。例えば、「メンテナンスフリー」な静的サイトではなく、データベース連動型の動的サイトを作る場合でも、「静的サイト」の部分を除けば、ほぼそのまま応用できるはずです。

このように、アーキテクチャは抽象化によってスケーラビリティを獲得します。アーキテクチャの具体的な構成要素に注目するだけでなく、抽象化して眺めてみることには大きなメリットがあります。具体的な構成要素を置き換えれば、異なる前提条件のプロジェクトにも応用できるのです。

思想と手法

アーキテクトが新しいアーキテクチャに挑むときには、小規模なプロトタイピング・スタディがとても有効です。そして、アーキテクトというものは、「自分のデザイン思想とデザイン手法」を持って、はじめて一人前なのだと思います。そういう思いから、今回のリニューアル作業には、かなりの時間を投資しました。プロトタイピング・スタディによって「自分のデザイン思想とデザイン手法」を研究するために。

最後に、ここまで説明してきた思想と手法の関係を図解しておきます：

結び

以上が、今回のリニューアルについての報告です。私はこのアーキテクチャを持続的に成長させ、また別のサイトにも適用していくことになるでしょう。¹³

なお、このサイトのソースコードはGitHubで公開されており、誰でも自由にclone/forkできる状態になっています。本稿執筆時のコミットは3f5135cです。また、リニューアル前のサイトのコピーをAmazon S3にアーカイブしてあります。