---
title: "開発プロジェクトの遅れに早く気づくには｜アメリア・テクノロジー株式会社"
url: https://www.ameliatechnology.co.jp/blog/project-delay-early-signs/
description: "システム開発の遅れに早く気づくための見方を、はじめて発注する方向けに説明します。進み具合の確かめ方、遅れの兆しになりやすい出来事、定例の会議で聞くこと、遅れに気づいたときに発注者ができることを整理します。"
updated: 2026-11-12
publisher: "アメリア・テクノロジー株式会社"
---
# 開発プロジェクトの遅れに早く気づくには

システム開発の遅れに早く気づくための見方を、はじめて発注する方向けに説明します。進み具合の確かめ方、遅れの兆しになりやすい出来事、定例の会議で聞くこと、遅れに気づいたときに発注者ができることを整理します。

2026.11.12 [開発の発注と契約](https://www.ameliatechnology.co.jp/blog/category/outsourcing/)

執筆 [桐谷彰人](https://www.ameliatechnology.co.jp/blog/author/kiritani/)（取締役COO）

開発の発注と契約（OUTSOURCING）のコラム

## この記事の要点

- 進み具合は「何%終わったか」ではなく、終わった作業と、決めた日に終わるはずだった作業を比べて確かめます
- 決めごとの返事の遅れや、課題の一覧が増え続けることは、遅れの兆しになりやすい出来事です
- 遅れに気づいたら、原因と対応策を開発会社と一緒に確かめ、範囲・納期・体制のどれを調整するかを決めます

開発プロジェクトの遅れに早く気づくには、「何%終わったか」という報告だけに頼らず、終わった作業と、予定では終わっているはずの作業を、一つずつ比べて確かめることが大切です。システム開発の遅れは、ある日突然に表れるのではなく、小さな兆しが積み重なって表に出ることが多いです。兆しに早く気づけば、打てる手も増えます。

この記事では、はじめてシステム開発を発注する方に向けて、進み具合の見方と、遅れの兆し、発注者ができることを説明します。

## 「何%終わった」が当てにならない理由

進み具合の報告でよく使われる「全体の80%まで終わりました」という言い方は、遅れを見落としやすい報告です。作業には、思ったより手間のかかる部分が後に残りやすく、「80%から先がなかなか進まない」ということがよく起きるためです。

割合の代わりに、作業を小さく分け、一つずつ「終わった・終わっていない」で数える見方が役に立ちます。作業を分けた一覧（[WBS](https://www.ameliatechnology.co.jp/glossary/wbs/)）があれば、次のように比べられます。

| 比べるもの | 見方 |
|---|---|
| 予定 | 今日までに終わっているはずの作業 |
| 実際 | 今日までに終わった作業 |
| 差 | 終わっていない作業と、その理由 |

「終わった」の基準も決めておきます。たとえば、プログラムを書き終えただけでなく、テストまで終えたら「終わった」とする、といった決め方です。基準があいまいだと、ほとんど終わっているはずの作業が、後でやり直しになることがあります。

## 遅れの兆しになりやすい出来事

遅れの兆しは、作業そのものよりも、その周りの出来事に表れることがよくあります。次のような出来事が続いたら、注意して様子を見ます。

1. **決めごとの返事が遅れる**：発注者が決めるべきこと（画面の内容、業務の決まりなど）の返事が遅れると、開発会社の作業が止まります
2. **課題の一覧が増え続ける**：解決するより早く、新しい課題が増えていく
3. **同じ課題が何度も持ち越される**：定例の会議で、同じ課題が「検討中」のまま続く
4. **予定の見直しが続く**：小さな予定の変更がくり返され、そのたびに後ろの予定が詰まっていく
5. **担当者の交代や不在が続く**：開発会社の側でも発注者の側でも、中心になる人が替わると、引き継ぎに時間がかかります
6. **テストの開始が遅れる**：作る作業が延びて、テストの期間が短くなっていく

見落としやすいのが、1つめの発注者の側の遅れです。システム開発は、発注者と開発会社が分担して進めるものです。発注者の返事が遅れることも、プロジェクト全体の遅れの原因になります。

## 定例の会議で確かめること

遅れに早く気づくには、定例の会議で、毎回同じ観点で確かめることが役に立ちます。IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」では、発注者と開発会社が定期的に連絡協議会を開き、開発会社が進捗管理の報告を出して、遅れている事項の有無、遅れている事項があるときはその理由と対応策、体制の変更の要否などを協議する、という条項例を示しています。協議の結果は議事録に残す形です。

出典：[情報システム・モデル取引・契約書（第二版）（IPA）](https://www.ipa.go.jp/digital/model/model20201222.html)

定例の会議では、次のような問いを毎回聞くと、兆しに気づきやすくなります。

- 前回から今回までに、予定していた作業のうち終わらなかったものはあるか
- 終わらなかった作業は、なぜ終わらなかったか。次はいつ終わるか
- 発注者の側の返事や作業を待っているものはあるか
- 新しく出てきた課題と、その影響
- 次の大きな区切り（テストの開始、公開など）に間に合いそうか

報告を受けるだけでなく、疑問に思ったことはその場で聞くことが大切です。課題の一覧には、課題ごとに担当と期限を書き、期限を過ぎた課題がいくつあるかを毎回数えると、増え方の変化に気づきやすくなります。「問題ありません」という報告が続いていても、具体的な作業の状況を聞くと、隠れていた遅れが見えることがあります。発注する側の担当者がすることは[発注する側のプロジェクト管理。担当者がすること](https://www.ameliatechnology.co.jp/blog/client-side-project-management/)でも説明しています。

## 遅れに気づいたら、発注者ができること

遅れに気づいたら、まず原因と対応策を開発会社と一緒に確かめます。原因によって打つ手が変わるためです。

| 原因の例 | 考えられる対応 |
|---|---|
| 作る量が見積もりより多かった | 作る範囲を絞る、優先度の低い機能を後に回す |
| 発注者の決めごとが遅れていた | 社内で決める人と期限を決め直す |
| 技術的な問題が見つかった | 別の作り方を検討する、詳しい人に相談する |
| 開発会社の体制が足りない | 体制の見直しを相談する |

対応を決めるときは、「範囲」「納期」「体制（費用）」のどれを調整するかを考えます。3つとも変えずに遅れを取り戻すのは、難しいことが多いです。範囲を絞る場合は、どの機能が業務に欠かせないかを、発注者の側で決めておく必要があります。範囲や納期が変わる場合は、変更の手順に沿って記録を残します（[開発の途中で仕様を変えたいときの進め方](https://www.ameliatechnology.co.jp/blog/change-request-handling/)）。

なお、準委任などの契約で、発注者が開発会社の技術者に直接、作業の指示を出して遅れを取り戻そうとすると、偽装請負とみなされるおそれがあります。対応の相談は、開発会社の責任者を通して行います。

## 始める前にできること

遅れに早く気づける体制は、プロジェクトを始める前に整えておくのが効果的です。始まってから仕組みを作ろうとすると、目の前の作業に追われて後回しになりやすいためです。

- 作業を小さく分けた一覧と、それぞれの終わりの基準を作ってもらう
- 定例の会議の頻度と、報告の形を決めておく
- 発注者の側で、決める人と、返事の期限を決めておく
- 大きな区切りごとに、続けるかどうかを判断する場を設ける

最初の要件を固める段階の進め方は[要件定義で決めること：はじめての方へ](https://www.ameliatechnology.co.jp/blog/requirements-definition-basics/)で説明しています。

## 当社のご支援

当社の[Webシステム開発](https://www.ameliatechnology.co.jp/service/web-system/)では、区切りごとに、できたものをお客様と一緒に確かめながら進め、食い違いを早く見つけるようにしています。他社と進めているプロジェクトの進め方を相談したい場合は、相談や小さな開発を月単位で頼める[AIタイムシェア](https://www.ameliatechnology.co.jp/timeshare/)もご利用いただけます。技術者がお客様の現場に入って開発を進める[FDE](https://www.ameliatechnology.co.jp/fde/)の形もあります。まずは[お問い合わせ](https://www.ameliatechnology.co.jp/contact/)からご相談ください。

- プロジェクト管理
- 進捗管理
- 発注
- 開発の進め方

## この記事に出てくる用語

- [システム開発](https://www.ameliatechnology.co.jp/glossary/system-development/)
- [WBS](https://www.ameliatechnology.co.jp/glossary/wbs/)
- [情報システム・モデル取引・契約書（IPA）](https://www.ameliatechnology.co.jp/glossary/model-contract-ipa/)
- [プロジェクトマネジメント](https://www.ameliatechnology.co.jp/glossary/project-management/)
- [見積もり](https://www.ameliatechnology.co.jp/glossary/estimate/)
- [偽装請負](https://www.ameliatechnology.co.jp/glossary/disguised-ukeoi/)
- [請負契約](https://www.ameliatechnology.co.jp/glossary/ukeoi-contract/)
- [要件定義](https://www.ameliatechnology.co.jp/glossary/requirements-definition/)

## 関連する法令・指針（参考情報）

- 指針
   独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書」（第二版（2020年12月22日））
   情報システムの受託開発（一部の企画を含む）と保守運用の取引について、モデル契約と解説をまとめた資料です。民法の改正に直接関係する論点と、それ以外の論点の両方を見直しています。
   [発行元の公式ページで開く](https://www.ipa.go.jp/digital/model/model20201222.html)

法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは[法令・指針の参考情報と凡例](https://www.ameliatechnology.co.jp/knowledge/legal/)をご覧ください。

この記事を書いた人

[桐谷彰人](https://www.ameliatechnology.co.jp/blog/author/kiritani/) 取締役COO

システムエンジニアとして、ビジネスモデルの策定から要件定義、開発、コードレビューまでを担当してきました。運送管理、飲食業向けのDX、ECサイトなど、さまざまな業界のシステム開発に携わっています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

## あわせて読みたい

- [開発会社を替えるときの引き継ぎと、そろえておく資料](https://www.ameliatechnology.co.jp/blog/vendor-switch-handover/)
- [取適法（中小受託取引適正化法）とシステム開発の発注](https://www.ameliatechnology.co.jp/blog/toriteki-act-system-development/)
- [システム開発の成果物の著作権は誰のものか](https://www.ameliatechnology.co.jp/blog/software-copyright-ownership/)

[開発の発注と契約のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/outsourcing/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/)

## 次の一歩

### 現場に入るチームに任せる

技術者がお客様の現場に入り、要件定義から開発・運用までを担います。

[FDEを見る](https://www.ameliatechnology.co.jp/fde/)

### まずは30分、オンラインで話してみる

何に使うかが決まっていない段階でも構いません。30分のオンライン相談は無料です。

[無料で相談する](https://www.ameliatechnology.co.jp/contact/)

## ご関心に合わせて、お選びください。

[情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis)

---

出典：アメリア・テクノロジー株式会社「開発プロジェクトの遅れに早く気づくには｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/project-delay-early-signs/