検索
連載

IT訴訟弁護士「塔子」参上!美人弁護士 有栖川塔子のIT事件簿(1)(2/2 ページ)

ITシステム開発で最も大切な「要件定義」。だが1度合意したはずの要件に、開発中に追加や変更を繰り返し行われてプロジェクトが混乱する例が後を絶たない。こんなときはどうすればよいのか、IT訴訟専門の美人弁護士「塔子」に聞いてみよう。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

登場人物紹介

TOKO

東京地裁の、平成16年3月10日の判決※2が参考になるわ。ユーザーの出す要件変更がプロジェクトにどう影響するかは、専門家であるベンダじゃないと分からない。ベンダは、要件の追加・変更要望があったとき、そのメリット・デメリットを説明したり、場合によっては追加費用を見積もることも必要って判断がなされてるわ。


AYANE

一応、他の機能を削ることもお願いしてるんですけど。


TOKO

作業の量や質が、手戻りも含めて本当に釣り合ってるならそれでもいいけど、現実はそんなにキレイにはいかないでしょ。ダメなものはダメ、費用が必要なら必要ってちゃんと言わなきゃ。


AYANE

でも、そんなことお客さん相手に言いにくいです。


TOKO

最終的に、どちらが本当にユーザーの信頼を得られるかよく考えなさい。この程度のことができないようじゃ、そもそも人から金取ってITベンダやってる資格なんてないわ。


AYANE

じゃあ、具体的にはどうしたらいいんですか?


TOKO

定期的に要件変更に関する会議を開く※3のよ。そこでその期間に出た要件の追加や変更についてメリット・デメリットと期間、費用、他への影響を徹底的に話し合う。


AYANE

けっこう、手間暇がかかりますねえ。


TOKO

要件の変更が設計工程でも出続けるのは、むしろ当たり前のことなのに、みんなそれを異常なことって考えてる。本当なら、プロジェクト計画や見積もりのときに、要件変更検討のための費用も考えて見積もらなきゃダメなのよ。


AYANE

そんなことしたら競合に不利じゃないですかぁ。


TOKO

そういう費用を認めないようなユーザーなら、そもそも商売しない方が得策だわ。もし戦略上どうしても欲しい案件なら、赤字を出してでもやることはやる。プロジェクトの費用と要件のバランスは、現場の担当者同士だけでちゃっちゃと判断できるほど甘くないのよ。プロジェクトがこけたら、それこそお互いに重大な損失でしょ、何千万円、何億円って。そうなっちゃったら、お互いの経営にだって影響しかねない。要件管理をナメんじゃないわよ。


AYANE

別にナメてるわけじゃないですけど。


TOKO

甘いのよ! ハチミツかけたあんこより甘い。プロジェクト計画時に要件変更に対処するための管理工数も見込む。最低限、外部設計工程の完了までは、定例会議のアジェンダに要件の追加変更の検討を入れる。追加・変更については、とにかく見積もって、実施の可否や実施方法の選択肢を用意し、おのおのメリット・デメリットをみんなで検討する※4。他の要件との差し替えなんて、その後だわ。あと要件定義工程と設計以降の工程を別に契約するのも有効よ。


AYANE

お客さんにいい顔してるだけじゃダメってことですね。


TOKO

当たり前じゃない。アタシなんかクライアントとケンカしない事件なんてないわよ。


AYANE

それはそれで問題なような……。


TOKO

物事に真剣に取り組もうとすれば、意見が違ってケンカになることだってある。その場しのぎで取り繕って、問題を先送りにする態度こそ、不誠実この上ないのよ。


AYANE

そういう度胸も、プロジェクトには必要ってことですね。


TOKO

そう。それにケンカするなら早い方がいい。要件定義のときに徹底的にやっておけば、後は案外うまくいくものよ。


AYANE

でも先輩見てると、そうとも言い切れないような。


TOKO

どういう意味よ。


AYANE

だって先輩、男の人と付き合うとすぐにケンカするけど、いつもそれっきり別れちゃうじゃないですか。『後はうまく』なんて信じられないっていうか……痛っ、痛いですよ先輩! 六法全書投げるなんて危な過ぎますって! だ、誰か助けてー!


今回のPOINT

  • ユーザーから要件変更要望があったら、メリット・デメリットを説明し一緒に採否を検討する。
  • 追加要望には必ず費用を見積もる。
  • 見積もりにはプロジェクト管理費用として、要件変更の採否検討や要件変更の管理工数を含んでおく。

※2 東京地方裁判所 平成16年3月10日判決。ある公共団体の業務系システム開発において、システムの納入が遅れ、ベンダの債務不履行が問われた事件。裁判所はシステムの納入が遅れた原因は、要件などについて明確な意思決定を適時に行わなかったユーザーにもあるが、ユーザーに要求の撤回や追加の委託料負担を求めるなどしなかったベンダにもプロジェクト管理義務違反があったとして、ベンダへの支払が大幅に減額された。

※3 経済産業省発行の「情報システム・モデル取引・契約書」では、外部設計検討会について記した第21条の3に「外部設計検討会における検討等により、甲が要件定義書の内容を変更しようとする場合において、作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第33条(本契約及び個別契約内容の変更)の手続によるものとする」と記してある。

※4 スコアリングマトリクスなどを使用して、その要件が業務にもたらすメリット・デメリットを比較し判断することが効果的。

書籍紹介

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

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

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

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

細川義洋

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

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

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

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



Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る