佐藤将之『amazonのすごい会議』

anazonを例として、効率的な会議について記したもの。まとまりよく読みやすい、参考になる一冊。本書が扱う、開催する意味がある会議は意思決定会議、アイデア出し会議、進捗管理会議の三つ。意味が薄いとされて対象外となっているのは、情報伝達会議。情報伝達会議は基本的にやる必要はないとされる。特に定例とされている情報伝達会議はさらに意味がない。こうした会議の代わりに、伝達すべき相手に直接伝えればいいだけだ。むしろやるべきはone-on-oneのミーティング。アマゾンでは毎週、または隔週で部下と上司が行っている(p.23-27)。

まず意思決定会議。この会議にはなによりも資料が必要とされる。良い会議資料とは、(1)会議の趣旨、目的が明確である、(2)少ない労力、少ない時間で読むことができる、(3)いつ誰が読んでも確実に伝わることが条件(p.35)。特に後ろ二つの条件のために、有名な話だがamazonではパワーポイントの利用、ことさら箇条書きを禁止している。代わりにWordによる文章（ナラティブ）が推奨される。解釈の違いが生まれないように、その場で読んですぐに理解できる文章の形式が求められている。この要請はまた、きちんとした文章を書くには推敲を重ねる必要が出てきて、推敲してじっくり検討するプロセスを経ることそのものも期待している(p.36-41)。

会議を開始してから出席者全員が15分程度で読み切れるよう、会議資料は簡単な報告なら（日本だとA4、アメリカではレターサイズ）1ページ、より大がかりなもの（年次予算や大きなプロジェクト）は6ページに収めるものとされる。ただし添付資料の量はいくらでもよい。作成者は、6ページを書くには通常でも2日、長い時には一週間以上を推敲に要する(p.44-54)。

計画や提案を行う資料では、最初にゴールを決めて、それに向けて何をすればいいかを考える(Thinking Backwards, Working Backwards)ことが求められる。よくある積み上げ式では、何度もインベーションを起こし、大きく成長することはできない(p.59-61)。特に新規プロジェクトが立ち上がる時に用いられるのが、これも有名な、プレスリリース形式の資料だ。プレスリリース形式の資料は、読み手が受け入れやすい。新規プロジェクトの立ち上げはステークホルダーに理解してもらうことが重要なので、プレスリリース形式の資料とする意味がある。プレスリリースは、外（顧客）の視点に立って書かれる。企業内の自分たちがこうしたいではなく、顧客がどういう問題を感じていて、提案をどう受け止めるかを表現する。さらにFAQやユーザーズマニュアルも作成することで、提案する商品やサービスがどのようなものかがクリアになり、ステークホルダーにも説明しやすく納得を得やすくなる(p.64f, 71-74)。

意思決定会議ではオーナーの役割が決定的に重要だ。まず進行役を別途用意するのではなく、オーナーが進行役を務めること。アウトプットに責任を持つ人、プロジェクトリーダーが方向性を示して議論をリードする方が、会議の方向性が定まり、効率的な質の高い意思決定が可能になる。オーナーの役割は進行役・ファシリテーションだけでなく、参加者の選出と招集、議事録の配布、会議後の決定事項の進捗確認を含む(p.84-87)。ファシリテーションの技法は数多くあるが、本書ではアマゾンで言われていた三つの技法を取り上げる。(1)リフレーズ。発言者の言葉の足りない部分を細くしたり、言い換えたりする。これによって、発言が少ない人の意見を議論の場に引き出す。(2)パーキングロット。ホワイトボードの片隅に線を引き、本題から外れる意見をメモする。本題からずれた話をする人の意見を尊重し、嫌な気持にさせずに、論点を引き戻す。(3)バルコニー。議論が熱を帯びているときに、冷静で客観的に議論を見渡す。実際に椅子から立ち上がってみる(p.9-105)。

アイデア出汁会議は日本では少なすぎるので、もっと活用すべしと書く。ただしブレストが有効なのは、ソリューションがよく分からないときに限られる。解決補の方向性がある程度見えているのなら、普通に意見を出して現実的に具体策を詰めていく方がよい。ブレストは5～6名で行い、ホワイトボード（オフサイトの場合は持ち帰れるように模造紙）、ポストイットを使う(p.122-128)。また通常のオフィスの会議室ではなく、研修施設やリゾート施設を用いて行うオフサイト・ミーティングも効果的。ただし、オーナーが決まったことをリスト化し、フォローアップしないとただの楽しい旅行で終わる。チームビルディングが主目的ならいいが、経費を使っているにはもったいないだろう(p.147f)。

進捗管理会議は何よりもKPIの設定が必要。最終的なゴールであるKGIと区別し、タスクを行う人がコントロール可能な粒度まで落とした定量的なKPIの設定が必要。そして、長くても一週間単位で確認したPDCAサイクルを回す。KPIはプロジェクトが安定してきて異常値が起こらない状況になったら、見るのをやめることも大切。不要な数字やレポートを減らすようサポートするのは上司の役割だ。メンバーがKPIの監視を止めるのは難しい(p.172-174)。そして、進捗管理会議の最後の締めとして、どんな失敗やミスがあり、何が成功したのか（ハイライトとローライト）、どうすれば次に生かせるかを学習するポストモーテム（事後検証）を必ず行うべし。これは犯人探しではなく、次に向けた組織学習の機会となる(p.177f )。

こうしたamazonの会議のやり方は、暗黙の前提になっている価値観に基づいているからこそうまく機能する。この価値観は14か条のリーダーシップ理念(Our Leadership Principles; OLP)にまとめられている(p.182-185)。OLPはリーダーだけでなく、amazon社員の仕事の進め方の基本となる原則であり、人事評価にも使われる。リーダーはメンバーのOLP上の弱みを指摘するだけでなく、OLPに沿った行動を強化したり、伸ばすために何をすればいいかを考えることが求められる(p.203)。OLP14か条のうちどれか一つをまず取り入れようとするなら、Ownershipから取り組むべき。会議の出席者がそれぞれオーナーシップをもって臨めば、必要ない人は会議に呼ばれないし、決定したことに主体性を持って取り組める(p.187)。

すぐに活かせる会議の効率化のポイントが最後にまとめてあげられる。会議は行う目的がなければ直前でもキャンセル可能として、そもそも会議の数を減らす(p.211f)。出席者は必須と任意を分けて、出席者を絞りつつも「俺は聞いていない」と後から文句を言う人を減らす(p.216)。そしてオーナーは会議のゴールの確認と、タイムキーピングを徹底して、会議の時間を減らす(p.221)。

全部ではないにしても個々のポイントには、どの組織でも取り入れることができるものがあるだろう。たしかに日本の企業は会議出席者が多すぎる。ただし日本の会議が大人数になるのは、誰がどの仕事をするのか明確には決まっていないからであり、本当の意味では会議の仕組みだけ変えても不十分であり、人がどう仕事をするかを見直さなければならない(p.220)。