手戻りをしない前提のウォーターフォールを採用した場合、手戻りをしない以上、本来的には、要件定義や基本設計でソフトウェアの仕様が完璧に固められている必要があります。
とすれば、遅くとも基本設計を終えた時点で、ソフトウェア開発にかかる全体報酬に関し、高精度の見積もりをベンダが提示することも、本来可能となるはずです。
他方で、仕様を完璧に固めることは困難であることがほとんどであるとも考えられます。
とすれば、たとえウォーターフォールを採用する場合であっても、手戻りをする前提での契約を締結をすべき場合は少なくありません。
例えば、手戻りをする前提で、契約時に報酬額を完全に固定しないことや、手戻りの回数を予め決めておくことを内容とする契約を締結することが考えられます。
どのような契約とするかは、あくまでも契約の対象となるプロジェクトによって決められるべきなのです。
ソフトウェア開発委託契約では、基本契約と個別契約とが締結され、個別契約によって契約全体が細分化されるケースがよく見受けられます。
契約を細分化する目的は複数考えられますが、その目的を達成するために契約を細分化する必要が必ずしもない場合にまで契約が細分化され、かえって有害無益となっている場合もあります。
基本的には、契約の細分化により生じる差異は、次の契約を締結するかどうかの選択の自由を与えるか否かという点、精度を高めた再見積、開発スケジュールや見積報酬の変更が発生するか否かという点くらいといっても過言ではありません。
それ以外の、例えば、報酬の支払時期や契約解除の効力が及ぶ範囲については、一括契約と多段階契約とで、必ずしも違いが生じるものではありません。
ウォーターフォールを採用するとしても、なんとなくで多段階契約を締結するのではなく、そのプロジェクトではどのようなソフトウェアの開発を行うのか、プロジェクトの見通しはどのようになりそうか、プロジェクトに関する見直しのタイミングはどの程度必要となりそうか、といった点などを考慮した上で、当該プロジェクトに適切な契約類型を選択すべきと考えられます。
定型処理を行う小規模システムの開発等、要件定義を行う前であっても、打ち合わせを経ることによって開発対象が特定され、ソフトウェア開発にかかる全体報酬の算定が可能となる場合もあると思われます。
このような場合にまであえて契約を細分化すると、かえって契約交渉や締結に際して時間がかかってしまい、契約交渉等のため開発スケジュールに支障が生じることにもなりかねません。
契約の細分化は必要十分程度に抑えるべきという見地から、そのような場合には、要件定義からテストまで一括してベンダが請け負うという契約類型を採用することも、一考に値するものと考えられます。
一括契約とする場合、請負契約となることがほとんどでしょう。
以上の条件をもってしても、ベンダとしては、全体報酬を要件定義前に算定することがやはり無視できないリスクであると捉えることはあり得るところです。
他方で、たとえ一括契約を締結したとしても、必ずしも契約締結時にベンダの報酬をすべて決定しなければならないことにはなりません。
ある程度の見積もりとのズレが生じることを予測して、全体報酬の上限を定め、ソフトウェア開発終了後、その範囲内で報酬額を決定するという契約をすることも可能なのです。
また、途中で契約解除に至った場合には、ベンダがユーザに報酬を請求できないのではないかという懸念もあるかと思います。
しかし、改正法で明記されたように、ベンダが完成させた割合に応じた報酬をユーザに請求することが可能です。場合によっては、損害賠償という形で、報酬全額相当の支払を受けることができるかもしれません。
他方で、要件定義や基本設計を行わなければ開発対象が特定されず、ソフトウェア開発にかかる全体報酬の算定が不可能ないし困難な場合には、一括契約は適当ではありません。
一括契約では、ベンダ側としては、過小見積リスクを負うこととなりますし、ユーザ側としても、過小見積リスクを懸念した高額な見積を提示されるリスクを負うこととなります。
もちろん、全体報酬の上限を定める契約を締結することも可能ですが、開発契約すら特定されていない状況では、上限を適切に設定すること自体も不可能ないし困難といえます。
そこで、このような場合には、多段階契約が適当であると考えられます。
上述のとおり、一括契約が適当である場合はかなり限定されるものと考えられます。
すなわち、要件定義前や基本設計前の段階において、開発対象が特定され、ソフトウェア開発にかかる全体報酬の算定が可能な場合は、必ずしも多いとはいえないと考えられます。
基本設計が終了した場合には、開発対象は特定され、不確定要素は少なくなり、全体報酬の精度の高い見積も可能となるものと考えられます。
もちろん、手戻りの可能性もありますが、手戻りをしない前提であれば、この時点で仕様を凍結させるような契約にしておくことが考えられます。また、手戻りをする前提であれば、再見積を行えるような契約にしておくのが通常でしょう。
何段階の契約とするのかは個別の事情によるところではありますが、4段階の契約で足りることが多いのではないかと思われます。
すなわち、①要件定義に関する個別契約、②基本設計段階に関する個別契約、③詳細設計段階から開発に関する個別契約、④運用テスト等以降に関する個別契約、といった4段階の契約が考えられるところです。
この場合には、②の契約交渉段階において、全体報酬や開発スケジュールの見直しを行うことができますし、③の契約交渉段階においても、その見直しを行うことができます。また、ユーザ側としては、②や③の契約交渉段階において、他ベンダに変更するか否かの検討を行うこともできます。
なお、契約の性質については、①は準委任契約、③は請負契約となることが通常でしょう。また、②と④は、ベンダとユーザがどのような役割分担となるかによって、準委任契約となる場合もあれば、請負契約となる場合もあるでしょう。
ところで、もちろん4段階以上の契約をすることが合理的な場合も存在します。
しかし、上述したとおり、契約の細分化は、契約交渉や契約締結の手間が増えるだけで、かえって有害無益となることもあるところです。
したがって、プロジェクトの内容に応じて適切な数の契約を締結することが、ソフトウェア開発委託契約では重要となります。
アジャイルを採用した場合、スコープを確定しないまま開発を進めるため、これを確定しつつ、見積と契約を繰り返すこととなります。
アジャイルを採用した場合には、仕様凍結ができないこと等を原因とするコスト超過のリスクがついてまわります。
また、仕様を固める前に開発を行うわけですから、見積が複数回にわたって繰り返されることが前提となります。
そこで、仕様凍結を確実に行うため、仕様変更の受入期限を契約で定めておく必要があるでしょう。この受入期限との関係では、イテレーションの回数制限を契約上設けることも考えられます。
また、何度も見積を繰り返すことから、イテレーションの期間を定めるとともに、再見積のタイミングを定めておくべきということになります。
なお、開発手法上、偽装請負となるリスクが相対的に高まるため、偽装請負とならないような体制を契約で定めておく必要も生じると考えられます。
ちなみに、スコープが確定しない以上、請負契約ではなく、準委任契約となることが多いと考えられます。
他方で、あるタイミングで遡及的に請負契約のような契約とすることも可能であり、すべては締結する契約次第ということとなります。
その他、スパイラルやプロトタイプ等の開発手法もありますが、いずれも上述した視点が必要となることには変わりないため、ここでの記載は省略します。
受付: 10:00~18:00 / 土日祝を除く