円滑なERP導入を支える会議間の連携と運営ポイント
プロジェクトマネジメント計画にはコミュニケーションプランがあり、その中心となる活動として「会議」が位置づけられます。特に、ERP導入のように複数部門を横断するプロジェクトでは、以下のように多くの会議が設置されるでしょう。
- ステコミ（ステアリングコミッティ）
- 月次報告会
- 週次定例会
- 課題検討会
- 横串会議
- PMO定例会
- リスク検討会
- 緊急会議（必要に応じて随時開催）
本記事では、これらの会議体がどのようにつながり、どのように情報をエスカレーションしていくかを解説します。
会議間の関係
ERP導入のプロジェクトでは「個人の課題 → チームでの共有 → プロジェクト全体での検討 → 全社レベルでの対応」という順番で会議体を引き上げていきます。ここでのポイントは「課題の影響度に応じて、検討の場を適切に切り替える」ことです。特に「気づきとフィードバックの仕組み」を通じて、個人対応で終わらせず、上位レイヤーへスムーズにエスカレーションされることが重要になります。
- 個人対応：課題が起票されるとまず担当者が割り当てられ、個人で対応できるかを検討。
- チーム対応：個人で解決が難しい場合は「課題検討会」でチームとして対応策を協議。
- プロジェクト全体対応：チームで対応しきれない場合、横断的に影響する課題やリスクは「横串会議」や「PMO定例会」で全体方針を検討。
- 全社レベルの意思決定：月次報告会で経営層を含むマネジメントへ報告し、最終判断をステコミで下す。
このように、課題やリスクは段階的に検討の場を上げていくことで、対処漏れを防ぎつつ、必要なレベルで意思決定が可能になります。なお、「プロジェクトに関する課題はプロジェクトメンバー内で対処すべき」といった考えは持たない方が良いでしょう。いずれ全社レベルの活動となるわけですから、多くのステークホルダーを巻き込みながら対処していく方が得策です。
また、課題が個人で留まらず、適切な会議体へとエスカレーションされるためには、管理ツールを上手に活用することも重要です。課題にアラート項目を設けて、チームを横断して議論したいことやマネジメントへの依頼事項など担当者から容易に発信できるようにし、プロジェクトメンバー全体が瞬時に気づいて対応の準備に入れる仕組みを整えるのです。具体的な管理方法については、以前に掲載した「SaaS ERPのプロジェクトダッシュボード」をご参照ください。
PMO定例会とリスク検討会の関係
一方、リスクに関しては、PMO定例会で、「バッドニュースファースト」の方針に基づき、今後起こりうる問題を事前にマネジメント層に報告し、前向きに対策を講じます。なぜ週次定例会ではなくPMO定例会で扱うかというと、バッドニュースは人によっては「悲観的」に受け止められやすく、プロジェクトメンバーのモチベーション低下を招く恐れがあるためです。そこで先ずはマネジメント層だけが参加するPMO定例会でリスクとして取り上げ、優先的にリスク対応を検討するのです。
PMO定例会で挙がったリスクは、まずはリスク管理表に登録し、「リスク検討会」で詳細を検討します。リスク検討会にはプロジェクトメンバーも参画しますが、この段階では既にリスク対策案が出ているため、メンバーは「悲観的」になるよりも「この対策でリスクを軽減しよう」と前向きに取り組みやすくなります。
なお、月次報告会ではリスクも重要な議題となるため、リスク検討会は月次報告会の前に開催することが望ましいです。リスク検討会で事前に検討・対策案を整理しておくと、月次報告会において速やかに意思決定や経営層の判断を仰ぐことができるからです。
さらに、リスク管理で洗い出された軽減策や発生時対策（コンティンジェンシープラン）は、課題として再度起票し、「課題検討会」で詳細を詰めていく流れとなります。
運営ポイント
- 週次 → 月次 → ステコミという“階層”を踏まえた会議運営
- 課題は週次の定例会や課題検討会で一次的に検証し、解決不能なら月次、さらに解決不能ならステコミへ。
- 月次報告会からステコミへの流れは、いわば“最終決定プロセス”として機能します。
- 緊急会議は、この通常フローで対処できない“突発性・重大性”が高い場合にのみ招集する。
- 気づきとフィードバックで個人対応に依存しない仕組みづくり
- 図中では「課題発生 → 担当者アサイン → チーム → 横串会議 → プロジェクト全体 → ステコミ」と流れが示されています。
- 途中でアラートを上げる仕組みが整備されていることで担当者任せにならずに、課題の共有、エスカレーションが進みます。
- リスクはまずPMO定例会で扱い、リスク検討会で詳細検討
- 現場メンバーに“バッドニュース”をむやみに広げるのではなく、先にPMO（マネジメント層）で慎重に議論しておく運営が大事です。
- 対応方針が固まってから現場に共有することで、メンバーが前向きに動きやすくなる利点があります。
時間通りに会議を進行するために
近年は会議を減らす機運が高まっており、以前は2時間枠だった会議が30分単位で設定されるケースも増えています。だからこそ、会議の事前準備、役割の明確化、結果のフォローがこれまで以上に重要です。以下に、時間通りに会議を執行するための具体的な施策を紹介します。
- 議題は事前に持ち寄る
- PMだけに任せず、メンバーもあらかじめ、「会議タスク」に議題を挙げておく。
- 議題には進行役と所要時間を明記し、各人が「何をどれくらい話すのか」を把握できるようにする。
- 会議中の進め方
- リモート会議の場合、発言時には部署と名前を名乗ることで、参加者全員が発言者を認識しやすくする。
- 議事をリアルタイムに共有(画面共有やドキュメント共有など)し、参加者が常に今どのトピックを扱っているかを把握できるようにする。
- 予定された議題以外が話に上がったら、“今”話すことなのかを適切に判断する。（基本的に次回定例会の議題にする。）
- ラップアップ（まとめ）
- 会議で上がった課題を整理し、担当者と期日を明確にする。
- 時間内に議論しきれなかった議題は、次回以降の議題としてリスト化しフォローする。
- 次回の予定を案内して、参加者のスケジュール調整をしやすくする。
- 継続的な振り返り
- 会議後に「予定通り進行できたか」「決定事項や次のアクションに漏れはないか」を振り返る。
- 必要に応じてルールをアップデート（プロジェクトマネジメント計画書を更新）することで、常に会議体を最適化していく。
このように、事前準備、進行、ラップアップ、振り返りの一連の流れを徹底することで、時間通りに会議を進められるだけでなく、先延ばしにしないチーム体制を築くことができます。
会議に参加しやすくするために
ERP導入プロジェクトでは、ヒアリングやトレーニング、実機検証など多くのセッションが行われます。実務と兼任しているユーザーもこれらに参加しやすくするためには、会議の時間帯や案内方法を工夫する必要があります。例えば、勤務時間が9:00〜18:00の企業では、午前のセッションを10:00〜12:00、午後のセッションを13:00〜15:00および15:00〜17:00と設定するのが一般的です。そのため、会議を9:00〜10:00や17:00〜18:00に設定すれば、他のセッションと重ならず、スムーズに開催できるでしょう。さらに、プロジェクト開始時に曜日と時刻をあらかじめ決めておき、プロジェクトメンバー全員と合意を取っておくことで、プロジェクトメンバー全員が参加しやすくなります。
緊急会議の扱い（最小限にするポイント）
通常の会議スケジュールでは対応しきれない突発的かつ重大なインシデントが発生したときのみ、緊急会議を招集します。むやみに開催するとメンバーの稼働やスケジュールに大きな影響が出るため、以下の基準を設けるとよいでしょう。
- 放置するとプロジェクト全体に甚大な被害や納期遅延を招く
- 既存の会議体を待っていたら手遅れになる
- 主要な意思決定者が短時間でも集まれる
このような条件を満たす場合のみ緊急会議を実施し、決定した対応はその後の定例会等で正式に共有・フォローアップする形を取ります。
まとめ
- 課題のエスカレーションフロー：「課題検討会 → 横串会議 → 月次報告会 → ステコミ」という段階的な検討で、課題を確実に解決へ導く
- リスクのエスカレーションフロー：「PMO定例会 → リスク検討会」で対策案を決定し、必要に応じて課題として再度起票
- 緊急会議：通常の会議体で対処できない緊急度の高い案件に限定して開催。プロジェクト全体への影響と実施基準を明確にしておくことが重要
ERP導入のような大規模プロジェクトでは、会議体の役割を明確にし、それぞれのタイミングと目的に応じて情報を連携していくことで、プロジェクト内のコミュニケーションが円滑になり、チーム間の風通しが良くなります。各会議が互いに連携しながら意思決定を行い、全体の進行をスムーズに保ちながら確実に課題やリスクへ対応できる体制を整えましょう。
以上が、円滑なERP導入を支える会議体の連携と運営ポイントのまとめとなります。ぜひ、参考にしてみてください。
