システム開発と開発委託契約の相性の悪さ
この記事は、法務系 Advent Calendar 2017のエントリーです。
テーマについては、昨年に引き続きAI(人工知能)関連にしようかとも考えたのですが、関心がある部分がAIとソフトウェア関連発明と少しマニアックなので、システム開発紛争にしました。
1．はじめに
システム開発紛争は、個人的にはストレスの高いというかめんどくさい訴訟類型です。このような紛争に巻き込まれないようにするためには、どうすればよいのかということをずーっと考えているのですが、とりあえず考えてきたことを吐き出します。ただ、これといった決定的な解決策はなく、想像に基づく部分もあるので、違うよということがあれば御指摘いただければと思います。
システム開発と言えば、すでに、Utastmさんが「民法改正とシステム開発 - 君の情熱がいつの日か」で書かれているように、開発委託契約と改正民法の関係が関心の高いところだと思います。が、今回はシステム開発と「システム開発契約書」、「開発委託契約書」というのは相性が悪いよねという話です。法務担当者としては、契約書（第○条と書かれている部分）をきちんと作成することは大前提なので、それはできていても、紛争は生じる（スルガ銀行対IBM事件でも契約条項は相対的にはきっちりしてます）、それは何故？、どうすればよいのという話です。
なお、私の場合は観測範囲としては、中小から中堅企業が中心です。また、システム開発に関して言うとどちらかというとユーザの立場よりというバイアスがかかっています。
2．問題の所在
（1）契約対象が確定できない
システム開発紛争が訴訟となった場合、「契約書」が主たる争点となると思われるでしょうか。ここでいう「契約書」というのは、第○条という条項がならんでいる契約書本文のことを指しています。
もちろん、損害賠償の責任条項等、契約書の文言が問題となる場合もありますが、契約書の文言について主張する割合（準備書面等に占める割合）は少ないです。契約書がなく、発注書と請書だけというのもありますし、そもそも「システム開発契約書」の本文では、何を作ってもらうかも明確に書いていないことが多いです。モデル契約（注1）もそうですが、具体的に何を作るのかや、具体的にどんな作業を行うのかは、個別契約で定めるとなっています。小規模な開発の場合は、個別契約がないことももちろんありますが、仕様書等で何を作るのかを特定します。
訴訟の観点から見れば、仕様書がシステム開発契約の本体です。結局のところ、何を作ってもらう事になっていたのかを探求するのが、システム開発訴訟進行上の多数の時間を占めます。契約は意思表示の合致によって生じますので （注2）、訴訟になると、証拠としても、議事録は当然として、開発中の電子メール等ありとあらゆるものが証拠としてでてきます。また、議事録等も単なる技術事項の確認もあれば、仕様や契約内容に関わるもの、といったように渾然一体となったもので、どの部分が訴訟に関わるのかも不明確です。これらの証拠に基づき主張をするので、主張も詳細かつ長いものになります。
本来、仕様書がちゃんと作られていれば、作る対象は明確になっているはずなので、あとはそれの通りにプログラムを作ればよいのですが、仕様書がある程度できていても紛争は生じます。
仕様書というものは、基本的には、言葉で書いてあるため、特にユーザ側からみると、何ができるのがイメージしにくいのです（画面については遷移画面が作成される事も有りますが、実際の使い勝手が把握できるかというと難しいです）。
また、ベンダ側も何を作って欲しいのかをつかみきれないのです。特にシステム開発の場合、ユーザ企業の業務と不可分一体の関係にあります。ユーザ企業の業務は同じような業種であっても内部の処理は様々です。この業務をベンダが把握できないので、仕様の策定がうまくいかないのです。
あとよくあるパターンとしては「現行システム」の置き換えに新規開発をプラスした開発です。「現行システム」の置き換えですから、何を作成しないといけないのか明確なはずですが、現行システムとはすなわちその企業の現行の業務体系であり、それをうまく仕様書に反映できるかはいろいろ問題があります 。問題点は、いくつか指摘されていますが、現行システム開発時点のドキュメント、人員が残っていない、ユーザ側も何をすればいいのか分からない、ベンダもよく分からない等の事情があります（注3）。
（2）仕様変更管理の問題
仕様変更かどうかという事も問題となりやすい類型です。これは仕様がきちんと確定できない、難しいということに起因します。なので、仕様変更の問題は必ず発生します。モデル契約書でも仕様変更管理の規定は盛り込まれています。
しかし、仕様変更管理規定が守られないことは実際多いです。法務の立場からするときちんと守れという話ですが、私は、そもそも仕様変更管理などというものは、実際は不可能を強いているのではないかという疑いをもっています。
当初の仕様確定がうまくできないのに、開発途中に仕様変更か否かを判断するのは時間の制約もある中で相当難しいのではないかということです。
（3）まとめ
以上のとおり、私の問題意識としては、ユーザ企業は何を作って欲しいのかうまく表現できない、ベンダは何を作ればよいのか分からないので、きちんと仕様書（契約）が作れない、そして、確定できない物を無理矢理確定しようとし、実態と合わない契約書とあいまって破綻をきたしているのではということです。
3．対応方法
対応方法として、いろいろ考えてみました。何か決定的な対応方法があるわけではありません。
（1）仕様変更管理を徹底する
仕様変更管理を徹底するといっても限界がありますが、現実的な対応です。仕様変更管理は、おそらく法務の方はあまり関わっていないと思うのですが、実質的には契約変更なので、規定を整備した上で、適度に関わっていただくことが重要なのだと考えています。すべての進捗会議に出席することは不可能でしょうし、無駄だと思いますが、開発の進捗が遅れる、予定工数が超過した場合等、何らかの基準を内部的に決めて、法務が関与したほうがいいと考えています。
あと、仕様変更は必ず発生することを前提に予算を組む必要があると思います。
訴訟になると仕様変更か否かは開発時の議事録を中心に話が進みます。議事録についても、記載されている要望と回答が、瑕疵対応なのか、仕様の追加なのか、確認、詳細化なのか等が不明確です。そのあたりフォーマットを工夫する必要があると思います（注4） 。
あと、仕様変更そのものの問題ではありませんが、仕様に関する要望は、ユーザ企業の利用者（現場でのシステムの利用者）からでてきます。ユーザ企業のシステム部門と利用者の調整をどうするのか、ここは私にはよくわからないところですが、法務がうまく関与する必要があるかもしれません。
（2）システム開発契約（業務委託契約）をやめる
すべて内製化する方法です。社外からユーザ企業の内部を把握することは困難なので、内部で開発しましょうということです。開発手法については、次に取り上げるアジャイル開発等、柔軟な開発手法が採用できます。開発に必要な人は、派遣、期間雇用等で外部から来てもらう。問題点としては、外部から必要な人材を調達できるか、おそらく費用は業務委託以上にコントロールできないのではないかということです。
また、システム開発契約の問題は回避できますが、今度は人事労務関係の問題がでてきます。
（3）アジャイル開発を業務委託として行う
ここまで検討してきたのは、いわゆるウオータフォール型の開発を前提としています。これは、仕様書を確定し、それに基づき設計書を作成し、プログラムを開発するという様に一旦決めた仕様（上流工程）に基づき開発する一方向型の契約です。色々な形態があるようですが、一定の反復（イテレーション）を定めて、反復的に開発を進めるという開発形態で、一方向に開発が進む点でウオータフォール型の開発とは異なります。
PoohSunnyさんの「法務部門へのスクラムの適用可能性についての一考察」
でとりあげられている「スクラム」の一形態がアジャイル開発と呼ばれているものだと認識（間違っていたらごめんなさい）しています。
Web系のサービスではよく使われている開発手法だと認識しています。UI（ユーザインターフェース）に関する部分については、とりあえずある程度実働するもの作成し、修正していくのは合理的な手法です。
イテレーションの反復の段階では、完成を観念しないので、どちらかというと内製化した場合と似てくると思います。基幹系のシステムをアジャイル開発でおこなうというのはあまり聞かないのですが、あまり行われていないとすれば予算の問題かと考えています。どれくらい修正することになるか工数が事前に読みづらいのでしょう。請負型ではなく、準委任型の契約形態がなじむと考えられています。
私自身、すべてアジャイル開発を採用する形の契約書は作成、検討したことはありません（IPAが公開している雛形もありますが、あまり使われているように見えません）。本来的には、業務委託ではなく、内製開発で採用するのがいいのだと思います。
ただ、開発に入る前の段階から契約書の作成、個別契約の作成、検収、導入の段階まで、必要に応じてアドバイスしたことがあり、その契約で一部アジャイル開発の条項をいれたことがあります。一部というのはユーザインターフェースのところで、金額の上限を入れています。ユーザインターフェースのところは、ユーザ企業側で一番不満が出やすいところですし、ユーザ企業内部で情報システム部門とシステム利用者（システム部門以外、役員含む）で利害が対立しやすい部分です。また、実際に触ってみると問題点が色々出てくるので、合理的な方法だと考えています。
4．おわりに
とりあえず、システム開発紛争を防止することができればと思い考えてみました。特にユーザ側はそれほど経験する機会があるわけではないので、少しでも参考になればと幸いです。
最後までお読みいただきありがとうございました。
次は＠mikannoomさんです。
よろしくお願い致します。
------------------------------
1）「情報システムの信頼性向上のための取引慣行・契約に関する研究会」～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第一版〉(経済産業省商務情報政策局情報処理振興課平成19年4月)
2）契約は、意思表示の合致により成立しますし、契約書を含む書面は不可欠ではありません。この点は、改正民法で明確化されています（改正民法522条）。改正民法は、請負に関する条項から「瑕疵担保」がなくなり、「契約不適合」となっていますが、現状の訴訟でも紛争は当事者で合意した「契約」内容と、契約内容と比較して完成していない機能等の探求に当てられており、この部分の変更はあまり影響しないのかと思っています。
3）このあたりの事情については、最近でた記事が参考になります（全文読むには登録が必要です）。「IT部門が唱える滅びの呪文「ゲンコウドオリ」の本当の恐怖」
4）ユーザ側からみると、ベンダに議事録作成を任せっきりというのもリスクがあります。