納期トラブルが起きた時の責任の所在｜契約と工程の観点から整理する
「納期に間に合いません」——その一言で始まる、責任の押し付け合い
システム開発プロジェクトの終盤で、ベンダーから「納期に間に合わない可能性があります」と告げられる。発注側の担当者にとって、これほど胃が痛くなる瞬間はありません。社内へどう説明するか、スケジュールをどう調整するか、頭を悩ませる中で必ず出てくる問いがあります。「これは、どちらの責任なのか」。
この問いに感情的に答えようとすると、たいてい泥沼化します。「そもそも見積もりが甘かったのでは」「いや、仕様変更が多すぎた」「いやいや、確認の返事が遅かったのはそちらでは」——お互いの主張は平行線をたどり、肝心の「今後どうするか」の議論に進めなくなってしまいます。
感情で押し問答しても、誰も得をしない
厄介なのは、納期トラブルの責任の所在は、単純な白黒では決められないことがほとんどだという点です。発注者の要件確定の遅れ、ベンダー側の見積もり精度、途中の仕様変更、外部システムとの連携不備——複数の要因が絡み合って遅延は発生します。
それにもかかわらず、感情的な押し問答に時間を使ってしまうと、次の2つを両方とも失います。ひとつは、費用や納期の再調整という目の前の実務的な合意。もうひとつは、今後も付き合いを続けるかもしれない相手との信頼関係です。責任の所在は、犯人を決めて相手を追い詰めるためではなく、公平な着地点を見つけ、同じ失敗を繰り返さないために整理するものだと捉え直す必要があります。
責任の所在は「契約」と「工程」の2つの観点から整理できる
この記事では、納期トラブルが起きたときに責任の所在を感情論ではなく整理する方法として、契約の観点と工程の観点という2つの軸を紹介します。契約の観点では、準委任契約と請負契約で責任の性質がどう異なるかを整理します。工程の観点では、遅延の原因がどの工程段階に遡るかを特定する考え方を解説します。この2軸で状況を整理すると、感情を排して建設的な話し合いに進めるようになります。
契約と工程、2つの観点から責任を整理する
責任の所在を整理する3つの視点
視点1: 契約形態による責任の違いを理解する
まず押さえるべきは、契約形態によって「何に対して責任を負っているか」がまったく異なるという点です。
請負契約の場合、ベンダーは成果物の完成に責任を負います。納期に成果物が完成しなければ、原則としてベンダー側の債務不履行となり、遅延損害金や契約解除といった話に発展し得ます。ただし、発注者側の要件確定の遅れや、仕様変更の指示が遅延の原因であれば、その分はベンダーの責任から除外されるべきという考え方が一般的です。
準委任契約の場合、ベンダーは決められた業務を「善良な管理者の注意をもって遂行する義務（善管注意義務）」を負いますが、成果物の完成そのものを約束しているわけではありません。したがって、準委任契約下での納期遅延は、直ちにベンダーの契約違反にはなりません。むしろ、進捗管理や情報共有が適切に行われていたか、発注者側の意思決定が滞っていなかったかなど、双方の協力義務の履行状況が問われます。
契約書に立ち返り、「今回のプロジェクトはどちらの契約形態か」「責任の範囲についてどう定められているか」を確認することが、責任整理の出発点になります。
視点2: 遅延の原因を工程のどの段階に遡って特定するか
契約形態を確認したら、次は遅延の原因が工程のどの段階で発生したかを時系列で遡って特定します。納期遅延は、テストフェーズなど終盤の工程で表面化することが多いのですが、真の原因はもっと上流の工程に潜んでいるケースが少なくありません。
- 要件定義段階の原因：要件確定が遅れた、確定した要件があいまいだった
- 設計段階の原因：外部システム連携や非機能要件の考慮が不足していた
- 開発段階の原因：見積もりの精度不足、体制やスキルのミスマッチ
- テスト段階の原因：テスト計画が不十分で、終盤に不具合が集中発覚した
「なぜ遅れたのか」を1段階だけで判断せず、3〜4段階遡って掘り下げると、表面化した工程の担当者だけでなく、その手前の工程における意思決定や情報共有の欠落が見えてきます。責任は、遅延が発覚した工程ではなく、原因が生まれた工程に紐づけて考えるべきです。
視点3: 責任分界点をあらかじめ文書で明確にしておく
視点1・2はトラブルが起きた後の整理ですが、最も効果的なのはトラブルが起きる前に手を打つことです。プロジェクト開始時点で、どの工程・どの意思決定の責任が発注者側にあり、どこからがベンダー側にあるかという責任分界点を、契約書や仕様書レベルで明文化しておきます。
具体的には、要件定義の最終承認は発注者が行う、承認後の仕様変更は変更管理プロセスを経る、進捗報告の頻度と形式を定めておく、といった取り決めです。これらが事前に文書化されていれば、トラブル発生時の責任整理は「言った言わない」の水掛け論ではなく、合意済みのルールに照らした確認作業に変わります。
こうした契約設計や進行管理の仕組みづくりに不安がある場合は、開発を依頼する段階から第三者の視点を入れるのも有効です。私たちのアトリエ・バイナリ（atelier binary）でも、契約形態の整理を含めたプロジェクト立ち上げの伴走をお手伝いしています。
責任分界点を事前に文書で明確にする
こんな方におすすめ
- 現在まさに納期トラブルの渦中にいて、責任の所在をどう整理すればよいか悩んでいる発注担当者
- ベンダーとの契約が請負・準委任のどちらか曖昧なまま進行しているプロジェクトの責任者
- 今後の開発案件で、同じような責任の押し付け合いを防ぐための契約設計を見直したい経営者・情報システム責任者
責任の所在を整理する目的は、相手を追い詰めることではなく、公平な着地点を見つけて前に進むことです。契約と工程という2つのものさしを持つことで、その議論は驚くほど建設的になります。
まとめ
契約と工程の観点で整理され、前に進むプロジェクトチーム
納期トラブルが起きたときの責任の所在を、契約と工程の2つの観点から整理する方法を紹介しました。
- 契約形態の違いを理解する——請負なら成果物の完成責任、準委任なら善管注意義務という前提の違いを押さえる
- 遅延の原因を工程段階まで遡って特定する——表面化した工程ではなく、原因が生まれた工程に責任を紐づける
- 責任分界点を事前に文書化しておく——トラブル後の水掛け論を防ぐ、最も効果的な予防策
納期トラブルの責任整理は、感情論から契約と工程という2つの軸に切り替えるだけで、驚くほど冷静な話し合いが可能になります。もし現在進行中のプロジェクトで契約や責任分界点に不安がある場合は、早めに専門家に相談することをおすすめします。
アトリエ・バイナリでは、開発プロジェクトの契約設計から進行管理、トラブル発生時の第三者診断まで幅広くご相談いただけます。まずは現状をお聞かせください。
