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

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

[東京高等裁判所 IT専門委員 細川義洋，＠IT]

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

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

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

何の用？

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

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

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

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

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

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

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

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

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

どんな仕事？

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

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

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

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

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

それの何が問題なのよ。

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

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

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

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

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

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

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

えぇぇぇぇ。裁判で？

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

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

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

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

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

こ、困ったなぁ。

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

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

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

振る舞い？

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

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