エンジニアがファシリテーション勉強会に参加し続けて得たもの
こんにちは！ととです。
私は普段モバイルアプリエンジニアとして仕事をしていて、普段は「どう作るか」「どう設計するか」「どう問題を解くか」を考えることが多いです。
でも近年、それと同じくらい、あるいはそれ以上に、「どう話し合うか」「どう決めるか」が大事なのではないかと思うようになりました。
月に1回、Sansanさんの関西オフィスに集まり、「ファシリテーション勉強会」に参加しています。
私は第二回から参加していて、行けない回もありつつ、約1年半この勉強会に関わってきました。今回はそこで得た気づきを書いてみたいと思います。
どんな勉強会なのか
この勉強会のテーマは、「実践から学び、学びから実践へ」です。
ファシリテーションについて座学で学ぶというより、実際にやってみて、振り返って、また現場で試してみる。そんな場です。
チェックイン
勉強会では、最初にチェックインをします。
議論に入る前に場の雰囲気（空気）を確認し、参加者の心理的準備を整える作業です。
「少し緊張しています」
「最近〇〇を始めました」
「仕事でこういうことがありました」
これは単なるアイスブレイクというより、話す相手を「人間」として認識する時間なのだと思います。
少し疲れていそうだな、今日は緊張しているんだな、最近こういうことに関心があるんだな。そういう小さな情報があるだけで、議論の空気は変わる気がします。
テーマを決めて、ファシリテーション実践
この勉強会では、テーマをひとつ決めて議論します。
これまでにも、「多数決はなぜだめなのか」「若手から相互の人間関係を築くには」「この勉強会のテーマは何なのか」「良い会議と悪い会議は何が違うのか」など、色々なテーマで話してきました。
メインはファシリテーションの実践ですが、テーマそのものから得るものも多いです。
世代によって議論の進め方が違うこと。
組織のビジネスモデルが、組織文化を形作ること。
そしてそれが、意思決定の仕方や会議のやり方にまで影響しているのではないか、ということ。
勉強会では、7分ごとにファシリテーターを交代し、議論を進めます。
そして交代のたびに、自分でやってみた感想と、メンバーからのフィードバックを話します。
「自分はファシリテーターとして、ここに気をつけていた」
「7分の中で、あの場面に困った」
「あの時、どう進めるか迷った」
こういう自分の意図や迷いを、ファシリテーター自身が開示します。
自分のファシリテーションについて、こんなふうに話す機会はなかなかありません。
そして、メンバーからのフィードバックも毎回面白いです。
「〇〇というアクションが良かった」
「〇〇という意図が伝わった」
「あの時はどうして〇〇と言ったの？」
など、そんな風に見えていたのか、だとか無意識にやっていたことを教えてもらったりすることができます。
自分では無意識にやっていたことを指摘してもらえたり、逆に意図したことがちゃんと伝わっていたと分かったりします。
他の人のファシリテーションを見て、自分も実践して、その場でフィードバックをもらえる。これが、この勉強会の大きな価値だと思っています。
他にも、職場の人間関係づくりトレーニングにあるゲームをみんなでやったりすることもあります。
得た気づき
議論の最初に、前提とゴールをそろえる
ファシリテーションの勉強をしたいかもと思った頃、一番悩んでいたのが「議論が明後日の方向にいかないようにする」ことです。
この勉強会に参加して、最初に癖がついたのが、議論の冒頭で以下を確認することです。
今日話したいテーマは何か
その背景は何か
この時間のゴールは何か
ゴールを議論の途中で再設定することもあります。
議論が白熱して、時間が経ってしまった時、残る時間で何ができるかを考え、その場の落とし所を決めます。
そして必要であれば、宿題やネクストアクションを書く。
大事なのは、ゴールに少しでも近づくことです。
「結局なんのための会議だったんだっけ」
「何を話したんだっけ」
そういうモヤモヤを、参加者に持ち帰らせないようにする。
そのために、合意が取れた目的、前提、ゴールなどをホワイトボードの目立つところに書いておきます。
議論中、ファシリテーター自身もそれを見返しながら進めることで、話が脇に逸れた時に戻ってきやすくなります。
問題 vs 私たち、という構図をつくる
議論がうまくいかない時、いつの間にか「ファシリテーター vs 参加者」や「誰か vs 誰か」という構図になっていることがあります。
でも本来は、「問題 vs 私たち」であるべきです。
そのために、勉強会では問題（議論の目的、前提、ゴール）を書いたホワイトボードに向かって半円になる形で議論を進めます。
ディベートではないので、誰かの顔を見て戦うのではなく、みんなで同じ問題を見る。
これは、姿勢だけでも表せるのだと感じました。
ファシリテーターをする時も、発言者と真正面から向き合って対峙するのではなく、同じホワイトボードを見るように立つ。
小さなことですが、議論を共同作業にするために大事な振る舞いだと思います。
ファシリテーションに意図を持つこと、意図を話すこと
実践を通して感じたのは、ファシリテーターにも意図が必要だということです。
そして、その意図を話すことも大切ですし、発言者の意図を汲み取ったり聞き出したりすることも必要です。
時にエンジニアの発言は、時に攻撃的に受け取られることがあります。
「それは間違っています」
「この設計だと危ないです」
「そのやり方はやめた方がいいです」
言っていること自体は必要でも、背景や意図がないと、ただ否定されたように聞こえてしまいます。（自戒も込めて）
でも、「この観点が抜けると後で運用が苦しくなりそうなので確認したいです」と言えば、受け取られ方は変わるかもしれません。
同じ内容でも、意図を添えることで、議論は攻撃ではなく協力になります。
AIに指示を出す時、前提や背景を丁寧に渡すと、期待に近い返答が返ってきやすくなるように、人間相手の時にも、本当は同じことが必要なのだと思います。
発散、分析、収束を意識する
ファシリテーターの大事な役割のひとつに、タイムマネジメントがあります。
最近は「発散」「分析」「収束」の3つを意識すると、かなり進めやすくなりました。
発散は、色々な意見をたくさん出すフェーズです。
ここでは、なるべく多くの意見を集めます。
もちろん発散しすぎると、あとでまとめるファシリテーターは大変になりますが、ここで十分に聞けていないと、後から参加者の「自分の意見を聞いてもらえなかった」という不満につながることがあります。
分析は、出てきた意見を整理するフェーズです。
グルーピングしたり、似ている意見をまとめたりします。
ただこの時、ファシリテーターが勝手に文言を書き換えすぎないことも大切です。
人によって言葉の定義が違ってたりするので、喋った言葉をそのまま書く。
端的にまとめたい時は、「〇〇ということで合っていますか？」と発言者に確認する。
この一手間をサボると、「なんかズレてきてない？」と後の議論がこじれてしまったりすることもありました。
収束は、集めた意見を会議の目的に沿ってまとめるフェーズです。
ここでまた発散に戻らないようにするのは難しいです。けれど、「ではそろそろまとめに入りましょうか」などの声かけをして、参加者も今は収束の時間だと意識できると、会議はかなり前に進みやすくなります。
また、どちらか一方ではなく、複数の意見をくっつけるというような提案をするというのもここのフェーズでやることもできそうです。
議論を構造化する
ホワイトボードには、議論の内容を書いていきます。
言葉だけで議論する、いわゆる空中戦を避けるためです。
出てきた意見を表にしたり、構造化したり、色を分けたり、強調したりする。すぐ色を切り替えられるように、ペンを3色片手に持つこともあります。
今のAI議事録は、平文で会議の進行を記録するものが多い印象です。
でも議論する時に欲しい議事録は、議論の構造や関係性が、その場で見えるもの、ファシリテーショングラフィックというものです。
（似たようなものにグラフィックレコーディングがあります）
リアクションを引き出す
ファシリテーションを考える中で、リアクションの大切さも感じています。
特にリモート会議では、反応が見えにくくなります。
会議の最初に「なるべくリアクションしてほしい」と伝えておくだけでも、場は変わるかもしれません。
話している人が安心して話せるように、うなずきやスタンプ、チャットでの反応を意識することも大事です。
また、ファシリテーター以外の、議論に参加している人も「影のファシリテーション」をすることで、場の納得感を醸成しやすくなるというのも、実践を通して感じたことです。
ただ、今の勉強会では、そもそもファシリテーションに興味がある人たちが集まっているので、勉強会では「意見を言わない人」がおらず
実際の現場で、あまり発言しない人がいる場合にどう聞き出すかは、まだまだ今後考えたいところだなと感じています。
ファシリテーターは、場を操作する人ではない
勉強会で印象に残っていることのひとつに、ファシリテーターは第三者である必要がある、という話があります。
議論の結果に責任を持つリーダー格の人が、そのままファシリテーターをやるのは難しい。
たとえばリーダーが「いい意見ですね」と言うと、その発言が場に強い影響を与えることがあります。リーダーにとっては何気ない一言でも、参加者から見ると「この意見が正解なのだ」と受け取られるかもしれません。
もちろん、ファシリテーターが意見を言ってはいけないわけではありません。ただ、その時は「これは私の意見ですが」と前置きをすることが大切です。
そうしないと、それが会議のまとめなのか、ファシリテーター個人の意見なのかが曖昧になります。
そしてその曖昧さは、場合によっては「参加者の議論を無視して、ファシリテーターが自分の意見を会議の決定として操作した」と受け取られかねません。
ファシリテーションをできる人を育てる
ファシリテーションは、特殊な人だけが持つスキルではなく、チームで働く人に必要な基礎体力のようなものだと思います。
そして、ファシリテーションができる人を増やすことも、チームリーダーの仕事なのだと思います。
固定メンバーだけがファシリテーターをするのではなく、Slackでランダムに決めたり、持ち回りにしたりする。
いきなり重い意思決定の場ではなく、朝会のような比較的責任の軽い場から始めるのも良さそうです。
正しい答えを選ぶだけではなく、みんなで前に進める決定をする。
その力は、これからのエンジニアにも、きっと必要になっていくのだと思います。
ファシリテーションは、納得感のある決定をつくる力
議論というと、つい「正しいことを選ぶため」にするものだと思いがちです。
でもどれだけ正しい結論でも、その決定に関わった人たちが納得していなければ、その後のコミットメントは弱くなります。
だからこそ、意見を聞くこと、発散の時間を取ること、傾聴すること、「みんなで決めた」という感覚をつくることが大切なのだと思います。
ファシリテーションとは、場をうまく支配する技術ではなく、参加者が納得して議論に参加できるようにする技術なのだと学びました。
謝辞
この記事を読んでファシリテーションに興味をもった！という方は、
かわのさん、広瀬さんが近々エンジニア向けのファシリテーションが学べるイベントを考えているとのことなので、ぜひチェックしてみてください。
いつも場所を提供くださる、Sansan株式会社さま（関西支店）
そして勉強会のメンバーの皆さまに感謝して、この記事を終わります。
いつもありがとうございます。これからもよろしくお願いいたします！
おまけ
勉強会で、トーキングオブジェクトというものも知りました。
会議では使わないものだそうですが、話す人が持つもので、それを持っている人だけが話せる、というルールを明示する道具です。
それを持っている人以外は話せないので発言権をコントロールして割り込みを防ぐほか、特定の人（偉い人など）ばかりが話してしまうことにも効果があります。
小さいぬいぐるみのような柔らかいものだと、持っているだけで少し緊張がほぐれる感じもありました。
