ファシリテーション時の「頭の中の枠」と「ボードの中の枠」

先日、自社イベント会場で行われたイベントで、普段ミーティングでファシリテーションを行うときに考えていることについてお話しました。

スキルハックfukuoka#2 https://skillhack-fukuoka.connpass.com/event/79252/

どんなこと話したの?

わたしは普段ファシリテーションさせてもらうとき、Open−Narrow−Closeモデルを頭に浮かべて、それぞれ「どのくらいホワイトボードの面をつかったか」で議論がどういう状態にあるかを捉えるように努めていますよ、というのが主な内容です。

以下、スライドで登場するキーワードについての補足です。

議論の生産性とは?

※(ここでの議論はミーティングを指しています)

このイベントのテーマは「生産性」だったので、改めて「議論の生産性」について考えてみました。そのものが成果を出すためのプロセスの一部なので、「ムダな会議が多くない?」「参加人数でコスト考えると見合わなくない?」など、生産性について語られるとき、コスト要素としてネガティブに捉えられるケースも少なくはないのではないか、とおもいます。

  • 関係者全員が参加すると多すぎてコスト増。何人か結局しゃべらないよね。。
  • そのうえ合意が大変。何も決まらなくて終わったり。前回もそうだったような。。
  • 人数減らしてた結果、不参加だった人の意見であとからひっくり返って辛い。。

などなど。

正直わたしも「認識合わせる」「整理する」「議論する」「検討する」などが目的のミーティングであれば、slackなどのコミュニケーションツールで事足りると思っています。でもプロセスとして整理したり検討したうえで、最終的に「何か」が産まれ、それが投資に見合うものであれば実施する価値があるはずですよね。

ミーティングにおける投資は「参加者の時間」と考えて問題ないでしょう。(もちろん特定スペースの専有も伴いますが)次に「成果」の定義ですが、ここでは「高次の合意形成」としました。

高次の合意形成

単に「なるほどね」と納得感を得てもらうためであれば、わざわざ集まってミーティングしなくてももっとよい方法はありますよね。 自分1人では思いつかなかったようなことが産まれたり、見落としが補完されて「いいじゃんそれ!!すごい!!」って思える合意形成できたら、それは議論においての「成果」であると考えています。

f:id:akrmiya:20180414152247p:plain

そんな合意を分解すると ((納得感×人数)+ 共創性) と考えることができるのでは、と最近思っています。

多数の納得感を得たとしても、その分投資がかかっているので生産性が高まることはないです。でも 複数の視点 から産まれた「成果」には、抜け漏れのない網羅的な確認と、交錯からアイデアに深みがある。それは足し算でなく累乗の価値があると言える。そう信じることが引き出す側としての目標なんじゃないか とここで言いたかったのでした。

なお、人数イコール視点ではなく、1人で複数の視点をもつ人もいれば、職能が偏ることで3人で1つの視点になることもある、と思います。

とてもエモーショナルですが、伝わると幸いです。

話したとき上がった質問

「リモートではどう実現する?」という質問をいただきました。これは正直ずっと答えが出ずにいるし、当日も明確に答えられなかったのですが

  • リモートで無理にリアルミーティングのファシリテーションの成果を求める必要はない。
  • リモートならチャットツールで十分に事足りる。
  • これからリモートワークが当たり前になる分、実際に顔を併せる希少な機会で何が産み出せるかはとても重要。
  • 高度の職能レベルとファシリテーションスキル併せもつ人同士は言語のみで脳内同期可能で、リモートでも問題ないように見えている。
  • そんな人達でも顔を会わせたらもっと高い価値を産むのだろうな、と信じている。
  • VRミーティングが当たり前になったら、その時考えをアップデートしたい。

などなど思っています。

まとめ

  • 複数の視点を交錯させることで、ミーティングは生産性を高めることができる。
  • 課題に対するアイデアや考慮すべき要素を、網羅的に拡げ、収束して「成果をだす」ことがミーティングには必要。
  • 「頭の中」と「ボードの枠」を同期させ議論の状態を捉える。

当たり前のようなことですが、導くのがファシリテーターの役目であれば、しっかり意識しておきたいとおもっている次第です。

イベント開催情報

なお、明日(2018年4月15日)は以下勉強会のメインファシリテーターを行う予定です。 今回おかげさまでもう少しで定員です。興味ある方、是非お待ちしてます。

fflab.connpass.com

数値でふりかえる2017年、その先としての2018年

仕事

ファシリテーション 135回

ほとんどが社内(社外で5回ほど実施)だが、これまでの3倍くらいの回数だと思う。2017年はエンジニア職としての担当サービスのリーダーから管理職へと、ハイスピードで役割が拡張していった。その中で「直接話をしておいたほうがよい」と自分が感じた場面で主催していった結果の数。その場面というのは

  • メンバー皆の前提がずれていてコミュニケーションロスが発生している。
  • メンバーそれぞれにとって重要度の格差があり、優先度の設定にも至っていない案件がある。
  • メンバーの経験成長のため、成果を客観的に評価してほしい時期を迎えた。

およそその場面でやっていたのはこの3つ。

  • デザイン思考アプローチでのアイディエーション
  • 論理的思考アプローチでの仕様FIX
  • ふりかえり

その後どうなった?のフォローも欠かさず行った。この中で幾つかのフレームワークを考え実践したので、それはまた別の機会で紹介したい。次々に増える課題に対して、とにかく前に進む動きを止めないことで精一杯だったようにもおもう。

あえてミーティングをやらない場面もあった。

  • GHE(GitHub Eniterprise)のイシュー上で完結できるような課題が複雑でない場合。
  • KPTでいうところのProblemがあまりに外的要因の影響を受けている場合。
  • 既にそれぞれメンバーが内発的に動機づけられ連携がうまくいっている場合。

こういった場合は発生するネガティブ要素を個別に除去するフォローのみに努めた。 こうふりかえると、自分のやりたいファシリテーションは「みんなの望む未来を、なるべく早く、みんなで迎えるため」と定義できるな、と今感じている。最近はチームが置かれている状況をシステム図化して「ボトルネックを除去する」「より活動を強化する」手段の1つとしてミーティングとそのファシリテーションを位置付け、活用することを実践している。 2018年は 「メンバーが手を止め思考を共有することで生産性が高まる」と考えられる場面を見極めることを意識下において、ファシリテーションの数と、それによって獲得した未来「共有ビジョンの構築」「定量目標への到達」を計測してみたいとおもってる。

海外渡航 1回

採用目的ではじめて海外(ソウル)に渡った。たった1回だけども、大きな意味のある1回だったと思う。 入国カードで「Business」にチェックを入れたのもはじめてだった。目的も達成できそうな見込みのうえ、世界基準で技術・チーム・事業を考える動機付けとしては十分だった。これまで単なる旅行としては20〜30回くらい海外渡航しているが、「この渡航で成果を出す、出さなければただの旅行」というこれまで感じたことのなかった緊張感が自分の中で高まっている。2018年は既に1月、再度ソウルへの渡航が決まっているが、中長期的目標に向け、自分たちの活動範囲を拡張する年にしたい。

生活

ライブ 9回

2017年は少なかった。

ベストアクトは11月のogre you asshole。 一番はしゃいだのは12月のハイスタ。 一番感動したのはサンセットのハンバート。

2017年は年始のCloud nothingsをはじめYumi zouma、Frankie cosmos、Japanese Breakfast などなど、めんたい村を無視した来日が続きくやしい1年だった。2018年は遠征もしたい。

旅行 2回

会社仲間で行った沖縄は最高の思い出の1つ。今年もまた行きたい。 バンコクはトーキョーに似てた。タクシーとめるのが大変。

年齢 39歳

2018年は40歳になります。

上司より年上に見られる 2回

もう慣れました。

2018年もどうぞよろしくおねがいします。

ふりかえりにつかうレイアウト「4G」を考えた

チームのふりかえりにつかうホワイトボードのレイアウトをかんがえました。

f:id:akrmiya:20170427141404p:plain

なぜ?

「役割を考えてチームの体制をつくる」というふりかえりミーティングのファシリテーションをする予定がありました。

お互いの思っていることを言い合うプロセスは必要(というか大事)なんだけども、なるだけ早めにチームとして機能する状態にしたい。そのうえ、開発業務とちがって「どういう役割が必要なのかあまり想像つかないぞ….」と思ってたわけです。

チームのふりかえりではKPTをよく使うんですけど、今回のケースだとTRYとして体制まで考えるのは結構大変で、もう一歩踏み込んだやり方を「ホワイトボードのレイアウトを上手く使ってとれないか?」とかんがえたんです。

どうやって使うの?

  • 何らかのチーム作業を(スプリント0)一度経験しておく。
  • チームの目指す目標は最初にかいておく。
  • ひととおり矢印の順番にすすめる。

詳しくは以下スライドをご覧ください!

speakerdeck.com

使ってみてどうだった?

「目的」を途中に挟むことでブレなく話ができたようにおもいます。またKPTでいうところの「KEEP」を「GOOD→GROUND」と段階踏むことで「なぜ?」「それはつまり何?」と全員が思考できたようにもおもいます。

10人ほど参加のミーティングにて

フェーズ 所要時間
GOOD 15分
GROUND 20分
GOAL 5分
GAP 20分
ROLE&RULE 60分

というとこでした。

今後もチームとして「自分たちのやり方」を改めて見直したい場面などで、もっと色んな場面でつかっていって フレームワークと呼べるものにブラッシュアップしていきたいなとおもっています。

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

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

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