もしも要件定義の無いシステム開発の担当になったら：美人弁護士 有栖川塔子のIT事件簿（10）（1/2 ページ）

要件定義の無い開発の紛争は、双方の主観的な主張が入り乱れて泥仕合化することが多いようです。しかし双方が協力して要件さえ固めれば、仲直りも再開も可能です。

[東京高等裁判所 IT専門委員 細川義洋，＠IT]

※この連載は「なぜ、システム開発は必ずモメるのか？」（細川義洋著）のCHAPTER1を、著者と出版社の許可の下、一部加筆・修正して転載するものです。

　IT紛争を得意とする弁護士 塔子のオフィスに、大学時代のゼミ仲間で大手ITベンダーに勤める一郎が相談に来ました。あるプロジェクトを引き継いでマネージャーを任されたのですが、契約書は大ざっぱだわ、要件定義書は無いわで、苦しんでいるようです。

≫登場人物紹介　≫前回までのお話

でっ、ど、どうかな。

どうもこうもないわよ。こんな契約書じゃ、どっちが何言っても何も証明もできないじゃない。何なのよ、この「在庫管理システム一式」って。アンタの会社、いつもこうなの？

い、いつもはそんなことないんだけど、今回はお互いの社長同士が細かい話をせずに決めちゃったから……。

トップセールスの全てが悪いとは言わないけれど、システム化の目的も改善したい業務もアヤフヤのまま話が下りてきたら、担当者は苦労することが多いわ。イチロ、アンタもでしょ？

あ、あの。何年も言い続けてるけど、僕の名前は一郎で……。

分かってるわよ。アンタがゼミの自己紹介で「座右の銘は真実一路です」なんて言うからじゃない。今さら一郎と呼ぶのなんて無理よ、無理ムリ。

　……それにしても本当にヒドいわね。契約書は「システム一式」だし、要件定義書無しでいきなり作った設計書は画面設計に動作のメモ書き程度だし、要件についてやりとりした議事録も断片的でサッパリ分からないし。

一言もないよ。僕も急に引き継いだから……。

何を作るのかもハッキリせず、中身もザックリしすぎ。この状態で開発を続けたら、絶対失敗するわね。

そうなんだ。ユーザーからはすでに、「この機能がない」「あの画面もない」「こんな機能は頼んでない」って毎日のように文句を言われてるよ。

ちゃんと要件を提示しないユーザーの非は問えないの？

そ、それがね。向こうは要件は画面説明と議事録で分かるはずだって言うんだ。

こんな設計書じゃ、入出力も演算も大まか過ぎて使えないじゃない。「これじゃ作れません」って言ったらどうなの？

ユーザーは「前の担当者だったら分かってた。お前が出てきてから話がややこしくなった」って言うんだ。僕は「不明点を明らかにして、要件定義をやり直したい」ってお願いしているんだけど、「今さら何を言ってるんだ」って。

どんどん状況が悪化してるわけね。

出入り禁止寸前だよ。それどころか「このままじゃ契約は打ち切る。場合によっては裁判だ」なんて言う人もいるんだ。

うーん。何せ要件定義と契約が結び付いてないから、ユーザーは「自分たちの希望をすべてかなえてくれるはず」だと思っているだろうし、ベンダーは「費用と期間で、できるところまでやる」としか言えないでしょうし。これは泥仕合になっちゃうかもね。

も、もし裁判になったら、ど、どうなるかな？

何とも言えないわね。ただ解決には2〜3年くらいかかるかな。

そんなに？ それは、こ、困るなあ。

だから、裁判なんてやらないに越したことはないのよ。

いっそ相手の言い値に値引きして、プロジェクトを打ち切りにした方がスッキリするんじゃないかと……。

さっすが大手ね、太っ腹。でもこのメールを見ると、相手の担当者は「遅れてもいいから何とか完成させたい」って言ってるじゃない。

以前はね。でも揉めごとが相手の経営層に伝わってからは、そんな話もすっかりなくなってさ。

ふーん……あ、あの話、もしかしたら参考になるかな。

何ナニ、どんな話？