IT化プロセス 2．要件定義

企画化が完了すれば、次にやる事は企画で決めた目的を具体的にどう実現するかを決める事です。

二つやり方があります。一つは自分達でシステムを作っていく場合です。目的達成の為のシステム要件を決めていきます。これを要件定義書を呼びます。今回はこちらについて記載します。提案依頼書は次回記載します。

要件定義書の目次は以下の通りで作ります。

1．目的

2．範囲

3．必要要件

4．要件を実現する為の必要な機能

5．運用条件

6．具体的な画面の例

7．拡張性

8．希望スケジュール

順番に説明します。

1．目的

ここは企画書で記載した目的をそのままコピー&ペーストで良いです。

2．範囲

これも企画書で記載している場合、コピー&ペーストでOKです。もし企画書で範囲を記載していなく、且つ範囲を記載した方が良いかなと思った場合は、システム化の範囲を記載してください。システムや機能の連携がある場合、図で示すと分かりやすいです。

3．必要要件

ここは、要件事に区切って記載します。例えば、在庫管理システムを作ろうとした場合、要件を区切る事が出来ます。例えば、在庫発注、入庫、引当、出庫、在庫数の参照、棚卸等です。在庫発注で要件を記載するとすれば、このような例が考えられます。

「受注データを流用して、発注入力が行える様にして、入力作業を可能な限り無くして、今より作業効率を上げる」

このようにして要件はシステム的な観点で記載するのではなく、あくまで業務目的を達成する為にどんな状態になってほしいか？をこの要件定義書を読んだ人が分かるようにします。仮にシステム機能は沢山作ったけど、この要件をみたしていないのならば、そのシステムは全く意味がありません。

要件を記載は非常に重要です。なぜならば、システムの作り手が「良いシステム」をつくれるかどうかに大きな影響を与えます。逆に言うと、仮に要件の記載がなく、システム機能の話が中心だとしましょう。その場合、作り手側は、言われた通り（要件定義書に記載された通り）に作る事は出来ますが、その作ったものが、業務要件（例えば業務を効率化したい！）にちゃんと繋がっているかをイメージ出来ないのです。そうすると、言われた通りに作ったけど、使えないと言われるシステムになる可能性が高いです。

しかし、ここで要件が記載されていれば、作り手は自分が作っているシステムで業務を行うイメージが持てます。

4．要件を実現する為の必要な機能

ここでは、先に記載した「要件」を満たす為に具体的に必要と思うシステム機能を記載します。例えば在庫発注なら、以下の様なものを考えてみます。

・受注データを取り込んで発注データを自動的に作る事。（可能な限り転機は行わないという考え方）

・発注先の必ず手配先マスターデータを使う。手配先の手入力は行わない。

・（制作や加工を依頼するなら）発注時に注文書と手配する図面のデータも一緒にEDIで送信する。

等です。

5．運用条件

これも重要です。前提となる運用条件を明確にしておかないと、作っても「使えない」と言われるシステムになる可能性が高いです。システムを使う業務担当者は、要件を漏れなく完璧にいう事が出来ない事が多いです。そしてシステムが出来上がってテストしたり、運用が始まると、明確にする事が出来なかった業務をシステムを使ってやろうとします。しかし、それは事前に明確にされていないので、システムはそれを実現するように作られていない事が多いです。従って、要件定義の時点で、運用条件を明確化しておくことが重要です。在庫発注なら、「データの流用元である受注データが入力され、確定状態になっている事」「（部品等の制作を依頼する場合なら）図面データがあらかじめ準備されている事」「●●については、システムでは発注しない」等です。

6．具体的な画面の例

機能を言葉で定義したら、具体的にその機能の画面や帳票のレイアウトを決めます。画面のレイアウトを決めると、そこに配置する項目やボタンも決まるはずです。項目やボタンの役割も決めましょう。項目毎に項目名やそこに何を入力するかを記載します。ボタンについては、ボタンを押したら、どういう動作をするのか記載します。

ここまで説明した要件・必要機能・運用条件・具体的な画面の例は、セットで記載します。例えば、在庫発注なら、在庫発注で要件・必要機能・運用条件・画面を記載します。次に入庫の機能を同じように要件・必要機能・運用条件・画面の順に記載しいます。

ここまで記載した内容は以下の通り、論理的に繋がっている必要があります。

目的→目的実現の為の要件→要件を実現する為に必要なシステム機能→その機能を実現する為の業務前提条件の規定→システム機能を実現する為の画面や帳票のレイアウトとその機能

論理的な繋がりを意識して記載する事は重要です。なぜなら、後工程で漏れが分かったり変更が発生した場合、自分が「どこで何を見落としていたから、漏れが発生したのか」また「変更部分が影響を与えるのはどの部分か。目的が変更なったのか。要件が変更になったのか。運用条件が変更になったのか」をすぐに把握出来るからです。論理的に前から後に話が繋がっていくように内容を作っていけば、最初から順番に考えていく事が出来まば、変更箇所の特定も容易です。変更すべき箇所を特定したら、その箇所とその後の部分を漏れなく修正すれば良いです。内容の修正範囲もとても分かりやすくなります。

7．拡張性

今回のシステム開発に対して、今後の展望や予定があれば、記載しておきます。これも作り手側と共有しておけば、作り手側もそれを意識して、良いシステムを作る事が出来ます。

8．希望スケジュール

要件定義が完了したら、どれくらいのスケジュールでそれを実現したいのか記載しておきましょう。要件定義の内容と作業量と自分の考えているスケジュール感を作り手側と共有します。これも作り手側が違和感なく共有できれば、要件定義の精度の確認にもなります。もし、自分が思っている要件定義の内容とスケジュールについて、作り手側が違和感を覚える場合があったとします。例えば、要件に対して、スケジュールが短すぎると相手が思った場合、作り手側は要件定義書の内容について記載すべき内容が不足していると察知して、相手に伝える事も出来ます。これも要件定義書の品質向上につながると思います。