非IT企業の情報システム部がシステム開発を依頼させられた場合④～RFPの作成～

はじめに
RFPとは
システムベンダー決定までの大まかな流れ
RFPのポイント
RFP記載事項例
RFPの配布
- Related posts:

はじめに

情報システム部の方で、ITに詳しいだろうからという理由で、ビジネス用のシステム開発のマネージメントをするように依頼されることはないでしょうか？

実際は情報システム部の仕事と、ビジネス用システムの開発は大きく異なるものかと思います。

また、非IT企業では、システム開発を依頼する機会も少なく、一発勝負になることも多いです。

そんなお悩みを解決できるよう、いち非IT企業の情報システム部メンバーとして、実体験に基づくシステム開発の依頼の流れをまとめさせていただきました。

システム開発でお悩みの方は、是非見てみてください！
またITベンダーの皆さんにも企業側はこんなこと考えてるんだなーと思ってみていただければ嬉しいです。

RFPとは

RFP:

Request for Proposal (提案依頼書)の略。
システム開発を委託するITベンダーに具体的なシステム提案を行うように要求すること。

システムベンダー決定までの大まかな流れ

要求定義
RFP作成
選定先決定
選定用の点取り表作成
提案先へRFP説明
提案先より提案受領
点取り表完成
提案先決定

RFPのポイント

資料として完結していること
はじめてRFPを見た人が、何を提案してほしいと考えているかがわかること。
付記必要な資料は確実につけておくこと
点取り表と整合性がとれていること
ベンダー評価に利用したい項目を回答してもらえるような記載をしていること。
例えば会社規模が知りたいのであれば明記するように明言すること。

RFP記載事項例

作成してほしいシステムの概要
ベンダーに委託したい業務範囲
ムラタ側の体制想定
スケジュール
提案依頼事項
提案期限

選定するために必要な情報を書き、PM（プロジェクトマネージャ）としてやり易い体制を敷けるよう選定できる情報が出てくるように記載する。

結局ベンダー選定した後に、そのベンダーの人々と長時間調整し、苦労を共にするのはPMであるあなたです。そのため、単純に安いというだけではなく、自分にとってやりやすい素敵な企業を選ぶのは非常に重要です。

また、ドキュメントやモックアップが必要な場合は明記してあげる必要がある。RFPに記載されている成果物が期待される成果物であり、記載されていないもの、提案書に書かれてこないものは作成されない。
　※「当然作るものと思ってました」は通用しない。

【目次例】
1.	前提
1.1.1	目的
1.1.2	用語
1.1.3	ビジネス概要
1.1.4	ビジネス関係概略
1.1.5	システム概要
1.1.6	基本方針
1.1.7	システム規模
1.1.8	利用ユーザー数
1.1.9	取り扱いデータ
1.1.10	業務データサイズ
1.1.11	データ送信
1.1.12	ユースケース
2.	業務委託範囲と内容
2.1	開発する機能内容
2.2	委託する業務
2.3	委託する業務内容と役割分担
2.4	委託業務概要
3.	サービス要件
3.1	システム開発
3.2	保守運用
3.3	運用保守サービスレベル
3.4	監視
3.5	セキュリティ
3.5.1	電子媒体の管理
3.5.2	文書の管理
3.5.3	システムファイル、ＤＢのセキュリティ
3.5.4	開発・保守運用機器のセキュリティ
3.5.5	変更管理
3.5.6	ウィルス対策
3.5.7	セキュリティ監査
3.5.8	システムアクセス端末
3.5.9	アカウント管理
3.6	保証要件
3.7	機密保持
3.8	要員/体制
3.9	契約期間
3.10	その他
4.	提案依頼事項
4.1	システム構成
4.2	サービス内容
4.3	サービスレベル保証
4.4	セキュリティ
4.5	体制・要員
4.6	コミュニケーション
4.7	費用・契約
4.8	貴社情報
4.9	納期およびスケジュール
4.9.1	予定本稼働開始年月日
4.9.2	スケジュール
4.10	納品条件
4.10.1	納品物品の明細
4.10.2	受渡媒体、部数、方法、時期
4.11	教育訓練
5.	提案手続きについて
5.1	提案手続き・スケジュール
5.1.1	提案書提出について
5.1.2	提案書の採否連絡
5.1.3	プレゼンテーション日程
5.1.4	最終提案の採否連絡
5.2	提案依頼書に対する窓口
5.2.1	窓口
5.3	提供資料
5.3.1	ご提供資料
5.3.2	提供資料の扱いについて
5.4	参加資格条件
5.5	別紙1 システム概要図
5.6	別紙2 開発画面・機能一覧
5.7	別紙3 ユースケース