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

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

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

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

　前回、コンピュータシステムの要件に変更や追加が相次いだ際に、開発ベンダが注意すべき事柄について教えられた彩音。でも、そもそも「要件定義」とはどのようなことをする作業なのか、いまひとつ理解していません。

≫登場人物紹介

塔子先輩、そもそも要件定義って何を決めるんですか？

そんなこと説明したら、それだけで本1冊になっちゃうわ。

大まかなとこだけでも教えてくださいよ。じゃないとこれから先、先輩の話に付いていけないかも。

別に付いてこなくてもいいけど。ってか彩音、これからもアタシにいろいろ頼ろうってわけ？ タダで？

いいじゃないですか。かわいい後輩が困ってるんだから。

かわいくなんかないけど、いちいち初歩的な質問されても、うっとうしいから概略くらい話してあげるわ。

わーい。よろしくお願いしまーす。

システムの要件を定義するには、まず対象となる業務自体の処理や流れを定義する※1必要があるわ。例えば会社で経費の精算を自動化するシステムを作るなら、そもそも経費精算業務とは、誰からの依頼でどんな業務を行い、結果を誰に返すのか、というようなことを、コンピュータのことを考えずに定義する。

どうして、コンピュータのことを考えないんですか？

コンピュータありきで業務を考えると、本来は人間が行った方が効率的だったり妥当な業務を無理にシステム化して、かえって業務の支障になることがあるからよ。

あーなるほど。すぐ隣にいる課長にちょっとハンコもらえば済むことをわざわざシステムに入力して承認待つことになったり、紙に書いて持っていった方が早い文書を、わざわざ社内クラウドに入れて参照させることになったり。

大体そんなところね。ナンセンスなシステム化を防ぐためには、コンピュータ抜きで業務の要件を考えて、その後どこをシステム化したら良いかを検討するのが鉄則よ。

なるほどねぇ。

通信販売会社のコールセンターシステムの業務要件について、ユーザーとベンダが打ち合わせをしてる記録があるわ。参考になるはずよ。

ベンダ　「コールセンターの役割は、大きく言うと、電話を受けて、顧客からの注文を受け付け、その場で注文票を作成し、後方の手配部門に流すということですね？」

ユーザー　「そうなります」

ベンダ　「その中でシステム化するのは、受けた電話の番号を基に顧客情報を画面に表示する部分だけでしょうか。注文票を作成する部分はどうですか？ 同じ画面から連動させてできるようにするとか」

ユーザー　「いや、オペレーターの操作が複雑になるので、それは対象としません。それより、かかってきた電話の番号を電話会社からもらって、システム側で利用できませんか？」

ベンダ　「技術的には可能ですが、特別な機械を入れるので、初期費用もランニングコストも膨大になります。オペレータの省力化の分を差し引いても、システム化の目的であるコスト削減に逆行してしまう結果になってしまいます」

※1　業務フロー図やBPMN（Business Process Modeling Notation）、UMLのユースケース図などを利用して業務の流れを図式化したり、業務シナリオを書きながら現状の問題点などを明らかにすることが一般的。