共同主催だったり、主催から呼ばれてヘルプでテーブルファシリをする、みたいな形で10回以上はワークショップに参加させてもらってきましたが、先日、ようやく自分の単独プロデュースでクライアント向けワークショップの企画･運営･ファシリテートする機会を得ましたので、そこで得た気づきを残しておきます。ちなみに、お題は｢カスタマージャーニーを作ろう｣という、まぁ至極よくある系の話でした。

慣れてる人にとってはかなり当たり前な内容も含まれていると思いますが、ご容赦を。

その前に、そもそもワークショップの意義

一部の界隈では｢魔法の杖｣のごとく崇められているワークショップですが、これやれば課題解決できる、といったもんではないことに注意は必要。

ここは諸説あると思いますが俺の場合は、ワークショップは課題顕在化プロセスのうちの1手段と考えています。
課題を顕在化する手法にはいろいろあり、アンケートやインタビューを通じて利用者や顧客に問うやり方や、我々のような第3者がアレコレ考えるやり方とは別に、ワークショップはサプライヤーロジック(事業者の理論)で課題を問う手段に属するものかと考えています。あ、もちろんクライアントと行う場合は、です。

その中でも、ワークショップという手段は多様な利害関係に属する事業従事者の意見を白日に晒すことで価値観の交換や意見調整まで一緒にやってしまうというところに特徴があります。その特徴を最大限に高めることでワークショップの価値は最大化されるはずです。

やってみて気付いたこと

ということで、(主に自分が次の機会で振り返る用に)気付いたことをメモっておきます。と言ってもほとんどがプログラム設計で決まると言ってもいいと思います。まさに｢段取り八分｣の世界です。

さて行ってみましょう。

内職させない

いきなりどうでもいいネタのように見えて、一番重要だと思いました。内職させてしまうと別のグループの発表を聞かない人が発生してしまうからです。異なる立場の人が意見交換することがミソなワークショップでこれをやられると意味が半減します。
ということで、事前に内職｢NGです｣と伝えておくべきかなと。もちろんできる範囲で、ですが。

お互いの発表をちゃんと聞かせる

ほとんど一つ前のと同じ意味です。異なるグループの意見を聞いて｢そういう意見もあるのか｣という気づきの相乗効果を狙うのがワークショップ効果の一つです。
発表慣れしていない方は手元のメモを見ながら発表しがちなので｢前を向いて喋ってください｣と言ったり、別テーブルの人が聞いてなさそうだったら｢聞いてあげてくださいねー｣とディレクションした方がいい。

意味あるのか分かりませんが、模式図を作って見ました。ワークショップという手段をとる以上、この場にいるみんなの総意が可視化されたという状態にできるだけ近づけるために、適宜発表のタイミングには意見を聞いてもらいます。

あ、もちろん意見を散らかすことが目的のワークショップだと逆効果の可能性もあります。

参加者はできるだけ固定する

クライアント相手にこれをやるのは難しいかもしれませんが、途中退席や途中参加はなるだけ避けます。
異なる視点の意見が蓄積されないデメリットは言うに及ばず、ワークショップの目的や視点を都度説明したり、適宜チームの入れ替えとかしていると場の流れをストップしてしまいますし、グダグダ感が助長されてしまいます。

休憩時間を長めに設定しておく

ワークショップってほとんどの場合時間が押すので、最低20～30分くらい休憩時間を設計しておいて、押した時間は休憩時間で調整できるようにしておくといいと思います。
俺の場合、その上でさらに｢予定より30分押しても大丈夫｣なように終了時間を設定しておきます。

テーブル議論は10分で区切る

話し好きが集まっていれば、お題さえ与えれば永遠に議論してくれるテーブルもあるのですが、まぁ稀です。じゃあ1回のテーブル議論にどれくらい時間を割けばいいかと言うと、多分10分がちょうどいいかなと思います。5分だとまとめる時間が無いし、20分だと後半時間を持て余すことが多ように思います。
仮に10分で足りなかったとしても、無理やりでも10分で一旦区切ってテーブル発表してもらった後に2サイクル目に入った方がテンポもいいし、価値観を交換するという意義にも沿っているのでいいと思います。

適度に個人ワークも入れる

｢ずっと議論し続けなければならない｣という時間が続くのはかなりハードだと感じました。議論と議論の間に、一人ひとりが考える個人ワークを入れて緩急つけた方が長い時間を過ごしやすいのではという思います。良いか悪いか置いといて、慣れてない人にはその時間を休憩ライクに使ってもらってもいいかもしれない。

1テーブル5or6人を基準にする

勝手に喋り出すタイプ、他人にノせられて喋るタイプ、喋らないタイプ、と3クラスタの人がいるとして、5-6人集まればそれぞれ1-2人ずつがミックスされる確率が高まるだろう、くらいの感覚。まだコレだという正解はよく分かりません。
経験上、喋り好きが集まれば3人いればテーブルが成立する。けど、参加者のキャラが事前に分かっている自社ワークショップならまだしも、クライアントワークショップとなるとこういう確率論で設計するしかないかなぁという感じ。まさか｢喋らない人は呼ばないで下さい｣と言うわけにもいかんし。
加えて、こちらからテーブルファシリを1人づつ配置することで、議論が硬直化するリスクを減らします。

ということで、だいたい割り振りはこんな感じになるかと思います。

• 12人なら：4人 + 4人 + 4人 or 6人 + 6人
• 13人なら：5人 + 4人 + 4人
• 14人なら：5人 + 5人 + 4人
• 15人なら：5人 + 5人 + 5人
• 16人なら：6人 + 5人 + 5人
• 17人なら：6人 + 6人 + 5人
• 18人なら：6人 + 6人 + 6人
• 19人なら：5人 + 5人 + 5人 + 4人 or 7人 + 6人 + 6人
• 20人なら：5人 + 5人 + 5人 + 5人

最初から最後で、6時間

今回はどうしても1日でやり切る必要があったので、結果としてトータル7時間半(昼休み込)のプログラムになりましたが、まぁ長かったです。俺はずっとアドレナリンがもりもり出てたのでいいのですが、テーブルファシリにつけたメンバーがどこからどう見ても憔悴していっているのを見て｢悪いことしたな｣と思いました。
じゃあ6時間がベストかと言われるとよく分からないが、7時間半よりはマシだろうくらいの感覚です。それを超えるようなら2日間に分けた方が良い気がします。

最初にこってりやりすぎると後が疲れる

重めのワークをいきなり冒頭にぶつけないほうがいいなと思いました。軽いディスカッションや、現状のスタディとかをサクッとやる、みたいなところからスタートした方が良さげです。もちろん冒頭にアイスブレークをやったとしても、です。

発表をリアルタイムに編集する

自分の場合は、発表された意見には｢こういう解釈もできますね｣とか｢本質的にはこの意見に包含されますね｣とか｢別の意見と背反しますが、どちらが優先でしょう｣みたいに、問いやツッコミを入れながらリアルタイムに編集しまくります。後で結論化しやすいようにするためです。あと場の全体を議論に巻き込みやすいというメリットもあります。
頭をフル回転させながら意見を聞く必要があるためカロリーを消費しますが、この時はIA(インフォメーションアーキテクト = 情報設計者)をやってて良かったと思います。こういうの、結構慣れてます。

ただこの方法の弱点は時間をとられてしまうところです。いろんなファシリスタイルがあるかと思いますが、発表には手を付けずに、ワークショップの後に編集する方法でもいいとは思います。

ルールは何度でも伝える

ワークショップだからと言って、思いついたことを何でもかんでも言ってもらえばいいというもんではありません。
今回はお題がカスタマージャーニーだったので、｢顧客を主語にしましょう｣というルールを繰り返し伝えました。が、最後まで浸透せず、何度も何度もサプライヤーロジック(顧客都合というより事業者側の視点)による意見が出ること出ること。
これは対策を打つというよりは、｢そういうもんだ｣という心構えをすべきという話かもしれません。

とまぁ、TIPSというか、今回やって上手くいったことと改善すべきだなと思ったことを関係なく列挙してみました。

で、次何するんだっけ？にならないように

冒頭で述べた通り、ワークショップは課題解決というよりは課題顕在化のための手段だと思っているので、これがどう使われるかの方が問題。やったことある方なら分かると思いますが、付箋でペタペタ貼ったことをパワポにしても何の意味もないし、パワポにしたところで｢で、次に何するんだっけ｣という状態に陥っているケースを何度か見てきました。

クライアントのコンディションや、ワークショップの立ち位置によって後続工程が異なるのはもちろんですが、ただ共通しているのは、意味のある単位に情報をまとめて、そこから有効な課題なり次の打ち手を導くことかと思われます。

プロジェクトの成果としてどのような結論を期待するかが先に定義されているはずなので(されてないプロジェクトをよく見るけど)、そこに至る道程としてワークショップが手段化されているべきです。そうすると、自ずとワークショップの結果をどう編集すべきかも定義されているはずですので、ここでも｢計画がモノを言う｣段取り八分な世界だなぁと思わされます。