検索
連載

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

ITシステムの要件定義では、対象業務のフローや入出力を決める「業務要件」とシステムが持つべき機能を定める「機能要件」、システムの速度や容量、使い勝手やセキュリティなどを定義する「非機能要件」について、ユーザーとベンダで徹底的に議論することが大切です。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

登場人物紹介

TOKO

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


AYANE

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


TOKO

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


AYANE

機能要件定義?


TOKO

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

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


AYANE

えらくシンプルですね。


TOKO

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

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

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


AYANE

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


TOKO

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

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

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


AYANE

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


TOKO

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


AYANE

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


TOKO

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


AYANE

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


今回のPOINT

  • 業務要件の検討ではコンピュータのことを考えない

  • 要件はシステム化の目的に照らして採否を決める

  • 要件の定義にはユーザーとベンダの徹底した議論が必要

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

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

書籍紹介

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

細川義洋著
日本実業出版社 2100円(税込み)

約7割が失敗すると言われるコンピュータシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。

細川義洋

東京地方裁判所 民事調停委員(IT事件担当) 兼 IT専門委員 東京高等裁判所 IT専門委員

NECソフトにて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムにてシステム開発・運用の品質向上を中心に、多くのITベンダ及びITユーザー企業に対するプロセス改善コンサルティング業務を行う。

2007年、世界的にも稀有な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。

ITmedia オルタナティブブログ「IT紛争のあれこれ」



Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る