なぜ開発は遅れるのか。納期・スケジュールの見方

「予定通りに進んでいます」と開発会社から聞いていたはずなのに、納期の直前になって急に「もう少しかかりそうです」と連絡が来る。上司には「今月中には終わる」と報告してしまっている。なぜ急にそんなことになるのか、次はいつ終わるのか聞いても、はっきりした答えが返ってこない。ひとりで情シスや総務のIT担当を兼任している方であれば、こうした場面に一度は直面したことがあるのではないでしょうか。

システム開発の遅延は珍しいことではありません。しかし「珍しくない」と分かっていても、自社の案件が遅れると不安になりますし、経営層への説明にも困ります。厄介なのは、遅延の多くが「ある日突然」発生するのではなく、途中の進捗報告の中に予兆が含まれていることです。予兆を読み取れないまま「大丈夫です」という報告を信じ続けた結果、納期直前になって初めて深刻さに気づく、という流れが典型的なパターンです。

結論から言うと、開発の遅延は「工程の後半になるほど発覚しやすい」という構造上の性質を持っています。これは開発会社の怠慢だけが原因ではなく、システム開発という仕事の進め方そのものに組み込まれた特徴です。この記事では、なぜ遅延が起きるのかという構造的な理由と、進捗報告のどこを見れば早期に異変に気づけるのかを、実務目線で解説します。読み終える頃には、「進捗率80%」という報告を鵜呑みにせず、次に何を確認すればよいかが分かるようになるはずです。

この記事で分かること

納期の遅れに困っている担当者、あるいは今後の遅延を予防したい担当者が抱える疑問に、順番に答えていきます。

• なぜシステム開発は遅れやすいのか。構造的な理由
• 「進捗率」という数字がなぜ当てにならないことがあるのか
• 開発の工程ごとに、遅延の兆候はどこに現れるのか
• 進捗報告で確認すべき具体的な項目
• 遅延が発覚したときに発注者側がまず取るべき行動
• 遅延を未然に防ぐために、契約前・発注時にできること

一つずつ、順を追って見ていきます。

なぜ開発は遅れるのか。3つの構造的な理由

システム開発の遅延には、いくつかの典型的な原因があります。大きく分けると次の3つです。

• 見積もり段階の不確実性: 開発が始まる前の見積もりは、まだ実装していない作業量を予測した数字にすぎません。要件が具体化するにつれて、当初の想定より複雑な仕様だったと判明することがあります
• 要件・仕様の変更: 開発の途中で「やっぱりこの機能も必要だった」「この画面はこういう動きにしてほしい」といった追加要望・仕様変更が発生すると、その分の作業が積み増しになります
• テスト工程での不具合の集中発覚: 設計・実装段階では見えなかった不具合が、テスト工程に入ってから一気に見つかることがあります

IPAが公開している「情報システム・モデル取引・契約書」の解説でも、ユーザー（発注者）側が仕様凍結後に大量の追加開発要望を出した結果、開発が遅延したという事例が紹介されており、要件・仕様の変更が遅延要因になり得ることが示されています。同資料では、こうした変更が発生した際の扱いを契約段階で取り決めておく「変更管理手続」の重要性も指摘されています。

発注者側の追加要望や仕様変更は、開発会社にとって「言われた通りに対応しただけ」であっても、当初のスケジュールには織り込まれていない作業です。誰の責任かを問う前に、まず「追加された作業である」という事実を発注者・開発会社の双方で認識を合わせることが、トラブルを避ける第一歩になります。

この3つの理由に共通しているのは、いずれも「開発が始まった後にならないと正確な量が分からない」という性質を持っている点です。見積もりというものは、まだ手を動かしていない段階での予測にすぎないため、実際に作業を進めてみて初めて「思ったより複雑だった」「想定より簡単だった」という差が生まれます。この差が積み重なることで、当初の計画からのズレとして表面化するのが遅延の正体です。

さらに、これら3つの理由は互いに独立しているわけではなく、連鎖することも少なくありません。たとえば見積もり段階で複雑さを見誤っていた機能について、実装段階になって発注者側から仕様の明確化を求められ、その結果として仕様変更に近い手戻りが発生し、テスト工程でさらに想定外の不具合が見つかる、といった具合です。1つの遅延要因が単独で発生するケースよりも、複数の要因が折り重なって遅延が拡大するケースのほうが、実務上はむしろ多く見られます。

次の見出しで、なぜこの性質が遅延の発覚を遅らせるのかを詳しく見ていきます。

「進捗率80%」が当てにならない理由

進捗会議で「進捗率80%です」と報告されると、多くの人は「あと20%だから、もうすぐ終わる」と受け取ります。しかし、この受け取り方には落とし穴があります。

システム開発における「進捗率」は、多くの場合「予定していた作業項目のうち、着手または完了した項目の割合」を示す数字です。つまり、実際に動くものがどれだけ完成しているかではなく、あらかじめ決めた作業計画のどこまで進んだかを表す指標にすぎません。この違いが、遅延の発見を遅らせる原因になります。

• 設計書やコードの「記述」は進んでいても、実際に動かして検証する「テスト」がまだ手つかずの場合、進捗率の数字だけでは分からない
• 複数の機能を並行して進めている場合、簡単な機能から着手して進捗率を稼ぎ、難しい機能が後回しになっていることがある
• 「80%」という数字自体が、残り20%の難易度を織り込んでいないことがある。仮に残りの作業が最も複雑な部分に集中していれば、実際の残り工数は20%よりずっと大きい可能性がある

とくに注意したいのが、システム開発の工程は一般的に「要件定義→設計→実装→テスト→受け入れ確認」という順で進み、後工程に行くほど不具合や認識のズレが発覚しやすいという構造です。実装段階では「作った通りに動いている」ように見えても、実際のデータや利用シーンでテストして初めて、想定していなかった不具合や仕様の抜け漏れが見つかることが少なくありません。テスト工程に入ってから不具合が集中して見つかると、その修正のためにスケジュールが後ろにずれ込みます。

つまり、進捗率が高い数字で推移していても、それは「作業計画通りに手を動かしている」ことを示しているだけで、「品質面で問題なく完成に近づいている」ことを保証するものではありません。この違いを理解しておくことが、進捗報告を正しく読むための出発点になります。

「後半で急に進捗率が止まる」現象の正体

進捗報告のグラフを見ていると、序盤は右肩上がりに進んでいた進捗率が、終盤になって急に伸びが鈍化する、あるいは横ばいになる現象を目にすることがあります。これは偶然ではなく、開発工程の性質上、起こるべくして起こる現象です。

序盤の作業(画面の枠組みを作る、基本的なデータの出し入れを実装するなど)は、比較的見積もりが立てやすく、予定通りに消化しやすい作業です。一方で終盤に残るのは、複数の機能が絡み合う処理や、例外的なデータパターンへの対応、他システムとの連携部分といった、見積もり段階では想定しきれなかった難易度の高い作業であることが多くなります。この「簡単な部分から片付き、難しい部分が最後に残る」という偏りが、進捗率のグラフにも反映されます。

• 序盤の進捗率の伸びが良いからといって、そのままのペースで完了すると期待しない
• 終盤に近づくにつれて、進捗報告の頻度を上げてもらうよう依頼する
• 「残り20%」の中身が、どの機能に該当するのかを具体的に確認する

こうした偏りを知っているだけでも、「なぜ最後だけ急に遅れるのか」という疑問への心構えができ、終盤での混乱を減らすことができます。

工程ごとに見る、遅延の兆候はどこに現れるか

遅延の兆候は、開発工程のどの段階にいるかによって、現れ方が変わります。工程ごとにチェックすべきポイントを整理します。

要件定義・設計段階での兆候

この段階での遅延は、多くの場合「決めるべきことが決まっていない」状態が原因です。次のような状況があれば注意が必要です。

• 発注者側の確認・承認待ちで作業が止まっている期間が長い
• 「詳細は追って詰める」といった曖昧な合意のまま次の工程に進もうとしている
• 仕様に関する質問や確認事項のやり取りが、想定より頻繁に発生している

要件定義の段階で認識のズレが解消されないまま実装に進んでしまうと、そのズレは後工程でより大きな手戻りとなって表面化します。この段階の遅延は、実は最も早く・安く修正できるタイミングでもあるため、「まだ設計段階だから大丈夫」と油断せず、疑問点はその都度確認しておくことが重要です。

実装段階での兆候

実装段階での遅延は表面化しにくく、進捗会議で「順調です」という報告が続きやすい時期でもあります。次のような兆候があれば、掘り下げて確認する価値があります。

• 進捗報告の内容が「〇〇の実装が完了しました」という定性的な表現に終始し、テストの実施状況や残作業の見通しに触れていない
• 当初のスケジュール表（マイルストーンや中間の完了予定日）が、いつの間にか更新されずに古いままになっている
• 担当者の増員・交代など、体制面の変化があったにもかかわらず、スケジュールへの影響について説明がない

テスト段階での兆候

前述の通り、テスト段階は不具合が集中して発覚しやすい時期です。この段階では、次の点を確認してください。

• 発見された不具合の件数と、そのうち未修正で残っている件数
• 不具合の深刻度（軽微な表示崩れなのか、業務が止まるレベルの不具合なのか）
• テストの実施範囲が、当初予定していた範囲を網羅できているか

テスト段階で「不具合はいくつか出ていますが、対応中です」という報告だけを受け取ると安心してしまいがちですが、件数・深刻度・修正の見込みまで確認しないと、実際の遅延インパクトは判断できません。

受け入れ確認段階での兆候

自社での動作確認(受け入れテスト)の段階に入っても、油断は禁物です。次のような兆候が見られる場合は、最終納期に影響が出る可能性を念頭に置いてください。

• 自社で確認した不具合や要望に対して、開発会社側の修正対応に想定より時間がかかっている
• 「仕様通りです」という回答が続き、発注者側が期待していた動きとの認識のズレが解消されない
• 検収(納品物が契約内容を満たしているか確認する手続き)の基準があいまいで、何をもって完了とするかの合意ができていない

この段階での認識のズレは、最終盤で発覚するだけに調整の時間的余裕が少なく、当初の想定より対応が長引きやすい局面です。受け入れ確認の基準は、可能であれば開発の早い段階で開発会社とすり合わせておくことをおすすめします。

遅延の連鎖を生む「クリティカルパス」という考え方

進捗管理の実務でよく使われる考え方に、クリティカルパスというものがあります。これは、複数の作業が並行して進む開発プロジェクトの中で、「これが遅れると、プロジェクト全体の完了が確実に遅れる」という、最も影響の大きい作業の連なりを指す言葉です。

たとえば、ある機能Aの実装が3日遅れたとしても、他の作業に十分な余裕(バッファ)があれば、プロジェクト全体の納期には影響しないことがあります。一方で、機能Bの実装が1日遅れただけで、後続のテスト工程や他機能との連携作業がすべて後ろにずれ込み、結果的に最終納期に直結してしまうこともあります。この機能Bのような、遅れがそのまま全体の遅延に直結する作業の連なりがクリティカルパスです。

• すべての遅延が同じ重みを持つわけではないと理解しておく
• 進捗報告で「〇〇の作業が遅れています」と聞いたときは、それが全体の納期に直結する作業なのか、それとも余裕がある作業なのかを確認する
• 開発会社が進捗管理表(WBS=作業を細かい単位に分解した一覧)を用意している場合、どの作業が全体のボトルネックになっているかを聞いてみる

すべての作業の進捗を均等に気にする必要はありません。全体の納期に直結する作業がどこにあるかを把握しておくことで、限られた確認の時間を効率よく使えるようになります。

進捗報告で確認すべき5つの項目

進捗報告を受け取る際、次の5項目を確認する習慣をつけると、遅延の予兆に早く気づけるようになります。

これらの項目を毎回の進捗報告で定型的に確認するようにすると、「なんとなく順調そうだった」という印象論から、「どの項目で遅れが出ているか」という具体的な把握に変わります。とくに、進捗報告のフォーマットが開発会社側の裁量に任されている場合、この5項目を発注者側からテンプレートとして提示し、毎回同じ形式で報告してもらうよう依頼することも有効です。

質問の仕方に迷う場合は、次のような聞き方を参考にしてください。

• 「予定していた作業のうち、今週完了したのはどれですか。動作確認まで済んでいますか」
• 「残っている作業の中で、一番難しいと感じている部分はどこですか」
• 「現時点で分かっている不具合は何件ですか。そのうち、業務に支障が出るレベルのものはありますか」
• 「今のペースで進んだ場合、当初の納期に間に合いそうですか。間に合わない場合、どこまで遅れそうですか」

抽象的に「進捗はどうですか」と尋ねると「順調です」という抽象的な回答が返ってきやすくなります。具体的な項目を指定して質問することで、回答も具体的になりやすくなります。

遅延が発覚したときに、まずやるべきこと

進捗報告や自社での確認を通じて遅延の可能性に気づいたら、次の順番で対応することをおすすめします。

1. 事実確認を最優先する: まずは「何が」「どれだけ」遅れているのかを、感情的にならず事実ベースで確認します。犯人捜しから入ると、開発会社側から正確な情報が出てきにくくなります
2. 遅延の原因を切り分ける: 発注者側の確認待ちが原因なのか、開発会社側の作業遅延なのか、あるいは想定外の技術的な難易度が原因なのかを整理します。原因によって、その後の対応や費用負担の考え方が変わります
3. リカバリー案と新しいスケジュールを求める: 「いつまでに」「何を」「どうやって」取り戻すのか、具体的な計画を開発会社に提示してもらいます。曖昧な「頑張ります」という回答で終わらせないことが重要です
4. 社内への影響を確認し、早めに共有する: 業務開始日や他部署との調整が絡む場合は、遅延の可能性が見えた時点で早めに社内関係者へ共有し、影響範囲を最小限にとどめます

遅延が発覚した直後は「なぜ遅れたのか」を問い詰めたくなりますが、それだけでは前に進みません。原因の特定と並行して、「今後どう取り戻すか」という前向きな計画を求める姿勢のほうが、結果的に早い解決につながります。

なお、遅延によって当初のスケジュールが大きく崩れる場合、契約書に記載された納期や工程の扱いについても確認が必要になることがあります。契約形態が請負契約なのか準委任契約なのかによって、遅延に対する開発会社側の責任の考え方が異なるため、状況が深刻な場合は契約書の該当条項も合わせて見直しておくと安心です。契約形態そのものの違いについては、別記事で詳しく解説しています。

経営層への報告で気をつけたいこと

遅延が判明すると、経営層への報告が必要になる場面も出てきます。ここで陥りやすいのが、開発会社から受け取った情報をそのまま右から左へ伝えてしまい、質問されたときに答えられずに信頼を落とすパターンです。報告の際は、次の3点を自分の言葉で整理してから臨むことをおすすめします。

• 何が、どれだけ遅れているのか(期間・影響範囲を具体的な数字や事実で示す)
• なぜ遅れているのか(開発会社側の要因か、自社側の要因か、想定外の技術的な難易度か)
• 今後どうするのか(リカバリー案の内容と、それでも間に合わない場合の代替案)

経営層は、遅延そのものよりも「先が見えない状態」に不安を感じることが多いものです。完璧な解決策を示せなくても、現状把握と見通しを整理して伝えるだけで、報告の受け止められ方は大きく変わります。

遅延を未然に防ぐために、発注前・契約時にできること

遅延が起きてから対処するよりも、発注前の段階で遅延の芽を減らしておくほうが負担は小さく済みます。以下は、発注前・契約時に検討できる予防策です。

• 要件・仕様をできる限り具体的に固めてから発注する: 曖昧な要件のまま開発に着手すると、後工程での仕様変更が発生しやすくなります。要件のまとめ方は関連記事で詳しく解説しています
• 見積もりの内訳に、テスト工程や予備の作業時間（バッファ）が含まれているか確認する: バッファが薄い見積もりは、少しの想定外でもスケジュール全体に影響しやすくなります
• 進捗報告の頻度・形式を契約前に取り決めておく: 「月1回の簡単な報告」なのか「週1回、5項目を定型で報告」なのかによって、異変への気づきやすさが大きく変わります
• マイルストーン(中間の区切りとなる納期)を細かく設定する: 最終納期の1点だけで進捗を管理すると、遅延の発覚が直前になりがちです。工程の節目ごとに中間の確認ポイントを設けることで、早い段階で軌道修正しやすくなります

これらは、いずれも開発が始まってからでは後追いになりやすい対策です。とくに初めて外注する場合は、契約前の打ち合わせの段階で進捗報告の形式について合意しておくことをおすすめします。何を確認すればよいか分からない場合は、開発会社との初回打ち合わせで聞くべきことを整理した記事も参考にしてください。

さらに、見積書を受け取った段階でも、遅延予防の観点からチェックできることがあります。見積書の内訳にテスト工程が独立した項目として明記されているか、要件定義や設計の工数が極端に小さくないかといった点は、見積書の読み方を扱った記事でも詳しく触れています。要件定義や設計に十分な工数が割かれていない見積もりは、その分のしわ寄せが後工程の仕様変更や手戻りとして表面化しやすい傾向があるため、金額の大小だけでなく工程ごとの工数バランスにも目を向けることをおすすめします。

複数社を比較する際の視点

相見積もりを取っている段階であれば、金額だけでなく、各社の進捗管理・報告の考え方を比較する視点も持っておくと、契約後のミスマッチを防ぎやすくなります。

• 進捗報告の頻度・形式について、事前にどこまで具体的な提案があるか
• 過去のプロジェクトで遅延が発生した際、どう対応してきたかを尋ねたときの回答の具体性
• 見積もりの中に、不測の事態に備えた予備日数(バッファ)がどの程度織り込まれているか

金額の安さだけを基準に選んでしまうと、進捗管理の体制が手薄な会社を選んでしまうリスクがあります。相見積もりの比較観点を扱った記事もあわせて参考にしてください。

小規模な発注ほど、遅延の影響が大きくなりやすい

ひとりで情シス・総務を兼任している方が発注するシステム開発は、大企業の基幹システム刷新のような大規模プロジェクトと違い、比較的小規模な案件であることが多いはずです。小規模案件だからこそ意識しておきたい点を補足します。

• 大規模プロジェクトのように専任のプロジェクトマネージャーが進捗管理に張り付いているとは限らず、進捗管理の精度が案件ごとにばらつきやすい
• 発注者側の担当者も他業務と兼任のため、進捗報告を丁寧に確認する時間を確保しづらい
• 少人数体制の開発会社の場合、担当者の急な体調不良や他案件との兼ね合いだけで、スケジュールに影響が出やすい

小規模案件だからこそ「進捗報告をきちんと確認する」という基本動作の重要性は変わりません。むしろ、遅延を早期に発見してリカバリーする余地が小さい分、早めの気づきがより重要になるとも言えます。

業務側のスケジュールとの連動も忘れずに

システム開発の遅延は、開発会社と発注者間の話にとどまりません。多くの場合、新しいシステムの稼働開始日に合わせて、業務側でも「旧システムの並行運用終了」「関係者への操作説明会」「データ移行の準備」といった付随作業のスケジュールが組まれています。開発の遅延は、これら業務側のスケジュールにも連鎖的に影響します。

• 稼働開始日を起点に、業務側で組んでいる付随作業のスケジュールを洗い出しておく
• 開発の遅延が判明した時点で、業務側のスケジュールにどこまで余裕があるかを確認する
• 旧システムを並行して使い続けられる猶予があるかどうかを事前に確認しておく

開発の遅延が発覚してから業務側のスケジュールを慌てて調整するのではなく、発注段階で「開発が多少遅れても業務に支障が出ない余裕」を持たせておくことも、実務上有効な予防策です。

まとめ:遅延を前提に、早期発見の仕組みを作る

システム開発の遅延は、特定の開発会社が悪質だから起きるものとは限りません。見積もり時点の不確実性、要件・仕様の変更、テスト工程での不具合の集中発覚など、開発という仕事の進め方そのものに組み込まれた構造的な要因が大きく関わっています。

だからこそ発注者側にできることは、「遅延をゼロにする」ことではなく、「遅延の兆候にできるだけ早く気づき、リカバリーの余地があるうちに手を打つ」ことです。進捗率という数字だけを鵜呑みにせず、完了した作業の中身・残作業の難易度・不具合の件数と深刻度・遅延要因とリカバリー案という5つの項目を定期的に確認する習慣を持つことで、納期直前になって初めて深刻さに気づくという事態を避けやすくなります。

次は、発注前の段階でできる準備について、要件のまとめ方や相見積もりの取り方を解説した記事もあわせてご覧ください。進捗管理は発注後の話ですが、発注前の準備の質が、そのままスケジュールの安定度に直結します。