要件定義を決めるのはベンダーの仕事でしょ？：美人弁護士有栖川塔子のIT事件簿（3）（2/2 ページ）

» 2013年12月06日 18時00分公開

[細川努，＠IT]

前のページへ 1|2 　　　　　　

登場人物紹介

そう。ユーザーは入力情報の詳細を自分で確認してないし、ベンダーもガイドせずに勝手な理解でモノを作った。

アタシたちは、そんなにいい加減にやってるわけじゃありませんよ。今のお客さんだって……。

アンタんとこのユーザーは、アンタらが作った要件定義書を、ちゃんと検証してOK出してる？要件定義を実際の業務に当てはめてシミュレーションしたり、接続先の他システムの担当者とあらゆる危険を想定して話したり、オペレーターに操作性や処理速度なんかを聞きに回ったりしてる？

いえ、そこまでは……。

「そういうことをしてください」って促すのもベンダーの責任。

そんなことお客さんが自発的にやるべきじゃないんですか？

手前勝手なこと言ってんじゃないわよ！開発経験の少ないユーザーが、要件定義にそういうことが必要だなんて知るわけないでしょ。そーいうのを“作り手の理屈”って言うの。ちゃんとユーザーに促さないと、ダメ※2よ。

キビしー。

ベンダーは、ユーザーの決めるべきこと全てをちゃんとガイドして、期日通りそれが完了することを管理しなきゃいけない。

でも「要件定義はユーザーの責任」って本で読んだことありますよ。

それは、決まった要件に責任を持つってことで、何を決めれば良いのかは専門家のベンダーが教えなきゃ分からないでしょ。

世の中には、「ベンダーの指示は受けない」って自信のあるユーザーもいるけど、やっぱり日ごろからいろんなシステム開発を経験しているベンダーには、それなりの知見がある。ユーザーはそれを軽視すべきじゃないし、逆にベンダーは自分たちのそういうスペシャリティを軽視させるべきじゃないわ。

この間教えた要件の項目なんかを参考に、ベンダーがしっかりと固めるのよ。

なるほど。

それと、こと要件定義に限っては、役割分担を捨てるくらいの気持ちも必要よ。

捨てちゃう？

要望を出すときや、それを整理して要件にするときには、役割を超えて、お互いが気付くことをどんどん言い合う形でしか網羅性は担保できない。

ベンダーがオペレーターの立場に立たないと「ここは画面の動きが遅くなるけど大丈夫？」なんて問題は提起されにくいし、ユーザーもベンダーの立場で「この期間に、これだけの機能つくれる？」って気にすることが大事よ。

チーム全体が、あーでもない、こーでもないって納得するまで議論しないと要件定義はできないわ。

チーム？

要件定義・管理担当、技術主幹、業務に精通しているメンバー、ユーザー側窓口、エンドユーザー部門、運用担当、外部接続先のシステム担当者…… プロジェクトによっていろいろだけど。

要は、新システムで実現する業務フローに載る人の意見を全て収集する必要がある。実際に会議に参加してくれなくても、アンケートとかね。

役割分担にこだわってちゃ、ダメなんですね。

失敗プロジェクトの9割は、要件定義が関連してる※3って言われてるわ。大変なのは当然よ。

何か心配になってきた。今日の合コンやめようかな。

あら、いいのよ。気にせず行ってらっしゃい。

えっ？

今のうちに能天気に遊んで、後になってから、壊れたプロジェクトの中で血ヘドを吐いて、もだえ苦しめばいいのよ、ホホホ。アーッハハハハ！

せ、先輩、相変わらずゆがんでますね……。

今回のPOINT

ベンダーはユーザーの決めること、調べることを積極的にガイドする
要件定義は、役割を超えてチームで徹底的に議論する
要件定義チームには、できるだけ多くの利害関係者を入れる

※2　東京地方裁判所　平成16年3月10日判決「（供給者）は、受給者における意思決定が必要な事項（中略）について、具体的に課題および期限を示し、決定などが行なわれない場合に生ずる支障、複数の選択肢から1つを選択すべき場合には、それらの利害得失などを示した上で、必要な時期までにX（受給者）がこれを決定ないし解決できるように導くべき義務を負い……」とある。ユーザーが要件、つまり意思決定が必要な事項について決定が行われない場合、ベンダーにも責任があることを述べている。

※3　情報処理推進機構　ソフトウェアエンジニアリングセンターの「アンケート調査報告2005/6/ 29-7/1 SODECにおけるアンケートによる」より。