検収で発注者と揉めた実例｜「不具合」と指摘されたのは、要望に応え続けた末に残った当初の実装だった

検収とは、納品されたシステムが発注時に合意した内容どおりに動くかを発注者が確認し、受け入れるかどうかを判断する手続きです。決め方や期間の目安は検収・納品ガイドや検収チェックリストにまとめていますが、この記事はそれらの一般論ではなく、FUNBREWが実際に発注者と認識のズレを起こした場面と、検収が終わったあとに不具合の連絡が来たときの扱いを、開発会社の側から書いたものです。

検収で実際に揉めたのはどんな場面だったか

結論から言うと、揉めたのは「何をもって合格とするか」が、開発の途中で少しずつ動いていたことに双方が気づいていなかった場面です。バグの有無で揉めたのではなく、正しく動いているものが不具合として指摘されました。

要望に応え続けた結果、当初の実装が「不具合」に見えた

そのプロジェクトでは、開発の途中でお客様から出てくる要望に、私たちは都度応えていました。画面や動きの細かな変更が積み重なるうちに、最初の要件で合意して実装した部分と、途中の要望で変えた部分とが混ざった状態で検収に入りました。

検収の場で指摘を受けたのは、当初の合意どおりに作った機能でした。お客様の頭の中では、その後の要望で変わった姿がすでに「正しい仕様」になっていて、当初の実装が残っている箇所が、直し忘れや不具合に見えたのです。私たちの側から見れば仕様どおりですが、お客様の側から見れば頼んだものと違う。どちらも嘘をついていないのに、合格の基準が食い違っていました。

原因の一部は、開発会社側が変更履歴を残していなかったこと

このズレを開発会社の落ち度として認めるべき点があります。途中の要望をどこまで取り込み、どこは当初のままにしたのかを、私たちは記録として残していませんでした。記録があれば、検収の場で「この箇所は最初の合意どおりで、変更の対象には入っていません」と資料で示せたはずです。口頭のやりとりだけで進めた結果、指摘されたときに証拠がなく、お互いの記憶を突き合わせるしかなくなりました。

変更履歴を残す運用は、事前に相談しないと回らない

ここまで読むと「変更履歴を残せばよい」という単純な話に見えますが、実際にやろうとすると別の負担が生まれます。結論としては、どの程度きっちり管理するかを、着手前にお客様と相談して決めるのが現実的です。

要望を一件ずつ記録するなら、予算と変更にも敏感になる必要がある

変更履歴を正確に残す運用にすると、途中で出てきた要望を一件ずつ「これは当初の範囲か、追加か」と仕分けることになります。仕分ければ当然、追加分の見積もりや納期への影響を毎回確認する流れになり、要望のたびに予算の話が挟まります。気軽に頼めていたものが、都度の判断を求められるやりとりに変わります。

開発会社側の管理コストも増えます。記録を残し、合意を取り、資料を更新する時間は、開発そのものには使えない時間です。小さな要望に柔軟に応えるやり方と、変更を厳密に管理するやり方は、両立が難しいところがあります。

どちらの運用にするかを、着手前に決めておく

だからこそ、変更をどう扱うかは最初に相談しておくべきだと考えています。柔軟に応える代わりに、検収の基準は最終的な打ち合わせの内容で決めるのか。あるいは一件ずつ記録して、追加分は都度見積もるのか。どちらが正解というより、プロジェクトの規模や予算の余裕、お客様側で決められる人の距離によって向き不向きがあります。決めずに進めると、この記事で書いたようなズレが検収の場で表面化します。途中で見せながら進める大切さは納品後に「思っていたのと違う」と言われないためににも書きました。

検収が終わってから不具合が見つかったらどうしているか

結論としては、検収後に見つかった不具合には基本的に対応しています。ただし「不具合」と呼ばれるものの中には、開発会社が無償で受けづらいものが混ざります。線を引いているのは次の2つです。

時間が経って相対的に古くなったものは、不具合とは別

納品から時間が経ってから連絡が来る内容で注意しているのが、当時は問題がなかったものが、時間の経過で相対的に古くなったケースです。分かりやすいのがセキュリティの穴です。保守契約を結ばず運用を続けていたシステムで、あとからセキュリティ上の問題が見つかることは珍しくありません。納品当時は細心の注意を払って最新の状態で作ったとしても、その後に新しい攻撃手法や部品の欠陥が公表されれば、古い状態のまま置かれたシステムには穴が生まれます。

これは納品時点の不具合ではなく、時間の経過で生じた課題です。無償の不具合対応ではなく、保守や更新の相談として扱うのが筋だと考えています。保守を結んでいない場合にどうなるかは保証期間はどこまで無償かで詳しく書いています。

途中で変わった合意のうち、直されなかった部分

もう一つは、当初の合意で実装したものが途中で変更になり、その変更の一部が反映されないまま検収を通過した場合です。検収期間が終わってから「ここは変更したはずだ」と指摘を受けても、開発会社としては無償で受けづらいのが正直なところです。検収は、その時点の状態を発注者が確認して受け入れる手続きだからです。

ただ、これは最初の実例と地続きの話でもあります。変更の記録が残っていれば、どこまでが反映済みでどこが漏れたのかを検収の場で確認でき、期間が終わってから指摘が出る事態そのものを減らせます。無償か有償かの線引き以前に、検収の時点で双方が同じ資料を見ている状態を作ることが、いちばんの予防策です。

まとめ

FUNBREWが検収で揉めた実例は、バグではなく、要望に応え続けるうちに動いていた合格の基準が原因でした。変更履歴を残していなかった開発会社側の落ち度もあり、その反省から、変更をどう扱うかを着手前にお客様と相談する形にしています。検収後の不具合は基本的に対応しますが、時間の経過で相対的に古くなったものと、途中で変わった合意のうち直されなかった部分は、無償の不具合対応とは分けて考えています。検収の進め方そのものに不安がある方は、お問い合わせから状況をお聞かせください。開発会社としてどう対応してきたかを踏まえてお答えします。