[木内里美の是正勧告]

ベンダーは契約を逃げ道にするな!

木内里美の是正勧告 第20回

2010年5月12日(水)木内 里美(オラン 代表取締役社長)

回復とまではいかなくても景気に底打ち感が出始めた今、情報システムの構築や刷新プロジェクトが増加しつつある。しかし従来のままプロジェクトに挑めば、トラブルが続発するのは必至だ。何しろ業務要件はもとより、パッケージやIT製品の組み合わせによってシステムは年々、複雑化している。必然的に開発コストが膨らんだり、予定する稼働時期に間に合わず、稼働を断念するケースが増える可能性がある。損害賠償訴訟や「動かないコンピュータ」のネタも増えそうだ。

見積もりの不透明性が問題

問題の根源はどこにあるのだろうか。筆者はズバリ、見積もりの不透明性とソフトウェアの品質問題が大きいと思っている。情報システムの開発では、要件定義がよく問題視される。しかし発注者が定義する必要のある業務要件は、最初の段階から詳細を決めることはできない。プロセスを踏みながら確定するし、要件の変更も常態である。変更に備えるなら変更管理を決めて合意しておけば済む話で、業務要件の不確定要素が見積もりを不透明にしているわけではない。

問題は、そもそも情報サービス業界には発注者が内容を理解できる標準積算手法や積算基準がないことにある。内訳のよくわかる単価の表示もない。例えば見積もりにはリスクが見込まれるが、そのリスクの内容が明示されることはない。

見積もりの不透明性は発注者の不信を呼ぶ。品質に至っては基準も保証の仕組みもない。バグがあるのは当たり前とばかりに、非無謬性を正当化するような姿勢すら見られる。しかしリコールのないソフトウェアも、ハードに組み込まれるとリコールに追い込まれることも起こる。

情報システム開発と契約問題

一方、「○○一式」に代表される契約の曖昧さが根源だという見方もある。そうした見方に則って経済産業省は、2007年に情報システムの信頼性向上と取引可視化に資するモデル契約書の第1版を、2008年にはパッケージやSaaSなどを対象にした追補版を、それぞれ公表した。

確かに訴訟に発展した事例を分析すると、合意形成が不十分、かつ未契約で開発に着手して金銭トラブルになったケースが少なくない。役割分担や完成基準、変更管理などを曖昧にしたまま開発を進め、開発途上や納品時に齟齬を生じて訴訟に発展するケースも多い。

しかし前者は契約以前の問題であり、同時に商慣習の問題である。後者からはベンダーへの丸投げや、ベンダーから再委託先への丸投げなどの甘えの構造と、期待に応えられないベンダーの力量不足という信頼性を損ねる大きな問題が浮かんでくる。つまり契約の厳格化で責任の明確化は出来ても、開発トラブルそのものを激減させることは期待できない。

モデル契約書もその背景にある狙いは、役割分担の明確化によるトラブルや紛争リスクの低減であり、見積もりの不備や品質、信頼性などの根源的な問題には踏み込んでいない。

契約だけでは解決は困難

要するに契約で解決できることは、限られているのである。信頼性のある情報システムを予算と工程通りに完成させるためには相互協力と協働が必須である。そのためには要件や見積もり、リスク、プロセスにおける不確定要素を可視化し、変更時の合意形成が必要である。その基本はコミュニケーション改善にある。ワークショップ型の協働開発手法がよい成果を残しているのはその好事例と言える。ところが最近のシステムは技術も作り込みも多様化し、複雑になっているのに協働が薄れてしまっている。

発注者とベンダーはもともと非対称性の問題を抱えている。ベンダーは発注者の業務内容を熟知しているわけではないし、発注者は最新の情報技術やIT製品に深い理解を持つわけではない。非対称性を解決するには役割認識と相互協力しかない。

しかしベンダーの姿勢をみると、最近では不採算プロジェクトが多いことから多段階契約を成果物責任のない委任契約で受けて、区切りをつけようとする傾向が目立つ。契約で逃げているようにさえ映るのだ。ベンダーがITのプロであるなら契約を逃げ道にせず、「請負うプライド」を失わないで欲しい。根を絶たない限り改善は覚束ない。

木内 里美
大成ロテック監査役。1969年に大成建設に入社。土木設計部門で港湾などの設計に携わった後、2001年に情報企画部長に就任。以来、大成建設の情報化を率いてきた。講演や行政機関の委員を多数こなすなど、CIOとして情報発信・啓蒙活動に取り組む
バックナンバー
木内里美の是正勧告一覧へ
関連記事

トピックス

[Sponsored]

ベンダーは契約を逃げ道にするな!回復とまではいかなくても景気に底打ち感が出始めた今、情報システムの構築や刷新プロジェクトが増加しつつある。しかし従来のままプロジェクトに挑めば、トラブルが続発するのは必至だ。何しろ業務要件はもとより、パッケージやIT製品の組み合わせによってシステムは年々、複雑化している。必然的に開発コストが膨らんだり、予定する稼働時期に間に合わず、稼働を断念するケースが増える可能性がある。損害賠償訴訟や「動かないコンピュータ」のネタも増えそうだ。

PAGE TOP