関連

• リモートワークにおけるファシリテーションの方法論を公開します！
• 書籍: ファシリテーション入門〈第2版〉
• 組織開発の氷山モデルが言及される記事

分解

前提

• 作成のきっかけ
  • コロナが流行りだしてリモートミーティングを取り組む会社が多くなる中で、自社は結構経験があったから
• 言語解説：コンテントとプロセス
  • コンテンツ
    • プロジェクトで生み出したい成果
  • プロセス
    • 良いコンテンツを生み出すためには環境が大事

ファシリテーション

• ファシリテーションとは？
  • より良いゴールを達成するために必要な一連の行為が適切に行われる状態を作ること
  • ファシリテーター1人ではなく、関係するメンバー全員で行っていくべきもの
• なぜ全員でファシリテーターをする必要があるのか？
  • 特定の一人でファシリテート（マネジメントも）するのは、複雑化するプロジェクトでは無理だと思っている
  • 負担を全員で分散
  • 全員が経験することでプロジェクト自体が良くなる
• リモートワークのファシリテーションで、特に何を意識するといいのか？
  • 「基本認識がずれやすくて、ズレを確認しにくい」という前提を持つ

合意形成の難しさ

• 地域における合意形成の難しさ
  • 住んでいる人数千人の合意100％など取れない
    • 質も数も
  • 二人の関係の合意形成でも無理かもしれない
• みんなで議論して合意するのは理想だけど、現実的には無理だ
  • これを前提とする
  • 期待と諦めを持った方法論
• なぜ合意形成はこんなに難しいのか？
  • あるイシューに対する意見は、それぞれの人のコンテキストが必ず違う
  • コンテキストの円やベン図がどこまで重なっているかが合意
    • 円を全て重ねようとするのは無理
      • できない前提
  • プロジェクトスプリントをこなしていく中で円が徐々に重なっていくモノ
    • 円自体も把握せず、どこまで重ねるかも議論せず合意形成をしようとしても難しい
• 自分の理解、自分自身の考えをどうやって把握すればいいのか？
  • 合意できる範囲がどこなのかを、他者に対して把握するのは難しいが、自分に対しても理解していないかもしれない
• 意見は点ではなく、範囲で考えるのが大事
  • 自分が合意できるものを点ではなく範囲で考える
  • プロジェクトのゴールも点で考えがちだが範囲で見なければいけない
  • 合意したい最低のポイントと、ここまで行きたい理想的なポイント、絶対に受け入れられない反対のポイント
• 発話することによって自分の考えを初めて認識する
  • 人の発言も当然そうで、発言しない意見はわかるはずもなく、逆に発言したことには説明責任を持つ
  • 発言したり書いたりすると自分の中身がわかってくる
  • オートクライン効果
• 口頭で読み上げるとロジックの破綻に気づく
  • 見たり読んだりだと気づかない
  • TOC(制約理論)が説明される書籍: ザ・ゴール２
  • 言語化することによって、客観的に見れる状態になる
    • 自分のものではなくなる
    • 自分で自分にツッコミを入れられる

人数と時間を制限する

• なぜ、参加人数を絞るべきなのか？
  • コミュニケーションのコストが高まり、精神的負担も高まる
    • 合意しづらくなる
  • 単純にミーティング時間を減らして業務の負担を下げないといけない
• 短時間で複数のミーティングを開催したほうが良い理由は何か？
  • 1時間1回より30分2回の方が良い
  • MTG間に何かあってもコミュニケーションが取りづらくなる(オンラインだと特に)
    • こまめに確認したほうが方向のズレなどを把握出来る
  • メンバーの関係性や、プロジェクトの緊急度によって頻度・時間を使い分ける
  • 「環境の変化が激しい」状況
    • 環境の認識が固定化されていないと非同期のコミュニケーションがやりにくい
    • 何か意見したくても、もう状況変わってるかも？と思って引っ込めてしまう
  • 環境が固定していない、変化しているとは具体的には？
    • 新しいメンバーが入ってお互いの仕事の仕方などが共有できていない
    • 緊急性の高いプロジェクト
      • 次のMTGまで待っていては状況が間に合わなくなったりする
  • MTGは参加者の環境を擬似的に固定する
• チャットでの書きづらさは、どこからやってくるのか？
  • リアルタイムに返事するという前提が無いから
  • デイリースクラムの時間を固定すればチャットでも

会議の準備

• 個人ワーク重要説
  • Amazonでやられてるやつ
  • 会議前にメモ(Notionなどの同期ツール)を黙って読む時間を設けて、コメントもそこで書き込む
    • コメント内でコミュニケーションが成立したりする
• ファシリテーターは何を準備するのか？なぜ準備しなければいけないのか？
  • 準備をしないと、MTGで得たいものが得られない
    • ラフな雑談をしたい場合は準備をしないで望むこともあるが、「そういう場」であるということを明示して共有するという準備が必要
  • 「準備する」ということが会議自体を想定することになる
    • 当日の生産性などが上がる
    • 準備をするということは事前に資料などを参加者に共有できる情報があるということなので
      • 参加者も準備できていて会議に参加し易い土壌ができる
• 最低限、何を事前に準備すればよいのか？
  • Doneの定義
    • 議論が終わったときに、どういう状態にしたいか
  • 発散のアジェンダなのか、収束のアジェンダなのか、共有のアジェンダなのか
    • ダブルダイアモンドより

会議中

• ミーティングで共有する時間をとるべきなのか？
  • 資料で共有すれば良くない？
  • 伝える内容や状況次第
    • 必要であれば積極的に入れる
    • 意図が伝わりにくい、疑問がたくさん出るのではないかという内容
  • 「絶対読んでくるというカルチャー」があるならいらない
  • 会議で共有する理由は
    • 誰かに次の行動を促すため
  • 共有によって会議の状況を固定化して、それを前提として会議でこれを議論しようとなる
    • getting on the same page
• 発散・収束・共有の順序性は？
  • プロジェクトの状態による
    • 会議がプロジェクトのどのタイミングでどの目的で行われているのか
    • 来週までに決めなきゃいけないなら絶対収束させなきゃいけない
  • 収束を仮説として設定したけど、いい感じに発散したならそれでも良い場合もある
  • 会議内ででた情報によって仮説が変わることもある
  • 発散まではMTGでやって、収束はリーダーがやるという場合もある
• 収束させるのが難しい問題に対して、ファシリテーターとしてどう振る舞うか？
  • その場でどの程度の合意が必要なのかを確認する
    • 全員の賛成が必要なのか、反対が無ければいいくらいなのか
  • 合意形成のレベル・ラインを確認する・下げる
    • 多数決で多そうなところで
    • プロジェクトリーダの決定で
    • 反対があれば言ってくれ、無ければ進めるよ
    • など
  • ep.66から"アイデアの決め方を事前に合意しておく"
    • 決め方の決め方を決めておく
• 「あれば言ってください」というのは難しい。どうやって対応するか？
  • Miroやチャットで「一人一個違和感を強制的に書かせる」
    • 無理やり出してもらってもこれくらいの違和感や反対意見なんだな、 進めても大丈夫だなと言う安心感を得る
  • しょうがない一個書くか
    • 「言う」ではなく「書く」
  • オンラインになって画面に注目してもらいやすくなった
    • オフラインではメモさせたりホワイトボードを見させるの面倒
    • 個人ワークや情報共有がしやすくなった
    • 会議で同じことを見させることの重要性
    • Zoomのブレイクアウトルームは使いやすい

議事録

• 議事録はどうやって作っていけばいいのか？
  • 会議中にみんなで取りきってしまう
    • MTGの後起こそうとすればするほど大変
  • 必要な程度の粒度で良いという前提を共有する
    • 全部残す必要は無いよね
    • 決定事項とTODOだけあれば良い場合もある
• 議事録をみんなで書くためのコツは？
  • みんなで取ることの意味を共有する
    • 一人で書いていると
      • 取り切れない
      • 理解が間違っている場合がある
  • アジェンダごとに小さく分けて取る人を決めてしまう
    • AさんがメインのアジェンダならBさんCさんで取ってね
    • 一人に負担を与えない

タグ

• 情報分解
• fukabori.fm