社内システムはMust-Haveを要件にし、70点を目指すべき理由

IT部門（情シス）が、社内ITのために、社内ユーザに要件のヒアリングを行うことはよくある。

しかし、なぜかしっかりした要件が決まらなかったり、要件漏れがあったり、使いにくいものが完成したり、納期が決まらなかったり、定めた要件定義用の想定期間内で確定しなかったりする。

これはなぜかを考えたときに思ったことは、いくつもの理由が存在することに気が付く。ここでは改善出来るが実際は出来ていない要件定義のヒアリングの考え方で怒る問題について考えてみる。

IT部門が社内でシステム要件のヒアリングをしてくると、対外の顧客のような緊張感も少ないせいか、雑談も交えながらいろんな話を聞いてくる。それ自体は良いことだけど、えてして要件が発散し過ぎで、Must-HaveとNice-To-Haveが混在し、ユーザと一緒に迷子になっているときがある。

・Must-Have（やらなければいけないこと、実現しなければいけない機能）
・Nice-To-Have（やったほうがいいこと、あった方がいい機能）

そのため、この2つを明確にしなければいけない。特にヒアリングにあたっては、その違いを明確にすることをヒアリングの最初に宣言したり、情報が発散した際に口にするなどの情報の制御が必要になってくる。

そして、ユーザ側も社内だからという甘えがあるが、要件定義として定めた期間内に整理できなかった情報は、納期にC/Oするシステムの要件からは外すということに合意させる必要がある。

これらがヒアリングする側のIT部門側が出来ていないことによって、冒頭のような問題が起きるのである。

社内システムを作るときは100点目指すのではなく、要件は70点くらい、その分テストは正確に、くらいでも良いときが多い。70点に要件の本質がカバーされていたら、30点分くらいはだいたい実際の利用率が僅かしかない機能。それよりは早く使い始められるようにした方が良い。

何よりどれだけ目指してもNice-To-Haveが無限に存在する以上、100点の達成は不可能で、それを前提に取り組もうという姿勢自体が傲慢であったり、ユーザから見たIT部門もしくはIT部門からみたユーザに対して、課題が生じたときの他責を生む隙につながるのではないかと思う。

まずは、Must-Haveをターゲットに70点のシステムを作ることがうまくいきやすいコツである。