〇 RFP（提案依頼書）の柱となる要求は端的にいえば「何を、いくらで。いつまでに」したい、である。「何を」は業務要求・技術要求・運用要求の3つであり、「いくらで」は見積もり、「いつまでに」はスケジュールである。
これらの主要な要求以外にもRFPに記載すべきいくつか要求事項がある。その1つが「納品物」の要求だ。システム構築のプロジェクトでは様々な成果物が作られる。その成果物の中でユーザーが要求し、ベンダーもそれを了承し、両者合意したものが正式な「納品物」となる。納品物の候補としては以下のように様々なものがある。
① システム構築のベースとなるもの。
- 要件定義書
- 基本設計書（外部設計書）
- 詳細設計書（内部設計書）
- テスト計画書（テスト仕様書） 単体テスト、結合テスト、総合テストなどテスト種類ごとに作成
- テスト結果報告書
② プロジェクト管理に関するもの。
- プロジェクト計画書
- 進捗管理表
- 課題管理表
- 議事録
③ マニュアル類。
- システム管理者マニュアル
- ユーザー操作マニュアル
- ユーザートレーニング用の研修テキスト（最近では動画で作成されることもある）
- 障害発生時対応マニュアル
④ プログラムや本番稼働環境。
- 実行プログラム
- ソースコード
- 本番稼働環境（SaaSやノーコードの場合）
- ステージングやバックアップなどの別環境
⑤ システム設定情報。
- システム構成図（ハードウエア、ソフトウエア、ネットワークなど）
- サーバーやネットワーク機器の設定情報
さて、問題はこれらの成果物から何を納品物として求めるかである。筆者のおすすめは、まずベンダーがどのような納品物を考えているか情報をもらうことだ。図1に、RFPに記載する、納品物に関する要求例を示す。この方法で重要なのはRFPに記載しているものはあくまでも例であり、まずはベンダーとして何を納品する予定なのか、それらの納品物は無償なのか有償なのかを聞くことである。それを見たうえで過不足がないか検討する方法だ。
「ベンダーが出してくるものを全部もらえばいいのではないか」という意見もあろう。「もらえるものはもらう」というのは確かにシンプルな考え方ではある。だが、納品物の作製にはベンダーの労力がかかる。「開発に付随するので無償で納品されます」というものも少なくないが、無償といっても別見積もりではないだけで、実際には納品物の作製コストは開発費に含まれていると考えるべきだろう。だから、不要なものは「いらない」と明示したほうがよい。
また、「本当にその納品物に利用価値があるか、本番稼働後に活用することがあるか」についてもRFP作成段階では思案したほうがよい。それは、システムの対象となる業務や規模、システムの開発手法、本番稼働後の運用保守をユーザー主体で実施するのかベンダー委託なのか、などの要因により異なってくる。それでも以下の6つはどのようなプロジェクトでもベンダーからの正式な納品物とすべきだろう。
- 要件定義書
- 基本設計書
- 総合テスト（ベンダーのテスト）結果報告書
- システム管理者マニュアル
- 実行プログラムとソースコード（プログラム開発を行った場合）
- 本番稼働時点のシステム設定情報
以降では、これら6項目について順に説明する。
要件定義書。
ウオーターフォール型の開発やアジャイル型をうたっていても要件定義というフェーズが示されている案件であれば、要件定義書は納品が必須の最重要なドキュメントである。要件定義は教科書的にいえばユーザー主体の作業であり、準委任契約で行われることがほとんどである。だから本来は成果物の納品は必須ではないのだが、現実には「要件定義書」というドキュメントはベンダーに作ってもらうほうが多い。基本設計以降の工程で適宜参照され、開発途中の仕様変更か否かを判断する基となる。またユーザーの受け入れテストでの確認項目にもなる、重要なドキュメントである。
基本設計書。
ベンダーによって内容や用語、表記の仕方などがけっこう異なるが、おおむね業務フロー、機能、画面、帳票、外部インターフェースなどが記載される。クラウドのサービスを利用する場合でもこれらは設計されるので、納品物として求めたい。
基本設計書は本番稼働後の仕様変更や追加開発の時に参照されることがあるので、情報がアップデートされていることが重要である。基本設計の段階で記載したことが、後続のフェーズで仕様変更したり、設計ミスを修正したりで変更されることは多々ある。その変更が基本設計書に反映されずに、プログラムだけ修正されると、出来上がった本番稼働システムと納品された基本設計書に齟齬（そご）が生じている。その齟齬が放置されたまま納品されると、数年後の追加開発時やシステム再構築時の調査などで問題となることがある。納品物としての設計書は本番稼働時のシステムの仕様が合致して記載されていることを求めたい。
総合テスト（ベンダーのテスト）結果報告書。
現実問題として多くのユーザーにとっては、詳細設計書やベンダーの単体・結合テスト関連のドキュメントは納品物としての価値はあまりない。ユーザーはそれらを見ても内容がよくわからないからである。ベンダーからの納品物リストに詳細設計書が入っていない場合、それをあえて要求するかどうかはユーザー次第だ。詳細設計書に書かれている内容はほとんどわかる、という情報システム部であれば納品物として要求すればよいだろう。
ユーザーにとって大事なのはベンダーの総合テストの内容と結果である。ベンダーがテストを行って合格と判断してから、ユーザーの受け入れテストに渡すはずなので、総合テスト結果報告書には合格とした根拠が記載されている。もし、受け入れテストでボロボロと不具合が発見されたなら、ベンダーのテストがいい加減だった可能性が高い。ベンダーに不手際があったかどうかのエビデンス（証拠）となるのがテスト結果報告書である。
システム管理者マニュアル。
マニュアルは有償対応となるケースが増えているが、筆者の個人的な考えとしてシステム管理者マニュアルは本来ベンダーが無償で提供すべき納品物ではないかと思う。管理者マニュアルはユーザーでは基本的に作成することが難しいし、またシステムの運用上必要なものであるからだ。逆にユーザー操作マニュアルは有償でよいし、理想的にはベンダーではなくユーザーが自ら作成し、それを用いて社内の他のユーザーに指導していくほうがよい。さらにシステム操作とシステム外の作業を含めた業務マニュアルとなれば、これはベンダーには作ることができないので、納品物として求めるべきではない。
実行プログラムとソースコード。
こちらはプログラム開発を行った場合、当然の納品物であり、特に請負契約の場合の成果物そのものであるので、異論はないはずだ。SaaSなどクラウドサービス利用の場合はこれらの納品はない。
本番稼働時点のシステム設定情報。
仮に本番稼働後のシステム運用をベンダーにすべて委託したとしても、サーバーやネットワーク機器などの設定がどのようになっているかの情報はリスク管理の観点からユーザーとして保持すべきである。また、システムやネットワークの設定は様々なタイミングで変更されることがあるので、こちらも変更があった場合きちんと資料も反映し、最新の状態を保つことが肝要である。
