最近、プロジェクトを開始・推進することが増え、ミーティングを開催・ファシリテーションすることが増えた。 その為、以下の資料を拝見しつつ、自分が気をつけていること、気付きとなった点などをメモする。
なお、自分用メモであり、詳細は上記参照。
ミーティング・ファシリテーション入門 / Introduction To Meeting And Facilitation
必要に応じて自分の状況などをメモしている
はじめに
- そもそもミーティングはハイコスト
- これにその通りだと思う
- 可能なものは非同期などで共有・依頼することが可能であるか、というのを考える
- 一方で、特にプロジェクトの開始段階でのゴールの共有やまだ細いことが決めきれていない場合に、ざっくりとした案やドキュメントを用意して、意見を聞いたり、FAQ の時間とするなどの場合にミーティングを自分の場合には設定させていただくことが多い気がする
ミーティング前
- ミーティング4タイプ
- アイディア創出、ブレインストーミング
- 合意形成(収束)
- 進捗確認会議
- 情報共有
- 自分の場合「合意形成(収束)」「進捗確認会議」が多い。前者は「A という方向性を考えているが、意見があれば伺いたい。その上で作業などを依頼したい」という感じのものが多い。後者については個別にタスクを依頼している状況で、「進捗の状況を確認したい。遅延があれば打開策を検討したい」というものが目的となることが多い気がする
- 「進捗確認会議」は必ずしも必要ないが、「進捗確認会議」があることで、対応者もその会議で状況を報告する義務が生まれるので、設定する場合もある。また、ミーティングなどの方が、特に困った報告などはしやすいように感じる
- 特に「進捗確認会議」はすべて順調であれば早めに終わってしまってもいいと思う
- 自分の場合「合意形成(収束)」「進捗確認会議」が多い。前者は「A という方向性を考えているが、意見があれば伺いたい。その上で作業などを依頼したい」という感じのものが多い。後者については個別にタスクを依頼している状況で、「進捗の状況を確認したい。遅延があれば打開策を検討したい」というものが目的となることが多い気がする
- 目的(どんな状態を作りたいのか)を言語化して伝える
- 明確にしないと当事者意識が薄れる
- 明確に伝えられていない場合があった気がする。ミーティングの Invitation にフォーマットとして入れると漏れがない気がする。また、ミーティング冒頭でも説明できるとより良いと思われる
- 誰を呼ぶべきか?参加させるべきは目指す状態達成に貢献できる人
- 「とりあえず関係しそうだから呼んでおくか」の吸引力がある
- 迷ったら呼ばない方がいい(あとでメモを共有しますね、など)
- 参加人数が多いほど、当事者意識が薄れる。逆に人が少なければ当事者意識を高くすることができる
- 「自分呼ばれなかったんだけど...」という対応をなくすための方向としては、迷った人にはミーティング後に議事録を共有する方法が考えられる。議事録を読んだ上で参加したい場合には声をかけていただく、など
- 「とりあえず関係しそうだから呼んでおくか」の吸引力がある
- 意思決定系では施策のオプション、それぞれの Pros/Cons、Fact となるデータを用意する
- 自分は Invitation に資料を記載するようにしている。内容によるが、完璧を目指さず、「議論できるレベル」の資料を作る場合が多い
- 事前に読んでいない方もいらっしゃるので、大体最初の時間で説明するようにしている。こちらで書いてあるように「黙読時間を5−10分設ける」というのもありだと思われる。機会があればやってみたい
ミーティング中
- チェックイン
- 少人数(2-4人)であれば「今の気持ち」などを30秒程度話してもらう
- 5人- であればチャットに書いてもらい、ファシリテーターが拾う
- ミーティングの背景・目的・アジェンダ・参加者への期待を話す
- 「参加者への期待」を伝えられていないことが多い気がするので、注意して言えるようにしておく
- 必要なら「A さん、顧客視点からのアイディア出しお願いします」と伝える
- ミーティングに参加しているものの、ディスカッションに参加できないてない人がいる場合、具体的に名前を挙げてみることで軽い緊張状態を作る
- ミーティング終盤では「いつまでに、だれが何をするのか」を明示的に振り返る
- 「2月上旬までにお願いします」というようなブレがあるような記載方法ではなく「2月5日までにお願いします」など認識にブレがないように明確化しておく
- チームに依頼する場合も「A チーム、お願いします」だと具体的に誰がアクションすればいいか明確ではないので、「A チームの B さんで一旦対応いただけますか or タスクのアサインお願いします」など明示的に「担当者」を決めるようにする
- ミーティング自体を振り返る
- 「開催頻度はこのままで良いでしょうか」など
- 特に定期ミーティングの場合、節目で上記について検討することが重要そう
ファシリテーション
- 一歩引いて/バルコニーに立って俯瞰して「今、この議論で目的に向かって進んでいるか」を観察し、必要に応じて介入していく
- 常に同期で話してしまうと、時間切れになる。非同期の個人ワーク時間をうまく使う
- ふせんに個人の考えを書く時間を3分取る、会議チャットに書いてもらう時間を2分とるなど。リモート会議ならオンラインで使えるふせんやドキュメント参照ツールを使う
- 同期的な議論の場合、特定の人が長く話すこともあるため、適宜ファシリテーターは発言を抑制したり、促したりする
- 例「A さんありがとうございます。まだ、B さんと C さんの意見を頂けてないので、一旦 B さんからお話ししてもらえるでしょうか」
- 問いが重要
- 自分の経験として「どう思いますか」という質問は回答しずらいような印象。回答が難しそうな場合、質問を変えてみることをしてみる場合もある。「仮に今の状況の場合、X というタスクをアサインされた場合、問題なくできそうでしょうか?」など
- 意思形成の方法
- 意思決定者が決める or 多数決 + アルファ、多数決、など
- リモートワークにおけるファシリテーションの方法論p59にもあるように何も決まらないという状況にならないために「強引に決めてしまう」というのも重要
- 例:「何かあったら対応するので、一旦これで進めさせてもらいます」、「A については、B さん、お願いします」など
リモートワークにおけるファシリテーションの方法論
ページ数が多いので「気になった」「良いな」と思う点をピックアップ 先ほどの資料と重複する部分などは適宜割愛
1.ファシリテーション概論
- 議論・意思決定する際の人数を絞る
- 意思決定の際には「全員賛成」を求めず、明確な反対がない限り、意思決定者の判断で合意するという割り切りも大事
- コミュニケーションを小分けにする
- 大きなテーマをまとめて議論せず、意思決定しない小さな単位に分けて、一つずつ結論を出す
- 例:「週1回1時間のミーティング」->「週2回。30分ごと。意思決定・確認事項のテーマをより明確にする」
- 大きなテーマをまとめて議論せず、意思決定しない小さな単位に分けて、一つずつ結論を出す
- 議論する前に、ドラフトを持ち寄る
- 議論の際には何かしらドラフト(たたき台)を用意する
- ドラフトがないと議論が空中戦になりやすく、議論の質・コストに大きく影響を与える
2.ミーティングのファシリテーション
- 粗くても良いので、アジェンダを言語化(可視化)してから会議を始める
- アジェンダタイトル(必ず定義したい項目)
- 種別
- ゴール(達成したい状態)(必ず定義したい項目)
- ゴール(成果物)
- 進行方向
- 目的・理由
- 何分(必ず定義したい項目)
- 誰から誰に
- 「⚪︎⚪︎について」というアジェンダは避ける
- 話し手が情報共有して終わり、聞き手が聞いた後にどんなアクションを求めているか不明
- 以下を詰めておくと良い
- あるべき姿・ゴール
- 完了の定義
- アウトプット
- アジェンダは次回会議までにいつでも・誰でも追加できるようにする
- 複数のアジェンダを混ぜないように気をつける
- 議論するテーマの「たたき台」を作る
- 質にはこだわらない。むしろこだわってはダメ
- たたき台作成者に感謝し、讃えよう
- MTG 以外の時間を活用
- 会議の冒頭で、その会議の「前提」を揃える
- ファシリテーター以外にも適切な役割を
- 「議事録作成」「タイムキーパー」は他の人に依頼するというのもあり
- 全てのことを一人でやる必要はない
- 議論を可視化する
- 認識ずれをなくす
- 振り返りや議事録として残すため
- 議事録で何を取るか
- 必須事項
- 決定事項
- TODO
- MTG に応じて取るもの
- 議論の詳細。ただし、メモ程度で OK
- 必須事項
- 議事録は1ファイルで会議の内容を継ぎ足していくと良い
- 新規ファイルの作成の手間をなくす
- 過去の議論を参照しやすい
- 未来日付にメモを残しやすい
- 会議終了時に「Next Action」と「次回 MTG のアジェンダ」を確認
- 会議後は「決定事項」と「Next Action」をすぐに共有し、見直せる状態を作ること
- 認識が間違っている可能性のある場合、その旨を追記して、メンバーに書くにする
- 決定事項、Next Action が曖昧の場合、仮案で良いので明確にして共有
3.プロジェクトのファシリテーション
- プロジェクトの立ち上げ
- プロジェクトのストーリー(ゴールとマイルストーン:ある一定の成果が見込める「あるべき姿」「期日」をもつ地点・状態）を描く
- 各メンバーが自律的にアクションできる粒度で記載する
- プロジェクトの設計図は仮説
- 粗いたたき台を許容する
- 常に更新できるようにしておく
- プロジェクトを進める上での前提や価値観を確認する
- プロジェクトが始まると、目の前のタスクに追われてしまい、本質的な視点を見失いことがある
- 下記の前提・価値観が共有できると良い
- なぜそのプロジェクトを行うかの Why
- クライアントからの期待
- 会社からの期待
- プロジェクトに対する個人の思いの共有
- プロジェクトを進める上で大切にしたい「価値観」
- このプロジェクトを通じて何を学びたいかの共有
- プロジェクトをリノベーション(再構築)する場としての会議
- 見直し観点
- 目的
- 開催頻度・時間
- 参加者
- 不必要に増えていないか
- 小さなアウトプットを随時共有しながらプロジェクトを推進しよう
- リモートワークはちょっとした状況共有がしにくい
- プロジェクトの定期的なふりかえりを通じた学習
- 定期的に振り返る
- 時間軸のふりかえりで共通認識
- 文章化を通じたふりかえり
