前回の記事では、背景・課題にファクトだけ書こうという話をしました。そうすることでロジックが組み立てられ、アクションの精度が高まるということを書きました。
ファクトを書くということは非常に大切ですが、それと同じぐらい大切なものとして「話したいことを減らす」という点があります。
この記事では、その大切さについて書きます。
論点を定める
このような背景・課題があったとします。
- 事業KPIを毎日Slackや定例で伝えている
- しかしながら、ほとんど閲覧されていない
- 事業あっての企業であり、KPIに興味を持たない状態を改善したい
アジェンダの作成者のAさんは非常に素直な方で、論点を以下にしました。
- KPIを毎日見てもらうためにどうすべきか
そして、この論点に基づいてアクションのたたき台を以下にしました。
- 提案① ひと目見て分かるダッシュボードの作成
- 提案② ランチ情報などの小ネタによる仕掛け作り
- 提案③ 他社事例ヒアリング
それぞれの提案についてPros/Consや費用などを交えて議論を促し、どれがよいか決めることになります。
そして、フェーズや会社によっても違うと思いますが、KPIが毎日閲覧されれば最低限クリア。事業に貢献できる人材や施策が出てきたら、さらにクリアとなると考えます。
複数を解決したいという思い
では、同時期に他社で同じ悩みを抱えていたBさんの事例を見てみましょう。
Bさんはすごく気が利き、複数の問題を同時に解決したい思いが強かったとします。
Bさんは今回の件について調査を行い、関連会社Xでも同じ事例を抱えていることを見つけました。また、同じKPIでも会社によって異なることも見つけました。
その結果、論点を以下のように整理しました。
- ① KPIを毎日見てもらうためにどうすべきか
- ② 全社分を閲覧できる統一ダッシュボードの検討
- ③ KPI定義の再検討
そして、以下のたたき台を作りました。
- 提案1 全社ヒアリング
- 提案2 定義修正
- 提案3 新定義に基づき統一ダッシュボード作成
話したいことがかなり増えました。
アウトプットが出るまでのスピードを重視
両者を比較した際、重要視しなければならないのは、アウトプットが出るスピードです。
プロダクト開発ではMVPとよく言われますが、変化の早い時代においては最小の労力で一刻も早くプロダクトを出す必要があります。
Aさんの場合自社を見ているので、スコープが小さいです。そのため、議論も具体にフォーカスしやすく、現実的な議論ができます。
Bさんの場合、全社や定義という視点を含めたため、スコープが広がっています。その結果、話すべき内容が増え、具体にフォーカスしきれません。
アクションを決めるMTGの場合、最後は収束させる必要があります。具体にフォーカスできないと、色々話したけど結局どうするんだっけというMTGになってしまいます。
Aさんのほうがアクションを推進し、アウトプットが出るまでのスピードは早いでしょう。その結果早くフィードバックループを回すことができます。
小さくまとまってしまうのではという反論
このような話をすると、複数の問題を同時に解決したほうがよい、大きなことを狙うべきだという人がいます。
今のままでは最終的に目指しているゴールにたどり着かない、そのようでは意味がないと捉えるようです。
もちろん問題は複数解決したほうがよいですし、ムーンショットとして大きなことを考えることは素晴らしいことだと思います。
ただ残念ながら多くの人間は複数の問題を同時に解決できません。また理想だけ大きくなり、現実的に進めることすらできません。
なので自分たちが一世一代の天才でない限り、小さく始めることをオススメします。
そして流れに乗ってきたタイミングで論点を増やしましょう。そうすれば複雑度は増えず、扱えるようになります。
終わりに
ここまで話したいことを減らし、アクションまでのスピードを早めようという話をしました。
もちろん、多くの問題を解決したい思いは素晴らしいものですし、多くの短時間で解決できえればそのほうがよいに越したことはありません。
ただ、MTGという限られた時間で最大の成果を出すためには、まず話したいことを減らしましょう。
そして、適切なタイミングで論点を増やせばよいでしょう。
MTGに慣れていないうちは話したいことを絞る。まずはこの点を心がけて、司会進行を頑張ってくださればと思います。ではでは。
コメント