こんな定例ミーティングは嫌だ

私は、基本的に「定例ミーティングはやるべき」と思っています。
しかし、開催するからには意味のある時間にしないといけません。

だって、定例ミーティングって、開発者にとっては面倒臭いんですよ（ ´＿ゝ｀）
特にソフトウェア開発では、作業の中断は、けっこう開発効率に影響するんです。

そんな開発者の心情を逆撫でしてしまうような、
私の経験した「ダメなミーティング」の例をいくつか紹介します。

議題（アジェンダ）を知らせない

ミーティングが始まってから、初めて議題を知らせるケースです。
中には「議題が決まっていない」なんてミーティングにも遭遇したことがあります。

議題が「機密情報に関するもの」でもない限り、
参加者には、事前に議題を伝えておくべきです。

議題に関する質問や関連情報などを持ってきて貰えることもありますし、
そうすれば、集まって話す意味も出てくるわけです。

むしろ、議題が事前に決まらないような惰性のミーティングであれば、
中止することも検討した方がよいでしょう。

タイムテーブルがない、時間管理ができていない

次によくないのが、以下のような状態になるミーティングです。

• 議論が始まり、発散してしまう
• 時間通りに終わらない or 議題が消化できない
• 思いつきで余計な議題や報告が挟まれる

進行役が時間を管理できないと、いくら議題が予め決まっていても、
参加者にとって「意味のない」ミーティングになってしまいます。

私が東京で勤めていたある職場では、
事前の通達に、議題と共におおよそのタイムテーブルも記載されており、


という対応が取られている所もありました。

とにかく、ミーティングの主催者側は、
「参加者の時間を借りる」という意識のもとに執り行う必要があります。

結論や課題が不明なまま終わる

ミーティングを終えた後は、

• 取るべき具体的な行動が決まる
• 曖昧だった問題が明確になる

といった状態になるのが理想です。

ミーティングに参加したことで「仕事が前に進む」となれば、
参加へのモチベーションも上がります。

特に、議論が行われたミーティングでは、終了時に進行役や書記の人が
「ミーティングで決まったこと」「次回までの課題」のまとめをするとよいでしょう。

ミーティングそのものだけでなく、ミーティングを開催することで、
その後の作業にどう影響を与えたか？も大事なわけです。

リーダーやマネージャこそ積極的に報告を

以前の記事でも触れたことがあるのですが、定例ミーティングにおいて、
業務の成果を積極的に報告しなければいけないのは、リーダーやマネージャです。

開発者は、目に見える物を作っているので、極端な話、報告をしなくてもよいのです。
（もちろん "成果物" を作るだけが、開発者の仕事ではありませんが）

ある職場での話

以前、マネージャが待てど暮らせど事務報告以外しない、
という開発プロジェクトに遭遇したことがあります。

こうなると定例ミーティングは、開発者に対する

• 無駄な召集に参加者を従わせるという上下関係の誇示
• マネージャが開発には非協力的だという意思表示
• 主体的に組織の活動に参加する意識の喪失

というネガティブな印象を誘発する場にしかなりません。

しかも、そのマネージャは「開発者とマネージャは対等である」と力説するくせに、
参加者が話を聞かなくなるという理由で、ノートパソコンの持ち込みを
禁止にしようとしたりしました。（自分たちは持ち込み可）

言ってることと、やってることがチグハグでした。要するに言行不一致です。
「言葉は軽く、行動は重い」の記事で書いたように、言行不一致は信頼をなくすだけです。

たかが定例ミーティングと侮っていると、
知らないうちに現場の開発者の信頼を失っていることさえあるわけです。

今日のまとめ

• 主催者は、「参加者の時間を借りている」という意識を持つ。
• ミーティングの時間だけでなく、開始前と終了後の行動も大事。
• リーダーやマネージャこそ積極的に報告を行う。

定例ミーティングの上手い・下手を見ることで、
その組織のマネジメントの上手い・下手が、ある程度分かってしまいます。

そして「ソフトウェアの開発規模とチーム人数」の記事で書いたように、
大規模な開発にはマネジメントは不可欠です。

つまり、その組織の定例ミーティングの進め方を観察すると、
大規模開発の上手い・下手も、ある程度分かってしまうのです。