RFPの書き方｜要件を200行書いて、半年で使えなくなった話

RFPの書き方の話をする前に、そのRFPで何を発注しようとしているのかから始めます。ここを飛ばすと、あとの話が抽象論になるからです。

題材は、勤怠管理のシステムの入れ替えです。

なぜ入れ替えるのかというと、いまの状態がこうだからです。

→ 打刻は紙のタイムカード
→ 集計は総務が毎月Excelで手作業
→ 残業の上限管理も手作業で、月末に3人が3日がかりで確認
→ 対象は850名

そろそろ限界だ、と誰もが思っている。 ここまでは、どこの会社にもある話です。

では、なぜRFPを書くのかというと、発注先が決まっていないからです。

1社に決め打ちで頼めるなら、要らないものです。複数の会社に声をかけて、同じ条件で提案を出してもらい、横に並べて比べたい。 そのために条件をそろえる文書が要る。それがRFPです。

RFP（提案依頼書／Request For Proposal）とは、発注側が実現したいことと条件を整理して、複数のベンダーに提案を求めるための文書です。背景、目的、要件、予算、スケジュール、評価基準を並べます。

似た言葉にRFI（情報提供依頼書）があります。こちらは「そもそも何ができるのか教えてほしい」という段階で、まだ提案は求めません。RFPは、その次の段階です。 「これを実現する方法と金額を出してほしい」まで踏み込みます。

そして、書き方の型はほぼ確立しています。調達の基本動作なので、テンプレートも解説もいくらでも出てきます。

前置きはさておき、本題に入ります。

今日は、そのRFPを教科書どおりに書いて、提案を集めて、そこで何に詰まったかという話をしていこうと思います。

① 教科書どおりに、RFPを書く

書き方を調べると、出てくる助言はほぼ共通です。

→ 要件を漏れなく、具体的に書く（曖昧なRFPは曖昧な提案しか呼ばない）
→ 評価基準を先に決めて、配点を明示する
→ 予算とスケジュールを開示する（隠すと見積もりが膨らむ）

そのとおりに書きました。勤怠システムなので、機能はかなり具体的に書けます。

“`
・打刻方法：ICカード、スマートフォン、PC（3種）
・シフト管理：日勤／夜勤／変則の3パターンに対応
・残業上限のアラート：36協定の上限に対し、80%到達時に本人と上長へ通知
・既存の給与システムへの連携：月次でCSV連携
・対象人数：850名
・想定予算：〇〇万円
・稼働希望：来年4月
“`

機能を洗い出していくと、要件の行数は200行を超えました。 行が増えるほど、仕事をした感覚があります。

そして、これは正しく機能しました。 5社から提案が返ってきて、全社が要件の一覧に沿って回答してくれた。比較表が作れる状態になっています。

ここまでは、教科書どおりです。

② 提案を並べて、比べられないことに気づく

5社の提案を並べて、評価を始めます。

総額は、きれいに割れました。 高い順に並べて、体制の人数を見て、実績数を見る。それでも、どれを選べばいいのか決まりません。

決まらない理由を考えていて、あることに気づきました。5社とも、要件の一覧に「対応可」と書いているのです。

→ 打刻3種 — 全社が対応可
→ シフト3パターン — 全社が対応可
→ 残業アラート — 全社が対応可
→ 給与連携 — 全社が対応可

200行の要件は、200個の「対応可」を集めただけでした。

当たり前です。勤怠管理は成熟した領域なので、どこも作れます。 要件で差がつくのは、その要件を満たせない会社が混ざっているときだけです。

このとき残る比較軸は、総額と体制の人数と実績数だけになります。そして、その3つはどれも「作れるか」を測る指標です。全社が作れる領域で、作れるかを測っている。

200行が、比較の役に立っていませんでした。

③ 半年後、書いた要件が使えなくなる

もう1つの詰まりは、契約後に来ました。

RFPには「打刻の記録から、残業時間を集計して通知する」と書いてあります。当然の要件です。ところが進めているうちに、打刻の記録以外から取れる情報が増えていることが分かってきました。

具体的には、こういう話です。会議の予定、入退室の記録、業務システムの操作ログ。 これらを突き合わせると、打刻だけより正確に実労働時間が出る。しかも、それを組み合わせて判定する仕組みは、この半年で急に安くなっていました。

ここで、RFPに書いた要件が足かせになります。

→ 要件には「打刻の記録から集計する」と書いてある
→ 契約書には、そのRFPが添付されている
→ 別のやり方に変えるには、契約変更の手続きが要る
→ 手続きを始めると、技術の議論の前に契約の議論が始まる

そして、契約変更には時間がかかります。判断が2週間遅れるたびに、選べたはずの選択肢が1つずつ消えていきました。

これは勤怠システムに限った話ではありません。AIが絡む領域では、この劣化がもっと速く起きます。

たとえば、ある問い合わせ処理の仕組みでは、前段に小さな分類器を1枚置くだけで外部APIの呼び出しが8割以上減るという結果が出ています。もしRFPに「〇〇のAPIを利用して実装すること」と書いてあったら、この構成は提案されません。 契約に書いてあることを変える提案は、提案する側が自分の首を絞めるからです。

要件が、コスト削減の芽を潰します。

④ 2つの詰まりは、同じ前提から来ている

比較できない問題と、半年で使えなくなる問題。別々に見えますが、原因は1つでした。

RFPという道具は、「今日の正解は、契約期間中も正解であり続ける」という前提の上に立っています。

→ 前提が保たれるなら、手段を書いて比較するのは合理的
→ 前提が崩れると、手段の記述が、そのまま足かせに変わる
→ そして、手段が横並びになる成熟領域では、そもそも比較の役に立たない

つまり、手段を書くことが、両方の詰まりを同時に生んでいたわけです。

⑤ 直してみる — 固定するものと、空欄にするもの

RFPを書くのをやめる、という話ではありません。書く場所を変えます。

判断の基準は1つです。「これは半年後も同じか」と自分に聞く。

→ 同じなら、精密に書く価値があります
→ 変わるなら、書くほど足かせになります

この基準で仕分けると、こうなりました。

固定するもの（3つ）

1. 達成したい業務上の状態。
「打刻の記録から残業時間を集計して通知する」ではなく、「月末に3人がかりで3日かけている確認作業を、1人が半日で終えられる状態にする」。 手段ではなく、状態で書きます。

2. その達成をどう判定するか。
誰が、いつ、何の数字を見て、成功と言うのか。「確認作業の所要時間を、稼働3ヶ月後に総務部長が計測し、1人日以下であること」。 ここを空欄にしたまま進むと、検収の日に全員が違う定義を持ち寄ることになります。

3. 触ってはいけない制約。
給与システムとの連携が必須である。個人の位置情報は取得できない。監査でログの提示を求められる。これは時間が経っても変わらないので、精密に書く価値があります。

空欄にするもの（3つ）

1. 使用する技術・製品・API。 契約期間中に最適が入れ替わります。指定した瞬間、入れ替えが契約変更になります。

2. 機能一覧と画面数。 全社が「対応可」と答える領域では、比較の役に立ちません。

3. 総額の内訳としての工数。 工数はもうコストと比例していません。工数で縛ると、速く作る方法を選ぶ動機が消えます。

そして、必ず書く1項目

前提が変わったときの、変更手続き。

→ 誰が変更を提案できるか
→ 誰が判断するか
→ 何日以内に決めるか
→ 金額はどう調整するか

これを書いてあるRFPを、私はほとんど見たことがありません。 そして、変更が前提の開発でいちばん高くつくのは、この手続きが無いことです。

⑥ あとで知った — この形は、すでに制度になっていた

素朴な整理のつもりでしたが、調べてみると同じ考え方が、すでに公的な調達制度として運用されていました。

1つ目。 米国の連邦調達では、業務仕様書（SOW／Statement of Work）から、成果仕様書（PWS／Performance Work Statement）へ移行するよう指示が出ています。 そしてPWSの定義が、まさにこれです。

「どうやるか（how）ではなく、どういう結果を出すか（what result）を、一般的な用語で述べる」。

僕が「手段ではなく状態で書く」と整理したものは、すでに名前が付いて、制度として要求されている書き方でした。

2つ目。モジュラー調達（modular contracting）。 大規模なカスタム開発の調達を、小さな契約の集まりに分割するやり方です。1本の巨大な契約にせず、動くソフトウェアを早く利用者に届けることを優先する。

変更が起きることを、契約の単位そのもので吸収しているわけです。僕がやろうとした「変更手続きを書く」より、もう一段先を行っています。

3つ目が、いちばん効きました。 アジャイル向けの契約形式を使えば、調達文書は十数ページで足り、半日で書ける、という運用が実際に行われています。

200行のExcelは、要らなかったということです。

分量が必要になるのは、手段まで指定しようとするからでした。達成すべき状態と、判定方法と、変更手続きに絞れば、短くなるのが自然です。

ただし正直に書いておくと、これらは政府調達の文脈で整備されたもので、民間企業がそのまま使えるわけではありません。モジュラー調達には前提条件があって、発注側にプロダクト思考と、疎結合な設計と、継続的に届ける体制があることが要ると明記されています。分割すれば良いという話ではない。

それでも、方向は同じでした。新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか

要件を200行から、状態と判定と制約に書き換えて、もう一度提案を集めました。

総額は、比較できなくなりました。 各社が違う手段を提案してくるので、金額の前提が揃わないからです。

代わりに、提案の中身が割れました。

質問を1つ足したのが効いています。「この前提が崩れたら、どこを直すことになりますか。その作業は何日で、誰が判断しますか」。

回答は、きれいに3種類に分かれました。

→ 「柔軟に対応します」 — 手順を持っていません。柔軟という言葉は、手順が無い人が使います
→ 「変更管理プロセスに則って対応します」 — プロセスはありますが、踏んだかは分かりません。踏んだ人は手順ではなく事故の話をします
→ 「前回はここが変わって、検知にこれだけかかって、直すのに何日でした」 — これです

3つ目を答えられる相手は、変更が起きることを織り込んで見積もっています。 だから総額は高く見えることがあります。それでも、1回目の変更で追加見積もりが出てくる相手と比べて、最終的にどちらが安いかは分かりません。

ひとつ、実際に効く指標があります。修正の見積もりが返ってくるまでの時間です。

ある現場では、不具合の修正見積もりが2分で「火曜日まで」から「1時間後」に書き換わりました。 最初は慎重な数字でしたが、実際に中を見たら1時間で済むと分かった。この「見てから直す」の速さが、そのまま変更への強さです。

見積もりが常に長めに返ってくる相手は、慎重なのではなく、中を見ずに答えている可能性があります。

⑧ 現場で使うなら、この目次

そのまま使える形に落とします。この順で書いてください。

#	項目	書く内容	分量の目安
1	背景	いま何に困っているか。数字で	1ページ
2	達成したい状態	手段ではなく状態。「〇〇が△△になっている」	1ページ
3	判定方法	誰が・いつ・何の数字を見て成功と言うか	半ページ
4	制約	連携必須・取得禁止・監査要件。変わらないものだけ	1ページ
5	予算とスケジュール	開示する	半ページ
6	変更手続き	誰が提案し、誰が何日で判断し、金額をどう調整するか	1ページ
7	提案してほしいこと	手段は自由。下の3問への回答を必須にする	半ページ
8	評価基準と配点	「作れるか」ではなく「直せるか」に配点を寄せる	半ページ

合計6〜7ページ。 200行の機能一覧は入りません。

提案書に必ず書かせる3問

→ 1. この前提が崩れたら、どこを直すことになりますか
→ 2. その作業は何日で、誰が判断しますか
→ 3. 直したあと、壊れていないことをどう確認しますか

3問とも、過去の実例で答えてもらってください。 「〜します」ではなく「前回は〜でした」で書けるかどうかが、そのまま経験の有無になります。

評価の配点（例）

観点	従来	変更後
実績数・体制	40点	15点
保有技術・製品	20点	5点
総額	30点	20点
変更対応（3問の回答）	0点	40点
運用・保守	10点	20点

「作れるか」に60点を配っていたのを、20点まで落とします。 全社が作れる領域で作れるかを測っても、点差が出ないからです。

⑨ この書き方が効き続ける理由

最後に、なぜこの形を推すのかを書きます。

達成したい状態は、技術が変わっても変わらないからです。

→ 「月末の確認作業を1人日以下にする」は、5年後も同じ日本語で通じます
→ 「打刻の記録から集計する」は、半年で古くなりました
→ 手段を書いた条項は、書いた瞬間から劣化が始まります

そして、状態で書かれた要件は、より良い手段を提案する余地を残します。 分類器を1枚挟めば8割安くなる、という提案は、手段が空欄でなければ出てきません。

RFPは、工業製品の調達から来た道具です。仕様を決め、相見積もりを取り、いちばん安いところに発注する。同じものが同じ品質で作られる前提があるから、この方法は合理的でした。

ソフトウェアは元々そこから外れていましたが、それでも「仕様を固めれば同じものが出来る」という建前で運用されてきました。AIは、その建前を維持できないところまで来ています。

この環境で発注側が持つべき能力は、「正しく選ぶ力」から「変わったときに直す力」へ移ります。 RFPも同じです。最初に正解を書き切ろうとするのをやめて、正解が変わったときの決め方を書く。

---

なお、あの200行のExcelは、いま思えば誰のためでもありませんでした。強いて言えば、書いた人が「詰めた」と言えるようになるためです。

安心を買うのに200行はちょっと高いな、と思います。半日で十数ページ、という運用があると知ってからは、なおさらです。

以上です。