会議は「設計」するもの

ビジネスオペレーションの「リズム」をつくるのが定例会議

私が在籍していたマイクロソフトという会社では、会社全体のビジネスオペレーションが「設計」されていました。

年度の目標設定はいつから始まり、それが数値目標として確定するのはいつか。どのレベル（階層）の人が、どれくらいの頻度で、なにをレビュー（進捗確認）するのか。

こういったビジネスオペレーション上のマイルストーンや定期的なミーティングの全体像を、リズム オブ ビジネス（Rhythm of Business）、略してROBと呼んでいました。

リズムという表現がおもしろいですよね。ROBを設計すると、会社全体やチーム全体のリズムが決まるわけです。

会社全体のリズムを上から決めていく

まずは、会社全体で決まっている会議や毎年必ず実施することを明らかにしていきます。例えば、

• 年度の目標設定は年度末にやり、新年度開始後2週間くらいで目標予算が確定する。
• 半期末で経営層を交えた大きめのレビュー（進捗確認）をする。
• リーダー・マネージャーレベルでは月次でレビュー（Monthly Business Review = MBR）を実施し、四半期でしっかりめのレビュー（Quarterly Business Review = QBR）をする。
• 現場レベルでは、週次で営業会議を実施する。

会議だけでなく、イベント的なことも含めます。

年度初めに決起集会（キックオフ）をやり、四半期に1回はお疲れ様会、年度末には納会をやる。新入社員歓迎会があったり、社員総会があったり、社員旅行があったり、忘年会もありますよね。

こういった会社全体のリズムは上から決めていくのが大切です。全体が決まっていれば、現場レベルの計画も立てやすく、手戻りや二度手間を減らせます。

直前になって日程調整すると、理想的なタイミングで開催できなかったり、欠席者が増えたりしますが、事前に日程を決めておけば直前での調整の手間も省けますし、出席率も高くなります。さらに、一部の時期に全社的なイベントが重なることを防ぎ、繁忙期を分散することもできます。

会議を設計するときに決めること

リズム（ケイデンスと呼ばれることも）とともに、参加者、目的・内容、時間配分、ミーティングオーナーを決めていきます。

参加者と目的・内容が揃ってないと、肝心な部分が煮詰まらなかったり、決めきれなかったりするので、セットで考えるのは欠かせません。時間配分は、頻度が少なければ長めでもいいけど、頻度が多いなら短めにするなど、バランスを考えます。

ミーティングオーナーをちゃんと決めておくのも大事です。アジェンダを決めたり、開催要否を決めたりする最終判断はミーティングオーナーの責任です。

会議を「なんとなく」設定している会社・チームが多すぎる

「なんとなく」で設定すると、会議がムダな時間になりやすい

チームで仕事を進めるためには不可欠な会議ですが、定例会議（チーム定例）を「なんとなく」で設定しているケースがあまりにも多い。

これは本当にもったいないです。

チームの単位はさまざまですが、会社にはたいてい複数の階層があるので、小チーム（課とかグループとか）での定例、大チーム（部門とか事業部とか）のリーダークラスの定例、さらに事業本部リーダークラスの定例、組織横断の定例など、あなたの会社にも多くの定例会議があると思います。

「なんとなく」で設定していると、時間が経ち、状況が変化するにつれて、出席者と議題がズレていき、当初は有意義だった会議も、無駄な時間になっていくことがあります。

会議が下手だと、社員のやる気もアウトプットの質も下がっていく

また、定例会議の前の事前打ち合わせや、決まったアクションの詳細を詰めるための打ち合わせと、放っておくと会議はドンドン増えていきます。会議が増えれば実行の時間が減ります。実行の時間が減れば、効果が出るのが遅れたり、そもそもの成功確率が下がったり、コストが増えたりと、何もいいことはありません。

この状況が蔓延すると、社内に会議への拒否反応が生まれ、会社や仕事に対する社員のエンゲージメントが下がり、主体的に関わらなくなります。主体的に関わらない社員が生み出すアウトプットのクオリティは当然下がっていき、やがてお客様や取引先にまで悪影響を与えます。

そんな大袈裟な…と言い切れるでしょうか？

会議を設計すると仕事が進みやすくなる

「なにを得たいのか」を考える

「設計」というからには、目的やゴールがあります。

こういうものが欲しいから、こうつくる。ビルをつくりたいから、ビルの設計をする。橋をつくりたいから橋の設計をする。素敵な家が欲しいから家を設計する。当たり前ですね。

でも、多くの会議はそういう風に設計されていないのです。

ある人はビルが欲しいと思い、別の人は家が欲しいと思いながら、会議に出ている。設計せずに「なんとなく」で会議をしていると、そんなことが起きていても不思議ではないのです。

何が欲しい、何を得たいから、どんな会議をするのか。それを考えるのが、会議を設計するということです。年間の目標を立てたり、3ヶ年の中期経営計画を立てたなら、それに向かって仕事を進めるために会議を設計するのです。

よくない会議の典型的なパターン

よくない会議の典型的なパターンは、「とりあえず状況を共有して」というやつです。これは2つの意味でダメですね。

ひとつは、これを聞いてる場合はたいてい、目標やゴール、具体的には期待する成果があいまいだから。

進捗とは、目標やゴールに対する進み具合という意味です。目標とは、アウトプットと期限のセットです。「いつまでに、〇〇が△△になっている」という目標が参加者全員にとって明らかなときは、「とりあえず状況を共有」という聞き方にはなりません。「〇〇はどこまで進んでる？」とか「今月△△まで行くために、なにか問題ある？」という具体的な聞き方になるはずです。

もうひとつのダメな理由は、状況把握、状況確認のために会議の時間を使うのは、あまりにももったいないから。

仕事は「見える化」しておくのが前提で、それを踏まえて相談であったり、議論であったり、意思決定に時間を使うのが、多くの参加者を集める会議の時間の有意義な使い方です。

「いつまでに、〇〇が△△になっている」という目標達成を確実にするため、直面している問題を相談したり、解決策を議論したり、むずかしい判断をしていく。また、目標を達成するために関係者間の連携をスムーズにする。このように年間の会議を設計していけば、仕事は進みやすくなります。

意味がなくなった会議はやめてもいい

事業も組織も「生き物」なので変わっていく

そうは言っても、ビルや橋と違って、事業は生き物なので、進めていくうちに状況が変わります。大きな組織でもそうですが、スタートアップやベンチャーのような小さな会社やチームでは、3ヶ月から半年もすると状況がガラリと変わるなんてことはよくある話です。

そこで大事なのが、「定期的に見直す」ことです。

先述したように、当初は有意義だった会議が、やがて意味のないモノになってしまうのは、よくあることです。それを放置しておくと、「ウチの会社、やたら会議が多くて、しかも意味ない」という認識が広がってしまいます。

積極的に会議を見直す、やめることで、組織は強くなる

そういう兆しが出てきたら、躊躇なく見直します。

慣れないうちは、見直す時期を決めておくと良いでしょう。一般的には最低でも1年に1回、来年度の計画を立てるときには要不要を見直すことをおすすめします。状況の変化が激しい会社なら、半期に1回か、四半期に1回くらいの頻度で見直してもいいかもしれません。

また、見直しを提案する役割の人を置いておくという手もあります。支援先では私がその役割を担うこともあります。

上が積極的に会議を見直せば、会議ってやめていいんだ、という共通認識ができあがります。現場でも主体的に会議を見直し、取捨選択できるようになります。こうなれば、組織として1段階強くなったといえるでしょう。

定例会議を設計するためのツール

人類にとって会議はまだ必要なもの

会議が嫌いな人は多いですし、メディアでも定期的に会議が目の敵（かたき）にされますが、残念ながら人類はまだテレパシー能力を獲得してないので、対話なしでスムーズに意思疎通できることは稀だと思います。

自分だけで何かを進めるなら打ち合わせは不要ですが、多くの人を介してコトを進めようとすると、会議という対話の場は必須です。

作業を進めるには個人の時間が必要ですが、何かを決めるとき、決めたことを伝えるとき、チームをつくっていくときなど、文脈の共有が大事な場面では対話（会議）は欠かせません。

言語化が得意な人たちばかりのチームで、テキスト化（文章によるコミュニケーション）が徹底されてる環境ならいざ知らず、普通の人が集まったら、会議なしでどうやって議論したり、認識を合わせたり、意思決定事項をすり合わせるのか、私には想像つきません。

定例会議の設計テンプレートをつくりました

では具体的に、どうやって「設計」するのか。実際にやってみればすぐにわかりますが、実はそれほどむずかしくありません。この記事で解説した内容を決めていき、関係者で確認・合意する。そして、決まった内容を公開するとともに、カレンダーに設定する。これだけです。

とはいっても、とっかかりがあった方がいいですよね。そこで、定例会議の設計テンプレートをつくりました。

テンプレートは2つのパーツでできています。

目的・内容、頻度、参加者、時間配分、ミーティングオーナーを設計していくパーツと、それらを年間のリズムとして表現するパーツです。

見れば一目瞭然なので詳しい解説は不要だと思いますが、もし疑問や不明な点がありましたら、遠慮なくお問い合わせください。