業務をパッケージに合わせると言ったけど、めんどくさいからやっぱりやめた：「訴えてやる！」の前に読む IT訴訟 徹底解説（99）（1/3 ページ）

既製品でいいと思ったけど、やっぱりあれも付け足して、これも変更して。いや、いっそ根本からまるっとこちらの希望に合わせてよ。

[ITプロセスコンサルタント 細川義洋，＠IT]

連載目次

システム開発契約に大切なのは、「要件」と「目的」と……？

　システム開発契約において、その中核をなすものは言うまでもなく、システムにどのような機能や性能などを具備するかという「要件」であろう。受注者であるベンダーは、この要件を実現することで代金を支払ってもらえる。つまり要件は契約上の「債務」の中核であり、いくら欠陥のないシステムを納品しても、要件を満たさないシステムは「債務の不履行」となり、費用の支払いを得られないばかりか、場合によっては損害賠償の請求までされてしまう。

　もっとも、ここでいう「要件」とは、要件定義書に明記されたものだけを指すわけではない。たとえ文書化されておらず要件として定義されていなくても、システム開発契約の目的に照らして当然必要であると考えられるものや、それまで使っていたシステムに存在し、今後もその必要性が変わらない機能は、ベンダーは実現する必要があるとされる場合もある。

　本連載で以前扱ったマンモス大学の履修登録システムを構築する際に不特定多数の同時アクセスを考慮しなかったベンダーや、航空券の発券システムに旧システムにはあったリモートメンテナンス機能を具備しなかったベンダーが債務不履行とされた裁判などは、そうした「文書化されない要件」の例である。つまりシステム開発契約においてベンダーが負う債務は、要件定義書だけではなく契約の「目的」からも導出されるということになる。

　ところがシステム開発を巡る裁判では、要件と目的以外にも受注者たるベンダーの債務、逆にいえば発注者であるユーザー企業の債権に影響を及ぼすものがあるという事例もある。それは「開発の方針」と呼ばれるものだ。

　開発の方針というと、ウオーターフォールやアジャイルという開発方式もあるが、今回取り上げる裁判ではパッケージソフトウェアを利用した開発の方針が問題になった。

　パッケージソフトウェアを元にユーザー企業の業務を支援するシステムを構築する場合、パッケージをユーザー企業の業務に合わせて部分的に改造する「カスタマイズ方式」と、逆にユーザー企業の業務をパッケージに合わせて改善する「フィッティング方式」がある。

　どちらが正しいかは、ユーザー企業の意志による。自分たちの業務プロセスを世の中の潮流に合わせて変えたいと思えば、世の一般的な業務プロセスを内包していると思われるパッケージソフトウェアに業務を合わせる「フィッティング方式」だろうし、あくまで自分たち独自のプロセスは変えたくないと考えるなら、「カスタマイズ方式」に寄ることとなる。

　無論、この方式の選択は「0対10」ではない。パッケージソフトウェアの機能を全くいじらずに業務だけを変更することは、ほとんどないだろうし、業務の改善を全くせずにパッケージソフトウェアを大幅にカスタマイズするのも安全ではないし、システムを入れ替えるメリットが半減してしまう。ここでカスタマイズ方式、フィッティング方式といっているのは、あくまで、そのどちらに比重を置いているかという区別にすぎない。

「パッケージに合わせる」と言ったのに！

　今回取り上げるのは、パッケージソフトウェアの開発方針を巡る争いだ。

　開発は当初、フィッティング方式で行うはずだった。フィッティング方式であれば、定義するシステム要件はパッケージソフトウェアの設定変更が中心となり、開発規模も膨らまずに済むし、ベンダーが学ぶべきユーザー企業の業務や既存システムの機能の範囲も限定的だ。

　しかし、最初は「当社の業務をパッケージに合わせて改善する」といっていたユーザー企業が、いつの間にか「この機能がないと、ウチの仕事は回らない、パッケージにないのなら作ってくれ」などと言い始める。その結果、要件が膨らんで予算もスケジュールも大きく狂ってしまった。

　ベンダーとしては「カスタマイズ方式にされて要件が膨らんだ。約束が違う」との言い分だ。しかしユーザー企業は、「フィッティング方式では結局、自分たちの業務には対応できない。業務の回らないシステムなど作られても、それは仕事をしたことにならない」との思いだったようだ。

　事件の概要から見ていただきたい。