開発契約での留意点

私たちは物事を話し合いで解決する慣習があり，あまり契約書を重視していませんでした。しかも，情報システムの開発には，情報システム特有の事項が多いので，経営者は辟易しがちです。ところが，情報システムは複雑ですので，当初の期待通りにはいかない場合が発生します。そのとき，契約があいまいだと，いろいろなトラブルが発生する危険があります。

情報システム構築のプロセスと契約範囲

情報システムの構築は，大まかに次のプロセスに区分できます。これをソフトウェア開発のライフサイクルといいます。

要求分析: 対象とする情報システムへの要件を整理して，取り入れる要件と除外する要件を決定します。
外部設計: 「外部」とは，コンピュータを内部としたときの外部で，人間のことです。要求分析により，構築する情報システムの機能を，関係者が理解しやすい文書にします。これが「システム仕様書」になります。なお，ここまでのプロセスを上流プロセス，内部設計以降を下流プロセスということがあります。
内部設計: 情報システム開発者（プログラマなど）に理解させるための仕様書です。業務用語で書かれた外部仕様書をコンピュータ用語に翻訳したようなものです。
プログラミング: 実際にプログラムやデータを作成します。
テスト: 出来上がったプログラムや全体としてのシステムに，エラーがないか期待通りに動作するかを確認します。
実施: 一定期間従来の作業と新規システムを並行的に行い，満足な結果が得られたら実施に入ります。

上流・下流分離か，一括契約か

契約をするとき，システム仕様作成までの上流プロセスだけを契約するのか，システム開発の下流プロセスまでも一括して契約するのかに区分できます。

本来は，上流プロセスと下流プロセスを分離してベンダを選択して契約するべきです。

ベンダには，コンサルタント会社から発展して上流プロセスを得意とするベンダと，プログラム受注を主業務としてきた下流プロセスを得意としたベンダがあります。それらを使い分けるのが得策です。
上流プロセスでは特定のベンダの製品や技術に固定しないで，最適な情報システムを検討するべきです。下流プロセスまで受託するとなると，どうしてもベンダは自社の状況を考えてしまいます。

しかし，一括したほうが便利なこともあります。

ベンダが発注者の状況やニーズを理解しているので，繰り返して説明する必要がない。そのために費用や期間を節約できます。
分離したのでは，理想的に走りすぎて現実に構築するのが困難なシステム仕様書になる危険がありますが，一括契約では実現もベンダの責任ですので，実現しやすいシステム仕様書になります。

一般に中小企業では，開発対象が小規模であること，分離して管理するだけの能力が乏しいことから，一括契約にするのが通常です。でも，同じベンダに発注するにしても，上流プロセスと下流プロセスにわけて，システム仕様書ができるまでを当初の契約として，それを承認した時点で開発の契約にするのが適切です。
　中小企業では，提案依頼書の作成，提案書の理解，ベンダとのコミュニケーションなどが不十分ですので，提案書とシステム仕様書の間には大きな相違があり，見積金額も大きなギャップが生じてトラブルになる危険があります。上流と下流の間で見直しをする機会を明確にしておくべきです。

運用をどうするか

特に中小企業では，自社にコンピュータを設置して運用するのではなく，外部のセンターのコンピュータをネットワークで利用することも考えられます。特にインターネットを利用する情報システムでは，情報セキュリティ対策の面からも，運用をアウトソーシングするほうが適切です。
　それで，下流プロセスの契約では，単にシステム開発を委託するのか，その運用までも含めて契約するのかを検討するべきです。最近では，ハードウェアたけでなく汎用的な業務の情報システムや運用までも受託するＡＳＰという業態も増加しています。それを前提とするならば，契約の内容も変化します。

このように契約の範囲はまちまちですが，ここではシステム開発だけを一括して契約するケースに限定します。

開発に伴う発注者とベンダ間でのトラブル

発注者とベンダの間でのトラブルは多様ですが，システム仕様書が確定するまでのトラブル，システム開発の過程においてシステム仕様書の範囲解釈に関するトラブル，機能以外でのトラブルに区分できます。

システム仕様書策定までのトラブル

要求分析での追加事項: 提案依頼書や提案書が完璧であれば，要求分析は単に要件の確認作業だけになるはずですが，現実にはこの段階で新しい要求や条件が発見されます。それで提案書での見積金額と契約での金額に大きな違いが出てきます。ベンダは，提案依頼書段階よりも多くの要求や条件になったのだから金額を上げるべきだと主張しますし，発注側は，ベンダはプロなのだから，その程度の違いは織り込んで提案したはずだと主張します。逆に，当初は可能だと思っていた機能が，調査により見送られてしまうこともあります。それを値引きするかどうかでの対立もあります。
外部設計までの時間: また，この要求分析に多大の時間がかかることもよくあります。ベンダにとっては費用が発生しますし，納期遅れの原因になります。
その原因には，ベンダが業務をよく知らないために，それを理解するのに時間がかかるというベンダ側の責任もありますし，発注側が関係者の間で相互に矛盾する要求を出すなど，事前に十分に要件を整理していなかいことが原因の場合もあります。その責任をなすりあうこともよくあります。

システム仕様書策定以降のトラブル

仕様変更に伴うトラブル: 「システム仕様書」が承認された後で，その不備に気づくことがあります。特に下流プロセスに入ってから，上流プロセスでの不都合が発見されると，そのための手戻りに非常な費用や時間がかかります。その原因にもベンダ側の理解不十分によるものもあるし，発注側のチェックが不十分なことに起因するものもありますが，特に後者の場合，仕様変更なのか単なる仕様確認であるかが争点になります。
実施後のトラブル: 情報システムのすべてをテストで発見することは不可能です。実際に使う段になってから発見されるエラーもあります。たまたまエラーのある部分を使わずに長期間過ごした後で，そのエラーが発見されたときどうするかが問題になります。また，関係者全員が開発プロジェクトに従事しているわけではありません。実施段階になってから新しい関係者から致命的な欠陥を指摘されることもあります。
ベンダは要員をこのプロジェクトにいつまでも張り付けておくことはできません。他のプロジェクトに従事しています。このようなトラブルが発生したとき，事情の知らない担当者になると，対処をめぐって大きな問題になります。

間接的なトラブル

情報システムの仕様に関する以外にも，多様なトラブルの原因があります。

当初にデータ量が明確に示されていなかったか予測が不適切であったために，ハードウェアを追加購入したり，ソフトウェアの設計を変更する必要が出てくることがあります。
たとえばＷindowsやLinuxなどＯＳ欠陥があるとか，第三者ソフトの予定されていた次期バージョンの提供が遅れたなど，第三者に起因する事情で作業に大きな手直しが発生したとき，その費用をどうするかという問題があります。
作成したプログラムの一部を他のシステムでコピーして使うときには，プログラムの著作権が発注者とベンダのどちらにあるのかが問題になります。
受注者の秘密事項の取扱いについて，どこまでが秘密なのか，ベンダの再委託先にどこまで知らせてよいかなどもトラブルの原因になります。

標準的な契約書の利用

（これまで「情報システム開発」と表現してきましたが，ここでは「ソフトウェア開発」といいます。厳密には，前者ではハードウェアを含むのに後者では含まないなどの違いがありますが，ここでは区別をしておません）

このように，ソフトウェア開発では多くの事項について明確な契約をする必要がありますし，契約に関する知識とソフトウェア開発に関する知識が求められます。慣れていない中小企業にとって，適切な契約書を作成するどころか，ベンダが作成した契約案を検討するすら困難でしょう。
　標準的な契約書があれば便利です。多くの開発でこれが利用され評価されているならば，安心して用いることができます。

ソフトウェア開発委託モデル契約

その代表的なものに，ＪＩＳＡ（社団法人情報サービス産業協会）による「ソフトウェア開発委託モデル契約」（２００２年，以下「モデル契約」と略称）（ http://www.jisa.or.jp/activity/guideline/dev_contract2002.html）があります。これをベースにして，必要に応じてカスタマイズすればよいでしょう。
　また，ＪＩＳＡは，このモデルを策定した考え方として「新しい取引における契約問題とその対応についての考え方（ポジションペーパー）」（ http://www.jisa.or.jp/activity/opnion/020530-j.html）を発表しました。ソフトウェア取引において，当事者間で利害が対立する問題とその対応についてのＪＩＳＡとしての考え方を述べたものです。これも合わせて読むことを勧めます。

なお，モデル契約では，契約時には詳細なシステム仕様はできていないで，契約後に作成されるものとしています。ですから，システム仕様書の内容についての記述はありません。また，運用のアウトソーシングは含まない一括契約を想定しています。

モデル契約を利用するときの留意点

宅地建物取引では，業者は専門的知識を持っているのに対して消費者は素人であるとの観点から，消費者の立場を考慮した取引になっています。ところがこのモデル契約は，全般的には適切なのですが，発注者がベンダと対等な立場であることを前提としており，しかもＪＩＳＡがベンダが中心の組織です。それで，この分野に経験の少ない中小企業がこのモデル契約を利用するときには，いくつかの留意点があります。

発注者の義務事項: ベンダから要請された作業の実施やデータ移行テスト実施，承認期間の設定など発注者の義務が多くあります。これらは円滑な開発を行うのに大切なことですが，発注者は自社にそれだけの能力があるかを考える必要があります。「ソフトウェアの品質が不十分で納期に遅れたのは，その要請に応えなかったからだ」と一方的にいわれる危険があります。
第三者ソフトの問題: 最近のソフトウェア開発では，すべてをベンダが開発するのではなく，フリーソフトや市販ソフトを部分的に利用することにより，短期間に安価に開発します。ところが，そのようなソフトの欠陥についてはベンダもわからないので，そのリスクを発注者と分担することになっています。でも，素人にはそのソフトすら知らないのです。「専門家であるベンダが研究して採用を勧めたのだから，ベンダ側でリスクを負うべきだ」とする必要があります。逆に，どのソフトを採用するかには口出ししないほうが無難です。
第三者の知的所有権: 開発するソフトウェアのなかで第三者が作成した画面体裁や処理プログラムを利用すると著作権の侵害になります。また，情報システムを活用した業務の方法が特許に抵触することがあります。モデル契約では，これらのリスクも両者が分担することになっていますが，このようなことは発注者は調査する能力すらないのです。
納入物の著作権の取扱い: 著作権法では，ベンダが開発した文書やプログラムの著作権はベンダに属することになっています。このままですと，発注者がそのシステムを第三者に販売することもできませんし，他のシステムで利用することも制限されます。発注者が文書やプログラムを自由に使えるように変更しておく必要があります。

これ以外にも留意すべきことは多くありますが，経験のない経営者がモデル契約を見て発見するのは困難でしょう。また，業界常識として受け入れるべき事項もあります。それで，自社がモデル契約を用いるときに，具体的にどの条項をどのように変更すればよいかを，まえもって弁護士やコンサルタントに相談しておくとよいでしょう。

ソフトウェアの品質保証

品質について両者が合意することをＳＬＡ（サービスレベル・アグリーメント）といいます。ソフトウェアの品質には，「請求書を発行する」というような機能品質，「画面が表示されるまでの時間を５秒以内とする」というような操作品質，「故障が起きたら，保守要員は３０分以内に現場に到着する」というようなサービス品質などがあります。これらについてＳＬＡを設定しておくことが，トラブルを回避するのに必要です。
　ＳＬＡは，重要な事項に関しては提案依頼書で明記するべきですし，システム仕様書段階ではかなり詳細にしておく必要があります。さらに，ソフトウェア引渡しの時点で改めて確認するべきです。

サービスレベルの数値化

品質のうち，機能品質は比較的わかりやすいのですが，操作品質では主観的な要素もあります。サービス品質では厳格な実行規定なのか努力目標なのか決められない事項もありましょう。

その解釈が両者で異なるとトラブルが発生しますので，サービスレベルをできるだけ客観的に把握できること，それには数値で表現できるようにするべきです。例えば操作品質では「操作がしやすい」というような主観的な表現ではなく，「画面が表示されるまでの時間を５秒以内とする」などとするのが適切です。
　しかし，それには限度がありますし，測定項目が限定されるとそれ以外の品質が無視される傾向もあります。事前によく話し合い文書にしておくことが必要です。

サービスレベルの設定

重要なことは，発注者が完全主義に走らないこと，ベンダが防衛主義にならないことです。また妥協ではなく，費用対効果の観点から最適レベルにするために協力することが大切です。

画面表示までの時間は短いのがよいのに決まっています。でも発注者が「１秒以内」などと極端な値を主張すると，それを実現するために特殊な工夫が必要になり，それだけのために大きな費用がかかることもあります。またベンダが「３秒で可能だと思うが，安全のために５秒にしておこう」というのでは，なかなか合意に達しません。
　いかに努力しても絶対はありません。「プログラムエラーは０とする」ようなことを決めても実現できるはずがありません。発注者がそれを主張すれば，ベンダはエラーを隠す努力をするでしょう。それではますます危険な状況になります。

経験の乏しい発注者ほど，利用者からのクレームを恐れて完全主義者になりがちです。するとベンダはないさら防衛的態度になり，それがこうじると不信感に発展します。そのような事態を避けるためにも，発注側はコンサルタントに第三者的な立場からの意見を求めるのが適切です。

モニタリングと逐次見直し

ＳＬＡの遵守を高めるために，納期遅れが発生したらペナルティを科し，予定よりも早く完成したらプレミアムを与えるような契約にすることも行われます。互いに成熟度が高い場合には適切な手段です。
　しかし，副作用として当事者が必要以上に緊張感を持ち，サービスレベルの設定がなかなか合意に達しないとか，トラブルの原因を相手になすりつけるようなことにもなりますので，当事者が成熟度が低い場合には慎重にしたほうがよいでしょう。

それよりも，モニタリングの徹底を図るべきです。定期的にサービスレベル実現状況を報告して適切な対処を検討する体制を整えることが必要です。そして，その結果により，より適切なサービスレベルに見直すことが重要なのです。