1 ユーザー主導で決めるべき業務要件の対象レベル

RFPに記述する業務要件の対象レベル

　記述する業務要件の対象は「(1)目的」「(2)仕組み」「(3)ルール」の3つとする。

業務要件の記述レベル

1、目的要件

　なぜIT調達を行うかの必要性、希望、願望、要求、実現したい効果、達成目標などを簡潔に、定量的および定性的に表現する。「要件」と言っても「要求を実現するための諸条件や制約」までを記述するものではない。RFPの最初に書き、提案者に発注者の意志を伝える役割を持つ。

2、対象業務の仕事の仕組み要件

　次の仕組みを文章、図、表、例示、範例、シミュレータ、デモなどで表現する。

• 対象業務の組織体制、役割分担、仕事の内容、業務フロー
• 情報伝達と共有
• 人間の仕事におけるITインタフェース（IT媒体と画面や帳票）など

　この記述レベルは、仕事でITを利用する必要性、希望、願望、要求、実現したい効果、達成目標などを「どのように実現するか」の「諸条件」を定義するものである。このレベルの要件定義RFPが、ネットワーク設計、サブシステム設計、概念データモデルなどの全体設計の提案依頼文書となる。しかし、要件定義のあいまい性や手戻りなどをなくするためのデータ処理「仕様」レベルではない。

3、仕事をするために守るべきデータ処理ルール要件

　ITとは、具体的にはコンピュータ、パソコン、携帯電話、ネットワーク機器、電子メール、ホームページ、各種ソフトウェアなどである。人間がITに対して何らかの操作をし、ITが反応するその結果を人間が利用する。この事態をITで技術的に実装するには、次のデータ処理「仕様」が定義されていなければならない。

• どんな操作で、どんなデータが入力されて　→　見やすさ要件、使いやすさ要件
• どんなルールにもとづいて　→　正しさ要件
• どんな操作で、出力するか　→　見やすさ要件、使いやすさ要件

　あいまいな要件でなく、限りなく手戻りをなくすために例外処理ルールまで記述するのが、画面や帳票や接続外部接続ファイルなどのデータ処理レベルの仕様である。

• 正しさ要件は、「データ項目定義書」で厳密に記述する（注2）
• 見やすさ要件と使いやすさ要件は、厳密には定義できないので例示でよい

（注2）人間は、例外処理まですべてを厳密に記述し、すべてのユーザーが要求する仕様の整合性を保証することは不可能に近い。中途半端なプロトタイピングやアジャイル手法で解決できるとも思えない。業務設計シミュレーション手法が必要である。前出の弊著「4.5補論：プログラミング手順の抜本的な変革への序曲（109ページ～）」を参照。

2 RFPの構成

　IT調達のためにSI業者などのベンダーに「提案書」を依頼するときのRFPは、上述した業務要件だけではない。RFP全体を次のように構成する

(1)業務要件～仕事でITを活用するトップ、ミドル、担当者から見た要件

(2)システム要件～ITを運用保守する情報システム部門から見た要件

(3)プロジェクト要件～IT調達プロジェクトを実施するための要件

3 ユーザー主導LSMによるRFP作成手順の概要

　詳細な手順は次回より解説するが、基本的な作成手順の流れを把握してほしい。

4 RFP構成の事例

ユーザー主導によるRFP作成の事例

平成18年5月8日、東京都千代田区が財務会計システム調達のためにプロポーザルを公募している。

政府が進めているEA(エンタプライズアーキテクチャ)の事例

「自治体EA事業」の成果物が総務省のホームページに掲載されている。

オブジェクト指向をベースにした「要求開発アライアンス」の事例

「要件定義」ではなく「要求開発」ということを提唱している。

RFP構成のほかの事例

　RFPの構成、要件定義書の構成と書き方など、ソフト業界の標準はない。前出弊著「第6章RFPの構成と記述内容（160ページ～）」で、以下の事例を紹介している。

• ITコーディネータ協会の研修テキスト
• 高知県の情報システム調達ガイドブックV1.0
• （社）情報化リーダー養成研修テキスト