RFP の書き方の説明です。
第四回は、工程定義と成果物の説明です。
１．工程定義
開発工程は、ベンダーが決まってからベンダーとの話し合いで決まりプロジェクト計画書で定義されます。
RFP における工程定義は、主にマスタースケジュールと連動し、マスタースケジュールの各大タスクのボリューム感を掴むためのものです。
そのため一番重要なことは、工程定義の各工程が、マスタースケジュールのどの線にあたるのかが分かることです。１対１になっていればベストです。
また工程定義の各工程で重要なのは「単体テスト」です。
「単体テスト」は一番認識違いが起きやすい工程です。
教科書的には「単体テスト」とは、プログラムが個々の機能を正しく果たしているかどうかを検証するテストで、 通常、関数やメソッドが単体テストの単位（ユニット）となります。プログラムテストとも呼ばれます。
ただ現実のプロジェクトでの「単体テスト」は、１画面内のバリデーションなどのテストや、バッチであれば１ジョブ内のテストを指すことが多く、教科書的には「結合テスト」に該当します。
どちらが正解というものではなく、工程の呼び方の問題なので、まずは RFP の中では「単体テスト」がどちらを指すのかを明記しておきます。
また忘れがちなのがアプリケーションの工程以外の基盤系の工程です。非機能要件定義、基盤設計、基盤詳細設計、環境構築などもきちんと定義し、マスタースケジュールと対比できるようにします。
特に開発環境など本番環境以外の環境を作る場合には、環境構築も本番環境と工程を分けて、本番と開発のどちらの環境を先に作るかをマスタースケジュールで明記した方が良いと思います。
スケジュールに余裕のないプロジェクトは、通常、本番環境から先に作ることが多いですが、会社によってはまずは開発環境で品質を担保して、その後、本番環境を構築するといったルールを決めているところもあります。それらは発注者がベンダーに RFP の中で伝える必要があります。
他にも教育や移行の計画、再構築の場合の既存システム凍結期間などがある場合にも、これらもマスタースケジュールに記載します。
２．成果物
各工程でどのような成果物を作成するかを記載します。
成果物に対しての認識合わせはベンダーが決まってから、プロジェクト計画を作る際に話し合い、認識を一致させる必要がありますが、RFP 段階ではそこまでのことはできないので、あまり細かい成果物名は必要ありません。
例えば、要件定義で作成する成果物で、「業務フロー」「機能一覧」「ビジネスロジック」など細かく成果物名を書いても、逆に漏れが出てしまうので、「要件定義書」と書けば十分です。
それよりも要件定義書以外の成果物を記載することが重要です。
議事録、要件定義完了報告書、進捗報告書、といったものです。
またここでも重要なのが「単体テスト」です。
テストケースは作るのか、工程完了報告はするのか、といった点で認識違いが起きやすいです。
前述のとおり「教科書的な単体テスト」は、通常は発注者はレビューしませんし、よほどの大規模プロジェクトでもなければ、品質報告も要求しません。
それに対して「実プロジェクトで多い単体テスト」は、画面でのチェックなどが対象になるので、発注者のレビュー対象となりますし、品質報告の対象ともなります。
それが都合のいい部分だけを解釈して、「実プロジェクトで多い単体テスト」なのに、発注者はレビューせず、ベンダーも品質報告をせず、といったプロジェクトが非常に多いのが実態です。
規模の小さいプロジェクトの場合、一番重要なテスト工程は「実プロジェクトで多い単体テスト」にも関わらずです。
ただ「実プロジェクトで多い単体テスト」は、テストケース数も多いですし、品質報告も大変なので、プロジェクトがはじまってから認識違いが発覚すると費用面で揉める可能性があります。
ベンダーはテストケースは通常作りますが、それを納品物にするとなると、やはり自分達だけで使うものと納品物とでは手間が違いますし、品質報告をするためにはきちんと障害の管理もしないといけないので、RFP の段階で「実プロジェクトで多い単体テスト」の成果物を明記しておく必要があります。
【振り返り】
今回は RFP に記載する工程定義と成果物の説明でした。次回は前提条件や課題等の説明です。
①はじめに（用語集や関連資料など）、目的と背景、対応概要、スコープ
②スケジュール、体制、役割分担、作業環境
③工程定義、成果物
④前提条件、制約条件、リスク、課題
⑤機能要求、非機能要求
⑥提案方法、評価方法
