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

前回の記事「情報システム調達:提案公募での業者選定手法はこれまでの呪縛を打ち破れるか(2)」の続きです。
前回はRFPを作成する際の3つの要素について解説しました。

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

RFP
その中で、前提条件(Postulate)について解説したのでした。
ということで、次は「要求事項(MUST)」です。
前述した「前提条件(Postulate)」を踏まえて、システムとしてどのようなものが欲しいのかを記述するものです。
そして、ここで重要なポイントです。「前提条件(Postulate)」と「要求事項(MUST)」は因果関係が成立するものなのです。
つまり、
「○○(前提条件)」であるため「××(要求事項)」してほしい。
と書くようになるのです。
このあたりは、少し情報システムの素養が求められるポイントなのかもしれません。でも、先行事例を見るというならば、前提条件から要求事項を導き出すセオリーのようなものを類推することを心がけてもらう方が意味があると思うのです。
(このセオリーみたいなのは個別に研修して会得してもらった方がよいのでしょうかねぇ)
ちなみに一般競争入札をするのならば、仕様書にここまでの「前提条件」と「要求事項」がもれなく記述されているだけで十分に機能します。
今回は公募型プロポーザル方式の話ですので、ここでさらに「提案事項(WANT)」という要素が出てきます。
「提案事項(WANT)」とは、要求事項として形式化できない事柄や、そもそもノーアイディアである事柄について、前提条件に基づく新たなアイディアを求めるものです。
当然「前提条件」と「提案事項」には因果関係が成立します。
また「要求事項(MUST)」は達成しなければならない最低条件であるのに対し「提案事項(WANT)」は素晴らしい内容を評価する前向きな視点を持ちます。
自治市では一般競争入札ではなく、公募型プロポーザル方式を採用しがちなのは「要求事項が書けないため提案事項を求める」ことが理由とされています。しかしながら、要求事項として自明であることすら記述せずに、その上の提案事項を求めることは実際のところ困難です。
こういう状況ですので、提案事項に対する評価基準の設定もなかなか雑にされてしまっています。
前提条件が形式的で、要求がなされておらず、何を提案してほしいのかが不明な状態で、何を評価するというのでしょうかね・・・。
現状では、評価基準が設定できないので、とても抽象的な基準で評価を行っているのが現状です。
びっくりする評価基準として、

  • 提案内容が理解できているか(!)
  • 提案書がよく書けているか(!!)

なんてのもあります。評価基準も曖昧です。
こんな公募型プロポーザル方式の必勝法は、

  • RFPに書かれた(ありきたりの)前提条件とわずかに書かれた要求事項を単にオウム返しに書き、「きちんとやります」の旨を追記する。
  • バカでも(失礼)理解できるような、見やすく、いや見栄えの良い提案書にする。

ということになります。
こうなるとよい提案がもらえることは期待できません。
私が自治市に赴任して、どうしてこんなことになってしまっているのかを理解するのに少し時間がかかってしまいましたが、いつまでもこんなインチキなことをやっているわけにはいきません。
そこで最近、大規模なシステムの調達案件があった際に、これまでの公募型プロポーザルの考えを一新し、新しい手法を検討のうえ実践してみることにしました。