会議設計の勘所 - 行動が変わらない会議の話

会議が終わった。結論らしきものも出た。しかし「で？何をすればいいんだっけ」となることはないだろうか。
そうした会議に足りないもの、会議を設計する際に考えておくべきことをLTで簡単に発表。

Transcript

1. 会議設計の勘所 ― 行動が変わらない会議の話 北島翔貴 | Connehito Inc.
2. こんな経験、ありませんか？ 会議が終わった。 ゴールも達成された。 でも… 「で、私は何をすればいいんだっけ？」 ゴールは達成されたのに「で？」が残る。 この違和感の正体は何か。
3. 例：プロダクト方向性会議にて 結論：「今期はユーザー獲得にフォーカスする」 全員が納得して解散。しかし翌日 … PM KPIを変えるべき？何を捨てるか決まっていない エンジニア どの施策から着手すればいいか分からない CS 既存ユーザー対応の優先度は下がるのか？ 営業 判断軸が変わったのか不明。今まで通り動く 結論は出た。でも「何を捨てるか」と「なぜそう判断したか」が共有されていない。
4. 原因：会議のゴールが「結論」になっている よくある会議設計 1. アジェンダを決める 2. 議論する 3. 結論を出す 4. ??? 行動変容を設計する 1. 誰の行動が変わるか決める 2. 必要な結論の形を逆算する 3. 議論し、結論を出す 4. 各自が動き始める 結論はゴールではなく、行動変容のための手段
5. 会議のゴールは 「結論」ではなく 「参加者の行動が変わること」 会議の前と後で、誰の行動がどう変わるか？ それを最初に設計する。
6. 結論の「フォーマット」を事前に決める 会議の結論に必ず含めるべき 3つの要素 01 何をやるか、そして何を捨てるか 「ユーザー獲得にフォーカスする」だけでは不十分。 それに伴い何の優先度を下げるのかまで決める。 捨てるものが明示されて初めて、全員が判断できる。 02 なぜそう判断したか どのデータや仮説に基づいた判断なのかを共有する。 根拠がないと各自が自分の仕事に翻訳できない。 過程の共有が、自律的な行動を生む。 03 各ロールのネクストアクション 結論から各自の行動への変換テーブルを設計する。 PMはこう動く、エンジニアはこう動く。 この変換まで含めて「結論」とする。
7. 改善例：同じ会議をこう設計する 結論フォーマット： 「ユーザー獲得にフォーカスする。 既存ユーザー向け機能開発は今期凍結する。 理由：DAU成長率が3ヶ月連続で鈍化、 LTV改善より母数拡大を優先」 各ロールのネクストアクション PM 獲得チャネル別KPIを今週中に再設計 エンジニア LP改善・招待機能の工数見積もりを開始 CS 既存ユーザーへの影響範囲を整理し共有 営業 新規獲得に効く顧客セグメントをリスト化
8. 注意：人間は結論を出したがる 「結局こうだよね」 この一言は危険。結論が同じでも、そこに至った論理や思考が共有されなけれ ば、チームの認識はバラバラのまま。 結論だけの共有は、行動変容につながらない。 結論だけ共有 → 論理が積み上がらない → 誤った解釈で伝播する 過程も共有 → 判断基準が揃う → 各自が自律的に動ける
9. ただし、結論は予測できない 事前に結論を決められるなら、会議ではなく命令をすればいい。 会議で何かを決める以上、どんな着地点に辿り着くかはわからない。 だからこそ、 「どんな結論が出ても、全員が動き出せる形で着地させる」 という設計が必要になる。 不確実性に向き合う思考と設計が、会議にも求められる
10. 明日から一つだけ変えるなら 次の会議を設計するとき、こう問いかける： 「この会議の後、 誰の行動がどう変わるか？」 会議のゴールを「結論」から「行動変容」へ。 それだけで「で？」はなくなる。