なぜ自治体のベンダーロックインは繰り返されるのか？ 背景にある「発注者の3つの心理」（2/3 ページ）

[川口弘行，ITmedia]

「分からない」をどう乗り越えるか

　では「分からない」「怖い」「面倒くさい」を回避する方法を、順に考えてみることにしましょう。

　まず「分からない」を回避する取り組みですが、素直に考えると「分かるようにする」必要があります。では、”何を”分かるようにすればよいのでしょうか。

　筆者は、この部分に“ある誤解”があるのではないかと考えます。

　導入するシステムの機能（どのようなデータを使ってどう処理しているのか、そのための内部構造など）と非機能（レスポンスタイムなどの性能や保守性など、システムを満足して使える状態にする条件）について、詳細を決定して文書化しておくことが「分かる」ことだと考えがちです。

　これらの内容について知識を持っていることは望ましい面もあります。ただし、発注者が自らシステム開発を担うわけではない以上、知識の深掘りには限界があります。加えて、近年ではパッケージシステム導入も増えており、その内部構造は企業の機密に当たるため、発注者が詳細まで把握するのは現実的には困難です。

　むしろ、問題は発注者でなければ決められないことを決めていないことです。例えば、どのような背景、制約条件の中で、なぜそのシステムを導入する必要があるのか。つまり、システムを導入、運用することで、どのような課題を解決したいのか、新たにどのような価値を得たいのかという点です。

　発注者として本当に実現したいことを整理し、ベンダーに分かりやすく伝えられれば、役割は十分に果たしていると言えるのではないでしょうか。そこから先の実現手段を考えるのはベンダー側の責務ですし、発注者とベンダーの役割分担を明確にし、その前提となる条件について双方が合意しておくことが重要だと考えます。

発注者には、システムへの理解よりも導入目的の明確化が求められる

　その際、公共調達のテクニックとしてRFI（情報提供依頼書）の活用があります。これは、正式な入札前に発注者が複数のベンダーに対して仕様案などを提示し、ベンダーから「応札を判断するために必要な情報」を聞き出す仕組みです。

　筆者がRFIを実施する際は、調達仕様の改善や応札意思の判断材料となる情報であれば、機密性の高い内容を除き、できる限り積極的に公開することを心がけています。その過程でベンダーから「新規参入を目指している当社としては、現状では判断に必要な情報が十分ではない」というような率直な意見をいただくこともあります。しかし、こうした意見に真摯に耳を傾けなければ、発注者として何が不足しているのかを把握することは難しいでしょう。

　なお、この「発注者でなければ決められないことを決める」行為は、システム導入の場面だけの話ではありません。自分たちが何者で、何のために存在しているのかを他者に説明する機会は、採用活動や人事異動に伴う業務の引き継ぎでも必要となります。

　ここで言語化、文書化されたものは、組織全体の資産であり、日々資産を形成しているという認識でいなければならないのです。

　先ほど例に挙げた公共系団体でも、既存ベンダーと随意契約を結びたい理由として「長年この業務システムの開発・保守に携わり、十分な知見がある」という説明がありました。裏を返せば、発注者側にはその知見が備わっていないことを認めているようなものですが、システムの内部構造を熟知できたとしても、発注者としての役割は別のところにあります。「知見」に対する認識のズレが現在の状況を招いているとも言えるでしょう。

「怖い」――新システム調達のリスクとどう向き合うか

　続いて「怖い」を回避する取り組みについて考えてみましょう。

　不安を解消するために既存ベンダーを選ぶという行為は、発注者の不安をベンダーに転嫁しているだけだと言えます。その場合、転嫁された側のベンダーは不安を感じていないのでしょうか？　もちろん不安を感じていると思います。

　では、ベンダーはなぜその不安を引き受けているのでしょうか？

　「ビジネスだから」というのは一つの答えですが、不安を解消するための取り組みと備えを持っているからだと思います。

　コンピュータシステムを開発する企業は、ソフトウェアの品質を確保するための手法について、日々研究と実践を進めています。ソフトウェアが設計通りに動作するかのテスト技術についても、多くの知見があります。

　しかし、それ以上に大きな不安解消の要素となるのが「システムが安定して稼働し続けている」という実績です。見た目や設計が古いものであっても、実際に課題解決や目標達成に貢献しているのであれば、それ自体が正当性の根拠となります。

　長期にわたり安定運用されてきた実績が信頼につながり、稼働実績の多いパッケージシステムが高く評価されるのも、こうした理由によるものです。

　ここで誤解してほしくないのは、「パッケージシステムだから価値がある」のではなく、「豊富な稼働実績があるか」が重要であるという点です。

　極端な例ですが、新しく開発されたばかりのパッケージよりも、長年多くの場面で動いてきたスクラッチシステムの方が信頼性は高い場合もあります。また、システムをリプレースする際も、現行のソフトウェア資産をできるだけ流用できた方が移行リスクを抑えられるのは言うまでもありません。

　つまり「リスクを十分に引き受けられる体制や実績を持ったベンダー」に発注者の不安を託すことは、一定の合理性はあると言えます。ただし、その前提となる実績や備えが本当に整っているのか、発注者側がきちんと確認しておくことが不可欠です。

　また、発注者が怖いと感じる理由の一つは「制御不能になる」ことだと筆者は考えます。仮にトラブルが発生しても、その原因や対策の見通しが立っていれば、不安を感じることも少ないはずです。「分からない」にもつながる話ですが、人間の認知能力を超えた規模の物事を見通すのはリスクを伴います。したがって、対象システムを適切な規模で分割して管理することも必要です。

　この観点から考えると、大規模なシステムを一度に丸ごと置き換えるのではなく、サブシステム単位で段階的にリプレースしていくアプローチも有効です。ただし、その場合は発注者自身がリプレースプロジェクトに長期的に関わり続ける覚悟と体制が求められます。これは後述する「面倒くさい」にも関連する話となります。