RFP の書き方の説明です。
第五回は、前提条件、制約条件、リスク、課題の説明です。
１．前提条件
RFP における前提条件は、主にベンダーが見積もりをする際の前提条件です。
例１
自社で用意をした基盤上に、ベンダーが業務システムを構築するような場合、その基盤のスペックや導入されている OS 、ミドルウェア、基盤の利用可能時期などが前提条件になります。
例２
要件定義に参加できるメンバーや参加頻度なども前提条件になります。
例３
プロジェクト開始時点の社内 PC は Windows 7 だけど、本番稼働時には全台 Windows 10 にバージョンアップしているような場合にも、Windows 10 のみ動作保証すれば良いという前提条件になります。
２．制約条件
前提条件と制約条件の違いは難しいです。
教科書的には、前提条件は「計画を立てるにあたって、証拠や実証なしに真実、現実、あるいは確実であるとみなした要因」、制約条件は「プロジェクトまたはプロセスの実行に影響を及ぼす制限要素」となります。
ちんぷんかんぷんです。
実際のところ、前提条件と制約条件には大きな違いがありません。
その条件が、プロジェクトを遂行する上で足枷になるのであれば「制約条件」、逆にその条件がないと困るのであれば「前提条件」です。
例１
自社で用意をした基盤上に、ベンダーが業務システムを構築するような場合、その基盤のスペックや導入されている OS 、ミドルウェア、基盤の利用可能時期などが前提条件になります。
ですが、もしこれが、例えば利用可能時期が総合テスト工程以降の場合には、これは制約条件になります。
あるいは、スペックが低く、それでも性能を担保しなければならない場合には、かなり厳しい制約条件になります。
例２
要件定義に参加できるメンバーや参加頻度なども前提条件になります。
ですが、もしこれが、業務部門のメンバーの参加が月に１回で１時間程度など、要件定義を実施する上で支障の出る頻度だと、それは制約条件になります。
例３
プロジェクト開始時点の社内 PC は Windows 7 だけど、本番稼働時には全台 Windows 10 にバージョンアップしているような場合にも、Windows 10 のみ動作保証すれば良いという前提条件になります。
ですが、もしこの社内 PC にプロジェクト固有のソフトウェアがインストールできないような場合、それは制約条件になります。
３．リスク
リスクは計画から実態が大きく外れる可能性のことです。
リスクには、プラスのリスクとマイナスのリスクがありますが、通常の RFP にはマイナスのリスクを記載します。
前提条件もそれが崩れるとプロジェクトに影響を及ぼすためリスク管理の対象ですが、崩れる可能性が低いから前提条件に記載しているため、通常は RFP のリスクには記載しません。
つまり RFP のリスクに記載をするものは、見積もりをする上での前提として良いけれど、前提が崩れる可能性があるから、バッファーを積んでおいてね、というものを記載します。
例１
自社で用意をした基盤上に、ベンダーが業務システムを構築するような場合、その基盤のスペックや導入されている OS 、ミドルウェア、基盤の利用可能時期などが前提条件になります。
ですが、もし利用可能時期が、何らかの要因で遅れる可能性がある場合には、リスクとなります。
例２
要件定義に参加できるメンバーや参加頻度なども前提条件になります。
ですが、要件定義の時期が業務部門の繁忙期と重なっている場合には、業務を優先して要件定義への参加頻度が落ちる可能性があるため、リスクとなります。
例３
プロジェクト開始時点の社内 PC は Windows 7 だけど、本番稼働時には全台 Windows 10 にバージョンアップしているような場合にも、Windows 10 のみ動作保証すれば良いという前提条件になります。
ですが、台数が多くて本番稼働までに全台の切り替えが終わらない可能性があるのであれば、リスクとなります。
これらをリスクとして記載することで、ベンダーが提案書の中でどのようなリスク対策をするかも評価の一つとなります。
４．課題
RFP の時点で課題があることは少ないですが、要求定義をまじめにやっているプロジェクトであれば、要求定義中に発生した課題を記載することになります。
例１
自社で用意をした基盤上に、ベンダーが業務システムを構築するような場合、その基盤のスペックや導入されている OS 、ミドルウェア、基盤の利用可能時期などが前提条件になります。
もし利用可能時期が、総合テスト工程以降であれば制約です。
製造工程には間に合うけど、何らかの要因で遅れる可能性がある場合にはリスクとなります。
計画では製造工程ですが、間に合わずに総合テスト工程になってしまいそうなので、インフラ部門と製造工程に間に合わせるために調整中であれば課題となります。
例２
要件定義に参加できるメンバーや参加頻度なども前提条件になります。
もし参加頻度が月に１回１時間程度であれば制約です。
要件定義の時期が業務部門の繁忙期と重なっている場合には、リスクとなります。
業務部門のキーマンが異動してしまったので、異動先の所属長と要件定義への参加を調整中であれば課題です。
例３
プロジェクト開始時点の社内 PC は Windows 7 だけど、本番稼働時には全台 Windows 10 にバージョンアップしているような場合にも、Windows 10 のみ動作保証すれば良いという前提条件になります。
この社内 PC にプロジェクト固有のソフトウェアがインストールできないような場合には、制約条件です。
本番稼働までに全台の切り替えが終わらない可能性があれば、リスクとなります。
社内 PC にプロジェクト固有のソフトウェアのインストールが必須で、PC の管理部門と調整中であれば課題です。
【振り返り】
今回は RFP に記載する前提条件、課題等の説明でした。次回は機能要求と非機能要求の説明です。
①はじめに（用語集や関連資料など）、目的と背景、対応概要、スコープ
②スケジュール、体制、役割分担、作業環境
③工程定義、成果物
④前提条件、制約条件、リスク、課題
⑤機能要求、非機能要求
⑥提案方法、評価方法
