仕様変更における追加報酬のトラブルを防止するためにはどうすればよいか

仕様変更をめぐるトラブル

仕様変更とは何か

　システム開発プロジェクトでは、一度仕様が合意されたあとも、プロジェクトの途中でユーザーから仕様を変更したり、機能を追加したりするように要望が上がることは珍しくありません。このような、仕様の合意後に、仕様が変更されることを「仕様変更」といい、法的には、当事者間で債務内容を変更するよう合意することであると評価できます。

　仕様変更があった場合、設計や開発作業のやり直しが必要になりますので、ベンダーはユーザーに対して追加報酬を請求することとなりますが、ユーザー側から、「ベンダーの作業は追加作業ではなく本来の作業範囲に含まれるものであるから、追加の報酬支払義務はない」などという反論がなされることがあり、追加報酬の支払義務を巡るトラブルが発生します。

トラブルの原因

　このようなトラブルが発生する原因としては、

1. 「本来の債務」の内容が明確ではなく、ある作業が追加作業なのか否かが不明確であること
2. 仕様変更をすることについて、明示的な合意をしないまま、追加作業が実施されてしまうこと

の2つがあげられます。
　以下、①と②についてそれぞれ考えてみましょう。

原因① - 仕様が不明確

　本来の債務の内容が明確ではなく、ある作業が追加作業にあたるのか否かが不明確であることにより、当事者間に見解の相違が発生し、トラブルが発生するという構図です。

　このような場合、「本来の債務」をいかに立証するかがポイントになります。仕様書を中心に、議事録やメモ、メールなどの多様な資料を元に、本来の債務を立証することになりますが、立証が困難な場合も少なからず存在します。

（注）顧客が本当に必要だったもの＝顧客が説明した要件は左上の絵にある「木にぶら下がった3段ブランコ」だったが、真の要求事項は右下の絵にある「木にぶらさがったタイヤ」であったというもの。このように、顧客は自分が本当に必要であるものをそのまま伝えることができず、また、そもそも自分にとって本当に必要なものは何かを理解できていないという例

　また、トラブルの原因が仕様書の不明確さにあるのですから、単純な話ですが、当初の仕様凍結の段階で「仕様の明確化を図ること」が、トラブルを防ぐための対策になります。具体的な方法については、「機能・仕様に関する紛争の発生原因と予防のためにベンダーがすべきこと」にて解説しましたので、そちらを参照してください。

　なお、システム開発の現場では、「新システムが備えるべき機能の内容は、現行システムの該当機能の内容と同様とする」という意味で、仕様書に「現行どおり」とか「現行踏襲とする」などと記載されることがあります。ベンダーとユーザーとが長期的な関係を持っており、ベンダーがユーザーの業務やシステムの内容に精通している場合などにこのような内容の仕様書が作成されることがありますが、曖昧な仕様の典型例とでもいうべきものです。ベンダーとユーザーとの関係性など、様々な事情を背景にしてこのような記載がなされてしまうのですが、トラブルの原因を作ることはユーザーにとっても望ましいことではありません。このような仕様書の書き方は避けるべきでしょう。

原因② - 仕様変更であることや追加報酬の合意が明確になされない

追加の合意

　仕様変更は契約の変更ですから、明確に合意がしてあれば、当然、ユーザーにはその合意の内容に従った追加報酬の支払義務が発生します。したがって、追加作業を行う前に、追加の合意をすることが、トラブル防止のための対策になります。

　しかし、現実のプロジェクトでは、仕様変更部分に関する報酬額について合意ができずにいるが、プロジェクトを予定どおりの時期に完了させるためには、作業を開始しなければならないといった事情により、明確な合意をしないままで作業を開始してしまうということがみられます。

　もっともこのような場合について、有償での作業を行う旨の合意が成立していたとする裁判例は少なくありません。理論的にも、明示的な追加代金支払いの合意がなくとも、承認であるベンダーが追加作業を実施した以上は、商法512条の趣旨に鑑みて、有償の合意（相当な対価を支払う旨の合意）があったと認められる場合が多いと考えられます。

　他方で、ユーザーとの関係性を壊したくないというベンダーの現場担当者の思いもあり、費用について曖昧なままにして、サービスとして無償で追加作業を行ってしまい、ユーザー側がこの作業は無償であると信頼をしてしまうようなケースであれば、追加費用請求ができなくなる可能性が高くなります。プロジェクトの進行状況により、個別の機能について、ユーザーと事前に協議をすることが困難であれば、「仕様変更にあたるか否かの判定を経て、別途費用について精算させていただきます」というような文言を差し入れることでも、後のトラブル時には一定の効果は見込めます。

前工程の要件定義書や基本設計書に不備があった場合

　なお、前工程の要件定義書や基本設計書に不備があった（たとえば、設計書の内容が業務に適合していないなど）ために、仕様変更が必要になったという場合には、どのように考えるべきでしょうか。ユーザーからすると、ベンダーの前工程での作業に不備があったために、後工程で作業が発生したわけですから、それに対する追加報酬を支払うというのは納得しにくいと思います。

　この問題については、仕様凍結までのプロセスがどのようなものであったかにもより、明らかな設計書の不備であれば、ベンダーの前工程の作業について不完全履行があったとして、ベンダーに追加作業分を負担させるという処理をすることも考えられます。しかし、ユーザーの業務はユーザーにしか決められないというのが原則であることを考えれば、仕様の確定の最終判断者であるユーザーが、要件定義書や基本設計書を承認したという事実を重視して、有償の仕様変更を原則とするのが妥当であると考えられます。

追加報酬の金額について

　仕様変更に関する合意が明確になされていない場合、追加報酬の金額が争いになることがありますが、ベンダーの標準単価をもとに、実際にベンダーが投入した工数を乗じた金額を追加報酬額とするのが妥当でしょう。

• 参考文献
• 裁判例から考えるシステム開発紛争の法律実務
• 著者：難波修一、中谷浩一、松尾剛行、尾城亮輔
• 定価：本体4,600円＋税
• 出版社：商事法務
• 発売年月：2017年2月