会議設計フレームワーク

概説
会議設計フレームワーク
総括

概説

現代のビジネスは会議で成り立っています。少なくとも必要条件です。会議の成否は事前設計により決まります。では、どのように会議設計をすべきでしょうか。

私は外資コンサル企業にてクライアントのビジネスにおいて必要となるプロジェクトを成功させるためのPMOを担当しています。日々会議の連続です。その中で、会議を成功させるための会議設計の方法論を自身の中で磨き上げています。今回は、私が実際に会議設計をする際に用いているフレームワークを紹介します。少しでも読者の方が会議設計を行う際の参考となれば幸いです。

本フレームワークでは、会議設計を設計レイヤーと期待適合性の2軸で考えます。

設計レイヤーとして要件定義、内部設計、外部設計の3層に区分けしています。要件定義でその会議に求められる条件を検討します。内部設計で協議すべき論点と、想定される仮説、それに至るロジックを検討します。外部設計で協議に必要な前提情報とその伝え方を検討します。ここで、各レイヤーの順序制約は希薄です。外部設計を最後にすべきではありますが、要件定義と内部設計の順序は問いません。最終的に全レイヤーが十分に整理されていることが目的です。会議とは基本的に一連の継続的な業務における、ある断面のワンショットであることが多いためです。つまり、多くの場合は会議設計を始める前に既に部分的に論点やロジックの整理が行われおり、従って思考財産のパケット化と言える行為であるためです。システム開発に慣れた方は違和感を覚えるかもしれませんが、あくまでアナロジーとして理解して下さい。

期待適合性として正常系と異常系を考えます。正常系は各設計レイヤーにおいて本来あるべきとして期待する理想型を設計します。理想的に会議が進行すると仮定した場合の理論値です。一方で異常系は例外処理を定めます。リスク管理であり、コンティンジェンシープランです。正常系の会議設計を事前に行なっている方は多いと思います。もちろん必要ですが、それだけでは十分ではありません。異常系の設計を入念に行うことが会議の異常終了を防ぐことに繋がります。さらに、十分なリスク管理は強力な精神的支柱となります。不安が晴れた状態でのファシリテーションは最高のパフォーマンスに繋がるでしょう。それに加えて、例外の中にこそ、隠された本来あるべき正常系の姿が見出されることも少なくありません。

		期待適合性
		正常系	異常系
設計レイヤー	要件定義	アジェンダ整理・会議後どのような状態になることを目指すのか・そのために何について協議すべきか・誰が必要なのか・必要な時間はどのくらいか	アジェンダ例外処理・アジェンダの過不足を指摘された場合の対処・必要な人が集まらなかった場合の対処・会議の目的が未達となった場合の対処
	内部設計	論定整理・何の問いに対して解を与えるべきか・得たい解は何か、解を導出するロジックは何か	論点例外処理・想定外の論点が提起された場合の対処・想定ロジックとは異なる方向に議論が発展した場合の対処・解を導出できなかった場合の対処
	外部設計	ストーリー整理・スコープをどのように伝えるか・必要十分な背景情報は何か、どう伝えるか・各論点をどのように提起するか	ストーリー例外処理・説明する情報の過不足を指摘された場合の対処

表1. 会議設計のフレームワーク

要件定義：アジェンダ整理

要件定義レイヤーでは、その会議に求められる条件、及びその例外処理を定義します。つまり、議事計画としてのアジェンダを整理するレイヤーと言えます。具体的には、会議の目的、議題、必要な人員、時間などを整理しておきます。例外処理としてアジェンダの過不足を指摘された場合や、必要な人員が集まらなかった場合、時間制約などにより会議の目的が未達となってしまった場合の対処などを整理しておきます。

会議の目的は「その会議の終了時点において目指すべき理想状態を設定すべき」です。誰に対して、どのような出力を引き出すのか、それは何故なのかを具体的に分解しておくべきです。アウトプットをFixして次の工程に移るために責任者と合意形成をするのか、それともある工程を進める上で必要となる情報を現場から出し切ることなのか。また、会議の要件を検討する際は、目的と手段の両軸で考えるべきです。例えば協議に必要な要員を検討するケースでは、あるアウトプットに関する責任者の合意を得たい会議であれば責任者はもちろん必要ですが、合意形成をする上で責任者に対して説明が可能となる情報のカバレッジを必要十分に満たすような各領域の担当者も必要でしょう。

では、上記のように描いた理想が叶わない場合はどうすべきでしょうか。それが例外処理となります。例外処理を考える場合は、どのような例外事象が発生しうるか、それが与える影響、影響を鑑みた上での対処法を整理します。例えば、合意を得たい責任者が急遽参加できないことが判明した場合、会議を開催しても無意味です。緊急性が高い場合はメールなどでの方法に切り替えるべきかもしれません。場合によってはより上位の責任者にエスカレーションすべきである場合もあるでしょう。こうした例外事象への対処を事前に整理しておくと、慌てて精度を落とすことなく落ち着いて行動でき、かつ事前回避策を取ることもできます。

内部設計：論点整理

内部設計レイヤーでは、論点とその例外処理を整理します。論点として、各議題において何の問いに対して解を与えるべきか、得たい解、解を導出するロジックなどを整理しておきます。例外処理として、想定外の論点が提起された場合の対処、想定ロジックとは異なる方向に議論が発展した場合の対処、解を導出できなかった場合の対処などを整理しておきます。　

会議では参加者に対して目的やアジェンダを伝えるのみで、「じゃあ、どうしましょう」では会議がカオスになるだけです。目的を達成するために答えるべき問いに分解しておく必要があります。それが論点となります。さらに論点に対する仮の解として仮説を持っておくべきです。人は何かを創造することよりも何かを批判することの方が圧倒的に能動的となります。また、仮説は議論に方向性を与える機能もあります。会議では完全に論理的に議論が進むとは限らず、ゼロから議論をスタートすると非合理な解が結論として収束してしまうこともあるので、仮説を持っておくことは非常に重要です。論点から仮説までに至る論理的な道筋がロジックとなります。また、アジェンダ整理と同様に理想型からのズレに対処する例外処理を検討しておくことも重要となります。

外部設計：ストーリー整理

外部設計レイヤーでは、会議のストーリーとその例外処理を整理します。ストーリーとして、アジェンダを伝える方法、アジェンダと論点の紐付け方法、各論点の協議のために必要十分な情報とそれを伝える方法などを整理しておきます。例外処理として、説明する情報の過不足を指摘された場合の対処などを整理しておきます。

アジェンダと論点、その例外処理を整理したのみで満足してはいけません。それを「どう伝えるか」も非常に重要です。また議論に臨むメンバーがが全員同様の知識を持っているとは限りません。議論に必要な背景知識があればそれを補う必要があります。議論を行う上で、形式的にも本質的にもお膳立ては重要になってくるのです。