エンジニアにこそ、 ファシリテーションが必要だと思った話

https://note.com/totokit4/n/n11b3f521bf79 の要約

Transcript

1. エンジニアにこそ、 ファシリテーションが必要だと思っ た話 ファシリテーション勉強会で学んだこと 5〜10分共有 社内向け 01
2. なぜこの記事を書いたか 背景 1年半ほど、有志の月 1回の勉強会に参 加 ・会議の進め方を実践しながら学ぶ場 ・エンジニアとして「正しさ」だけでは進まない場面を感じ た ・学んだことをnoteにまとめた 実践 → 振り返り → 現場へ 02
3. 正しい結論なら、人は動くのか？ 問題意識 会議は「正しい決定」をするため、と思いがち でも、結論が正しくても 実行されなければ意味がない エンジニアは論理・正しさに寄りやすい → 正論パンチになることがある 正しさ ？ 動く 03
4. 勉強会では、 7分ごとに実践する やっていること テーマを決める 7分ファシリ 振り返り フィードバック ファシリテーター自身が「意図」と「困った場面」を話す 他人の実演を見て、自分もやって、その場でフィードバックをもらう 04
5. 学び①：問題 vs 私たち 対立ではなく共同作業にする ファシリテーター vs 参加者にしない ・目的・前提・ゴールをホワイトボードに書く ・半円で同じ問題を見る ・誰かと戦うのではなく、問題に向き合う 目的 / 前提 / ゴール 05
6. 学び②：発散・分析・収束を分ける 今どのフェーズかを明確にする 発散 意見を出す 分析 整理する 意味を確認する 収束 目的に沿って まとめる 会議が迷子になる時は、何をしている時間かが曖昧なことが多い 06
7. 学び③：ファシリテーターは第三者である 決める人と進める人を分ける リーダーがそのまま進行役をやるのは難しい ・結果に責任を持つ人は、無意識に結論へ誘導しやすい ・ファシリテーターは「内容」ではなく「プロセス」を見る ・意見を言う時は「これは私の意見ですが」と明示する 決める人 決められる 状態をつくる人 07
8. まとめ：ファシリテーションはエンジニアの基礎体力になりそう 今日持ち帰ってほしいこと 納得感とコミットメントが高くなる 決定をできる力 ・納得感は「全員一致」ではない ・正しい結論でも、実行力が落ちることはある ・正しさを実行可能にするために、場を設計する 正しい結論 ＋ チームで実行でき る状態 ありがとうございました 08