その性能要件は消滅しました（えっ！？）：美人弁護士 有栖川塔子のIT事件簿（7）（2/2 ページ）

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

まずお客さんが商品をショッピングカートに入れてから、それが本当にカートに入ったかを確認したり、次の商品を見られるまでに数十秒かかる可能性があるわ。お客さんはその間、システムがちゃんと処理しているのか不安だし、イライラするでしょ。あんまり待たされたら、他のお店の方がいいやって思って、二度と来てくれなくなるかもしれないし。

そ、そんなの困るなあ。

もっと困るのはこの後よ。もしも購入決定ボタンを押した後、あまりに長く処理に時間がかかると、ネットワークがタイムアウトして、商品を買ったつもりなのに買えてないってこともあり得るし、ユーザーがPCを切っちゃったら、プログラムが異常終了して何が起こるか分からない。購入決定していないのに商品が発送されたり、請求が出たり……。

駄目、駄目、駄目！ そんなことになったら、オンラインショップだけじゃなくて、本体のスーパーの信用までがた落ちだよ！

下手したら損害賠償だってあり得るから、有形無形の損害は計りしれないわよ。

でも、そういうことって、オンラインショップを作るとき、当然考慮に入れなきゃいけないことじゃないの？

それはどうかしら。「言われてないから知りません」ってベンダーも結構いるわ。大手でも性能要件を約束するのを嫌がることがあるし。性能要件とそれに付随するセキュリティ要件は、かなりの量の検討や設計、プログラミングが必要になるから、やるかどうかでベンダーのコストが相当変わるのも事実だしね。

こちらは必要だけど、ベンダーは約束したがらないんだね。じゃあ、どうしたらいいの？

基本的なこととして、性能要件を条件付きで決めることね。

条件付き？

例えば、同じシステムをインターネットを通さない直結で動作させた場合の速度を定義するとかね。これなら、ベンダーも約束するはずよ。これでシステムの基本性能をまず約束してもらう。

まずサーバー内の処理速度を縛るってことだね。

そしてできるだけ早い時期に、実際のインターネットを使って実証実験をするのよ。本来なら、要件定義中にパッケージソフトの開発会社の環境とかを借りて実施して、その結果を基に、実現可能な処理速度を定義するべきなんだけどね。

その結果が悪かったら？

だから、要件定義工程でやるんじゃない。その時期ならデータの大きさやネットワークの太さをいろいろ変えられるし、パッケージソフトを取り替えることだってできるでしょ。この前話した、要件定義工程の契約を別にする※3っていうのは、こういうときのためよ。性能の検証を最終的なシステムテスト段階で行うシステム開発もよく見るけれど、特にインターネットを使うシステムでは、それじゃ遅過ぎる。絶対に早期にやるべきよ。

なるほど。それにしても、たった1行の書き換えでこんなに変わっちゃうなんて、要件定義書って怖いねえ。

その1行が何億円って損害につながることだってあるんだから、シビアに見ないとね。ただ今回のベンダーは……

問題アリ？

要件定義書は、契約書別紙として位置付けられるべき重要な書類で、裁判でも重視される文書よ。それをうやむやのうちに都合よく書き換えて、その議事録も残していないなんて、悪意すら感じるわ。傷の浅いうちに違約金払って変えた方がいいかも。

ど、どうしよう。また、パパに叱られる。

パパじゃないでしょ！ スーパーの経営とアタシの顧問料が危険に晒されてるのよ。何とかしなさいよ！

今回のPOINT

• 性能要件は早期に検証して、実現方式検討に生かすべき
  
  
• ユーザーの要望と要件定義書にズレやモレのないことを、双方が厳密に確認することが必要
  
  
• 要件定義書を書き換えるようなベンダーは契約を打ち切る

　「パパに叱られる前に塔子に怒鳴られちゃった（てへぺろ）」（章介）。越後屋のシステム開発はどうなるのか、続きは2月21日掲載です。

※3　「多段階契約」と言われ、経済産業省も薦めている。ユーザーにとっては全体費用が見えにくいというデメリットがあり、プロジェクト開始当初にベンダーが見積もった費用を大幅に上回る可能性もあるが、工程毎にベンダーの選定を行えるメリットもある。

書籍紹介

なぜ、システム開発は必ずモメるのか？

細川義洋著
日本実業出版社　2100円（税込み）

約7割が失敗すると言われるコンピューターシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。

細川義洋

東京地方裁判所 民事調停委員（IT事件担当） 兼 IT専門委員　東京高等裁判所 IT専門委員

NECソフトにて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムにてシステム開発・運用の品質向上を中心に、多くのITベンダー及びITユーザー企業に対するプロセス改善コンサルティング業務を行う。

2007年、世界的にも稀有な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。

ITmedia オルタナティブブログ「IT紛争のあれこれ」

「美人弁護士 有栖川塔子のIT事件簿」バックナンバー

• 要件やシステム化の範囲はどうやって決めるのか？
• 業務要件のモレを無くすためにマークすべき人とは？
• もしも要件定義の無いシステム開発の担当になったら
• もし要件定義担当者とベンダーが「グル」だったら？
• 修正の影響範囲が分からない？ そんなの徹夜でおやりなさい
• その性能要件は消滅しました（えっ！？）
• 要件が決まるまで、テコでも動きません！
• パッケージソフト導入の「お・と・し・あ・な」
• 排他制御でアイタタタ！―― パッケージソフトの落とし穴
• 要件定義を決めるのはベンダーの仕事でしょ？
• そもそも要件定義って何なのよ
• IT訴訟弁護士「塔子」参上！
• 登場人物紹介　有賀一郎
• 登場人物紹介　西園寺彩音
• 登場人物紹介　成兼章介
• 登場人物紹介　有栖川塔子
• 登場人物紹介　全員