システム・ベンダー選定の際の有用なツールであるRFP（提案依頼書）ですが、その書き方には決まりごとはありません。
そのため、RFPへの記載内容は各社各様です。
RFPでは機能要件（システムに必要な機能）が、重要な要素の一つになりますが、ベンダーを選ぶ際に確認すべき事項は他にもたくさんあります。
今回は、機能以外の要件にどのようなものがあるかを見ていきます。
RFPとその記載内容
RFP（提案依頼書）は、ベンダーに対して提案を求めるための資料です。
前述の通り、記載内容に決まりはありませんが、システム選定の場合には、大枠では以下の様な内容になることが多いです。
RFPの構成（システム選定の場合）
・提案依頼の趣旨
・システム構築方針
・機能要件
・非機能要件
・その他の要件
・提案要領
RFPの中心になるのは機能要件ですが、システム選定のためのRFPであれば、誰もが必要だと気付く内容です。
それ以外の要件については、様々な視点から検討する必要があり、特に初めてRFPを作成される方だと、要件を網羅的に記載するのは至難の業です。
今回は、その機能要件以外の要件にスポットを当てて、記載内容を確認していきます。
非機能要件
システムには、それぞれに異なる仕様があります。それらの仕様に関する要件は、非機能要件と呼ばれたりします。
その非機能要件には、次のようなものがあります。
・利用環境
システムの機能が充実していても、環境が自社に合っていなければ使うことはできません。
サーバーのOS、クライアントのOS、利用可能なブラウザ、リモート接続が可能か、など、自社の利用環境を想定して、要件として記載します。
・性能
システムは、処理スピードも大事な要素となります。
想定しているデータ量を示したうえで、入力や出力、帳票印刷等に要するスピードや、日次・月次で行うバッチ処理の所要時間などを要件として挙げることがあります。
・セキュリティ
今日、ビジネスで利用するシステムで、いつでも誰でも全てのデータにアクセスして良い、というものは少ないと思います。RFPを使って選定するような、大規模なシステムであれば尚のことです。
そこで、アカウント管理（パスワード管理含む）やアクセス制御、ログの記録に関しての要件を記載し、どの程度のセキュリティを設けることができるかを確認します。
・バックアップ
データのバックアップも重要な要素の一つです。
バックアップの頻度や取得方法、リストアの方法などにおいて、必要と考える事項があれば、要件として記載すべきです。
主に上記のようなものが非機能要件と呼ばれるものになります。
システムに関する専門知識も必要になりますので、情報システム部門が中心となって取りまとめをすることも多いです。
導入要件
続いて、導入要件について具体的な中身を見ていきます。
導入要件とは、文字通り、システム導入作業に関する要件です。
※データ移行やインターフェース開発、研修も広い意味では導入要件と言えますが、当ブログでは、次の「その他の要件」で説明します。
システム導入作業でも、注意すべき点は様々ありますが、5W1Hの視点で考えるとわかりやすいです。
・When（いつ？）：システム構築スケジュール
いつからシステムを稼働するか、どの時期に受入テストを行うかなど時期に関する要件がある場合に記載します。
例えば、受入テストは繁忙期を避けたい、といったことがあれば、その繁忙期を避けることを要件とします。
段階的にシステムを導入する際は、各段階における内容と時期を要件として明記することもあります。
・Who（誰？）：プロジェクト体制
システム構築プロジェクトの体制について、要件があれば提示します。
また、要件として示す以外に、体制やプロジェクトリーダーの実績を提示すること、など情報開示を要請することもあります。
・What（なに？）
プロジェクトの作業内容や成果物に関する要件があれば記載します。
例えば、上場企業であれば内部統制（IT全般統制）により、システム構築時に必要な書類を定めているはずです。
これらの資料にはベンダー側で用意すべきものも含まれていますので、必要なものを明記しておく必要があります。
・Where（どこで？）
作業場所に関する要件があれば記載します。
本社ではなく、システム部門がある○○県での作業が必要、という場合は、要件として記載する必要があります。
また、作業を常駐で行う（逆にスペースが無いので常駐は不可）といった条件があるようであれば、それも記載しておくべきです。
・How（どうやって？）
システム構築スケジュールの進め方について、条件があれば記載します。
例えば、要件定義フェーズにおける打ち合わせの場所やメンバー、頻度などが該当します。
また、プロジェクト進捗報告の方法や頻度について言及する場合もあります。
条件ではないですが、プロジェクトにおける役割分担（ベンダーが行う作業と自社で行う作業）も、プロジェクトを進めるうえで重要な要素です。
役割分担や各種MTGの頻度、自社側の工数（想定）について、提示を求めることも有用です。
システム導入を円滑に進めるための条件が、導入要件です。
機能とは異なる視点でとなり、かつ、システム構築には必要不可欠な要件と言えます。
※5W1Hと言いましたが、Why（なぜ？）は出てきませんでした。
WhyはRFPの「提案依頼の趣旨」や「システム構築方針」に記載しますので要件には出てきません。
念のため補足します。
その他の主な要件
非機能要件、導入要件を見てきましたが、それ以外にも大切な要件がありますので、確認していきます。
・データ移行要件
システムリプレイスの場合には、必要になる要件です。
旧システムから移すデータの範囲、ベンダーに依頼する作業内容などを要件として記載します。
・研修要件
システムの操作研修に関する要件です。システム管理者向けとユーザー向けに分けて考えることも多いです。
研修方法、回数、テキスト準備の要否などが要件となります。
・インターフェース要件
周辺システムとのデータ連携に関する要件です。
データの内容、連携方法、連携頻度などを定めます。
・運用・保守要件
システム運用開始後の要件です。
保守サポートの対応時間や障害発生時の対応などが対象となります。
ご覧いただくとわかるように、これらの要件の記載内容は、機能要件や導入要件とも異なります。
RFPに漏れなく要件を記載しするためには、様々な切り口から、要件を定義していく必要があります。
RFPに記載すべき事項に抜け漏れが無いか
ここまで、機能要件以外の要件について、主な例を取り上げてきました。
システムを選ぶ際に確認しなければならない点は、機能だけではないことがお分かりいただけたのではないかと思います。
RFPを作成する際は、このように多岐にわたる要件に抜け漏れが生じないようにしなければなりません。
要件を網羅的に記載するためには、以下のような視点で整理してみることが考えられます。
・システム導入から運用までの作業を棚卸する。
システム導入では、要件定義、基本計画、詳細計画、設定・開発、テスト、並行稼働などのフェーズに分かれます。
また、設定・開発フェーズには、データ移行やインターフェース開発もありますし、テストフェーズ又は並行稼働フェースのタイミングでは、従業員への教育（研修）も必要です。
運用に入ってからも、平常時、月次処理時、障害発生時などに分類できます。
そして忘れてはならないのが、導入から運用に切り替わるタイミングで発生する契約フェーズです。
契約条件として求めるべきこと（契約形態や決済方法など）があれば、それも一つの要件と言えます。
このように、システム導入から運用までの作業を棚卸していくことが一つの切り口になります。
・棚卸した作業ごとに5W1Hの視点で要件を考える。
作業ごとに5W1Hの視点で明示すべき要件が無いかを考えていくことにより、抜け漏れが生じ無くなります。
例えばですが、要件定義フェースでは、いつ、どこで、だれが、何を・・・といった視点で考えていくことにより、要件定義を行う時期を定めなくて問題は無いか、作業分担を示す必要は無いか、作成する成果物を指定しなくてよいか、といった要件に気づくことができる訳です。
要件は、会社のビジネス環境や導入するシステムによっても変わってきます。
その要件を抜け漏れなく洗い出すのは大変な作業です。
RFPを作成する際には、要件の記載漏れを防ぐためにも、上記のような視点でチェックすることをお勧めします。
まとめ
・RFPに記載する要件は機能要件だけではない
☑ 業務機能以外のシステム仕様を対象にした非機能要件
☑ システムの導入や運用保守などシステムの機能・仕様以外の要件
・非機能要件には利用環境や性能などを記載する
☑ 利用環境：OS、ブラウザ等
☑ 性能：処理速度等
☑ セキュリティ：アカウント、アクセス権限等
☑ バックアップ：方法、頻度、リストア方法等
・システムの機能・仕様以外の要件には導入要件や運用・保守要件がある
☑ 導入：スケジュール、体制、役割分担、成果物等
☑ データ移行：対象データ、移行方法等
☑ 研修：研修方法、回数、テキスト準備の要否等
☑ インターフェース：データ、頻度、連携方法等
・RFPに漏れなく要件を記載するために
☑ 導入から運用までの業務を棚卸する
☑ 棚卸した業務毎に5W1Hの視点で要件を考える
