業務要件のモレを無くすためにマークすべき人とは?美人弁護士 有栖川塔子のIT事件簿(11)(1/2 ページ)

ユーザーから要件をヒアリングするときには、単に業務プロセスを確認するだけでなく、オペレーターの振る舞いや属性に着目すると、思わぬ発見があるものです。

» 2014年04月04日 18時00分 公開
[東京高等裁判所 IT専門委員 細川義洋,@IT]

※この連載は「なぜ、システム開発は必ずモメるのか?」(細川義洋著)のCHAPTER1を、著者と出版社の許可の下、一部加筆・修正して転載するものです。

 要件定義が無いプロジェクトを担当することになった一郎は、学生時代の友人、塔子の助言を得て、ユーザーの担当者と力を合わせて要件定義から出直すことになりました。しかし製造業の業務知識不足のため、業務プロセスに定められていないオペレーターの活動が捉えられず、業務要件にモレが出てしまったようです。「と、塔子。たびたびすまないのだけれど、また相談に乗ってくれないかな?」

登場人物紹介 ≫前回までのお話

TOKO

何の用?


ICHIRO

な、何か機嫌が悪そうだけれど、あ、あの、僕、何か……?


TOKO

もういいわよ、フン。で、例の在庫管理システムはどんな塩梅よ?


ICHIRO

あ、あの、と、塔子のおかげでうまくいったんだけど。そしたら、うまくいかなくなったっていうか、何て言うか……


TOKO

だーっ! うまくいったのか、いかなかったのか、どっちなのよ!


ICHIRO

え、えっと……。ユーザーの担当者と協力して要件定義をやり直せたんだけれど、急いだせいか、また業務要件にモレが出ちゃって。


TOKO

どうやって決めていったの?


ICHIRO

業務プロセス文書※1を基に、在庫管理の業務プロセスを在庫管理担当者にヒアリングしたんだ。「いつ」「どんな依頼を受け」「どんな作業をするか」ってね。プロセスはモレなく追ったつもりだったんだけれど。


TOKO

でも、業務要件がモレたんでしょ?


ICHIRO

うん。プロセス外で行われている仕事があって。


TOKO

どんな仕事?


ICHIRO

もともとこの在庫管理業務っていうのは、倉庫に数百台保管している出荷用のPCを管理する仕事なんだ。


TOKO

型番別在庫数やシリアル番号を一覧で管理する感じ?


ICHIRO

そう。それで、営業担当から出荷要請が来たら、必要台数を在庫管理担当者が倉庫にある製品に引き当てる。


TOKO

必要台数のPCに出荷日と納入先を予約するのね。


ICHIRO

それでね、在庫数を超える注文が入ったら、出荷を次回入荷まで待ってもらうんだ。仮の引き当てだけしてね。


TOKO

それの何が問題なのよ。


ICHIRO

た、たまになんだけれど、営業担当者が「それじゃあ間に合わない、すぐ欲しい」って言ってくることがあるんだよ。そういうときは、後回しにできそうな他の注文に引き当たっているPCを急ぎの方に振り向けるんだ。


TOKO

そこが例外プロセスなのね。


ICHIRO

うん。でもそんなことがあるって僕らは知らなくて、そういう仕事の流れを要件として定義できなかったんだ。


TOKO

ははーん。正規のプロセスをモレなくしっかり確認して、それで安心しちゃったのね。でも失敗は失敗、要件定義者の無知は罪よ。イチロはもともと金融系システムの担当だから、製造業における商品の在庫管理が分かってないんでしょ。


ICHIRO

うん、だって急に押し付けられたプロジェクトだし……。


TOKO

だーっ! だーっ! だーっ! もひとつオマケにだーーーーっ!!!

 情けないこと言わないでよ。ユーザーには、アンタの事情なんて関係ないでしょ! メーカーの製品出荷に“割り込み”があるなんてこと、業界では常識よ。常識を知らないってことが要因になって、ベンダーが負けた裁判※2だってあるんだから。


ICHIRO

えぇぇぇぇ。裁判で?


TOKO

航空券予約のシステムだったかな。オペレーターが遠隔地からサーバーのデータを修正する機能を盛り込まなかったことが問題になったんだって。


ICHIRO

オペレーターがデータベースに直接アクセスして、データを書き換えるのが通常必要な機能? そんなの信じられないよ。


TOKO

ベンダーの技術者もそう思ったんでしょうね。普通のシステムなら、データベースを直接オペレーターに触らせるなんて危険だもの。でも、航空券販売業務ではそれが不可欠の機能なのよ。だから、「たとえユーザーから明確な要望が無くても、対応する機能を具備するべきだった」って判決だったのよ。


ICHIRO

業界知識が無いと、とんでもないことになるんだなあ。


TOKO

全てに当てはまるわけじゃないけれど、少なくともシステム開発において、ユーザーの業界における「常識」は無視できないのよ。


ICHIRO

こ、困ったなぁ。


TOKO

今回の場合も、イチロに業務知識が無いのなら、在庫管理担当者にシステム作りに入ってもらいなさいよ。


ICHIRO

た、頼んでるんだけど、なかなか忙しいらしくて。だからせめてヒアリングだけでもと思って、聞きに行ってるんだ。


TOKO

そのヒアリングを業務プロセスに沿ってしかやらないから、モレが出るのよ。要件定義のためのヒアリングではね、業務プロセス以上に人の振る舞いに注目しなきゃ駄目なのよ。


ICHIRO

振る舞い?


※1 システム化対象となる業務の手順などを記した文書。ユーザーの業務を調査する時に、部門の役割を定義した業務分掌などと併せて参照する。

※2 東京地方裁判所 平成16年6月23日判決 この裁判では、ベンダーが開発した旅行会社のシステムに「ユーザーが直接サーバーのデータを変更する機能」を具備していないことが、ベンダーの債務不履行に当たるかが争われた。裁判所は、契約書別紙である仕様書にも記載の無かったこの機能を「旅行商品販売業務には不可欠である」とし、その他の事象とも併せて、システムは完成していないと判断した。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

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

メールマガジン登録

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