Webシステム開発の受託側と発注側の両方に長年携わってきた筆者が、本当にあった失敗事例やつまづきやすいポイントを紹介しながら、Webシステム開発の知識や経験が浅い担当者が、自社に最も適したシステム開発会社を見つけ出すための正しい道筋を、全5回に分けて解説する。
きちんと要望を伝えたつもりなのに、ピンとのずれた提案ばかり
酒蔵メーカー「永鶴酒造」の山下さんは、ECサイトを新たに開発するため、比較検討の末に選び抜いたシステム開発会社3社と、それぞれ打ち合わせを行った。
特に説明資料や企画書などは事前に用意せず、口頭でどんどん要望を伝えていく山下さん。つい盛り上がって話が本題から脱線したり、その場で思いついたアイデアを口にしたり。開発会社の営業担当は山下さんの話を笑顔でうなずきながら、必死にメモを取る。
後日、3社から出揃った見積と提案書を見ると、ある会社は必須と伝えたつもりの要素が含まれていなかったり、自社の課題からずれた提案だったりした。また、ある会社は、その場の勢いで盛り上がった内容がすべて反映され、大幅に予算を超過した見当違いの見積になっていた。結局、山下さんはすべての開発会社に再度説明をするはめになってしまった……。
第3回は「提案依頼書（RFP）作成」を解説
リサーチとヒアリングによって発注先のシステム開発会社を絞り込んだら、いよいよ提案をもらうことになるのだが、ここで重要なのがRFP（Request For Proposal／提案依頼書）の作成だ。RFPは開発会社に良い提案をもらうための重要な情報伝達手段であり、プロジェクト全体の質を高めるためにも欠かせない要素となる。
第3回では、中小企業のWebシステム開発で使い勝手のよいフォーマットを示しながら、RFP作成にあたって注意すべきこと、基本的な考え方などを解説する。
「直接口頭で伝えればいい」は、プロジェクト失敗への第一歩
RFPとは、Request For Proposal（提案依頼書）の略で、発注企業がシステム開発を行う際に必要な要件をまとめ、発注先の開発会社に具体的な提案を依頼するための資料だ。
システム開発の発注経験がない担当者が、次のように疑問に思うケースも少なくない。
お金を払う側（発注企業）が、お金をもらう側（システム開発会社）のために、なぜ手間をかけてわざわざ説明資料を準備しなければならないのか、一から相談に乗ってくれるものではないのか
しかし、何も用意せず、すべて口頭で進めるのは後々の失敗につながる可能性が高い。伝達の達成レベルが、説明する側・受け手側個人の能力やその時の状況に大きく影響され、次のようなことが起こり得るからだ。
- 各社に伝える内容が、ミーティングごとにブレる。
- その場の話の盛り上がりに流され、伝えるべきポイントの強弱や優先順位にバラつきが出る。
- その時の体調や精神状態などで、伝えるべきことが抜ける、忘れる。
- 説明者の話に丁重に対応しながら、すべてメモを取ることは困難。
- メモを取りながら同時に質問することは難しく、確認漏れが起こりやすい。
開発会社の担当者は、発注企業から直接説明を聞く営業、技術的な部分を考える社内のエンジニアというように、役割が分かれている場合が多い。口頭だけだと、すべての情報は直接話を聞いた人の「メモ」と「記憶」だけになる。つまり、開発会社のなかで「伝言ゲーム」が発生し、情報が誤った形で伝わる可能性があるのだ。
口頭での伝達は、正確な情報や一番解決したいことを開発会社へ明確に伝えることは不可能に近い。第1回では、開発会社に声をかける前に最低限準備すべきことがあると話したが、それは提案依頼でも同じで、発注企業がシステム開発の要望を正確に伝えるためには説明資料であるRFPを準備すべきであり、それが良い提案を引き出すことにつながる。
RFPは正しい情報を提供し、良い提案をもらうための手段
RFPは、システム開発業界では一般的な用語であるが、発注が未経験の人には耳慣れない言葉だろう。ただRFPといっても、難しく構える必要はまったくない。良い提案をもらうために、できるかぎり限り正確な情報を正しく伝えるための説明資料だと考えればよい。つまり、RFP作成の目的は、
システム開発会社へ、解決したい課題や達成したい目的・目標を明確に伝えること
なのである。具体的なRFPの作成方法は、全体構成を次の3つに大きく分けて考えると作成しやすい。
- 全体像
今回提案を依頼したいシステム開発の全容をシンプルに理解させるためのもの。
開発の目的、目標、予算、スケジュールなどを記載する。 - 提案の要件
具体的に何を満たした提案が欲しいかということを具体的に示したもの。
提案を依頼したい範囲、役割分担、必須な機能、運用・保守、成果物を記載する。 - その他
1と2以外に伝えた方がよいと思われる情報、判断に迷っていることなどを補足として記載する。
| 1. 全体像 | 開発の背景 |
|---|---|
| 開発の目的 | |
| 目標・成果 | |
| 予算規模 | |
| スケジュール | |
| ターゲット | |
| 取り扱いコンテンツ数 | |
| 2. 提案の要件 | 提案を依頼したい範囲 |
| 納品成果物 | |
| システム開発の手法 | |
| 機能要件 | |
| 運用・保守要件 | |
| 教育・研修要件 | |
| 貴社の体制 | |
| 当社の体制 | |
| 3. その他 | 検討事項 |
| 想定する競合サイト |
全体の構成をふまえて、実際に作成したRFPのサンプルは以下の通りだ。特に注意すべき点はcheckポイントとして、後半で詳しく解説する。
全体像 check2
- これまで当社の売上は小売店舗と卸販売が全体の95％以上を占めている
- ECサイトを開発することで、新たな販売チャネルを開拓し、売上拡大を目指す
- 初年度のEC売上3,000万円、3年後に年間1億円を目標とする
- 開発にあたっての初期費用：300万円を上限とする
- 保守・運用は上記300万円に含めない。初期費用と分けて、月額にかかる費用を明記のこと
- 提案書プレゼン：11月1日～11月10日
- 開発会社の決定：11月末日迄
- 設計・開発開始：12月～
- ECサイト公開日：翌年4月1日
- 清酒、焼酎などの愛好家（40代以上）の男性
そのなかでも、これから自分のお気に入りの銘柄を見つけていきたいと考えている ビギナー層
- 清酒、焼酎などの150～200種類
提案の要件 check3
- 必須（以下の要素をトータルで考えた最適な提案を依頼）
- 仕様書の作成
- ECサイトの設計、デザイン、コーディング作業
- 本番サーバーの設定および本番環境への移行
- ECサイト運用の社内向け研修
- ECサイトの保守・運用
- サイトのキャッチコピー、商品説明文は当社が提供する資料やパンフレットをもとに、貴社に原案作成を依頼
（弊社はロゴデータ、商品リストや商品の画像を提供するのみ） - 貴社に強みがある場合は、集客・販促も同様に提案を依頼したい
- コンテンツ一式
- ECサイトの仕様書
- 業務フローのチャート
- 管理画面の操作マニュアル
- オープンソースかASPサービス、パッケージソフトから最適なものを提案
- サイトの商品の更新、最新ニュースのアップはHTMLの知識のないスタッフでも簡単にできる（CMS対応）
- サイトの表示速度は2秒以内
- 会員登録機能、メール配信機能あり
- サーバーは外部委託（サーバー会社への取次、SSL対応なども含めて提案を依頼）
- 決済はクレジットカード、宅配会社の代引き
- 日報などの集計が簡単にできる
- PC、フィーチャーフォンに対応
- CMS対象外のコンテンツの更新、問合せに対して、営業時間内はタイムリーな電話対応を希望
- サーバーの管理
- サポートの窓口担当者を付けること
- 当社のシステム利用者（3名）に操作マニュアルのもと、操作方法の研修を行う
- プロジェクトリーダーは、ECサイト開発の経験が豊富であること（具体的な開発実績も提示してください）
- プロジェクトリーダーは、提案プレゼンテーション、受注後のミーティングに必ず参加すること
- 当社の体制は、プロジェクトリーダー山下、メンバー：商品管理、出荷、経理部門から各1名、計3名を予定
その他 check5
- 技術的要件（Flash使用有無、ブラウザなど）はアドバイスがほしい
- フィーチャーフォン版では、PC同等まで対応すべきか
- 弊社が保有する商品画像はカタログ印刷用のみ。そのまま提供して問題はないか
- 澤野醸造、金桂冠、菊錦酒造など
- 自社小売店での顧客の行動様式
※リアル店舗を持っている場合は、そこでの客層や行動様式も参考情報として提供する- 40代以上～シニア男性、所得層は高めと推定
- 雑誌の比較記事や店員のおすすめなどを参考にして、いろいろな銘柄を試したがる人が多い
- 試飲して自分の好みに合っていると思えば気前よくお買い上げ
- 来店の際は異なる銘柄を数本まとめて買って行く人が多い（1回の来店での平均購買単価は7,000円程度）
- 合わせる酒の肴（料理）や酒器にも関心、こだわりがある人が多い
- 「これ！」というお気に入りの銘柄が見つかれば、定期的にリピート買いする人が多い
以上
6つのRFP作成チェックポイント
RFPの作成では、いくつか押さえておくべきポイントがある。特に重要なポイントに絞って解説していこう。
- check1 開発プロジェクト名を共有できているか
まずプロジェクト名を必ず記載する。これは「●●社 ECサイト開発計画」など簡単なもので十分だ。企画書にタイトルを書くのと同じで、プロジェクト名称があると、共通のゴールを発注側、受注側で共有しやすくなる。
- check2 最低限必要な項目が含まれているか
システムの全体像を把握するために最低限必要な項目は、「開発の目的」「成果」「予算」「スケジュール」だ。これらは、本連載の第1回で作成したものがベースにあれば、すぐにできあがるはずだ。また、目標（ゴール）は売上などの数値目標も示せるとよい。
- check3 システム開発会社の役割、期待することは明示してあるか
RFP作成で重要なことの1つは、発注企業と開発会社の役割分担を明確にすることだ。ここが曖昧な状態だと、「これは（相手方が）やってくれるはず」といったお互いの思い違いから、後々タスクのお見合いが発生して、トラブルになりやすい。
ポイントは、「必ず提案してほしいこと」「可能であれば提案してほしいこと」を明確に記載することだ。
- check4 実際に対応してくれるシステム開発会社のメンバーはだれか
開発会社の開発体制、メンバーは提案の段階で具体的になっていた方がよい。受注が決まるまでは、社長をはじめとするメンバーが真摯に対応してくれたものの、受注が決まった途端、「あとはエンジニアと直接やり取りしてくれ」という状況になり、困ってしまったという話もよく耳にする。
特に、プロジェクトを仕切るリーダーは、過去の経験や実績だけではなく、プレゼンに参加させて人柄や相性などもチェックすべきだ。また、受注後もプロジェクトにコミットしてもらうために、必ずミーティングに参加することを条件に入れるのもよい。
- check5 判断に迷っていること、よくわからないことをリストアップ
RFP作成の段階では、何をどこまで開発するか、すべて決まっていないことの方が多い。その場合は、迷っていることを開発会社にきちんと伝えることが重要だ。そうすると、開発会社は開発した場合のメリット、デメリットなどをふまえて、提案を考えることができる。
また、中小企業のITに詳しくない担当者だと、当然、技術的によくわからないいことも多い。その場合は、わからないこと、疑問に思っていることを正面から伝えた方が、発注企業と開発会社、お互いのためになる。業界特有の専門用語など、わかったつもりで話を進めてしまうのも危険だ。
- check6 役立つと思った情報はどんどん提供していく
上記以外に、これは開発会社に伝えておくと提案に役立ちそうと思うことは、遠慮せずにどんどん提供していこう。発注側にとっては当たり前のことでも、参考になる情報は多い。ECサイトの場合だと、競合と意識しているサイト、自社に合いそうなデザインに近いサイトなどを教えてあげると、開発会社の業界調査が効率的に行えるうえ、デザインのイメージの相違なども避けやすくなる。
また、サイト情報だけではなく、自社のカタログやパンフレット、過去の販促物など、紙媒体も同様に参考になるので、ぜひ一式を準備することをおすすめする。
雛形は参考にしながらも、こだわる必要はない
RFPの作成は、RFPにフォーカスした書籍が多数あるほど奥深いテーマだ。インターネットで検索すると、さまざまなフォーマットを見つけることができるだろう。
上記サイトをざっとながめるだけでも、さまざまなフォーマットがあることがわかる。本稿でも、いろいろな参考事例やサンプルを提示し、RFPの作成について解説をしたが、特定のフォーマットに必ずしもこだわる必要はない。作成した書類を今回紹介したチェックポイントをベースに見直し、伝えるべき情報が抜けていないか、まだ検討しきれてないことはないか、確認しながらブラッシュアップを繰り返し、社内で意思統一するための叩き台のような形で利用しながら作成していけばよい。
たとえば、上記で紹介したITコーディネータの見本などはかなりのボリュームがあり、敷居が高いと感じるかもしれないが、
はじめから完璧なRFPでなくてもOK
ということを伝えておこう。システム開発に慣れた大企業の人でも、まったく漏れのない完璧なRFPを作ることは非常に難しい。中小企業のシステム開発の発注経験がない担当者ならなおさらのことだ。
また、RFPはあくまで質の高い提案をもらうためのものであり、良い提案をもらい、発注先が決まればその役目を終え、開発の詳細な設計資料の作成へと移っていく。最終的にRFPの目的（良い提案をもらうこと）が果たされれば、必ずしも完璧なRFPを完成させる必要もないのだ。
だからといって手を抜いていいわけではなく、発注企業の担当者は、できる限り正確な情報を伝えるため、良いRFPを作成する努力は行わなければいけない。しかし、それでも足らなかったり、抜けてしまったりする部分を補ってくれる開発会社が、その企業にとってベストパートナーになると筆者は考える。それらの見極めは、第4回で説明する「オリエンテーション」や提案の内容などをふまえながら、判断していけばよいだろう。
宇野 健人（うの けんと）
株式会社ユーザラス代表取締役社長（「発注ナビ」編集長）
アクセンチュアやトランスコスモスなどで、業務システムのコンサルティングや消費者向けWebサービスの立ち上げなどに10年以上携わる。システム開発の受託側と発注側、その両方に関わった経験を活かし、新規事業の創出を行う株式会社エムアウトのグループ会社である株式会社ユーザラスの代表取締役社長として、企業の発注担当者とWeb制作会社やシステム開発会社などのIT企業をつなぐ会社検索サイト「発注ナビ」を立ち上げる。
自ら「発注ナビ」の編集長として、自社のニーズや事情に合った開発会社を探したい発注担当者のために、最適な会社選びを日々手助けしている。
企業の発注担当者と、Web制作会社やシステム開発会社などのIT企業をつなぐ会社検索サイト。各社の得意分野や予算規模に加え、実名の開発実績や顧客のクチコミ、社員紹介など、開発会社の“生の情報”を掲載。
- 内容カテゴリ：サイト企画／制作／デザイン
- コーナー：中小企業のための失敗しないWebシステム発注・開発
※このコンテンツはWebサイト「Web担当者Forum - 企業ホームページとネットマーケティングの実践情報サイト - SEO/SEM アクセス解析 CMS ユーザビリティなど」で公開されている記事のフィードに含まれているものです。
オリジナル記事：サンプルでわかる提案依頼書（RFP）作成6つのポイント、発注内容の伝言ゲームは失敗の第一歩／第3回 [中小企業のための失敗しないWebシステム発注・開発] | Web担当者Forum
Copyright (C) IMPRESS BUSINESS MEDIA CORPORATION, an Impress Group company. All rights reserved.