システム開発の定例会議を改善する8つのプラクティス

システム開発における定例会議は、関係者の認識をそろえ、必要に応じて課題を議論し、意思決定する場にもなります。ただし、定例会議を唯一の意思決定の場にすると、次の開催日まで判断や対応が止まりかねません。顧客を含む多くの関係者が参加する会議では、目的と参加者に合った議題を扱い、その場で資料を読み始めたり、一部の担当者にしか関係しない議論を続けたりしないことが大切です。

本記事は、定例会議の目的を明確にし、会議待ちによる遅れを減らすための8つのプラクティスを説明します。PMIに掲載された実務記事、GitLabの公開ハンドブック、Atlassianの会議運営ガイドなどを参考にし、システム開発の定例会議への適用方法として整理しました。

プラクティス	定例会議で避けること	なぜ避けるべきか?
重要情報を定例会まで持ち越さない(No Surprises)	重要情報を定例会まで持ち越す	顧客が影響を確認する時間を失い、必要な調整や対応の開始も遅れるためです。
目的に合った議題と参加者を守る(Agenda Discipline)	目的や参加者に合わない話題を、その場で長く議論する	必要な議題を扱う時間が減り、関係しない参加者も待たせるためです。
資料を事前に共有し、不明点を確認する(Pre-read)	会議で初めて資料を読む、全員で読み上げる	各自で確認できる内容に、参加者全員の時間を同時に使うことになるためです。
集まる目的がなければ開催しない(No Agenda, No Meeting)	共有・議論・判断することがないのに集まる	会議で得られるものがなく、準備と参加の負担だけが生じるためです。
対応事項を定例会待ちにしない(Action Item Management)	定例会まで担当決めや作業開始を待つ	着手できる作業が会議待ちになり、定例会の開催間隔が進捗を制限するためです。
決定済みの内容と根拠を共有する(Decision Log)	決定済みの事項をその場で蒸し返す	同じ議論を繰り返し、決定済みの内容を前提に進む作業にも混乱を招くためです。
保留した論点を記録し、担当者へ引き継ぐ(Parking Lot)	論点を保留するだけで、記録や引き取り先を残さない	必要な確認が抜け落ち、同じ話題が繰り返し定例会に持ち込まれるためです。
責任者と決定者への確認経路を明確にする	定例会の出席者に判断を委ねる	判断権限のない人が決めたり、本来の決定者への確認が遅れたりするおそれがあるためです。

重要情報を定例会まで持ち越さない(No Surprises)

重要情報の共有を、定例会議の開催日まで待ってはなりません。 納期遅延、追加費用、重大な品質問題などは、把握した時点で共有し、必要な対応につなげます。既に把握していた重要情報を、定例会で顧客に初めて知らせることを避けます。

なぜ必要か

月曜日に分かった遅延を金曜日の定例会で初めて伝えると、その間にできたはずの影響確認や調整が進みません。顧客担当者も、定例会に出席するまで問題を知らず、その場で説明や判断を求められることになります。

重要情報の初報を定例会まで待つ運用は、関係者の準備時間と、問題へ対処するための時間を失わせます。

実践方法

重要な問題やリスクを把握したら、合意した連絡経路で顧客側の窓口や必要な関係者へ伝えます。判明している事実、想定される影響、未確認事項、次に情報を更新する時点を示します。解決策の完成を待たず、調査中の内容は調査中と明示します。

例えば「接続先の試験環境が利用できず、接続試験を開始できていません。リリース日への影響は確認中です。明日15時までに影響見込みを共有します」と伝えます。その後の検討や判断も、定例会を待たずに進めます。

定例会では、既に共有した問題の現在の状態と、前回の情報から変わった点を確認します。会議直前や会議中に重大な事実が判明した場合は、直ちに知らせ、必要に応じて定例会を打ち切り、必要な関係者による緊急対応へ移ります。事前に共有できなかったことを理由に、報告を先送りしません。

出典との対応

Project management from the middleの「No Surprises」は、チームメンバーがPMへ、マイルストーンに遅れる可能性を対処方法の確定前でも知らせるよう勧めています。

目的に合った議題と参加者を守る(Agenda Discipline)

定例会議では、目的、議題、参加者に沿って進めます。 解決策の検討や意思決定を行う場合も、必要な資料と決定権限を持つ人を事前に確認します。

なぜ必要か

進捗を共有している途中で「新しい認証方式を採用するか」という議論を始めると、その判断に関わらない顧客や他チームの担当者も待つことになります。詳しい人が出席しているという理由だけで議論を始めると、定例会が長時間の検討会になってしまいます。

実践方法

アジェンダには、共有・議論・判断する事項、参照する記録、必要な参加者、所要時間を記載します。例えば「決定済みのリリース方針について、対象機能と各部門への影響を確認する」とすれば、今回の議題の範囲が明確になります。

短い事実確認で解消できる不明点には回答します。予定外に原因調査や案の比較が必要になり、その場の参加者や資料では扱えない場合は、論点、引き取り担当、回答期限を記録して本来の議題へ戻ります。議題として準備され、必要な人と資料がそろっていれば、定例会で議論や意思決定を行えます。急ぐ判断は次の定例会を待たず、必要な関係者で進めます。

出典との対応

Atlassianの会議運営ガイドは、目的に沿ったアジェンダを共有し、脱線や技術的な詳細への深入りを抑えることを勧めています。同ガイドは、議論や意思決定も会議を開く有効な目的として挙げています。

資料を事前に共有し、不明点を確認する(Pre-read)

必要な資料を、定例会議の場で初めて読ませてはなりません。 参加者が事前に現状を理解し、不明点を確認できるようにします。

なぜ必要か

当日初めて資料を配布すると、内容を読む時間や説明を聞く時間を参加者全員で使います。資料が事前に届いていても、変更点や確認する範囲が分からなければ、準備に必要以上の時間がかかります。

実践方法

課題一覧や決定記録など、日々更新している情報へのリンクとともに、次の内容を伝えます。

• 前回からの主な変更点。
• 関係者に認識をそろえてほしい点。
• 必ず確認する範囲と、必要に応じて参照する詳細資料。
• 不明点の問い合わせ先と、コメントの記入先。

例えば「接続試験の遅延に伴う分割リリースは、顧客側の責任者が承認済みです。リンク先の決定記録で、対象機能と代替運用の範囲を確認してください」と案内します。ここで求めるのは決定内容の理解です。参加者が資料を開けるよう、アクセス権も確認します。

質問や認識の相違は、気づいた時点で課題票やチャットに記載し、担当者が随時対応します。定例会当日まで質問や回答をためておく必要はありません。定例会では、事前に解消できなかった不明点のうち、短い確認で認識をそろえられるものを扱います。

資料の共有期限は分量や確認に必要な時間を考慮して決めます。関係者全員へ詳細資料の読了を求めるのではなく、各自に必要な確認範囲を示します。直前の変更は差分を知らせ、既読の資料を最初から読み直す負担を抑えます。

出典との対応

GitLabのLive Doc Meetingsでは、事前資料を少なくとも24時間前に送り、質問も事前に記載する運用を示しています。24時間はGitLabの運用例です。

集まる目的がなければ開催しない(No Agenda, No Meeting)

明確な目的や議題がない定例会議を、予定が入っているという理由だけで開催してはなりません。 今回、関係者が同時に集まって認識共有、議論、意思決定を行う必要があるかを確認します。

なぜ必要か

全員が既に理解している進捗を順番に読み上げるだけでは、参加者の時間を使う理由がありません。定例会のための資料作成や待ち時間も含め、顧客と開発側の双方に負担が生じます。

実践方法

主催者は、文書やチャットで済んでいることと、同時に集まって扱う必要があることを整理します。会議で扱う事項が残っていなければ、開催を見送り、最新情報の参照先と問い合わせ先を知らせます。

例えば、複数部門に影響する変更について、対象範囲や現在の状態の理解に相違がないかを確認する必要があれば、その点に絞って開催します。解決策の議論や意思決定が必要な場合も、関係者と資料がそろえば定例会の議題にできます。急ぐ課題は次の定例会を待たず、必要な関係者で扱います。

参加者も、その認識共有が必要な人に絞ります。頻度と所要時間を見直し、確認が終われば早く終了します。開催を見送る判断期限や連絡方法は顧客と合意しておきます。

出典との対応

GitLabのWorking Groupsには、次回の会議にアジェンダがなければ中止することが明記されています。

対応事項を定例会待ちにしない(Action Item Management)

対応事項の担当者と期限を曖昧にしたまま、定例会を待ってはなりません。 作業が必要になった時点で内容、担当者、期限、完了条件を明確にし、着手します。

なぜ必要か

月曜日に必要と分かった確認を、金曜日の定例会で担当者へ依頼する運用では、毎回数日間の待ちが発生します。「顧客側で確認」「開発側で対応」という記録だけでは、誰が動くかも曖昧です。

実践方法

対応事項は発生した時点で課題管理ツールなどへ登録し、担当者が内容と期限を引き受けていることを確認します。

外部からの回答待ちで完了日を確約できない場合も、問い合わせを行う担当者と、状況を再確認する期限を決めます。期限超過や作業を妨げる問題は、定例会を待たずに関係者へ知らせます。

定例会では、対応事項のうち、関係者に影響する変更点や遅れに絞って状態を共有します。課題一覧を全件読み上げる必要はありません。その場で新しい不明点が見つかった場合は、確認を引き取る担当者と回答期限を記録します。

出典との対応

AtlassianのMeeting Minutes Templateでは、対応事項に担当者と期限を付け、会議の終わりに次の行動を確認することを説明しています。

決定済みの内容と根拠を共有する(Decision Log)

既に合意・決定済みの事項を、定例会で根拠なく蒸し返してはなりません。 決定内容と理由を記録し、関係者が同じ情報を参照できるようにします。

なぜ必要か

「分割リリースとする」という結論だけが伝わると、判断の背景を知らない人から同じ疑問が繰り返し出ます。また、正式に決まったことでも「次の定例会で皆に確認してから進める」という扱いにすると、定例会が実質的な承認待ちの場になります。

実践方法

決定した時点で、次の内容を記録し、影響を受ける関係者へ共有します。

• 決定を識別するID、日付、決定者。
• 決定した内容と適用範囲。
• 判断時の前提、比較した選択肢、採用した理由。
• 決定に伴う影響や条件。
• 有効、再検討中、別の決定で置き換え済みなどの状態。

定例会では、この記録を参照し、決定した内容と影響範囲について理解の相違がないかを確認します。決定理由への質問には記録をもとに回答し、正式な手続きで決まった事項の再承認は求めません。

前提の変化や判断の誤りが見つかった場合は、記録と新しい事実を決定者へ速やかに伝えます。再検討は必要な関係者で行い、変更時は旧記録を残して新しい決定へリンクします。定例会の全員で議論をやり直したり、次回の定例会まで再検討を待ったりしません。

出典との対応

Michael NygardのDocumenting Architecture Decisions(2011年)では、アーキテクチャ上の決定について、背景、決定内容、状態、結果を記録するADR(Architecture Decision Record)を説明しています。決定を変更した場合も旧記録を残し、置き換え先を示す方式です。

保留した論点を記録し、担当者へ引き継ぐ(Parking Lot)

その場で扱わない論点を、「別途確認」とするだけで終えてはなりません。 予定した議題や参加者で扱える範囲を超える話題は、その場で議論を続けず、論点と引き取り先を記録して本来の議題へ戻ります。

なぜ必要か

リリース方針の共有中に、管理画面の改善要望が出たとします。その場で詳細な議論を始めると、関係しない参加者も待つことになります。一方、「それは別途」と切り上げるだけでは、誰が何を確認するのかが残りません。必要な確認が抜け落ちたり、対応状況が分からず次の定例会で同じ話題が持ち出されたりします。

実践方法

詳しい確認や話し合いが必要な話題が出たら、その場で解決しようとせず、議事録に次の3点を残して本来の議題へ戻ります。

• 後で確認する内容。
• 確認を担当する人。
• いつまでに状況を知らせるか。

例えば、管理画面の検索条件を増やしてほしいという要望が出たら、「佐藤さんが必要な検索条件を確認し、翌営業日までに田中さんへ伝える」と記録します。要望を受け入れるか、どのように実現するかは、必要な関係者で別途話し合います。既に課題一覧などへ登録している内容であれば、そのリンクを議事録に載せます。

会議を終える前に、後で確認する内容に担当者と期限が記録されているかを確認します。担当者は会議後に必要な人へ連絡し、確認や検討を進めます。結果や途中経過は議事録や課題一覧から分かるようにし、関係する人へ知らせます。次回の定例会まで、確認や連絡を待つ必要はありません。

急いで対応すべき重大な問題は後回しにせず、直ちに担当者や判断できる人へ連絡します。必要であれば定例会を終了し、関係者による緊急対応へ切り替えます。

出典との対応

Atlassianの会議運営ガイドでは、会議の範囲外のアイデアや質問をParking Lotへ記録し、後で必ずフォローすることを説明しています。

責任者と決定者への確認経路を明確にする

定例会議だけを意思決定の場にせず、責任者と決定者を明確にして必要なときに判断を進めます。 誰へ確認すれば進められるかを、日頃から明確にしておきます。

なぜ必要か

「定例会には顧客側の担当者がそろうから、そこで聞く」という進め方では、確認のたびに次の開催日を待つことになります。出席している人が、その判断に必要な権限を持っているとも限りません。

実践方法

まず、業務や課題ごとの確認窓口と、判断を依頼する決定者を共有します。定例会に出席しているという理由だけで、その人へ判断を委ねないようにします。

役割表に加えて、連絡先、問い合わせ方法、不在時の確認経路を共有します。役割表を作るだけで権限が与えられるわけではないため、顧客側の承認手続きや契約上の決定範囲と整合させます。

作業や成果物の責任分担を整理する(RACI)

RACIは、作業や成果物ごとに、誰が実行し、誰が結果に責任を持つかを整理する手法です。相談する相手と進捗や結果を知らせる相手も明確にし、日々の作業で必要な確認を進められるようにします。

役割	意味
Responsible	作業を実行する人。
Accountable	作業や成果物の結果に最終的な説明責任を持つ人。
Consulted	実行にあたり意見や助言を求める人。
Informed	進捗や結果を共有する人。

出典との対応

AtlassianのRACI解説は、作業ごとの実行責任、最終的な説明責任、相談先、共有先を整理しています。

意思決定を進める役割を整理する(DACI)

DACIは、特定の判断が必要になったときに、誰が意思決定を進め、誰が最終的に決めるかを整理する手法です。判断材料を提供する人と決定結果を知らせる人も明確にします。

役割	意味
Driver	必要な情報や関係者を集め、期限までに意思決定を進める人。
Approver	最終的な意思決定を行う1人。
Contributors	専門知識や判断材料を提供する人。
Informed	決定結果を共有する人。

例えば、リリース方針の判断では、開発側のPMがDriverとして対応案と判断期限を整理し、権限を持つ顧客側の責任者へ確認を依頼します。業務担当者や技術担当者から必要な情報を集め、顧客側の承認手続きに従って決定します。定例会で判断する場合も、必要なやり取りや準備は開催日を待たずに進めます。

決定後は影響を受ける人へ速やかに共有します。定例会では、誰が何を決め、誰が対応中かを確認します。未決の事項は、判断する人、確認を進める人、回答予定を共有します。決定者と必要な情報がそろえば定例会で判断でき、そろわない場合や急ぐ場合は必要な関係者で別途進めます。

出典との対応

AtlassianのDACI Playbookは意思決定の役割を定義し、Approverを最終判断する1人としています。

まとめ

定例会議は目的に沿って進め、必要なら議論や意思決定も行います。資料は事前に確認できるようにし、当日は変更点と必要な論点を扱います。文書やチャットで用件が済む場合は開催を見送ります。

課題の議論、意思決定、作業の実行は、定例会の開催日だけに結びつけず、必要な関係者で随時進めます。定例会で新たに見つかった論点も、記録して担当者へ引き継ぎ、次回の開催を待たずに確認します。8つのプラクティスを通じて、顧客を含む関係者の時間を守り、定例会の開催が進捗の条件になることを防ぎます。

参考資料

• PMI - Relationship Building: 顧客への継続的な情報共有と、不意打ちとなる情報提示の回避。
• PMI - Project management from the middle: No Surprisesと、遅延の可能性の早期連絡。
• Atlassian - How to run effective meetings in the era of hybrid work: アジェンダに沿った進行とParking Lot。
• GitLab - Live Doc Meetings: 資料の事前共有と参加者の準備。
• GitLab - Working Groups: アジェンダのない会議の中止。
• Atlassian - Meeting Minutes Template: 対応事項の担当者と期限の記録。
• Michael Nygard - Documenting Architecture Decisions: 決定の背景・状態・結果を残すADR。
• Atlassian - Understanding and using RACI charts: 作業と成果物の責任分担。
• Atlassian - DACI Decision-Making Framework: 意思決定を進める役割と決定者の明確化。