ITシステム発注者から見たプロジェクトマネジメント

調達仕様書は、ざっくり言えば構築したいシステムをどのような条件でどのような手順で構築するのかを受注者に示すものとなります。RFP(Request For Proposal)とも呼ばれることもあります。

調達仕様書のサンプルは、以下のサイトのものが参考になると思います。

【独立行政法人情報処理推進機構(IPA)】
情報システム調達のための技術参照モデル（TRM）調達仕様書ひな形編
https://www.ipa.go.jp/osc/trm/trmtemplate.html

【総務省】
政府共通ルールの策定(標準ガイドライン等)
http://www.soumu.go.jp/main_sosiki/gyoukan/kanri/i...



プロジェクト計画書と要件定義書があれば、それを流用すれば調達仕様書の半分以上は作成できます。（「プロジェクト計画書」および「業務要件とシステム要件」を参照ください。）
それ以外の記載事項としては、以下のようなものがあります。

・参加（受託）条件
　調達に応じるための受注者に求める前提条件を記載します。（資格・認証、実績、作業場所など）

・調達方法
　受注者決定までの流れを記載します。
　（提案書の提出期限、質問回答の方法、プレゼンテーションの実施要領、受注者の決定基準など）

・作業範囲
　該当調達で受注者に委託する作業範囲を記載します。
（職員研修、ヘルプデスク、運用保守など追加作業があればあわせて記載）

・契約条件
　受注者決定後に契約する際の条件を記載します。
　（機密保持、遵守する法令、知的財産権の帰属、再委託の制限、瑕疵担保責任、検収条件など）


また、調達仕様書で示す要件定義についてですが、下記の範囲でシステム開発ベンダーに要件定義の一部をシステム開発作業とあわせて委託するのが理想となります。（下図は「業務要件とシステム要件」からの流用です。詳細はそちらで確認ください。）



ただし、実際には発注者側のITスキルが十分でないことが多いため、まずは下記のように要件定義の一部をコンサルタント会社などに委託して、その後にシステム開発ベンダーにシステム構築を委託するという流れになる場合も多いです。



こういった場合も前述の作業範囲にどこまでの作業を委託するのかを明確に記載しておく必要があります。



もう一つ要件定義の注意点があります。

理想として調達仕様書にシステム要件の一部も含めて記載したほうが良いと書きましたが、一方であまり書きすぎないほうが良い場合もあります。

どういうことかというと、発注者がやりたいこと（業務要件）に対しての実現方法（システム要件）は一つとは限りません。ITの技術は日進月歩で成長しており発注者が考える実現方法案よりもよい別の案が存在する可能性があります。システム要件はあくまで手段であるため、より良い手段があればそちらを選ぶほうが賢明です。
また特定の技術・インフラを条件としてしまうと、受託できる開発ベンダーを制限してしまう可能性もあります。昨今オープンソースなどが好まれているのはそういった理由からです。
（余談ですが、コンサルティング会社が開発ベンダーとつながっていて、特定の開発ベンダーに有利になるようなシステム要件を記載される場合もあります。）


調達仕様書は発注者と受注者の間で合意するための重要な文書となりますので、十分な検討を重ねて作成する必要があります。