なぜシャッフルディスカッションがブレイクスルーにつながる場合があるのか？

御指名なので。

あれよあれよという間にというのは大げさだが、翌朝の時点で何チームかがブレイクスルーしちゃったのでした。
なぜ？あれだけオールジャパンクラスの講師が次々とアドバイスしたのにダメだったものが・・・。
タナハシさんどうしてだろう？？

これ、何の話をしているかがそもそもわからない方のために書いておくと、昨年の8月27日、28日の2日間にわたって行われた「横浜ワークショップ2008」で、横浜の街のフィールドワークを元に横浜の地図を作成するという課題をこなすにあたって、1日目の夜の時点では多くのチームがデザインの方向が困っていたにも関わらず、2日目の朝になると多くのチームが実際の物の制作をはじめたのは何故だろうか、という話。1日目の夜の最後にシャッフルディスカッション（詳しくは浅野先生の記事を参照）という手法を使ったのですが、どうもそれが効果があったのでは？という話になっています。



まず、最初に事実関係を整理しておくと、

  • すべてのチームがブレイクスルーしたわけではなかった
  • ブレイクスルーしたチームも本当にシャッフルディスカッションの効果でブレイクスルーできたのかは不明
  • シャッフルディスカッションで他チームの意見をそのまま反映したチームはむしろ失敗の方向に進んでいる（このケースは9月に行われた「インフォグラフィックス・ワークショップ 1」でも見られた）

といったところでしょうか。

講師のアドバイスも処理しきれない情報を増やすだけ

まず講師のアドバイスがうまく機能しにくいのは何故か？
それはアドバイスを受ける側にとっては、講師のアドバイスもまた、フィールドワークで収集してきた情報同様に処理できないまま、未整理フォルダのなかの情報量を増やすだけになってしまうからではないかと思います。

自分たちがフィールドワークで集めてきた情報さえ、うまく整理できていない、構造化してデザインのための発想へと昇華できない人にとって、新たに耳に入ってくる講師のアドバイスという情報は単に情報量が増やす厄介なものだったりするのではないでしょうか。ただでさえ、手持ちの情報量に圧倒されて目指すべき方向性を見出せなくなっているのです。そこに新たな情報が加わればますます混乱をきたすことはあっても、アドバイスが適切に機能することはないのかもしれません。

フィールドワークがデザインと何の関係があるの？

前に「教えてもらいたければまず学べ！」なんてエントリーも書いたことがありますが、他人のアドバイスが役に立つケースというのは、アドバイスを受ける人自身がアドバイスを受ける前にその問題を十分に考えている場合だと思います。

自分が考えたことと他人のアドバイスを比較してそこに差異を認識できてはじめて、自分の考えややってることのどこがマズイのかがわかる。自分たちの考えがなかったり、自分たちの考えとアドバイスの内容をうまく結び付けられないと、また未整理の情報が増えるだけです。自分たちで何かしらの仮説を組み立てたうえで、それがうまくいかない場合にこそ、他人のアドバイスというのは機能するのではないかと思います。

ところが先のケースの講師のアドバイスというのは、残念ながら、そういうものにはなっていなかったと思うんです。というのも、参加者の問題はそもそもフィールドワークの情報は必要なの？　何に使うの？　というものに近かったはずだから。
何に利用すればいいのかわからない情報を整理できずにもてあましてしまうのは、ある意味、当然だと感じます。どうしていいのかわからない大量のデータを前に途方に暮れるのもある意味仕方がない。

ところが、講師の方はというと、そうは感じていない。

だから、講師はすこしは問題が整理できた状態を想定してアドバイスをしたり、問題の整理の仕方についてアドバイスをしてしまう。でも、参加者にとっては問題はそこじゃない。そもそも問題を整理してどうなるの？　という根本の問題にぶつかっている。

その意味では僕も含めて講師は参加者が何を問題にしているかを理解した上でアドバイスができていなかったし、フィールドワークがデザインと何の関係があるの？をうまく参加者に伝えきれていなかったんではないかと思ったりもします。



他人の意見

その意味では、シャッフルディスカッションで他人の意見を聞いたり、他のチームのやっていることを知ったりすることがブレイクスルーにつながるとも考えにくい。だって、それだと講師のアドバイスを聞くのと同様に単に情報量を増やすだけですから。

ただ、講師のアドバイスとひとつ違う点がある。それはコンセプトレベルでも何かしら形になったものを介したコミュニケーションがシャッフルディスカッションでは行われるから。
自分たちの説明したコンセプトに対する他人の指摘は、なんとなく自分たちの進むべき方向を示してくれるように見えます。ましてや、他チームのコンセプトを聞くとなんとなくまとまっているようにも思える。

でも、両方とも勘違いなんですね。

まず自分たちの説明に対して他人が意見を言えるのは、他人に示された情報が自分たちがもっている膨大な情報に比べてはるかに少ないからです。他人が接する情報は、なんとか筋道を立てて説明した、少なくともなんとなくは論旨が整理された情報なのだから、それを理解して意見をいうのはラクです。０から１を導くのはむずかしくても、すでにある１に意見をいうのはそんなにむずかしくない。後だしジャンケンだから勝って当然です。

また一方で他のチームのコンセプトを聞いて、それいいねと真似するケース。これもおんなじ。他チームの説明もまたなんとなくはまとまっている。それは自分たちの手元にある未整理の情報と比較すればはるかに扱いやすい。

でもね、両方ともシャッフルディスカッションのせいで失敗を犯すことになる際の典型例だと思うのです。
だって、両方とも自分たちが手元の情報をもとに悪戦苦闘してきて、未整理状態ではあってもなんらかの感じを抱いたことをすべて捨てて、安易に説明された案へと走ってしまうのだから。他人の力を借りた説明だけで何かを組み立てたとしても、それがまともなデザインにならないのは当たり前だと思います。だって、そこには単純に説明できるだけのアイデアしかつまっていないのですから。

なぜシャッフルディスカッションがブレイクスルーにつながる場合があるのか？

さて、では、なぜシャッフルディスカッションがブレイクスルーにつながる場合があるのか？　僕なりの仮説です。

それはやっぱり未整理状態で混乱していた情報群のなかから、無理やりにでも構造化した形の説明をいったん作り、実際にそれを言葉として発するという行為を行うからではないかと思うのです。つまり、説明する、そのための文章化をするという行為に意味があるのだと思うのです。
頭の中に考えがあるのと、言葉を発したり文章にしたりというのは違うのだと認識する必要がある。さらにいえば、図式化によるアウトプットと文章化によるアウトプットも違うのだと知っておくことが大事です。

発想法としてのKJ法では、データのグループ化～構造化という作業後に、それを図式化し、さらにそれをもとに文章化するという作業を行います。これはペルソナを作る場合でもいっしょでKJ法でデータを統合したあとに、ペルソナ文書を書く。
いずれも大事なのは、図式化から文章化に視点を変換することなんだと思います。



KJ法の生みの親である川喜田さんもこう書いています。

文章化は図解のもっている弱点を修正する力をもっている。もっと平たくいえば、その誤りを見破って、発見し、かつ修正の道を暗示する力をもっている。

図式によって大まかに情報群の構造を理解した後、その構造を文章化することでその構造のおかしなところが見つかる。図による構造があいまいでも、文章にするには物事の関係性をいったんは整理する必要があるので、それまで未整理だった情報群にもいったんはある関係性のもとに整理されることになります。

これは膨大な情報を目の前にして混乱していた人たちにとっては、とりあえずのとっかかりになる。それまで一度も整理されなかった情報がまがいなりにも、ひとつの関係性におさまったのだから。
また、説明する側がその関係性をちゃんと意識した上で説明を行い、さらに他人の意見を聞くことができたのなら、それは先の「アドバイスが役に立つケース」にあてはまってくる。つまり、自分たちが説明によって作った関係性が他人にどう見えるのかという視点でみることができるから。それは単に膨大な情報に新たな情報が加わるのとは違い、すでに関係性の規定された情報群とそれとは違う関係性の定義の仕方の比較となるので、ぜんぜん意味が違ってきます。

そういう風に機能した場合、シャッフルディスカッションというのはブレイクスルーの役に立つのかなと思います。



ただし、そのためには、以下の条件が必要になるのではないでしょうか。

  • シャッフルディスカッションの前にはチーム内でコンセプトの説明をその概要の共有というレベルではなく、同一の文章の共有というレベルで行っておく→できれば、シナリオ法を使いたいところ
  • 文章化の前に、完璧ではないまでも情報群の構造化～図式化を行っておく
  • フィールドワークで集めてきた情報の整理の仕方（例えばKJ法もそのひとつ）を事前に教える
  • そもそもフィールドワークとデザインがどう関係するかを、最終的にできあがったデザインの側から逆算（リバースエンジニアリング）的に説明した形で事前に教える（いま、この説明が一番求められていると感じてます）

まぁ、これはフィールドワークからはじめるデザインの場合でのシャッフルディスカッション成功の確率を高める条件ですね。
それ以外のプロセスでまだシャッフルディスカッションを実施したのを見たことがないので、これ以外のケースではどうかはちょっとわかりません。

というわけで、長くなってしまいましたが、これがシャッフルディスカッションはなぜブレイクスルーのきっかけとなりうるかの僕の仮説です。
もっといい説明ができる人はご意見ください。

　

P.S.
ちなみにフィールドワークなどのユーザー調査結果を具体的にどうやって具体的なデザインに落とし込むのかがわからないという話。これって学生とか人間中心設計というものに携わったことがない人だけの話じゃないんですよね。人間中心設計というものに携わっているはずの社会人のデザイン関係の仕事をしている人でも、調査結果の膨大なデータをどう扱っていのか途方にくれることは少なくない。人間中心設計に関わってる人が調査データを具体的なデザインに落とし込むのかを本当のところ、わかっていないというのが困りものです。

ただ、そこは学生と違って、とりあえずは前に進もうとするところは社会人。でも、調査データを整理できない状態をどうにかできるわけではない。じゃあ、どうするかというと、調査で調べたまんまの改善をするか、その反対に調査とは無関係な勝手な想像からデザインをするかのいずれかなんですね。ようは調査してないのとおんなじわけです。調査データを構造的に分析し、関係性を組み立てて、データ全体に適切な物語を組み立てつつ、その物語の要素を具体的なデザイン要件に落とし込むということができている人はほとんどいません。挙句の果てに、それで「調査ってやる意味あるの？」とか言ってるので困ったもんです。いわゆる人間中心設計プロセスというのは現状かなりグダグダな状況かなと感じます。

こういう状況はマズイなと感じるので、そもそも情報とは人間にとって何か、古代より人は情報をどう活用してきたかから、ちゃんと情報整理とか推論とか発想法とかの話を、デザインという視点からまとめなおす必要があるんじゃないかと思っています。

関連エントリー

この記事へのコメント

コメントを書く

この記事へのトラックバック