この工程は何をするのか
IT パスポート試験シラバス Ver.6.5 の「24. 調達計画・実施」は、流れをこう定義している。
調達の基本的な流れは，情報提供依頼（RFI：Request For Information），提案依頼書（RFP：Request For Proposal）の作成と配付，選定基準の作成，ベンダー企業からの提案書及び見積書の入手，提案内容の比較評価，調達先の選定，契約締結，受入れ・検収であること
自分たちで作らない部分を、誰にいくらで頼むかを決める工程。 会計事務所や事務の立場でシステムに関わるとき、実際に手を動かすことになるのはここが多い。
4つの文書の関係
シラバスはそれぞれをこう定義している。
| 文書 | 誰が書くか | 何のためか |
|---|---|---|
| 情報提供依頼（RFI） | 発注側 | 提案依頼書を書く前に、手段や技術動向の情報を集める |
| 提案依頼書（RFP） | 発注側 | システムの概要・提案依頼事項・調達条件を示し、提案書の提出を依頼する |
| 提案書 | ベンダー | RFP を基に検討したシステム構成・開発手法を提案する |
| 見積書 | ベンダー | 開発・運用・保守にかかる費用を示す |
順番が大事で、RFI は RFP の前に来る。何が可能かを知らないまま RFP を書くと、実現できない条件や、逆に安く済む方法を潰す条件を書いてしまう。
具体的な成果物
| 成果物 | 中身 |
|---|---|
| 情報提供依頼（RFI） | システム化の目的と業務概要を示して、情報提供を依頼する文書 |
| 提案依頼書（RFP） | 導入システムの概要、提案依頼事項、調達条件 |
| 選定基準と比較評価の記録 | 何を基準に、どう比べて選んだか |
つまずきやすいところ
選定基準を提案書を見てから作ると、選定になっていない。 シラバスの流れでも選定基準の作成は提案書の入手より前に置かれている。後から基準を作ると、選びたい相手に合う基準を作ってしまう。
見積書は開発費だけではない。 シラバスは「システムの開発，運用，保守などにかかる費用」と書いている。運用と保守が抜けた見積りを比べると、安く見えた方が結局高くつく。
AI に任せられる範囲
現時点では、この図書館に根拠となる記述がない。
RFP の下書きやベンダー提案の比較は AI が得意そうに見えるが、この図書館が扱う3つのツールの仕様に、その用途を述べた記述が無い。裏付けの無い工程で「AI に任せられる」とは書かない規則にしている（docs/schema.md）。ここを埋めるには、調達文書の作成を扱った出典を新たに sources に足す必要がある。
まだ人がやること
条件を書くこと。 何を required とし、何を optional とするかは、業務側の事情を知っている人にしか決められない。
相手を選ぶこと。 提案の比較評価には、価格や機能に表れない要素（付き合いの長さ、担当者の相性、撤退リスク）が入る。
契約すること。 責任範囲と検収条件の取り決めは法務の領域で、間違えたときの損失が大きい。