あるお役所がCOBOLで書かれた古いパッケージソフトを使い続けている理由：政府の失敗に学ぶ、ベンダーマネジメントの勘所（前）（1/3 ページ）

マイナポータルの不具合、1円入札、COCOAのゴタゴタ──失敗の宝庫ともいえる政府ITの失敗と改善の歴史から、ベンダーマネジメントの勘所を学ぼう。

[ITプロセスコンサルタント 細川義洋，＠IT]

政府システム開発プロジェクトにおける、ベンダーマネジメント問題

　政府のシステム開発プロジェクトといえば、特許庁基幹システム開発で50億円以上の損失を出した件、マイナポータル導入時の不具合多発、最近ではCOCOAや補助金申請にかかわるゴタゴタなど、失敗ばかりが目立っています。これらはもちろん国の財政に負の影響を与えますが、それ以上に国民の政府や制度に対する不信を募らせるという意味で重大な失敗です。

　これらの問題には種々さまざまな原因があります。本記事では、こうした問題を「ベンダーマネジメント」という切り口で考えていきます。

　政府がベンダーの行う開発をうまくコントロールできない、あるいはベンダーロックインなどによってベンダーの言いなりになっているために、高いコストを費やした揚げ句に不具合の多発するシステムを作ってしまう――そんなことがこれまでも多くありました。これから先も続くとすれば、国の財政に悪影響を及ぼすことはもちろん、官民を含めて進めるべきDX（デジタルトランスフォーメーション）の進捗（しんちょく）を遅らせ、成長戦略の足を引っ張り、ただでさえ他国に後れを取り始めている日本のDX、ひいては経済の成長をさらに遅らせることにもなりかねません。

　元政府CIO補佐官だった私の自戒の念も込めて、政府のベンダーマネジメントに関する、これまでの「問題」や、これまで行ってきた「対応策」、そして、なお残る「課題」について概観していきます。

政府ITに見るベンダーマネジメント失敗の類型

　政府ITの場合、年度予算の関係もあって納期オーバーやコスト超過といった問題は表面的には見えにくいのですが、機能不全や不具合が多数発生したシステムの誕生は、民間と同じか、もしかしたらそれより多いかもしれません。前出の失敗例は、そうしたものの一部です。

　政府の失敗の数々をベンダーマネジメントという視点で見ると、幾つかの類型が見えてきます。大きく分けると、「1：IT導入の政策的（業務的）な目的をベンダーに理解させていない」「2：技術的な課題や難易度について発注者とベンダーが共有しきれていない」「3：ベンダーにプロジェクト管理義務を果たさせていない」「4：ベンダーロックイン」です（言いたいことは、他にも山ほどありますが……）。

　細かく見ていきましょう。

システム化の「目的」を見ず、「要件」にだけ縛られたベンダーの失敗

　まず「1：IT導入の政策的（業務的）な目的をベンダーに理解させていない」から見ていきます。

　政府でITを調達する入札を行う際、システムの要件定義書と共に「調達仕様書」を作成して公開します。応札者はこれに沿って提案書を作成し、めでたく落札すれば、ここに書かれていることを実現するためにプロジェクト計画を作成して作業に入ります。

　調達仕様書には「システム化の目的」が書かれています。これこそがIT導入の最も大切な部分ですが、抽象的過ぎたり概略過ぎたりしてベンダーの理解を生んでいないケースがあります。

　システム化の目的に「行政職員の省力化」や「国民の利便性向上」といった定性的で抽象度の高いことしか書いていない調達仕様書をよく見掛けます。これだとベンダーは何のためにシステムを作るのか分からないまま、「いわれた機能要件を実現するだけ」という姿勢で開発してしまいます。

　目的を理解せずに機能要件だけを金科玉条にして開発を行うと、状況に応じて機能を加えたり減らしたりするアジャイル開発や、ウオーターフォールでの要件の抜き差しなどができません。途中で要件が変わったり、加わったりしてもベンダーはかたくなに断るだけでしょう。

　ベンダーはとにかく当初の機能要件の実装さえすればお金がもらえるわけですから、極端な話、システムが業務に使えようと使えまいと関係ないし、そこで発注者がごり押しをするとプロジェクトは必ず混乱します。

　逆にベンダーが、「発注者がいっているから」と手戻りで工数が膨らんでも何とか対応しようとしてデスマーチになることもあります。前掲の特許庁のシステムも、開発中に特許庁が、「システムの全面刷新ではなく機能は現行踏襲」と方針転換をし、それに伴って要件が大幅に変わったにもかかわらず、ベンダーがこれに無条件に付き合ってしまったことがプロジェクト破綻の原因の一つだったと思われます。

　これがもし、「システム化の目的」や「それによって実現する業務の姿」をベンダーが理解し、契約上も、ベンダーの債務は「システム化の目的に資するものを作ること」であり、「当初要件に拘泥することではない」とされていれば、方針転換時に、「では、これとこれは後回しにして、これを捨てましょう。この部分は今まで通り、手作業でやってもシステム化の目的は果たします」とか、「来年にしましょう」などと提案でき、お互いの合意の下で最低限のシステムを作れたはずです。

　確かに政府ITでは、財務省や会計検査院が、費用と機能を結び付けてシステム開発をチェックしますから、機能を落とすことは簡単ではありません。しかし、民間同士のIT訴訟でも、裁判所が「請負契約の債務は契約の目的に資するものを納品することであり、要件のみに固執するものではない」という趣旨の判決を出しています。何よりも要件のみに固執した結果50億円の損失を生むよりは、よほどマシだったはずです。

　プロジェクト実施時にベンダーにシステム化の目的と皆が幸せになった絵姿を具体的にイメージしてもらうことは、無駄遣いをなくしてベンダーの積極的な提案を引き出すことになります。しかし残念ながら、政府ITにおいてはまだまだ「目的軽視」の仕様書が数多く見られ、ベンダーをただの作業者にしてしまっているケースがあります。

納品したシステムが契約の目的に合致しなかったためにベンダーが敗訴したIT訴訟例

検収後に発覚した不具合の補修責任はどこまであるのか（前編）

ベンダーが確実に支払いを受けるための3つのポイント（検収書裁判解説 後編）