ベンチャーこそ“会議”が必要だ～“良い会議”の４つの効用と７つのルール～＜①＞

＜ベンチャーに会議は不要、なのか＞

今週読んだブログ記事で一番おもしろかったのが、イノーバ・ブログの宗像さんの火曜日のエントリー「ベンチャー企業の生産性を2倍にする方法」

（http://innova-jp.com/blog/entreprenuer/%E3%83%99%E3%83%B3%E3%83%81%E3%83%A3%E3%83%BC/#more-5138）です。

記事にあるように、何でもかんでも全員で話し合って決める、ではベンチャーの生産性が著しく低くなるというのは頷けます。

一方で、ベンチャーだと必要な話は立ち話程度で済んでしまうので、関係者が集まっての会議らしい会議をしないケースもあると思います。「会議」なんて大企業文化ですからね。それに、人手が少ないのでそれぞれの専門分野に専念している方が効率が上がる、というのも、論理的に聞こえます。

でも僕は実は、「ベンチャーだからこそ会議が必要」と思っています。個々のメンバーがそれぞれしっかりした専門性（プロフェッショナリティ）を持っている「強い個」であればあるほどそうだと思います。

＜会議の４つの効用＞

ソニックガーデンの対談ブログ「MessageLeafの出来るまで【その３】〜自分の思いがちゃんとこもったものが作れる〜」（http://www.sonicgarden.jp/116）にも出ていますが、僕自身は、MessageLeafというITベンチャーをやる中で、毎週必ずチームメンバーと顔を合わせて会議をしています。

記事には、顔を合わせて話すと話が早いという利点について書かれていますが、実はそれよりもさらに重要な４つの効用があります。

効用１：他人のアタマを使って自分のアタマを進化できる

会議をすると、自ずと自分の意見を他の人に説明することが必要になります。まず他の人に説明すること自体で、自分の頭の中が整理されていきます。さらにメンバーから突っ込みが入る（＝質問をされる）ことで刺激を受け、思考が進化＆深化する。これが会議の一番の効用だと思っています。

MessageLeafの本質は「良いコンテンツに対して、『いいね！』以上の気持ちを伝える仕組みづくり」であることに気付いたのも、会議の中で、「MessageLeafが本当にやりたいことってなんでしたっけ？」という倉貫さんからボソっと出てきた質問がきっかけでした。

自分のプロフェッショナルな領域にプライドを持つことは悪いことではないですが、それが「領域外の人から口出しされたくない」になってしまうのはよろしくない。自分が何をやっているのか、どうしてそれが大事なのか、自分のアタマで考え抜く良いきっかけを、他人のアタマがつくってくれるのが会議の良いところなのです。

効用２：ムダな仕事をしなくなる

お互いの意思疎通がきっちりできていないまま、それぞれの専門分野に任せて仕事を進めていくと、たいがい無駄が生じます。たとえば。。。

A（プログラマ）：「試作品、できたよ。」

B（プロダクト・オーナー）：「あれ、なんで右下からポップアップじゃないの」

A：「え、どういうこと？真下だっていいじゃない。」

B：「いや、右下からポップアップしてくるっていうのがこのツールのミソなんだから」

A：「それなら早く言ってよ～」

B：「えー、その話、してたよ。」

なんていうケース。

真相は、「Bさんが立ち話で伝えていたけど、Aさんはあまり重要な話と思っておらず聞き流してしまっていた」、かもしれませんし、「Bさんが伝えていたけどAさんが憶えていなかっただけ」かもしれませんし、「Bさんの単なる記憶違いで伝え漏れていた」のかもしれません。いずれにせよ、立ち話ベースだとこういったコミュニケーション・ミスは結構起きますし、テキストベースでのコミュニケーションでも数多の他の情報と一緒になると埋没するリスクが結構あります。

そう考えると、結局は会議をした方が無駄な仕事はしなくなるんです。というより、無駄な仕事をしないようにするために会議をする、と言った方が良いかもしれません。

効用３：仕事の納得感が生まれる

こういうケースを考えてみて下さい。

プログラマが、ただ単に、「そっち（A）の仕事ではなくてこっち（B）を先にして」とプロダクト・オーナーに言われたとします。でも、どうして「そっち（A）じゃなくてこっち（B）」なのか、なかなか納得できません。開発としてはA⇒Bの順番で行く方が効率良い、と考えているからです。

でも、例えばプログラマも参加する会議の中で、「実は試作品ユーザーの声を聴いてみるとBの機能開発の優先度が圧倒的に高い。プロコン考えてもB⇒Aの順番にせざるをえない。でも、開発にそれだけ負荷がかかるのなら同時進行で進んでいるCの開発は一部後ろ倒しにしよう。」なんていう議論があってB⇒Aとなったのだとしたら、プログラマも心から納得してBに取り組めます。そうした「仕事の納得感」というものはモチベーションや生産性にも大きく響いてくるはずです。

プログラマが単なる「歯車」で働いているんだったら話は別ですけどね。ただ、そういうベンチャーだと、プログラマの人も長続きしないのではないでしょうか。

効用４：リスク回避になる

効用１の応用編なのですが、自分と異なる視点が入ることによって、大きなリスクを回避することにも繋がります。

大体、顔を合わせて会議していると、何か意思決定した時に顔を見渡してみて、未だ腑に落ちていない表情をする人が出る時があります。そういう時に「何か引っ掛かっているの？」と考えを引き出してみると、自分がそれまで気付いていなかった落とし穴や視点が出てくることがある。

先日も、来月予定しているローンチ記念MeetUpについて、「いや、フタ開けてみたら5人しか来ませんでした、なぁんてことになったらどうしようかと思って」というフジワラさんの一言にギクッとさせられました。この何気ない一言が、そうならないように本当にベストを尽くすには何が必要か、万が一そうなってしまった時は何をするのか、を考える良いきっかけになったのです。

お互いに干渉せずに気持ち良く仕事ができている、というのは実は危ない兆候だと思っています。「う、嫌なこと言うな～（痛いとこ突いてくるな～）」という思いを時々しているような状況の方が健全で、会議というのはそういう場を提供するんですね。

大体、ベンチャーやろうなんて人は、僕も含めて「独りよがり」になりがちなタイプが多いので（笑）、よくよく注意した方が良いと思います。

ということで、今回は、メンバーが顔を合わせての会議はベンチャーだからこそやった方が良い、というお話でした。とはいえ、「やり方」を間違えると、かえって仕事の効率を悪くしてしまうのも会議の特徴。大きな組織ではよくある話です。

次回、良い会議をするために何が必要か、を考えていきます。

＊＊＊本稿へのご感想・コメントは是非画面右下のMessageLeafで！＊＊＊

　　　　　　　（ただし、iPhoneでは表示されません）