リリースまであと1か月。開発会社との定例会で進捗を聞くと、返ってくるのは毎回「順調です」のひと言。システム開発の進捗報告がこれだけだと、「本当に間に合うのか」と不安になるのは自然なことです。
「進捗報告は『順調です』ばかりで、本当に間に合うのか不安…」
先に結論をお伝えします。不安の正体は、開発会社への不信ではなく「進み具合を確かめる材料がない」ことです。技術が分からなくても、「動くものを見せてもらう」「何をもって完了とするかを決める」「残っている課題とリスクを一覧で見る」の3つがそろえば、本当の進み具合はかなり見えるようになります。
この記事では、「順調です」になってしまう理由、発注者でもできる進捗の確かめ方、定例会の議題と報告テンプレート、遅れのサイン、遅れそうなときの対応、そして発注者側の役割までを、チェックリストと開発会社への質問例つきで解説します。
進捗報告が「順調です」になってしまう3つの理由
「順調です」という報告は、必ずしもごまかしではありません。多くの場合、報告する側にも受け取る側にも、そうなりやすい事情があります。
理由1：悪い知らせは誰でも言いにくい
「少し遅れています」と言えば、発注者をがっかりさせてしまいます。担当者としては「来週取り戻せるはずだから、今は言わなくてもいい」と考えがちです。これは開発会社に限らず、社内の報告でもよく起きることです。
ただ、小さな遅れは早く共有されるほど打てる手が多く、リリース直前になって初めて分かると選択肢が一気に減ってしまいます。悪い知らせほど早く聞ける関係をつくることが、結果的に双方を守ります。
理由2：進捗の「測り方」が決まっていない
「どこまで進んだか」の物差しがないと、報告は感覚的になります。たとえば「画面を作り始めた」も「画面ができてテストも終わった」も、担当者の感覚では同じ「進んでいます」になりえます。
よく知られた落とし穴に「9割できています」がずっと続く、というものがあります。残りの1割に、他のシステムとのつなぎ込みや不具合の修正といった手間のかかる作業が集まっていることが多いためです。
理由3：発注者が「何を聞けばいいか」分からない
発注者の側も、技術的なことを聞いても分からないだろうと遠慮して、「進捗はどうですか？」としか聞けないことがあります。漠然とした質問には、漠然とした答えが返ってきやすいものです。
逆にいえば、聞き方と見るものを具体的にすれば、報告も具体的になります。次の章から、その方法を順に紹介します。
技術が分からなくても本当の進捗が分かる5つの確かめ方
システム開発は、工場の生産と違って途中経過が目に見えにくい仕事です。IPA（情報処理推進機構）も、プロジェクトの問題を早く見つけて解決するために、見えにくい開発を「見える」ようにすることの重要性を示しています。
📰 出典：IPA「エンタプライズ系事業/プロジェクト見える化」
IPAはこのページで、開発中のプロジェクトで起こる問題を早期発見し解決していくために、「見えにくい」システム開発を「見える」ようにすることが重要だと述べています。発注者にとっての「見える化」は、次の5つから始めるのが現実的です。
1. 動くものを見せてもらう（デモ）
最も確実なのは、実際に動く画面を見せてもらうことです。定例会で5〜10分でよいので、前回から増えた機能を画面で操作して見せてもらいましょう。
- 資料や口頭の説明より、動く画面のほうが「どこまでできたか」がはっきりします
- 発注者が実際に触ると、仕様の思い違いにも早く気づけます
- 作りかけの画面でも構いません。「まだ見た目は仮です」と前置きしてもらえば十分です
「完成してからお見せします」と言われた場合は、「作りかけで構わないので、流れだけ確認したい」と伝えてみてください。
2. 「完了」の定義を決める
「完了」という言葉の意味を、開発会社とそろえておきます。たとえば次のように決めておくと、報告の「できました」がぶれなくなります。
- 画面・機能を作り終えている
- 開発会社の中でのテストが終わっている
- 発注者が画面で確認し、OKを出している
「発注者の確認まで終わって初めて完了」とすると、進捗の数字と実態のズレが小さくなります。
3. 残課題・リスク一覧をもらう
「何が終わったか」より大切なのが、「何が残っているか」「何が心配か」です。残っている作業、未解決の課題、起こるかもしれない問題（リスク）を一覧にして、毎回更新してもらいましょう。
リスクが1件も書かれていない一覧は、むしろ注意が必要です。リスクを書いてくれる開発会社は、隠さずに共有しようとしていると前向きに受け止めましょう。
4. マイルストーン（中間目標）で見る
リリース日だけを見ていると、遅れに気づくのが最後になります。「◯日までに受け入れテスト（＝発注者が実際に使って確かめる検査）開始」「◯日までにデータ移行のリハーサル」のように、途中の区切り（マイルストーン）を決め、予定どおり通過できたかを確認します。
リリース1か月前であれば、残りの期間を1週間ごとに区切り、「今週末までに何が終わっている予定か」を確認するのがおすすめです。
5. 課題管理表で「誰の」ボールかを見る
課題管理表（＝決めるべきこと・直すべきことを一覧にした表）には、担当者と期限の欄を必ず設けてもらいましょう。すると、止まっている課題が「開発会社の作業待ち」なのか「発注者の回答待ち」なのかが一目で分かります。
定例会の議題と進捗報告テンプレート
確かめ方が決まったら、定例会の中身をそろえます。IPAが公開している「情報システム・モデル取引・契約書」でも、こうした場の位置づけが示されています。
📰 出典：IPA「システム開発の健全化に向けて ～『情報システム・モデル取引・契約書』から読み解く～」（2025年4月24日講演資料）
この資料で紹介されているモデル契約の条文（第12条 連絡協議会の設置）では、発注者と開発会社が、業務が終わるまでの間、進捗状況、リスクの管理と報告、双方の分担作業の実施状況、問題点の協議と解決などを話し合う「連絡協議会」を開くというひな型が示されています。議事録は開発会社が作成し、発注者が確認する流れも例示されています。
実際の契約にどう書くかは案件ごとに異なるため、自社の契約書で定例会や議事録の扱いを一度確認しておくと安心です。
30分定例会の議題例
小規模な案件なら、週1回・30分程度でも十分に回ります。
- 前回の宿題の確認（5分）
- デモ：前回から増えた機能を画面で見る（10分）
- マイルストーンの達成状況と、来週の予定（5分）
- 残課題・リスクの確認と、決めるべきことの決定（8分）
- 宿題の確認（誰が・いつまでに）（2分）
ポイントは、毎回「決めること」と「宿題」で終わることです。報告を聞くだけの会にしないようにしましょう。
進捗報告テンプレート（表）
報告書の形式を開発会社にお願いするときは、次のような表を例として渡すと伝わりやすくなります。
| 項目 | 書いてほしい内容 | 例 |
|---|---|---|
| 次のマイルストーン | 名前・予定日・見込み | 受け入れテスト開始 10/15 予定どおり |
| 今週完了したこと | 「完了」の定義を満たしたもの | 受注登録画面（発注者確認済み） |
| 来週の予定 | 終わらせる予定の作業 | 請求書出力、権限設定 |
| 予定とのズレ | 遅れ・前倒しとその理由 | 帳票出力が3日遅れ（仕様確認待ち） |
| 残課題 | 件数と主なもの・担当・期限 | 残り12件（発注者回答待ち4件） |
| リスク | 起こりそうな問題と対策 | 既存データの形式が想定と違う可能性 |
| 発注者にお願いしたいこと | 回答・確認・準備 | テスト用データの提供（10/8まで） |
状況は「予定どおり／注意／遅れ」の3段階で書いてもらうと、ひと目で分かります。「注意」を気軽に使える雰囲気をつくるのが、早めの共有につながるコツです。
「順調です」の裏で遅れているかもしれないサイン
次のようなサインが重なったら、遠慮せず詳しく確認しましょう。どれも「遅れている」と決まるわけではなく、「確認したほうがいい」合図です。
- 何週間も「ほぼ完了」「9割できています」が続いている
- デモを何度お願いしても「次回に」と先送りになる
- 残課題の件数が減らない、または一覧自体が更新されていない
- 質問への回答が「確認します」のまま戻ってこない
- 受け入れテストやデータ移行の具体的な日程がなかなか決まらない
- 定例会が中止・短縮されることが増えた
こうしたときは責める口調ではなく、「リスクがあれば早めに一緒に考えたいので、率直に教えてください」と伝えるのが効果的です。
「遅れを早く言えると本当に助かります。1か月前なら打てる手はまだ多いんです」
間に合わなそうなときは「範囲」と「優先順位」で調整する
遅れが分かったら、選択肢は大きく「リリース日をずらす」「人を増やす」「リリース時点の範囲を絞る」の3つです。ただ、終盤に人を増やしても、新しい担当者が状況を理解するまでに時間がかかるため、すぐには効果が出にくいと言われます。
リリース日を動かせない場合は、「リリース日に必ず必要な機能」と「後から追加でよい機能」に分けるのが現実的です。この仕分けは、発注時に整理した「必須」と「あれば嬉しい」がそのまま使えます。
- 初めての発注で要望をどう仕分けるかは作りたいシステムを開発会社にどう伝える？初めての発注で準備したい5つのことで紹介しています
- 機能を「入れる／入れ替える／後に回す」で比べる考え方はシステム開発の途中で仕様変更したい！どこまで変えていい？判断の物差しと進め方が参考になります
範囲や日程を変えるときは、口頭で済ませず、変更内容・費用・日程を書面で合意しておきましょう。契約上の扱いに迷う場合は、契約書を確認のうえ、必要に応じて専門家に相談してください。
発注者の「回答の遅れ」も進捗を左右する
進捗管理は、開発会社だけの仕事ではありません。先ほどのIPAの資料では、システム開発はユーザ（発注者）とベンダ（開発会社）が協力して進めるものだという基本に立ち返り、双方が役割を果たすプロジェクトマネジメントが重要だとしています。
同じ資料では、開発会社が進捗を管理し、開発を妨げる要因に対応する役割を負う一方、発注者にも、必要な情報の提供などの協力が求められると説明されています。そしてこの「協力」には、積極的に何かをすることだけでなく、開発作業を妨げる行為をしないことも含まれるとしています。
発注者側でよくあるのが、次のような「回答待ち」による遅れです。
- 仕様の質問への回答が、社内の確認に時間がかかって1〜2週間止まる
- テスト用データや既存資料の準備が遅れる
- 決める人が定例会に出ておらず、その場で判断できない
- 終盤になって新しい要望が次々に追加される
課題管理表で「発注者の回答待ち」が増えていたら、まず自社側のボールを片づけましょう。回答期限を決め、社内で誰が判断するかを先に決めておくだけでも、進み方は大きく変わります。
進捗確認でやりがちな失敗
- 「順調ですか？」とだけ聞く：「はい」で終わってしまいます。「今週終わった機能を見せてください」のように具体的に聞きましょう
- 遅れの報告に強く反応してしまう：一度強く責めると、次から悪い知らせが上がりにくくなります
- リリース日だけを見ている：途中のマイルストーンがないと、遅れに気づくのが最後になります
- 報告書の数字だけで安心する：「進捗率80%」でも、残り20%が一番難しい部分かもしれません。デモと残課題もあわせて見ましょう
発注者がやることチェックリスト
- ☐ 定例会で毎回デモ（動く画面）を見せてもらう約束をした
- ☐ 「完了」の定義（発注者の確認まで含むか）を開発会社とそろえた
- ☐ 残課題・リスク一覧を毎回更新してもらうよう依頼した
- ☐ リリースまでのマイルストーンを週単位で確認できるようにした
- ☐ 課題管理表に担当者と期限の欄があり、自社の回答待ちを把握している
- ☐ 社内で判断する人と、質問への回答期限を決めた
- ☐ リリース日に必須の機能と、後回しにできる機能を仕分けた
- ☐ 契約書で定例会・議事録・変更手続きの扱いを確認した
開発会社への質問例
定例会でそのまま使える質問です。
- 「前回から増えた機能を、作りかけで構わないので画面で見せていただけますか？」
- 「リリースまでに一番心配なこと（リスク）は何ですか？それが起きたら何日くらい影響しそうですか？」
- 「残っている作業と課題のうち、こちら（発注者側）の回答待ちになっているものはありますか？」
- 「予定どおり進んでいるかは、何を基準に判断されていますか？」
- 「もし間に合わなくなりそうなら、どの時点で分かりそうですか？その場合の選択肢も早めに教えてください」
こうした質問は、開発会社を疑うためではなく、同じ情報を見て一緒に判断するためのものです。
まとめ：「順調です」を「見て分かる進捗」に変えよう
進捗報告が「順調です」ばかりになるのは、悪い知らせが言いにくいことと、進捗の測り方が決まっていないことが大きな理由です。技術が分からなくても、次のことを定例会の仕組みにすれば、本当の進み具合は見えてきます。
- 動くものを見せてもらう（デモ）
- 「完了」の定義をそろえる
- 残課題・リスク一覧とマイルストーンで確認する
- 課題管理表で、発注者側の回答待ちも把握する
リリース1か月前は、まだ打てる手が残っている時期です。不安を抱えたまま待つのではなく、今週の定例会で質問例を1つ使ってみるところから始めてみてください。
あわせて読みたい関連記事
