システム開発の保証期間はどこまで無償か｜有償になるのは開発以外の工数だった

システム開発を発注すると、納品・検収のあとに「保証期間」が設けられます。この期間に見つかった不具合は無償で直してもらえる、という理解は概ね正しいのですが、実際に揉めるのは「これは不具合なのか、新しい要望なのか」の境目です。ここでは、FUNBREWが実際に保証期間をどう設定し、どこで無償と有償を分けているかを書きます。

システム開発の保証期間とは何か

システム開発の保証期間とは、納品・検収のあとに見つかった不具合を、開発会社が追加費用なしで直す期間のことです。契約書に期間を明記して運用します。

保証期間は何ヶ月に設定するのか

FUNBREWの場合、保証期間は1〜3ヶ月に設定することがほとんどです。

• 多くの案件で1〜3ヶ月
• 期間が短くなるのは、プロジェクトの規模自体が小さいとき
• 期間は口頭ではなく契約書に記載する

発注側として最初に確認すべきなのは、この期間が契約書に書かれているかどうかです。書かれていなければ、納品後に「どこまでが保証か」を話す共通の土台がありません。

契約不適合責任と、契約書の保証期間は同じものか

別のものです。契約不適合責任は民法上の責任で、2020年4月1日施行の民法改正により、それまでの「瑕疵担保責任」から名称と内容が改められました（法務省「2020年4月1日から契約に関する民法のルールが変わります」）。請負契約については、注文者が不適合を知った時から1年以内に請負人へ通知することが求められます（民法第637条）。

一方、契約書に書く保証期間は当事者間の取り決めです。実務でまず参照するのは契約書に定めた保証期間になるため、個別の案件でどちらがどう効くかは、契約書の内容と合わせて確認してください。

検収後に「動かない」と言われたら、無償か有償か

結論から言うと、開発対象であれば無償で改修することがほとんどです。保証期間はそのためにあるので、バグか仕様かを細かく争うことはしていません。検収が終わったあとに「ここが動かない」と連絡が来た場合、それが当初の開発対象に含まれるものであれば、まず直します。

受け入れテストの期間を設けているのに、指摘が大量に来たとき

例外はここです。受け入れテストの期間を設けている中での連絡で、あまりに数が多い場合は、追加要望として捉えることがあります。何件からという基準を決めているわけではなく、内容を見ての判断になります。

この「不具合の指摘が、いつの間にか要望に変わっている」状態は、開発期間中にも同じ形で起こります。開発中に追加費用の話が出るときの判断軸はシステム開発で「これは追加費用です」と言われるのはどこからかで詳しく書いています。

実際に「これは有償です」と伝えたもの

これまで有償で対応させていただいたものを振り返ると、機能の話ではなく、開発以外の工数がはっきりと多くなっています。作るものの話ではなく、作ったあとに人が動く話です。

なぜ開発以外の工数が抜け落ちるのか

発注時の打ち合わせで話題になるのは、作る機能です。画面がいくつ必要か、どの業務を置き換えるか、という話が中心になります。そのため、打ち合わせ・連絡体制・データ移行・マニュアルといった、機能一覧に載らない作業は見積もりの外側に置かれやすくなります。

特にデータ移行とマニュアルは、当初は発注側が用意する予定だったものが、納品が近づいてから開発会社に回ってくることがあります。作業そのものが増えたというより、担当が動いた結果です。だからこそ、機能の範囲と同じくらい、開発以外の作業を誰がやるのかを最初に決めておく価値があります。

揉めないために、発注前に決めておくこと

前提として、要望が増えること自体は避けられません。作られたものを見て初めて気づくことがあるからです。問題は要望が増えることではなく、増えたときに「ここまでが当初の範囲だった」と示せるものが無いことです。

そのために、開発会社側で必ず用意すべきものが2つあります。

• 機能一覧 —— 「ここまでです」と示せる粒度で書いたもの。「ユーザー管理」のような大項目のままだと、解釈が人によって広がります
• 画面仕様書 —— 工数がかかっても必ず作ります。画面は発注側からも目に見えるので、認識を合わせる基準になります

この2つを作る工数は見積もりに乗ります。ただ、後から線引きで揉める時間と比べれば、先に払っておく方が見通しが立ちます。発注側としては、見積もりに仕様書作成の工数が入っているかを確認してみてください。入っていない場合、その分は後から別の形で表に出てくることがあります。

あわせて、開発以外の作業の担当も決めておきます。移行するデータは誰が作るのか、マニュアルは誰が書くのか、運用開始後の打ち合わせはどれくらいの頻度で、いつまで続けるのか。ここが決まっていれば、納品後に有償の相談をする場面自体が減ります。

それでも範囲が動くなら、請負ではなく準委任にする

機能一覧と画面仕様書を作っても、進めるうちに追加・修正が必要になり続けるプロジェクトはあります。その場合は請負開発ではなく、準委任契約にします。決めきってから作る前提の請負より、動かしながら決める形の方が実態に合っているからです。契約形態の違いはシステム開発の契約形態｜請負と準委任の違いにまとめています。

まとめ：保証期間で確認しておくこと

• 保証期間は1〜3ヶ月が多く、規模が小さい案件ほど短くなる。必ず契約書に記載してもらう
• 検収後に見つかった不具合は、開発対象であれば無償での改修がほとんど
• 受け入れテスト期間中の指摘が極端に多い場合は、追加要望として相談になることがある
• 有償になるのは機能ではなく開発以外の工数。運用の打ち合わせ、即応の連絡体制、データ移行、マニュアルが典型
• 効くのは保証期間の長さではなく、機能一覧と画面仕様書で範囲が示せること
• 範囲が動き続けるプロジェクトは、請負ではなく準委任にする

納品前の段階で認識のズレを見つける進め方は納品後に「思っていたのと違う」と言われないためにに、保証期間が切れたあとの費用の考え方はシステム保守の費用相場と選び方にまとめています。

いま進行中の案件で保証期間の範囲について判断に迷っている場合は、お問い合わせからご相談いただけます。