こんにちは、Misoca開発チームの黒曜(@kokuyouwind)です。
ついにECS execできるようになったことに咽び泣いていますが、今日の記事は全然関係ない話です。
社内向けに「どうすれば質の高いミーティングを作れるか」を検討した読み物記事を書いていたのですが、社外に出しても問題ない内容だったので開発者ブログに載せることになりました。
割と社内では評判が良かったので、参考になる部分があれば幸いです。
目次
はじめに
複数人で何かをしようとしたり、何かを決めようとしたとき、あるいは認識を揃えようとしたとき、業務では様々なタイミングで「ミーティング」が必要になります。
しかしながら、ミーティングというのは「無駄な仕事」と感じられることも多く、また正しくミーティングを実施しないと「1時間かけて、得られたのは参加者の徒労感だけ」ということになってしまうこともあります。
本記事では筆者の考える「よいミーティング」の作り方を、いくつかの観点からまとめたものです。
もちろん「このやり方が正しい！」と主張するものではありませんが、一つの参考としていただければ幸いです。
要点
長くなってしまったので、最初に要点だけをまとめます。
各節にはより細かい話や具体例などを書いていますので、興味のある題材の節をご参照ください。
- 良いミーティングとは
- 「短時間・少人数」で、「ミーティングの目的をよりよく達成する」もの
- この2つはある程度トレードオフの関係にあるが、工夫して「効率の良いミーティング」にすることで両方を高める事ができる
- ミーティングの準備
- ミーティングの目的を明確にする。参加者全員に誤解なく伝わる端的な名前をつける
- ミーティングの参加者を決める。必要十分なメンバーを選ぶ
- ミーティングの前提情報を洗い出し、参加者に共有する。議論の前提となる知識が何であるかをはっきりさせる
- ミーティングの進行方法を選び、時間を見積もる。簡単なこと・前提となるものを前に、難しいこと・時間のかかることを後にする
- ミーティングの実施
- ファシリテーターは「ミーティングの目的」を達成するため、参加者の意見を引き出し整理させる。適切なタイミングで落とし所が見つけられるよう誘導する
- タイムキーバーは「時間内でのミーティング」を達成するため、進行の区切り時刻を通知する
- 参加者は「ミーティングの目的」を達成するため、各々の観点から意見を出し議論を進展させる。他の参加者やファシリテーターが「敵」ではなく「同じ目的を達成するための別ロール」であることを認識し、互いを尊重しながら協力して議論を行う
- ミーティングの後
- 議事録を作り、知るべき関係者に周知する
- 次のアクションがあった場合、それが適切に実施されるようにする
よいミーティングとは
ミーティングとは
そもそも、ミーティングとは何でしょうか。
辞書で「ミーティング」という語を調べると、「比較的少人数の集会。会合。」といった定義が出てきます。
これに間違いはありませんが、業務において使われる「ミーティング」はもう少し狭い範囲のものを指しているような気がします。
Misocaチームでは複数の定期ミーティングを開催しています。
これらはそれぞれ、何らかの 目的 を持って、参加者の時間を使っているものです。
こうしてみると、少なくともMisocaチームにおいては「何らかの目的を達成するために参加者が集まる場」をミーティングと呼んでいる、といえそうです。
おそらく、一般的な会社でもこういった意味合いで使われることが多いのではないでしょうか。
よいミーティングの条件
例えば、Misocaチームで毎週行っている「開発チームふりかえり結果共有」というミーティングであれば、目的は以下のように書かれています。
Misocaで動いてるプロジェクトは定期的にふりかえりを行っている。
開発チームが関わるプロジェクトで得られた知見や経験を、開発チーム全体で共有して他のプロジェクトへ展開する。
つまり、このミーティングを経て「開発チームがかかわるプロジェクトで得られた知見や経験が、他のプロジェクトへ展開されている(業務でその知見や経験が生かされる)」ことが期待されています。
目的を持って開催されている以上、 ミーティングの目的が達成されている のはよいミーティングの条件として適切でしょう。
ところで、同じことを決めるのに、一方のミーティングでは2時間かかっていたのに、他方のミーティングでは30分で終わったとしましょう。
この場合、30分で終わった参加者は残りの1時間半を自由に使うことができることになります。
あるいは、同じことを決めるのに、一方のミーティングでは10人で話しており、もう一方のミーティングではそのうち5人で話していたとしましょう。
この場合、前者では全員が会議しかできなかったのに対し、後者では5人が別の作業を自由に行うことができます。
こうしてみると、複数人の時間を使うものである以上、目的が達成されるのであれば より短時間・少人数で終わる というのも大事な観点だと言えそうです。
ただし後者の「少人数」については、参加しなかったメンバーへの情報共有や、そのメンバーの意見抽出が行われないことに注意が必要です。
目的の達成度
注意が必要なのは、目的の達成は「できたか、できなかったか」だけではなく、「どの程度よく達成できたか」という曖昧さがあることです。
先の「開発チームふりかえり結果共有」でいえば、「開発チームがかかわるプロジェクトで得られた知見や経験が、他のプロジェクトへ展開されている(業務でその知見や経験が生かされる)」というのには、少し考えるだけでも以下のような結果がありえます。
- どのメンバーも、互いのプロジェクトで得られた知見を「各自が体感した」レベルで細部まで完全に把握した
- どのメンバーも、互いのプロジェクトでどのような知見が得られたか一切わからなかった
- どのメンバーも、プロジェクトXでの知見は完全に把握したが、プロジェクトYでの知見は一切わからなかった
- メンバーAは各プロジェクトでの知見を完全に把握したが、メンバーBはどのプロジェクトの知見も一切わからなかった
- どのメンバーも、互いのプロジェクトで得られた知見を大まかに把握したが細部まではわからなかった
- メンバーAはプロジェクトXの知見が完全に、プロジェクトYの知見は大まかにわかった。メンバーBはプロジェクトXの知見が大まかに、プロジェクトYの知見がほんの少しわかった
これだけでも、「誰が」「何を」「どれだけ」理解したか、と3種類の尺度が登場しています。
情報共有以外でも、例えばブレインストーミングであれば「どれだけ多くの意見が出たか」「どのくらい多方面からの意見が出ているか」「重要な意見をどれだけ掘り下げられたか」など、決議であれば「各参加者がどれだけ背景を理解したか」「考慮漏れの検討などがどれだけ正確に行えたか」「参加者のうちどれくらいが納得できる結論をだせたか」など、様々な観点から「達成度」を考えることができるでしょう。
もちろん、可能な限り目的を100%達成するのが望ましいのは言うまでもありません。
しかしながら、目的を完全に達成するのが時間の制約上難しかったり、そもそも現実的に不可能である、ということもありえます。
達成度と時間のバランス
別の例として、以下の3つのミーティングを考えてみましょう。
- 10分で目的の5割を達成できたミーティングA
- 30分で目的の8割を達成できたミーティングB
- 2時間で目的の99%を達成したミーティングC
この3つのミーティングでは、どれが一番良いミーティングだと言えるでしょうか？
極論は「目的による」といえますが、筆者の個人的な感覚では以下のようになります。
- 情報共有が目的であれば、短時間で大枠のみ目的を達成したミーティングAが優れている
- 何らかの議論やブレインストーミングが目的であれば、議論の大半を終わらせることができるミーティングBが優れている
- 大きな決定を下すのであれば、ほぼ完全に目的を達成できるミーティングCが優れている
「目的を達成すれば良い」「時間が短ければ良い」のは確かですが、実際には上記のようなトレードオフの関係になることが多いでしょう。
このため、ミーティングを実施するときには目的に応じて適切な達成度が得られるよう開催時間を調整する必要があります。
効率の良いミーティング
達成度と時間のバランスを踏まえた上で、より良いミーティングにするためにできることはないでしょうか。
ひとつの考え方として、「より密度の高いミーティングを行う」ということが考えられます。
すなわち、「同じ時間でより高い達成度を得られるよう工夫する」のです。
みんなが知っていることの確認に時間をかけすぎていないでしょうか？
参加者が議論に集中できる説明の流れになっているでしょうか？
ミーティングの目的と関係のない議論に時間をかけていないでしょうか？
こうした点に注意することで、短い時間で目的をより達成する 効率の良いミーティング にすることができるかもしれません。
ミーティングの準備
ミーティングを行う際は、以下のことを事前に行うのが望ましいでしょう。
- ミーティングの目的とゴールを明確にする
- ミーティングの参加者を決める
- ミーティングの前提情報が何かを洗い出し、参加者に共有する
- 目的達成のために必要なミーティングの進行方法を検討し、必要な時間を見積もる
ミーティングの目的とゴールを明確にする
ミーティングを開催する以上、そこにはなんらかの「目的」があるはずです。
よくあるのは以下のようなものでしょう。
- 一人では決定できない事柄について、複数人で協議して決めたい
- ある事柄について、いろいろな意見を集めて掘り下げたい
- ある情報を参加者全員に周知したい
- 複数人の親睦を深めたい
これらが入り混じったミーティングもありえますが、その場合でも 主たる目的を明確にする ほうが望ましいでしょう。
そうすることで、「最低限何を達成しなければいけないか」という優先度づけがしやすくなります。
目的を明確にして人に伝えるためには、言葉で表現する必要があります。
「会議の目的」を、端的な1~3文程度でまとめましょう。
「何をしたいか」「なぜミーティングをする必要があるのか」「何が足りないのか」などを明確にしましょう。
読んだ人が「なるほど、確かにこのためにはミーティングが必要だ」と思うようにしましょう。
また、それにあわせて「会議名」をつけましょう。
目的の中から重要な語を拾い上げ、目的がイメージしやすいようにしましょう。
文字数が限られるため、文字数が少なくなるよう言い換えたほうが伝わりやすくなるかもしれません。
さらに、「会議のゴール」も端的な1~3文程度でまとめるとよりよいでしょう。
ミーティングを経て「何が得られていればよいか」「どうなっていればよいか」を明確にしましょう。
「ゴールを達成したとき」のイメージができるようにしましょう。
これらは誰でも見られるよう、カレンダー予定の会議名と詳細に書いておくと良いでしょう。
例えば、「この記事を全体に共有するミーティング」であれば以下のようになるでしょう。
会議名: 「よいミーティングの作り方」の読み合わせ
目的:
ミーティングを効率よく進行するための自分の考えについて、「よいミーティングの作り方」という記事をまとめました。
この内容を展開して今後のミーティングの質を高めるため、読み合わせによって全員に確認していただきたいです。
また時間があれば、これを各ミーティングで意識できるようにプロセスへの組み込みなどができないかを議論したいです。
ゴール:
メンバー全員が記事に書かれた内容を理解し、各ミーティングの前提事項として共有された状態にする
この例では、目的を「背景」「主目的」「副目的」の3文で構成しています。
このうち、「背景」と「主目的」で なぜ ミーティングが必要なのかを、「主目的」と「副目的」で 何をしたいかを明示しています。
- なぜ: 新しく作った記事が重要な内容なので、全員に確認してもらいたい
- 何をしたいか: 記事の読み合わせと、プロセスへの組み込みに関する議論
記事の読みあわせが主目的なので、会議名はそれが明確なようにします。
一方で、ゴールについては「記事の内容を確認する」だけではなく「それを会議に活かす」ほうがより達成度が高いので、それを含めた1文にまとめています。
以下は、よりよい目的設定をするための検証観点です。
- 目的は端的な表現になっているでしょうか？ 誰が読んでも誤解なく伝わるでしょうか？
- 会議名から目的を想像できるでしょうか？
- 目的とゴールは正しく繋がっているでしょうか？ そのゴールを満たすことで、目的は達成されているでしょうか？
- 専門的な用語が使われていないでしょうか？ 誰が読んでもその内容を理解できるでしょうか？ 平易な言い換えはないでしょうか？
- 参加者一人を具体的にイメージして、その人が目的やゴールを正しく認識できそうでしょうか？
ミーティングの参加者を決める
目的とゴールが定まったら、ゴールを達成するのに必要なメンバーを列挙します。
情報周知であれば、周知したい対象全員に参加してもらうだけでよいでしょう。
ただし、大人数になるほど「本当にミーティングが必要か」や「事前の情報共有で時間を短縮できないか」をより吟味して開催する必要があります。
議論や決議が目的の場合、参加者はよく吟味する必要があります。
人数が少なすぎると十分な意見の吸い上げができませんが、多すぎると議論が発散してしまったり発言する時間が取れず、参加する意味のない参加者が発生しやすくなるからです。
以下は、適切な参加者を洗い出すための検証観点です。
- 目的に含まれる題材について、担当していたり作業をしているメンバーはいないでしょうか？
- ゴールを達成する上で、参加者に不足しているロールはないでしょうか？
- 意思決定が目的であれば、意思決定を行える人はいるでしょうか？
- 議論が目的であれば、多方面からの意見が出るようなメンバーになっているでしょうか？
- 重複するロールの人はいないでしょうか？ いずれか一名にした場合、どのような影響があるでしょうか？
- 影響が少ないのであれば、いずれか一名にしたほうが効率が良い可能性があります
ミーティングの前提情報を洗い出す
ある事柄を議論するためには、その事柄のことを十分に知っておく必要があります。
議論のために何を知っていればいいかを検討し、参加者が確認できるようにしましょう。
おおむね全員が理解しているのであれば、情報へのリンクなどを張るだけでよいでしょう。
もし前提情報を把握しきっていない参加者がいるようであれば、事前に目を通すようにお願いしたり、ミーティングの最初に前提確認の時間を長く取ると良いでしょう。
情報共有を目的とするミーティングでも、前提が揃っているかは重要です。
また情報共有は「その情報についての質疑応答による掘り下げ」を副目的とすることが多いため、主目的の資料を事前に共有しておくのはよいプラクティスです。
すべてのメンバーが目を通すとは限りませんが、「参加者全員に一定以上理解してもらう」上で「事前に読んだメンバーはより高いレベルで理解し、質問事項を予め検討することで深いレベルの掘り下げを行うことができる」というのは十分な効果でしょう。
ミーティングの進行方法を決める
最後に、ミーティングの進め方と時間配分を検討します。
典型的な流れは以下のとおりです。
- 議論であれば「前提の確認」→「議題の確認」→「意見の吸い上げ」→「個別意見の掘り下げ」→「得られた知見の整理」
- 決議であれば「前提の確認」→「議題の確認」→「質疑応答」→「決議」
- 情報共有であれば「前提の確認」→「情報共有」→「質疑応答」
ただし、目的や題材に応じて変わる部分も多いでしょう。前提確認は必要ないこともあれば、長めに取る必要があることもあります。
重要なのは以下の2点です。
- 参加者が自然に参加できるか
- その流れでゴールにたどり着けるか
いかなる時でも、前提の確認はミーティングの最初にあるべきでしょう。
また参加者が意見を出しやすいよう、理解しやすい流れで進行するべきです。
一方で、時間が足らなくなってしまったり、そもそもゴールとは全く違う方向へ進んでしまっては本末転倒です。
このため、極力「時間のかからないこと」を先に済ませ、「主目的」をその次に置き、「時間のかかること」や「副目的」は最後になるようにするのが望ましいです。
とはいえ主目的やその前提となる議論に時間がかかることも多いので、このあたりはケースバイケースとなります。
進行が決まったら、それぞれのステップの時間目安を添えて、参加者全員が見られるようにまとめておきましょう。
ミーティングの実施
ミーティングでは目的を達成するために、以下のようなロールが協力して進行します。
以下の役割は、議論に主眼を置いたミーティングについて記述しています。
決議や情報共有を目的としたミーティングでも各々の役割は変わりませんが、自由な発言の余地が少ないためそこまで意識しなくても問題なく進行することがほとんどです。
ファシリテーターの役割
ファシリテーターの役割は「議論を促進し、ミーティングの目的を達成できるように参加者を導く」ことです。
参加者から意見を引き出し活発な議論になるようにしつつ、議論が収束するよう交通整理を行います。
- 議題について、参加者が平等に発言できるよう配慮して意見を求めましょう
- 発言の少ない人には「◯◯さんはどうでしょう？」などという形で意見を求めましょう
- 話の長すぎる人がいる場合は、適度な長さで中断してもらうよう促しましょう
- 人の話を遮ってしまう人には、議論のルールを守ってもらうよう注意しましょう
- 議論が発散してきた場合はそれまでに出た意見を整理し、議論の焦点を確認しましょう
- 議論がミーティングの目的から逸れてきた場合は、目的を再度周知しましょう
- 時間内に結論が出るよう、参加者を促しましょう
- 「残り10分ですが、どうしましょうか」「直近で行うアクションはありますか？」など、極力オープンクエスチョンの形で参加者の発言を促しましょう
- 議論が発散している場合、それまでの議論を整理して採りうる選択肢を列挙したうえで、参加者の意見を募っても良いでしょう
- 意見が大きく対立している場合、双方の譲歩できるポイントを確認してみましょう
ファシリテーター自身が意見を出したりミーティングの結論をまとめるのではなく、「参加者が意見を出して結論を出すのをサポートする」役割である、ということが重要です。
ファシリテーターの詳しい役割やポイントについては「会議ファシリテーション」の基本がイチから身につく本などが参考になるでしょう。
タイムキーパーの役割
タイムキーパーの役割は「ミーティングの目安となる時間を参加者に周知する」ことです。
名前と反し、「ミーティングの時間を守る」のは参加者全員の責任であるため、時間を守らせることはタイムキーパーの責務ではありません。
ミーティングの進行予定を元に、議題ごとの予定時刻が近づいていることを知らせます。予定時刻の何分前に伝えるかはミーティング開始時に確認するか、チーム全体で目安を決めておくと良いでしょう。
なお筆者個人の目安として、「10分の議論なら2分前」「30分の議論なら5分前」など議論時間の1/5 ~ 1/6程度を残したタイミングで時刻を知らせるようにしています。
このくらいの残時間ならば「もうまとめに入らないと終わらないな」という意識になりやすく、なおかつそれまでの議論をまとめられる程度の余裕時間があるように感じます。
タイムキーパーが時刻を伝える際、できれば呼び出しベルのようなものを用意しておくと良いでしょう。
口頭で「◯分前です」と伝えても良いのですが、誰かが話している最中だと気後れしてしまうこともありますし、声が交じると聞き取りづらくなってしまいます。
ベルの機械的な音であればボタンを押すだけなので気後れせず押しやすいですし、話を遮ることもなくなります。
参加者の役割
参加者の役割は「ミーティングの時間内にミーティングのゴールを達成すること」です。
議論であれば自分の意見を積極的に出し、他者の意見を吟味し、全員が納得できる結論を得られるように協調します。
情報共有であれば受け取った情報を確認し、疑問点があれば質疑応答の時間内で許される限り確認します。
重要なポイントは「時間を守ったりゴール達成を目指すのは参加者全員の責任」というところでしょう。
とくに議論を目的とするミーティングでは、しばしば議論が横道に逸れてしまったり、意見が対立してしまうことも起こります。
こういった場合でも、「議題以外の話を取り下げ、議論を収束させること」「お互いの意見をすり合わせ、落とし所となる結論を見つける」といった振る舞いが参加者全員に求められます。
もちろん意図せず話がそれてしまった場合などはファシリテーターや周囲の参加者からも働きかけるべきですが、少なくとも「自分がミーティングの目的達成に協力する」という意識は全員が持っておくべきでしょう。
これが抜け落ちると、本来の議題とはかけ離れた話で時間を使い切ってしまったり、互いの意見を主張し合うだけで落とし所が見つけられなかったり、といったことが起こることになります。
ミーティングの後
議事録をまとめる
ミーティングで決まったことや話したことは議事録にまとめ、関係者に周知します。
個人情報や情報機密などの問題がない限り、全ての議事録は極力チームメンバー全員が見られるようにしましょう。
情報をオープンにしておくことで、関係者以外からのフィードバックも得やすくなり、場合によっては新たな関係者が見つかることにも繋がります。
議事録の形式はミーティングの内容に応じて調整するべきですが、「ミーティングの結論」「直近のアクションと担当者」「ミーティング中の議論の流れ」といった形で重要な情報を先にしておくと、読み手が概要を掴んだ上で必要に応じて詳細を追うことができるようになります。
議事録は可能であればミーティング中に並行してまとめ、ミーティング最後に全員で「ミーティングの結論」「直近のアクションと担当者」を合意すると効率が良いです。
とはいえ話しながら議事録を取るのは慣れないと難しいため、重要な情報のみミーティング内にまとめて合意をとった上で、議論の大まかな流れなどは後追いでまとめても良いでしょう。
なお、音声録音からの文字起こしは補佐的に利用しても良いものの、全文を読まないと結論やそれに至る流れが掴めないという点で読者に不親切になります。
後追いで議事録を作る際の参考情報としては有用なため、そういった用途で使うのがおすすめです。
「次のアクション」を実施する
議論の結果なんらかのアクションを起こすことになった場合、それが適切に実行されるようにしましょう。
チームのタスクになるのであれば、そのチームのタスクボードで管理するため理想的です。
一方で個人のタスクになってしまうと、その個人がうっかり忘れてしまった場合にアクションが止まったままになってしまいます。
「共通のタスクボードにアクションの置き場所を作る」「アクションの関係者が定期的に確認する」など、チームとして放置されたアクションを作らない仕組みが構築できるとよいでしょう。
まとめ
ミーティングは油断すると大人数の時間と気力を奪うだけに終わってしまいますが、うまく実施できれば短時間で多くの人の意見を反映した素晴らしい結論を得ることもできます。
この記事が「よいミーティング」を開催する一助になれば幸いです。
参考リンク
Misoca開発者ブログでは他にもミーティングに関する記事がいくつか投稿されていますので、そちらもぜひご覧ください。
tech.misoca.jp
tech.misoca.jp
またミーティングのための資料準備については、質の高い技術文書を書く方法が非常に参考になると思います。
blog.riywo.com
宣伝
弥生株式会社ではよいミーティングをしたいエンジニアを募集しています！
www.yayoi-kk.co.jp
id:mizukmb です。
