ソフトウェア開発ベンダー向けRFPチェックリスト

ソフトウェア開発のRFPには、解くべき課題、機能要件と非機能要件、セキュリティとデータ要件、契約条件、採点方法を先に明記します。加点方式の基準で比較し、事例紹介ではなく実績を確認し、予算を拘束する契約の前に有償の小規模パイロットを実施します。

ソフトウェア開発のRFPに書くべき内容

この文書は、回答を互いに比較できる状態にするためにあります。ベンダーは書かれた内容にしか答えられません。構想と金額だけを求めるRFPは、どれも聞こえのよい提案を集めてしまい、相互に評価できません。機能面の内容、制約、採点ルールは、最初の回答が届く前に固めておきます。さもなければ、評価は基準を巡る交渉になります。

さらに数か月を省ける手順上の論点があります。RFPは、自社に何が必要かを発見する場ではありません。要件は内部の作業から生まれます。実際の業務の流れをプロセス責任者が説明し、経理部門が照合すべき項目を示し、毎日システムを使う担当者が、今の一番困っている箇所を語ります。この作業は遅く、組織内の利害を伴い、ベンダーが関わる前に終わらせておくべきものです。最初に現れたベンダーに丸投げすると、そのベンダーの製品の言葉で要件が書かれてしまい、他の提案がすべて不適合に見えます。提案の質が低いからではなく、一人の入札者を基準に物差しを作ってしまうからです。

よく混同される3つの文書を区別しておく価値もあります。RFIは市場に「何があるか」を尋ねる文書で、短く、要件より前段のもので、誰も拘束しません。RFPは、定義した要件と明示した評価方法に基づく提案を求めます。RFQは、定義した範囲に対して価格を求めます。範囲ができ上がる前にRFQを回すと、意味の違う3つの数字を並べて比べることになります。

完成したRFPだけが備える5つの点は次のとおりです。

• 課題を定義し、解決策は書かない。「月次の連結レポート作成を、数日から指定した時間数まで短縮する」は課題の記述です。「データウェアハウスを作ってほしい」は、問題を解決しないかもしれない解決策の当て書きにすぎません。


• 要件と好みを切り分ける。 合否を決める必須要件、順位を決める望ましい要件、何も決めない任意の要件。この区別が見えて初めて、ベンダーは真剣に応答します。


• 制約を名指しする。 連携が必要な既存システム、移行が必要なデータ、監査と保存の義務、稼働開始の時期、承認者。


• 評価方法を先に示す。 加重基準、誰が評価するか、必要な証拠、落選したベンダーへスコアの要約をいつ伝えるか。


• 工程の日程を置く。 質問の締切、質疑応答の期間、提出締切、評価期間、決定日。日程のないプロセスには、もともと忙しいベンダーだけが寄ってきます。

RFPの構成

機能要件と非機能要件

機能要件は、システムが何をするかを記述します。どのプロセスを、どの役割のために、どの出力で。非機能要件は、それをどれだけうまくこなすかを記述します。欠落しやすいのは後者で、後から高い代償を払って強制されるか、まったく守られないことになります。

ほとんどのB2B案件で明記しておく価値があるのは次の6点です。

• 性能。 受注明細の登録、レポート生成、月次締めなど、重要な業務について、指定負荷下での応答時間。


• 可用性。 事業に必要な稼働率、保守の時間帯、停止時にどうなるか。許容できる停止時間の記述のない目標は、要件になりません。


• 復旧。 RTOとRPOを平易な言葉で定義します。事故後に業務をどれだけ早く再開できるか、どれだけの作業を失ってよいか。この2つの数字は契約書だけでなく、評価の段階で扱います。


• 監査証跡。 誰がいつ何を変更したか、どれだけ保存するか、誰が取得できるか。お金、在庫、個人データが動く処理では特に欠かせません。


• アクセシビリティと操作性。 誰が、どの端末で、どの言語で使うか。倉庫の担当者が操作できないシステムは、どれだけ高得点でも導入したことになりません。


• 連携とデータ。 どのシステムとつなぐか、データはどちら向きに流れるか、各マスタ記録を誰が保持するか。

セキュリティとコンプライアンスの確認事項

セキュリティは、はい/いいえの一文ではなく、証拠を添える質問として尋ねるほうが確実です。盛り込む価値があるのは次のとおりです。

• ISO/IEC 27001 — 保有しているか、認証の範囲はどこまでをカバーしているか。営業組織は範囲内でも開発チームが範囲外の証明書は、逆に具体的な事実を伝えます。


• セキュア開発 — 設計、コードレビュー、テストのどこにセキュリティを組み込むか。依存ライブラリや脆弱性の扱いが、日常の工程として定着しているか。


• OWASP Top 10 — Webに公開する部分のレビューに組み込まれているか。答えられる形の具体的な質問です。


• アクセス制御 — 自社の環境とデータに誰が入れるか、付与と失効の手続き、どのようなログがあるか。


• データ保護の義務 — 該当すればKVKKとGDPR。誰がコントローラーで誰がプロセッサーか。データ処理契約はサブプロセッサーと侵害通知について何と言うか。

商業条件とSLA

価格は、比較できる形で求めます。何が含まれ、何が別途請求され、変更がどう見積もられるか。裏づけの範囲を伴わない単一の数字は、別の単一の数字と比較できません。コストと価格モデルのページでは、一般的な構造と、それぞれが抱える疑問を解説しています。

SLAにも、要件と同じ精度が求められます。稼働率のパーセントは、測定方法、除外事項、救済措置とセットで初めて意味を持ちます。応答時間は、深刻度の定義と営業時間の定義があって初めて意味を持ちます。定義のないパーセントの一覧を受け取るのではなく、各ベンダーにSLAの中の用語を定義させてください。

ソフトウェア開発ベンダーの評価スコアリングマトリクス

コピーして使えるテンプレートです。以下の重みは一例で、自社の優先順位に合わせて設定し、合計を100に保ちます。1、3、5の意味は、誰かが採点を始めた後ではなく、その前に定義してください。

この表を機能させる規律は2つあります。まず、議論する前に各自で採点すること。最初の自信満々の声が部屋の空気を決めてしまいます。次に、点数ごとに一行の根拠を残すこと。理由付きのスコア要約を受け取ったベンダーは、結果を素直に受け入れますし、自社チームも半年後にその妥当性を説明できます。

3つ目の規律は、誰が採点するかです。評価パネルには、結果と日々向き合う人——プロセス責任者、データの担当者、セキュリティや経理の担当者——を含めるべきです。調達部門だけでは不十分です。評価は、判断できること（提案書の構成、営業チームの磨き上げ）を採点し、判断できないこと（連携手法が今のシステムに本当に合うか）を先送りするうちに静かに失敗します。「今の運用では動きません」と言える技術者が一人いるだけで、どんな割引より多くのコストを防げます。

重み自体にも注意が要ります。重みは優先順位の宣言であり、ベンダーにも見えます。セキュリティに5%、価格に30%と付ければ、真剣にセキュリティを考えるベンダーは気づきますし、契約を結んだ自社チームも同じように気づきます。表を埋めるためだけに慌てて設定した重みは、部屋の外の全員にとっての真実として読まれます。一度、意思決定者が同席して決め、変える場合も同じ手順を踏んで変えてください。

リファレンスチェックとパイロット

事例紹介はマーケティングで、リファレンスチェックは証拠です。有効な通話は短く、提供物ではなく出来事を尋ねます。プロジェクトは完遂したか、範囲はどこで変わったか、実際のチームは誰だったか、何を違えて行うか、同じベンダーでもう一度始めるか。過去形で具体的な答えが返ることがサインです。

依頼するのは、規模と複雑さが自社に近い案件のリファレンスで、ベンダーが最も誇る仕事ではありません。予算の2倍かかる看板導入からは、自社と同じ規模でのチームの動きはほとんど学べません。そして、確認は自分で行ってください。ベンダーが事前に話を通した連絡先は、推薦文であってリファレンスではありません。聞く内容をその場で知らされる顧客との通話こそが役に立ちます。

その次に、短い有償パイロットで、リファレンスでは測れない部分——要件が揃っていない状態でこのチームが自社のメンバーとどう働くか——を試します。設計の原則は、あらゆるパイロットに共通です。実際の業務を使う、受け入れ基準を文書で置く、途中で一度だけ変更を入れる、判断基準を先に合意する。アウトソーシングのページで、パイロット設計をもう少し詳しく扱っています。

確認する契約条項

• 知的財産の譲渡 — コード、文書、派生物に対する権利が、最終支払時ではなく、創作物が発生した時点から自社へ移ること。
• データの所有権 — データは自社のものであり、ベンダーの権利は提供に必要な範囲に限られること。
• 検収 — 検収の意味するところ、宣言する者、不合格となった場合の手続き。
• 変更管理 — 範囲変更の申入れ、価格算定、承認の方法。これがなければ、すべての変更が紛争になります。
• 終了と引継ぎ — 終了時のソースコード、アクセス、文書、支援。ベンダーが替わった場合の知識の移転。
• エスクロー — 事業継続がベンダー保有の構成要素に依存する場合に、ベンダーが事業を続けられなくなったときの扱い。
• 責任制限 — 責任の上限、除外事項、保険の外にあるもの。価格と同じ注意で読んでください。
• 解除 — 解除の予告期間、解除後の義務、データの返還または削除の手続き。

よくある質問

RFIとRFP、どちらを先に送るべきですか

市場や課題が見えないときはRFIです。何があり、いくらかかるかを尋ねます。要件と評価方法が定まっているときはRFPです。早くに送っても、要件を作り込む作業が各ベンダーの提案書の中へ移るだけで、彼らの言葉と彼らの優先順位の中で進みます。

ベンダーは何社に依頼すべきですか

すべての提案書を熟読し、すべてのリファレンスに電話できるくらいの少人数です。数社を超えると、多くの評価は質を落とします。RFI、一次選別の通話、類似案件ひとつのリファレンスから作った短い候補リストのほうが、有名な名前の長いリストより役に立ちます。

重み付けはどう決めますか

提案書を見る前、自社の優先順位から決め、結果と向き合う者同士で合意します。よくある失敗は、すべてに同じ重みを付けることです。どれも他のどれも同じに重要だと言っているのと同じになります。価格やリスクが支配的なら、重みがそれを語るべきです。

価格は評価対象にすべきですか

するべきです。ただし、範囲を固定した加重基準のひとつとしてで、評価の全体ではありません。裏づけの範囲を伴わない価格を採点すると、もっとも少ない作業を前提としたベンダーが得をします。まず要件に価格を付け、同じもの同士の合計を比べてください。

セキュリティの回答はどのように採点しますか

口調ではなく証拠で採点します。3段階が使えます。立場の表明がない（1）、方針の説明がある（3）、認証範囲の検証に加えてセキュア開発の説明と証拠の提出がある（5）です。証明書を持たないベンダーには、同等の統制が文書で何があるかを尋ねてください。統制が文書化された正直な「ない」は、検証できない「ある」より高得点になります。

RFP提出後にもソフトウェア開発の要件は変更できますか

提出前であればできます。変更は全員に周知します。提出後は、すべての応募者が受け取る正式な質疑応答を通じてのみ可能です。あるベンダーだけに黙って要件を変えると、このプロセス全体の土台だった比較可能性は終わります。契約の後は、変更管理がそのためにあります。

出典と規格

• ISO — ISO/IEC 27001（情報セキュリティマネジメント）の発行機関。依拠する前に、最新版と証明書の範囲を確認してください。
• OWASP — 本ページで参照したTop 10 Webアプリケーションセキュリティリスクのチェックリストの発行元。
• スコアリングマトリクスの考え方は、公開されているRFPテンプレートの実務に沿ったものです。表示している重みは編集用の一例であり、推奨値ではありません。本ページは調達上のガイダンスであり、法的助言ではありません。WorldwideTradeXは、認証や監査を提供しているとは主張していません。

関連ページ

ソフトウェア開発 · トルコ発ITアウトソーシング · コストと価格モデル · IT監査とコンサルティング · 見積もりを依頼する