経産省モデル契約
経済産業省が主導して纏めた資料で、IT開発を委託する際にユーザ側とITベンダー間の契約モデルをまとめた契約書のひな形（モデル契約書）を公開しています。
2007年4月に公開したもので、2008年にはパッケージソフトウエア、SaaS、ASPモデルを前提としたモデル取引、契約書のひな形も公開されています。
公開までにパブリックコメントによる意見聴取をしてはいますが、そもそも、その元となる契約モデルや契約書をまとめる段階で参加しているのは御用学者や日系の大手IT企業なのです。
経済振興が目的の経産相ですから当然ですが、その内容はこれらの日系ITベンダーの都合の良い内容となっていますが、官公庁の政府調達と言われる契約や、民間のIT調達契約でも参考にされることが多くなっています。
ウォーターフォール開発モデルが前提のわけ
この経産省のモデル契約もまた、ウォーターフォール開発を前提としています。この開発モデルは既に過去のもので現代のGUIベースの開発スタイルでは何のメリットもなく、海外では相当前から既に使われていません。
にも拘わらず、日本の経産省はこのウォーターフォール開発モデルを前提とした契約モデルを改めて公開しています。それは、これらの日系IT会社にとって都合が良いからです。
その内容は通常のウォーターフォール開発スタイルで「システム化の方向性定義」「システム化計画」「要件定義」「システム設計」「ソフトウエア設計・プログラミング・ソフトウエアテスト」「システムテスト」「運用テスト」「運用」「保守」と順々に進むとなっており、契約形態は準委任契約を基本としています。
ウォーターフォール開発としてはごく一般的な進め方で違和感はありませんが、やはり今更感が強いと言わざるを得ません。
IT関連のユーザー企業とIT会社との訴訟問題が増加し、深刻化している現実があり、経産省はその原因が契約段階で双方の責任を明確化していないため、との認識のようです。そして、このウォーターフォール開発モデル契約の対象は重要インフラ・企業基幹システム構築のような比較的長期で高額になるシステム開発のようです。
開発工程だけでも請負にしましょう
この通産省モデル契約でも、内部設計～単体テスト（ソフトウエアテスト）は請負契約のパターンもあり、むしろそちらをメインにしています。要件定義、外部設計までは様々な外部要因などの影響を受け、どの様なプログラムを開発するのかなかなか確定しません。
また、ユーザー企業の協力があて初めてどのような機能が必要なのか定義できる面も大きいため、外部設計までは準委任契約で進める、となっているのだと思います。
また、システムテスト工程以降も既存システムとの接続テストや現在のシステムからのデータ移行などユーザー企業の協力が不可欠な面がありますので、ここも請負契約で完成責任をIT企業側が負うことは現実的ではない、となっているのだと思います。
しかし、内部設計は作るべきプログラムの機能が確定した上で、その内部の作りの設計ですし、それをプログラムとして書いていく工程と作成したプログラムが単独で予定した通りの動きをするのかをテストする工程はIT会社が独自に進めることが出来ます。
むしろ、ユーザー企業は何も出来ない部分ですので、ここは請負契約で、とされているのは納得できます。そして、作成したプログラム自体に問題があれば、完成責任や瑕疵担保責任を求めていくのが良いかと思います。
その時に、それまで要件定義、外部設計を委託していたIT企業が請負契約を拒むようであれば、他のIT企業を入れて競争入札にして開発費用を抑えるのが良いかと思います。
経産省のモデル契約でも、フェーズ毎にRFPを出してベンダー選定をしていくようにも書かれていますし、自社以外が見て判り、そのまま作れば必要な業務機能を満足するものが完成するレベルの要件定義、システム設計が文書として定義されていなければ、準委任契約にしろ、その工程を委託した会社の不備なのです。そのまま英訳してインドの会社にでも製造を委託できなければいけません。それがグローバルの標準的なレベルです。
恐らく、「要件をとりまとめ設計した自社でなければ開発出来ない」とIT企業は主張するでしょうが、そうであってはいけないのです。
今までのようにIT会社に自社のITシステムの開発運用を丸投げし、ベンダー・ロック・インと言われる逃げられない状態にされて、高額な保守運用費用を搾取されてきた歴史を繰り返さないように、ITベンダーから自由になりましょう。
それが、現代のビジネスに直結したITシステム開発・運用の自由度・スピードを上げる唯一の道だと思います。幸いにも、最近のITシステムの開発スタイルは大きく変わって来ていますので、自由になる絶好の機会かと思います。
