217
154

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

ミーティングにはサプライズを持ち込まない

Posted at

ミーティングの技術について色々な書籍・記事が出ていますが1、これらを抽象化していくと、

「ミーティングにはサプライズを持ち込まない」

という結論になりました。

もしかしたら具体的なハウツーよりもこういった観点をひとつ持っておけば上手くいきやすいかもなと思い、エントリにまとめてみます。

ミーティングにおけるサプライズ4選

「サプライズ」と聞くと、誕生日パーティーやフラッシュモブなど、ポジティブな楽しいイメージがあります。

しかしミーティングにおいてはサプライズは不要である、というのが本エントリの主張です。

まずはサプライズの具体例を、参加者の立場になっていくつか考えてみましょう。

こんなことを話すの?

Aさんは「〜システムの開発について話したい」というミーティングに呼ばれました。「このシステムについてAさんが詳しいと聞いたので、実装について教えてほしい」という内容でした。

そのシステムの開発を担当したのは数年前であり、すぐには思い出せなかったので、過去に準備していたドキュメントを読み返したり、とくに設計の複雑な機能のコードを読み直したりしてからミーティングにのぞみました。

しかしいざミーティングが始まってみると、その機能の実装に使われているプログラミング言語について知りたかったことがわかりました。

聞かれた質問には一通り答えることはできましたが、とくに機能に関する話題はあがらず、そのミーティングは終わりました。

本当に終わるの?

Aさんがプロジェクトの定例ミーティングに参加すると、議事録にアジェンダがズラーっと並んでいます。このミーティングは30分間であり、1つの議題を5分で消化したとしても、まだ半分程度議題が残りそうです。

案の定ミーティングですべての議題は消化できず、何名かは次の予定のため退室。とはいえ議題は消化されていないので、その場にいるメンバーでなんとか話し合いを続けました。

しかし退室済のメンバーの意向も聞いたほうがよいという意見が出て、意思決定まではできず。結局翌週の定例ミーティングに持ち越されることになりました。

結論は出ないの?

「新規開発を優先すべきかリファクタリングを優先すべきか」を相談するミーティングが開かれました。

どちらを優先すべきかは難しい問題です。そのなかでAさんは「新規開発をまずやるべきだ」と思い、理由とともに主張をしました。

一方でBさんは「リファクタリングを今やらないといけない」ことを説明しています。その主張も一利あるため、Aさんはどちらに決まってもよいかもと感じました。

ミーティングはとても盛り上がりましたが、終わりの時間が訪れたため、突如お開きに。メンバーの意見はわかりましたが、結局どちらを優先すべきかはまとまりませんでした。次回のミーティングが開かれるのかはわかりません。

自分がいる意味あるの?

ある機能に関してコンサルから質問がたくさんあるようで、それを解決するためののミーティングが開かれました。

Aさんのほか関係する開発メンバー全員が呼ばれ参加してみると、その質問は基礎的な内容で、最近入社したCさんでも十分に答えられるものでした。

「難しい質問もあるのかも」と思って待っていましたが、結局ほぼすべての質問が簡単であり、開発者全員が出席すべきものだったのかは疑問が残ったままでした。

サプライズを減らして、「イメージ通り」にする

「想像とは違う」サプライズの発生するミーティングを描いてみました。

それぞれの事例は誇張されていますが、似たような経験は皆さんもあるのではないかと思います。

それでは次に「このようなミーティングを回避するにはどうすればよいか」という観点で考えてみましょう。

さて、サプライズの誕生日パーティーを思い返してみると、「サプライズが相手にバレている」というのは大きな失敗例のひとつです。

しかしこの失敗は、ミーティングにおいては成功の一因となります。「サプライズが相手にバレている」つまりイメージ通りになるよう設計してみるのはどうでしょう。

ミーティングの終わりをあらかじめイメージする

イメージ通りにするには、最低でもミーティングの主催者がまずミーティングのイメージをもつ必要があります。

ミーティングには誰が参加するか。とくに誰の参加が重要であるか。ミーティングの話題はなにか。そういったことの整理が必須です。

とくにミーティングの「終わり方」のイメージは、殊に重要だと感じます。

あるテーマに対して決断したいのか。もしくは、ある情報を参加者全員に理解してほしいのか。

意思決定の場合は、その選択肢もイメージしてみます。「ほぼ絶対にこの結論になる」という場合もあれば、「どちらかの選択肢になるけど、かなり迷うだろう」という場合もあります。「決まらないときはどうするのか?」というイメージもしておきたいところです。

またときおり「ゴールのイメージは持てないのだけれど、とにかく話してみたい」という場合もあるでしょう。そのような「イメージがつかない」というのもイメージの一つだと私は考えます。

イメージは参加者にも共有されているか

つぎにそのイメージを参加者も共有できているかを想像してみます。

参加者はたいてい異なるバックグラウンドを持って参加します。全員がイメージできている必要はあるでしょうか。必要性が高いなら、ミーティングの事前準備として資料を準備したり、事前に情報共有をすべきかもしれません。

意思決定の場合、あらかじめ選択肢を伝えておくのはどうでしょう。参加者もそれぞれイメージを膨らませてから参加できますし、自身が検討していなかった新しい選択肢が事前に出るかもしれません。

繰り返しになりますが、ミーティングにサプライズを用意するメリットはありません。参加者がイメージできなそうな箇所があれば、それは事前に伝えたり、最低でもミーティングの開始時点で解消しておくと良いと感じます。

イメージ通りのミーティングを爆速にする方法はあるか

ここまでできたら、最後はミーティングの効率化を考えます。つまりイメージ通りにミーティングが進む、そのスピードを調整します。

アジェンダをあらかじめ共有したり、選択肢を提示するのはこれにあたるでしょう。参加者はあらかじめ自身を意見を持ってミーティングに臨めますし、場合によってはとくに議論せずとも全会一致で終わるかもしれません。

ミーティングのような同期コミュニケーションを取らずとも、非同期コミュニケーションで事前に意見を吸い上げておくこともできるはずです。当日さまざまな意見が出るなかで上手にファシリテーションするのは相当なスキルが必要ですが、事前に集めたさまざまな意見をグルーピングしておくのは相対的に簡単なはずです。

まとめ、参加者のひとりである貴方ができること

「ミーティングに大事なnつのこと」ではなく、どういうミーティングになればよいか、という観点で書いてみました。

最後に。

上述の例を読みながら「この参加者もたいがいやなあ」と思った方もいるかもしれません。

実際、彼/彼女は、疑問や不満を持ちながら参加していますが、とくにそれを改善しようとはしませんでした。

主催者がミーティングをイメージできていないのはかなりネガティブですが、仮にそうだとしたとき、これを是正できるのは参加者しかいません。

「もしかしたらサプライズがあるかも」と思った場合は、その不安や懸念をミーティング前に主催者に伝えるだけでも、良いミーティングになるかもしれません。

  1. 今回の記事を書こうと思った直接のキッカケは、資料の準備が無い会議滅びろ委員会|樫田光 | Hikaru Kashidaでした。

217
154
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
217
154

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?