第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編

連載 発注者からみた官公庁情報システムの現状と課題
第 26 回 官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調
達編
神奈川県庁 岩崎 和隆
１ はじめに
前回のメルマガ※１では、官公庁の情報システム開発運用保守を今後は全面的に内製化すべきことを論じました。しかし、様々な事情から、全面的ないし大半の情報システムについて、外注を継続することも多いと推察します。外注における受注者の決め方には、競争性に着目して分類すると競争性のある調達方法（以下「競争的調達」と言います。
）と、競争性が失われたときに採用する一者随意契約（特命随意契約とも言います。）の 2 つがあります。本稿では、前者におけるプロジェクト成功率向上方法について、私の考えを説明いたします。
なお、前回のメルマガで論述したとおり、外注ではどうしても解決できない課題がありますから、本稿で紹介する手法をフル活用しても、プロジェクト成功率向上の効果は限定的です。
また、民間企業の発注者及び受注者の方と異なり、私の発注者としての経験は少ないた
め、私自身が実践したことがないものばかりです。それでも、あえて論述するのは、日ごろ、勤務先及び他団体の方とお話をしていて、官公庁の多くの実務担当者が、競争的調達において情報システム開発運用保守プロジェクトの成功率向上をどのようにしたらよいか、困っていると感じるからです。
本稿が少しでも困っている実務担当者の方々の参考になれば幸いです。
２ 発注前の業務ルールブックの作成
前回のメルマガでも説明したとおり、競争的調達では、情報システムのライフサイクル
全体を一括契約にせざるを得ません。また、アジャイルの採用も不可能と考えざるを得ません。そうなると、情報処理推進機構（IPA）が指摘※２するとおり、開発プロセスの初期段階における規模見積もりは試算ないし概算にすぎないため、規模見積もりにあいまいさがある段階での見積もりが最後まで受注者の束縛になってプロジェクト成功の阻害要因になるという課題があります。
この課題を緩和するためには、発注時点において仕様をなるべく詰めて、発注仕様書において提示することが考えられます。具体的には、情報システムの実装次第で変わる部分
を除く制度や業務のルールを漏れなく業務ルールブックとしてまとめ、RFI で公表し、受注希望者の意見に基づきブラッシュアップします。たとえば、お金の計算をする機能を含
む情報システムでは、端数処理についても完璧に業務ルールブックに記載する必要があり
1 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編

ます。
業務ハンドブックに一般職員など業務に関係する職員と受注希望者双方のための詳細な事例集を記載して、それをテストケースに用いることも考えられます。
なお、情報システムのリプレースなどに伴い制度や業務の簡素化を行うときは、遅くても業務ルールブック作成時点までに行います。リプレースによる開発と並行して制度や業務を簡素化した例を聞いたことがありますが、それは、以下の理由により困難です。
制度や業務の簡素化は、開発をしていないときであっても、他の制度や業務との整合性の検討など制度及び業務設計、そして関係各所との調整に多くの時間が必要です。受注者が決まり開発が始まると受注者との打ち合わせ等で制度や業務の担当が多忙になります。
また、開発が始まると発注者は短期間での意思決定が求められます。このような状況では、制度や業務の簡素化のための時間を確保することが難しくなります。
また、制度や業務の簡素化では、少なくとも制度や業務の担当が把握できるレベルまで簡素化しないと、制度や業務の担当による制度や業務の運用が困難になります。
制度や業務の見直しでは、制度や業務が情報システムに向いているか否かも考慮します。情報システムに向かない制度や業務では、情報システムが複雑になるか手作業が増えるかのいずれかとなり、業務コストが増大します。
【本項実施に必要となる主な資源】
発注仕様書作成前の業務ハンドブック作成に必要な制度及び業務担当の増員。
３ 制度及び業務担当による要件提示及びテスト
制度及び業務担当が情報システムの開発や改修を情報システム担当に丸投げすると、要件の肥大化に歯止めが効きづらくなります。また、要件が制度及び業務担当から情報シス
テム担当を経由して受注者に伝えられると、伝言ゲームになって要件が正しく伝わらなくなります。そのため、制度及び業務担当が、受注者に直接要件を提示するとともに、発注者による受入テストのうち制度や業務の要件に係る部分を実施するようにします。情報システムに係る予算確保や受注者との開発内容の調整についても、制度及び業務担当が行う
ようにします。汗をかく人とそれによるメリットを得る人が、前者が情報システム担当、後者が制度及び業務担当では、外部経済ないし外部不経済になって、うまくいきません。
情報システム担当は、情報システムの知見に基づき、制度及び業務担当を支援します。
なお、本項については、アプリケーション・オーナー制度※３が参考になります。
【本項実施に必要となる主な資源】
開発中の要件提示及び受入テストに必要な制度及び業務担当の増員。
４ 受注者選定方法の見直し（１）技術的対話（競争的対話）の導入
国は、情報システム調達において、2020 年度（令和 2 年度）から技術的対話（競争的対2 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編話とも言います。
）を試行※４～７しています。私が知る限り、地方公共団体では甲府市※８を除き、技術的対話の実施例を聞いたことがありません。私は、地方公共団体においては、
技術的対話という調達方法が認知されていないという印象を持っています。
技術的対話以前の総合評価落札方式一般競争入札において、RFI から契約までの流れ
は、おおむね次の表１のとおりです。
表１ 総合評価落札方式一般競争入札における RFI から契約までの流れ
項番

発注者

１

〇

２
３

〇

〇

〇

８

〇

書面により質問提出
書面により回答を公表若しくは受注希望者へ通知〇

７

書面により意見提出
調達仕様書案などを適宜修正し、入札公告

〇

６

内容
調達仕様書案などについて RFI を作成、公表

〇

４
５

受注希望者

提案書提出。なお、提案書について、プレゼンテーショ
ンと質疑応答を行うのが一般的
審査に基づき落札者決定

〇

契約締結

入札公告後の質問と回答（表 1 の項番 4 と 5）は 1 回のことが多いです。発注者原因により受注希望者に仕様その他が誤って伝わったとき又は受注希望者原因により受注希望者
が仕様その他を誤って理解したときは、そもそも受注希望者から質問されない可能性が高
いため、質問回数を増やしても認識の齟齬が訂正される可能性は低いと言えます。
契約締結後は、打ち合わせにて要件を伝えることと対比すると、表 1 の流れでは、コミュニケーションの質も量も少ないです。私の経験では、契約締結後に問題が生じたことがあります※９。
次に、この総合評価落札方式一般競争入札において技術的対話を採用したときの RFI から契約までの流れはおおむね次の表２のとおりです。

3 / 14

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編

第 26 回

表２ 総合評価落札方式技術的対話における RFI から契約までの流れ
項
番
１

発注者

希望者

特有の手続き書面により意見提出〇

調達仕様書案などを適宜修正し、入札公告〇

書面により質問提出
書面により回答を公表若しくは受注希望者へ

〇

６

内容
調達仕様書案などについて RFI を作成、公表

〇

４
５

技術的対話

〇

２
３

受注

通知
〇

一次提案書提出
一次提案書の審査。基準点数を満たさない、

７

〇

〇

ないし受注希望者が多くて対話対象者を絞る必要があるときは、一部の受注希望者を一次審査不合格とする

８

〇

９
10

〇

11

〇

〇

〇

〇

〇

一次提案書について、対話を実施
※

複数回実施

一次提案書を修正し、最終提案書提出
最終審査に基づき落札者決定

〇

契約締結

私は、技術的対話による調達の経験はありません。しかし、従来の総合評価落札方式一般競争入札及び企画提案方式随意契約において提案書を拝読したとき、入札公告の表現の悪さが原因で発注者の意図が伝わらないと感じることが多かったため、項番 8 の対話により、意思疎通の齟齬の大半を防げると考えます。
次に、最終審査後に発注者と最優秀の提案をした受注希望者が交渉できる企画提案方式
技術的対話における RFI から契約までの流れを紹介します。これは、おおむね次の表３のとおりです。なお、この調達方法は、国では使えますが、地方公共団体のうち都道府県及び政令指定都市については、20 万 SDR（2020 及び 2021 年度は 3,000 万円）未満に限って可能です。その理由については、前回のメルマガをご覧ください。

4 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編

表３ 企画提案方式技術的対話における RFI から契約までの流れ

項
番
１

発注者

受注
希望者

企画提案方式特有の手続き
（注１）

〇

２

内容
調達仕様書案などについて RFI を作成、公表〇

書面により意見提出
調達仕様書案などを適宜修正し、公告

３

〇

※

入札ではないので、調達概要書という名称で公告する４５〇

書面により質問提出
書面により回答を公表若しくは受注希望者へ

〇

６

通知
〇

一次提案書提出
一次提案書の審査。基準点数を満たさない、

７

ないし受注希望者が多くて対話対象者を絞る〇必要があるときは、一部の受注希望者を一次審査不合格とする

８

〇

９

※

〇

10

〇

11

〇

12

〇

13
14

一次提案書について、対話を実施〇

一次提案書を修正し、最終提案書提出
最終審査に基づき優先順位交渉権者決定

〇
〇

〇

複数回実施

〇

〇

契約内容の交渉

〇

仕様書確定

〇

見積書提出
契約締結

注１ 総合評価落札方式技術的対話との比較です。
技術的対話では技術的対話を行わないときと比べて、発注者と受注希望者のコミュニケーションの質と量が改善されますが、発注者による審査が 2 回になること、発注者と受注希望者の対話を行うこと、受注希望者が提案書を対話の回数と同程度修正することが想定されることから、発注者、受注希望者双方の手間は増えます。そのため、比較的規模の大きい、あるいは難易度の高い情報システムの調達において採用することとし、規模が小さ
くかつ難易度の低い情報システムでは、総合評価落札方式一般競争入札若しくは企画提案
方式随意契約を採用するのがよいと考えます。発注者が、受注希望者のプロジェクト遂行能力評価を必要と判断したら、どんなに安価であっても、最低価格落札方式一般競争入札
5 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編など、価格だけで受注者を決めることは避けた方がよいと考えます。
提案書作成は受注希望者の負担になります。
（入札）公告作成や審査は発注者の負担になります。そのため、安価な案件では、総契約額見合いで受注希望者及び発注者の過度な負担にならないよう、提案書や審査基準、また、受注希望者のプロジェクト遂行能力評価を簡素にします。
（２）審査基準（落札者決定基準）における総合点算出方式の見直し
技術的対話を行う場合であっても、一次審査及び最終審査において、予め定めた選定基準に基づき審査することが必要です。総合評価落札方式技術的対話では審査基準に基づき落札者を決定するため落札者決定基準という言葉を使えますが、企画提案方式技術的対話
では審査基準に基づき優先交渉権者を決めるため、落札者決定基準という言葉は不適切です。そこで、本稿では審査基準という言葉を用います。
私は、審査基準における総合点算出方式として現在主流となっている加算方式を採用す
ると、情報システム開発運用保守プロジェクト成功率向上や業務の QCD 確保が難しいと考えています※10。また、私の経験から、受注希望者のプロジェクト遂行能力を受注希望者の業務実績やプロジェクト管理手法などの評価要素に細分化して評価すると、受注希望者のプロジェクト遂行能力を適切に点数化できないと考えています。
国ではガイドライン※11、12 で加算方式を用いることとしているため、ガイドラインを改正しないと加算方式に代わる新たな方式は採用できませんが、地方公共団体ではそのような制約がありません。
加算方式に代わり私が提案する総合点算出方式は次のとおりです。
総合点 10,000＝ （基礎点 90 ＋ 仕様を上回るサービス点 5 ＋ 価格点 5）
× プロジェクト遂行能力評価（及びパッケージソフトウェア品質評価）100※ 数値はそれぞれ満点。なお、基礎点はすべての受注希望者に一律満点をつける。
なお、パッケージソフトウェア品質評価については、パッケージソフトウェア導入のときに限ります。パッケージソフトウェア品質評価の必要性については、私のメルマガ第 6
回※13 で説明しています。
パッケージソフトウェア品質評価については、実施例を聞いたことがないため、実施可
能か否か、予め RFI 等で情報収集する必要があります。実施する場合、受注希望者から、一例ですが次の表４記載の資料を提供してもらうことが考えられます。

6 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編

表４ パッケージソフトウェア品質評価において受注者に提示をお願いする資料
項番

資料内容

１

過去 5 年間に判明した製品不具合件数

２

同不具合内容３

同不具合解決までの所要期間

４

現時点で残存している不具合内容と判明時期※

過去 5 年間に判明したものに限定しない

そして、プロジェクト遂行能力評価（及びパッケージソフトウェア品質評価）については、評価要素を細分化しないで、ひとつの評価要素として 10 段階の評価とします。この10 段階評価では、まず、すべての受注希望者についてプロジェクト実施のリスクを大小の二段階で評価し、大の受注希望者については、0 点とします。すべての受注希望者が 0 点のときは、調達のやり直しないしプロジェクトを中止します。次にリスク小の受注希望者について、最優秀の受注希望者を満点とし、他の受注希望者については、最優秀な受注希望者を基準とした相対評価とします。最優秀な受注希望者との比較で発注者が有意な差がないと判断した受注希望者は満点、有意な差がある受注希望者については、最優秀な受注
希望者を基準にして適宜１から９の範囲で評価し、それを 10 倍して点数にします。
プロジェクト遂行能力評価について、評価要素としてプロジェクト計画書の評価（50 点
満点）、技術的対話における受注希望者のプロジェクト遂行能力の心証評価（50 点満点）のように細分化しないでプロジェクト遂行能力評価（100 点満点）というひとつの評価要素にするのは、私の経験や見聞から、評価要素を細分化すると、適切な評価から乖離することが多いと考えるからです。パッケージソフトウェア品質評価を行うときは、プロジェ
クト遂行能力評価とパッケージソフトウェア品質評価をあわせてひとつの評価要素とします。
これは、次の理由によります。プロジェクト遂行能力評価及びパッケージソフトウェア
品質評価全体で 100 点満点としたとき、このふたつを別々の評価要素にするとします。たとえば、両者を加算するときは、前者を 70 点満点、後者を 30 点満点とすることが考えられます。両者を乗算するときは、前者を 20 点満点、後者を 5 点満点とすることが考えられます。これとの対比で、あわせてひとつの評価要素としたときも 100 点満点で採点します。ふたつを別々の評価要素にして加算ないし乗算で採点したときと、ひとつの評価要素
として採点したときの点数が一致しないとき、発注者としてどちらの点数を採用した方がプロジェクト成功率向上を見込めるかを考えると、ふたつを別々の評価要素にしたら発注者にとって不本意な選定結果になるおそれがあります。
そして、プロジェクト遂行能力評価（及びパッケージソフトウェア品質評価）をひとつの評価要素にするときの注意点があります。この評価要素は、加算方式の見直しにより審
7 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編

査結果を大きく左右します。そのため、この評価要素の点数について、他の受注希望者と比較した詳細な評価理由を作成し、受注できなかった方への説明や、万が一、審査結果に疑義が生じたときに備える必要があります。この評価理由については、受注できなかった
方の不利益にならないよう、匿名であっても一般には公開しないことと、受注できなかった方からの要求があれば、その方に対し、本人及び受注者の評価理由に限定して、開示することを想定しています。
（３）受注希望者のプロジェクト遂行能力評価の見極め方の見直し
受注希望者のプロジェクト遂行能力は、従来、提案書に受注希望者の業務実績やプロジ
ェクト管理手法などの記載を求め、それぞれを評価要素とする※14 とともに、受注希望者のプレゼンテーションも評価要素としていました。しかし、すでに説明したとおり、複数の評価要素に分割することは好ましくないため、単一の評価要素とし、次のものを総合的に評価するように改めます。
ア プロジェクト計画書（入札）公告でプロジェクト計画書の提出を依頼します。
イ 技術的対話の過程における心証
技術的対話は本来、受注希望者が調達仕様書等入札内容についての理解を深めるとともに、発注者と受注希望者の対話を通して受注希望者の提案書を改善する場と考えられます。しかしながら、私の経験では、RFI より前の情報収集において受注希望者と打ち合わせを何度か実施すれば、受注希望者のプロジェクト遂行能力について、ある程度心証が得られることが分かっています。また、同じく私の経験ですが、受注希望者のプレゼンテー
ションだけでは、受注希望者のプロジェクト遂行能力評価を行うためのコミュニケーショ
ンの量が不足することも分かっています。
そのため、技術的対話において発注者と受注希望者のコミュニケーションの質と量が増えることを利用して発注者が積極的に心証を形成して評価に反映させます。具体的には、提出されたプロジェクト計画書について質疑応答を行います。業務実績なども必要に応じて提案書への記載を依頼し、それが今回発注の案件との関係でプロジェクト遂行能力が高いと判断できるか、質疑応答を通して発注者が心証を形成するようにします。
なお、手続き論として、（入札）公告において、対話をプロジェクト遂行能力の心証形成にも利用する旨を記載しておいた方が、後日、受注できなかった方とのトラブル防止になると考えます。
ウ 口コミ（ア）手続き論
手続き論として、口（くち）コミを評価に用いるには、（入札）公告にその旨を記載する必要があると考えます。
（イ）口コミの集め方
口コミの集め方としては、次の方法が考えられます。
8 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編

ａ 提案書に記載された業務実績
提案書の業務実績において発注者の実名の記載を依頼します。
なお、（入札）公告において、当該発注者から口コミを収集すると記載すると、上手くいかなかった業務実績を記載しないおそれがありますが、受注希望者とのトラブル防止のためには、記載する必要があると考えます。
ｂ 他団体などへの照会
たとえば発注者が都道府県であれば全部で 47 団体なので、（入札）公告前にすべての団体から発注を予定している情報システムと同種の情報システムの受注者を聞いておき、対話と並行して受注希望者が現に受注している団体から、仕事ぶりをヒアリングすることが考えられます。また、発注者の別の部署における受注希望者の仕事ぶり、たとえばＡ県が人事給与システムを調達するときに、Ａ県の別の部署が担当している会計管理システムの口コミを考慮することは、（入札）公告にそのようなことがありうることを記載していれば、問題ないと考えます。
ｃ Web
Web で匿名のものを含めて口コミを収集することが考えられます。
（ウ）収集した口コミへの受注希望者の反論の機会の有無
他の発注者からヒアリングした結果を受注希望者に説明して反論の機会を与えることは、偏った口コミが是正される機会が得られる反面、他の発注者が口コミの提供を躊躇する可能性があります。Web で口コミを集める場合にはそのような懸念がないことと、信憑性に問題がある可能性を考慮して、受注希望者に反論の機会を与える必要があると考えます。
（エ）口コミ利用の課題
口コミ利用は一般的には客観性に欠けると言われますが、私は、公平性の視点からは望ましいと考えます※15。しかし、口コミを集める範囲と収集した口コミへの受注希望者の反論の機会の有無については、さらに検討が必要と考えます。口コミを実務で利用し、実務からフィードバックを得ないと、これ以上、口コミ利用の検討が難しいという面もあります。
そのため、ここでは、仮の結論として、口コミの収集方法は本稿記載のすべての方法を用いることとし、反論の機会については Web で収集したものに限定することとしておきます。
エ パッケージソフトウェア品質評価
パッケージソフトウェア品質評価については、本稿第４項表４をご覧ください。
５ 適切な調達単位の設定
たとえば人事給与システムを、一般職員が入力に使用するフロント機能と給与計算などを行うバック機能に分けて調達する例が見受けられます。フロント機能限定のパッケージ
9 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編

ソフトウェアの存在がその一因になっているのかもしれません。このように分割調達すると、一般的には受注希望者の増加が見込めます。
しかし、フロント機能とバック機能に分けると、相互のインターフェースの数が多くなると考えられます。インターフェースの数が多いときに調達を分割すると、次のとおり発注者が困ることになります。
仮に、フロント機能をＢ社、バック機能をＣ社が受注したとします。分割調達している
ので、契約関係は発注者とＢ社間、発注者とＣ社間となり、Ｂ社とＣ社との間には契約関係がありません。Ｂ社原因の不具合によりインターフェースが適切に動作しないとき、発注者とＣ社との法的関係では、Ｂ社は発注者の補助者となるため、Ｃ社に対しては発注者
原因の不具合となります。逆も同様です。そして、実務上は、フロント機能とバック機能のどちらかに不具合があるのは発注者が証明できるが、どちらに不具合があるのか、発注者が証明だけでなく疎明もできないことがあります。Ｂ社、Ｃ社ともに発注者から不具合があるとの疎明がないため調査に応じず、不具合が解消しないことがあります。また、フロント機能の不具合ですがバック機能を修正した方が容易に対応できるときもあります。
しかしバック機能を受注したＣ社に契約不適合責任に基づく修正を求めることはできません。
そのため、インターフェースの数が多いときは、まず、一緒に調達することを検討します。具体的には、ジョイントベンチャーを認めることとし、それによって受注希望者が複数見込めるか、そのうち一社以上がプロジェクト遂行能力を十分に有しているか、事業者から情報収集します。
競争的調達において複数の受注希望者が必要なことと、受注希望者の中にプロジェクト遂行能力を十分に有した受注希望者が一社以上いないとプロジェクトの成功が難しくなる
ことから、いずれかを満たせないときは、いずれかを満たせるように分割発注せざるを得ません。
ジョイントベンチャー方式では、仮にジョイントベンチャーＢＣ連合においてフロント
機能をＢ社、バック機能をＣ社が受注していても発注者の契約は、発注者とジョイントベ
ンチャーＢＣ連合との契約になります。そのため、発注者はフロント機能とバック機能のいずれに不具合があるか特定しなくても、人事給与システム全体として受注者に不具合があることを証明できればジョイントベンチャーＢＣ連合に契約不適合責任に基づく修正を求めることができます。
６ 体制（１）優秀な制度、業務及び情報システム担当の確保
難易度の高い情報システムであれば、優秀な人材が必要です。情報システム担当だけでなく、制度及び業務担当にも優秀な人材を必要数確保します。情報システム担当については、民間からプロジェクトマネジメントや情報セキュリティなどに精通した人材を採用す
10 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編ることも考えられます。
（２）工程管理支援者の導入
工程管理支援者を内部ないし外注により確保することも考えられます。なお、工程管理支援者は優秀なだけでなく、工程管理支援者に十分な権限を付与しないと、プロジェクトの軌道修正、必要があれば早期中止などが行えません※16。工程管理支援者の調達も官公庁の調達制度の制約を受けます。工程管理支援者を外注するとき、適切な受注者の選定が難しいようでしたら、雇用であれば官公庁の調達制度の制約を受けないため、個人のアドバ
イザーの雇用も考えられます。
７ まとめ
官公庁における情報システム開発運用保守では内製化を推奨しますが、外注を継続する
なら、以下の方法により効果は限定的ですが、プロジェクト成功率向上が見込めると考えます。
情報システムの実装次第で変わる部分を除く制度や業務のルールを漏れなく業務ルール
ブックとしてまとめ、RFI で公表し、受注希望者の意見に基づきブラッシュアップします。情報システムのリプレースなどに伴い制度や業務の簡素化を行うときは、遅くても業務ルールブック作成時点までに行います。
制度及び業務担当が、受注者に直接要件を提示するとともに、発注者による受入テストのうち制度や業務の要件に係る部分を実施するようにします。情報システムに係る予算確
保や受注者との開発内容の調整についても、制度及び業務担当が行うようにします。アプ
リケーション・オーナー制度も参考になります。
比較的規模の大きい、あるいは難易度の高い情報システムの調達において企画提案方式
技術的対話ないし総合評価落札方式技術的対話を採用することとします。規模が小さくか
つ難易度の低い情報システムでは、総合評価落札方式一般競争入札若しくは企画提案方式
随意契約を採用することとします。
審査基準における総合点算出方式として現在主流となっている加算方式をやめて次の方式を採用します。
総合点 10,000＝ （基礎点 90 ＋ 仕様を上回るサービス点 5 ＋ 価格点 5）
× プロジェクト遂行能力評価（及びパッケージソフトウェア品質評価）100※ 数値はそれぞれ満点。なお、基礎点はすべての受注希望者に一律満点をつける。
そして、プロジェクト遂行能力評価（及びパッケージソフトウェア品質評価）については、評価要素を細分化しないで、ひとつの評価要素として 10 段階の評価とします。この11 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編

10 段階評価では、まず、すべての受注希望者についてプロジェクト実施のリスクを大小の二段階で評価し、大の受注希望者については、0 点とします。すべての受注希望者が 0 点のときは、調達のやり直しないしプロジェクトを中止します。次にリスク小の受注希望者について、最優秀の受注希望者を満点とし、他の受注希望者については、最優秀な受注希望者を基準とした相対評価とします。最優秀な受注希望者との比較で発注者が有意な差がないと判断した受注希望者は満点、有意な差がある受注希望者については、最優秀な受注
希望者を基準にして適宜１から９の範囲で評価し、それを 10 倍して点数にします。
受注希望者のプロジェクト遂行能力は、プロジェクト計画書、技術的対話の過程における心証及び口コミを総合的に評価します。パッケージソフトウェア品質評価では、一例ですが、過去 5 年間に判明した製品不具合件数、同不具合内容、同不具合解決までの所要期
間、現時点で残存している不具合内容と判明時期（過去 5 年間に判明したものに限定しない。
）を総合的に評価します。
調達する情報システム間のインターフェースが多くなるときは、別々に調達しないでジョイントベンチャーを認めて一緒に調達することを検討します。その際、（入札）公告に対し複数の受注希望者が見込めること、受注希望者の中にプロジェクト遂行能力を十分に有した受注希望者が一社以上いることを公告前の情報収集で確認しておきます。
難易度の高い情報システムであれば、情報システム担当だけでなく、制度及び業務担当にも優秀な人材を必要数確保します。情報システム担当については、民間からプロジェク
トマネジメントや情報セキュリティなどに精通した人材を採用することも考えられます。
優秀な工程管理支援者を内部ないし外注により確保し、プロジェクトの軌道修正、必要があれば早期中止など、十分な権限を付与します。工程管理支援者の調達も官公庁の調達制度の制約を受けるため、適切な受注者の選定が難しいときは、個人のアドバイザーの雇用も考えられます。
８ おわりに本稿の内容は、神奈川県の見解でなく、私の知見と記憶に基づくものです。
本稿へのご助言、ご異論、ご感想、ご質問や、今後取り上げるテーマのご要望をくだされば、大変幸いです。特に、ご異論やご助言は、私の考えをブラッシュアップしてくださる、貴重なものです。心より、お待ち申し上げております。

※１）岩崎和隆, “官公庁と DX（８）内製化（改）”,https://www.issj.net/mm/mm16/06/mm1606-gk-gk.pdf 参照 2021-10-20, 情報システム
学会メールマガジン, No.16-06, 連載 発注者からみた官公庁情報システムの現状と課題
第 25 回,2021.

12 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編※２）独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター編, “実務に活かす IT 化の原理原則 17 ヶ条”, https://www.ipa.go.jp/files/000005141.pdf 参照
2021-10-20, 2010, pp.11-12.
※３）澁谷裕以, “アプリケーション・オーナー制度”,
https://www.ipa.go.jp/sec/old/users/seminar/seminar_et2013_20131122a-03.pdf 参照
2021-10-20, 2013.
※４）令和元年 5 月 29 日各府省情報化統括責任者(CIO)連絡会議決定, “情報システムに係る新たな調達・契約方法に関する試行運用のための骨子”,
https://www.kantei.go.jp/jp/singi/it2/cio/kettei/20190529kettei_1.pdf 参照 2021-10-20,2019.
※５）内閣府, “情報システムに係る新たな調達・契約方法（技術的対話）：調達情報”,
https://www.cao.go.jp/chotatsu/mitsumori/taiwa.html 参照 2021-10-20, 2021.
※６）総務省, “情報システムに係る新たな調達・契約方法（技術的対話）”,https://www.soumu.go.jp/menu_sinsei/cyoutatsu/jouhou_system.html 参照 2021-1020, 2021.
※７）金融庁, “情報システムに係る新たな調達・契約方法（技術的対話）”,https://www.fsa.go.jp/common/choutatu/taiwa/index.html 参照 2021-10-20, 2021.
※８）川野辺健志, “自治体におけるパフォーマンスベース契約の枠組みとその実施に関する分析－岐阜県と山梨県甲府市を事例として－”, http://www.pp.u-tokyo.ac.jp/grasppold/courses/2010/documents/graspp2010-5150010-2.pdf 参照 2021-10-20, 東京大学公
共政策大学院リサーチペーパー, 2010, pp.47.
※９）岩崎和隆, “地方の公的機関の情報システム調達実務における供給者評価方法について”, https://www.jstage.jst.go.jp/article/proceedingsissj/8/0/8_d2-1/_pdf/-char/ja 参照
2021-10-20, 情報システム学会第 8 回全国大会・研究発表大会論文集, 2012 年 8 巻
D2-1, 2012.
※10）岩崎和隆, “官公庁の情報システム調達における総合評価落札方式の落札者決定基準の基礎理論”, 情報システム学会第 16 回全国大会・研究発表大会論文集, 2020 年 16 巻
A1, 2020.
13 / 14

第 26 回

情報システム学会 メールマガジン 2021.10.29 No.16-07
連載 発注者からみた官公庁情報システムの現状と課題
官公庁と DX（９）外注におけるプロジェクト成功率向上方法（１）競争的調達編※11）平成 14 年 3 月 29 日情報システムに係る政府調達府省連絡会議了承, “情報システムに係る政府調達制度の見直しについて”,
https://warp.da.ndl.go.jp/info:ndljp/pid/235321/www.soumu.go.jp/gyoukan/kanri/0303
29_1.html 参照 2021-10-20, 2002.
※12）平成 25 年 7 月 19 日調達関係省庁申合せ, “情報システムの調達に係る総合評価落札方式の標準ガイドライン”,
https://www.kantei.go.jp/jp/kanbou/27tyoutatu/huzokusiryou/h2_5.pdf 参照 2021-1020, 2013.
※13）岩崎和隆, “落札者決定基準におけるパッケージソフトウェアの品質評価試案”,
https://www.issj.net/mm/mm14/11/mm1411-gk-gk.pdf 参照 2021-10-20, 情報システム
学会メールマガジン, No.14-11, 連載 発注者からみた官公庁情報システムの現状と課題
第 6 回,2020.
※14）岩崎和隆, “官公庁の情報システム取得時の総合評価落札方式における供給者のプロ
ジェクト遂行能力評価の取扱い”,
https://www.jstage.jst.go.jp/article/proceedingsissj/13/0/13_c14/_pdf/-char/ja 参照
2021-10-20, 第 13 回全国大会・研究発表大会論文集, 2017 年 13 巻 S1-C.4, 2017,
pp.2.
※15）岩崎和隆, “官公庁の情報システム調達における供給者選定方法の課題”,
https://www.jstage.jst.go.jp/article/proceedingsissj/14/0/14_S1-D3/_pdf/-char/ja 参照
2021-10-20, 第 14 回全国大会・研究発表大会論文集, 2018 年 14 巻 S1-D3, 2018.
※16）井上英明, “京都市がシステム刷新失敗、「悲劇を繰り返すな」とご意見番”,
https://xtech.nikkei.com/it/atcl/watcher/14/334361/120900974/参照 2021-10-20, 日経
クロステック記者の眼, 2017.

14 / 14