システム導入における「妥協」の功罪について

CIO Contribution Strategy

はじめに

公共調達は一般競争入札が原則である。

とはいうものの、力のない発注者はこの原則を貫くことに疲れ、安易な道(特命随意契約とか)を選ぶ誘惑にかられてしまうのだが、私が関与する組織ではそんなことはさせない。

受注の機会を広範囲に与え、より良い成果を得るための手法として、私はこの原則を大切にしている。

ちなみに、一般競争入札の中には「最低価格落札方式」と「総合評価方式」というものがある。最低価格落札方式は文字どおり「ある定まった仕様に基づき、もっとも安値を示した者と契約する」方式である。

一方、総合評価方式とは「入札価格だけでなく技術的な提案を定量的に比較し、総合的に優れた者と契約する」方式である。情報システムの調達では、最低価格落札方式に耐えられる仕様を示すためには克服すべき課題が多く残されている(遠まわしに書いてます)ため、総合評価方式を採用するケースが多い。

なお、「プロポーザル型業者選定」という方法もあるのだが、これは一般競争入札ではなく、随意契約のための業者選定の手法である。ただし「技術的な提案を定量的に比較する」という行為を行うところは総合評価方式と同じなので、事実上同じような取扱いで運用している自治体もある。

技術提案評価における提案依頼書(RFP)

総合評価やプロポーザル、いずれの場合でも技術的な提案を求めるために提案依頼書(RFP)を発注者から示すことになるのだが、RFPをどう書いたらいいのか困っている職員が多い。これはどの行政機関でも共通した悩みのようだ。結果、何が評価の軸なのかわからない「なんちゃって総合評価」「なんちゃってプロポーザル」が横行し、情報システム導入の質を下げている。

私が職員に対して検討の入口として指導していることは、非常に単純である。

  1. まず、「ほしいもの」「やってほしいこと」を素直に挙げる。難しい言葉を使う必要はないけど、素直に挙げること自体が難しいので、案外訓練が必要かもしれない。
  2. 上記1.について、今までどうだったのか、現在どうなっているのかを挙げる。これも難しく書く必要はなく「イケてること」「イケてないこと」を挙げてもらえればよい。
  3. 上記2.の「イケてないこと」について、「本当はこうあってほしいのに」と思うことを、対比させて挙げる。
  4. 上記1.と上記3.の内容を併記させて、整理する。(整理の基準や手法についていろいろ書きたいけど、ここでは省略。知りたかったら個別にコンタクトしてください。)
  5. 整理した「ほしいもの」「やってほしいこと」から、「これらが実現したら何がどうなるのか(よくなるのか)」という目論見を挙げる。この目論見は非常に重要で、予算協議の際にはこれが説得材料となる。

ざっとこんな感じ。

ここで「ほしいもの」を整理したが、従来の最低価格落札方式の調達仕様では、これをどこまで精緻に書くのか、どう表現すれば認識の違いを解消できるのかという点に注目してしまい、本来の調達の目的がおざなりになってしまう可能性もあった。RFPの場合には、”提案事項”を仲立ちとして発注者と応札者との間で仕様の補完が行うことにより、調達目的を逸脱することなく事前の合意形成が行われている構造になっているものと(私は)考えている。

Fig1

図1.WHY→WHAT→HOWの関係

この図は、物事を「抽象」から「具体」へ導くためにたどるステップである。調達仕様も概ね同じような流れである。WHY(なぜなのか;目的)→WHAT(何なのか;ほしいもの)→HOW(どうするのか;やってほしいこと)という関係が成立する。少し色の違う枠は、本来は発注者から明確に示さなければならない事項について、”提案”をもらうという意味である。

(ちょっと横道にそれると、この”提案”を求める方法や考え方についても、世の中の多くの行政機関は「間違っている」と断言できるのだが、その話はまたの機会に)

「ほしいもの」「やってほしいこと」を「できること」に

いずれにしても、調達仕様は整ったとしよう。応札業者、あるいは実際の受注者はこれらを「できること」として整理し、実現に向けて活動しなければならない。

情報システム調達の場合、次の図のようなアプローチで「できること」を導き出している。

Fig2

図2.要素技術に分解する

そのとおり。個々の要素技術に分解して、できることとして定義しているのだ。近年の情報システムは複数の機能や要素技術の組み合わせにより構成されているため、まずこの作業に取り組むことになる。

ところが、そもそもの調達仕様がすべて実現性を担保して要素技術で構成されているわけではないのも事実である。まさか、と思われるかもしれないが、提案にゆだねることで、モヤモヤとしたフィージビリティを先送りしているような提案依頼書の場合、この現象が起こりうる。私はこれを「投げっぱなしジャーマン的提案依頼書」と呼んでいる。

恥ずかしながら告白すると、私自身も過去にそのような「投げっぱなしジャーマン」をしたことがある。あるいは、技術的なブレークスルーを期待して、WHYだけを重視して提案を求めたこともある。応札するベンダーの力量がある場合には、思いがけないアイディアを得て実現に弾みがつく一方、裏目に出るとどのベンダーも「できません」と応札を早々とあきらめ、調達が流れてしまうこともあった。

実現性が担保されない提案依頼とその回答の顛末

さて、ここからが今回のメインテーマである。(とりあえず私の妄想)

どうやら世の中(特に霞ヶ関界隈)には「降りてはいけない案件」というものがあるらしく、いくつかの要素技術について実現性が見えないまま応札をせざるを得ないベンダーもいるらしい。

降りられないのには事情があるようだが、そのあたりはあえて触れない。ただ、現在の政府調達のルールでは、一度調達が不調になると全体的な計画が数か月(場合によっては約一年)後にずれてしまうこともある。法律の施行日が先に決まっているような情報システムの場合、調達自体は大変神経をすり減らす行為であることは想像に難くない。

そうすると、とにかく何とかやってくれそうなベンダーと契約して(もちろん調達は適切に行われている)、実現性は「走りながら考える」とする案件が出てきてもおかしくない。システムの仕様がなかなか出てこない、とか、仕様がどんどん変更になる、といった現象がみられる場合には、少し実現性の担保を疑った方がよいと思う。当事者たちはおそらく苦しい思いをしているかもしれないのだが。

ただ、いつまでも苦しい思いをしているわけにもいかないので、ある段階で実現性の目途が立たなくなった時点で、仕様についての「妥協」がなされることになる。できないものはどうやってもできないのだ。この「妥協」が調達仕様に大きく響く場合には契約変更手続きが必要となるが、多くの場合には仕様書の拡大解釈によりうまく読み切るので、妥協が表に出るのはシステムが完成してからの話となる。

妥協することがいけないとは言わない。システム導入が破たんするよりもマシである。ただ、この妥協が許されるのは(個人的には)1回が限度だと思う。妥協を2回重ねれば、もはやそれは当初と異なるシステムだし、3回以上重ねるのであれば当初のWHYの設定意義にもかかわる話となる。

官民問わず、さまざまなシステム導入案件を見ていて、この「妥協」により骨抜きになるシステムや、逆に稼働させるだけで不幸をまき散らすようなシステムにも遭遇した。そう考えると、妥協を許さない、妥協を生み出さないシステム企画の能力が求められるのだろう。

 

photo by:

« »