ソリューションプロバイダがシステム開発を受注する際の契約は、他の産業に比べても未成熟──。最近、ソリューションプロバイダなどに契約に関する取材をしていて、改めてこう実感した。

　ITサービス業界は、労働集約型の請負産業という共通点から、建設業界とよく比較されるが、こと契約という観点では、建設業の方がきっちりしている。建設業の取引では、分厚い契約書や関連文書を整備した上で、契約、着工する。頻繁な設計変更にも、きちんとした合意文書で対応している。

　一方、ITサービス業界におけるシステム開発の契約では、あいまいさが目立つ。ユーザー企業からの業務要求やRFP（提案要求書）に応じて提案書、見積もりを出すのだが、システム開発に必要な詳細な仕様が確定していない時点での見積もり・契約が、契約後の開発段階で、仕様変更などによるコスト増大や納期遅延につながる。その上、仕様を確定するためのプロセスや変更のルール、問題が起こったときのソリューションプロバイダとユーザー企業との間の責任分担ですら、契約で明確になっていないことは少なくない。

　その結果、ユーザー企業とソリューションプロバイダとの間でトラブルが発生し、訴訟問題にまで発展することもある。最近では今年5月、札幌市の医療機器商社ムトウが、東洋ビジネスエンジニアリングに対して、契約の解除と9億3400万円の損害賠償を求める訴えを起こした（関連記事）。業務システムの再構築案件において、バグによる開発遅れに加え、サーバーの性能設計に問題が発生したという。契約の中身については明らかになっていないが、性能設計の責任の所在について、双方の主張は真っ向からぶつかっている（関連記事）。

　訴訟に至らないまでも、ソリューションプロバイダと顧客企業の取引で、トラブルは後を絶たない。その最たる結果が不採算案件の発生で、多くのソリューションプロバイダが、業績悪化の主要因に挙げている。

　日本IBMで20年以上法務を担当し、現在もIT業界の契約問題を数多く扱う高石法律事務所の高石義一弁護士は「日本人はビジネスを行う上で、簡単な契約を好む傾向がある。IT業界では、その考えが多くのトラブルを引き起こしている。ITの技術はこの十数年で大きく進歩したが、取引における契約のあり方はいまだに確立していない」と指摘する。

　実際ソリューションプロバイダの中には、「契約条項を持ち出して議論するようになったら営業マンはおしまい」「どんな契約をしていようが、顧客の言うことには逆らえない」といった論調すらある。

ベンダー優位の契約を見直すユーザー企業

　実はユーザー企業の間で、契約のあいまいさを問題視し、ソリューションプロバイダとの契約を見直す動きが出てきている。

　例えばJTB。同社は、基幹システムの再構築案件が開発半ばで頓挫し、システム開発を発注したソリューションプロバイダと、3年に及ぶ訴訟を経験した（関連記事）。JTBの野々垣典男IT企画チームマネージャーは「ユーザー企業がリスクをヘッジするには、契約を見直すしかないと痛感した」と振り返る。JTBは訴訟での経験を踏まえ昨年、ソリューションプロバイダと契約する際の条件を見直した。

　ユーザー企業にも失敗のリスクがある以上、今後も契約の見直しや厳密化の動きがどんどん出てくる可能性がある。ソリューションプロバイダも、契約の見直しに取り組まなければ、不利な契約を強いられることになりかねない。ソリューションプロバイダの側が、自らの責任も明確にする形で、ユーザー企業に提案できる契約条項を用意しておくべきだろう。

　現実には、問題が訴訟にまで発展するのはまれで、問題が起こった際も、契約だからと顧客の意見をはなから否定できるわけでもない。だが、契約条項がなければ、顧客の言い分をそのまま受け入れざるを得なくなりかねない。逆に、きっちりとした契約条項があれば、議論のスタート地点にして落としどころを探せる。

合意事項はすべて文書化

　見直すべきは、契約書そのものだけではない。契約書を交わす前の提案段階や、開発に入ってからのユーザー企業との協議事項についても、合意のためのプロセスや変更ルール、問題発生時の責任の所在を明確にし、合意事項を文書として記録に残しておくことが望ましい。ユーザー企業との間で交わした合意事項は、すべて契約書と同じ効力があるからだ。現状では“口約束”も多いようだが、文書化しておけば、不測の事態が起こったときの議論の土台になる。

　富士通は、顧客との合意のためのルール作りに取り組む1社だ。今年4月、不採算案件撲滅に取り組む部門としてSIアシュアランス本部を設置、ユーザー企業との契約のプロセスの改善も実施した。その1例が、契約時に契約書に添付する受託条件明細の整備だ。従来の文書を見直し、プロジェクト計画書、工程設計書、SI進行基準書といったドキュメントを策定した。

　例えばプロジェクト計画書では、仕様の不備などが起こった場合に顧客と共同で作る対応組織や、そこでの対処のルールまで記載し、顧客と合意しておく。従来、プロジェクト計画書に相当する文書として実行計画書があったが、これは、予算にかかわる開発時の要員計画や品質資料にとどまっていた。

営業担当者の役割も広がる

　加えて、営業担当者のプロジェクトへのかかわり方も変えていく必要があるだろう。受注・契約というプロジェクトの入り口だけでなく、プロジェクト全体にわたって契約変更やリスクを管理する、いわゆる「契約管理（コントラクトマネジメント）」の役割が、営業担当者に求められているのだ。

　契約管理は、契約が守られているかをチェックし、変更が発生したときには変更契約を結んだりするなどして、契約面からプロジェクトを管理すること。開発にかかわる作業や顧客との協議はプロジェクトマネジャーやSEの仕事でも、追加の対価の交渉などで顧客との窓口となるのは営業担当者にほかならない。日本では「営業担当者は契約を取るのが仕事」という意識が強く、欧米に比べ契約管理を軽視する傾向があるといわれている。

　伊藤忠テクノサイエンスは昨年から、営業部門に、契約管理を担う「プロジェクト・オーナー」という役割を導入した。プロジェクト・オーナーはプロジェクトの採算に責任を持ち、プロジェクトマネージャやSEと二人三脚でプロジェクトを進める。横山良治執行役員プロジェクトマネジメント室室長は「今後は、開発に失敗して損が出ても、営業部門は被害者という意識は通用しない」と話す。