さて、前回、「仕様書の作成に「正解」など存在しない」という話をしました。
如何でしたか？
実際に発注側として調達に関わっている方は、少しは実感できるのではないでしょうか？
今回はその話の続きです。
システム調達をしよう！と思った時、まず最初に考えなければならないのは、「業務仕様書を作ること」ではありません。
（ここでは、システム化計画は立案されていて、将来のシステム化の構想は出来ている、と仮定します。）
最初に考えるのは、「事業スキーム」です。
プロジェクトのスキーム、と言ってもいいのですが、「プロジェクト」と言ってしまうと、費用の支払い方法やリスクの分担方法など、主にカネに関する契約関連の話題を忘れてしまう方が多いので、私は「事業」という呼び方をしています。
カネを払って成果を得るんですから、立派な「事業」ですものね。
発注する側と受注（すると想定される）側との力関係、持っている能力、予算、期間、システム化の難易度、その他もろもろの外部環境を考慮して、どのような契約条件で事業を行うのかを考えなければなりません。
その、「発注側から示す契約条件」を文書化したものが「仕様書」でなければなりません。
同じように、「受注者側から示す契約条件」を文書化したものが、「提案書」でなければなりません。
でも、実際にはそうなっている事例は少ないようです。
契約書、仕様書、提案書はそれぞれバラバラに存在し、それぞれが関連していません。
なので、「契約は契約、提案は提案」というように都合よく解釈され、リスクてんこ盛りのプロジェクトになってしまいます。
そのシステムでは契約費用内で実装するつもりが無いのに、様々な追加機能やコンセプト、果ては夢や希望やアピールポイントなどを長々と書いている提案書をたまに見かけますが、あれこそリスクの塊のような文書です。
そういう提案書を出してくる会社というのは、どんなに世界的な大手企業であっても、そもそも客（発注者側）の条件に従おう、なんて考えていないものです。
ですが、仕様書や提案書、議事録などその他文書は、契約書の別紙であることを明示的に示していれば、後になって「話が違う！」というリスクをかなり減らすことができます。
ここまで来ればお分かりの通り、仕様書において重要なのは、業務仕様ではありません。
発注側と受注側の役割・リスク・費用をどのように分担するのか、その境界線を明確にし、費用の支払いの有無や支払い方法を明確にすることです。有り体に言えば、カネの払い方を細かく決めること、ですね。
弊社は実際、契約条件やプロジェクトの進め方は文書化しても、業務仕様は殆ど文書化しない、という調達・契約コンサルティングをすることがあります。
事業のリスクと効果とコスト、3つの要素について、事業固有の状況に最適なバランスを取ることが、システム調達のキモであり、成功の秘訣です。
余談ですが、契約条件である仕様を作成する際に、特に考慮しなければならないのは、「運用時にどのような問題が起こる可能性があるか」ということです。
システム化の事業において、運用とは、成果を実際に受け取るフェーズであると共に、「リスクが最も顕在化するフェーズ」でもあります。
開発がやっとこさカットオーバーに漕ぎ着いて、達成感にまみれる気持ちは良く分かりますが（笑）、事業（もしくはプロジェクト）としてはそこからが本番です。
調達時に、将来そのシステムの利用が完了する日までに起こりうるリスクを想定し、そのリスクを回避できるような条件を仕様書に盛り込む必要があります。
運用においてどんなリスクがどのように顕在化しやすいのか、これには様々なプロジェクトの計画〜調達〜開発〜運用〜終了まで全てのフェーズに関わった経験が必要になります。
要件定義だけ、開発だけ、という経験では、判らないことが沢山ありますよね。
最後はやっぱり、弊社の宣伝で終わりたいと思います（笑）
詳しいことが気になる方・お困りの方はぜひお問い合わせください！
追記：弊社のこれまでのコンサルティング経験をまとめた、「公共団体のための情報システム調達ガイド」を作成しました。
システムの全てのフェーズで、リスクをコントロールし、マネジメントを行う手法をまとめています。
