[37signals] Getting Real とデザイン

(原文: Getting Real and Design)

デザインプロジェクトに取り組む際の方法論として私が知っているのは一つだけだ。そこから多くのバリエーションが生じるが、本質的には、Discover（発見・問題の洗い出し）・Plan（計画立案）・Design/Develop（デザインやプログラムの実装作業）・Deployment（作業成果物の配備）という４つの段階に分けられる。受注開発であろうと社内開発であろうとこのステップを踏むことに変わりはなく、そのことを疑問に思うこともなかった。

その後37signalsからGetting Realが出版され、私はこっちの方がプロジェクトに取り組むにあたってより良いやり方なのではないかと思うようになった。私が過去に取り組んだ、あのときGetting Realがあればよかったのになぁと思うデザインプロジェクトをいくつか、みなさんに紹介したい。これらのプロセスが37signalsではどのように機能しているかについての所見もあわせて紹介しよう。

問題の洗い出しとブランドの洗礼

９０年代の終わりころ、私はOrganicというインタラクティブ分野の受注開発会社に勤務していた。そこで私は才能あふれるデザイナーやプログラマー達と共に、商用サイトの再デザインに関する作業を行っていた。プロジェクトの開始早々、我々は「発見フェーズ」と呼ばれるものを放棄する事にした。３週間というもの、店舗サイトを訪れ、雑誌の切り抜きが散乱する戦略会議室を作り、ベン図とブランドに関する○×表を作った。

アートディレクターは素晴らしいクリエイティブ・ブリーフ（訳注:広告の目的・広告のターゲット・商品の特徴などで構成された、広告指針をまとめた書類）を作り、ミネアポリスにいるクライアントの上層部に向けてプレゼンを行った。プレゼンの結果は惨憺たるものだった。その理由は、我々の出した結論や調査結果が的外れだったからではない。実際に目に見えるWebページデザインを提示しなかったからなのだ。３週間と予算の15%をつぎ込んで我々がやってのけたことは、顧客がとうの昔に知り尽くしていた事を馬鹿面下げて語ったということだけだったのだ。

発見フェーズが必要になることもあり、受注開発の場合は特にそうだ。しかしこれは切り捨てることも可能だ。クライアントの上層部に現状認識をするチームがいればいいのだ。最初のプレゼンで現状のデザインに関する処置を盛り込めるよう、彼らと共同で作業するというのはどうだい？ そうすればこのステップは省けるし、予算も節約出来るし、より速やかに作業成果をクライアントに提供出来る。クリエイティブ・ブリーフも結構だが、実際のデザインはさらに結構なのだ。

ワイヤフレームとスタイルガイド

Crate & Barrel（訳注:家具や台所用品の会社）でも、発見フェーズを省略してすぐにワイヤフレーム（訳注:骨組みだけのデザイン）にとりかかるという点以外は、同じステップを踏んだ。ワイヤフレームでのプレゼンはあくびが出るほど退屈だ。販売責任者や部門長達にとって、ワイヤフレームを見ただけで正確に理解するのは困難だからだ。みんなと同様、彼らも「デザイン」が見たいのだ。プレゼンが現実に即したものになればなるほど、彼らからフィードバックや指示を得るのが容易になる。たとえそれがPhotoshopで描いた模造品であったとしても。

サイトの実働部分や機能を作るにあたって、設計担当者とデザイナーがプログラム開発者と一緒に作業を行うと考えてみてほしい。ワイヤフレーム作りは作業プロセスのひとつではあるが、プレゼンで見せるようなものではない。プレゼンが現実に即したものであればあるほど、よりよいフィードバックが得られるのだ。

ワイヤフレームはUIデザインにおける拘束になることすらある。「ワイヤフレームでそうなっているからデザインもそうしなければならない」「ワイヤフレームに無いからデザインでもそれがあってはならない」といった具合にだ。ワイヤフレームにがんじがらめにされてデザイン変更がままならないというハメに陥るのが常だ。スタイルガイド（訳注:デザイン様式に関するガイドライン・指針）についても同じような事が言える。スタイルガイドに則って、ビジュアル面において何が許可され何が許可されていないかを明らかにする為に時間を費やし、あげくのはてに自らのデザイン指針を破棄せざるをえなくなるというのがオチだ。

Crate & Barrelで最初に聞いたのが、従うべきスタイルガイドがあるかどうかだった。クリエイティブ・ディレクターのAlessandro（私の知る限り、最高に頭が切れる人のうちの一人）はこう言った、そんなものは無いし必要ない、と。スタイルガイドがあると今だけでなく将来にわたってグラフィックデザインが硬直化してしまうのだ。この考え方は実に賢いと思った。スタイルガイドなぞ無くても、存在感のあるグラフィックデザインを持った素晴らしい定番ブランドが厳然と存在している。

オープンソースデザイン

人生において最も困難な事の一つが、他人に公開・共有するということを学ぶ事だ。私はこの意味において37signalsのプログラマー達を深く尊敬している。彼らはみな、作業成果を公開するのが自明となっているオープンソースの世界からやって来ている。デザイナーというものは生まれつき公開することを嫌うものだ。少なくとも私はそうだ。私の作品が私の手を離れて自分自身の道を歩むのを見るのはつらい。実際のところ、私はそれがいやで受注開発をやめたのだ。一年後には見る影も無くぼろぼろになった自分の作品を見るはめになるというのが嫌でたまらない、というだけの理由で私は自分の作品を手放そうとしなかった。

37signalsではデザインというものは全て公開が求められる。JasonもRyanも私もシカゴ在住だが、別々の場所で作業を行う事がひんぱんにある。Highriseのマーケティングサイトを作る際に、デザインに関してレビューや方針の指示をしてもらう為にBasecampとCampfireを利用した。このプロセスは、これまでのものよりも迅速にHTMLファイルが実際に使えるレベルのものに仕上がるようになったという点で、他に類を見ないものだった。これらのHTMLファイルはみんながアクセス出来るGitのレポジトリ（訳注:Gitとは分散型のバージョン管理システムで、レポジトリとはGitの管理するプロジェクト毎に作られるファイル置き場）に置かれた。これによりJasonが私の作ったグラフィックのコピーに手を加えている間であっても、私の方でグラフィックに手を加える事が可能になった。結果として私たちは、あたかも共同でサイトを彫刻しているような気分になった。PSD（訳注:PhotoShopの画像フォーマット）ファイルを投げつけ合うことなしでだ。HTMLファイルを更新するだけでページの実物をそのまま目にすることが出来るのだ。

サイト立ち上げの時点から細かな調整も行ってきた。実際、当初からその予定だったし今なお調整は続いている。これまで取り組んだプロジェクトのうち、これは最もイテレーティブ（訳注:大きな変更をどかんと行うのではなく、細かな変更を何度も繰り返し積み重ねていくというやり方）なプロジェクトだった。このプロジェクトは商用サイトの再デザインに比べれば規模という点においては小さいけれど、こういったイテレーティブな開発手法を他でも採用しない理由は全く無い。ブランド調査やワイヤフレーム作りにかまけているから、こういったイテレーティブな手法を採れないのだ。こういった短時間で結果の出せるイテレーティブな手法は継続的なサイト改善に大いに役立つ。

Getting Realなやり方は仕事をするにあたって大いに役立つが、反面、手を出すにはちょっと怖いところもある。開発を進める上で誤りを犯したり苦渋の決断を迫られることもあるかもしれないが、結果として得られるものは諸君をよりハッピーにしてくれるだろう。どんな場合であっても、うまくいかない場合はやり方を変えればいいのだということを忘れないでほしい。諸行無常なのだから！