今夜も徹夜…デスマーチを生むシステム開発のトラブル事例
「IT紛争」とは、システム導入などIT分野のプロジェクトで、ベンダ（開発元）とユーザ（顧客）の認識の齟齬によって起こるモメ事のこと。近年、当事者間で「話と違うじゃないか」「なんでそこまでウチがやらないといけないんだ！」とトラブルになり、裁判沙汰になることが増えているといいます。
この「IT紛争」のケースと対策について、東京地裁でIT事件担当の民事調停委員を務める細川義洋さんが教えてくれるのが『「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則』（日本実業出版社／刊）です。
今回はその中から、システム導入プロジェクトでありがちなトラブルをいくつか紹介します。
ベンダには、さまざまな会社から「RFP（提案依頼書）」が舞い込みます。これは簡単に言えば「ウチの会社にこんなことができるシステムを入れたいんだけど、何かいいシステムがあったら教えてよ」という情報提供の依頼書。
もちろん、ベンダは受注が欲しいわけですから、なんとか自社の製品やサービスの良さを伝える回答をして契約に結びつけようとします。この際、受注を欲しがるあまりやってしまいやすいのが、自社製品の良さについて少々「誇張」してしまうこと。
もちろん、正式に受注したとなったら契約書を取り交わすわけですが、特に訂正や削除がない場合はRFPの記述も要件になってしまうので、誇張して書いてしまうと、あとで「話と違うじゃないか」とトラブルになりやすいのです。
ですから、誇張を書かないことはもちろん、もし書いてしまったのなら、契約の際にこれまでユーザ企業に提出した文書を調べ直して、誇張や虚偽、時間の経過によって変化してしまったことなどを修正したり、否定することが大切になります。
■「任せられた」結果、顧客の希望とまったく違うシステムが…
めでたく契約を結んだ後もトラブルの種は尽きません。
ベンダ側が、期日までにシステムやサービスなど成果物を納品することを保証する「請負契約」というものがありますが、これは裏を返せば「期日までに納品できれば、誰がどんな作業を行おうと構わない」ということでもあり、「任せきり」「任されきり」になりやすい性質があります。
システム開発はベンダとユーザが作業を分担して行うことが多いため、対話は不可欠です。ユーザがシステム要件を定義して後は任せきり、となってしまうと、ベンダは成果物の受入検証時になってはじめて、ユーザの希望とまったく異なるシステムを開発してしまったこと気づくという悲劇が起こりかねません。
「請負契約」自体は、作業管理や人の配置に自由が利く点で、ベンダ側のメリットは大きいので、ユーザと作業の方法や順序を話合って、双方で作業を監視しあいながら進めていくということを、ベンダが舵を取ってやっていくべきです。
■裁判所はベンダに厳しい！
ベンダはシステム開発の専門家で、ユーザはいち顧客ですから、たとえばベンダA社からユーザB社へのシステム納品のプロジェクトが頓挫してしまい、プロジェクト全体の管理責任をめぐって法廷闘争になった時、裁判所はベンダ側の責任をかなり重く見る傾向があります。前項でも触れましたが、プロジェクト全体の舵はベンダがしっかりと握っていないといけません。
この舵取りにおいてポイントになるのは、ベンダがユーザ側の行動も含めて管理するということです。
特に有効なのは、「こんなケースは中止する」「こんな場合は双方が協議して対策を考える」といったように、プロジェクトの進捗が何らかの理由で滞ってしまった時の行動をベンダとユーザで共有しておくこと。
こうすることでユーザ側にも当事者意識が芽生え「任せっきり」な状態にはなりにくくあります。
今回は比較的よくある「IT紛争」の例を紹介しましたが、この分野にはまだまだ紛争・トラブルの種が隠れています。
本書はそういったトラブルと、その予防策・対処法が網羅され、詳細な解説が加えられていますので、ベンダ側の方はもちろん、ユーザ側の人もぜひ参考にしてみてください。
（新刊JP編集部）
