開発中の進捗管理と定例会議の進め方｜発注者向け
システム開発中の進捗管理と定例会議の進め方を発注者向けに解説。会議の頻度と議題、進捗報告で見るべき点、議事録を残す理由、遅れが出たときの判断を紹介します。
開発会社に発注したあと、「進捗は順調です」という報告だけで本当に大丈夫なのか、不安になる発注担当者は少なくありません。システム開発の進捗管理は、開発会社だけの仕事ではなく、発注者が定例会議で何を確認するかで結果が変わります。この記事では、定例会議の進め方（頻度・議題・参加者）、進捗報告で見るべき指標、議事録を残す理由、遅れが出たときの判断を、発注者の立場から説明します。
システム開発の進捗管理と定例会議の基本
まず押さえておきたいのは、予定どおりに終わるシステム開発は多くないという事実です。日本情報システム・ユーザー協会（JUAS）の調査では、2022年度に「予定どおり完了」したプロジェクトは、100人月未満の規模でも32.4%でした。500人月以上の規模では「予定より遅延」が51.9%にのぼります（企業IT動向調査報告書2023）。
遅れはある程度起きるものとして、早く気づき、早く判断できる仕組みを作るのが進捗管理の目的です。その中心になるのが定例会議です。
定例会議の基本形は次のとおりです。
ポイントは、発注者側に「その場で判断できる人」を入れることです。窓口担当だけが出席し、決定を毎回持ち帰ると、それだけで1週間ずつ遅れていきます。
決裁者が毎回出席するのが難しい場合は、窓口担当にどこまで決めてよいかを社内で決めておきます。たとえば「画面の文言や項目の並びは窓口担当が決める」「費用や納期に影響することは決裁者が決める」と線を引いておくと、持ち帰りの回数を減らせます。
定例会議とは別に、月1回程度、決裁者が出席する報告会を設けるのも有効です。週次の細かい進捗ではなく、全体の遅れ、費用の見通し、大きなリスクだけを報告してもらい、判断が必要なことをまとめて決めます。
定例会議の議題と進め方
議題は毎回同じ順番にすると、確認漏れが減ります。次の順番がおすすめです。
- 前回の宿題（ToDo）の確認
- スケジュールの確認（予定と実績の差）
- 課題・リスクの確認
- 今回決めるべき論点
- 次回までの宿題と担当者
「今回決めるべき論点」には、論点ごとに担当者と時間を割り当てておきます。全員で何となく話し合う時間が長くなると、決めるべきことが決まらないまま終わります。
アジャイル開発（短い期間で作って確認する進め方）の場合は、「前のスプリント（1〜2週間の開発単位）で何をリリースしたか」「今のスプリントの進み具合」「やることリスト（バックログ）の優先順位」を扱うのが一般的です。進め方の違いはウォーターフォールとアジャイルの違いで説明しています。
仕様に関する質問は、定例の場だけでなく日常的にも出てきます。開発会社のPMに質問の窓口を一本化してもらい、まだ決まっていないことは課題管理表に載せて管理すると、「言った・言わない」が起きにくくなります。
進捗報告で見るべき指標
「8割できています」という報告は、発注者には判断材料になりません。何をもって8割なのかが分からないからです。進捗報告では、次の点を確認してください。
特に見落としやすいのが最後の「発注者の宿題」です。遅れの原因が開発会社ではなく、発注者側の確認待ちや資料の未提出にあることは珍しくありません。
もう一つ大切なのは、契約の範囲を開発メンバーまで共有しておくことです。ある案件では、開発のリーダーが契約形態や範囲を把握しないまま、追加の要望を次々に受け入れていました。定例会議で「この要望は契約の範囲内か」を毎回確認すると、追加費用のトラブルを防げます。追加要望の扱いは仕様変更と追加費用で詳しく説明しています。
議事録を残す理由
議事録は、会議の記録であると同時に、あとでトラブルになったときの証拠になります。システム開発の紛争では、「いつ、誰が、何を決めたか」が争点になることが多いからです。
議事録に必ず残したい項目は次のとおりです。
- 決定事項（何を、誰が決めたか）
- 保留事項と、決める期限
- 宿題（担当者と期限）
- 仕様の変更と、それに伴う費用・納期への影響
- 開発会社からの警告（「このままでは遅れる」など）
議事録は開発会社が作る場合が多いですが、発注者も必ず読み、内容に違いがあればその場で指摘してください。違いを指摘しないまま時間がたつと、その内容に同意したと受け取られやすくなります。
遅れが出たときの判断と打ち手
遅れが分かったときに取れる手は、大きく分けて次の4つです。
判断の順番は、まず「遅れの原因」を確認することです。原因が仕様の追加なら範囲を減らす、技術的な問題なら開発会社に対策を出してもらう、発注者側の確認待ちなら社内の体制を見直す、と打ち手が変わります。
開発会社から「このままでは間に合わない」と言われたら、聞き流さずにその場で次の手を一緒に検討してください。警告を受けたあとの発注者の対応は、裁判でも問われることがあります（システム開発の失敗事例で裁判例を紹介しています）。
受託開発の現場から
受託開発の現場で実践されている定例・進捗管理の進め方から、発注者にも役立つものを紹介します。
- 定例の成果物を決めておく: 週1回の定例会を運営し、議事メモと課題管理表を成果物として発注者に渡しています。会議をしたかどうかではなく、何が残ったかで進捗を確認できるようにするためです。
- 節目の報告会には決裁者に出てもらう: 調査フェーズでは、30分の週次定例に加えて中間報告会と最終報告会を設け、最終報告会には発注者側の代表者の同席をお願いしています。決める人が最後に初めて内容を聞く、という状態を避けるためです。
- アジェンダの順番を固定する: 定例はToDoの確認、スケジュールの確認、論点の検討の順に進め、論点ごとに担当者と時間を割り振ります。
- 未確定事項は一か所で管理する: 仕様に関する質問・確認は開発会社側のPMが一元管理し、決まっていないことは課題管理表に載せて、定例で一つずつ消し込んでいきます。
まとめ
- 予定どおりに終わる開発は多くありません。遅れに早く気づく仕組みとして定例会議を使います。
- 定例は週1回、ToDo・スケジュール・課題・論点・宿題の順で進め、判断できる人が出席します。
- 進捗報告では「完了の定義」と「発注者側の宿題」まで確認します。
- 議事録は決定事項・保留・警告を残し、発注者も読んで違いを指摘します。
- 遅れが出たら原因を確かめ、範囲・納期・体制・品質のどれで調整するかを発注者が決めます。
開発の進め方や定例の運営に慣れていない段階でも、FastProposal の無料AI相談なら、案件の内容を整理し、どのくらいの期間と費用がかかりそうかを数分で確認できます。発注前に全体像をつかむ材料としてお使いください。