失敗しないRFPの書き方(前編)
RFP作成の注意点 スクラッチの場合、パッケージ/SaaSの場合
システム投資に失敗しないために、比較的小規模のシステム導入でもRFPを作成しようと考える企業が増えてきた。本稿ではスクラッチ開発の場合、パッケージもしくはSaaS利用の場合、それぞれのRFP作成の注意点を解説する。
「何を、幾らで、いつまでに」をベンダーに明確に伝える
RFP(Request For Proposal)とはユーザー企業がベンダーに対して、情報システムの調達のための提案依頼を文書で提示する行為、または提案依頼の文書そのもの、つまり「提案依頼書」のことだ。システム調達を行う際にRFPを書くという行為はかなり以前からあったが、大企業などの一部のシステムの場合がほとんどであった。しかしここ数年、システム調達の失敗を防ぐ有力な手段として、中小規模のシステム案件でもRFPが用いられるケースが増えてきている。
RFPがあらためて注目されるようになったのは、やはり昨今の不景気が影響しているだろう。経営上システムは不可欠であるが、多大な投資が必要である。そして、その投資には失敗は許されない。システム投資を失敗すると、コストが当初の2倍、3倍、そしてそれ以上に増加することも珍しいことではない。また、本番稼働時期が遅れることで、業務に多大な影響が出たり、商機を逃したりといった弊害も小さくない。失敗のリスクを少しでも小さくするために、多少面倒でもRFPを作成しようと考えるユーザー企業が増えているのだ。
「システム投資の目的や背景」「何をシステムに求めているのか」「幾らの予算で検討しているのか」「いつごろまでにシステムが稼働している必要があるのか」、つまり「何を、幾らで、いつまでに」をベンダーに明確に伝えることは、システム投資を成功させる上で非常に重要である。
スクラッチ開発とパッケージ利用の特徴
RFPを作成する上で考慮しなければならないことは幾つかあるが、今回はスクラッチ開発の場合とパッケージ利用の場合において、それぞれ注意すべき点について解説したい。また、一般的なパッケージソフトとSaaS(Software as a Service)の場合でのRFPの留意点の違いなどにも触れてみる。まずは、スクラッチ開発とパッケージ開発、それぞれの特徴を確認しておこう。
スクラッチ開発の特徴
スクラッチ開発とは、独自のシステムを新規に開発することである。基本的に制約のない一からの開発なので、いかようにでもシステムを組むことができる。
スクラッチ開発の特徴
- 業務に合わせて、思い通りにシステムを開発できる
- ほかに事例のない特殊な業務や大規模なシステムの開発に用いられることが多い
- 一般的に開発コストはパッケージ利用より高価になる
- 一からの開発のため、システムはある程度完成しないと動かない
- 設計者やプログラマーの力量により、バグなどの品質が左右される
パッケージ利用の特徴
パッケージ利用はその名の通り、既存の業務パッケージソフトを導入する方法である。パッケージをそのまま利用する場合と、カスタマイズ(機能の修正)やアドオン(機能を新たに追加)を行った上で利用する場合がある。
パッケージ利用の特徴
- パッケージをそのまま利用する場合は、システムに業務を合わせることになる
- 上記では業務要求が満たせない場合は、カスタマイズやアドオン開発を行うことになるが、その場合はパッケージ利用のメリットが減少する
- スクラッチ開発より安価である(ただし、カスタマイズやアドオン開発が増えると、高価になる場合もある)
- 導入に要する期間がスクラッチより短期間である(上記と同じ原因で長期化する場合もある)
- 最初から動くし、バグも少ない
さらにパッケージ利用のもう1つの選択肢として、SaaSやASPなどのサービス利用もある。この場合、上記パッケージの特徴に以下が加わる。
SaaS/ASPの特徴
- ハードウェアやサーバの運用場所が不要となり、初期コストを大幅に削減できる
- 逆にランニングコストは相応に掛かる
- 契約したその日(または翌日)から利用できる
- カスタマイズやアドオンは通常のパッケージ以上に大きく制限される
- データをすべてサービスベンダーに預けることになる
RFPを作成する場合に、システム構築の方針がスクラッチ開発か、パッケージ利用か、あるいはSaaS利用か明確に決まっている場合は、それぞれの特徴を把握した上で記述する方が要求内容は明確になり、ベンダー側としても前提条件が決まるので提案がしやすくなる。
もちろん、RFP作成段階ではスクラッチにするかパッケージにするか決まっておらず、ベンダーからの提案書を見てから判断したいという場合もあるだろう。その場合は純粋に業務要求や運用要求を洗い出して記述すればよいが、当然のことながら提案書評価の作業は複雑かつ増大する場合が多い。一般論で言えば、RFPを書く段階でシステム構築の方針が決まっている方が、調達活動全体の作業負荷は小さい。
RFP作成時の留意点
スクラッチ開発のRFPの留意点
業務に合わせて思い通りにシステム開発ができるというメリット、つまり自由度が高いということは、逆に「要求を明確にしないと、いかようにも解釈できてしまう」というリスクもある。極端な言い方をすれば、「RFPを受け取る前のベンダーは、前提知識がゼロである」と考えた方がよい(実際の調達活動では事前にベンダーに情報提供したり、面談したりするのでゼロということはないが)。従って、かなり詳細な情報をベンダーに与える必要がある。
そこで最も重要な情報が、業務フローとなる。ここでは話を分かりやすくするために純新規ではなく既存システムの再構築の場合で説明すると、以下2点をどれだけ具体的に提示できるかがスクラッチ開発の場合のRFPの要点となる。特に新業務フローが明確に記述されていれば理想的である。
スクラッチ開発のRFPで明示すべき業務フロー内容
- 既存システムではどのような業務を、どのようなフローで処理しているのか
- 新システムでは現行業務フローのどこを改善したいのか、あるいは既存ではやっていないどのような新業務フローを追加したいのか
しかし、現実的にはスクラッチ開発を前提とした場合であっても、RFP作成時点では新業務の目的や内容は決まっているが、新フローまでは決まっていないことも多い。そのような場合は以下の点を注意すべきである。
RFP作成時点で新業務フローが決まっていない場合
- まず業務そのものをきちんとベンダーに理解してもらうこと。そのために現行業務フローをきちんと提示する
- 現行業務フローの課題部分を明示し、問題点を分かりやすく文章化する
- 業務の中心となる処理が新たな業務フローとなる場合は、RFPの段階でもできる限りフローを提示する。未確定の部分があれば、どこが未確定かコメントしておく
パッケージ利用のRFPの留意点
パッケージ利用の場合、システム開発のスケジュール・品質・コストに最も影響を与えるのは、「カスタマイズやアドオン開発をどれだけやるか」ということだ。特にアドオンの増加は影響が大きい。アドオンが増えると開発コストが高くなるだけでなく、運用後のメンテナンス、つまりランニングコストも増大する。例えばパッケージのバージョンアップでは、パッケージ本体部分は動作保証するが、アドオン部分は対象外となる場合がある。その場合、別途ユーザー側のコスト負担で検証テストをしなければならない。従って、業務要求を記述するときに、「必須の機能」と「あれば便利な機能」を明確に分けて、さらに優先順位を付けることが重要となる。
また、「この処理は自社独特のもので、パッケージにはないだろう」と予想される業務処理がある場合は要注意である。そのような処理はアドオンになる確率が高いし、情報が少ないとベンダー側が要求を理解しきれずに、後々品質やコストでもめる要因となる。従って、文章だけでなく模式図などで「見える化」して伝えるべきである。
パッケージ利用の場合、業務要求とパッケージがどれだけ適合するか、フィット&ギャップ分析を行う。このフィット&ギャップ分析ではすべての業務要求を均一に評価してはいけない。
パッケージのフィット&ギャップ分析の注意点
- 優先順位の高い要求からフィット&ギャップ分析を行い、重み付けをして評価する
- 「必須の機能」がパッケージ基本機能またはカスタマイズでどれだけ対応可能かベンダーが分析しやすいよう、RFPの記述を工夫する
上記、「必須の機能」には当然自社独自の機能も含む。RFPの記述を工夫するとは、例えば要求を表形式でまとめて、「1ライン1要求」「明確な優先順位(重み付け)」「基本機能・カスタマイズ・アドオンの3択」などの表記を行うとよいだろう。
また、パッケージ利用の場合はスクラッチ開発と比較して、新業務フローの必要度は低いと考えてよい。もちろんあればそれに越したことはない。しかし、RFP作成は限られた時間しかない場合が多いので、作業の取捨選択も必要だ。パッケージ利用は基本的に「業務をシステムに合わせる」という発想をすべきで、新業務フローを頑張ってゴリゴリ書いて「この業務フロー通りの処理をパッケージで用意しろ」というのは、労多くして益が少ない。従って、パッケージ利用の場合はフィット&ギャップ分析を意識した要求の明確化と優先順位付けを重視しよう。
永井昭弘(ながいあきひろ)
株式会社イントリーグ 代表取締役社長兼CEO
日本アイ・ビー・エムの金融担当SEを経て、ベンチャー系ITコンサルティングのイントリーグに参画。1996年、代表取締役に就任。情報化企画、RFP作成支援、ベンダー選定支援、プロジェクトマネジメント支援などのITコンサルティングの実績多数。特にRFP作成からベンダー選定の調達フェーズに対し独自に体系化したコンサルティングノウハウを持つ。著書『RFP&提案書完全マニュアル』(日経BP)
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品レビュー
「電子帳簿保存法対応」実践術:タイムスタンプ付与などの要件の手軽な実現方法 -
事例
「大企業のデジタル化」成功事例集【コクヨ、九州電力、ヨネックスなど21社】 -
製品資料
“顧客管理の課題”を簡単に解決する方法とは? -
製品資料
契約管理の“あるある課題”をノーコード開発で解決するためのポイント -
製品資料
揺らぐ境界防御 いま企業が特に警戒すべき「3つのセキュリティ課題」とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
2
「技術屋」で終わらないために 情シスが今取るべき認定資格5選
-
3
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
4
Oracle巨大ITプロジェクトはなぜつまずいたのか 8年で導入1割、追加で170億ドル
-
5
「即戦力」は幻想? 中途の3割が消えるAI時代のエンジニア生存戦略
-
6
自宅のWi-Fiが「遅い」「途切れる」本当の原因は? Dellが推奨する鉄則
-
7
継続利用は4割どまり M365 Copilotが「効く業務」と期待外れの境界
-
8
ISMSの“コンサル丸投げ”が招く数千万円の無駄 NTTドコモビジネスの脱出劇
-
9
「VMwareのコスト」に悩んでいるユーザー企業に送る、VMwareを残す・捨てる基準
-
10
PCリプレース時には注意 不完全なデータ消去が情報漏えいのリスクに
ホワイトペーパーランキング PR
-
1
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
2
AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
-
3
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
4
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
5
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
6
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
7
「結局、一部の人しか使わない」 AI活用が業務に定着しない根本的な理由
-
8
AIエージェントで成果は出る? 調査結果に見る費用対効果の実態
-
9
PostgreSQLの「機能」「性能」「運用」「拡張性」に関する悩みの解消法
-
10
ゼロトラストにおける「IDaaSの課題」と補完すべき重要機能とは?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー