スラッシュドット・ジャパン

昔々、某元は親方日の丸の大会社で仕事した時、毎日毎日進捗発表会で午前中を潰されて、
「この進捗の遅れを取り戻す方策はどうすれば良い？」
と言われて少々キレた事有り。
「進捗の確認は各職長に口頭で伝え責任者にはメールで出して、会議を問題点の対処だけに集中して週一にすれば、
一人当たり週に１２時間余計に作業が可能だと思います」
とついつい言ってしまった。

＃他にも、QC活動の為のQC活動とか有ったりしてそりゃもうストレス溜まりまくり。

マネージャーは会議を開くことが仕事なので、開いて参加さえすれば
それで仕事は終わり。後は野となれ山となれの放置プレイ。

プログラマーは物を作るのが仕事なので、会議に参加すればするほど
開発に避ける時間が減る。さらに当然のごとくデスマになれば、
評価も下がって給料にも響く。

極論すれば、会議を数多く開けば開くほどマネージャーの給与は上がるが、
開発現場ではデスマの確率が上がり、しかもその責任は何故か一方的に
現場に押し付けられてプログラマーの給与は下がる。

同じ会議（例えばプロジェクトに進捗会議）で見ればそれは正しいですが、
マネージャーとてレポート先があるので、他の会議には準備はするはずですよね？
確かに、マネージャーがレポートしやすいように報告書を何度も作り直させたり、って事はありますが（怒）。

以前に（IT関係ではない会社でしたが）、
マネージャー自身がその上司から何を言われていて、
その結果こういう対応をする事にしたので、協力して欲しい、
と言う内容の話をするマネージャーがいました。

マネージャーとエンジニアは違うと言っても、
プロジェクト成功させるという事と、
それをさらに上層部から評価してもらう、
という共通の目的があるので協力したくなる言い方だなと思いました。

主催者ってその辺事前に説明しないんですか？

説明のための会議は開きませんが、目的や資料は全部メールで送ってありますとも。

その証拠に、マネージャ以外全員、会議の目的もゴールも資料も、全部把握している。

まずもって、会議を開かないようにする。

情報を一箇所に集めるための会議、というのはほとんどの場合意味がありません。マネージャがエンジニアの間を回遊して情報を収集し、まとめたものを全体に配ればよい。
その結果に対して、突っ込みを入れるための会議という形にすれば、エンジニア自体は会議の前30分ぐらいあれば、会議準備もできる。合計でも2時間程度で済みます。

さらに、「枠を確保する」というのと「会議を開く」というのを同義にしない。
乱暴な話、特に突っ込み所が無いなら会議は開かなくてよい。上記の例なら、まとめを受け取って最初の30分以内に突っ込みを入れたい人は手を上げる。そうしたら会議。誰も手を上げなくて、マネージャ自身も確認事項、連絡事項ともに特に無ければ、その会議枠は解放。

.

最悪なのは、会議室につれて来られてからテーマを与えられて、
「さぁ、考えろ。さぁ、答を出せ」
とせっつくタイプの会議です。大抵の効率の悪い会議はこのパターン。

人によって、ある種類の問題を解くのが得意な時間帯というのは異なります。それを強引に「会議のある時間帯」に押し込もうとしたら、良案は出ませんし効率も悪い。それでも、お客様との会議ならばやむをえないかもしれませんが、社内会議でそれはやるこっちゃない。

ましてや「午後7時からでお願いします」とか言うのは論外。

意外と理解されていないみたいだが、会議は報告する場じゃなくて決定する場なんだよね。
だからそれを考慮してブレインストーミング効果を活用する様な案件なら、間違いなくメーリング
リストやグループウェアよりも効率は良い。

それらには同時性が負担できないから、リアルタイム応答が得られる会議に勝てる物では無い。

にも関わらず実際にそれらが効率が高く見えるかって言えば、本来会議とするべきものでない
物をも、会議として行っているからだろう。

「今から仕様を決める」ならこれは会議の方が効率が良い。
でも、「進捗の確認をする」のであれば、本来は人間が顔を合わせる必然性は無いもの。
そして、そこでの一番頻繁に発生する問題「遅れ」に対して、その「自称会議」という物は
足を引っ張る方に作用する。
そりゃ嫌われるのは仕方なかろう。

マネージャーは会議好き、プログラマは懐疑的