デザイン力としての分解と組立
なにかをつくる上で大事なことの1つは、ものごとを要素に分解して考えることができ、その分割して理解した要素を元にその時々に適切な組立を行えることだと思う。
世の中のサービスデザイン系、UXデザイン系のフレームワークの多くは基本そのためにある。
ビジネスモデルキャンバスしかり、
カスタマージャーニーマップしかり、
サービスブループリントしかりだ。
いずれも共通しているのは、最終的にビジネスやサービスで使われるモノやシステムのデザインではなく、そのビジネスやサービスが何なのか？をデザインするフレームワークである。
言うなれば、HOW（どうやって）ではなく、その前にWHAT（何を）を決めるために、要素の候補を抽出しその組み合わせを考えるためのフレームワークである。
そう考えれば、いわゆるUIとかのワイヤーフレームを書くのだって、同じである。ワイヤーフレームは最終的なUIそのものではない。そこにはビジュアルも振る舞いも定義されていない。
ワイヤーフレームは、情報設計（IA）という観点で、必要な情報の要素を抽出したうえで、それが使われる状況での最適な組み合わせを思考するためにつくるものだろう。
Jesse James Garrettの5 Planes Model
表現（HOW）のデザインと、内容（WHAT）のデザインを切り分けて思考できるようになることが大事だ。
その考え方は、古くは、Jesse James Garrettが5 Planes Modelで明確にしている。
WEBデザインのUXを考えるためのフレームワークとして提案されている、そのモデルは、次の5つの階層から構成される。
戦略（Strategy）：ユーザーニーズ／サイトの目的
要件（Scope）：コンテンツ要求／機能要件
構造（Structure）：インフォメーション・アーキテクチャ／インタラクション･デザイン
骨格（Skelton）：インフォメーション・デザイン／ナビゲーション・デザイン／インターフェイス・デザイン
表面（Surface）：視覚的デザイン
この考え方は、最終的なUIデザインとして「表面（Surface）」は、基本的には、ほかの4つの階層がある程度クリアになった上で考えましょうということである。
いわゆるワイヤーフレームは、「骨格（Skelton）」を考えるものだし、サイトの構造やユーザー導線を考える作業が「構造（Structure）」にあたる。
その前にどんなサイトにするかが「要件（Scope）」になるし、そもそも何のために？と目的を問いつつプロジェクトの方向性を決めるのが「戦略（Strategy）」だ。
つまり、ビジネスモデルキャンバスやカスタマージャーニーマップなどは、この戦略や要件を考えるために利用可能なフレームワークということになる。
そして、それを元にサイトのストラクチャーやワイヤーフレームが検討可能になる。
具体的な表現としてのデザインはそのあとである。
この戦略〜要件についての思考や議論が不十分で、その定義が行われないまま、構造、骨格、表面の議論をしても、寄って立つところがないのでどうしても話がまとまらない。いや、まとまっても何のためにまとまったのかわからない。
何のためのものかが決まらないのに、それをうまくデザインすることなど不可能なはずだ。けれど、そこの部分が曖昧なままデザインが行われ、何の基準もないまま、デザインの良し悪しが語られる。
ただ、これはデザインプロセスをウォーターフォール型にしようという話では決して。あくまで思考過程としてこの順番で組み立てようということであって、それを具体的にどんな作業ステップで行うかはまた別の話である。
ダブルダイアモンド
5 Planes ModelはもともとWEBのUXを想定してモデル化されたものだが、基本的な考え方は、ほかの領域のデザインでも同じだ。
たとえばダブルダイアモンドという考え方がある。
2005年に英国デザイン協議会で初めて導入された方法で、問題発見と解決策発見の2つの段階で、それぞれ発散と収束を行う課題解決の方法だ。
アイデアを広げる発散とアイデアを束ねていく収束が2つのダイヤモンドを描くようなのでそう呼ばれる。
考え方は同じだ。
問題発見がWHATであり、解決策発見がHOWである。
さらにいうなら発散が要素をリストアップすることであり、収束がそれらの要素を選択しながら組み立てていく作業である。
問題発見の発散で問題と考えられる事柄をリストアップし、問題発見の収束ではそれらの問題要素を構造化したり関係性を明らかにして統合を行うことで、取り組むべき課題とそれがどのような状態で解決されるべきかというゴールを明らかにする。
課題とゴールが明らかになってはじめて、解決策の発見という次の段階に移れる。
解決策の発見における発散では解決のためのアイデアをリストアップし、またその収束でそれらのアイデアを取捨選択したり組み合わせたり構造化していったりしながら、最終的な解決策をつくりあげる。
いずれも発散という形で、問われていることを要素に分解しながらアイデアにしていく作業と、収束というかたちで発散を通じて得られた要素を用いながら答えを組み立てていく作業に別れる。
それはWHATの段階でも、HOWの段階でも共通している。
何かをデザインするということは、この分解する脳と組み立てる脳の両方が必要なのだ。
もともとの問いを適切に分割して要素にできなければ、組み立てるために使える必要な要素を手に入れられないし、うまく要素に分割できたとしても、それを用いて求められる答えを導き出せるよう組み立てができなれけば、最終的な結果にはつながらない。
分割と組み立て。
それは発散と収束の別の呼び方だろう。
理解するためには分割が必要
日本では昔からよく、分けることは分かること、と言われる。
実際にそうだと思う。分けることだけが分かる方法ではないが、それが1つの方法であるのは間違いない。
プロジェクトを実行する上でも与えられた課題をタスクに分解することが大事だとされる。
課題を解決するのに実際にどのようなタスクが必要かを洗いだす作業である。
タスクのリストがなければタスクは実行されず、タスクが実行されなければ課題は解決されない。
しかし、そもそも課題をどうやって解決するかを必要なタスクのリストへと分割することができなければ、それはつまり解決する方法が分かっていないということになる。
つまり、課題の解決策が分かっているかどうかは、タスク分解ができるかどうかということにほかならない。
先のダブルダイアモンドの解決策発見とは規模が違う話だが、基本は同じである。
タスク分解をする際のいろんな案出しという発散があって、その案を適切な取捨選択や並び替えという収束があって、はじめて解決策が分かる。
分解するということは分かることだ。
機械のなかを開けてみて分割するのも、自然の動植物を分類学的に分けていくのも、そうすることで理解ができるからだ。
逆にいえば、まだちゃんと分けてみてないのなら、分かっていない可能性が高いということにもなる。
思考の整理整頓をすることが苦手なことと物事の理解度が低いことはおそらく無関係ではない。
要素を組み立てられるか
さて、もうひとつ、要素は集まったはいいが、それを組み立てて何らかの答えを導くことができないというケースもある。
WHATの場面でも、HOWの場面でも同じように。
発散は方法を問わなければ、要素の数は出せる。
やたらめったら調査したら、何だかわからないけどアイデア出しのブレストしたりすれば、要素の数は集まる。
でも、本来その発散は、問題に対する適切な分解でなくてはならない。
だから適切なテーマ設定がされていない調査やブレストで集まった要素は組み立てられない。
そんなものは無理して組み立てるのは無駄だ。
あきらめて適切なテーマ設定をして調査やブレストをやり直した方がよい。
だが、適切なテーマ設定をした調査やブレストでそれなりの要素が集まっても、それを組み立てることができない場合もある。その場合は組み立てスキルの問題だ。
組み立てるには、要素の意味を理解する必要がある。
特に要素間の相対的な関係の意味を読み解いていく必要がある。
この段階で2段階目の「分かる」過程に入っている。
ジグソーパズルでパーツ相互の関係性を読み解くのと基本は同じだ。どのパーツとどのパーツが組み合わさり得るのかを見つけるわけだ。適切な組み合わせを続けていけば、最終的に絵ができる。
ただ多くの課題解決は、パズルと違って要素同士の可能な組み合わせは一通りではない。
だから、個々の要素間同士の組み合わせを考えるのと同時に、最終的に描きたい絵はどんな絵か？という完成系も何となくイメージしながらパーツの組み合わせを模索する必要がある。
そのパーツの組み合わせの模索と完成イメージを明らかにしていく作業は、互いにリンクしてるはずだ。
要素の組み合わせの可能性を見つけると、完成系のイメージが湧いたりする。完成系のイメージが見つかると探すべき要素の組み合わせが何かのヒントが得られる。
分かろうとしているか、いないか
ここでもやはり分かるということが大事だというわけだ。
けれど、誤解してはいけない。
分かると分からないがあるのでない。
本当にあるのは、分かろうとしているかと分かろうとしていないかなのだから。
それは分割と組み立てをしてるか、していないかということにほとんど同じだろう。
その意味ではデザインすることというのは、デザイナーに限らず、ほとんどの人のやるべきことなんだろうと思う。
基本的にnoteは無料で提供していきたいなと思っていますが、サポートいただけると励みになります。応援の気持ちを期待してます。