「ついでにこれも」で揉めないために、発注前に決めておく4つのこと

システム開発の追加費用で揉めるのは、頼んだ内容の良し悪しよりも、「範囲の中」と「範囲の外」の境目が書面になっていないことのほうが、きっかけになりがちです。発注の前に4つだけ決めておくと、請求書の段階で話がぶつかりにくくなります。

追加費用は、どこから出てくるのか

出どころは3つに分けられます。

1つ目は、頼む側が要件を変えるときです。機能を足したい、決めた業務の流れを変えたい。どのプロジェクトでも普通に起きますし、変更を頼むこと自体は悪いことではありません。

2つ目は、もともとの依頼があいまいに書かれていて、作る側が「これは範囲の外です」と扱う場合です。

3つ目は、チャットや電話で頼んだ作業がその場で始まり、あとから請求書に別の行として載る場合です。チャットで「ついでにこれもお願いします」と書いて、「いいですね」と返ってきた。そのやり取りを、請求のときに誰も覚えていないことがあります。

2つ目と3つ目は、書面の問題です。ここから先の4つは、この2つに備えるためのものです。

発注前に決めておく4つのこと

1. 範囲の基準にする文書を、1つ決める。 「必要な機能一式」ではなく、どの文書の、いつの版を基準にするかを決めます。見積書でも構いません。基準がないと、何が変更なのかを言えなくなります。

2. 変更を頼む人と、承認する人を決める。 お互いの役職まで書いておくと安心です。権限のない人がチャットで「それでお願いします」と返してしまうのを防げます。

3. 変更の見積もりに、書いてもらうことを決める。 金額だけでは足りません。納期がどれだけ動くかも、一緒に書いてもらいます。金額が小さくても、納期が2週間延びるなら判断は変わります。

4. 承認しなかったときは、元のままで進むと決める。 見積もりを見て「今回は見送ります」と言えることが前提です。見送ったら、元の範囲と元の価格のまま続きます。

契約書という形のものがない取引でも、この4つは見積書や、依頼時のやり取りに書いておけます。メッセージの文面で十分です。

私たちの場合

私たちは、範囲の外の作業を、次の順で扱っています。変更依頼として記録し、費用と納期への影響を書面でお出しし、承認をいただいてから着手します。承認がなければ作業せず、請求もしません。「ご承認いただいていない作業の請求書をお送りすることはありません」とお伝えしています。

チャットで頼まれたことも同じです。その場で手を動かすことはせず、フィードバックを管理するファイルに記録するか、作業の一覧（バックログ）のタスクにします。そのうえで、金額と、範囲の外であれば納期への影響を添えて、確認をお願いします。

この流れが成り立つのは、基準になる文書があるときです。文書がなければ、何が範囲の外なのかを決められません。

見積もりで気をつけたい兆候

見積もりの段階で、追加費用の兆候が見えることがあります。

・固定価格なのに、その価格がどの文書にもとづくのか書かれていない ・範囲が「必要な機能を含む」としか書かれていない ・変更について、「発生したらご相談」の一言しかない

3つとも、頼まれる側が悪いとは限りません。ただ、聞いておいて損はありません。「この金額は、どの文書にもとづいていますか」「途中で変えたくなったとき、何をいただけますか」。この2つなら、見積もりの返事にそのまま添えられます。

手順では解決しないこと

変更の手順は、変更にかかる費用そのものをなくすものではありません。妥当な変更には、やはり費用も時間もかかります。違いは、同意する前に金額がわかることです。

頼む側の時間もかかります。依頼のたびに、権限のある方が読んで返事をすることになります。その方が不在がちなら、代理の方を最初に決めておいてください。

この記事は、一般的な情報で、法的な助言ではありません。契約の文言については、弁護士にご確認ください。

出典：経済産業省・IPA「情報システム・モデル取引・契約書」(第二版、2020年)に、変更管理の手続きの条項が含まれています

このブログでは、オフショア開発とベトナムのことを続けて書いています。続きを読みたい方は、フォローしていただけるとうれしいです。