そもそも要件定義って何なのよ：美人弁護士有栖川塔子のIT事件簿（2）（2/2 ページ）

» 2013年11月22日 00時00分公開

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

コールセンター業務の流れを確認して、システム化範囲を絞っている※2のが分かる？大切なのは、もともとシステムを作ろうと思った目的に照らして、要件を捨ててるところ。パッと見でやりたくなる電話番号転送を“コストの削減”という目的に照らして捨ててる。こういうのが大事なのよ。

検討していくうちに、最初の目的を見失うことってありますよね。業務要件定義のこと少しだけ分かりました。

システム化の範囲を含めた業務要件が明らかになったら、次はシステムに持たせる機能を検討する機能要件定義よ。

機能要件定義？

システムにどんな情報が入力されたら、どのような演算や判断をして、どんな情報をどこに何を出力するのかといったことを業務要件に基づいて決めていく※3。

このコールセンターシステムの場合だと、要件は表面的には1つだけ、“顧客情報検索機能”ということになるかしら。オペレーターがPCの画面から顧客の電話番号を入力したら、それをキーに既存の顧客データベースを検索し、該当する顧客の諸情報を画面に表示するといった機能ね。

えらくシンプルですね。

もちろん、たったこれだけのシステムでも、オペレーターの操作権限を管理する機能やセキュリティ、運用などに関わる機能とかが必要だけど、ここではその説明は省かせてもらうわ。

機能要件はシステムが何をするのかを一番具体的に明らかにする部分で、ここでの漏れや誤解、理解不足は、直接ケンカの火種になるから要注意よ。とにかく一つ一つ決めるたびに、システム化の目的とか、直前に話した業務要件定義と見比べながら、合目的性、合理性、妥当性、網羅性、正確性なんかを検証しながら進めていく。

ユーザーとベンダが一緒に機能要件用のチェックリストを作ってしっかり話し合うことが大切ね。多分、全プロジェクトの中で最も大切な会議になるはずだから、面倒くさがらずにとことん話し合うことよ。

それとは別に“非機能要件”ってのもありますよね。

さっきのシステムで言えば、画面から電話番号を入れて情報が表示されるまでに5分もかかったらシステムの目的を果たさないし、マウスしか使えないオペレーターにキーボード入力を強いるシステムじゃ使えないでしょ。

システムを作る際には、その反応速度やデータ容量などの性能要件、それに使い勝手などの操作性を決める必要があるわ。『この画面表示は30秒以内とする』とか『この画面の操作はすべてマウスで行えるようにする』って具合ね。

機能以外でシステムが備えておかなければならない性能や特性を、非機能要件として定義するのよ。

機能のことばっかり考えてると、忘れちゃいそうですね。

事実、非機能要件が忘れられて大問題になることがよくあるわ。機能要件ならプログラムの修正や追加で何とかなるケースが多いけど、性能要件は何千万、何億円もするハードウェアを無駄にしかねない危険があるから、ホント要注意よ。

返品ってわけにいきませんもんね。

非機能要件は、これ以外にも耐障害性やセキュリティなど広範にわたるし、ユーザーが分かることとベンダが分かることが混在してるから、両者がヒザ突き合わせてとことん話し合わないと漏れが出る怖いところよ。

なるほど。そこんとこ間違えると「ITの紛争処理ができる」って機能要件は満たすけど、「怒りの蓄積容量が少なすぎる」とか「怒りの反応が速すぎる」みたいに非機能要件に難のある、どっかの女弁護士さんみたいなのが出来上がっちゃ…… 痛っ！ …… ま、また叩いて…… きゃー！

今回のPOINT

業務要件の検討ではコンピュータのことを考えない
要件はシステム化の目的に照らして採否を決める
要件の定義にはユーザーとベンダの徹底した議論が必要

※2　業務の流れを確認して出た問題点をコンピュータで解決するか、他の方法で対処するかを判断し、システム化する範囲を決めていく。業務の流れを図式化したものに線を入れたり、UMLのシステムコンテキスト図を作成することが一般的。

※3　例えば銀行のATMで預金を引き出す機能であれば、「引出金額の入力画面を表示する」「金額入力を受け付ける」あたりが入力である。「入力された金額が預金残高を下回っていることを確認する」のが演算、「演算の結果から引き出せると判断して、マシンに出金を命じ、通帳と帳簿データを書き換えると共に処理終了画面を表示する」のが、出力にあたる。