はじめに：会議が多いと作業に集中できない
こんばんは、e-dash のプロダクト開発部でエンジニアをしている yuki_nomura です。
弊社では幸いなことに社員数が着実に増えており、それに伴い事業スピードを加速して拡大を図っています。そんな中で、新たな課題が顕在化してきました。
「会議が多くなってきた」という問題です。
こうした状況を受け「会議を減らそう」という声が上がっています。
「会議が多すぎて集中できない」という嘆きを耳にすることは少なくありません。
とくにエンジニアであれば、実装や設計にまとまった時間を使いたいのに、スケジュールが会議で埋まってしまうのはフラストレーションの種になります。
そこで、「会議を減らせば作業時間が増え、結果的に生産性が上がる」と主張する声が出てくるのも自然な流れですし、方向性としては決して間違っていないでしょう。
しかし、本当に会議の削減をすれば生産性が向上すると 言い切れる でしょうか。
会議を一掃した結果、必要な情報共有や意思決定が滞り、むしろ開発プロセスが混乱してしまうリスクは否定できません。
この記事では、会議削減のリスクや必要なコミュニケーションのあり方について考えてみたいと思います。
会議を減らすことが正解ではない
会議を減らすと聞くと、一見 良いことづくめ に思われるかもしれません。
逆に「会議をしなかった場合、どんなリスクが顕在化するか」というシンプルな問いから考えてみたいと思います。
ゴミ（使われないアウトプット）の量産リスク
エンジニアとしては、手を動かしてどんどん機能を作るのは楽しいもの。
しかし、「とにかくたくさん作れば価値が高まる」というわけではありません。
会議の削減によって顧客やユーザーの声を十分に拾わなければ、実際には誰も使わない、あるいは求められていない機能が生み出されてしまうリスクが高まります。
誰も使わない機能は「粗大ゴミ」 と言っても過言ではなく、後から削除・再設計が必要になり余計な工数が発生しがちです。
それだけでなく、コードベースを複雑化させて サービス全体の品質やユーザー体験を損なう 可能性もあります。
結局、アウトプットの数ではなく 「価値をもたらすアウトカム」 が最も重要です。これはユーザーに対してだけでなく、開発チームにとっても同様でしょう。
意思決定とコミュニケーション不足による手戻りリスク
プロダクト開発は常に「何を、いつ、どのように作るのか」という意思決定の連続です。
UI ひとつとっても、機能との兼ね合いやユーザー体験、納期やリソースとのバランス調整など、多角的な検討が必要になります。
こうした意思決定を行う際、関係者（たとえばプロダクトオーナーやデザイナー、QA など）との 適切なコミュニケーション は欠かせません。
もし会議を極端に削減してしまえば、情報共有不足から方向性を誤ったまま開発が進行し、「仕様が合わない」「この機能はそもそも不要だった」という手戻りが増えてしまうリスクが高まります。
結果として、開発スピードや品質が大きく損なわれる可能性が高くなると言っても良いでしょう。
何を目指すべきか：価値あるアウトカムを生み出すためのコミュニケーション
会議を「削減するか、しないか」という二元論に陥るのではなく、「いかに価値あるコミュニケーションを実現するか」が本質といえます。
そのためには、以下のような工夫が効果的と考えます。
- オーナーシップを明確にする
- 会議をコントロールする担当者やチームを設定し、会議そのものの責任と目的を明確化する。
- 誰が会議を運営しているのかがはっきりすると、「本当にこの会議は必要か」という視点を持ちやすくなり、無駄の削減につながります。
- アジェンダとゴールを明確に
- 会議の前、あるいは開始時に「何を決めるのか」「何を共有するのか」を参加者同士で認識合わせしておく。
- あらかじめ目的が明確であれば、「いま決めなくてもよいこと」や「他の方法で共有できること」が浮き彫りになり、時間を大幅に短縮できます。
- 必要な人と役割を決めておく
- 意思決定者が不在の会議や、「何となく呼ばれているだけ」の参加者が多い会議は迷走しやすくなります。
- 本当に必要なメンバーだけを集めることで、意思決定の速度と質が高まり、不要な情報共有も減らせます。
これらを意識して会議を運用すれば、ただ数を減らすだけでなく 「意思決定ミスを防ぐ」「使われない機能を作らない」「集中作業時間を確保する」 を同時に目指しやすくなるでしょう。
弊社で実行してみたこと
会議が増えたという課題から目を背けず、「エンジニア」「デザイナー」「プロダクトマネージャー」「QA」など異なる役割のメンバーを集め、次の手順で会議の整理を行いました。
- 定例会議を洗い出す
- 洗い出した会議を「今のままで良い会議」と「あり方を変えたい会議」に分ける
- 「あり方を変えたい会議」について、深く話し合う
この作業は Figjam や Miro などのオンラインホワイトボードを使ってリモートでも行えます。オフラインなら付箋とペンがあれば十分でしょう。
Figjam であれこれ話した跡
議論の結果の一例として、スクラムイベントに対して次のようなアクション（Next Action）を立てました。
- プランニング 1
- PM, エンジニアが「やりたいこと」を事前にリストアップしておく
- 事前に「やりたいこと」が出ている前提なので、時間を短縮
- プランニング 2
- 各チーム判断とする
- リファインメント
- Slack のリマインダーに返信する形で、対象チケットをあらかじめ見える化
- 必要なチケットに関係するメンバーのみが参加し、他の人の時間を奪わない
- レビュー
- 会議内容を録画しておき、後から必要なタイミングで見返せるようにする
このように 必要な場は残しつつも、時間短縮や必要メンバーの限定化 を進めることで、1 スプリントあたり最大 2〜3 時間の会議削減が可能になりました。
完全に会議をなくすといった 0-1 思考に陥らず、使える要素を最適化しながら進めるだけでも大きな効果を得られることが分かりました。
あとはレトロスペクティブなどで継続的に振り返り、さらに改善を図っていきたいと考えています。
まとめ
会議が多いと、「会議を減らせば生産性が上がる」と安易に結論づけたくなることがあります。
しかし、必要な場まで削ってしまうと 意思決定の迷走や使われない機能の量産 といった重大なリスクをはらむ可能性を見逃せません。
生産性向上の鍵は、 「いかにして価値を持った成果（アウトカム）を効率よく生み出すか」 にあります。
そのためには会議を闇雲に減らすのではなく、 しっかりと目的を持って行い、必要な情報と判断を得る「最適化された場」 として活用することが大切です。
必要なコミュニケーションを保ちながら、不要な会議を減らす工夫を続けることで、プロダクト開発全体の質とスピードがさらに高まっていくはずです。
Discussion