ビジネスに使えるITツールとは

企画委員　秋山　剛

　近年では中堅以上の企業ではＩＴ調達に際してRFPを発行するケースが多くなっています。しかし企業によってレベル差がありRFPとして充分に機能していないものも見られます。また中小企業においてはRFPの存在すら認識されていないケースも多いのが現実です。最適なITシステムを調達するためにRFPの重要性が高まっており、より精度の高いRFPが求められています。ここではＲＦＰの作成方法や、有用なサイトをご紹介します。

◆RFPとは
　RFP （request for proposal）は「提案依頼書」のことで、ユーザー企業がITベンダーに対して自社が調達したいシステムの要件をまとめたものである。ユーザー企業がITベンダーに対してRFPを発行し、ITベンダーはRFPに沿って提案書を作成し、ユーザー企業が提案書の評価を実施する。

◆RFPの目的

①ITベンダーから精度の高い概算見積を取得する

　一般的にITシステムを調達する場合にシステムの概要を伝え概算見積を取った上で発注先を１社に絞り詳細仕様の検討を実施する。しかし多くのケースでは詳細仕様の時点で概算見積にはない要件が発生し、正式見積段階で大幅な見積UPが提示される。
　ユーザー企業では概算見積段階で予算を取得しており、大幅な見積UPに対し追加予算を獲得するか、必要な機能を削って予算内に収める努力を強いられ、導入したITシステムが１００％の効果を発揮できないケースも発生している。
　このようなリスクを減らし、概算見積段階でより正確な見積を取得するためにRFPを作成することが重要となる。

②複数のITベンダーに同じ条件で提案させる

　複数のITベンダーから提案依頼を受ける場合に、概要書や口頭によって要件を伝えても提案するITベンダーの理解力の差等により提案の範囲が統一されず、横並びの比較ができないケースが発生する。価格が安くて提案範囲が狭いものと、価格は高いが将来に渡った提案がされているものを単純に比較することは難しく同じ条件で提案を受けて横並びの評価を可能にするためにもRFPを作成して提案依頼の範囲を明確にすることが重要である。

③言った言わないの曖昧な表現をなくし、要件を明確にする

　ユーザー企業にとっては常識の範囲の当たり前のことであっても、明確にその要件を明示していないとITシステム導入時にユーザー企業が「こんなはずじゃなかった」と言ってもITベンダーからは「それは聞いていない」と言われ改修に追加費用を請求されることになる。
　例えばレスポンスの条件を明確に提示せず、実際に導入されたシステムを使ってみて「これでは日常業務に耐えられないのでなんとかしてくれ」と言っても、「この処理は負荷が高いのでこれくらいかかるのは当たり前。レスポンスを向上するためにはシステムの設計からやり直さないといけないので大幅な追加費用が発生する」と言われ、収集がつかないケースも見受けられる。
　このように後で言った言わないでもめることがないように必要な条件は文書で明示しておくためにもRFPが重要となる。

◆RFPに記載すべき事項

①会社概要

　提案依頼をするITベンダーには自社の業界に詳しい人材がいないケースが多々ある。自社がどのような業界に属し、どのようなビジネスモデルで業務を行っているかも伝えないと誤った知識で提案されることになる。自社のビジネスモデルに最適な提案を受けるためにも自社の概要を伝える必要がある。
　またデータ項目の桁数や発生するデータ件数も業態によって様々なので、別の業界で実績のあるITベンダーであっても自社の業態に最適な提案がされるとは限らない。そのためにも主要なデータの桁数やボリュームも伝える必要がある。

（会社概要に記載すべき内容）
・会社の業務内容（ビジネスモデル）
・ＩＴの現状についての説明
・主要なデータの桁数とボリューム（取引先数、品番点数等）

②業務課題

　IT導入の目的は経営課題・業務課題を解決することである。それらの課題を明確にせずに必要なITの要件だけを伝えても目的が達成されるITが導入されるとは限らない。課題を解決するための手法はいくつもあり、そのうちの１つだけをIT要件として伝えた場合に詳細検討を進める中でそのIT要件を満たすことが目的になってしまい、本来の目的から逸脱してしまうことも起こりうる。なんのためにITを導入するのか、その目的を明確にして自社のITプロジェクトのメンバー及びITベンダーと目的を共有することが重要である。

③新業務フロー

　ITを導入する場合には、現状の業務をそのままIT化しても個別業務の改善に留まり、全社最適にはならない。IT導入を行う場合には必ず現在の業務を全社的な視点で見直し、業務の「あるべき姿」を明確にした上で、「あるべき姿」を実現するためにITを活用することが重要である。そのためには業務課題の抽出においても全社的な視点で課題を抽出した上で、その課題を解決するための「新業務プロセス」を考案し、新業務フローとしてまとめ、システムの関わりも含めて記述をする必要がある。

④システムの範囲

　複数のITベンダーから提案を受ける場合に、今回導入を予定しているシステムの調達範囲を明確にして同じ条件で提案を受け横並びの評価を実施する必要がある。そのためにもシステムの範囲を図等を用いてできるだけわかりやすく提示する。
　またハードウェアについてもネットワークや周辺装置も含めてどこまでの範囲を含めるのかを明確にする必要がある。

⑤ＩＴ化要件

　IT化要件では業務課題を解決するために必要となる機能について詳細な要件（機能要件）を明示する。詳細な要件とは一言で言えば「入力に対してどのような結果を得たいか」である。必要な場合はＤＦＤやＥＲＤ等を使用することもあるが要件が伝われば手法は限定する必要はない。
　IT化を実施する場合に、業務上非常に重要な役割を果たす機能と、必要ではあるが詳細にはあまり拘る必要がない機能もある。たとえば「顧客管理システム」を導入する場合にどのような顧客の情報を管理するのかはシステムの成否に関わる重要な要件であるが、「生産管理システム」を導入する場合には顧客の情報は基本的な項目があれば十分であり詳細に拘る必要がない。必要なすべての機能に関して詳細な仕様を提示すればより正確な見積を取得することは可能であるが、無駄な労力と時間を費やすだけで付加価値の高い作業とは言えない。業務課題を解決するために重要となるポイントだけに絞って詳細な機能要件を定義することが望ましいと言える。

⑥必要機能・帳票一覧

　IT化要件で記述しなかった機能も含め全体でどれだけの機能が必要なのかの機能一覧と、どのような帳票が必要なのかの帳票一覧を提示する。ITベンダーはこれらの数で全体のボリュームを見積もることになるため、必要な機能を漏れなく記述する必要がある。
　またITベンダーからパッケージでの提案がされる場合に、パッケージ標準機能の範囲でどこまでの機能が満たされるか、カスタマイズやアドオンが必要な機能はどれだけあるのかを明確にしてもらうことも重要である。

⑦非機能要件

　システムに必要な機能以外に、システムを稼働させ、運用するために必要な非機能要件についても明示する必要がある。

　主な非機能要件には以下がある
・スケジュール・納期
　導入までの希望スケジュールと納期を明確にする
　※運用教育・データ移行に関する要求も含める
・利用人数・クライアントの台数
　パッケージにおいてはライセンス料の見積に必要になる
・納入物件
　ハード・ソフト以外に、設計書や操作説明書等要求する納入物を明確にする
　※受託開発においてはソースの提供等の条件も明確にしておく必要がある
・教育訓練
　システムを使用するユーザへの教育内容、期間等を明確にする
・データ移行
　システムを移行する場合には旧システムから移行すべきデータの種類やボリューム等を明確にする
・セキュリティ
　システムのセキュリティ条件を明確にする
・品質・性能条件
　レスポンス等の条件を明記する
・保守条件
　保守の条件（時間等）を明確にし、保守範囲・方法等についての提案を求める
・検収条件
　検収の時期や条件を明確にする
・機密情報保護対策
　機密保持契約等に関する条件を明確にする
・権利
　完成したシステムの所有権、利用権、二次的著作物の利用権等の権利が自社に移転されるかどうかを明確にする
・ITベンダーの情報
　ITベンダーからの提案を評価する場合に、提案内容だけでなくITベンダーの信頼性や実績も評価の対象となるため、それらを評価するための情報として企業情報・導入実績・開発体制・開発方針等を提示してもらうことを求める

◆RFP作成に参考になるリンク集

・ITコーディネータ協会が作成したRFPのサンプルを公開しています
http://www.itc.or.jp/foritc/useful/rfpsla/rfpsla_doui.html
・日経ITプロフェッショナルで「業務システム分析のためのUMLモデリング演習」

の回答としてRFPのサンプルを公開しています
http://itpro.nikkeibp.co.jp/NIP/modeling/index.shtml
・ThinkITのサイトでRFPの作成方法を解説しています
http://thinkit.co.jp/free/article/0701/25/1/
・＠IT情報マネジメントのRFP作成に関する記事
http://www.atmarkit.co.jp/fbiz/cinvest/opinion/qa/qa12.html
・日立システムズのサイトで「失敗しないRFPの書き方」が紹介されています
http://www.tensuite.jp/ts/column/operation/002/
・EnterpriseZineのサイトでRFPについて解説されています
http://enterprisezine.jp/article/detail/1326

以上