Retty Tech Blog

実名口コミグルメサービスRettyのエンジニアによるTech Blogです。プロダクト開発にまつわるナレッジをアウトプットして、世の中がHappyになっていくようなコンテンツを発信します。

RettyのPMが試行錯誤して見つけた会議ファシリテーション準備のポイント

この記事は Retty Advent Calendar 2020 5日目の記事です。

adventar.org

こんにちは。Rettyで飲食店向けプロダクトのプロダクトマネージャーを担当している神山です。

私の仕事は営業部署と開発部署を巻き込んで開発要件を決めていくような営業と開発の橋渡し的な役割で、直近はGo To EatのPJではビジネス側のプロダクトや業務支援システムのPMを担当しておりました。

今回の記事では、私のファシリテーション下手くそ時代の話から、試行錯誤の末に見えてきた重要なポイントをまとめてご紹介させていただきたいと思います。

こんな人に読んでほしい

・会議準備の方法を模索している方
ファシリテーションに課題を感じている方
・PJを円滑に進めたい方


結論:会議ファシリテーションで重要なこと

f:id:rettydev:20201201172317p:plain それぞれのポイントの詳細を説明していきます。

会議ファシリテーションで死亡する日々

今でこそ重要なポイントを紹介します、とか偉そうなこと言ってますが、実は1年くらい前まで会議が嫌いでした。

当時はとにかくファシリテーションが下手くそで、会議参加者の時間を奪う「時間泥棒」として社内に名を轟かせていたと思います。

例えば私が開催する会議では以下のようなことが起きているやばい状態でした。

  • なんでこの会議必要なの?って毎回聞かれる

  • 参加者の発言をほとんど理解できない

  • 会議の最後に何も決まっていない

上記のような状態なので、良い会議なわけないんですよね。

いつも最後に「一旦持ち帰ります、、、」と言って会議を締めることが続いていました。

ファシリテーターは、会議中参加者に議題を説明したり、参加者の意見を聞いて議事録書いたり、、同時に複数のことを処理しないといけません。

この複数のことを同時に処理する作業ってかなり難しく、当時の私は思考メモリの容量を超えて頭パンク状態になっていました。

一度頭パンク状態に陥ると、一切何も思考できません。ファシリテーター不在の会議になるので、一瞬で無法地帯と化します。やばいですよね?今振り返っても地獄のような会でした。 f:id:rettydev:20201205121636p:plain

どうやって「良い会議」ができるようになったのか?

会議前にどれだけファシリテーションのイメトレやロープレをやっても、会議が始まるとパンク状態になってしまいます。

そしてファシリテーションの場数が解決すると信じてましたが、場数をただ単にこなしても解決しませんでした。



試行錯誤した結果、この状態を回避するには会議の適切な事前準備をすることが重要でした。

少し具体的にいうと、会議前の段階で適切な準備を行い、ファシリテーション中に使う思考量を最小化することです。
この結論に到達するために参考になった本がこちら。内容もとてもわかりやすく、私はこの本に救われました、、、 www.amazon.co.jp


ファシリテーションの教科書」を参考に色々試していくうちに、会議前に考え抜いて適切な準備ができるようになると、会議中はファシリテーションに集中することができるようになってきました。

余裕が生まれて参加者の意見を理解できるようになったり、その場で話し合うべき論点について議論できる会議を作れるようになりました。

f:id:rettydev:20201201170958p:plain
適切な会議準備がもたらす好循環


そんな私が会議前にどんな準備をしているかについて、最も重要だと思う会議前に行うべき2つの準備を紹介したいと思います。

「良い会議」を作るための会議前準備

会議の準備には大きく2つの準備が必要です。これらを徹底的に考え抜いて準備できれば、かなりの確率で「良い会議」を作ることができると思います。

  1. 会議のスタート地点&ゴール設定

  2. 会議ゴールに到達するための論点設計

詳細を以下で説明していきたいと思います。

1.会議のスタート地点&ゴール設定

まず、会議のスタート地点とゴール設定です。
「いかに参加者の状態を想定することができるか」が鍵となっており、主に2つのステップがあります。

ステップ① 参加者の「状態」から会議のスタートとゴールの目処をつける

そもそも会議とは合意形成をする場です。本や講義で紹介されていることを自分なりの解釈を含めてまとめると、会議で扱う合意形成には大きく3種類あります。

f:id:rettydev:20201130174210p:plain
ファシリテーションの教科書」合意形成のステップを参考に筆者作成

会議では、1〜3まで全てが盛り込まれた会議もあれば、1〜2までを合意する会議もあります。

例えば、参加者が会議の内容について大方合意していて、あとは詳細なアクションプランだけ決めたいと思っている状態で「この問題の背景は〜」から話が始まると、そこはもういいよ!ってなります。

逆に参加者が会議で扱うテーマの必要性がわかっていない場合に、「どう解決するかアクションを決めましょう!」と言っても、いやいやそもそもそれ問題なの?みたいなことになります。私はよくここで躓いていました。

個人的によくある失敗ケースが、アクションの必要性が合意できていないのにアクションを決めようして、必要性の議論に逆戻りするケースです。

私がPMになりたての頃、とある営業活動を支援する社内システムをリニューアルしようとしました。
どうやってリニューアルするか?について会議を開きましたが、エンジニアさんから「そもそも何が問題なの?」「今やらなきゃいけない話なの?」と指摘を受け、必要性について準備をしていない私は議論を何も進めることができず会議を締めたことがありました。

これは参加者と必要性の合意ができていない典型的な例です。

なので、このような自体を防ぐためには参加者の状態を事前に想定し、どこから議論を始めてどこまで到達させるか?を明確にする必要があります。

ステップ② 到達したいゴールを「状態」で定義する

「状態で定義する」ってどういうこと?って思うかもしれないですが、会議で到達したいゴールは「状態」で定義するとより参加者同士でゴールイメージの認識が合いやすくなります。参加者の会議に対する安心感観点でこれは結構おすすめな手法です。

「〇〇について議論する」というゴール設定されても、それどうなったらゴール達成できるの?みたいな話になっちゃいますよね。

状態で設定したゴールとは例えば以下のようなものです。

・「◯◯◯要件について営業および開発の間で認識が揃っており、実現するための詳細仕様についてエンジニアに相談できる状態」
・「◯◯◯についてどこが問題になっていているのかを特定し、問題の原因について仮説を考えられる状態」
・「◯◯◯の問題を解決するための打ち手をタスクリストに洗い出し、営業と開発が合意した優先度に並び替えられている状態」


いかがでしょうか?「◯◯について議論をする」よりも会議が終わった後でどんな状態になっているかについてイメージしやすいと思います。

2.会議ゴールに到達するための論点設計

次に、論点の設計方法です。細かいことは端折りますが、「その会議で扱う必要のある論点をどれだけ精度高く準備することができるか」が鍵です。

本でも紹介されていた3つのステップを参考に必要な論点設計を行います。

ステップ① 論点の洗い出し

まずは、会議テーマに関わりそうな論点をとにかくたくさん洗い出します。

このステップでは、どの論点を会議で扱うか?は考えない方が良いです

例えば、もし私が弊社のネット予約システムに対して中長期的に課題があると感じていて、会議で問題提起するとします。このような状況だった場合、私はまず「必要性」「妥当性」「実現性」の観点で論点を以下のようなイメージで洗い出します。観点別に洗い出すと、明らかにするべき論点の網羅性が出て来ます。

「必要性」に関する論点例
・「ネット予約システムのあるべき姿は?」
・「ネット予約システムの現状は?」
・「解決した時のインパクトは?」
・「他の問題よりも優先するべき問題か?」
「妥当性」に関する論点例
・「解決するための方針案は?」
・「方針案の評価軸は?」
・「評価基準は?」
「実現性」に関する論点例
・「誰が責任者か?」
・「どんなスケジュールで進めていくか?」
・「どんな体制で解決していくべきか?」
ステップ② 論点の絞り込み

次に、会議で扱う論点を絞り込みます。

このステップで意識することは、なぜ会議で扱う論点として採用したのか?なぜ会議で扱わない論点としたのか?を明確にすることです。

例えば、スクラム開発のスプリント期間中にユーザーさんがネット予約できないbugが発覚したとします。他の施策の優先度を下げてまで差し込みで対応する必要があるのか?についてマネージャー陣で話し合うとした場合、会議のゴールは「必要性の合意」までとなりそうです。

必要性が合意できれば、あとは別途現場メンバーでどのようなう方法で解決していくのか?(妥当性の話)や、具体的にいつまでに誰が進めていくのか?(実現性の話)をすれば良いことになりますので、これらはマネージャー陣との会議では扱わない論点となります。

f:id:rettydev:20201202130306p:plain
この作業を行うことで、実際の会議で扱わないとした論点について参加者から指摘があっても、「その論点は◯◯の理由で今回の議題から外させてもらっています。重要な論点なので次の◯◯の機会で扱ってもよろしいですか?」といった感じの返答ができ、参加者も納得感を持つことができます。

一度論点を洗い出し、会議で扱うかどうかを検討しておくことでこのような効用があります。

ステップ③ 論点を扱う順番を決める

最後に、論点を扱う順番を決める必要があります。Bの論点の結論を出すために、Aの論点の結論を出しておく必要があるケースってありますよね?

例えば、bugが起きている箇所が特定できていないのにbugの原因の話はできません。実装方法が決まっていないのに具体的なリリーススケジュールは決めることができません。

「どの論点から扱うか」まで考え抜くことで適切な議論が実現できます。参加者の納得度と安心感はかなり高まるはずです。

まとめ

私が良い会議が作れなかった原因は「会議中のファシリテーション力」ではなく、「会議前の準備力」でした。

適切な準備ができれば80点くらいの会議ができそうな印象ですが、残りの20点は会議中の議論(論点)の「さばき方」によるものだとも感じています。 今後はさらに議論を深められるように会議中のさばき方を磨いていきたいと思います!!