情報システム調達:提案公募での業者選定手法はこれまでの呪縛を打ち破れるか(2)

前回の記事「情報システム調達:提案公募での業者選定手法はこれまでの呪縛を打ち破れるか(1)」の続きです。
架空の自治体、自治市のお話です。
まず個人的な意見ですが、私は情報システムの調達は一般競争入札で行うことが基本だと考えています。
というのは、どういう方式での業者選定であっても、委託契約を締結する段階では委託仕様を確定する必要があるためです。
少なくとも、自治市の委託契約は「請負」であるため、曖昧な仕様は契約後のトラブルを誘発し、訴訟問題に簡単に発展します。訴訟事件にならないのは、自治市が外界から実質的に隔離されたガラパゴスな自治体だからです。
まぁ私の基本的な考え方は、なかなか組織全体には浸透しませんので、本日も公募型プロポーザル方式が採用されています。ただせっかくならば、本当によい提案が採用され、その後の随意契約交渉が容易に進められる手法を追求していくことも必要でしょう。
そこで私自身もいろいろと勉強しました。
現在の自治市における公募型プロポーザル方式は、案外雑に運用されています。雑というと語弊があるかもしれませんが、言い換えれば、「後付けの理屈によりいくらでも解釈を変えることが可能」です。
例をあげてみましょう。ある情報システムの新規開発案件です。
基本的な流れは次のとおり。

  1. 自治市の担当部門が当該情報システムに関するRFPを作成する。
  2. さらにRFPに対応した評価基準を作成する。
  3. 自治市担当部門がRFPを公示する。
  4. 応募業者がRFPに基づき提案書と見積書を作成し提出する。
  5. 自治市担当部門が招聘し組織した審査委員会において、各応募業者の提案書と見積書を評価基準に従って定量評価し得点化する。
  6. 得点の最も高い事業者を契約候補者、二番目の事業者を次点として決定し、各事業者に通知する。
  7. 自治市担当部門と契約候補者が、改めて仕様内容を協議し契約交渉を行う。合意に至れば委託契約(発注)する。
  8. もし契約候補者との協議が期限内に調わない場合は次点の事業者と契約交渉を行う。

この中で大きく影響を与えるのが、RFPと評価基準の作成です。私が危惧しているのは、これらの検討が不充分であるがゆえに、なんだかズレてしまっているものが自治市に納品されてしまっているという事実です。
先に結論を書いておきましょう。
「自治市担当部門の職員は、何が欲しいのかが自分でよくわかっていない」
わかっていないのならば、その事実を素直に認めて、自問するところからスタートすればいいのです。しかし、プライドなのかどうかは判りませんが、それを認めようとしません。
結果、形式的なところにこだわりをみせてRFPを作ることになります。自問していないわけですから、どこかの先行事例を引っ張ってきて体裁だけ整えられたRFPができてしまいます。
こうやって作られたRFPには特徴があります。
それは、提案を求める事項が極端に少なく、要求する事項も疎らで、要件に関する記述がやたらに多いことです。
用語解説が必要ですね。RFPには3つの要素が含まれます。

  • 提案事項(WANT)
    依頼者(この場合は自治市担当部門)も漠然とそのものがイメージできずに、できればなんらかのアイディアを示してほしい事柄。
  • 要求事項(MUST)
    依頼者が求めるもののイメージが明確であり、必ず実現してほしい事柄。
  • 前提条件(Postulate)
    提案事項や要求事項を示す際にあらかじめ考慮すべき事柄。

一見すると区別のつきにくい概念ですが、これらは異なる事柄ですし、それぞれに密接な関係があります。
図にしてみました。
RFP
まず「前提条件」ですが、これはRFPを書いている時点ですでに明らかになっている事柄です(そのため過去の領域に位置付けています)。言い方を換えるならば「制約条件」という解釈でもよいかと思います。
特に情報システム構築に関するRFPならば、「業務要件」という表現をするとしっくりきますかね? ただし、私の主張する「前提条件」は、政府や自治体で掲げている手法における「業務要件」とは少し異なります。
というのは、現在の公共調達の場で示されている「業務要件」の記述の多くは要求事項を含んでおり、整理されていないのです。
つまり前提条件において業務について示す場合には「処理件数は年間1000件前後」とか「財務会計のデータを取り込んで入金情報の消し込みをしている」というような事実を示します。決してシステムで実現してほしいことを書くものではありません。
ちなみに先行事例を援用して書いたRFPでは、一見この手の記述が充実しているように見えます。しかし、援用できるのは、どのような情報システムの場合でも書かれているような(当たり前の)事柄ばかりですので、結果として前提条件の記述レベルは著しく低いものになります。
「納期を守ること」とか「各フェーズの完了時には委託者の検収を受けたうえで次のフェーズに進むこと」とか書かれてても(契約としては意味がありますが、)ほとんど役に立たないのです。
ということで、次回に続く。