システム開発が遅延する原因と、発注時にできる防ぎ方
システム開発の遅延には、いくつかの典型的な原因があります。その多くは、開発が始まってからではなく、発注の段階での決め方や準備に関わっています。この記事では、遅延が起きる原因を整理したうえで、発注側が事前にできる防ぎ方を順に説明します。
システム開発の「遅延」とは何が遅れることか
一口に遅延といっても、遅れる対象はひとつではありません。私たちは、次の3つに分けて考えると整理しやすいと考えています。
- 納期の遅れ：約束した日にシステムが使える状態にならない
- 範囲の縮小：納期は守られたが、当初想定していた機能が入っていない
- 品質の妥協：納期は守られたが、不具合が多く、実際には使えない
納期に間に合わせるために範囲を削ったり、確認を省いたりすると、見かけ上の遅延は消えても、事業としては「遅れた」のと変わりません。新規事業では、市場に出す時期が事業の成否に関わることもあります。そのため、日付だけでなく、「使える状態で、想定した価値を届けられるか」で遅延を捉えておくことが大切です。
もうひとつ押さえておきたいのは、遅延の責任がどちらか一方にあるとは限らないことです。開発側の見積もりや進行管理の問題で起きることもあれば、発注側の準備や判断の遅れで起きることもあります。ここでは発注側が手を打てる部分に絞って書きます。
システム開発が遅れる主な原因
1. 要件が固まらないまま開発が始まる
最も多い原因は、作るものの定義、つまり要件が曖昧なまま着手することです。要件定義とは、システムに何をさせるのか、誰がどう使うのかを具体的に決める工程のことです。ここが曖昧だと、開発の途中で「これも必要」「ここは違う」という話が出てきます。そのたびに設計をやり直すので、スケジュールが後ろにずれます。
新規事業では、まだ事業の形が固まっていないことも多く、要件が揺れるのは自然なことです。問題は、揺れることを前提にせず、「固まったことにして」進めてしまう点にあります。要件定義の考え方は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で詳しく整理しています。
2. 完成した物を見て初めて認識の違いに気づく
文章や図だけで要件を合意すると、同じ言葉でも頭の中のイメージが人によって異なります。「管理画面があれば十分」と言ったとき、発注側は一覧と検索だけを想像し、開発側は権限管理まで含めて考えているかもしれません。
この違いは、完成に近づいてから動く画面を見て、初めて表に出ることが多いものです。その時点での修正は、手戻りの範囲が大きくなります。結果として、納期が延びるか、追加の対応が必要になります。詳しくはシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも触れています。
3. 発注側の確認・判断が遅れる
開発のスケジュールは、開発側の作業だけで決まるわけではありません。画面の確認、仕様の質問への回答、データやアカウントの提供など、発注側が返す必要のある作業が多くあります。これらが想定より遅れると、開発側の作業が止まります。
特に起きやすいのは、次のような場面です。
- 確認の窓口が複数いて、意見がまとまるまで回答が返せない
- 決裁者に確認が必要なのに、報告の機会が月1回しかない
- 現場の担当者が通常業務と兼務で、確認の時間が取れない
悪意があるわけではなく、発注側の体制が開発の速度に合っていないだけのことが多いです。見積もりや契約の段階では、「開発側が何日で作るか」ばかりが注目され、「発注側が何日で返すか」は決まっていないことがよくあります。
4. 開発の途中で範囲が広がる
スコープ（作る範囲）が少しずつ広がることも、遅延の典型的な原因です。ひとつひとつは小さな追加でも、積み重なると工数が増えます。「ついでにこの機能も」「やはりここも自動化したい」といった要望は、開発が進んで実物が見えてくるほど出やすくなります。
範囲の拡大自体は悪いことではありません。使ってみて必要だと分かった機能は、本来入れるべきです。問題は、何を足し、何を後回しにするのかを決める基準がないまま追加が通ってしまうことです。最初に入れる機能の絞り方はMVP開発の機能の絞り方｜最初に作るものと後回しの基準で整理しています。
5. 見積もりの前提に未確認の事項が残っている
見積もりは、その時点で分かっている情報をもとに作られます。次のような事項は、後から判明すると工数に大きく影響します。
- 既存システムや外部サービスとのデータ連携の有無と仕様
- 移行が必要な既存データの量と状態
- 決済・本人確認など、外部の審査や契約が必要な機能
- 想定するアクセス数、扱うデータの重要度
たとえば外部サービスとの連携は、相手側の仕様や審査の期間に左右されます。開発側の努力だけでは短縮できません。こうした事項が見積もりの前提に含まれていないと、後から「想定外」の作業として現れ、遅延につながります。
6. 役割と責任の分担が曖昧
誰が何を決めるのか、誰が最終的に責任を持つのかが曖昧だと、確認事項が行き来するだけで時間が過ぎます。特に社内にエンジニアがいない場合、技術的な判断を誰が行うのかが決まっていないことがあります。この点は新規事業でエンジニアいない会社の進め方｜システム開発や発注側のプロダクトオーナーとは｜役割と判断のしかたで触れています。
発注の段階でできる防ぎ方
ここからは、発注前や契約前に取れる対策を、順に説明します。
目的と成功条件を、短く書き出す
最初にやっておきたいのは、「このシステムで何を確かめたいのか」「何ができたら成功とみなすのか」を、短い文章にすることです。機能の一覧ではなく、目的と判断基準を書きます。
たとえば「会員が自分で予約を完了できること」「最初の3か月で検証したい仮説は何か」といった内容です。この軸があると、途中で機能の追加を求められたときに、「目的に必要か」という基準で判断できます。範囲の拡大を抑える土台にもなります。
機能に優先順位をつける
機能は、次の3つ程度に分けておくと、判断が楽になります。
- 最初のリリースに必須のもの
- あれば望ましいが、後から足せるもの
- 今回は扱わないと決めたもの
「扱わないと決めたもの」を明示するのがポイントです。何をやらないかが共有されていれば、開発中の追加要望も、後回しにする判断がしやすくなります。
確認の窓口と、決裁の流れを決めておく
発注側の窓口は、原則として1人に絞ります。そのうえで、その人がどこまで自分で決められるのか、どの内容は決裁者に確認が必要なのかを、事前に整理します。
あわせて、確認の期限もスケジュールに組み込みます。たとえば「画面の確認は依頼から3営業日以内に返す」と決めておくだけで、待ち時間が見えるようになります。決裁者への報告が必要なら、開発の節目に合わせて会議の日程を先に押さえておくと、判断待ちで止まりにくくなります。
外部連携・既存データ・審査事項を洗い出す
見積もりを依頼する前に、次の点を書き出しておきます。
- つなぐ必要のある外部サービスや既存システム
- 移行したいデータの種類と置き場所
- 法令や業界ルール、社内規程で確認が必要な事項
- 本番公開までに取るべき審査や契約
すべてを確定させる必要はありません。「分からない」と分かっていることを、開発側に伝えるだけで十分です。分からない点が見えていれば、開発側も調査の時間を計画に入れられます。
契約の形と、区切り方を確認する
契約形態によって、遅延が起きたときの扱いは変わります。一般に、請負契約は成果物の完成に責任を負う形で、準委任契約は作業の遂行に責任を負う形です。仕様が固まっていない段階で請負契約を結ぶと、仕様変更のたびに調整が必要になります。一方、準委任では、成果物の完成が約束されるわけではありません。
契約の種類は受託開発とは？依頼の流れ・契約形態・新規事業の選び方で整理しています。なお、契約書の雛形や考え方については、経済産業省が公表している「情報システム・モデル取引・契約書」も参考になります。
契約形態を選ぶのと同じくらい大切なのが、区切り方です。全体をひとつの大きな契約にするより、段階ごとに成果を確認できる形にしたほうが、遅れが出たときに早めに気づけます。
仕様の変更をどう扱うか、先に取り決める
開発中に仕様が変わること自体は避けられません。そこで、変更が出たときに「誰が、何を基準に、どう判断するか」をあらかじめ決めておきます。たとえば、次のような流れです。
- 変更の内容と理由を書き出す
- 目的に必要かを確認する
- スケジュールと工数への影響を開発側が示す
- 今回入れるか、次の段階に回すかを決める
この手順があれば、追加要望が来るたびに議論が一から始まることを避けられます。
実物を先に見て確かめる進め方
ここまでの対策は、発注側の準備を整える方法でした。もうひとつの有効な手段は、本格的な開発に入る前に、動く実物で確かめてしまうことです。
文章の仕様書では、先ほど書いた認識のズレや抜け漏れを、完成間際まで見つけられません。動くプロトタイプがあれば、実際に触りながら「ここはこう」「これは要らない」と指摘できます。使ってみて分かる「これじゃない」を早い段階で直せるため、後半の手戻りを減らしやすくなります。プロトタイプとMVP、モックの違いはプロトタイプとMVP・モックの違いを整理｜新規事業の使い分けにまとめています。
また、実物があれば、社内の合意形成も進めやすくなります。企画書だけでは伝わりにくい「何ができるのか」を見せられるため、決裁者への説明や稟議でも判断材料になります。この点は稟議を通すシステム開発｜プロトタイプの使い方で詳しく書いています。
ただし、プロトタイプにも注意点はあります。見た目が整っていても、本番で必要な品質や処理能力が備わっているとは限りません。プロトタイプで確かめるのは「何を作るのか」であり、本番運用の品質は別に確認する必要があります。ここを混同すると、かえって後の工程で想定外の作業が出ます。
最近はAIを使った開発も広がっており、動くものを短期間で用意しやすくなっています。ただし、AIが書いたコードの品質確認や保守は、人が責任を持つ部分です。発注の際に確認したい点はAI受託開発に依頼する前に確かめたい6つのことやAI開発でも品質には人の確認が必要な理由で整理しています。
発注前に確認したいチェックリスト
最後に、ここまでの内容を、発注前の確認項目としてまとめます。すべてを埋められなくても、空欄が分かるだけで意味があります。
- システムで確かめたいこと、成功とみなす条件を、短い文章で書けているか
- 機能が「必須」「後から」「今回は扱わない」に分けられているか
- 確認の窓口が1人に決まり、その人の決裁範囲が整理されているか
- 確認に返す期限（何営業日以内か）を、開発側と共有しているか
- 外部連携、既存データ、審査・契約が必要な事項を書き出しているか
- 契約の種類と、段階ごとの区切りを理解しているか
- 仕様変更が出たときの判断の流れを決めているか
- 本格開発の前に、動く実物で確かめる機会があるか
発注先を選ぶ段階でも、これらの項目をどう扱ってくれるかは判断材料になります。選び方の視点はシステム開発会社の選び方｜新規事業で失敗しない7つの視点に、外注全体の流れはシステム開発の外注ガイド｜依頼の流れと失敗の防ぎ方にあります。すでに外注でうまくいかなかった経験がある場合は、システム開発の外注で失敗後のやり直し｜再依頼の見直し点も参考になります。
まとめ
システム開発の遅延は、開発の現場だけで起きるものではありません。要件の曖昧さ、認識のズレ、発注側の判断の遅れ、範囲の拡大、見積もり前提の未確認、役割の不明確さといった原因の多くは、発注の段階での準備と取り決めで減らせます。
特に、目的と成功条件を書き出すこと、優先順位をつけること、確認の窓口と期限を決めること、変更の扱いを先に決めることは、すぐに取りかかれる対策です。さらに、動く実物で確かめる機会を早い段階で持てば、完成間際になって初めて違いに気づく事態を避けやすくなります。
JustFitは、構想をもとに約1ヶ月で実際に動くプロトタイプを先に開発し、実物を見てから契約を判断していただける受託開発サービスです。仕様が固まっていない段階や、稟議を通す前の段階でも相談できます。サービスの考え方はJustFitのサービス紹介で紹介しています。