連載
» 2014年02月07日 18時00分 公開

美人弁護士 有栖川塔子のIT事件簿(7):その性能要件は消滅しました(えっ!?) (2/2)

[東京高等裁判所 IT専門委員 細川義洋,@IT]
前のページへ 1|2       
TOKO

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


SHOSUKE

そ、そんなの困るなあ。


TOKO

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


SHOSUKE

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


TOKO

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


SHOSUKE

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


TOKO

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


SHOSUKE

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


TOKO

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


SHOSUKE

条件付き?


TOKO

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


SHOSUKE

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


TOKO

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


SHOSUKE

その結果が悪かったら?


TOKO

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


SHOSUKE

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


TOKO

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


SHOSUKE

問題アリ?


TOKO

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


SHOSUKE

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


TOKO

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


今回のPOINT

  • 性能要件は早期に検証して、実現方式検討に生かすべき

  • ユーザーの要望と要件定義書にズレやモレのないことを、双方が厳密に確認することが必要

  • 要件定義書を書き換えるようなベンダーは契約を打ち切る

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

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

書籍紹介

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

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

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

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


細川義洋

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

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

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

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



前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

編集部からのお知らせ

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。