非IT企業の情報システム部がシステム開発を依頼させられた場合②～要求定義と要件定義の違い～

はじめに

情報システム部の方で、ITに詳しいだろうからという理由で、ビジネス用のシステム開発のマネージメントをするように依頼されることはないでしょうか？

実際は情報システム部の仕事と、ビジネス用システムの開発は大きく異なるものかと思います。

また、非IT企業では、システム開発を依頼する機会も少なく、一発勝負になることも多いです。

そんなお悩みを解決できるよう、いち非IT企業の情報システム部メンバーとして、実体験に基づくシステム開発の依頼の流れをまとめさせていただきました。

システム開発でお悩みの方は、是非見てみてください！
またITベンダーの皆さんにも企業側はこんなこと考えてるんだなーと思ってみていただければ嬉しいです。

要求定義　と　要件定義はよく話として出てくるが、結局どっちがどっちなのかがよくわからなくなる場合が多い。翻訳家としては要求と要件の違いは重要であり、それぞれ以下のように定義できる。

要求定義とは、ビジネスにおいてシステムに求める全仕様であり、要件定義はその中から、システム化することを決定した仕様と言い換えることもできる。

そのため、要求定義で求められるのは、”PJTにおいて、ビジネス側から求められるすべてのシステム化要求事項を洗い出すこと”である。そして、要件定義は、”洗い出された要求定義をもとに、システム化する範囲を合意事項として示したもの”であるといえる。

そのため、要求事項　>　要件定義　という包含関係が成り立ち、要求事項にない、要件事項は存在しないこととなる。

要求定義において一番大きな問題は「要求漏れ」である。注文していないものはシステムには実装されない。当たり前のことであるが、ITシステムという非実態のモノに対してはこれに対する理解が希薄である。

例えば、貴方が新しく注文住宅を建てるとして、２階にもトイレが欲しいのであれば、「２階にもトイレが必要だ」と工務店さんに依頼する必要がある。

ITでも同じである、何かの機能が必要なのであれば、要求事項として依頼する必要がある。

とはいっても要求は漏れるものである。これは、依頼するビジネスサイドがITについての知見に乏しいことが原因である。そのため、情報システム部はビジネスの内容を把握し、これを網羅する要求事項をまとめる必要がある。

そのためには、以下を心がけることが大事である。

要求の「視点」に漏れがないか確認を行う
システムに触れる可能性がある人を洗い出し、それぞれの視点で動かし方を想定し、抜け漏れがないかを確認する。
「言わなくてもわかるでしょ？」と要求者（ビジネス側）は考えていると理解し、粘り強く調整する
要求漏れがあった場合、”当然やってくれるものだと思っていました” とビジネス側は言います。また、~~めんどくさいから~~適当にやっておいて、とも言われます。
ここでめんどくさがって、引き下がると、後々何倍もめんどくさくなります。要求者の頭の中にしかない”当然”を引き出すため、丁寧なヒアリングを心がける。