読者です 読者をやめる 読者になる 読者になる

ファシリテーターについてまとめてみる。

チームビルディング

ファシリテーターについてまとめてみたいとおもいました。

f:id:akrmiya:20170211195744j:plain

なぜ?

今年は「ファシリテーション」について、勉強の時間をふやしています。

理由は、今年からリーダーというポジションについたという点が大きいです。わたしはチームにおいてリーダーの担う役割とはチームの目指す目標を達成するため、チームの生産性を最大化させること とかんがえています。

生産性向上のため、メンバー全員が納得し、新しい仕組みを運用していくとしたら、そのプロセスに 意見を話し合う という場はかかせないものとかんがえています。なので、議論活性化しまとめる能力 というのは生産性のたかいチームをつくるために欠かせないものだとおもうんです。

で、社内でファシリテーションについて話す機会をちょっぴりつくれそうなので、いま時点での 自分の考えるファシリテーターの役割とのそのやり方ってのをまとめてみようとおもった次第です。

ファシリテーションとは

ファシリテーション(英: Facilitation)は、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の1つ。

ファシリテーション - Wikipedia

これを実践するひとを ファシリテーター とかんがえます。

ファシリテーターの役割

  • 参加者を動機付けする。
    • なんのために自分は議論に参加しているのか?を参加者が理解するための準備を行います。
  • 議論のプロセスを管理する。
  • 成果を具現化する。
    • その後、決定したことは実現されたか? 次のプロセスに議論が発展したか?フォローを行います。

ファシリテーションのながれ

ここでは自分の属するチームに限定せず あるミーティングのファシリテートを依頼された としてかんがえてみます。

準備

1.目的設定の準備

  • 可能なかぎり下記目的を事前に確認します。
    • このミーティングは、何のために行うのか。
    • このミーティングは、誰にとってメリットがあるか。
    • このミーティングで、何を達成したいのか。

これらが不明確な場合は、ミーティング自体必要ないかもしれません。

2.参加者の決定と分析

  • 目的に応じて、どういう人が参加すべきなのか事前に考えておきます。
    • 決定したい場合、決定権のある人。
    • 運用する場合、実際にその運用をとる人。
    • 開発する場合、実際にその開発をする人。
  • 参加者はどういう人なのか確認しておきます。
    • どういう知識/スキル/経験をもっているのか。
    • どういう意欲や関心をもっているのか。
    • ミーティング実施の目的に対して賛成/反対、どういう感情をもっているか。

実施

1.導入

  • 長時間、多人数であれば事前のアイスブレイクを実施します。
  • 少人数であれば「このミーティングのおわったあとどうなっていたい?」といった参加動機をひとりずつ聞くのもよし。
  • また、目的設定の準備で確認しておいた内容から ミーティングのゴール を共有します。
  • ゴールに応じて、おおまかな 議論の枠組み をきめて、タイムマネジメントを行います。

2.議論を進める

  • 参加者の意見が一致している論点にはあまり時間をかけないようにします。
  • 参加者の意見が割れる論点に時間をかけるようにします。
  • 発言を引き出すように努めます。
    • 興味持ちやすい話題を提供する。「◯◯さんXXについて話してませんでした?」
    • 状況を具体的に設定する。「例えば〜みたいな問合わせがきたりとかですね」
  • 発言を受け止めるように努めます。
    • 発言そのものと、発言に至った背景を理解する。「なるほど〜だから〜とおもったわけですね」
    • 自らの判断を加えない。
    • 発言を聞くときはその後の流れなどを考えず、発言に集中する。
    • 自分がどう理解したか復唱し、理解したことを示す。「つまり〜ということなんですね」
    • 発言者が感情的な場合は口調動作などを相手に合わせてペーシングする。
  • 適切な質問をするよう努めます。
    • オープンクエスチョンでアイデアを引き出し、参加者の参加意識を高める。「どんなものがありますか?」
    • クローズドクエスチョンで参加者の合意をつくる。「これについてはYES/NO?」
    • 言葉の定義を明確にするための質問を行う。「それはなに?」
    • 抽象的な言葉を具体化するための質問を行う。「つまりそれはなに?」
    • 主張に対して根拠が欠落している場合、確認の質問を行う。「それはなぜ?」
  • 発言を整理します。(ホワイトボードや付箋をつかっておく)
    • 同じ意見をまとめることで抜け漏れをふせぐ。
    • 意見を関連づけていく。(目的/手段、原因/結果、タイムライン、事象/解釈)
    • 整理した内容のレベル合わせをする。(抽象度で並べてみる)
    • 意見が一致していないのに議論が不足している箇所がないか明らかにする。
  • 横道にそれた発言に対処します。
    • 的外れな意見の場合、受け止めた上で、今後の材料として仕分けておく。
    • 意見のレベルがあってない場合、(いきなり具体策/そもそも論)ずれを指摘し発言の理由を確認する。
    • これらは導入での目的共有が弱いとおこりやすいので、ミーティングのゴール を再確認する。
  • 対立のマネジメントを行います。
    • 一致しているもの対立しているものを区分けし、参加者が対立点を客観的にみることを可能にする。
    • 意見が対立しているのか、意見の抽象度の違いなのか、明確にする。

3.クロージング

  • 議論の結果としてどのような結論が導き出されたか、共有します。
  • 次回開催が必要であれば、いつ、何について、誰が、どのような準備のもと行うか明確にします。

フォロー

1.内容へのフォロー

  • 結果が必要な範囲で正しく共有されているか確認します、例えば議事録など。
  • 結果が実行に移されているか確認します。「その後どうなりましたか?」

2.参加者へのフォロー

  • 参加者はミーティング後どうなったのか、ネガティブ要素が発生していれば声をかけるなどフォローします。
    • 認識 それぞれが、結果をどう認識したか?
    • 関心 それぞれが、どの論点を重視していたか?
    • 感情 それぞれが、結果/プロセスにどういう感情をもったか?

全体通して注意しておきたいこと。

  • 「議論する」「整理する」「検討する」といった あいまいな目的 は避ける。
  • 前提の違い を意識する。例えば「顧客満足度向上」は職種によって意味付けが異なる場合がある。
  • 様々な解釈がある ことを意識する。
  • 参加者によって、参加することへの 重要度の格差 があることを意識する。
  • 対立において 自分の知らない人間関係がある可能性 を意識する。
  • 職種(エンジニア/デザイナ/ディレクターなど)間の差異を実際以上に強く感じる強調化効果 があることを意識する。
  • 逆に同じ職種内では実際以上に同じ特性をもっているように感じる 同化効果 があることを意識する。
  • 沈黙をうまないよう意識する。同調圧力により皆が黙ってしまう 可能性がある。
  • 一度決めたことを正当化し、一貫性を保ちたいという意識が ただのこだわり を生んでいる可能性があることを意識する。
  • その場合、前提が変化していることを参加者で共有し、一貫性が崩れているわけでないことを明示する

まとめてみて思ったこと

ファシリテーションってめちゃくちゃ大変じゃん…….。 けど、これができたら、すごくよいチーム状態を維持できる とおもえるようにもなりました。

議論の枠組み議論のすすめ方 など、具体的な方法については ロジックツリーやファシリテーショングラフィック、ビジネスフレームワークなどの勉強をしているので、こちらもこんどまとめてみようとおもいます。

(ちょっとだけ追記)

これまでやってたこと、意識しようとしていたことを、あらためて1つ1つ振り返ってまとめてみた結果、 「できてたつもりだったな….ファシリテーションってめちゃくちゃ大変じゃん……」って客観的におもえたんです。 まとめるのだいじですね。

Hugoでサイトつくってみる

サイト制作

サイトジェネレータつかって静的コンテンツをいい感じに作りたいとおもいました。

ここでのいい感じとは

Webアプリケーションと切りはなされてて
Edgeがきいてて
Lovelyで
Long life(飽きがこない)

つまり「WELL」(いまかんがえた)

Hugoがファイル生成速くていい感じらしいので試してみます。

インストール

GitHub - spf13/hugo: A Fast and Flexible Static Site Generator built with love in GoLang

installing guide に従ってインストール

Hugo - Installing Hugo

goはいってない場合はgoから。

$ brew install go

How to Write Go Code - The Go Programming Language

zshつかってるので ~/.zshrc でGOPATH指定します。

これからGoを始める人のためのTips集 | The Wacul Blog

なるほどなるほどっておもったので、以下のように指定しました。

export GOPATH=$HOME/go/third-party:$HOME/go/my-project
export PATH=$HOME/go/third-party/bin:$HOME/go/my-project/bin:$PATH

準備できたのでインスト〜ル

$ go get -v github.com/spf13/hugo

mysite をつくります。

$ hugo new site mysite

カレントディレクトリに以下の構成ができました。

$ tree mysite
mysite
├── archetypes
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes

Hugo Themes Site

テーマを試しに1つ用意します。

git clone https://github.com/lasseborly/anybodyhome.git themes/anybodyhome

config.tomlを編集。

baseurl = "http://replace-this-with-your-hugo-site.com/"
title = "My New Hugo Site"
languageCode = "en-us"
theme = "anybodyhome"

記事つくってみます。 hugo new hoge.mdcontent 下に追加されました。

$ cd mysite
$ hugo new hoge.md
$ tree .
.
├── archetypes
├── config.toml
├── content
│   └── hoge.md
├── data
├── layouts
├── static
└── themes

TOML記述のfront matterがページ毎のパラメータとしてついてます。 もちろんカスタマイズできるとのこと。

$ cat content/hoge.md
+++
title = "hoge"
draft = true
date = "2016-09-12T02:45:25+09:00"

+++
$ vim content/hoge.md
+++
title = "hoge"
draft = true
date = "2016-09-12T02:45:25+09:00"

+++

# My First static page generate by Hugo.

確認のためサーバー起動&ビルド

draft=trueのページしかないのでドラフト版もビルドするオプションつけます。

$ hugo server --buildDrafts
Started building sites ...
Built site for language en:
1 of 1 draft rendered
0 future content
0 expired content
1 pages created
0 non-page files copied
1 paginator pages created
0 tags created
0 categories created
total in 34 ms
Watching for changes in /Users/akrmiya/test/mysite/{data,content,layouts,static,themes}
Serving pages from memory
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

f:id:akrmiya:20160912032251p:plain 表示できました。

ビルド後の構成。(テーマ以下は省略)

├── archetypes
├── config.toml
├── content
│   └── hoge.md
├── data
├── layouts
├── public
│   ├── 404.html
│   ├── index.html
│   ├── index.xml
│   └── sitemap.xml
├── static
└── themes
    └── anybodyhome

飽きてないし愛せるのでHugoいい感じです。 整えてこんどオリジナルテーマつくりたいとおもいます。

クリティカル・シンキングを学習するに至った

クリティカル・シンキング

半年前くらいからクリティカル・シンキングに興味をもち、ついにはビジネススクールに通いはじめるに至ったという話。

学習のきっかけ

自社で数年前、スクラムスクラム説明は割愛)を事業部で導入するとなったとき スクラムマスターという役割に立候補しました。平たくいうとチーム内のお世話役。

以降、チームビルディングやファシリテーションに関心をもち 自分なりに仕事の進め方を工夫しながらやってきました。

そのことは社内でもなんとなく知られ、なんとなく自分に そういった質問が来ることも増えてきました。

ところが最近ふりかえって見ると、チームがどうよくなったのか説明できません。 1つ1つのプロジェクトにおいて、その時うまくチームを回すためのパターンを 自分がいくつか知って、いくつか試せた。ただそれだけのように感じていました。 どうやったらもっとチームの状態が良くなっていくのだろう、とモヤモヤした日々を過ごしていました。

そんな時に人に勧められてこの本を読みました。

クリティカル・シンキング(批判的思考) 論理的にものごとを考える思考プロセスのひとつ。

デザイン系の学部にて芸術論を専攻していたので、芸術鑑賞の基本である 「疑って捉える姿勢」については理解していると思っていたのですが ビジネスにおいてのその姿勢は、抽象的すぎるものだったようです。

少なくともモヤモヤする原因は「どうよくなったのか説明できない」自分にあるよう。

ザッと本を読んで感じたことは

  • チームに対してそもそも何を課題と考えていたのか。

  • それをどういう論点で捉えるのか、その根拠は。

  • どういう結果がでれば解決したと言えるのか。

  • 自分は「やりたいこと」「やるべきこと」の区別がついていない。

  • 自分は思考のクセがあるようだ。

  • 自分は手元にある情報や経験を前提にし過ぎのようだ。

独学ではなく腰を据えてちゃんと学習してみよう。と思うに至るには自分には十分な気付きでした。 業務/チーム/自身のキャリア、なんでも論理的に考えられる下地を身につけたいと感じた私は 前述の本の出版元、グロービス経営大学院の福岡校に通いはじめたわけです。

ブログ

というきっかけがあったので、ちゃんと学習するため アウトプットとしてブログを書くことにしました。

何してるの?

GMOペパボという会社でエンジニアをやってます。 入社したときはデザイナーでした。 サービス運営のジェネラリストを自分のキャリアプランに据えてます。