なぜIT業界の会議は長引くのか？エンジニアを疲弊させない「PjM流・最強の会議術」
こんばんは！IT業界で働くアライグマです！
カレンダーに、新しい会議の招待が滑り込んでくる。その瞬間、多くのエンジニアの心に、ある種の「絶望」がよぎるのではないでしょうか。集中してコードの海にダイブしていた思考は強制的に中断され、得られたはずの生産性が、また一つ、泡となって消えていく。
「この会議、本当に今やる意味あるのか？」「アジェンダもなしに、何を決めるんだ？」「また長引くんだろうな…」
そんな心の声が、開発チームのSlackで愚痴として漏れ聞こえてくるのは、IT業界の日常風景かもしれません。しかし、これは単なる「あるあるネタ」で済まされる問題ではありません。無駄な会議は、エンジニアのモチベーションを削ぎ、プロジェクトの遅延を生み、そして組織全体の競争力を蝕む「静かなる病」なのです。
私自身、PjMとして多くの会議を主催する立場にありますが、同時に一人のエンジニアとして、その理不尽さを痛いほど感じてきました。この記事では、そんな私の両方の視点から、なぜIT業界の会議は無駄に長引くのか、その根源的な原因を告白します。そして、エンジニアを疲弊させず、むしろ開発を加速させるための、具体的で実践的な「PjM流・最強の会議術」を、余すところなくお伝えします。
PjMの告白：なぜ、私たちは「無駄な会議」を開いてしまうのか
まず、エンジニアの皆さんには、会議を主催する側の事情も少しだけ知っていただきたいと思います。もちろん、無策なPjMを擁護するつもりはありません。しかし、無駄な会議が生まれる背景には、PjMが抱える構造的なプレッシャーや悪癖が存在するのです。
理由1：責任の分散と「合意形成」という名の儀式
PjMは、プロジェクトの成功に対して重い責任を負っています。そのプレッシャーから、「自分の独断で決めた」という状況を無意識に避けようとする心理が働きます。そこで行われるのが、「関係者を集めて、みんなで決めた」という既成事実を作るための「合意形成」という名の儀式です。
本当はもう結論が出ているのに、念のためにエンジニア、デザイナー、営業担当者を集めて会議を開く。これは、万が一プロジェクトが失敗した際に、「あの時、会議でみんな合意しましたよね？」と言えるようにするための、一種の防衛策なのです。しかし、この儀式のために、多くのエンジニアの貴重な時間が奪われていきます。
理由2：単純な準備不足と「とりあえず集まろう」という悪癖
悲しいことに、これが最も多いパターンかもしれません。PjMは常に複数のタスクに追われており、一つの会議のために十分な準備時間を確保できないことがあります。論点が整理できていない、誰に何を確認したいのかが明確でない。そんな状態で、「とりあえず関係者を集めて話せば、何か良いアイデアが出るだろう」という淡い期待のもと、会議を招集してしまうのです。
これは、目的も地図も持たずに航海に出るようなものです。漂流の末に、結局「持ち帰って検討します」という、最も無意味な結論に至るケースが後を絶ちません。
理由3：エンジニアへの不信感とマイクロマネジメント
これはPjMとして認めたくない事実ですが、一部のマネージャーは、エンジニアの自己申告による進捗を心から信頼していません。JiraやBacklogのチケット更新だけでは、「本当に進んでいるのか？」「何か問題を隠していないか？」という不安を拭えないのです。
その結果、進捗を確認するためだけの会議が頻繁に開かれます。これは、エンジニアの時間を奪うだけでなく、「自分は信頼されていない」というメッセージを発信することになり、チームの心理的安全性を著しく損なう、最悪のマイクロマネジメントと言えるでしょう。
PjM流・会議設計の3原則：開催前に勝負は9割決まる
無駄な会議を撲滅するための戦いは、会議が始まる前、その招待メールを送る瞬間に、すでに9割が決まっています。私がPjMとして徹底している、会議を「設計」するための3つの原則をご紹介します。
原則1：明確な「ゴール」と「アジェンダ」を定義する
会議の招待状には、「この会議が終わった時、何が決まっていれば成功なのか」というゴールを、誰が読んでも一意に解釈できる言葉で記述します。
- 悪い例: 「新機能について」
- 良い例: 「新機能Aの実装について、フロントエンドとバックエンドのAPI仕様を確定させる」
そして、そのゴールを達成するための具体的な議題（アジェンダ）と、それぞれの議題にかける時間配分を明記します。これにより、参加者は事前に何を準備し、会議で何を議論すべきかを明確に理解できます。
原則2：参加者を「必要最小限」に絞り込む
Amazon社の「2枚のピザルール（会議の参加者は、2枚のピザで満腹になる人数であるべき）」はあまりにも有名です。会議の生産性は、参加者の数に反比例します。
参加者は、「その場で意思決定を下す人」と「意思決定に必要な情報を持つ人」だけに限定すべきです。情報共有だけが目的であれば、会議後に議事録を送れば十分。「念のため」で関係者を呼ぶのは、全員の時間を奪う罪深い行為だと心得るべきです。
原則3：「会議」以外の最適な手段を検討する
そもそも、その目的を達成するために、本当に会議が必要なのか？と自問自答する癖をつけましょう。
- 単なる情報共有や進捗報告: SlackやTeamsなどのチャットツールで十分です。
- アイデア出し（ブレインストーミング）: MiroやFigJamのようなオンラインホワイトボードで、非同期に行う方が、かえって多様な意見が出やすいこともあります。
- 仕様に関する簡単な質疑応答: ドキュメント（ConfluenceやNotion）上のコメント機能で完結させましょう。
同期的なコミュニケーションである会議は、参加者全員の時間を拘束する、最もコストの高い手段です。そのために不可欠なスキルが「ファシリテーション」です。
ファシリテーション入門この書籍は、会議の生産性を高めるための具体的な進行術や、参加者の意見を引き出すためのテクニックについて、網羅的に解説しています。すべてのPjM、そしてチームリーダーを目指すエンジニアにとって、必読の一冊と言えるでしょう。
エンジニアができる自己防衛術：会議に「殺されない」ために
会議の改善は、主催者だけの責任ではありません。参加者であるエンジニア自身も、チームの生産性を守るために、できることがあります。
防衛術1：「アジェンダのない会議」には出席を拒否する勇気
これは、少し勇気がいるかもしれませんが、非常に効果的です。目的や議題が不明確な会議の招待が来たら、ただ承認ボタンを押すのではなく、丁重に、しかし明確に主催者に問い返しましょう。
【返信テンプレート】
「〇〇さん、会議のご招待ありがとうございます。当日に向けてしっかり準備をしたいので、お手数ですが、この会議の具体的なゴールとアジェンダ（議題）をご共有いただけますでしょうか？」
この一文を送るだけで、主催者は準備不足を自覚し、会議の目的を明確にせざるを得なくなります。これは、チーム全体の生産性を高めるための、極めて建設的な行動です。
防衛術2：ファシリテーターを補助し、議論を本筋に戻す
会議が始まっても、話が脱線して雑談が始まってしまうことがあります。そんな時は、ファシリテーター（多くはPjM）を助ける意識で、軌道修正を試みましょう。
【発言例】
「〇〇さん、非常に興味深い論点ですが、一度アジェンダの△△の件に戻りませんか？残り時間も少なくなってきましたので。」
これは、議論を妨害するのではなく、会議の成功に貢献するための、当事者意識の表れです。
防衛術3：「持ち帰って検討します」を封じ、その場で結論を出す
議論が紛糾した際に、最も安易な逃げ道が「一旦、持ち帰って検討します」です。これを許すと、同じ議論を次の会議でまた繰り返すことになります。
そうなる前に、「この場で決めるために、あと何の情報が必要ですか？」「今日の選択肢の中で、最もリスクが低いのはどれですか？」と問いかけ、参加者全員で結論を出す努力をしましょう。その場で結論を出す文化が、無駄な会議を減らす最大の特効薬です。
こうした当事者意識の高い文化は、まさに「アジャイル開発」の思想そのものです。個別のテクニックだけでなく、チーム全体で生産性の高い開発文化を築きたいと考えるなら、アジャイルの本質を学ぶことが遠回りのようで一番の近道です。
アジャイルサムライ――達人開発者への道この書籍は、単なる開発手法に留まらず、価値あるソフトウェアを顧客に届け続けるための哲学と実践的なプラクティスを教えてくれます。無駄な会議が生まれる土壌そのものを、チームで変えていきたいと願うすべての人におすすめです。
まとめ
無駄な会議は、いわばチームの生産性を蝕む「生活習慣病」のようなものです。一つ一つは些細な不摂生でも、積み重なることで、やがてはプロジェクト全体を致命的な状態に陥らせます。
この病を治療するために必要なのは、PjMとエンジニア、双方の歩み寄りです。PjMは、会議を「設計」するというプロ意識を持つこと。エンジニアは、ただの参加者ではなく、会議の品質に責任を持つ「当事者」であるという意識を持つこと。
会議は、正しく使えば、チームの力を結集し、複雑な問題を解決するための最強のツールです。ただ愚痴を言うのではなく、明日から、あなたのチームの会議をより良くするための一歩を踏み出してみませんか。その小さな行動が、チーム全体の文化を変えるきっかけになるはずです。