システム開発の進捗管理では、発注者も「期限・完成条件・未決事項・変更」を週次で確認する必要があります。開発会社へ丸投げせず、成果物を基準に進捗を測り、遅れが出たら範囲・納期・体制の優先順位を早めに見直すことが重要です。
システム開発で発注者が管理すべき範囲
発注者が管理すべきなのは、開発者の細かな作業方法ではなく、事業上の期限、完成条件、意思決定、変更、リスクです。 技術的な作業管理は開発会社へ任せつつ、自社にしか決められない事項を放置しない体制を作ります。
開発会社へ発注すると、「契約後は完成を待てばよい」と考えてしまうことがあります。しかし、開発中には業務ルール、画面の使い方、データの扱い、優先機能など、多くの判断が必要です。発注者の回答が遅れると、その間に開発が止まったり、仮の前提で作業が進んだりします。
一方、発注者が実装方法まで細かく指定すると、開発会社が持つ専門性を生かせません。発注者と開発会社の役割は、次のように分けると整理しやすくなります。
| 管理項目 | 発注者の主な役割 | 開発会社の主な役割 |
|---|---|---|
| 目的・優先順位 | 売上、効率化、公開日などの優先順位を決める | 目的に合う実現方法を提案する |
| 開発範囲 | 必要な業務と機能を承認する | 機能を作業単位へ分解する |
| スケジュール | 事業上の期限と社内確認日を決める | 工程、作業順序、必要工数を計画する |
| 仕様判断 | 業務ルールや利用条件を決める | 選択肢、影響、推奨案を説明する |
| 品質 | 利用者視点で完成条件を承認する | 設計、実装、テストの品質を管理する |
| 課題・リスク | 事業判断と社内調整を行う | 技術課題を検知し、対応案を示す |
| 変更 | 必要性と予算を判断する | 費用・納期・品質への影響を見積もる |
「進捗率」だけでは状態を判断できない
進捗報告で特に注意したいのが、「全体の80％まで完了しています」といった数字だけの説明です。進捗率の算出方法が決まっていなければ、担当者の感覚によって数字が変わります。
発注者は、進捗率よりも次の事実を確認してください。
- どの成果物が完成し、誰が確認したか
- 今週完了する予定だった作業のうち、何が残ったか
- 残作業はいつまでに、誰が対応するか
- 公開日に影響する課題があるか
- 発注者の回答待ちになっている事項はあるか
- 仕様変更によって作業量が増えていないか
- テストで重大な不具合が発生していないか
成果物とは、要件定義書、画面設計、動作する機能、テスト結果など、完了を確認できるものです。「作業中」ではなく、確認可能な状態まで到達したかを基準にします。
最低限用意したい管理資料
小規模な開発であっても、次の資料は用意しておくことをおすすめします。高機能な管理ツールを導入する必要はなく、表計算ソフトや開発会社の管理ツールでも構いません。
- WBS：Work Breakdown Structureの略で、開発作業を細かく分け、担当者と期限を設定した計画表
- マイルストーン一覧：要件確定、設計承認、テスト開始、公開など、重要な中間到達点の一覧
- 課題管理表：現在発生している問題、担当者、対応期限、事業への影響を記録する表
- リスク管理表：まだ発生していないものの、納期や予算へ影響する可能性がある事項の一覧
- 変更管理表：契約後に追加・変更した仕様と、費用・納期への影響を記録する表
- 意思決定ログ：誰が、いつ、何を、どの理由で決めたかを残す記録
これらの資料が別々に存在していても、更新されなければ意味がありません。更新責任者と更新タイミングを決め、定例会では同じ資料を継続して確認します。
進捗管理の体制・会議頻度・費用目安
一般的な中小規模案件では、発注者側の責任者を1名置き、週1回の定例会と日常的な質問窓口を設ける形が基本です。 案件が大きい場合は、経営判断を行う会議と、実務課題を扱う会議を分けます。
案件規模に応じた管理体制
以下は一般的な目安です。期間だけでなく、関係部署数、外部サービスとの連携数、法令・セキュリティ要件などによって必要な管理量は変わります。
| 案件の目安 | 想定期間 | 発注者側の関与 | 会議の目安 | 主な管理方法 |
|---|---|---|---|---|
| 小規模な試作・改修 | 1〜3か月 | 週2〜5時間程度 | 週1回・30〜45分 | タスク表、課題表、簡易デモ |
| 中規模な業務システム・Webサービス | 3〜9か月 | 週5〜10時間程度 | 週1回・60分前後 | WBS、課題・リスク表、月次報告 |
| 大規模・複数部署にまたがる開発 | 9か月以上 | 週10〜20時間以上の場合もある | 実務会議を週1〜2回、責任者会議を月1回 | 統合計画、変更管理、品質・予算管理 |
発注者側で必要になる時間には、定例会への出席だけでなく、社内確認、質問への回答、成果物のレビュー、受入テスト、関係部署への説明も含まれます。発注担当者が通常業務と兼務する場合は、上司や関係部署が時間を確保できるようにしておく必要があります。
定例会で確認する項目
定例会は、報告を聞くだけの場ではありません。判断が必要な事項を確定し、次の行動と期限を決める場です。毎回の議題を次の順番で固定すると、重要事項の確認漏れを防ぎやすくなります。
- 前回の決定事項と宿題の確認
- 今週完了した成果物の確認
- 来週までに完了する作業の確認
- スケジュールの遅れと公開日への影響
- 課題・リスク・不具合の確認
- 発注者が判断すべき事項の決定
- 仕様変更と追加費用の有無
- 次回までの担当者と期限の確認
議事録は会議後できるだけ早く共有し、認識が違う場合の訂正期限も決めます。録画や文字起こしだけを残すのではなく、決定事項、未決事項、担当者、期限を短く整理することが重要です。
進捗管理・PMOを外注する費用
社内にシステム開発の管理経験者がいない場合は、PMOを外注する方法もあります。PMOとはProject Management Officeの略で、計画、会議運営、課題管理、品質管理などを支援する役割です。
一般的な費用目安は次のとおりです。
| 支援内容 | 費用の一般的な目安 | 向いている状況 |
|---|---|---|
| 計画・管理方法の整備のみ | 20万〜60万円程度 | 開発開始時の計画や書式を整えたい |
| 月数回の進捗確認・助言 | 月額20万〜50万円程度 | 社内担当者が管理し、専門家の確認だけ受けたい |
| 継続的なPMO支援 | 月額40万〜120万円程度 | 定例会、課題管理、変更管理まで任せたい |
| 大規模案件の専任支援 | 月額100万〜200万円以上の場合もある | 複数会社・複数部署を横断して管理したい |
金額は、担当者の稼働量、案件規模、資料作成量、会議頻度、技術調査の有無によって変わります。開発会社の見積もりにプロジェクト管理費が含まれている場合は、外部PMOと役割が重複しないようにしてください。
PMOへすべての判断を任せることはできません。事業の優先順位、追加予算の承認、業務ルールの決定は、最終的に発注者が行います。
発注後の進捗管理を進める6ステップ
進捗管理は、遅れが発生してから始めるものではありません。契約直後に基準となる計画を確定し、週次で実績との差を確認する流れを作ります。
1．責任者と判断ルールを決める
まず、発注者側と開発会社側の責任者を明確にします。発注者側は、問い合わせを受け取る窓口だけでなく、仕様を決定できる人、予算を承認できる人、最終的に検収する人を決めます。
最低限、次の点を合意してください。
- 日常的な連絡窓口は誰か
- 仕様を承認できる人は誰か
- 追加費用を承認できる人は誰か
- 回答期限を過ぎた場合に誰へ連絡するか
- 緊急時の連絡方法は何か
- 最終的な検収責任者は誰か
担当者不在で判断が止まる可能性がある場合は、代理承認者も設定します。
2．基準となるスケジュールを承認する
契約時の納期だけでなく、要件確定、設計承認、開発完了、テスト開始、受入テスト、公開といった中間期限を確認します。この基準計画がなければ、途中の遅れを把握できません。
スケジュールを見る際は、次の項目を確認します。
- 発注者の確認期間が確保されているか
- 土日祝日や長期休暇が考慮されているか
- 外部サービスの審査や契約期間が含まれているか
- データ準備や移行の期間が含まれているか
- テストで不具合が見つかった場合の修正期間があるか
- 公開作業に失敗した場合の予備日があるか
依頼内容がまだ整理できていない場合は、開発開始前にシステム開発ヒアリングシート｜依頼前の作り方を参考に、目的、利用者、必要機能、既存環境を整理しておくと確認が進みやすくなります。
3．完了条件を作業単位で決める
「画面開発完了」「テスト完了」という表現だけでは、どこまでできれば完了なのかが曖昧です。画面開発であれば、表示だけでなく、入力チェック、権限、スマートフォン表示、エラー時の動作などが含まれるかを確認します。
作業ごとに、次のような完了条件を設定します。
- 成果物が指定場所へ保存されている
- 開発会社内のレビューが完了している
- 指摘事項が修正されている
- 発注者が確認できる環境へ反映されている
- 定めたテストに合格している
- 発注者の承認が記録されている
完成条件が曖昧なままでは、開発会社は完了と考えている一方、発注者は未完成と考える事態が起こります。
4．週次で計画と実績の差を確認する
定例会では、全体の進捗率だけでなく、前週に完了予定だった作業が実際に完了したかを確認します。未完了の場合は、理由、影響、対応策、新しい期限を記録します。
特に確認したいのがクリティカルパスです。クリティカルパスとは、遅れるとプロジェクト全体の完了日も遅れる作業のつながりです。公開日に影響しない作業の遅れと、1日の遅れがそのまま公開日に影響する作業を区別して管理します。
発注者からの回答待ちも、通常の課題と同じように記録してください。「社内確認中」のまま期限がない状態にせず、回答担当者と回答日を設定します。
5．仕様変更を正式に管理する
開発中に変更が発生すること自体は珍しくありません。問題は、口頭やチャットで依頼した細かな変更が積み重なり、費用や納期への影響が見えなくなることです。
変更を依頼する場合は、次の流れを通します。
- 変更内容と変更理由を記録する
- 開発会社が作業量と影響範囲を調査する
- 費用、納期、品質への影響を提示する
- 発注者が実施、延期、見送りを判断する
- 承認後にWBS、見積もり、仕様書を更新する
小さな変更であっても、累積すると無視できない作業量になります。契約内で対応できる範囲と追加費用になる範囲も、あらかじめ確認しておきます。
6．中間成果物を確認しながら検収へ進む
完成後に初めてシステムを見るのではなく、画面設計、試作画面、主要機能などを段階的に確認します。早い段階であれば、認識の違いが見つかっても修正範囲を抑えやすくなります。
検収とは、納品物が契約や仕様どおりかを発注者が確認し、受領を判断する手続きです。開発終盤になってから検収条件を決めるのではなく、要件定義や設計の段階で合格基準を合意してください。具体的な準備はシステム開発の検収方法｜受入テストと注意点でも解説しています。
遅延を防ぐ見積もり・契約・会社選びのポイント
遅延を防ぐには、発注後の管理だけでなく、見積もりや開発会社の提案段階で管理方法を確認することが重要です。 金額と最終納期だけでなく、誰がどのように計画を更新し、問題を報告するのかを比較してください。
遅延の初期兆候と対応方法
開発の遅れは、突然発生するとは限りません。小さな未完了や未決事項が積み重なった結果、公開直前に表面化する場合があります。
| 初期兆候 | 考えられる問題 | 発注者が確認する質問 | 主な対応 |
|---|---|---|---|
| 進捗率が数週間変わらない | 難しい課題が未解決 | 何が完了を妨げているか | 課題を分解し、責任者と期限を設定する |
| デモが繰り返し延期される | 動作する状態に到達していない | どの機能なら確認可能か | 範囲を限定して早期に確認する |
| 「ほぼ完成」が長く続く | テストや修正量が見えていない | 残作業を件数と期限で示せるか | 残作業一覧を作る |
| 会議で新しい課題が毎回出る | 課題管理が機能していない | 発生日と検知経路は何か | 課題表を一本化する |
| 担当者の交代が多い | 引き継ぎ不足や体制不安 | 交代理由と引き継ぎ状況は何か | 体制表と責任者を再確認する |
| 質問への回答が曖昧 | 状況を把握できていない | 根拠となる成果物や記録はあるか | 資料と実物を基準に報告してもらう |
| 発注者の確認依頼が急増する | 計画に確認期間がない | いつまでに何を決める必要があるか | 判断事項を優先順位順に整理する |
遅延したときに比較する4つの選択肢
遅れが発生した際は、責任追及よりも、原因と事業への影響を整理することを優先します。主な選択肢は次の4つです。
- 公開範囲を減らす：優先度の低い機能を次回へ回し、重要機能だけで公開する
- 公開日を変更する：品質を維持したまま、必要な作業期間を追加する
- 作業順序を変える：公開に必要な作業を先に進め、後回しにできる作業を分ける
- 体制を補強する：特定分野の担当者やテスト担当者を限定的に追加する
増員は有力な選択肢ですが、常に納期短縮につながるわけではありません。新しい担当者への説明や作業分担に時間がかかり、既存担当者の負担が一時的に増えるためです。増員を提案された場合は、「誰を、いつから、どの作業へ追加し、何日短縮できる見込みか」を確認します。
見積もりで確認する管理項目
見積書では、実装費だけでなく、次の作業が含まれているかを確認してください。
- プロジェクト計画の作成と更新
- 定例会の開催と議事録作成
- 要件・設計に関する確認会
- 課題、リスク、変更の管理
- 開発会社内のレビュー
- テスト計画、実施、結果報告
- 発注者による確認環境の準備
- リリース計画と公開作業
- 操作説明や引き継ぎ
- 検収期間中の不具合修正
「プロジェクト管理費」として一式計上されている場合は、管理責任者の稼働量、会議頻度、作成資料、報告範囲を質問します。管理費が安く見えても、必要な管理作業が実装担当者の空き時間に任されていると、問題の検知が遅れる可能性があります。
契約前に開発会社へ聞く質問
提案を比較するときは、過去の実績数だけでなく、問題が起きたときの管理方法を確認します。
- 進捗はどの資料を使って報告しますか
- 進捗率はどのように計算しますか
- プロジェクト管理の責任者は誰ですか
- 責任者は他案件を何件程度兼務しますか
- スケジュールが遅れた場合、いつ、どの基準で報告しますか
- 課題・リスク・仕様変更をどのように記録しますか
- 発注者に求める確認作業と回答期限は何ですか
- 中間成果物や開発中の画面を確認できますか
- 担当者が交代する場合、どのように引き継ぎますか
- 追加費用が発生する条件は何ですか
良い提案は、「問題は起こりません」と説明するものではありません。問題が発生する可能性を前提に、検知方法、報告経路、判断手順が具体化されています。
発注のご相談を受ける開発会社の立場から見ると、プロジェクトが安定しやすいのは、すべての仕様が最初から決まっている案件だけではありません。未確定事項を明示し、いつ誰が決めるかを合意できている案件です。反対に、「細かい点は作りながら相談」としながら、判断担当者や追加費用の扱いが決まっていない案件は、認識の違いが起きやすくなります。
発注前・発注直後のチェックリスト
以下を確認できれば、進捗管理の基本的な土台が整っています。
- 発注者側と開発会社側の責任者が決まっている
- 仕様、予算、検収の承認者が明確になっている
- 中間期限を含むスケジュールがある
- 作業ごとの担当者と完了条件が決まっている
- 発注者のレビュー期間が計画に含まれている
- 週次報告の書式と会議頻度が決まっている
- 課題・リスク・変更を記録する場所が決まっている
- 追加費用が発生する条件を確認している
- 中間成果物を確認できる環境がある
- テストと検収の基準が合意されている
- 遅延時の連絡経路と判断者が決まっている
- 公開後の保守・問い合わせ窓口を確認している
自社の案件に必要な管理体制や、現在の進捗状況に不安がある場合は、契約・仕様・スケジュールを整理したうえで専門家へ確認する方法もあります。開発のご相談はこちらからお問い合わせください。
まとめ
- 発注者は、開発者の細かな作業ではなく、目的、優先順位、完成条件、判断、変更を管理します
- 進捗率だけを見ず、確認可能な成果物、未完了作業、課題、期限を確認することが重要です
- 一般的な中小規模案件では、発注者側の責任者を置き、週1回の定例会を行う方法が基本です
- 契約直後にWBS、マイルストーン、課題表、変更管理表を用意し、更新責任者を決めます
- 仕様変更は、費用・納期・品質への影響を確認してから正式に承認します
- 遅延時は、機能削減、公開日変更、作業順序の見直し、限定的な増員を比較します
- 見積もりでは、プロジェクト管理、レビュー、テスト、リリース、検収対応が含まれるかを確認します
- 開発会社は実績や価格だけでなく、問題の検知方法と報告・是正の手順で比較してください
よくある質問
システム開発の進捗率は何を基準に確認すればよいですか？
作業時間の消化率ではなく、確認可能な成果物と完了条件を基準にします。設計書の承認、機能の動作確認、テスト合格など、発注者が事実を確認できる単位で進捗を判断してください。
開発会社との定例会はどのくらいの頻度が適切ですか？
一般的な中小規模の開発では週1回が目安です。公開直前や問題発生時は週2回以上に増やし、反対に安定した保守フェーズでは隔週や月1回へ調整します。
開発が遅れた場合、開発者を増やせば解決しますか？
単純な増員で解決するとは限りません。新しい担当者への説明や作業分担に時間がかかるため、先に原因を特定し、機能削減、公開日の変更、作業順序の見直し、限定的な増員を比較する必要があります。
進捗管理やPMOの外注費用はいくらですか？
一般的な目安は、計画や管理方法を整えるスポット支援で20万〜60万円程度、継続支援で月額40万〜120万円程度です。案件規模、会議頻度、資料作成、課題解決への関与範囲によって変動します。