システム開発を外注しようと調べ始めると、早い段階で「RFP」という言葉に出会う。提案依頼書のことで、発注する側が作りたいものを伝え、開発会社に提案と見積もりを頼むための文書だ。
検索するとテンプレートがいくつも見つかる。開いてみると、現行システムの構成、非機能要件、セキュリティ要件、運用保守体制、提案書の評価基準と、項目が数十個並んでいる。社員数十人の中小企業で、情報システム担当もいない状態でこれを埋めようとすると、手が止まるのは当然だと思う。
あのテンプレートの多くは、複数社から正式な提案を集めて点数で比較する、大きな組織の調達を前提にしている。小さな会社が最初に書くなら、A4一枚で足りる。僕は依頼を受ける側にいて、その立場から見ても、一枚に要点が押さえてあれば十分に話を始められると思う。
RFPと要件定義書は別の文書
手が止まる理由のひとつに、RFPと要件定義書の混同がある。
RFPは、候補の会社に自分たちの状況と希望を伝えて、提案を求めるための文書だ。要件定義書は、システムで実現することや守るべき条件を、画面やデータの扱いまで具体的に書き残す文書で、多くの場合は開発会社と一緒に詰めていく。
目的が違うので、RFPの段階で機能を細かく決めきる必要はない。決めきれていない点はそう書いておけば、先方はそこも含めて提案を組み立ててくれる。要件を全部そろえないと見積もりは出ないと思い込むと、依頼書はいつまでも完成しない。
一枚に何を書くか
いま困っていること
僕は、作りたいシステムの名前より、いま何に困っているかを先に知りたい。在庫管理システムがほしいと一行で書かれるより、「在庫の数をExcelで管理していて、月末の棚卸しで毎回数が合わず、原因を調べるのに担当者が2日かかっている」と書いてあるほうが、何を作ればいいかずっと考えやすい。
同じ在庫管理でも、入力が面倒なのか、数が合わないのか、倉庫の外から在庫を見たいのかで作るものは別物になり、システムの名前だけではそこまで読み取れない。
使う人と使う場面
誰が、どこで、何の端末で使うのか。人数はおおよそでいい。
事務所のパソコンで経理担当が使うのと、倉庫で作業の合間にスマートフォンを触るのとでは、画面の作り方がまるで違う。現場の人が毎日使うものなら、その一言を入れておいてほしい。
やること・やらないこと
範囲に入れるものと入れないものを分けて書く。効くのは入れないものの方で、会計ソフトとの連携は今回不要、スマートフォンアプリにはしない、と書いてあるだけで見積もる側の迷いが減り、各社の金額の幅も狭まる。迷っているものは検討中としておけば、入れた場合と入れない場合で分けて見積もってくれる会社もある。
予算と時期
予算を書くと足元を見られる、と心配する人は多い。気持ちは分かるけれど、僕は書いたほうが得だと考えている。予算が分からないと、受ける側は数十万円の案と数千万円の案のどちらで組むか決められず、各社の見積もりが比べようのないほど散らばるからだ。
「300万円前後、上限400万円」くらいで十分。時期は、使い始めたい時点を書く。
まだ決まっていないこと
自分たちでも答えが出ていない点も書いておく。Excelの過去データを移すかどうか、承認の流れを部署ごとに変えるかどうか。迷っている点が分かれば、受ける側は選択肢ごとの手間や費用を示せる。データを移すか迷っているなら、移す場合と移さない場合で費用を分けて出してもらうと決めやすい。
僕はこの欄がある依頼書のほうが信用できると思う。
記入例
社員30人ほどの会社が、備品の貸し出し管理を外注する場面を想定した例だ。
| 項目 | 記入例 |
|---|---|
| 困っていること | ノートPCやプロジェクターの貸し出しを紙の台帳で管理している。誰が何を借りているか分からず、返却漏れが月に数件出る。探す手間で総務の時間が取られている |
| 使う人と場面 | 借りる側は全社員(約30人)。自分のスマートフォンかPCから予約と返却を記録する。総務担当2人が貸し出し状況を一覧で確認する |
| やること | 備品の登録、予約、貸し出しと返却の記録、返却予定日を過ぎたときの通知 |
| やらないこと | 備品の購入申請や経費精算との連携。社外からの利用 |
| 予算と時期 | 100万円前後を想定。来年4月から運用を始めたい |
| 決まっていないこと | 社員のログイン方法(今使っているGoogleアカウントを使えるか)。備品にバーコードを貼るかどうか |
項目はこれだけで、一枚に収まる。足りない部分は、相手に質問してもらえばいい。
書かなくていいもの
使う技術やプログラミング言語は、特別な事情がなければ指定しなくていい。発注者が技術を決めてしまうと、受ける側はその前提でしか見積もれず、もっと安く早く作れる方法があっても提案しにくくなる。
細かな機能一覧もいらないと僕は思う。困りごとから出てきた機能でなければ、使われない機能まで見積もりに入ってしまう。この点は仕様書と見積もりだけで進めた開発が失敗する構造的な理由でも触れた。
文章で伝わらない部分は画面で見せる
一枚の依頼書で伝わるのは、困りごとと条件まで。画面の使い勝手や入力の順番は、文章にするとどうしてもぼやける。開発会社が思い浮かべる画面と、自分たちが想像している画面は、たいてい違っている。
手書きの絵でも、似た既存サービスのスクリーンショットでもいいので、画面のイメージを一枚添えると話が早い。
渡した後は返ってくる質問を見る
依頼書を渡したら、金額より先に、相手が返してくる質問を見てほしい。
困りごとの背景を掘り下げてくる会社は、業務を理解しようとしている。やらないことの理由を確かめる質問が来たら、範囲の食い違いを先に潰そうとしている。質問がひとつもなく金額だけ届いたときは、その見積もりが何を前提にしているかを、こちらから聞いたほうがいい。そのとき、データ移行や保守の費用が含まれているかも一緒に確かめておきたい。
開発会社の選び方は開発会社の選び方で外さない5つの確認ポイントにまとめている。依頼書を書き上げたら、あわせて読んでみてほしい。
なのかデモに頼むという選択肢
依頼書を書いたら、その困りごとをなのかデモのリクエストフォームに書いてもらう手もある。試したいことと画面を書いてもらえれば、触れるデモを7日で、無料で作る。触ってみて、なのかデモで本開発に進むか見送るかを決めればいい。