バグか仕様変更か｜追加費用で揉める4か所と防ぎ方

画面ができてきた、と連絡が来て、触ってみる。案件の一覧が、古い順に並んでいた。新しい順で見たいと伝えたら、それは仕様変更にあたるので追加のお見積りになります、と返ってきた。金額と、数日の納期延長がついている。

言われた側は判断がつかない。並び順くらい当然そうなると思っていたし、かといって最初にそう頼んだ覚えもない。押し切れば角が立つし、そのまま飲めば次も同じことが起きる。ここで手が止まる。

先に線を書いておく。決めたとおりに動いていなければバグ、決めていないことを新しく決めるなら変更だ。判定するのは記憶でも、どちらの言い分がもっともらしいかでもなく、着手の前に交わした紙のほうである。

分ける線は、着手前の紙にある

バグは、決めた仕様のとおりに動いていない状態のこと。仕様変更は、書いてある内容を変える、あるいは足すこと。この二つだけなら判定は難しくない。紙を開いて、その行があるかどうかを見ればいい。

揉めるのは三つ目の場合だ。紙にその項目が書かれていない。書いていないのだから、違反もしていないし、変更にも当たらない。どちらでもない場所で、両者の当たり前がぶつかっている。追加費用の話がこじれるのは、たいていここになる。

つまりこれは、開発者の腕や誠実さの話ではなく、紙の話だ。以降は着手前に画面の一覧と「やらないこと」を書いた紙がある前提で進める。無いのであれば線を引く材料そのものが無いので、今からでも作るところから始めてください。

実際に割れるのは、この4か所

書き漏れる場所は、だいたい決まっている。派手な機能ではない。誰も口に出さないまま、双方が当然そうなると思っている細部だ。入力チェックの厳しさ、一覧の並び順、印刷の体裁、権限の細かさ。この4つでよく割れる。

どれも「顧客管理の画面」と一行書いた紙には現れない。開発側は動く形を先に作るので、必須の欄も並び順も、その場でいちばん素直な形を選ぶ。依頼側は今の紙やExcelでやっている形をそのまま思い浮かべている。ぶつかるのは画面が出来てからだ。

金額を扱うなら、もう一つ足しておきたい。端数の丸め方だ。切り捨てか四捨五入か、消費税を明細ごとに計算するか合計にかけるか。ここを決めずに進むと、後から「合わない」と言われて、それがバグなのか変更なのかで必ず割れる。全部の画面で同じ扱いにする、と一行あれば済む。

「修正2回」の1回は、何を指すのか

範囲の次に割れるのが、回数の数え方だ。当方も無償で受ける修正の回数を先に決めているが、その1回が何を指すのかまでは、書いておかないと合わない。ここは金額そのものより、終わったあとの後味に効いてくる。

気づくたびに1件ずつ送ると、送った回数だけ消えていくことがある。まとめて十件送れば、それで1回と数える形もある。同じ「2回まで」でも直せる量が何倍も変わるので、どちらの数え方かを着手前に聞いておいてください。

合わせて確かめておきたいのが、バグは回数に数えない、という点だ。決めたとおりに動いていないものを直すのは、修正の枠を使う話ではない。当方はお渡しから14日間を、そのまま動くかどうかを見ていただく期間として無償で扱っている。

直してほしい点は、触ってから、まとめて出す。

画面を見る前に想像で出した要望は、実物を触ると半分ほど消える。逆に、触って初めて出てくるものもある。何日か使ってみる期間を先に決めて、そのぶんを一通にまとめるほうが、消える回数もやり取りの往復も減る。

変更を頼むと決めたら、その場で二つ聞く

書いていなかったと分かって、それでも必要だと判断したなら、変更として頼めばいい。並び順ひとつで毎日の手間が変わるなら、払う価値はある。そこは堂々と頼んでよいところだ。ただし、聞き方に一つだけ型がある。

金額と納期を、同時に聞く。金額だけ聞いて進めると、渡す日のほうは後からまとめて動く。三件ためた頃には二週間ずれていた、という形になりやすい。金額はその場で出せても納期は読めない、という返事なら、読めるようになるまで着手を待ってもらったほうがいい。

決めた内容は一行でよいので文字に残す。ココナラのメッセージのように、やり取りがそのまま残る場所であれば、改めて書面を作る必要はない。並び順を新しい順に変更、追加はいくら、納期は何日延びる。それだけ書いてあれば足りる。

増やす前に、「今回はやらない」に置く

費用を抑える手がもう一つある。今すぐ決めずに、「今回はやらない」欄に置くことだ。消すのではなく、置いておく。変更として頼むか諦めるかの二択にしないほうがいい。三つ目の置き場所があると、その場で無理に決めずに済む。

使い始める前に思いついた機能は、動かしてみると要らなかった、ということが珍しくない。稼働してから足せば、その頃には本当に必要かどうかが分かっている。判断の材料が増えてから払うほうが、同じ金額でも外れにくい。

ただし例外がある。締め処理と帳票、それに履歴の残し方だ。締めた月の数字は後から動かさず、直すなら取り消しの記録を足す。この作りは後から入れるとデータの持ち方そのものに手が入り、全部の画面に影響する。先に決めておくほうが安く済む。

揉めるのは悪意ではなく、思い込みから

追加費用でこじれた話を聞いていると、どちらかが嘘をついていることはあまりない。開発側は自分が書いた範囲を見ていて、依頼側は完成した業務の姿を見ている。両方とも本気でそう思っている。

だから、揉めたら人ではなく紙を見る。紙に書いていないなら、それは紙の不足であって、どちらか一方の落ち度ではない。今回は無償で直し、以降は同じ種類のものも変更として扱う。そういう半分ずつの落とし所も、紙を見た後なら出しやすい。着手前に「やらないこと」を書いておく手間は、この一回を避けるためにある。

---

当方は元金融系のシステムエンジニアで、Excel・紙で回している業務を月額0円の買い切りWebアプリにする仕事をしている。着手の前に画面の一覧と「やらないこと」を1枚にまとめてお渡しし、修正の回数とお渡し後のバグ対応の日数を先に決めてからお受けしています。他所に出した見積りの線引きで迷っている段階でも構いませんので、ココナラのメッセージからご相談ください。