ソフトウェアの提案依頼書、いわゆるRFPは、本来、複数の発注先候補を横並びで比較できるようにするための文書です。ところが実際に出回っているものの多くは、その逆の結果を生んでいます。解決策を細かく指定しすぎて回答の幅を縛る一方で、金額を出すために誰もが必要とする情報のほうは抜け落ちているからです。結果として、桁が一つ違うほど開いた五つの見積もりが並び、どれも形式上は要求に答えているのに、同じものを測っている見積もりは一つもない、という状態になります。

よくある説明は、ベンダーが言葉を濁しているというものです。それが当たっている場合もたしかにあります。しかし圧倒的に多いのは、その文書に書かれている内容からは導きようのない数字を求めてしまい、各社がその空白をそれぞれ別の前提で埋めた、という筋書きです。前提が違えば金額が違うのは当然で、そこに誠実さの問題は関係ありません。

あなたのRFPが機能するかどうかを見分ける試験: 二社の異なるベンダーがそれを読んで、実質的に同じ範囲にたどり着けるでしょうか。もし文書に「ユーザー管理」とだけ書かれていて、ロールがいくつあるのか、権限がレコード単位で変わるのか、既存のディレクトリと連携する必要があるのかが示されていなければ、一社は一週間と見積もり、もう一社は二か月と見積もります。どちらも正直に答えています。そして、あなたはその二つを比較できません。

機能一覧が出発点として間違っている理由

機能の一覧は、あなたが何を決めたかをベンダーに伝えるだけで、あなたが何を必要としているかは伝えません。これが問題になるのは、その決定自体が間違っている可能性があるからです。そして、間違いに気づいた相手には、あなたが押しつけた文書構造の中でそれを指摘する場所が用意されていません。

さらに悪いことに、機能一覧はコストを動かす情報を覆い隠します。ソフトウェア開発の工数は、地味で面倒な部分に集まります。外部システムにいくつ接続するのか、既存データをどれだけ移行する必要があり、その中身がどれくらい整っているのか、権限の異なる利用者の種類がいくつあるのか、そして遵守すべき規制上の義務は何か。機能一覧はいくらでも長くできますが、その長さの中にこれらが一つも含まれていない、ということが平気で起こります。

代わりに求められているのは曖昧さではありません。課題を正確に記述し、本当に動かせない制約だけを明示したうえで、進め方の説明は提案する側に委ねてください。そうすれば返ってくる答えはばらつきますが、そのばらつきは雑音ではなく判断材料になります。どこで各社の意見が割れたかが、そのまま検討すべき論点の一覧になるからです。

ソフトウェアRFPに本当に書くべきこと

事業上の課題と、成功の定義。 いま何が起きていて、代わりに何が起きるべきで、うまくいったことをどう判断するのか。ベンダーはここを手がかりにして範囲そのものへ異議を唱えます。この段階で相手にしてもらえる仕事のうち、それがもっとも価値の高いものです。

規模と数量を、数字で。 利用者数、取引件数、レコード件数、想定している伸び。これを書くだけで、見積もりのばらつきの大きな部分が消えます。

接続が必要なシステムを、固有名で。そして、それぞれに文書化されたAPIがあるかどうかを一言添えてください。文書のない古いシステムとの連携が一本あるだけで、ほかのすべてを合わせた費用を上回ることがあります。

すでに手元にあるデータ。 どれくらいの量で、どこにあり、どんな状態か。移行はどのプロジェクトでも決まって、もっとも過小評価される項目です。

本当に動かせない制約。 規制上の義務、指定されたホスティング先、既存のID基盤、動かせない期日。どれが絶対条件で、どれが希望にすぎないのかを書き分けてください。絶対条件はベンダー側が防御的に見積もる対象になるからです。

依頼しないこと。 対象外を明示的に書き出すのは、見積もりのばらつきを縮める方法の中で、もっとも安上がりな部類に入ります。

予算のレンジ。 伏せても価格は下がりません。誰も知らない予算に合わせて範囲を切った提案が集まり、そのあとで作り直すことになるだけです。レンジを示せば、その中で何が実現できるのかをベンダーの側から言ってもらえます。金額帯ごとに何が買えるかは、カスタムソフトウェア開発の費用ガイドにまとめています。

ベンダーの差が出る質問

質問は数を減らし、質を上げてください。次の問いは、百行の要件チェック表よりも多くを明らかにします。

最初に何を作りますか、そしてそれはなぜですか。 着手の順序には、相手が課題を理解したのか、それとも文書を理解しただけなのかが表れます。

この案件でもっとも危ういのはどこで、それをどう小さくしますか。 実在するリスクを名指しできるベンダーは、リスクはありませんと答えるベンダーより信用できます。

具体的に誰が担当しますか。 氏名、経験の度合い、そして稼働の何割か。提案書を書いた人間が実装に関わらない、というのは何度も繰り返されてきた失望です。

範囲が変わったらどうなりますか。 範囲は必ず変わります。その答えからは、圧力がかかったときにその関係がどう動くかがわかります。これは人日単価よりも重要です。

こちらに何を求めますか。 プロジェクトは、ベンダーの能力不足と少なくとも同じ頻度で、発注側の要員が確保できないことによって失敗します。そう言えるベンダーは、売り込みではなく現実を説明しています。

最終的に何がこちらのものになりますか。 ソースコード、インフラ、各種アカウント、データ。これは選定のあとではなく、選定の前に書面で確認してください。

回答の読み方

もっとも安い見積もりは、たいていの場合、効率が良いことの表れではなく、範囲をもっとも狭く解釈した結果です。そして解釈の差は、作業が始まってから変更依頼という形で表に出てきます。

各社がどこに紙幅を割いたかを見てください。連携とデータ移行に多くを費やしている提案は、難所がどこにあるかを理解しています。方法論と組織図とチーム写真に費やしている提案は、課題そのものに向き合っていません。

頼んでいない反論は良い兆候として扱ってください。範囲の一部は不要だと言うベンダー、あるいは、あなたが挙げた制約は得られる価値に見合わない費用を招くと指摘するベンダーは、まさにあなたが本当にやってほしい仕事をしています。何にでも同意するベンダーは、読むのは楽ですが、一緒に仕事をすると苦労します。

そして、すべての見積もりが同じ問いに答えているかを確かめてください。二社の金額が三倍違うなら、どちらかが文書に書かれていない何かを前提に置いています。その前提を突き止めるほうが、どんな採点表よりも役に立ちます。

RFPを出すべきでない場合

仕事の規模が小さいとき、探索的な性質が強いとき、あるいは自分たちが何を必要としているかまだ分かっていないとき、RFPは道具として間違っています。双方に数週間を使わせたうえで、精度が高いという誤った印象だけを残します。

そうした場合は、有償の要件定義、いわゆるディスカバリーを先に行うほうが良い結果になります。短い期間で、そのあと市場へ持ち出せる仕様書を作る。あるいは、そもそも作る価値がないと結論づける。どちらの結果でも、誰も定義できていない範囲をめぐって競争させるよりましです。範囲の絞り方については、MVPソフトウェア開発のガイドの考え方がそのまま使えます。

Mecanikはソフトウェア開発の仕事の一環として、RFPに回答する側にも回り、発注する組織がRFPを書くのを手伝ってもいます。良い見積もりを引き出す文書は、例外なく短いほうの文書で、その中に実際の数字が入っています。

よくある質問

ソフトウェアRFPには何を書けばよいですか？ 事業上の課題と成功の定義、実際の数字を伴う規模と数量、連携先システムの固有名と、それぞれに文書化されたAPIがあるかどうか、移行対象データの状態、本当に動かせない制約はどれか、何が明確に対象外か、そして予算のレンジです。

RFPに予算を書くべきですか？ 書くべきです。伏せても価格は下がらず、誰も知らない予算に合わせて範囲を切った提案が集まり、そのあとで作り直すことになります。レンジを明示すれば、その中で現実的に何ができるかをベンダーが答えられるようになり、回答同士を比較できるようになります。

同じソフトウェアなのに見積もりが大きく違うのはなぜですか？ たいていは文書に空白があり、各社がそれを別々の前提で埋めたからです。「ユーザー管理」という一行だけで、ロール数もレコード単位の権限もディレクトリ連携も示されていなければ、一週間とも二か月とも正直に見積もれます。ばらつきはベンダーの性質ではなくRFPの性質です。

良いソフトウェアベンダーを見抜く質問は何ですか？ 最初に何を作りどうしてそうするのか、もっとも危ういのはどこでどう小さくするのか、具体的に誰が稼働の何割で担当するのか、範囲の変更をどう扱うのか、こちらに何を求めるのか、そして最終的に何が自社のものになるのか、です。

RFPを使わないほうがよいのはどんなときですか？ 仕事が小さいとき、探索的なとき、必要なものをまだ定義できないときです。定義されていない範囲で競争させれば双方が数週間を失い、精度の錯覚だけが残ります。仕様書を生むか、あるいは作る価値がないと結論づける有償のディスカバリーのほうが、道具として適しています。