書く作業を通じて、フィールドワーカーは、当初非常に奇異なものと感じ、また自分の理解の範囲を超えるように思えたことについて理解できるようになるロバート・エマーソン他『方法としてのフィールドノート―現地取材から物語作成まで』
というのも、「これからはデザインの時代｜デザインの時代はこれから」では、デザインの2つのミッションとして問題解決と価値創造をあげ、前者は顕在的な問題を対象にしたもの、後者は潜在的な問題を対象にしたものとの解釈を行いましたが、いずれにせよ、問題が顕在的であるか潜在的であるかに関わらず、問題の解決の前には問題そのものの理解が先立つ必要があると思います。
問題を理解する努力は、問題を解決する努力に先行しているに違いない。ハーバート・A・サイモン『システムの科学（第3版）』
すなわち、それは自分たちが何故デザインを行うのか？ どの問題を課解決するのか？ どんな潜在的な問題を表面化させそれを解消した価値創造を行うのか？ という目的を明示することが求められるのだと思います。
昨日、これからはデザインの時代｜デザインの時代はこれから」というエントリーを書いたことで、デザインという行為＝仕事と解決すべき問題というデザイン＝仕事の目的の関係が自分のなかであらためてしっくりと理解できるようになったのです。
目標、コンセプト、デザイン過程
問題を理解することは目的を明確にすることです。一方で問題をどのような形で解決するかを明確にすることは目標＝GOALを定めることになります。さらにデザイン過程においてGOALを詳細に落とし込んだものがデザイン・コンセプトです。
そして、デザインという行為を行う上で目的（問題は何か）を理解し、具体的な目標（どのような形で問題を解決するか）を明確にし、具体的にその目標を達成するためのデザイン行為を行うためには、いかにして問題理解から実際の問題解決のGOALにいたるかを示すデザイン過程そのものをデザインする必要があると思っています。
全体システム、サブシステム、階層構造
たいていのデザイン過程においては理解された問題が一気に解決にいたるということはありません。それはひとつひとつ問題をいかに解決するかという具体策を試行錯誤を行う個々の行為を積み重ねながら、最終的なデザイン案＝問題解決の解を導く作業です。全体システムの「内部環境」が、そのメカニズムの詳細な記述なしに単にその機能の記述によって定義されうるように、サブシステムの「内部環境」は、そのメカニズムの詳細な記述なしに、その機能の記述によって定義することができる。ハーバート・A・サイモン『システムの科学（第3版）』
例えば、以前、「IDEOにおけるデザイン・プロセスの5段階」で紹介したIDEOのデザイン過程は、
- Understand（理解）
- Observe（観察）
- Visualize（視覚化、具体化）
- Refine（改良）
- Implementation（実行）
から成りますが、それぞれの段階での詳細な記述がなくても各段階はそれぞれの機能・ミッションを明らかにすることで定義できます。
デザイン過程における全体システム、サブシステムの階層構造
例えば、「観察」という段階は、これからデザインしようとする製品カテゴリーの具体的な製品のいずれかをユーザーが実際にどのように利用しているかを観察により詳細に把握するミッションをもっている、と定義することは可能です。仮にそれを可能にする具体的なメカニズム（どのようなサブシステムが存在し、どのように機能するか）がわからなかったとしてもです。しかし、今度はその「観察」という段階には、どんな人を観察するかを明確にする段階、実際に街に出てフィールドワーク調査を行う段階、調査結果をシナリオ／フィールドノートに書き記す段階、シナリオ／フィールドノートの形で書き起こされたユーザー行動を分析する段階などのさらに細かなサブシステムが含まれていたとします。もちろん、この個々のサブシステムそれぞれも具体的にどのようにそれを行うのかを明示しなくても、その機能を定義することは可能です。
具体的な作業を行うには内部環境のメカニズムを知る必要がある
しかし、実際にデザイン作業を行う上で個々のサブシステムが上位のシステムを機能させる上で必要なものと定義されれば、サブシステムそのものの内部環境のメカニズムを知ることなくしてはその行為を行うことはできません。先の例でいえば、「調査結果をシナリオ／フィールドノートに書き記す段階」が機能としてどういうものか定義されていれば実際にその作業をできるかといえばそんなことはなく、実際に「調査結果をシナリオ／フィールドノートに書き記す」という作業をどう行うのかのイメージが具体的にもてていなければ実行することはできないでしょう。
もちろん、そのイメージは必ずしも最適解ではなければいけないわけではなく、定義された機能をある程度満足に満たすものであるというレベルでいいわけですが。
デザイン過程のデザインには最適化より満足化の発想が必要
そう考えると、デザイン過程を実際に動かすにはどんどんサブシステムの階層を下に下に移動して、個々の詳細なメカニズム＝具体的な作業イメージを追いかけたくなります。しかし、目的とGOALに応じてデザイン過程全体をデザインするという観点からいえば、サブシステムの階層構造を下方向に移動して個々の詳細なメカニズムをすべて明らかにしようというのは懸命ではありません。サブシステムに複数の選択可能な解決策が考えられる場合、いずれを採用すべきかをすべて検討しようとすれば、いわゆる巡回セールスマン問題に突き当たってしまうでしょう。
実際のデザインにおいては、コスト、時間など多くの制約があり、巡回セールスマン問題などに関わっている余裕などありません。
デザイン過程のデザインには、すべての解決策のリストから最適解を選び出そうとする最適化の発想ではなく、与えられた制約のなかで目的とGOALを満たす解を見出す満足化の発想が必要になります。
トップダウンとボトムアップの視点
個々のサブシステムを実際に実行している段階においても、そのサブシステムの完了だけを見ていて、次に何をするかが頭に入っていないと、デザイン過程全体のシステムがうまく機能せず、制約の範囲内で目的とGOALを満たすことがむずかしくなることがあります。ボトムアップの視点でディテールばかりを見ていると、デザイン過程全体の目的とGOALを見失ってしまうことがあると思うのです。
かといって、トップダウンで目的とGOALばかりを見ていて詳細なタスクのイメージができていなければデザイン過程は実際に機能することはありません。
だからこそ、デザイン過程を実際に動かすデザイナーには常にボトムアップの視点とトップダウンの視点を適宜入れ替えながら、デザイン過程を実際に前に進めていくことが求められます。
また、デザイン過程をデザインする際にも、そうしたトップダウンとボトムアップの視点を入れ替えつつデザインを行う必要があるでしょう。
ここではデザイン過程のデザインと書きましたが、これは自分の仕事をどうデザインするかという話でも同じように通じる話だと思っています。
自分の仕事の目的とGOALは何で、実際にそれを達成するにはどうしたらよいかを考えるのは、仕事をうまく行うには必要なことだと思うので。
そんなことを考える上で、ハーバート・A・サイモンの『システムの科学（第3版）』は難解ながら、非常に参考になる本です。
おすすめ。
関連エントリー
- これからはデザインの時代｜デザインの時代はこれから
- 利用者の観察から必要なデザインの形を理解するプロセス
- IDEOにおけるデザイン・プロセスの5段階
- 僕たち、普段、デザインしてないんじゃない？（デザイン・プロセスのデザイン2）
- デザイン・プロセスのデザイン