競馬好きのプログラミングブログ

競馬の統計分析をしていたらwebエンジニアになっていたエンジニア見習いのブログ。データ分析したりwebアプリを作ったりして学んだことを書いていきます。

ファシリテーションの話

前職ではスクラムで開発をしていたのですが、開発以外にも様々なスキルが求められていました。

今回はその中の一つ、ファシリテーションについて書いていこうと思います。

ファシリテーションとは

皆さんはファシリテーションと聞いてどのようなことを思い浮かべるでしょうか?

Wikipediaによると

ファシリテーション(英: Facilitation)は、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の1つ。 コミュニケーションスキル以外にも、ルールが必要な場合の内容設定や補助、プログラムのデザイン、進め方や、さらに会議の場所や参加者の選択、日程のデザインなど、オーガナイザーやリーダーの機能を担う。

とのことでした。

いろいろ書いてありますが、今まで私が研修を受けたり、勉強してきたことの答えは「ゴールに向かって推進させること」です。

ファシリテーターとは

ファシリテーターとは読んで字のごとくファシリテーションをする人のことを言います。こちらの役割は主に次の3つです。

  • 参加者に話してもらう
  • 参加者の意見をまとめる
  • 議論をずらさない

これらとは逆のことはしてはいけません。例えば、自分の意見ばかり言うようなファシリテーターはあまり良いファシリテーターとは言えないでしょう。

実際のファシリテーションの流れ

いきなりファシリテーターの役割はこれです!と言われてもイメージはつかないかと思います。 なので実際の会議の流れを具体的に書いてみようかと思います。

  1. 目標の整理

    会議が始まる時にその会議の目標が整理されていること 体言止めはだいたいよくない (×「生産性の向上」 ○「生産性を上げるための施策を考える」)

  2. アイスブレイク

    参加者が意見を発散させやすいように。自分の経験等からうまいやつをパクったりしたい

  3. 発散フェーズ

    ゴールに向かう意見を集める。

  4. 収束フェーズ

    集まった意見をグルーピングするなどしてまとめていく。 目標に即していない場合は再度目標に照らし合わせて発散からやり直す

  5. まとめ

    Next Actionを決める。5W1Hを全部埋めるくらい詰める 会議後にファシリテーターアサインをしておくこともある

実際の例

主に発散フェーズ、収束フェーズにフォーカスして書いていきます。

人数が多い時

人数が多いミーティングでは全ての参加者に意見を出してもらうこと、その意見をまとめること、議論をずらさないことはとても時間がかかり大変です。 そのため、ある程度工夫をすることが必要です。 1. ポストイットで意見を集める(時間短縮にもつながります。) 2. 集めたポストイットをグルーピングしていく(ホワイトボードに貼る時に似ている意見の近くに貼ってもらうなどをするととても楽)

経営会議のような重要な会議の時

ほとんどの人がファシリテーションをしなくても会議がぐんぐん進んでいくような会議の場合、無理にファシリテーションをしようとしない方が良いかもしれません。 1. 発散フェーズは参加者に任せていく(時間を意識して収束フェーズに持っていく) 2. 収束フェーズでは、本当に目的を達成しているのかどうかをしっかりと確認していく。このような会議の場合より明確に目的を達成している必要があるので、もしも時間内に目的が達成できなそうな場合、別途日程を設けるなどする。

最後に

結局のところエンジニアでも人と話すことがとても大事なのだと思います。 開発に集中するためには、早く正確に他の人とのコミュニケーションをする必要があると思うので、参考になる人がいれば幸いです。