「会議が多い」と嘆くエンジニアは、本当の問題に気づいていないのではないか

結論から言うと、「会議が多い」と嘆くエンジニアは、本当の問題に気づいていないのではないか——最初は半信半疑だったが、実践してみると仕事の進め方の根本が変わった。スキルより先に「習慣の設計」が問われる。この記事では、具体的な方法と気づきを正直に話す。

「今週も会議が多くて、コードを書く時間がなかった」。エンジニアとして働く人なら、この感覚を一度は持ったことがあるはずだ。会議の件数が多いことは確かに問題かもしれない。しかし、「会議が多い」という嘆きの裏に潜む本当の問題は、件数ではなく「会議の質」と「自分の会議との向き合い方」にあることがほとんどだ。

Googleの元プロダクトデザイナー、ジェイク・ナップとジョン・ゼラツキーが書いた「時間術大全」には、時間を奪うものの正体とその対処法が書かれている。会議そのものを悪者にするのではなく、「自分の時間をどう設計するか」という視点を持つことで、会議との関係が根本的に変わる。会議を減らすことより、会議の使い方を変えることのほうが、エンジニアの生産性に大きな変化をもたらす。

さらに、会議での発言の質を高めることも重要だ。伊藤羊一の「1分で話せ」が教える「結論から1分で伝える」技術は、会議でのコミュニケーションを根本から変える。長い説明をする必要がなくなり、自分の発言時間が減る分、思考に使える時間が増える。会議の時間を削るより、会議での発言を磨くことが、エンジニアとして最も効果的な会議改善策になる。

時間術大全も1分で話せも、Audibleで通勤中に聴けるビジネス書だ。会議の前の電車の中で「1分で話せ」を聴いて発言の構成を準備する。そのサイクルが、会議でのパフォーマンスを毎回少しずつ上げていく。

※ 30日間の無料体験。いつでも解約可能。

エンジニアの会議問題。本当に悪いのは「件数」ではない

「会議が多い」という不満を持つエンジニアに、「今週何時間会議に使ったか」を聞くと、多くの場合10〜15時間という答えが返ってくる。1日平均2〜3時間が会議に消えている計算だ。しかしこの数字だけを見て「会議を減らすべき」と結論づけるのは早計だ。問題は「その会議の中で、自分はどれだけ価値を生み出せていたか」という問いにある。

会議に参加しながら「これは自分がいなくてよかった」と感じたことはないだろうか。あるいは、自分が主催した会議が30分の予定で1時間になり、結論が出なかった経験はないだろうか。こうした「機能しない会議」が積み重なることで、「会議が多い＝時間が足りない」という感覚が生まれる。会議の件数ではなく、一つひとつの会議の質が問題の本質だ。

「機能しない会議」が組織に広がる背景には、「会議を入れることが仕事を進めることだ」という思い込みがある。不確実な状況に直面したとき、人は安心のために会議を設定しがちだ。しかし、解決すべき問いが明確でないまま会議を開いても、会議が終わった後に「結局どうするか決まらなかった」という結果になる。会議を減らす前に、まず「この会議で何を決めるか」を先に問うことが最初の改善策だ。

エンジニアが会議に感じるストレスには2つの種類がある。一つは「自分がいなくてもよかった会議」への参加から来る時間の無駄感だ。もう一つは「会議で何も言えなかった」「自分の意見が伝わらなかった」という自己効力感の低下から来るストレスだ。前者は参加する会議を選ぶことで改善でき、後者は会議での発言力を高めることで改善できる。この2つの問題を別々に解決することが、会議との関係を変える出発点になる。

会議の「本当のコスト」を計算する

会議のコストは参加者全員の時間の合計だ。5人が参加する1時間の会議は、組織全体では5時間の消費になる。さらに、会議前後のコンテキストスイッチングのコストを加えると、その数字はさらに膨らむ。1時間の会議が実質的に2時間の生産時間を奪うケースも珍しくない。このコストを可視化することが、会議の必要性を判断する第一歩だ。

エンジニアに特有の問題として「フロー状態の破壊」がある。深い集中状態（フロー）に入るには15〜20分の準備時間が必要だが、会議が1時間おきに入ると、一日中フローに入れない状態が続く。会議の件数が仮に少なくても、会議の「配置」が悪ければ、集中時間は確保できない。午前中の集中時間を会議で細切れにされることが、エンジニアの生産性を最も蝕むパターンだ。

生産性を下げる会議の特徴

• アジェンダがない：何を決めるための会議かが不明確なまま始まる
• 終了条件がない：何が決まれば会議が終わるかが共有されていない
• 全員参加が前提：情報共有のためだけに全員が集まる設計になっている
• 時間が固定されすぎている：30分で終わる議題に1時間の枠が使われる
• 議事録がない：決定事項と次のアクションが記録されず、次回も同じ議論になる
• 主役不在：誰がファシリテートするかが決まっておらず議論が漂流する

時間術大全が教える「ハイライト」で、参加すべき会議を選ぶ

Googleスプリントの発案者であるジェイク・ナップと、YouTubeのデザイン担当だったジョン・ゼラツキーが書いた「時間術大全」の中心概念は「ハイライト」だ。1日の始まりに「今日最も集中して取り組む一つのこと」を決める。このハイライトを決めることで、1日の時間の使い方の基準ができ、会議の優先度を判断しやすくなる。

ナップとゼラツキーが強調するのは、スケジュールは「自動的に埋まるもの」ではなく「意図的に設計するもの」だという視点だ。会議の招待が来るたびに「参加しなければ」と思ってしまう慣習を断ち切り、「このタイミングで参加することが今日のハイライトに貢献するか」という問いで判断する。この問いがあることで、参加すべき会議と断るべき会議の区別がつきやすくなる。

「時間術大全」はAudibleでも人気の高いビジネス書だ。通勤中に聴くと、時間の設計という概念が日常に馴染みやすくなる。本の内容を繰り返し聴きながら、実際の会議への姿勢を少しずつ変えていく。意識的な変化は習慣化するまでに時間がかかるが、Audibleでの反復学習が定着を早める。

この本はAudible（オーディブル）で聴くこともできます。 今なら1冊無料でお試し →

「ハイライト」を使った会議の取捨選択

毎朝「今日のハイライト（最重要タスク）」を決めてから、その日の会議リストを見直す。ハイライトと直接関係のない会議には「アジェンダを確認してから参加を判断します」と返答する習慣を作る。全員参加が前提になっている会議の場合は、「今回は議事録で共有していただけますか」という代替案を提案する。参加する会議を自分の判断で選ぶことが、ハイライトを守る具体的な行動になる。

「ハイライトブロック」として、毎日の午前中に会議を入れない時間帯を設定することも有効だ。Googleカレンダーで「集中作業中」のブロックを毎日設定し、チームに共有する。これにより、チームメンバーも「午前は会議を入れにくい人」と認識し、依頼が減る効果が生まれる。小さな設計の変化が、1週間単位で見ると大きな集中時間の確保につながる。

「Infinity Pool」を避ける

「時間術大全」が警告する「インフィニティプール」とは、Slackやメールのような「どこまでも続くコンテンツ」のことだ。会議の前後にSlackを確認してしまう習慣は、会議と会議の間の貴重な集中時間を奪う。会議が終わったらすぐにSlackを開くのではなく、5分間だけ次のタスクを準備する時間に使う。このわずかな習慣の変化が、会議と集中時間のバランスを改善する。

「1分で話せ」が変える、会議での発言の質

会議でのストレスの多くは「うまく話せなかった」「自分の意見が伝わらなかった」という感覚から来ている。伊藤羊一の「1分で話せ」は、あらゆる場面での話し方を「結論から1分で伝える」という原則で整理している。この原則が会議での発言に定着すると、発言時間が短くなる分、発言の回数が増え、会議での存在感が上がる。

多くのエンジニアが会議で陥るパターンは「背景を長く話してから結論を言う」という順序だ。「えっと、先週から調べていた件なんですが、AとBを比較して、いくつかパターンを試してみた結果、Cという問題が見つかって、それで考えたのが…」という話し方は、聞き手に「結局何が言いたいのか」という不安を与えながら進む。伊藤氏の言う「結論から話す」は、この順序を逆にするだけで劇的に改善できる。

「1分で話せ」はAudibleで通勤中に聴くと効果的だ。会議の直前に聴いて「今日は結論から話す」と意識してから会議に入る。繰り返し聴くことで「結論から話す」という習慣が体に染み込み、意識しなくても自然にできるようになっていく。発言の質が上がると、会議での自分の時間が効率化され、会議全体の生産性も上がる。

この本はAudible（オーディブル）で聴くこともできます。 今なら1冊無料でお試し →

「結論→根拠→具体例」の1分発言フレーム

伊藤氏が提案する発言の構成は「結論→根拠3つ→具体例」というピラミッド構造だ。会議での発言に当てはめると、「Aの実装方針を採用したいです（結論）。理由は3つあります。第一に保守性が高い、第二にチームの既存コードと整合している、第三にパフォーマンスの影響が最小限です（根拠）。例えば先日のBという機能で同じ方針を採用したとき、後の改修コストが30%下がりました（具体例）」という構成になる。

この構成で話す練習として、会議の前日に「明日の会議で言いたいことを1分で話す練習」を声に出してやることをすすめる。実際に声に出して話してみると、頭の中で考えていた内容より冗長だと気づくことが多い。声に出す練習が、会議本番での発言の密度を上げる最も効果的な準備になる。

「発言しない会議」を減らす技術

「自分は発言しなくてもいい参加者だった」という会議が続くのは、「なぜ自分がこの会議に呼ばれているのか」が明確でないことが原因の一つだ。会議の招待を受けたときに「自分に期待される役割は何か」をオーガナイザーに確認する習慣を作ることで、参加する会議での自分の発言の方向性が明確になる。役割が明確な会議では、発言の機会と質が自然に上がる。

発言が苦手なエンジニアが最初に試せる方法は「質問を1つ準備してから会議に入る」ことだ。アジェンダを事前に読んで、「この議題について自分が確認したいことは何か」を1つだけ考える。その1つを会議中に発言するだけで、「発言しない参加者」から「関わっている参加者」に変わる。小さな発言の積み重ねが、会議での存在感を育てていく。

主催者と参加者、それぞれの立場での会議改善アクション

会議の質を変えるアプローチは、自分が主催者か参加者かによって異なる。主催者は会議の設計そのものを変えられる立場だが、参加者でも自分の行動を変えることで会議の質に影響を与えられる。それぞれの立場で何ができるかを理解することが、会議改善の現実的な出発点だ。

主催者として変えられること

会議を主催するときに最初に決めるべきことは「この会議が終わったときに何が決まっていれば成功か」という終了条件だ。この終了条件をアジェンダに明記して参加者に事前共有することで、参加者が「今日の会議で何を議論すべきか」を把握した状態で参加できる。終了条件が明確な会議は、脱線が少なく、予定時間内に終わりやすい。

会議時間の設計も重要だ。多くの会議が30分または60分の固定枠になっているが、「この議題は15分で決められる」と判断したら15分の会議を設定する勇気を持つ。短い会議は参加者の集中度が高くなりやすく、発言の密度が上がる。30分の枠に収まらない議論は、論点の絞り込みが不足しているサインとして捉え、事前に論点を整理することが解決策になる。

「全員参加型」を「必要な人だけ参加型」に変えることも、主催者が取れる最も効果的なアクションだ。情報共有のみが目的なら会議ではなくドキュメントで代替できる。意思決定が必要な議題だけを会議にし、決定権を持つ人と実行する人だけを招集する。残りは議事録で共有することで、会議の参加者数が減り、意思決定のスピードが上がる。

参加者として変えられること

参加者として最もすぐに実践できる改善は「アジェンダを事前に確認し、自分の発言を1つ準備する」ことだ。会議の招待メールやカレンダーのアジェンダを5分読んで、「自分がこの会議に貢献できることは何か」「確認したいことは何か」を事前に考える。この準備があるかないかで、会議中の発言の質と量が大きく変わる。

会議中に「今の議論は今日の終了条件に向かっているか」を意識することも参加者として取れるアクションだ。議論が脱線しそうなとき「今日の目標に戻ると、Aを決めることが先決だと思いますが」という声かけは、参加者であっても誰でもできる。こういった発言が増えると、会議全体の生産性が上がり、「良い会議」という評価がチームに定着していく。

• 主催者：終了条件をアジェンダに明記して事前共有する
• 主催者：会議時間を議題の量に合わせて柔軟に設定する
• 主催者：情報共有だけの会議をドキュメントに置き換える
• 参加者：アジェンダを事前に読んで発言を1つ準備する
• 参加者：議論の脱線に気づいたら終了条件に戻す声かけをする
• 参加者：自分が不要と判断した会議は丁重に断る練習を積む

5ステップで会議との関係を変える実践計画

会議の問題は一度に全部変えようとすると挫折しやすい。1週間に1ステップずつ取り組むことで、無理なく会議との向き合い方が変わっていく。以下のステップは相互に関連しているが、順番通りに進めることで効果が積み重なりやすい。

ステップ1：今週の会議を「必要」と「任意」に分類する

今週参加予定のすべての会議をリストアップし、「自分がいなければ会議が成立しない会議（必要）」と「情報収集のために参加している会議（任意）」に分類する。任意の会議が半分以上を占めているなら、そのうちの一部を議事録で代替することを検討する。この分類をするだけで、「会議が多すぎる」という感覚の正体が明確になってくる。

分類するときの判断基準として「自分が発言しなければこの会議の意思決定が変わるか」という問いが使いやすい。自分の発言が意思決定に影響しない会議は、議事録を後から読む形で代替できることが多い。逆に「自分の技術的な判断が必要とされている会議」は、いくら忙しくても参加する価値がある。この基準で分類すると、参加すべき会議の輪郭がはっきりしてくる。

ステップ2：毎朝「今日のハイライト」を決めてからスケジュールを見る

時間術大全の「ハイライト」を毎朝実践する。「今日最も集中して取り組む一つのこと」を決めてから、その日の会議リストを確認する。ハイライトを妨げる会議があれば「参加の必要性を検討する」という思考が自然に生まれる。この順序を逆にしない。スケジュールを先に見てからハイライトを決めると、会議中心の1日になってしまう。

ハイライトを決めることは、その日の仕事の優先順位を自分でコントロールする第一歩だ。「今日は設計書の草案を完成させる」というハイライトがあれば、「この会議はその時間を削ってでも参加すべきか」という問いが立てやすくなる。ハイライトが羅針盤になることで、会議の取捨選択が感情論ではなく基準論で行えるようになる。

ステップ3：次の会議で「結論から話す」を1回実践する

「1分で話せ」の原則を1回の会議で1回だけ実践する。自分が発言する場面で「結論から話し、根拠を添える」という構成を意識する。完璧に1分に収める必要はなく、「結論を先に言うこと」だけを守ることから始める。この小さな変化が定着すると、会議での自分の発言時間が減り、発言の密度が上がる。

「結論から話す」練習として、会議が終わった直後に「今日言いたかったことを1分で話すとどうなるか」を声に出してみることも効果的だ。反省練習とも言えるこの習慣は、次の会議に向けての発言の精度を上げる。最初はぎこちなくても、10回繰り返すと自然に結論から話せるようになってくる。

ステップ4：自分が主催する次の会議のアジェンダを変える

次に自分が主催する会議のアジェンダに「この会議の終了条件」を一文追加する。「この会議が終わったとき、〇〇が決まっていることを目指す」という一文があるだけで、参加者の会議への準備度が上がり、議論の方向性がそろう。この一文を追加する手間は数分だが、会議の質への効果は大きい。

ステップ5：週次レビューで「今週の会議の収穫」を振り返る

週次レビューに「今週の会議で最も価値があった会議はどれか」「価値が低かった会議はどれか、来週からどう変えるか」という問いを加える。この振り返りを続けることで、自分にとって価値のある会議のパターンが見えてくる。価値のある会議が増えれば、同じ件数の会議でも「会議が多い」という感覚は薄れていく。会議の量より質を上げることが、会議ストレスの根本的な解決策だ。

よくある質問

まとめ：会議の「数」ではなく「質」を変えることが、エンジニアの答えだ

「会議が多い」という問題の本質は、会議の件数ではなく「会議への向き合い方」にある。時間術大全が教えるハイライトの概念を使って参加すべき会議を選び、1分で話せの原則で会議での発言を磨く。この2つのアプローチが組み合わさることで、同じ数の会議でも、会議から得られる価値と自分のパフォーマンスが根本的に変わる。

会議の質を変えることは、チームの合意や組織の決定を待つ必要はない。今日の会議でアジェンダを確認すること、結論から1回話してみること、明日のハイライトを今夜決めること。この3つの小さなアクションから変化は始まる。エンジニアとして「設計で問題を解決する」のと同じ発想で、会議という仕事の構造も設計できる。

時間術大全も1分で話せも、Audibleで通勤中に聴ける。次の会議の前の電車の中で、発言の構成を考えながら聴いてみてほしい。会議で「うまく話せた」という体験が1回積み重なると、会議への苦手意識が少しずつ薄れていく。会議との関係を変えることが、エンジニアとしての働きやすさを自分の手で変える、最も現実的な一歩になる。会議の質を高めるエンジニアは、チームの生産性全体を引き上げる存在になる。そこに気づいてから、会議は「奪われる時間」から「チームに投資できる時間」に変わっていく。それがエンジニアとしての成長にもつながる。

※ 30日間の無料体験。いつでも解約可能。