油絵フィルターと「マウスごしごし」インターフェイス
「泳ぎ続けなければ生きていけないサメ」と「波間にただようマンボウ」、あなたはどっち?

会議での「先送り助け舟」が本当に迷惑な点について

 私は基本的に会議はきらいだが、特にアジェンダがはっきりと決まっていない会議だとか、何も決定を下さない会議が大嫌いである。そんな中でも、もっとも許せないのが「提案を文書にする」「次のミーティングを設定する」などの一見建設的だが、実は単に意思決定を先延ばしすることを許容するだけの「助けにならない助け舟」である。

営業部長「こうなると選ぶ道はAかBしかありませんね」
社長  「そうは言っても色々と難しい面もある」
技術部長「ここで、決めるしかありませんね」
社長  「そんな簡単な話ではないだろう」
営業部長「そんな悠長なことを言っている暇はありません」
社長補佐「まあまあ。じゃあ、まずは営業部長に彼の提案を文書にしてもらうというのは、どうでしょう」
技術部長「文書にするって、今さんざん話したばかりで、もう分かっているじゃないか」
社長補佐「そうあわてずに。文書にしてもらえば見えてくることもありますから。」
社長  「そうだな、それを見てからもう一度会議を開こう」
技術部長「しかし…」
社長補佐「じゃ、今日の会議はこれで終わりということで。皆さんありがとうございました」

 よくあるパターンである。お分かりだと思うが、この例では、社長はなんらかの理由でその場で決定を下すことをためらっている。営業部長と技術部長がなんとかその場で社長に決定を下させようと迫っているのだが、そこで社長に対して余計な助け舟を出すのが社長補佐である。

 このくらい分かりやすく書けば、この手の「助け舟」を出すことは単なる一時しのぎでしかなく、本当の助けにならないことぐらいは明らかだと思うが、実際の現場ではもう少し巧みに行なわれるため、会議に参加しているほとんど全員が「おお、これで一応今日の会議の成果はあげられたな」と心の底から勘違いしてしまうケースが多々ある。

 考えてみると、私が直接関わったソフトウェアのプロジェクトで成功したもの(Windows95、Inernet Explorer、Candy、Gameコンパイラ)はすべて少人数で立ち上げて一人か二人でほとんどのことを決めてしまったが、失敗したプロジェクト(Netdocs、Cairo)はすべて最初から大人数が関わって、会議・会議でものを決めようとした。

 一人や二人でもの作りをすると、決定を先送りした「しわ寄せ」はすべて自分たちに返ってくるので、どうしてもどんどんとものを決めておかざるをえない。大人数でものを作ると、大人数ゆえの非効率さに加えて、「全体としての方針が決まっていないから私はまだ前に進めない」という言い訳が通じてしまうので、どんどんと効率が落ちる。

 まあ、そうは言っても、どうしてもある程度の人数で仕事をしなければならないケースはあるので、せめてその時には、問題の先送りを助長するような「助け舟」だけは出さないようにしましょう、と言うのが今日のメッセージである。

Comments

hg

うー、これは重要ですね。
官公庁に配布したいとこです。

蛟竜

私の経験したいやな会議は、よくある状況だとは思いますが、
積極的な意見を求めているという建前のもとで、新しい提案をすると上役に却下されつつ、何も意見を言わないと非難されるという状況でした。提案のメリットよりもデメリットばかり指摘されるというのは大変心苦しい経験です。上司がなぜ新しい提案を求めつつ、提案の先延ばしや消極的な否定を行い続けているのか、という心理を理解できるようになりたいです。

yu

どこの会社・職場でもありがちな光景である。少人数での迅速な意思決定はある意味で成功への条件なのかもしれない。

ところで、今はブームも過ぎた感じだがシックスシグマのワークアウトの手法はどうだろう? 手順の解説を読むと、ワークアウトではプロジェクトメンバーがまとめた提案に対して、プロジェクトオーナーは5分以内にそれを採用するか否かを「決断」しなければならないという。

たしかに「決断」できなければリーダーの資格はない。また提案自体がどうしようもないものならば、それはプロジェクトメンバーを入れ替えればいいだけのこと。「先延ばし」はいかなる意味でも合理的ではない、ということだろう。

oyo

 会議にかかるオーバヘッドは参加人数の指数に反比例するのではないかなー?と思ってます2^n(n=参加人数)。なぜかというと、会議の仕組みはノード(人)がメッセージを処理(理解)して総合的に結論を判断する意思決定システムだからです。
 極端な例えだと、一人で情報を集めて判断できれば、それがもっとも効率がいい。逆に多いほど効率が悪い。スパコンが通信オーバヘッドで性能上限に達してしまうように、会議の参加人数に限界があるかもしれません(笑)
 先延ばし云々の話は、情報処理性能の足並みを揃えられないノードがいるということだと思います。
 それ以外に会議には問題があって、音声プロトコルでメッセージを受け答えするのは効率が悪いです。「聞く話す」は高速化に限界があるので。「読む」に特化した情報交換ができるなら、意思決定システムはまだ高速化できる余地があると思います。

SQ

誰かが同じこと書いてましたね。
RFIDとIPODでしたっけ。

まったくそのとおりだと思います。
本当に。。

humu

必ずしも本文の例とか合致しないかもしれないけど,A,Bの二者択一を求めた場合
両方ともに決定打に欠ける or 説得できるだけのプレゼン能力がるのかどうか?
というのも問われるのでは?

同じものを文書にするかどうかは置いておくとしても,熱に浮かされたように
その場のある意味ノリで決めてしまうのは本当に正しい?

熟考するために期間をちょっと開けましょうというのはケースによってはやはり
有効化選択肢の一つだと思うよ

どんな物事でもケースバイケースじゃないかなあ

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)