開発を進める中で、当初予定していた納期が近づいても、完成の見通しが立っていないと感じることがあります。「進捗はどうですか」と聞いても「もう少しかかりそうです」という返事しか来ない。カレンダーだけが進んでいき、完成品はいつまでも見えない。このとき、感情的になって開発会社を責める前に、確認すべきことがいくつかあります。この記事では、納期が遅れ始めたとき、発注者側がまず確認すべきことを解説します。
この記事で分かること
納期の遅れには、さまざまな原因が考えられ、その原因によって、取るべき対応も異なります。「遅れている」という事実だけを見て一方的に相手を責めても、事態は好転しません。逆に、遠慮して何も言わずに様子を見続けても、状況は悪化するだけです。この記事では、遅れが見えてきた際に確認すべきポイントと、そのあとにどう動くべきかを、具体的な会話例やチェックリストを交えて紹介します。
結論を先に示すと、確認すべきことは次の3つです。
- 遅れの原因が、どちら側にあるかを確認する
- 今後の見通し（いつ、どこまで完成するか）を確認する
- 納期の遅れが、契約内容にどう影響するかを確認する
この3つを、この順番で確認することが重要です。原因を確認せずに見通しだけを聞いても的外れな回答になりがちですし、見通しを確認せずに契約条項の話を持ち出すと、話し合いが対立的になってしまいます。順序を守ることで、冷静で建設的なやり取りができます。
確認ポイント1：遅れの原因が、どちら側にあるかを確認する
納期の遅れには、開発会社側の作業の遅延が原因である場合と、発注者側からの追加依頼や、確認・承認の遅れが原因である場合があります。まずは、遅れの原因がどちらにあるのかを、冷静に確認することをおすすめします。
「これも追加でお願い」が積み重なることで、当初の予定より作業量が増えている場合、その分、納期が延びることは、ある程度自然な結果とも言えます。この場合、遅れを一方的に開発会社の責任と考えるのは適切ではありません。
原因を切り分けるための具体的な質問
実際に開発会社へ確認する際は、次のような質問をすると、原因の切り分けがしやすくなります。
- 「当初のスコープ（要件定義や見積もり時点で決めた機能範囲）と比べて、今の作業量はどう変わっていますか」
- 「私からの確認・承認の返答が遅かったことで、スケジュールに影響した部分はありますか」
- 「開発側の技術的な想定外（想定していなかった不具合や、外部サービスとの連携の難しさなど）はありましたか」
- 「今回の遅れの中で、いちばん時間がかかった作業は何ですか」
これらを聞くことで、遅れの構成要素が見えてきます。例えば「追加依頼で2週間、技術的な想定外で1週間、確認待ちで3日」というように分解できれば、どこに手を打てば納期を短縮できるかも判断しやすくなります。
よくある「原因のすり替え」パターンに注意する
発注者側が気をつけたいのは、原因の切り分けを都合よく解釈してしまうことです。よくある失敗パターンを2つ紹介します。
失敗パターン1：全部を開発会社の責任にしてしまう
「納期が遅れているのは開発会社のせいだ」と決めつけて、自分が出した追加依頼や、確認・承認にかかった時間を振り返らないケースです。あとから見積もり書や当初の要件定義書を見返すと、実は自分側の追加依頼が積み重なっていたことに気づくことがあります。感情的になっている段階では気づきにくいので、まずは事実（いつ、どんな依頼をしたか）を並べて確認することが有効です。
失敗パターン2：開発会社の説明をそのまま信じすぎてしまう
逆に、開発会社から「想定していなかった技術的な問題があった」と説明されると、それ以上踏み込まずに納得してしまうケースもあります。技術的な説明は発注者側には検証が難しいため、開発会社側が誠実に説明していない場合でも、そのまま受け入れてしまうリスクがあります。技術的な内容が分からない場合は、「その問題によって、具体的にどのくらいの作業時間が追加でかかっているのか」を数字で聞くことをおすすめします。数字での説明を求めると、曖昧な説明に頼っていた場合はその場で違和感が出やすくなります。
原因の切り分けチェックリスト
以下の項目を、開発会社とのやり取りの記録（メール、チャットの履歴、議事録など）を見ながら確認してみてください。
- [ ] 当初の見積もり・要件定義書に記載されていた機能範囲を再確認したか
- [ ] 契約後に追加した依頼を、日付順にリストアップしたか
- [ ] 確認・承認の依頼が来てから、自分が回答するまでにかかった時間を把握しているか
- [ ] 開発会社からの遅延理由の説明を、具体的な作業内容・時間の単位で聞いたか
- [ ] 過去の進捗報告（週次報告やチャットのやり取り）に、遅延の兆候が既に出ていなかったかを振り返ったか
この振り返りを行うことで、「誰が悪いか」を決めつける前に、事実に基づいた話し合いの土台ができます。
確認ポイント2：今後の見通し（いつ、どこまで完成するか）を確認する
遅れの原因を確認した上で、「いつ、どこまでの機能が完成する見通しか」を、具体的に確認することをおすすめします。「もう少しかかります」という曖昧な回答ではなく、「〇月〇日までに、この機能を完成させる予定です」という、具体的な見通しを求めることが重要です。
具体的な見通しを示せない場合、開発会社側でも、進捗の管理が十分にできていない可能性があるため、注意が必要です。
見通しを確認する際の具体的な聞き方
「いつ完成しますか」という聞き方だけでは、「もう少しです」といった曖昧な返答で終わってしまうことがあります。次のように、機能単位・日付単位で分解して聞くと、より具体的な回答を引き出せます。
- 「現時点で完成している機能と、未完成の機能を、リストで教えてもらえますか」
- 「未完成の機能について、それぞれいつ完成する予定か、機能ごとに日付を教えてもらえますか」
- 「その見通しには、テストの期間も含まれていますか」
- 「もし今の見通しどおりに進まなかった場合、次にどのタイミングで状況を再確認できますか」
特に「テストの期間も含まれているか」は見落としがちなポイントです。「開発が完了する日」と「実際に使い始められる日」を同じものと考えてしまうと、テスト・修正の期間が想定されておらず、二度目の遅延につながることがあります。
「もう少しです」から具体的な見通しを引き出す会話例
曖昧な回答が返ってきた場合の会話の進め方を、簡単な例で示します。
発注者：「進捗はどうですか」
開発会社：「もう少しかかりそうです」
発注者：「もう少し、というのは具体的にどれくらいでしょうか。今週中に完成する見込みですか、それとも来月にまたがりそうですか」
開発会社：「来月の頭くらいになりそうです」
発注者：「分かりました。来月頭までに、どの機能まで完成する予定か、リストにして共有していただけますか。それを見て、今後のスケジュールを一緒に考えたいです」
このように、選択肢を示して答えやすくしたり、リストという具体的な形で見通しを求めたりすることで、開発会社側も答えやすくなります。感情的に「いつまでにできるんですか」と迫るよりも、事務的に、かつ具体的に聞くほうが、正確な情報を得やすくなります。
見通しが「毎回ずれる」場合の見極め方
一度見通しを聞いて、それが多少ずれるのは珍しいことではありません。しかし、見通しを聞くたびに新しい遅延が発生し、何度も先延ばしになる場合は、プロジェクト管理そのものに問題がある可能性を疑う必要があります。次のような状態が続く場合は要注意です。
- 見通しを聞くたびに「あと1週間」と言われるが、実際には毎回延びている
- 完成している機能と未完成の機能の切り分けが、聞くたびに変わる
- 進捗報告の頻度が、遅延が発覚してから急に減っている
- 担当者が変わった、あるいは体制が変わったという説明が繰り返される
このような状態が2回以上続く場合は、単純な作業の遅れというより、プロジェクトの管理体制そのものに問題があるサインです。次の「早めに相談する」の段階に進み、場合によっては契約内容の確認まで検討したほうがよいでしょう。
確認ポイント3：納期の遅れが、契約内容にどう影響するかを確認する
契約書に、納期の遅れに関する条項（違約金、契約解除の条件など）が定められている場合、その内容を確認しておくことをおすすめします。ただし、こうした条項をすぐに適用しようとするのではなく、まずは今後の見通しを確認し、現実的な対応を相談することが優先です。
契約書で確認しておきたい項目
契約書を見返す際は、特に次の項目に注目してください。
- 納期の定義：契約書上の「納期」が、「開発完了日」「検収完了日」「本番リリース日」のどれを指しているか
- 遅延時の対応：納期に遅れた場合の取り決め（違約金、契約解除、再スケジュールの手続きなど）があるか
- 検収条件：何を確認して「完成」と認めるのか、検収の基準が明記されているか
- 契約解除の条件：どちらの当事者が、どのような場合に契約を解除できるか
- 追加費用の取り決め：追加依頼によって発生する費用や納期変更について、どのように取り決めているか
これらの条項がそもそも契約書に存在しない場合、遅延が発生したときの取り決めが不明確なまま進んでいることになります。その場合は、今後どう対応するかを、開発会社との話し合いのなかで、新たに取り決めておく必要があります。
契約条項を確認したあとの伝え方
契約条項を確認したことをそのまま開発会社に伝えると、対立的な印象を与えてしまうことがあります。次のような伝え方であれば、相手を追い詰めることなく、状況の重さを共有できます。
「契約書も確認しましたが、今回はまず、今後どう進めるかを一緒に考えたいと思っています。契約条項の話をする前に、現実的な見通しと対応策を相談させてください」
このように、契約条項を確認していることを伝えつつも、それを盾にするのではなく、まずは現実的な解決を目指す姿勢を示すことが、良好な関係を保つうえで重要です。
納期の遅れに気づいたら、早めに相談する
納期の遅れが見えてきた段階で、「まだ大丈夫だろう」と様子を見続けるのではなく、早めに開発会社に状況を確認することをおすすめします。早い段階で状況を共有することで、対応の選択肢（機能を一部削って、当初の納期を守るなど）を検討する余地が生まれます。
「様子を見る」ことのリスク
納期直前まで様子を見続けてしまうと、次のようなリスクが高まります。
- 選択肢が減る：納期が近づくほど、「機能を削る」「納期を延ばす」以外の選択肢がなくなっていく
- 次の予定への影響が大きくなる：サービスの告知やリリースイベントなど、後続の予定がある場合、直前の発覚では調整が難しくなる
- 関係が悪化しやすくなる：直前で問題が発覚すると、発注者側の不満が一気に噴出し、感情的なやり取りになりやすい
逆に、遅れの兆候が見えた時点（例えば、進捗報告の内容が前回と大きく変わらない、確認依頼への回答に開発会社側の対応が遅くなっているなど）で早めに声をかければ、まだ複数の選択肢を検討できる余裕があります。
早めに相談する際の伝え方
「遅れているのでは」と感じた段階で連絡する際は、相手を問い詰める言い方ではなく、状況を共有する言い方を心がけると、話し合いがスムーズになります。
「予定していた納期まで残り〇日ですが、現在の進捗を確認させてください。このまま進めて間に合いそうか、それとも調整が必要そうか、早めに共有していただけると助かります」
このような伝え方であれば、開発会社側も防御的にならず、正直に現状を共有しやすくなります。
遅れが、発注者側の対応によるものだった場合
確認や承認の依頼に対して、対応が遅れていた場合、それが遅延の原因になっていることがあります。この場合、今後は、開発会社からの確認依頼に、できるだけ早く対応することを心がけることで、遅れを最小限に抑えられます。
開発中の進捗確認や承認の重要性については、初めての発注でやりがちな失敗を扱った別記事でも触れています。
発注者側の対応が遅れがちになる典型的な理由
個人・複業でサービスを立ち上げる場合、本業と並行して開発を進めることが多く、確認・承認への対応が後回しになりやすい傾向があります。よくある理由を挙げます。
- 本業の忙しさで、開発会社からのメール・チャットの確認が数日後になってしまう
- デザインの確認や仕様の承認について、「じっくり考えてから返答したい」と先延ばしにしてしまう
- 何を確認すればよいのか分からず、返答に時間がかかってしまう
- 複数の確認依頼がまとめて来ると、優先順位がつけられず手が止まってしまう
こうした事情は、決して珍しいことではありません。ただし、開発会社側からすれば、確認待ちの間は次の作業に進めないことが多く、発注者側の対応の遅れが、そのままスケジュール全体の遅れにつながってしまいます。
対応スピードを上げるための工夫
確認・承認への対応を早くするために、次のような工夫が有効です。
- あらかじめ、確認依頼への回答期限（例：2営業日以内）を、開発会社と取り決めておく
- 確認依頼が来たら、まず「見た」ということだけでも即座に返信し、詳細な回答は期限内に行う
- 何を確認すればよいのか分からない場合は、「確認すべき観点を教えてください」と開発会社に聞き返す
- 本業が忙しい時期があらかじめ分かっている場合は、その時期を開発会社に共有し、スケジュールに反映してもらう
これらを実践するだけで、発注者側が原因となる遅延は大きく減らせます。
遅れが深刻な場合、専門家に相談することも検討する
納期の遅れが著しく、開発会社との話し合いでも解決の見通しが立たない場合、契約内容に基づいた対応（違約金の請求、契約解除など）を検討する必要が出てくることもあります。この場合、弁護士など専門家に相談することも、選択肢として検討することをおすすめします。
専門家への相談を検討すべきタイミング
次のような状態になった場合は、自分たちだけで話し合いを続けるより、専門家に相談したほうがよい段階と考えられます。
- 見通しを何度確認しても、その都度、大きく遅延し続けている
- 開発会社からの連絡が滞り、進捗状況の共有そのものが止まっている
- 契約解除や違約金について、開発会社側と意見が対立している
- 既に支払った費用と、実際に完成した範囲が大きく見合わない状態になっている
相談先の選び方
契約トラブルに関する相談先としては、次のような窓口が考えられます。
- 弁護士：契約解除や違約金請求など、法的な対応を検討する場合
- 中小企業向けの相談窓口（商工会議所や自治体の経営相談窓口など）：契約トラブル全般について、まず相談したい場合
- IT関連の専門家（ITコーディネーターなど）：技術的な内容の妥当性について、第三者の意見を聞きたい場合
いずれの場合も、契約書・見積もり書・やり取りの記録（メール、チャットのログ、進捗報告書など）をあらかじめ整理しておくと、相談がスムーズに進みます。
納期の遅れを、次回以降の教訓にする
一度、納期の遅れを経験した場合、その原因を振り返り、次回以降の発注に活かすことをおすすめします。例えば、「要件定義が不十分だった」「追加依頼が多すぎた」といった原因が分かれば、次回の発注では、その点を改善できます。
振り返りで確認しておきたい観点
プロジェクトが完了した後、あるいは一区切りついた後に、次のような観点で振り返りを行うと、教訓を具体的な行動に落とし込みやすくなります。
- 当初の要件定義は、実際に必要な機能を十分にカバーしていたか
- 追加依頼は、どのタイミングで、どのくらいの頻度で発生したか
- 進捗報告の頻度・形式は、実際の進捗を把握するのに十分だったか
- 確認・承認への自分の対応スピードは、スケジュールに影響を与えていなかったか
- 契約書に、納期遅延時の取り決めが明記されていたか
次回の発注に活かす具体的な対策
振り返りで見えてきた課題は、次回発注時の準備に反映させることができます。
- 要件定義の段階で、機能の範囲をできるだけ具体的にリストアップし、開発会社と共有する
- 追加依頼が発生した場合の納期・費用への影響について、あらかじめ開発会社とルールを決めておく
- 進捗報告の頻度・形式（週次で、完成した機能のリストを共有してもらうなど）を、契約前に取り決めておく
- 確認・承認への対応期限を、自分自身のスケジュールとして事前に確保しておく
専門知識を活かしたツールの場合、納期遅延の原因になりやすい点
専門分野の業務ロジックを含むツールの場合、開発中に、想定していなかった業務の複雑さが判明することがあり、これが納期遅延の一因になることがあります。この場合、遅延の原因を一方的に責めるのではなく、開発会社と一緒に、現実的な対応（機能の優先順位の見直しなど）を検討することをおすすめします。
業務の複雑さが後から判明する典型例
個人・複業で立ち上げるサービスの中には、特定の業界・職種の専門知識を前提にしたツールも多くあります。こうしたツールでは、次のような複雑さが、開発が進んでから判明することがあります。
- 業界特有の例外処理（「通常はこうだが、この場合だけ計算方法が変わる」といったルール）が、要件定義の時点で漏れていた
- 利用者ごとに異なる運用ルールがあり、それを一つのシステムでどう吸収するかの検討が不足していた
- 関連する法令・ガイドラインへの対応が、開発着手後に必要だと分かった
このケースでの発注者側の役割
専門知識が絡む複雑さについては、開発会社だけで解決できないことも多く、発注者側の協力が欠かせません。次のような対応が有効です。
- 業務のルールや例外パターンを、思いつく限りドキュメント化して開発会社に共有する
- 「これは絶対に必要な機能」と「省略してもよい機能」を、自分の中で優先順位づけしておく
- 判明した複雑さについて、対応にどれくらいの追加期間が必要か、開発会社と一緒に見積もり直す
こうした協力によって、遅延の原因を単なる「開発会社の遅れ」として片付けず、双方が納得できる解決に近づけます。
業種・サービス別に見る、遅延の起きやすいパターン
個人・複業でのサービス立ち上げでは、業種やツールの性質によって、遅延の起きやすいポイントに違いがあります。ここでは代表的な3つのパターンを紹介します。自分のプロジェクトがどのパターンに近いかを知っておくと、遅延の兆候にも早く気づけるようになります。
パターン1：予約・マッチング系サービス
利用者と提供者をつなぐ予約・マッチング系のサービスでは、「同時に複数の予約が入った場合の処理」「キャンセル・変更時のルール」など、運用上の細かい条件分岐が多くなります。要件定義の段階でこれらを網羅しきれず、開発が進むにつれて「この場合はどうする」という確認が増え、その分の対応で遅延が生じやすい傾向があります。発注者側は、想定される利用シーンをできるだけ多く書き出し、早い段階で開発会社に共有しておくことが有効です。
パターン2：業務効率化・管理系ツール
特定の業務（経理、在庫管理、勤怠管理など）を効率化するツールでは、現場の運用ルールが、当初想定していたよりも複雑だったと後から判明することがよくあります。「基本的にはこの計算方法だが、この部署だけ例外がある」といった運用の実態が、要件定義の段階では見えていなかったケースです。このパターンでは、発注者自身が現場の運用を詳しく把握し、開発会社に共有できる体制を整えておくことが、遅延を防ぐ鍵になります。
パターン3：コミュニティ・SNS系サービス
利用者同士が交流するコミュニティ・SNS系のサービスでは、「不適切な投稿への対応」「通知の仕組み」「利用者間のトラブル防止策」など、機能として明確にしづらい要素が多く含まれます。こうした要素は、発注者自身も「あればいいな」程度のイメージしか持っていないことがあり、開発が進む中で具体化させる作業に時間がかかりがちです。発注前に、似たような既存サービスを参考にしながら、必要な機能をできるだけ具体的にイメージしておくことをおすすめします。
遅延の兆候を早期に見つけるためのセルフチェック
「様子を見る」時間を減らすには、遅延の兆候を早めに察知することが重要です。以下のセルフチェック項目を、定期的な進捗確認のタイミングで確認してみてください。当てはまる項目が増えるほど、遅延のリスクが高まっていると考えられます。
- [ ] 前回の進捗報告と比べて、完成した機能の数がほとんど増えていない
- [ ] 進捗報告の文面が、具体的な内容から曖昧な表現に変わってきている
- [ ] 「想定外の問題が発生した」という説明が、複数回続いている
- [ ] 担当者からの返信スピードが、以前よりも遅くなっている
- [ ] 定例の打ち合わせが、延期・短縮されることが増えている
- [ ] こちらからの質問に対する回答が、的確でなくなってきている
これらの兆候は、必ずしも開発会社の能力不足を意味するわけではありません。人員体制の変化や、他の案件との兼ね合いなど、さまざまな事情が背景にある場合もあります。ただし、兆候に気づいた時点で早めに声をかけることで、深刻な遅延に発展する前に対処できる可能性が高まります。
進捗確認の頻度と方法を、事前に取り決めておく
納期の遅れに気づいてから対応を考えるのではなく、そもそも遅れに気づきやすい体制を、契約の初期段階で作っておくことも有効です。
進捗報告のフォーマットを決めておく
進捗報告は、「順調です」といった一言で終わらせず、次のような項目を含む形式で共有してもらうよう、あらかじめ取り決めておくと、遅延の兆候をつかみやすくなります。
- 今回の報告期間中に完成した機能・作業内容
- 現在対応中の機能・作業内容と、その完了予定日
- 未着手の機能・作業内容と、着手予定日
- 発注者側からの確認・承認が必要な事項
定例ミーティングの頻度を決めておく
プロジェクトの規模にもよりますが、個人・複業レベルのサービス開発であれば、週1回程度の短い定例確認の場を設けておくことをおすすめします。定例の場があることで、「言うタイミングがなかった」という理由で問題の共有が遅れることを防げます。仕事の都合でリアルタイムのミーティングが難しい場合は、チャットやメールでの定期報告でも構いません。重要なのは、報告の頻度とタイミングを、感覚ではなくルールとして決めておくことです。
Q&A：納期の遅れについてよくある疑問
Q. 納期を過ぎても連絡が来ない場合、どうすればよいですか。
A. まずは、開発会社に直接連絡を取り、現在の状況を確認してください。連絡が来ないからといって、進捗が全く進んでいないとは限りませんが、状況を共有してもらえない状態が続くこと自体が、大きな問題です。連絡がつきにくい状態が続く場合は、契約書の内容を確認し、必要であれば専門家への相談も検討してください。
Q. 「バグの修正に時間がかかっている」と言われた場合、どう判断すればよいですか。
A. 技術的な内容の妥当性を発注者側だけで判断するのは難しいため、「そのバグによって、どの機能が、どのくらいの期間影響を受けているか」を具体的に聞くことをおすすめします。説明が曖昧なまま「もう少しかかります」を繰り返される場合は、進捗管理そのものに問題がある可能性を考えてください。
Q. 遅延を理由に、追加費用なしで機能を増やしてもらうことはできますか。
A. 遅延の原因が開発会社側にある場合は、その点について交渉の余地があるかもしれませんが、追加費用なしでの機能追加を前提にした話し合いは、関係を悪化させるリスクがあります。まずは、遅延の原因を客観的に整理し、契約内容を踏まえたうえで、現実的な対応（納期の再設定、優先順位の見直しなど）を相談することを優先してください。
Q. 納期の再設定を持ちかけられた場合、何を確認しておくべきですか。
A. 新しい納期を提示された際は、その日付をそのまま受け入れるのではなく、「その日付の根拠となる、機能ごとの完成予定」を併せて確認してください。また、以前の見通しがどのように狂ったのかを振り返り、新しい見通しにも同じ要因が影響しないか（例えば、確認・承認の対応スピードなど）を確認しておくと、二度目の遅延を防ぎやすくなります。可能であれば、新しい納期についても、途中に小さな確認ポイント（中間マイルストーン）を設けてもらうと、遅延の兆候をより早く察知できます。
Q. 開発会社を変更（リプレース）することも検討すべきでしょうか。
A. 開発会社の変更は、最後の選択肢として考えるべきものです。途中まで進んだ開発を別の会社に引き継ぐ場合、既存のソースコードや設計内容の把握に時間がかかり、結果的にさらに納期が延びることが多いためです。契約解除・引き継ぎを検討する場合は、まず契約書上の知的財産権・ソースコードの引き渡し条件を確認し、専門家に相談したうえで判断することをおすすめします。多くの場合、開発会社との話し合いを重ねて、現実的な範囲で完成を目指す方が、結果的に早く目的を達成できます。
この記事の次に読みたい記事
納期が遅れ始めたときの対応を理解したら、次は専門分野の業務知識を正確に伝える工夫についても確認しておきましょう。あわせて次の記事も参考にしてください。
