会議はなぜ「椅子取りゲーム」化するのか - - 会議室に流れる「見えない音楽」
アジェンダは完璧、準備も万端。それなのに、なぜか会議が終わる頃には「結局、誰が主導権を握るか」という空気だけが残っている。
そんな経験はありませんか。
ホワイトボードに書かれた正論よりも、誰がどのポジションを確保したか。そんな目に見えない攻防に、私たちは日々ひどく消耗しているのかもしれません。
仕事の現場で、本来の目的を見失った会議が「椅子取りゲーム」に変質してしまうのには、いくつか明確な力学が働いています。
まずは、評価という名の限定されたリソースへの執着です。
組織という構造の中では、椅子(=評価されるポジション)の数は決まっています。全員が均等に称賛されることは稀で、誰かが「有能」という椅子に座れば、必然的に他の誰かは座れなくなる。
そうなると、議論の中身よりも「いかに自分が価値ある発言をしたか」というアピールが優先されてしまいます。
次に、自己防衛という本能的なガードが挙げられます。
失敗の責任という「座りたくない椅子」を誰に押し付けるか。その押し付け合いが始まると、会議は一気に殺伐とした空気を帯びてきます。
リスクを予見していたと主張することで安全圏を確保しようとする行為は、ビジネスマンとしての生存戦略としては合理的かもしれませんが、プロジェクトにとっては停滞でしかありません。
さらに、ITの現場などで顕著なのが「専門性という名の特権階級」の構築です。
複雑な仕様や技術的な背景をあえてブラックボックス化して、自分にしか分からない領域を作る。
これは情報の優位性を利用して、誰にも奪われない椅子を強引に作り出す行為に他なりません。
知識の共有よりも、独占による優位性が優先されてしまうのです。
この不毛なゲームを終わらせるには、個人の意識改革を待つよりも、仕組みという名のプログラムを書き換えるほうが現実的です。
ひとつは、問いの対象を「人」から「事象」へ強制的にシフトさせることです。
椅子取りゲームが起きるのは、参加者の視線が互いの顔に向いているからです。
これをホワイトボードや共有ドキュメントというひとつの「キャンバス」に向けさせます。
解決すべき課題をテーブルの真ん中に置き、全員でそれをハックする対象として定義し直す。敵は隣の席の同僚ではなく、目の前の未解決の課題であるという合意形成が必要です。
また、役割の固定化を解くことも有効な手段になります。
例えば、あえて「常に反対意見を言う役」や「論点を整理する役」を交代制で割り振ってみる。椅子を奪い合わせるのではなく、最初から全員に異なる形の椅子を用意しておくわけです。
役割が明確になれば、自分の存在意義を証明するために無理なマウンティングをする必要もなくなります。
最後に、情報の透明性を極限まで高める努力も欠かせません。
議論のプロセスをログとして残して、誰が何を言ったかではなく、どのようなロジックで結論に至ったかを可視化する。IT技術者がコードをレビューするように、会議のプロセスをレビューできる状態に置くことで、感情や政治が入り込む余白を少しずつ削っていくのです。
椅子取りゲームに勝っても、組織が沈んでしまえば座っている椅子ごと海に沈むことになります。そんな当たり前のことが、会議室の熱気の中ではしばしば忘れ去られてしまいます。
大切なのは、誰が座るかではなく、その椅子でどこへ向かうか。
明日、会議室のドアを開けるとき、少しだけ高い視点からその場を眺めてみてください。
音楽を止めて、全員で新しい椅子を組み立て始める。
そんな小さな変化が、実は一番の近道だったりするのです。
書籍の紹介
・ピープルウエア 第3版 Kindle版
トム デマルコ;ティモシー リスター (著), 松原 友夫;山浦 恒央;長尾 高弘 (翻訳)
日経BP (2013/12/24)
開発プロジェクトで技術よりも何よりも大事なもの――それは「人」。一人一人の人格の尊重、頭を使う人間にふさわしいオフィス、人材の選び方・育て方、結束したチームがもたらす効果、仕事は楽しくあるべきもの、仕事を生み出す組織づくり、という6つの視点から「人」を中心としたプロジェクト開発の大切をユーモラスに語っている。1987年の初版発行以来、多くのソフトウエア・エンジニアの共感を呼んだ名著の改訂第3版。
( ※ 書籍の解説等は原則としてリンク先(Amazon)における解説をベースに記載しています。詳細内容はリンク先を参照願います。)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
いいなと思ったら応援しよう!
よろしければ応援お願いします! いただいたチップはクリエイターとしての活動費に使わせていただきます!