無料会員登録
「聞いた話」はダメ、具体的な意見を述べよ
鉄則は「結論を出さないこと」。会議を切り上げるために「じゃあ結論を出そう」となりがちだが、無理に結論らしきものを出しても意味はない。
なぜなら、このタイプの会議にはデザイナーや企画担当者やメカの設計者など、立場の異なる多様なメンバーが集まっている。会議を受けてどのように対処するかは、立場によってまるで違う。つまり参加者の数だけ結論はある。
むしろ大事なのは、議論の中でどのような情報が出たかということだ。結論らしきものを出そうとすれば、それは必ず「ミッションの達成」を意味する新味のない言葉になるはずだ。それよりも途中経過を記録した議事録をつくり、それを各々が現場へ持ち帰るべきなのだ。
主宰者は「無理に意見をいわせない」ことも心に刻んでおかなくてはならない。
「私、ちょっとわからないんですけど」と前置きして出てくるのは無責任な意見である。話が混乱するだけなので聞いてはならない。「聞いた話ですが……」ではじまる意見も、情報源があやふやで無責任な抽象論になりがちだ。逆に「うちの子供は」という具体論なら、いくらでも話してほしい。
さて、最も特殊なのが4番目の「ブレーンストーミング」だろう。
これはセレモニーとしての会議や情報共有型の会議とは正反対で、制限時間を設けずに、体力が続く限り何泊でもしてアイデアを煮詰めるものだ。よく行うのは開発会議だが、業務プロセスの改善をテーマにしたものでも効果をあげやすい。
ここには、なるべく職位の上位者は参加しないほうがいい。理由は簡単で、時間無制限の会議だから年長者は先に参ってしまう。しかもその人がリーダーであれば、自分が疲れたところで「このへんでいいだろう」とまとめに入ってしまう。メンバーのアイデアが最後まで出つくさないうちに会議が終わってしまうおそれがあるのだ。
ただし、若いメンバーも最後には疲れきってしまうので、一眠りすると、何を話し合ったか忘れてしまう。だから、どんなプランが出て、どんな反対意見が出たのかをきちんと書き留めておく必要はあるのだが。
