はじめに
参考書籍はありますが、自分の体験談多めに書いてます。
ここに記載してないテクニックなども参考書籍にはあるので、興味ある方は見てみると良いかも。
少し古い書籍なので、今はもっといいものが出てるかも。
「スクラムマスターとして」って書いたけど、シンプルにファシリテーションするときに注意してることになってしまった。
参考書籍
前提・原則
いくつか書くけど、あくまで実体験で使えたものに絞って話します。ファシリテーション自体はいろんなシチュエーションで使われるので、これだけじゃないと思っています。
- ファシリテーターは「参加者が課題を解決できる状態」を目指す
会議をうまく回せばそれでいいわけではない。結局参加者が課題を解決できる状態に導けていなければ意味がない。
参加者に動いてもらうためには「理屈」と「感情」が必要
人に動いてもらうためには基本的には以下の２つの要素がある。
- 理屈：発議された問題の論点や背景を全員が理解できるように整理する（ロジカルシンキング）
- 感情：感情面での衝突が発生した場合に言い換えなどを行い関係者が「言い方」ではなく「問題」に集中できるようにする（コミュニケーションスキル）
個人的には感情は理屈に勝る。多少理屈が通ってなくても「お前との仲だからなぁ」で通るケースは少なくない。一方で、関係に問題がある場合は、どれだけ理屈が通っていても「理解はできるが、納得はできない！」という形で突っぱねられるケースはありうる。
システム開発では理屈だけで会話したいものの、会話しているのは人間なので感情を切り離せるわけじゃない。
- 基本原則：課題を明確にすることが解決の近道
課題を整理することに徹する。議論の混乱も衝突も課題がずれてたり不明確だったりすることが原因。課題が明確になれば9割くらい議論は終わってる。とにかく課題を明確にするべし。それに尽きる。
ここから書くのはほとんどこれの話。
ミーティングのデザインとコントロール
正直、原則と比べたら誤差の世界。細かいテクニック集。
- デザイン：議論設計の主要なポイント
あの手この手で「課題の明確化」を行う
原則にある通り「課題の明確化」が何よりも重要です。細かい説明は後述。
会議のゴール最初に示す（温度感や背景も合わせて伝えられるとベスト）
具体的には「今日は発散だけします。」「今日は結論を決めたいです。」「結論を出したい訳じゃない、単なる相談です。」とかです。（単なる相談のつもりが、課題が明確じゃない！と突っぱねられるケースもちらほら見かけます。）
ファシリテータだけがゴール認識をするよりも、全員にゴール認識をしてもらったほうが回しやすいです。ファシリテータ以外から議論の進め方を提案してもらうことにもつながるからです。
また、そのゴールの温度感も合わせて伝えられると良いと思います。例えば「今日絶対に決め切りたいです！（〜という締め切りがあるので・・・）」「今日は決まりきらないと思ってますが、できれば決めたいです。」などです。参加者が決め切るつもりで動いてくれるかどうかでかなり変わってきます。議論するのはあくまで参加者であってファシリテーターではないので。
「時間をかけないやり方」を積極的に活用しつつ「時間をかけるやり方」を有効に使う
全員に意見を聞いていたら議論ばっかりで終わらないので、時間配分を考える必要がある。
- 時間をかける：全員に意見を聞く・上がった意見を全て取り上げる
- 時間をかけない：制限時間内の意見のみ取り上げる・投票数の多い意見のみ取り上げる
時間は有限なので、時間をかけるアプローチは「ここぞ！」っていうタイミングに絞った方が良いと思ってる。
目先の効率にこだわりすぎない（たたき台を準備しすぎない・議論の横道を許容する）
たたき台があるに越したことはないですが、たたき台ができるのを待ち続けても物事は進まないので雑に話し始めるのも一つの選択肢です。
また議論が横道に逸れたからといってすぐに元に戻すのが正解とも限りません。横道が気になっている人がいる限り無限に横道に逸れます。少し横道を議論してある程度の満足を確認してから本筋に戻す方が結果的には効率良かったりします。
「発散」と「収束」は一緒には行わず別々に行う
自由闊達に意見を出すのが「発散」。出た意見を整理して結論としてまとめていく作業が「収束」。同時にやろうとすると十分に発散した意見が出ず、微妙な結論に収束してしまう。
１会議中に２フェーズ設けるのもいいし、会議自体を分けても良い。ただ、今どちらのフェーズなのかを明確にしてあげると、会議はしやすい。
例：KPTのアイデア出し（発散）→どれを議論するか（収束その１）→結論（収束その２）
なお、上記例のように、発散と収束のどちらも多少グラデーションがあるので、みんなが乗りやすいようにデザインするのが良い。
- コントロール：課題の明確化（課題と対策の取り違え）
「解決策の検討」よりも「課題の明確化」を先に取り扱って多く時間を割く
多くの人が「課題」についての理解をそこそこに「対策（ソリューション）」の話に目が行きがち。解決策の話をしてた時に、ふと「そもそもこの課題って・・・」という流れから、課題自体が実は単なる誤解だったので「対策は不要だった（認識を共有しただけで解決した）」ということは多い。
ただ「課題」について会話するのに慣れていない状況だと議論が煮詰まることが多いので、その場合は「対策」の話に移っても良いと思います。ただ、その場合でもファシリテータは「課題」について考え続けるのが良いです。対策の話をしていく中で課題が明確化していくことも多いからです。
対策の話をしたい人と、課題の話をしたい人のズレを直す
あと、よくあるのは「課題提起した人は対策の話をする」が「課題提起された人は課題の話をしたい」ケースが多い。会議の序盤に混乱するのはこのケースが多い印象。この場合は、課題提起した人に「みんな今初めてその課題提起を聞いてびっくりしているので、まずは課題認識を擦り合わせるところからやりましょう。」といって、まずは「課題」について認識合わせするところから話し始める。
「対策提起」の場合「課題」を見つけ出すことを優先する
課題提起は「〜に困っているので解決したい」という表現。対策提起は「（〜という課題に対して）〜という対策を打ちたい」といった表現です。
対策提起の場合は「課題」と「対策」のどちらが主眼なのか確認しましょう。例えば「課題が解決するのであれば別の対策でも良いか？」といった確認は有効です。NO（提起した対策であるべき）という話であるなら、課題の表現が誤っています。このまま議論してもずれてしまうので、課題認識を整理するところから始めましょう。
- コントロール：課題の明確化（具体的な事実に基づいた課題定義）
課題定義は抽象的な表現を避けて具体的な表現にする
議論はなるべく具体的に行う方が良い。抽象的な内容だけで議論していると、結論も抽象的になってしまい、どの解決にも結びつかないアクションが生まれやすい。また、抽象的な表現は受け手に想像の余地を残してしまうため、思わぬ対立の原因になったりする。
具体的なケースが既に目の前にある場合は、それを中心に議論するのが良い。そのケースだけに特化しすぎているように感じるなら別のケースをあげれば良い。遠回りに感じるかもしれないが、このやり方の方が圧倒的に解決までのスピードが早いという実感がある。（抽象を中心に置こうとすると議論自体が右往左往することが多い）
結論を抽象的な表現にするのは構わない。その方がわかりやすいこともある。ただし議論の最中は具体的なものを中心に置くべきである。
なお、抽象的なふわふわした話題にコアな課題が隠されていることも多いので、無視するのではなくちゃんと整理していくのが重要です。
課題定義は事実に基づいて表現する（推測と事実を丁寧に切り分ける）
具体と抽象に近い話だが、事実なのか推測なのかは明確に分ける必要がある。議論は事実に即して行う方が良い。
特に我々は職業柄「原因分析（なぜなぜ）」を行うことが多く、変に推測を立てることが染み付いている。ただ、それはあくまで推測でしかないので、そこを議論の中心に置くと話がぶれやすい。
議論の中心はあくまで「事実」。その上で「〜と推測したが実際どうか？」といった確認のアクションを挟むくらいが良い。その推測があっているのであれば、それは事実として取り扱えば良いが、確認するまではそれは事実ではない。
『A→Bときたら「C」に違いない。』と思うことはあるでしょう。この場合、AとBは事実だが、Cは推測でしかない。主観からするとCが事実と思い込んでしまうケースはあるが、ここをちゃんと切り分けるのは重要。（話を詳しく聞くとCだけでなくBすら推測のケースもあったりする）
なお、推測を否定する必要はありません。というかそこを否定すると揉めることが多いです。本人がそう推測したこと自体は否定できません。場合によっては「その人がそう認識する考え方をしている」というのも事実の一つとして取り扱う必要があることもあります。
- コントロール：課題の明確化（細かいテクニック）
オープンクエスチョン・クローズドクエスチョン
「どうしてそのような課題認識に至ったのですか？」「ちょっと説明が端的すぎるのでもう少し補足できるようなことあれば教えてもらってもいいですか？」といったオープンクエスチョン（自由記述形式で回答するタイプの質問）で切り口を見つけ出す。
「似たようなケースで〜もあったと思いますが、そちらは問題だと思ってますか？」と言ったようなクローズドクエスチョン（YES/NOで回答するタイプの質問）で絞り込んでいく。
重要なポイントを見極める（課題表現の一部をずらす・似たような別の課題との差・別の課題とまとめようとしてみる）
課題ってのは入り組んでることが多い。無理に切り分けようとすると逆に本質から遠ざかってしまうケースもある。うまく複数の課題に分割することができれば解決まで近くなる。
基本的に最初に思いついた課題表現は余分なものが多かったり、わかりづらい表現であることが多いため、そのまま解決策を考えようとするとうまくいかないことが多い。
- 課題表現の一部をずらす：例えば「〜を解決したい」という課題表現に対して、「〜を完全に解決したい」のか「〜という問題の発生頻度を減らしたい」のかなどを問うことで、課題の本質を特定する。
- 似たような別の課題との差：「カツ丼を食べたい」に対して「天丼じゃダメなの」みたいな感じ。
- 別の課題とまとめようとしてみる：振り返りなどで複数の意見が出た時にまとめるケースなどもあると思います。無理にまとめるのを目的にするのではなく、まとめて欲しくない部分が見つかった場合は課題の本質が見つかったと喜ぶ方がうまくいきます。
課題の背景を教えてもらう
課題の表現文字列が一緒でも発生しているコンテキストによって意味合いが変わることはある。例えば「お腹が痛い」ケース。→直前に生牡蠣を食べたとき（当たった）、大勢が参加するBBQで発生したとき（食中毒）、すごく辛いものを食べた（個人的な状況）など。
対立するのは見ている課題が違うケースが多いので、上記のようなアプローチでそれぞれが見ている課題を明確にしていく。課題の解決は後回し。課題の明確化が先。
思考の結果(output)のズレではなく、入力(input)と過程(process)のズレを中心に扱う
結果だけを見て反応する人が多いのですが、それはもう結果なのでどうしようもないです。
AさんとBさんで同じ課題認識をしてるはずなのに、なぜか出てくる対策のイメージが全然違う、というのはよくある話だと思います。このケース、考え方（過程）が違うというよりは、入力（過去の経験や今回の課題の見え方）が違ってることが多い印象です。
そういう意味で、対策や思考結果そのもので議論するよりも、そこに至った前提条件や背景などからずれを整理していくと揉めにくく、スッキリすることが多いです。
型/フレームワーク/フォーマットに落とし込んでズレを確認する
ホワイトボードなどに図式化すると参加者とも共有できる。脳内に描くだけでも整理につながる。
- ツリー形式：議論にしたいポイント、議論したいレベル・粒度、論理の抜け漏れ
- マトリクス形式：議論の軸（重視したい観点など）
個人的フルフォーマット
一度に全部使うと重すぎるので状況に応じて使い分ける
- 誰にとっての課題なのか（誰が困っているのか）→代弁者にどれだけ聞いても本当の課題は見えてこない
- その課題はどのような影響を及ぼしているのか、どれくらい急いでいるのか→課題による被害の度合いがわからないと優先順位が判別できない
- 解決方法ではなく「現在の状態」と「期待する状態」を把握する→「〜してほしい！」急ぎならそのまま答えるのはあり。答えつつも、結局？って聞くことが多い。
- その課題を解決しても繰り返し発生しそうかどうか→繰り返し発生しそうならそれは根本原因ではない（発生頻度や影響の度合いによっては根本原因を放置しても良い
- （他にもある気がするけど今は思いつかない）
- コントロール：参加者の感情に寄り添う
議論の熱量を見極めてうまく逃して課題の議論に集中してもらう
議論の熱量は冷静に見極める必要がある。めちゃくちゃ盛り上がっている状況で、「ここで一旦ストップ！」というのは必要なケースもあるが、わだかまりが残りやすいのでなるべくなら避けたい。
こんな言い方は誤解されるかもしれないが「ある程度のガス抜き」を目的として議論を泳がせることはある。ガスが抜け切ってない状態では次の議論に気持ちが入らないということは多い。理屈だけで人は動かないので、吐き出してもらうのが良い。（もちろん程度による）
また、ある程度議論を泳がせて、次に向けての整理を考えれるようになると強い。場合によってはその横道から良い課題が見つかるケースもある。
どうしても横道に逸れる場合は後回しにすることを明示する
別の論点を話したい！と思ってる人は目の間の論点をついズラしてしまうことが多い。これはその人が悪いとかじゃなくて、人間の習性として捉えた方が良い。
その場合は、論点を一旦受け止めた上で、後回しにさせてほしい旨を明確に伝えるのが良い。
なお、後になってから取り上げるかどうかはケースバイケース。
発話機会が少ない人に意図的に”バイネームで”話を振る
発話が少ない人に意識的に話を振る方が良い。発話が少ない人は意外と良い視点を持っていることが多い。今議論している前提条件自体に疑問を感じているケースなど、議論自体を解消させる良い気づきを思いついているケースもある。
また「みなさんどうですか？」では発話につながらないことが多いので、バイネームで聞くようにする。バイネームで聞いていたら、ある程度発話することに慣れて、自然と話すようになってくれる人もいる。が、まぁ個人のキャラクターに依存するので、「発話しない！」と憤ったところで状況は変わらないどころか悪化するので、ちゃんと振って、「ありがとう」と言えばいいと思う。
なお、具体的じゃない意見であってもうまく拾えるようにファシリテーターが支援できると強いが、そこはスキル次第。
発話のハードルを下げるようにする
ハードルを下げるアプローチはアイスブレイクだけではない。ハードルの種類を色々考えることが大事。
基本的には発話のハードルの原因となる「不安」を理解するのが大事。
- わからないって言っていいのか不安 → すごく基本的な用語でも質問していいことを示す（率先して基本的な用語を質問するのもあり）
- 怒られるんじゃないか不安 → ファシリテータがフォローするという信頼感を日頃から構築する
- などなど
発話してくれてありがとう！みたいなのはじゃんじゃん見せて言った方が良い。本当にみんなの中で発話が当たり前という空気感になればいらないとは思うが、例えばチームシンクで発言するのは多少なりとも勇気が必要なメンバーはまだいるだろうし、そういうのをちゃんと認めて本人の成功体験として積んで行ってもらうのが良い。
「発話してくれてありがとう！」は本人以外にも見ている周りのメンバーにも好影響を与えるので、そういう形で心理的安全性を醸成していくのが良い。（と思ってる。）
対立しがちな表現を言い換える（否定など）
誰しも、深く考えずに相手の意見を否定して自分の意見を言うことは多い。「XさんはAといったけど、私はBが良いと思う。」（よく考えると「XさんはAといったけど」は言う必要がないが、口をついて言ってしまうことはある。）
この場合、Xさんと私さんで不要な対立が生まれてしまうケースがある。可能ならそういう意図じゃないよね？とか確認しつつ、感情面のケアを中心に一旦置く。感情面が落ち着いたら、ロジカルな議論に戻していく。
ただ、これは程度問題があるので、あんまりにもキツイ表現で来られるとカバーしきれない時はある。しょうがない。
意見はちゃんと最後まで聞いた上で受け入れたことを示す
つい意見を聞いた直後に、対策の話をし始めてしまうことが多い。そうすると意見がうまく伝わってないと勘違いされて意見の説明を繰り返すことが発生する。
「意見を最後まで主張できた」「意見が受け入れられた」ということが明示されない限り意見の説明を繰り返す習性が人間にはあると捉えた方が良い。
「なるほど、〜という意見ということね、了解。」くらいの感じでリアクション返すだけでも良い。
反論はちゃんと最後まで聞いた上で受け入れたことを示す
まず指摘に対して反論するのは人間の習性（悪意とか打算とかではなく本能に近いもの）だと認識する。一種の心の防衛本能。自分が正しいことを示すためにある程度の理由を整理しているだけ。それが言葉や態度として表出するかどうかは人によるが、誰しも心の中では多かれ少なかれ感じるはず。
反論に対して「なるほど、そういうことだったんですね。状況了解しました。」というワンクッションを置くだけで、本筋に話を戻せる。そのワンクッションがないと、反論は繰り返される。
ちなみに、反論を受けて防衛本能から、咄嗟に反論の反論をしてしまうと、無限ループが発生する。
繰り返しが始まったら一旦止めて聞き手に確認を入れる
同じ話を繰り返していることに気づいたら一旦話を止める。
伝わってないと思って、話を繰り返すことが多いが、繰り返すよりも聞き手に確認する方が確実。
それ以外にも無言に耐えきれずに喋り出してるケースもあるが、いずれにせよ発話者を変えるのが良いため、聞き手に話を振るのが良い。
- クロージング：議論の終わらせ方
仕切り直しのパターン
このまま議論を続けても状況が変わらないケースはある。仕切り直し方もいくつかる。
- 議論内容が徐々にずれていって、参加者の大半が関係ない議論になってきているので、別枠でセッティングすることにして、本筋に戻す。
- このまま議論しても状況が変わらないにせよ、仕切り直す際のとっかかりだけはこの場で見つけておく。（〜が分かるようになれば議論が再開できるなど）
- 草案がないと無駄な時間を使うばかりになりそうなので、草案を作る人を決めて、別枠でセッティングすることにして、この場はクローズする。
- などなど
多数決を使う場合は少数派の意見も拾う
多数決は諸刃の剣。ある種少数派を切り落とすやり方でもあることを理解して使う。また、サイレントマジョリティというか、意見がない人が多数派に流れるケースもあるので、数字だけを見て判断するのは避けた方が良い。
なお、時間は有限なので多数決を使うこと自体は有用な場面が多い。が、少数派の意見を無視していいわけではないことを肝に刻んでおく。
最後に「その対策が課題を解消するのか？（ボトムアップな観点）」を確認する
課題をトップに置いて、ブレイクダウンしていって解決策がボトムだとします。
よくあるのはトップダウンで納得しておしまいになってしまうケース。自分がファシリテーターの時「その対策が課題を解消するのか？（ボトムアップな観点）」という指摘をすると「解消しないな・・・」ということがちらほらある。
この投げかけは、議論がある程度決着しそうな時に投げかける必要がある。なぜならこれは議論を混乱させることになるから。元々混乱している状態をさらに混乱させてしまうと訳がわからなくなる。少なくとも一方（トップダウン）の整理がついた後に、投げかけるのがちょうど良い。
明らかに問題ない時にこれを投げかける必要はない。怪しいなと感じた時に投げ掛ければ良い。
結論で確認すること
結論で以下を確認した方が解決に向けての動きに勢いがつきやすい。
- 解決すべき課題は何か？
- 課題解決のために誰が何をいつまでにするのか？
- 対策の完了確認は誰がいつするのか？（はたまたしないのか）
トレーニング
どんなものもいきなりできるわけじゃない。
人間の脳は慣れたやり方をすぐに思いついてしまうので、新しいやり方を身につけるには意識できる状況を作る必要がある。（手元にカンペを用意しておくなど）
- 時間をたっぷり使ってシミュレーションする（準備に時間を割く）
- 新しいやり方を試す（試さないと身につかない）
- ファシリテーターをやってみる（実践が一番身に付く）
- 振り返る（よかったことダメだったことをちゃんと振り返って学びを最大化する）
次回予告
本記事は、2022アドベントカレンダーです！
次回は、「心理的安全性を目的にするのは少し変だという話」をします。