事例研究会のススメ

何かの実務を専門とする大人が集まって「勉強会を開く」というのは各地で催されているけれど、その基本構造は誰かが前に立ってしゃべって、それをみんなが聴くスタイルだと思う。

私たちが子どもの頃から慣れ親しんだスタイルだから自然とそうなる面もあるし、忙しい仕事人が短時間で新しい情報や知見を受け渡すのに能率的なスタイルを選択しているとも言える。新しい概念を知ったり、これまで見えていなかった・できていなかったことの気づきを得るには有用で、特にあるテーマの学び始めにはフィットするスタイルの一つだと思う（講義形式というだけで何の学習効果もないと断じるのは早計だと思う）。

一方で、講義形式はスキル習得に直接役立つ構造ではない。スキルが「自分でやってみる」ことなしに身につくことはない。

また、主催者がイベントとしての集客数を重視した場合、人数が多いぶん参加者の前提知識がまちまちになりやすく、話の構成はおのずと知識の基礎固めにフォーカスされやすい。「これから学び始める参加者にも満足してもらえるように、足並みをそろえる講義が必要」ということで、そのテーマを学ぶ重要性で学習動機づけ→「とは何か」の概念説明→どういう考え方があるかのモデル解説→その方法論や思考モデルについて理解を深めるための事例解説で、たいていは時間いっぱいとなる。

目的・ターゲット・ゴール・実施条件によっては、それが最適解となることももちろんあるのだが、勉強会の多くが意図せずそれに偏り過ぎてしまっているとすれば、それはもったいない。勉強会にはいろんな目的・ターゲット・ゴール・実施条件があるはずで、それに対応した勉強会の構造を講義形式以外にも選択できたらいい。ということで、事例研究会のススメを書いてみる。

ちなみに、ワークショップっぽいものを開こうとすると、事前に仮想課題をこしらえる必要が出てくる。これを多様な参加者が取り組みやすいテーマで、やって意味ある演習課題に落とし込むのは相当骨が折れる仕事だ。かといって、この辺手を抜くと、かなりぼやっとした勉強会になる。当日のファシリテーションも難易度が高く、いろいろと主催者の荷が重い。

それに比べると、事例研究会というのは、事例をもたぬ実務者はいないわけだし、比較的手軽に実施しやすいのではないだろうか。もちろん明かせること明かせないことはあるだろうけど、一つの事例を深掘りしてじっくり話しあうことで、抽象的な言葉の空中戦にならず、実践的な議論・知見の共有がしやすいかなぁと思う。

逆に言うと、飲み会やお茶会などで情報・意見公開しているときというのは、たとえ誰かが事例を挙げたとしても、聞き手はそうそう頭からお尻までじっくりプロジェクトを把握してもの言えるわけじゃないから、プロジェクトの背景や実施条件などがわからず、「まぁ、そんなこともあるよねぇ」としかもの言えなかったりする。「そういう条件下で、こういう状況に陥ったんだったら、もっとこうしたら良かったんじゃない？」といった批判的かつ建設的な議論の展開が難しい。

せっかく実務者同士が集まっているのだし、実務者は仕事で成果出してなんぼだ。いくら概念をしゃべれても実務で活かせていなければ仕方ない。誰かが提唱した抽象的な言葉を一切使わずに、自分の案件について自分の言葉で具体的かつ論理的に説明し、それをネタに参加者全員が議論を深め合えたら有意義ではないだろうか。

一言で表すなら、「少人数の実務者が集まって、一つの事例をネタに、ある関心テーマでどっぷり語り明かす小規模な勉強会」って一言じゃ息切れしてしまいそうだが…。

というわけで、じゃあ事例研究会的なものをやるとしたら、どんな感じで進めるかの案を書いてみる。自分がWeb系の仕事に従事する人の学習をサポートする仕事をしているため、そっち系の人をイメージして書く。3時間〜3時間半もの。

【準備】
●主催者は、特定の関心テーマで参加者を集める（UXでもIAでもUIでも、もっと狭く絞り込んでもいい）
●参加者には、自分が手がけた案件を事例としてネタ提供できる人を1人入れる
●参加者には、そのテーマに自分（主催者）より詳しそうな人を1人含めるといい
●参加人数は、全員でディスカッションできる程度に限定する（4〜5人、聴講入れたとしても8〜10人くらい？）
●主催者と参加者で、日時と場所を決める（場所は事例発表、落ちついてディスカッションしやすいところ）
●事例提供者は、事例を共有できるよう当日までにできるかぎりの準備をする（NDAを破らないように準備）
●主催者と事例提供者は、事例発表に必要な機材・備品などの環境は洗い出して用意しておく

［参加者向けのポイント］
○いろんな人が気負いなく事例提供者になれることが大事だと思うので、提供者に対する「しっかり準備して、うまくしゃべれよ」的なプレッシャーを与えない。提供者が当日うまくしゃべれない場合、聴き上手な人が質問して要点を聴き出しながら進める。それができないで当日ぐだぐだになったら、参加者全員の責任とする（くらいの勢いで）。

【当日の流れ】
1)主催者：アイスブレイク（10分）
●自己紹介とかしながら場をほぐしたり、遅刻者を10分くらい待ってあげたりする。
●自己紹介では、「今回のテーマに仕事でどんなふうに関わっているか」とか「自分なりに勉強してきた関連知識・スキル」などを情報交換。

2)事例提供者：事例紹介（60〜90分）
●事例となる案件の全体像を話す（クライアントの業種業態とか組織・サイト規模とかプロジェクトの目的・目標とかターゲットとか、前提事項・制約条件など）。
●プロジェクト発端から終結までの各工程を、「順をおって」「今回集まったテーマに関連するところにフォーカスをしぼって」説明する（各工程でどんなことをやったのか、どんな試行錯誤があったか、どう決着させたか、どうアウトプットして周囲の反応はどうだったか、それに対してどう対処したか、結果はどうだったか、どんな反省があるかなど）。

［事例提供者向けのポイント］
○時間をかけていいので、じっくり、つぶさに話す（ただしテーマに関わらないところは思い切って省く）。
○著名人の理論とかモデルとかの抽象的な言葉を持ち出さず、具体的かつ論理的に説明する。
○「ここで他の人だったらどうしたかなぁ」など、みんなに聴いてみたいことは後で質問できるようにメモっておく。
○NDAに触れることはしゃべらない、資料を見られないよう事前に消しておくなど、自分できちんと情報管理する。
○立たずに、着席して話す感じがよい（と思う）。

［聞き手向けのポイント］
○細々とした質問は途中でも自由にする。
○「自分ならこうするかなぁ」といった所見や、後ほどみんなでじっくり議論したほうが面白そうな話はメモに残しておいて、とりあえず一通りの話を聴く。

3)休憩（10分）

4)参加者：感想コメントを一人ずつ（20分）
●皆で議論したいこと、皆が普段どう対応しているか知りたいシチュエーションなどを挙げる（「あの場面は自分だったらこうしたな」といった意見や、「自分にも似たようなケースで同じように説得したつもりだけど、クライアントにこう切り返された。どう対処したらいいと思う？」といった議論のネタなど）。
●事例提供者も、「みんなに訊いてみたいこと」があればネタを提示。

［主催者か、できる人向けのポイント］
○参加者一人ずつの感想を聞きながら、有意義そうな議論のネタを抽出してメモっておく。

5)参加者：ディスカッションやらおしゃべりになだれ込む（80分）
●議論のネタ抽出も参考にしつつ、結論なしでいいので、好き勝手にしゃべる。各々持ち帰る。

さて、それでどうなるかはわからないんだけど…、成功したらぜひ教えてください…。