IT訴訟弁護士「塔子」参上!:美人弁護士 有栖川塔子のIT事件簿(1)(2/2 ページ)
ITシステム開発で最も大切な「要件定義」。だが1度合意したはずの要件に、開発中に追加や変更を繰り返し行われてプロジェクトが混乱する例が後を絶たない。こんなときはどうすればよいのか、IT訴訟専門の美人弁護士「塔子」に聞いてみよう。
東京地裁の、平成16年3月10日の判決※2が参考になるわ。ユーザーの出す要件変更がプロジェクトにどう影響するかは、専門家であるベンダじゃないと分からない。ベンダは、要件の追加・変更要望があったとき、そのメリット・デメリットを説明したり、場合によっては追加費用を見積もることも必要って判断がなされてるわ。
一応、他の機能を削ることもお願いしてるんですけど。
作業の量や質が、手戻りも含めて本当に釣り合ってるならそれでもいいけど、現実はそんなにキレイにはいかないでしょ。ダメなものはダメ、費用が必要なら必要ってちゃんと言わなきゃ。
でも、そんなことお客さん相手に言いにくいです。
最終的に、どちらが本当にユーザーの信頼を得られるかよく考えなさい。この程度のことができないようじゃ、そもそも人から金取ってITベンダやってる資格なんてないわ。
じゃあ、具体的にはどうしたらいいんですか?
定期的に要件変更に関する会議を開く※3のよ。そこでその期間に出た要件の追加や変更についてメリット・デメリットと期間、費用、他への影響を徹底的に話し合う。
けっこう、手間暇がかかりますねえ。
要件の変更が設計工程でも出続けるのは、むしろ当たり前のことなのに、みんなそれを異常なことって考えてる。本当なら、プロジェクト計画や見積もりのときに、要件変更検討のための費用も考えて見積もらなきゃダメなのよ。
そんなことしたら競合に不利じゃないですかぁ。
そういう費用を認めないようなユーザーなら、そもそも商売しない方が得策だわ。もし戦略上どうしても欲しい案件なら、赤字を出してでもやることはやる。プロジェクトの費用と要件のバランスは、現場の担当者同士だけでちゃっちゃと判断できるほど甘くないのよ。プロジェクトがこけたら、それこそお互いに重大な損失でしょ、何千万円、何億円って。そうなっちゃったら、お互いの経営にだって影響しかねない。要件管理をナメんじゃないわよ。
別にナメてるわけじゃないですけど。
甘いのよ! ハチミツかけたあんこより甘い。プロジェクト計画時に要件変更に対処するための管理工数も見込む。最低限、外部設計工程の完了までは、定例会議のアジェンダに要件の追加変更の検討を入れる。追加・変更については、とにかく見積もって、実施の可否や実施方法の選択肢を用意し、おのおのメリット・デメリットをみんなで検討する※4。他の要件との差し替えなんて、その後だわ。あと要件定義工程と設計以降の工程を別に契約するのも有効よ。
お客さんにいい顔してるだけじゃダメってことですね。
当たり前じゃない。アタシなんかクライアントとケンカしない事件なんてないわよ。
それはそれで問題なような……。
物事に真剣に取り組もうとすれば、意見が違ってケンカになることだってある。その場しのぎで取り繕って、問題を先送りにする態度こそ、不誠実この上ないのよ。
そういう度胸も、プロジェクトには必要ってことですね。
そう。それにケンカするなら早い方がいい。要件定義のときに徹底的にやっておけば、後は案外うまくいくものよ。
でも先輩見てると、そうとも言い切れないような。
どういう意味よ。
だって先輩、男の人と付き合うとすぐにケンカするけど、いつもそれっきり別れちゃうじゃないですか。『後はうまく』なんて信じられないっていうか……痛っ、痛いですよ先輩! 六法全書投げるなんて危な過ぎますって! だ、誰か助けてー!
今回のPOINT
- ユーザーから要件変更要望があったら、メリット・デメリットを説明し一緒に採否を検討する。
- 追加要望には必ず費用を見積もる。
- 見積もりにはプロジェクト管理費用として、要件変更の採否検討や要件変更の管理工数を含んでおく。
※2 東京地方裁判所 平成16年3月10日判決。ある公共団体の業務系システム開発において、システムの納入が遅れ、ベンダの債務不履行が問われた事件。裁判所はシステムの納入が遅れた原因は、要件などについて明確な意思決定を適時に行わなかったユーザーにもあるが、ユーザーに要求の撤回や追加の委託料負担を求めるなどしなかったベンダにもプロジェクト管理義務違反があったとして、ベンダへの支払が大幅に減額された。
※3 経済産業省発行の「情報システム・モデル取引・契約書」では、外部設計検討会について記した第21条の3に「外部設計検討会における検討等により、甲が要件定義書の内容を変更しようとする場合において、作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第33条(本契約及び個別契約内容の変更)の手続によるものとする」と記してある。
※4 スコアリングマトリクスなどを使用して、その要件が業務にもたらすメリット・デメリットを比較し判断することが効果的。
書籍紹介
細川義洋著
日本実業出版社 2100円(税込み)
約7割が失敗すると言われるコンピュータシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。
細川義洋
東京地方裁判所 民事調停委員(IT事件担当) 兼 IT専門委員 東京高等裁判所 IT専門委員
NECソフトにて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムにてシステム開発・運用の品質向上を中心に、多くのITベンダ及びITユーザー企業に対するプロセス改善コンサルティング業務を行う。
2007年、世界的にも稀有な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。
- 要件やシステム化の範囲はどうやって決めるのか?
- 業務要件のモレを無くすためにマークすべき人とは?
- もしも要件定義の無いシステム開発の担当になったら
- もし要件定義担当者とベンダーが「グル」だったら?
- 修正の影響範囲が分からない? そんなの徹夜でおやりなさい
- その性能要件は消滅しました(えっ!?)
- 要件が決まるまで、テコでも動きません!
- パッケージソフト導入の「お・と・し・あ・な」
- 排他制御でアイタタタ!―― パッケージソフトの落とし穴
- 要件定義を決めるのはベンダーの仕事でしょ?
- そもそも要件定義って何なのよ
- IT訴訟弁護士「塔子」参上!
- 登場人物紹介 有賀一郎
- 登場人物紹介 西園寺彩音
- 登場人物紹介 成兼章介
- 登場人物紹介 有栖川塔子
- 登場人物紹介 全員
Copyright © ITmedia, Inc. All Rights Reserved.