この問題は、ほとんどのエンジニアにとって「魂の問い」と言えるでしょう。コードを書き始めると、まるで世界を創造しているかのような感覚に陥る一方で、会議に引きずり込まれると、人生が浪費されているように感じてしまう。この感覚はごく自然なことです。
「効率」というものを、二つの視点から見てみましょう。
第一に、「個人の生産性」という観点から見ると、コードを書く方が断然効率的です。
コードを書くことは、創造的で即座にフィードバックが得られる作業です。機能を実装すればそれが動き出し、バグを修正すればプログラムが正常に動作する。この感覚は、職人が作品を作り上げるのに似ています。一打一打、磨くたびに作品が完成に近づいていく。このような生産性は目に見え、数値化でき、大きな達成感とフロー体験をもたらします。1時間のコーディングで、新しいページが一つ生まれるかもしれません。
では、会議はどうでしょうか？1時間の会議では、ほとんどの時間を他人の話を聞いたり、一見「抽象的」に見える議論をしたりしているかもしれません。会議自体は直接コードを生み出したり、バグを修正したりするものではありません。この観点から見れば、それは確かに「非効率」です。
第二に、「チームの生産性」と「無駄の回避」という観点から見ると、効果的な会議は、あなたが一人で黙々とコードを書くよりも「効率的」である可能性があります。
例を挙げてみましょう。私たちは船を造ろうとしています。あなたは最高の木工職人で、木材を与えられればあっという間に船体を造り上げることができます。
-
シナリオ1： 誰とも会議をせず、木材を受け取るとすぐに作業に取り掛かり、自分の想像と経験に基づいて、せっせと1ヶ月かけて見事な船体を造り上げました。しかしその時、デザイナーがやってきて、「顧客の要望が変わりました。私たちが求めているのは尖った船ではなく、平らな船です」と言いました。どうしますか？1ヶ月の努力は無駄になり、すべてをやり直さなければなりません。
-
シナリオ2： 作業に取り掛かる前に、あなたは半日かけてデザイナー、営業、そして帆を作る担当の同僚と一緒に会議を開きました。皆で設計図を照合し、船のサイズ、形状、用途、そして各々の役割分担を確認しました。この半日間、あなたは木材に一切触れず、「生産性がなかった」と感じるかもしれませんが、この会議があったおかげで、その後の1ヶ月間の骨の折れる作業がすべて正しい方向に向かうことが保証されました。
この「会議」というプロセスは、目標を合わせ、情報を同期し、障害を取り除くためのものです。その役割は、チームの全員が同じ方向に向かって努力し、情報伝達の滞りによって無駄な作業をしたり、互いに「衝突」したりするのを避けることです。
良い会議は、重要な意思決定を解決し、プロジェクトが数週間の遠回りをするのを防ぐことができます。このような「効率」は指数関数的ですが、コードを書くようにすぐに目に見えるものではありません。
ですから、あなたの感覚は間違っていません。あなた個人にとっては、単位時間あたりのコード作成の生産性は、会議よりもはるかに高いです。 これこそが、エンジニアとしてのあなたの核となる価値です。
しかし、チーム全体やプロジェクトにとって、短く効率的な会議が回避する将来のコストや無駄は、数人のエンジニアの数週間分の作業量をはるかに上回る可能性があります。
スタートアップ企業では特にそうです。リソースが限られ、試行錯誤のコストが高いため、チーム全体が猛進した結果、間違った方向に進んでいたという事態が最も恐れられます。
もちろん、現実で私たちがうんざりするのは会議そのものではなく、「無意味で、長々と続き、準備不足で、なぜ開催されているのか分からない」会議です。ですから、重要なのは会議を開くかどうかではなく、いかに会議をうまく運営し、それが本当に「設計図を照合する」役割を果たし、皆の時間を無駄にしないようにするかです。