4 PBC の定義とモデル 24

平成 19 年度

情報システムの信頼性向上のためのモデル取引・契約普及に関する環境整備事業

「情報システムのパフォーマンスベース契約に関する研究」報告書

平成 20 年 3 月

情報システムのパフォーマンスベース契約に関する研究会

＜目次＞

1 概要 1

1-1 経緯 1

1-2 背景と目的 2

1-3 パフォーマンスベースの価格設定、契約とは 2

1-4 情報システムの価格に関する問題意識 3

1-5 検討対象～価格決定のメカニズムと本検討対象範囲～ 4

2 事例調査 5

2-1 国内先行事例調査 5

2-2 海外事例調査 7

2-3 他産業における類似事例調査 8

2-4 事例調査から得られた示唆 11

3 問題意識調査 18

3-1 調査概要 18

3-2 調査結果（まとめ） 20

3-3 調査結果から得られた示唆 21

4 PBC の定義とモデル 24

4-1 定義 24

4-2 PBC モデルの検討 28

5 まとめ（今後の課題など） 40

（別紙１）事例調査結果詳細 41

１．国内事例調査結果 41

２．海外事例調査結果 53

（別紙２）問題意識調査結果詳細 62

（別紙３）研究会委員名簿 79

1 概要

1-1 経緯

現在、我が国の国民生活および社会経済活動における IT 利用度は、コンピュータの処理性能の飛躍的な向上やインターネットの普及等の結果、かつてないほど高まっている。情報システムの障害等が及ぼす社会的影響は深刻化しており、システムの信頼性・安全性向上は喫緊の課題となっている。

他方、情報システムは企業・組織の経営の根幹に関わり、利用範囲のxx化・多様化が進んだことから、ユーザ・ベンダの間の密接なコミュニケーションを前提とした取引の可視化、役割分担・責任関係の明確化により、ユーザ・ベンダ一体となった情報システムの信頼性・安全性向上の取り組みが必要となってきている。

このようななか、経済産業省では『情報システムの信頼性向上に関するガイドライン』

（平成 18 年 6 月）および『情報サービス・ソフトウェア産業維新』（平成 18 年 9 月）を公表し、契約事項の明確化やユーザ（委託・発注者）・ベンダ（受託者）間の取引関係等の可視化が必要であることを示した。

これら提言を受け、経済産業省では平成 18 年度に「情報システムの信頼性向上のための取引慣行・契約に関する研究会及びタスクフォース」を設置、情報システムの信頼性向上・取引の可視化に向けた取引・契約のあり方の検討を行い、研究会最終報告書として、情報システムにおける開発・保守等の取引に関するユーザ・ベンダ間のモデル取引・契約書（以下「モデル取引・契約書」という）を策定した。モデル取引・契約書のなかに、今後の検討課題として、「パフォーマンスベース契約等の多様な契約のあり方についても検討を行う」と明記されている。

本年度は、“情報システムの信頼性向上のためのモデル取引・契約普及に関する環境整備事業”として、「中小企業ユーザ」「保守・運用サービス」「パフォーマンスベース」「検収フェーズ」の 4 つのテーマについて、モデル取引・契約書の整備等の検討に取り組んできた。本報告書では環境整備事業の一環として、“パフォーマンスベース契約”の検討成果を整理する。

1-2 背景と目的

我が国の情報システム市場は、現在、主として「人月ベース」の価格表示を行っており、それに伴う価格の根拠がユーザ側の価格への不信感につながっていることは従来から多数指摘されている※が、残念ながら、この課題は現在まで業界全体として抜本的に解決されるには至っていない。高い品質や高い効果を創出するシステムを構築できる付加価値の高いベンダがきちんと評価されるような市場構造が確立されなければ、IT サービス産業全体が健全な発展を遂げることができない。また、人月積算を前提とした Fixed Price（固定価格）のみでは、ベンダの品質xxxへのモチベーションは生まれない。さらに、ユーザにとって CEO（Chief Executive Officer：最高経営責任者）を始めとする経営層に説明できない価格では、投資の妥当性を提示できず、投資意欲そのものを減退させてしまう。

※1993 年度の産業構造審議会報告書『ソフトウェア新時代』において「人月は単純な労働量にもとづくプライシングの方法であるために、システムの品質や価値を十分反映することは困難であり、これが主流を占めている限り、市場の健全な成長は望めない」「品質や価値を反映したプライシングの方法を導入する必要がある」という提言がなされている。

また、2006 年度実施された産業構造審議会（情報経済分科会情報サービス・ソフトウェア小委員会）の中間取りまとめにおいても、「情報システムの価値に関する課題（人月工数単価からの脱却）」として、この問題が取り上げられている。

本報告書では、このような背景の理解した上で、IT リスクの軽減、効果創出に資することを目的に「パフォーマンスベース」の契約について事例調査や問題意識調査を行い、定義やモデルなどの検討を行う。

1-3 パフォーマンスベースの価格設定、契約とは

IT サービスにおける「パフォーマンスベースの価格設定、契約」（Performance Based Contracting：以下、「PBC」と呼ぶ）とは、「サービス・システムの対価の一部、または全部について、サービス・システムによって創出されるパフォーマンスにもとづいた価格設定を行うこと」である。

参考：“パフォーマンス基準型契約とは、プロジェクトを遂行していく手法ではなく、成果物、プロジェクト結果として得られる実績に重点を置く調達概念のことである”（『政府 IT 調達におけるインセンティブ付契約の適用に関する調査』平成 16 年 1 月独立行政法人情報処理推進機構より抜粋）

1-4 情報システムの価格に関する問題意識

（1）人月ベースの価格を起因とする問題

「1-2 背景と目的」にも示したとおり、「人月ベースの価格」は、IT サービス産業自体の地位低下と、ユーザの不信・不満の増大および IT 投資意欲の減退を招いている。

（図表 1-1 参照）

図表 1-1 人月ベースの価格を起因とする問題

「人月ベースの価格」

疲弊感の高まり、モチベーション低下

ITサービス産業自体の地位低下

ユーザの不信・不満の増大

・IT投資意欲の減退

⚫価格根拠として人月を提示されても、それが妥当な数

値かどうかが判断できない

⚫IT投資による効果が見えないため、価格に納得感が

持てない

ユーザが抱える問題

⚫高付加価値なアイディア創出のインセンティブが働か

ない（開発効率が上がると売上が減る）

⚫新「３K職場」化

きつい／帰れない／きりがない

⚫学生からも敬遠される

国立大も情報関連学科は定員割れ

IT業界・ベンダが抱える問題

（2）パフォーマンスベースの価格へのシフト

人月ベースから、「パフォーマンスベースの価格設定・契約」へシフトすることは、

IT サービス業界の地位向上と、ユーザの満足へとつながる。（図表 1-2 参照）

図表 1-2 人月ベースの価格を起因とする問題

「パフォーマンスベース」の価格

⚫ベンダがシステム以外についても提供してくれるよう

になるため、効果創出の可能性が高くなる

⚫価格根拠に説得性が生まれる

⚫IT投資に対するユーザの経営層の同意が得られや

すくなる

ユーザのメリット

⚫xxを使えば使うほど、たくさんおカネがもらえること

になる

⚫真の意味でユーザが求めるシステム－つまり、ユーザ

の売上や利益の増大、コストの削減のためのより良いシステム、サービスの提供が可能となる

⚫「労働集約型産業」から「知識集約型産業」へ脱却

IT業界・ベンダのメリット

やりがいがある職種

ITサービス産業の地位向上

ユーザの満足・信頼の醸成

1-5 検討対象～価格決定のメカニズムと本検討対象範囲～

情報システムの価格、見積、投資評価の関係を整理すると、xxxが見積を行い、ユーザが投資評価を行い、その両方の判断基準をベースに双方で合意する金額が「価格」になる。（図表 1-3 参照）

図表 1-3 価格決定のメカニズムと本検討対象範囲

投資評価

ベンダユーザ

見積

価格

ベンダ・ユーザ両方で合意

実際には、ベンダはユーザから提示される RFP（Request For Proposal）をもとに原価見積を行い、それに利益等を加えて、正式見積としてユーザに提示する。ユーザはシステム構想書やシステム企画書、要件定義書等をもとに、当該システムの投資評価を算定して、投資額の設定を行う。ユーザはベンダから提示される正式見積と自らが設定した投資額を比較し、必要に応じてベンダと内容の精査、金額等の交渉を行った上で、ベンダ・ユーザで合意した金額が当該システムの価格になる。本検討ではベンダにおける見積やユーザにおける投資評価ではなく、「価格」設定を対象範囲とする。（図表 1-4 参照）

図表 1-4 価格決定プロセスと本検討対象範囲

ベンダユーザ

RFP

Request For Proposal

システム構想書

RFP作成

原価見積

システム投資評価

投資額の設定

正式見積

（原価＋利益等）

見積提示投資額

価格決定

合意

金額等の交渉

内容の精査

本検討対象範囲

2 事例調査

国内外の情報システムのパフォーマンスベース契約について先進事例を調査するとともに、他産業における類似の契約事例の調査を行った。

国内外の情報システムの先進事例の調査結果の詳細は別紙 1 に付す。

2-1 国内先行事例調査

サービス提供形態として、システム開発/IT アウトソーシング、SaaS（Software as a Service）/ASP（Application Service Provider）、BPO（Business Process Outsourcing）別に、公知情報をもとに国内の先行事例調査を行った。それぞれの事例が採用している支払形態について、従来の定額固定契約に加え、パフォーマンスベース契約で想定される支払形態として従量課金契約、成果報酬契約の 3 つのカテゴリに分類した。

※SaaS とASP について

SaaS は ASP と類似の概念であり、その定義や相違点については様々な整理がなされつつあるが、本報告書では情報システムのサービス提供形態としては同義とみなし、「SaaS/ASP」の記述で統一することとする。

公表されている事例はそれほど多くないものの、システム運用、SaaS/ASP、BPO それぞれの PBC 事例が存在することが確認できた。システム開発の PBC 事例はほとんどなく、主にシステム運用の SLA（Service Level Agreement）をもとにインセンティブ（ペナルティ）を付ける形の PBC が多い。また、BPO については、特定の案件やユーザの事例ではなく、SaaS/ASP のように、ベンダが広く提案、提供しているアウトソーシングサービスに PBC の価格設定を取り入れている事例である。（図表 2-1 参照）

図表 2-1 国内先行事例調査結果一覧

サービス提供形態

事例

契約

形態

システム／

サービス名

ユーザ企業

ベンダ企業

概要

定額

固定

従量

課金

成果

報酬

①

システム開発/ITアウトソーシング

システム運用 SLA

ＪＡＬ

日本IBM

ＪＡＬの、運行系・予約発券等の業務に大きな影響を及ぼす30のシステムに対する運用委託サービス

2005年に、ペナルティなし→ペナルティ付きSLA（事前に設定したダウンタイムを超えた場合、委託料金から一定額を差し引く）に変更した

導入後、システム停止件数が半減

○

②

システム運用 SLA

リクルート

アークシステム、

シーエーシー

リクルート社内システム運用委託サービス要員数×要員単価

⇒業務量×必要スキル×システムの重要度（CLA）で算出されるポイントを基に委託費を決定

今後、CLA削減が実現できたら効果の50%をベンダーへ還元する計画

○

③

システム運用 SLA

岐阜県

ＮＴＴコミュニケーションズ

県に現存するすべての情報システムの開発・運用委託サービス

行政の情報システムの再開発で66億円、運営経費を7年間で35億円節減の成果を期待している

未達成項目の点数に応じたペナルティ付きSLAを情報システム分野で43項目設定している

①未達成項目があった場合：県が事業者に改善計画書を提出し、改善計画を実施

②未達成項目の点数合計が25点以上であった場合：当該年度支払限度額の 100分の１に相当する違約金を徴収

③直近三年度分の未達成項目の点数が累計で60点以の場合：県は契約の一部又は全部の解除

○

④

SNSサービス導入支援

SNSのビジネ

ス企画を持つ企業

キールネットワーク

ス

ソフト込みのＳＮＳサーバを無料導入し、売上の一定割合を得る SNSを導入する顧客側のイニシャルコストはほぼゼロ

○

⑤

SaaS/ASP

たのめーるプラス

一般企業

xx商会

企業用購買システム「たのめーるプラス」

取引量に応じた従量課金（初期導入コスト不要） 06年12月末で243社のユーザー企業獲得

○

⑥

フーズ

インフォマート

外食産業（売り手／買い手）

インフォマート

フード業界における、企業間の日々の受発注業務、伝票処理等の受発注業務を ASPで提供

支払形態は、

買い手企業：金額固定（8000円～／月）

売り手企業：金額固定（25000円／月）または従量課金（売上額の1％）

○

⑦

ジェネリック通知サービス

医療保険者

（健保組合など）

ＮＴＴデータ

ジェネリック医薬品促進通知書提供サービス

医療保険者（健保組合など）が持つレセプトデータを分析し、ジェネリック医薬品処方による薬剤費削減額及び薬品名を知らせる通知書を発行し、被保険者に情報提供する

契約形態としては、以下の２パターンを用意している

・削減された薬剤費の50%をＮＴＴデータに支払う成果報酬契約

・レセプト1件あたり50円（従量課金）

○

⑧

レコメンドサービス

WEBショッピングサイト業者

シルバーエッグ・

テクノロジー

リコメンド（推奨）ソフトをASP方式で提供

料金は、推薦の結果生じた売上の５～１０％を徴収する成果報酬型の設定（初期費用は不要）

○

⑨

BPO

イーサポートリンクシステム

青果物生産者、流通業者、小売店

イーサポートリンク

XML-EDIによる青果物受発注システム

ASPサービスに加え、販売店と小売店の需給調整等のBPOサービスも提供 ASPの支払形態：システム上の処理件数及び顧客の取扱高に応じた従量課金 BPOの支払形態：取扱事務の作業量と顧客の取扱高に応じた従量課金

○

⑩

BPS

一般企業

日本IBM

以下の5つのメニューについて、ASP型アウトソーシングサービスを用意

（１）購買（２）人材育成（３）文書管理（４）人事（５）売掛債権回収

（１）～（４）については、対象とする規模をベースとした従量課金

（５）については、成果報酬契約を採用している

過去のノウハウを元に業務プロセスを標準化、2～5ヶ月で導入可能

○

➃

コクヨBPO

一般企業

コクヨビジネス

サービス

人事・総務・経理等バックオフィス系のBPO

顧客業務及び人員を一括して請け負うサービス

価格は、事前に取り決めた額を固定で支払う方式と、効率化で得られた利益を分配する方式を用意

○

2-2 海外事例調査

国内事例調査と同じく、3 種類のサービス提供形態別に、公知情報をもとに海外の先行事例調査を行った。

国内事例調査結果に比し、海外事例ではシステム開発の事例や特定ユーザの BPO 事例などが存在するのが大きな相違点である。また、個々の事例をみると、ユーザとベンダの強力なパートナーシップの上に PBC が成り立っているケースが多く、契約期間も長期にわたっている。（図表 2-2 参照）

図表 2-2 海外事例調査結果一覧

サービス提供形態

事例

契約

形態

システム／

サービス名

ユーザ企業

ベンダ企業

概要

定額

固定

従量

課金

成果

報酬

①

システム開発/ITアウトソーシング

ネットワークインフラ構築・運用

コネティカットコンベンションセンター（CCC）

トータルコミュニケーションズ

構築費用としては支払わず（ベンダ負担）、イベント等で得られたコンベンションセンターの収入に対して一定の割合をベンダに支払う「総収入分配契約」を締結

総収入分配契約により、CCCは30万ドルのコストを削減できたと評価 SLAによるペナルティ／インセンティブを含んだ契約かどうかは不明

○

②

ITサービスセンター運営 SLA

保健社会福祉省（HHS）

（米）ユニシス

9つのSLAを設定し、達成状況に応じてボーナス／ペナルティが設定

（改善例）システムの問題発生からユーザへの初回連絡時間について、契約前の ITサービスセンターで実施できた改善は22%程度だったが、ユニシスはリモート管理装置を導入することにより94%改善

○

③

基幹系システム構築SLA

バンガードカーレンタル

ペローシステムズ

SLAを元に、その達成／未達成がバンガード社のビジネスにどのようなインパクトを与えるかを試算し、試算結果からインセンティブ／ペナルティ額を設定

（SLAの例）ヘルプデスクサービスにおいて、通常の問い合わせに対して4h以内に解決する ⇒（実績）平均3h以内での解決を達成

○

④

ネットワークインフラ構築

米国運輸保安局（TSA）

（米）ユニシス

2002年11月19日までに、本部と国内の429空港等を結ぶネットワークインフラの構築

2002年12月31日までに、国内の空港間を高速のインフラで接続し、電子監視装置を導入、エアポート・コマンドセンター、国土安全保障省のアプリケーションとの統合、地上移動無線の相互連携等の実現

2006年初めまでで、支払は8億3400万ドルを超過（最大で10億ドル支払の契約）

○

⑤

既存税金システム更改

アリゾナ州税務局（AZDOR）

（米）アクセンチュア

老朽化した既存の税金システムの更改

初期投資コストはベンダの負担とし、歳入の増加分を発注者とベンダでシェアするスキームを採用

ベンダは、自社が費やしたコスト分が還元されるまでは、歳入の増加分の85％を受け取る

システムの近代化に伴う徴税率のxxxにより、当初は10年間で4億円の歳入増が期待されていたが、最終的な歳入増は当初計画を上回る見込み

○

⑥

SaaS/ASP

オンデマンド型の保険アプリケーション

カナダ生命

（米）IBM

アプリケーションで処理された保険証の数に基づいた契約保険への新規加入者に応じてIBMへの支払いが決定する

「カナダ生命から要求されたアプリケーションの変更要求に対して、一定期間内に実装を行う」というSLA項目を含む

○

⑦

BPO

人事管理BPO

ブリティッシュテレコム（BT）

（米）アクセンチュア

2000年～2004年までの間は、サービスの利用量に関わらず一定の金額を支払う契約であったが、2005年に10年間でコストを34%削減する目標を立て、業務量、あるいは利用量に応じた新契約に変更

SLAの達成状況に応じたペナルティ／インセンティブ契約（未達成の場合はペナルティに加えて改善措置を要求）

効果測定に対する両社の負担を軽減するために、パフォーマンスの測定は190のサービスのうち費用の80%を占める30項目のみ

○

⑧

罰金徴収センター業務BPO

ミズーリ州立裁判所

アフィリエイトコンピュータサービス（ACS）

徴収できた額の大きさに関係なく、1件の徴収成功ごとに6.95ドルを支払う契約である

処理件数の増加は主に対象裁判所の拡大によるものであるが、それに加え、罰金支払のオンライン化が 2～3%程度の回収率改善につながっていると想定している

本サービスにより、ACSはミズーリ州に約200万ドルの価値を生み出した

○

⑨

電子政府ポータルサイト運営 BPO

テキサス州情報リソース局

（米）ベリングポイント

州政府および地方の政府機関による市民に対するオンラインサービス提供のための電子政府ポータルサイトであるTexasOnlineの開発、運用、メンテナンス

税収からの支出は行わず、データ販売、およびサブスクリプション・フィーまたはコンビニエンス・フィーの徴集を許可するハイブリッドモデルを採用

ベンダは損益分岐点に達するまではポータルの収益の90％、到達以降は50％を獲得、2005年には損益分岐点に到達

○

2-3 他産業における類似事例調査

PRM（Performance Reference Model）ベースでの KPI（Key Performance Indicator）の分類（アウトカム型、アウトプット型、インプット型）別に、公知情報をもとに IT サービス産業以外の類似事例調査を行った。（分類については 4 章図表 4-4 を参照）

他産業においてもパフォーマンスをもとに価格が決定する事例は多く、パフォーマンスを何で測るかはその事業、サービスによって多種多様であるが、総じてユーザ、サプライヤ双方からみて分かりやすい指標になっている。

ッ

図表 2-3 他産業における類似事例調査結果一覧

KPI 分類	事例				支払形態
KPI 分類	サービス／業務内容	サービス利用者	サービス提供者	詳細	定額固定	従量課金	成果報酬
アウトカム型	卸売	卸業者	小売店	同一商品に対する仕入量（＝売上）を増やした場合に仕入れ単価を下げる			○
	クレジットカード	カード加盟店	クレジットカード会社	クレジットカード利用による売上に対して3%の手数料をカード会社に支払う			○
	ネット広告（成功報酬型）	企業	ネット広告会社（楽天等）	・成功報酬型広告（バナー経由で広告先のサイトで購入したら売上の一定割合を支払う）・アフィリエイト（商品を紹介したHPのリンクから購入したら、売上の一定割合を支払う）			○
	Edy販売支援	Edy 加盟店	Edy運営団体（ビットワレット）	各Edy加盟店の目的に合わせた特典をEdy会員向けに実施し、それによる購買活動の効果に応じてEdy加盟店が費用を支払う			○
	メンタル強化コンサル	企業	講師、コンサルタント	社員のメンタル強化により会社利益が上がった場合、その利益と介入対象、介入回数、介入効果などによって成果報酬額を相談し支払う			○
	会計士	企業	会計士	経費削減額の5%～20%を成果報酬として支払う			○
	経営コンサル	企業	経営コンサルタント	成長企業に対し、資金融資＋コンサルタントの派遣を行い、対価の一部を新株予約権（ストックオプション）で支払う（固定＋インセンティブ）			○
	弁護士	個人、企業	弁護士	固定（実費など）＋裁判でのxx（xx内容）による成果報酬契約を実施している			○
	税理士	企業	税理士	節税効果の10～20%を成果報酬として支払う（着手金＋成果報酬）			○
アウトプト型	SEO （検索エンジン最適化）	ネット販売業者等	SEO会社（SEOコンサルティング）	SEO（Search Engine Optimization）により検索エンジンで事前に設定された順位が達成された場合に報酬が支払われる（上位○位にヒットするようになったら△△万円というような）契約を締結する（初期設定費用＋成果報酬）			○
	探偵	個人	探偵・興信所	調査料金（実費レベル）＋成功報酬というタイプが多い			○
	教育サービス	個人	教育サービス提供者（ニュートン）	成果が出ない、サービス内容に満足できなかったら（例：必ずTOEIC750点以上になれる）支払ったお金の全額あるいは一部を返却する			○
	携帯代理販売	携帯キャリア	代理店	1台売るごとに数万円のインセンティブ（販売奨励金）がキャリアから代理店に支払われる		○
	人材派遣	企業	人材派遣（インテリジェンス等）	転職1人あたり、転職者年収の20～30%が人材派遣会社に支払われる		○
	人材派遣	企業	人材派遣（インテリジェンス等）	求人情報を掲載し、求職者から応募メールが届いた場合、その応募内容を確認し、その求職者と連絡を取りたいと判断をしたら料金を支払う（課金体系は月額での請求）		○
	ネット広告（クリック保障型）	企業	ネット広告会社（Google等）	・クリック保障型（バナーのクリック数に応じた報酬）・運営するポータルサイトに求人情報を無料で掲載し、求職者が広告主にメールを送った場合にのみ報酬（5250円/件）を受け取る。広告掲載や広告内容の制作の費用は無料		○
インプット型	証券取引	個人、企業	証券会社（カブドットコム）	・xx注文の場合、売り買いとも実際の約定価格と受注を確認した当該注文受注時刻＋1分後の最初の値段との差額を値合金保証・指値注文の場合（当該注文受注時刻に執行されたとして約定成立していたと見なされる場合）、即時約定の上、約定価格と成立していた値段との差額を値合金保証	○
	通信ネットワーク	企業	プロバイダー（NTT東日本、 OCN等）	故障回復時間、遅延時間、稼働率等のSLAを設定し、守れなかった場合にペナルティとして料金の一部又は全部を返金する	○
	ネットセキュリティ	個人、企業	プロバイダー（トレンドマイクロ）	パターンファイルまたはプログラムツールを２時間以内に提供できなかった際は、ウイルス検体提出1件につき、１２万円の契約違反金を返金する	○
	ソフトウェア翻訳	企業	翻訳会社（E-C Translation）	納品遅延の場合、無償となる品質基準に問題がある場合、違約金として1%違約金として返金。ただし、問題がない場合、1%を報奨金として上乗せ	○
	宅配ピザ	個人	宅配ピザ会社（ドミノピザ）	配達時間に関するSLA（注文～配達完了を30分以内に実施）を設定し、守れなかった場合はペナルティとして割引（ピザ1枚につき700円を返金）を行う。 ※1985年頃から上記サービスが提供されてきたが、その後配達員の無理な運転による交通事故の可能性、住宅事情の変化から30分以内に配達できない実例などが増加してきたことなどから、現在は実施されていない	○

他産業における類似事例調査結果から得られた示唆を以下に示す。

（1）KPI に関する考察

PRM の各軸における KPI を整理したところ、一般的にアウトカム型では利益増大、コスト削減、満足度、アウトプット型ではプロセス品質、量、インプット型ではプロダクト品質、性能を KPI としていることがわかった。

図表 2-4 他産業類似事例における KPI 整理

分類

KPI

事例

アウトカム型

利益増大（売上・利益）

コストダウン

満足度（裁判結果）

卸売・クレジットカード・ネット広告（成功報酬型）・Edy 販売

会計士・税理士

弁護士

アウトプット型

量(販売量等)

プロセス品質（検索順位、

TOEIC 点数、証拠有無）

携帯電話代理販売・人材派遣・クリック保証型ネット広告

SEO（Search Engine Optimization：検索

エンジン最適化）・探偵・教育サービス

インプット型

プロダクト品質

性能

ネットセキュリティ・ソフトウェア翻訳

証券取引・通信ネットワーク・宅配ピザ

（2）価格構造に関する考察

他産業における類似事例では、価格構造と KPI の達成度に対する価格への反映方法によって 4 つの支払形態に分類される。

1）価格構造による分類

価格構造は「固定＋インセンティブ」と「完全な成果連動」に分類される。

「固定＋インセンティブ」では、成果に関わらず、ある一定金額が固定で積算された上で、KPI の達成度に応じたインセンティブが上乗せ（またはディスインセンティブによる返還）される。人的な作業を要するなど、固定費用が発生する原価構造の場合に適したプライシングといえる。

「完全な成果連動」では、固定額の積算はなく、価格の積み上げは KPI の達成度に応じたインセンティブのみとなる。一度作った仕組みを提供するなど、固定費用が発生しない原価構造の場合に適したプライシングといえる。

2）価格への反映方法による分類

KPI の達成度に対する価格への反映方法は「線形的反映」と「段階的反映」に分類される。

「線形的反映」では、KPI と価格が線形的な関係となる。利益増大やコスト削減のように KPI1 単位の上昇に対する価値上昇が正比例の関係の場合に採用される。

「段階的反映」では、KPI がある一定の値を超えた時点で価格が上昇する。裁判の判決のようにある一定の成果や値を超えないと価値が認められないサービスの場合に採用される。

価格

図表 2-5 PBC 事例における価格構造と価格への反映方法の分類

固定＋インセンティブ

完全な成果連動

（インセンティブ）

（固定）

（インセンティブ）

線形的反映

KPI KPI

･ 経営コンサル

･ 税理士

･ ネットセキュリティ

･ ソフトウェア翻訳

･卸売･ 携帯代理販売

･ クレジットカード ･ 人材派遣

･ ネット広告 ･ （会計士）

･ Edy販売支援･ （メンタル強化コンサル）


	（インセンティブ）
（固定）

（インセンティブ）

段階的反映

価格

KPI KPI

･弁護士･通信ネットワーク

･ SEO ･ 宅配ピザ

･探偵

･ 証券取引

･ 教育サービス

2-4 事例調査から得られた示唆

国内外の情報システムの PBC 事例、および他産業の類似事例の調査結果から、（1）サービス提供形態、（2）価格構造、（3）価格への反映方法、（4）KPI の設定、（5）リスクヘッジの観点での示唆が得られた。

（1）サービス提供形態

PBC と親和性が高いサービス提供形態は、ユーザ事業に直結したサービスである BPO や一部の SaaS/ASP、および SLA 等による固定＋インセンティブ（ペナルティ）契約のシステム開発/IT アウトソーシングが考えられる。（図表 2-6 参照）

1）BPO

現状の BPO では定額固定契約の適用事例が多いが、事業や業務に対するベンダ側の関与度が大きいというビジネスモデルの特徴からも、成果報酬との親和性が高いといえる。海外の事例にもあるように、今後は成果報酬ベースの契約事例が増加するものと想定される。

2）SaaS/ASP

必要な時に使用した分だけ払うという SaaS/ASP のビジネスモデルの特徴から、従量課金の適用事例が多い。特に提供するサービスが顧客の事業に直結するケースでは、成果報酬との親和性も高くなるものといえる。

3）システム開発／IT アウトソーシング

システム開発のみではユーザの事業や業務の成果に結びつけるのは難しいが、システム運用等での SLA によるインセンティブ（ペナルティ）契約の事例がある。このように運用業務までを含めた契約を行うケースでは、固定＋インセンティブ（ペナルティ）方式の親和性が高いといえるのではないか。

凡例：国内事例 PBCとの親和性

海外事例が高いゾーン

ミズーリ州

コクヨBPO

一般的な

BPO事例 BT

テキサス州

IBM BPS

ジェネリック通知サービス

レコメンドサービス

JAL

一般的なシステム開発/

ITアウトソーシング事例

CCC

保健社会福祉省

エアポートセキュリティ

バンガードカーレンタルアリゾナ州

定額固定

従量課金

成果報酬

一般的な

SaaS/ASP事例

システム開発／

アウトソーシング

サービス提供形態

BPO

SaaS/ASP

図表 2-6 PBC と IT サービス産業のサービス提供形態における親和性

プライシング／支払形態

凡例：

国内事例

海外事例

PBCとの親和性が高いゾーン

（2）価格構造

他産業の調査結果より、価格構造は「固定＋インセンティブ」と「完全な成果連動」の 2 タイプに分かれることが分かった。IT サービス産業では、前者は BPO、IT アウトソーシングが、後者はSaaS/ASP のサービス提供形態が適合しやすいと想定される。

（図表 2-7 参照）

図表 2-7 価格構造の示唆

他産業調査結果から得られた示唆 ITサービス産業への適用

（インセンティブ）

（固定）

価格

特徴事例特徴サービス提供形態との適合

（インセンティブ）

完全な成果連動

固定＋インセンティブ

価格

KPI

⮚費用構造：

サービスごとに（付加価値の高い作業による）人的費用が発生する

⮚顧客との関係：

1対1のビジネス

⮚費用構造：

サービスごとに人的費用が発生しない（人的費用が発生したとしても付加価値の低い作業である）

⮚顧客との関係：

1対多のビジネス

・弁護士

・税理士

・経営コンサル

・探偵

・XXX

・クレジットカード

・ネット広告

・人材派遣

・教育サービス

⮚顧客ニーズ：

既存サービスでは解決できない要件に特化したニーズであり、1対1のビジネスである

⮚コスト構造：

サービス提供単位に開発・運用等の人件費が発生する

※アメリカでは、固定に対するインセンティブの割合は通常10～20%程度

⮚顧客ニーズ：

不特定多数の共通的なニーズに応えるような1対多のビジネスである

⮚コスト構造：

サービス提供単位に開発・運用等の人件費が発生しない（開発費用等は共通的な投資のみ）

※ただし、特殊な背景（例：新規事業等、共同出資事業、顧客側に予算がない場合）が存在する場合、1対1、サービス提供単位で人件費が発生するビジネスでも当該価格構造になる場合はある

・BPO

・システム開発/

ITアウトソーシング

・SaaS/ASP

（特殊な背景がある場合）

・BPO

（3）価格への反映方法

得られた価値の価格への反映方法には「線形的反映」と「段階的反映」の 2 タイプがあり、どちらの構造になるかは設定する KPI により判断される。IT サービス産業では、前者は BPO、SaaS/ASP が、後者はシステム開発／IT アウトソーシングが適合しやすいと想定される。（図表 2-8 参照）

図表 2-8 価格への反映方法の示唆

他産業調査結果から得られた示唆 ITサービス産業への適用

特徴事例特徴サービス提供形態との適合

（線形的）

線形的反映

価格

⮚利益や売上等のアウトカム型のKPIまたは、 (達成度合いが線形的に測れる）量等のアウトプット型のKPIが設定される

・税理士

・経営コンサル

・クレジットカード

・ネット広告

・人材派遣

⮚売上やコスト削減などのアウトカム型のKPIや、量などのアウトプット型のKPIで、測定は比較的明瞭である

・BPO

・SaaS/ASP

KPI

（段階的）

段階的反映

価格

⮚品質保証等のインプット型やアウトプット型の KPIまたは、（勝ち負け、合否等の）成果が0か1かで表れるKPIが設定される

・弁護士

・探偵

・XXX

・教育サービス

⮚金銭的な価値への直接的な置換えは困難で、システム運用 SLA等、システム品質を測定するインプット型のKPIか、プロセス等を測定するアウトプット型のKPIを使用する

・システム開発/ ＩＴアウトソーシング

KPI

（4）KPI の設定

KPI は成果を価値に置き換える指標であり、ユーザ側からの納得感を得ることが重要である。インプット、アウトカムの指標は測定が比較的行いやすく、指標としても分かりやすいため、多くの事例が存在する。また、アウトプットの指標においてもアウトカムに近い KPI が設定されている事例が多い。（図表 2-9 参照）

図表 2-9 事例調査結果の KPI 整理と得られた示唆

KPI 事例

事例からの示唆

アウトプット型

アウトカム型

量（罰金徴収件数、契約者数、業務量、使用量）

インプット型

スピード（リードタイム）

システム品質（システム停止件数、故障復旧時間等）

アウトカム型のKPIは、利益増大、コスト削減等、KPI自体が事業目標とほぼイコールとなることから、ユーザ側からは納得感が得られやすいと想定される

バンガードカーレンタル、保健社会福祉省

ミズーリ州、カナダ生命、ジェネリック、BT、IBM BPS

JAL、保健社会福祉省

従業員満足

コスト削減

利益増大

CCC、テキサス州、アリゾナ州、レコメンドサービス、コクヨBPO、ジェネ

リック、BT、IBM BPS

以下の場合、アウトプット型のKPIでも一部合意が得られる可能性がある

⮚アウトカムのKPIとの相関が明確

（徴収件数、契約者数）

⮚KPIの計測が容易（業務量、使用量、徴収件数、契約者数）

⮚ユーザ視点とベンダ視点のKPIが

近い（業務量、使用量）

バンガードカーレンタルでは、ユーザ側でSLAの達成／未達成がビジネスに与えるインパクトについて詳細なシュミレーションを立てた

⇒本事例はユーザ側が先進的に取り組んだレアな事例と言える

システム運用委託契約において有効なKPIとなる

※PRM（Performance Reference Model：業績測定参照モデル）をベースにしたフレームワーク

（5）リスクヘッジ

PBC を適用することにより、少なからずユーザあるいはベンダの事業リスクが増すことが想定される。例えば、成果報酬型の契約であれば、成果がでなければベンダは収入がなくなる（少なくなる）という事業リスクがあり、いわゆる固定価格に比し、リスクが増大していることになる。PBC の適用によるリスクの増加をどのように減らすことが可能か、事例をもとに整理した。

1）事例におけるリスクヘッジ方法の整理

国内、海外の各事例において実践しているリスクヘッジ方法を整理した。

詳細

要素

リスクヘッジ方法

顧客名／サービス名

提供形態

SaaS/ASP

BPO

図表 2-10 事例で実践されているリスクヘッジ方法

提供形態

顧客名／サービス名

リスクヘッジ方法

要素

詳細

IBM BPS

・ユーザ数

・ノウハウ

◼総売上＝Σ（成果×成果単位の価格）と考えると、ユーザ数が増えることで成果のブレは均等化され、特殊要因による売上減のリスクを低減させる

◼ワールドワイドで培ったノウハウを流用することで成功確率を高める

コクヨBPO

・関与度

◼アウトソーシング契約を結ぶことにより、高い裁量の元、主体的に活動することが可能

（業務と人を一括して請け負う）

・期間

・関与度

◼長期契約とすることにより、突発要因や想定外の要因による未達成のリスクを低減させる

◼アウトソーシング契約を結ぶことにより、高い裁量の元、主体的に活動することが可能

ミズーリ州

・期間

・関与度

・契約の柔軟性

◼長期契約とすることにより、突発要因や想定外の要因による未達成のリスクを低減させる

◼アウトソーシング契約を結ぶことにより、高い裁量の元、主体的に活動することが可能

◼契約期間の一部をオプションとすることで、想定外の事象等による大幅な損失の発生を防ぐ

テキサス州

・プライシング

・契約の柔軟性

◼収入分配契約において、損益分岐点に到達するまではベンダ側の配分割合を高める

◼契約期間の一部をオプションとすることで、想定外の事象等による大幅な損失の発生を防ぐ

ジェネリック

・ユーザ数

◼総売上＝Σ（成果×成果単位の価格）と考えると、ユーザ数が増えることで成果のブレは均等化され、特殊要因による売上減のリスクを低減させる

レコメンドサービス

・ユーザ数

◼総売上＝Σ（成果×成果単位の価格）と考えると、ユーザ数が増えることで成果のブレは均等化され、特殊要因による売上減のリスクを低減させる

システム開発

アウトソーシング

CCC

・期間

・関与度

◼（想定）長期契約とすることにより、突発要因や想定外の要因による未達成のリスクを低減させる

◼アウトソーシング契約を結ぶことにより、高い裁量の元、主体的に活動することが可能

保健社会福祉省

・プライシング

・契約の柔軟性

◼固定＋インセンティブ／ペナルティ契約

◼契約期間の一部をオプションとすることで、想定外の事象等による大幅な損失の発生を防ぐ

バンガードカーレンタル

・プライシング

・期間

◼固定＋インセンティブ／ペナルティ契約

◼長期契約とすることにより、突発要因や想定外の要因による未達成のリスクを低減させる

◼年間一定量の発注を保証

エアポートセキュリティ

・プライシング

・契約の柔軟性

◼固定、コストプラス、インセンティブの複数のプライシングを組み合わせた契約

◼契約期間の一部をオプションとすることで、想定外の事象等による大幅な損失の発生を防ぐ

アリゾナ州

・プライシング

・期間

◼収入分配契約において、損益分岐点に到達するまではベンダ側の配分割合を高める

◼長期契約とすることにより、突発要因や想定外の要因による未達成のリスクを低減させる

2）リスクヘッジ要素の整理

1)で整理した事例から、PBC の実現に必要となる主なリスクヘッジ要素を整理した。 BPO では関与度、期間等、 SaaS/ASP ではユーザ数、システム開発/IT アウトソーシングではプライシング、契約の柔軟性等の要素でリスクヘッジが可能と考えられる。

（図表 2-11 参照）

図表 2-11 PBC 適用におけるリスクヘッジ要素

主な

リスクヘッジ要素

概要使用の可能性が高い

サービス提供形態

関与度期間

裁量を高め、事業に対するイニシアティブを取ることでベンダ側でコントロールできる範囲を広げる

長期契約にすることで、成果が出るまでの期間を確保し、導入効果を出しやすくする

BPO

BPO、

システム開発/

ITアウトソーシング

ノウハウ高いノウハウ、他プロジェクトでの成功実績を持つ業務に絞ってサービス提供択することで、成果が出る可能性を高める

BPO

契約の柔軟性

契約途中での契約見直しを行うことにより、外部環境等の実施中の変動要素に対するリスクを低減する

BPO、

システム開発/

ITアウトソーシング

ユーザ数

母数を増やすことで、（コントロールできない）外部環境等により発生する1ユーザごとの売上のバラツキを均等化する

SaaS/ASP

プライシング

固定＋インセンティブによる固定収入の確保や、原価回収するまでは成果報酬における受け取り割合を高める等、プライシングの工夫により原価相当部分の回収リスクを低減させる

BPO、

システム開発/

ITアウトソーシング

3 問題意識調査

情報システムの価格について、ユーザおよびベンダがどの程度問題意識を持っているか、および PBC の可能性等について調査を行った。

3-1 調査概要

情報システムのユーザ、ベンダ企業双方に、情報システムの価格の問題点および PBCの実現性をインタビューするとともに、ユーザ企業にはシステム開発調達や保守・運用時の QCD（Q：Quality（品質）、C：Cost（費用）、D：Delivery（納期））の評価の実態、ベンダ企業には価格の課題に関する取組み状況をあわせて調査した。

（1）ユーザ企業向け調査

1）調査趣旨

ユーザが情報システムの価格の現状について、どの程度問題意識を持っているか、ベンダのパフォーマンスを現在どのように評価しているかを把握する。

2）インタビュー先企業

JUAS（社団法人日本情報システム・ユーザー協会）会員企業 3 社

3）インタビュー項目

• 情報システムの価格に関する問題意識

– 自社で懸案となっている情報システムの価格に関する問題点

– 従来型（人月価格ベース）の見積や価格交渉に対する問題意識

– 従来方式の契約についての不満

• 自社におけるシステム開発調達時・保守運用時の QCD 評価の実態

– システム調達および保守運用における QCD の評価の取組み、評価項目

– 自社の業界、あるいは自社としての情報システムの価格、品質の標準の有無

– 開発完了時および一定期間の運用後のベンダへのインセンティブ（追加費用）支払実績の有無

– 自社におけるパフォーマンスベース契約の実績

• パフォーマンスベース契約の実現性

– パフォーマンスベース契約実施の背景や定義・分類の妥当性

– パフォーマンスベース契約の適用可能範囲

– パフォーマンスベース契約が実現した際のメリットや課題

（2）ベンダ企業向け調査

1）調査趣旨

ベンダが情報システムの価格の現状について、どの程度問題意識を持っているか、どのような対策を講じているかを把握する。

2）インタビュー先企業

JEITA（社団法人電子情報技術産業協会）会員企業 2 社

JISA（社団法人情報サービス産業協会）会員企業 2 社

3）インタビュー項目

• 情報システムの価格に関する問題意識

– 自社で懸案となっている情報システムの価格に関する問題点

– 従来型（人月価格ベース）の見積や価格交渉に対する問題意識

• 自社における価格の課題に関する取組み状況

– 見積や価格交渉における改善策

– 自社におけるパフォーマンスベース契約の実績

• パフォーマンスベース契約の実現性

– パフォーマンスベース契約実施の背景や定義・分類の妥当性

– パフォーマンスベース契約の適用可能範囲

– パフォーマンスベース契約が実現した際のメリットや課題

– パフォーマンスベース契約実施にあたって必要となる環境整備

3-2 調査結果（まとめ）

ユーザおよびベンダ企業への調査結果の詳細を別紙２に整理する。また、調査結果のまとめをユーザ、ベンダ毎に整理した表を以下に示す。（図表 3-1 参照）

情報システムの価格に関する課題の認識については、企業により多少の意見の違いはあるが、システム開発の QCD や運用の SLA、あるいは IT 投資効果を情報システムの価格に反映するという取組みはユーザ、ベンダともに検討しつつある。PBC の適用可能性については、時期尚早という意見と実際に行った経験もあり可能であるという意見があるが、総じてその効果については肯定的な意見が多い。

図表 3-1 ユーザ企業およびベンダ企業への調査結果まとめ

項目

ユーザ企業およびベンダ企業の認識

ユーザ企業

ベンダ企業

情報システムの価格・見積・契約における課題

• パッケージ以外の価格に対する納得感が少ない等、ソフトウェアの付加価値を（特に経営層からの視点で）評価する方法論が未確立である

• アウトカムから、システムにおける KPI および価格が算出されるのが本来あるべき姿だという意見と、人月価格にエンジニアの業務知識や開発経験が反映されない現状が問題だという意見

があった

• ユーザ側のIT に対しての理解度が高い場合や、見積を適用するプロセスによっては、人月ベースの価格でも問題は発生しないのでは

• システム企画や保守・運用工程においては、ユーザ・ベンダ間の役割分担が不明確

• 人月をかけるほど売上・利益につながる産業構造が優秀な人材を集まりにく

くさせている

価格・見積・契約における課題への取組み状況

• システム開発では、QCD に加えリスクを評価している

• 保守運用については SLA を活用し、ト

ラブルの削減、ユーザ・ベンダ間の責任分担の明確化を実現している

• 競争が激しい業界のユーザの間では、

カットオーバーするまでにいかに時間を削減できるかの関心が高まっている

• IT アウトソーシング、SaaS/ASP の利

用といった領域で、インセンティブ支払の実績がある

• 開発経験にもとづいたリスクの算定、工数見積のベースライン整備、工程別契約等、見積精度の向上に着手している

• ユーザへの提案時において、IT 投資効果を算定することも普及しはじめている

• SaaS/ASP や、保守・運用業務に関しての SLA 締結において PBC の実績が見られるが、大半は提案ベースにとど

まっている

PBC の

適用可能性

•「アウトカム」→「アウトプット」→

「インプット」という順でシステムを評価すべきという意見と、PBC を適用するのは時期尚早との意見があった

• システム開発工程においても、短納期開発、優秀なエンジニアへのインセンティブ付与といった形でPBC を適用できそうである

• 業種・業務、アプリケーション種別、工期、ベンダとの関係等によっては

PBC 適用が困難な可能性がある

• 事業モデル毎に、リスク、品質、信頼性、ブランドといった観点で PBC の指標を整備すべきではないか

• PBC をシステム開発に適用するためには、ベンダが IT コンサルの領域もカバーする必要がある

• ベンダのメリットとしては、エンジニアリング面での取組みへのモチベーションが高まる点が大きい。反面、ベンダのビジネスリスクは増加する恐れが

ある

3-3 調査結果から得られた示唆

（1）パフォーマンスベース契約の適用事例

今回調査において、保険会社 A 社がシステム開発・運用・保守における IT アウトソーシングと、新システム開発における ASP サービス調達において、パフォーマンスベース契約を適用したという事例が確認できた。以下にそれぞれの詳細を示す。

1）システム開発・運用・保守における IT アウトソーシング（アウトプット型）

【概要】

• 外資系ベンダ B 社との間で PBC を締結した

• 元来 A 社が抱えていた協力会社の人員分の開発を、B 社にアウトソーシング（またはオフショア）すると同時に、生産効率向上分の 50％をインセンティブとして付与した

• 結果、当初予定であった年間 15%以上の、年間 20%の生産効率向上を実現できた

【PBC 適用によるメリット】

• B 社が積極的に業務改善の提案をするようになった

• その結果、A 社は当初予定以上（15%→20%）の効果があげられた上、B 社も予定以上のインセンティブを獲得できた

2）新システム開発における ASP サービス調達（アウトカム型）

【概要】

• 当初はカスタムメイドで新システムを構築する予定であったが、別の保険会社のシステム子会社 C 社が新しくリリースする ASP サービスを調達する方針に切り替えた（＝C 社の ASP サービスのファーストユーザとなった）

• 支払形態は、ASP サービスの初期開発費用の 1/3（C 社の販売目標が 3 ユーザのため）の金額＋5 年間の利用料（インセンティブ）であった

• C 社の ASP サービスの販売実績は、最終的には目標 3 ユーザを上回る 5 ユーザとなった

【メリット】

• A 社のメリットはカスタムメイドの場合の 1/3 程度の金額で新システム開発を実現できたことであった

• C 社のメリットは、サービス開発前からファーストユーザがつくことによる、サービス初期投資額の抑制およびビジネスリスクの低減であった

１）および２）の事例から得られた示唆を以下に示す。

• 両事例とも、ユーザ（A 社）とベンダ（B 社、C 社）との間で「Win-Win」の関係を実現できた

• いずれもインセンティブの支払形態は、ベンダのリスクを考慮して、固定価格＋成果報酬とした

• いずれもユーザ（A 社）から提案した。提案されたベンダ（B 社、C 社）は当初は懐疑的であったが、ベンダ側のメリットを示す等、話を詰めていくうちに納得した

（2）PBC 分類に対する示唆

調査結果から PBC 分類（アウトカム型、アウトプット型、インプット型）それぞれに対して、新しい示唆を得ることができた。（図表 3-2 参照）

1）アウトカム型への示唆

アウトカム型の PBC の適用は、ユーザがシステム投資額をベンダと折半できることで大幅に削減が可能となる一方、ベンダがユーザを新サービスのファーストユーザと位置づけることで、より少ない初期投資で新サービス開発が可能になるといったように、ユーザとベンダの両方に大きなリターンをもたらす可能性が高い。

2）アウトプット型への示唆

アウトプット型の PBC 適用により、ユーザ・ベンダ双方による業務改善提案が活性化する可能性が高い。一方で、アウトプット型の PBC は、短期間開発では適用しにくい等、全ての業務やシステムへの適用は非現実的である、業種によっては業務とシステムとの因果関係（アウトプットとインプットの関係）の把握が困難である、といった理由から普及には時間がかかるのではないかとの意見もある。

3）インプット型への示唆

インプット型の PBC の必要性は多くのユーザおよびベンダが感じている。インプット型の PBC の適用方法については様々な考え方があったが、以下の 3 種類の方向性に整理できた。

1. システム開発・保守・運用等の QCD の成果に応じて、ベンダにインセンティブを付与する

2. 業界・業種・業務（アプリケーション）やユーザ規模ごとに、KPI をあらかじめ設定しておき、PBC を適用する

3. 人月単価を、SE のスキル（業務知識・開発経験等）に応じて精緻化して、契約する

図表 3-2 PBC 分類ごとに新たに得られた示唆

PRMのフレームワークを元にしたPBC分類

新たに得られた示唆

アウトカム

価値

アウトプット

価値

インプット人材と組織

テクノロジ

（システム）

プロセス

成果

• アウトカム型のPBCの適用はユーザにもベンダにも大きなリターンをもたらす可能性が高い

–ユーザはシステム投資額をベンダと折半する形で大幅に削減可能

–ベンダはユーザを新サービスのファーストユーザと位置づけることにより、少ない初期投資で新サービス開発が可能

• インプット型のPBCの必要性は共通的な見解であった

• PBCの適用方法については、概ね3種類の方向性がみられた

–システム開発・保守・運用等におけるQCDの成果に応じてインセンティブを付与

–業界・業種・業務（アプリケーション）や、ユーザ規模ごとに、KPIをあらかじ

め設定

–人月単価を、SEのスキル（業務知識・開発経験等）に応じて精緻化

• アウトプット型のPBC適用により、ユーザ・ベンダ双方による業務改善提案が活性化する可能性が高い

• 一方で、アウトプット型のPBCの普及には時間がかかるとの声も

–短期間開発では適用しにくい等、全ての業務やシステムへの適用は非現実的

–業種によっては因果関係（アウトプット→インプット）の把握が困難

※PBC 分類については 4 章図表 4-4 を参照

4 PBC の定義とモデル

PBC の定義を行うとともに、情報システムへの PBC への適用可能性を考慮したモデルを検討、整理した。PBC のモデルについては現時点での案と位置づけ、今後、議論や検討を行っていくなかで、更なる精緻化を図っていくことが望まれる。

4-1 定義

【IT サービスにおけるパフォーマンスベースの価格設定、契約（PBC）とは】

IT サービスにおける PBC とは、「サービス・システムの対価の一部、または全部について、サービス・システムによって創出されるパフォーマンスにもとづいた価格設定を行うこと」である

現行の人月ベースの価格設定では、「製品としての価値（モノへの対価）」に重きを置くため、「システムを構築するために要した労働量」を価格に換算する考え方が基本となっている。それに対して、PBC の価格設定では「システムやサービスが生み出す価値（価値への対価）」に重きを置くため、「システムやサービスが創出する価値」を価格に換算する考え方になる点が人月ベースの価格設定と本質的に異なる。

システムやサービスが

生み出す価値

（価値への対価）

創出

製品としての価値

（モノへの対価）

図表 4-1 PBC と現行（人月ベース）の価値の考え方

パフォーマンスベースの価格設定・契約

（価値への対価が中心）

価値（利益増大、コスト削減）

PBC

サービスやシステムが創出する価値を価格に換算する

人月ベースの価格設定

（モノへの対価が中心）

労働量（工数×単価）

現行

システムを構築するために要した労働量を価格に換算する

（1）PBC のメリット／デメリット

PBC はユーザとベンダにとっての「適正価格」で取引できる等、双方にメリットがあるが、予算確保の方法、KPI の成果を計測する仕組みの構築等、PBC の適用に伴い生じる課題の解決が必要である。

図表 4-2 PBC のメリット／デメリット

メリット

デメリット

ユーザ側の視点

・無駄な投資が減る等、「適正な価格」での

IT 投資ができる

・目的を共有することから、ベンダの積極性を期待することができる

・IT 投資に対する経営層の理解が得られやすい

・IT 投資による効果の把握がより明確に行

うことができる

・契約時に価格が確定せず、成果により事後的に価格が変動するため、定額固定契約と比べて予算確保が難しい

・KPI の数や内容によって、計測作業が煩雑となる可能性がある

ベンダ側の視点

・提供物より創出された価値に応じた「適正な対価」を得ることができる

・工数ベースの契約から脱却することで、付加価値の創出や効率化に対するモチベーションが向上する

・（特に新規ユーザに対して）営業の手段として効果的な活用が可能である

・期待した成果が出せない場合、定額固定契約と比べて収益の縮小となる可能性がある

・KPI の数や内容によって、計測作業が煩雑となる可能性がある

・取引額がサービス提供後の成果計測に

よって決定するため、定額固定契約と比べて対価を得るタイミングが遅い

また、PBC を適用した契約では、ユーザの IT への投資効果の拡大が、ベンダにとってもインセンティブの獲得につながることから、同じ目的へのモチベーションがユーザ、ベンダ両者にメリットをもたらす、Win-Win の関係が実現する。

ユーザ

ベンダ

図表 4-3 PBC によるユーザ、ベンダの Win-Win の関係

PBCの適用

IT投資目的をユーザとベンダとの間で共有可能に

当初目的以上の

成果を獲得

改善への

モチベーション向上

etc・・・

IIITT投資資効効率年間1155%%改改善

工場場のの生産性

在在庫をを年年間間

IT投資への当事者意識が醸成

年間55%%向向上 3300%%削減

新サービスの年間売上

110000億億円円達成成

インセンティブ

の取得

ユーザとベンダとの間でWin-Winの関係が実現

各々成果に見合ったインセンティブを設定

ベンダ

ユーザ

（2）PBC 分類

PRM（Performance Reference Model）のフレームワークをベースに、IT サービスにおける PBC を「①インプット型」、「②アウトプット型」、「③アウトカム型」の３つに分類した。（図表 4-4 参照）

1）インプット型

システム開発、運用そのものの価値をベースとした価格設定、契約を行う

• 範囲：システム開発、運用

• KPI 例：システム稼働率、バグ数、応答時間、保守時間

2）アウトプット型

情報サービス、システムにより実現される業務改善等のオペレーション価値をベースとした価格設定、契約を行う

• 範囲：システム開発、運用、オペレーション

• KPI 例：利用数・率、欠品率、作業時間、在庫回転率

3）アウトカム型

収益等の事業目的、成果をベースとした価格設定、契約を行う。

• 範囲：事業全体（システム開発、運用も含む）

• KPI 例：利益増大、コスト削減、満足度

図表 4-4 PRM を活用した PBC の分類

①インプット型

システム開発、運用そのものの価値をベースとした価格設定、契約を行う

②アウトプット型

情報サービス、システムにより実現される業務改善等のオペレーション価値をベースとした価格設定、契約を行う

③アウトカム型

収益等の事業目的、成果をベースとした価格設定、契約を行う

テクノロジ

（システム）

ト人材と組織

プロセス

成果

範囲

事業全体

（システム開発、運用も含む） KPI例

・利益増大

・コスト削減

・満足度

範囲

システム開発、運用、オペレーション KPI例

・利用数・率

・欠品率

・作業時間

・在庫回転率

範囲

システム開発、運用 KPI例

・システム稼働率

・バグ数

・応答時間

・保守時間

ＰＲＭのフレームワークＰＢＣの分類

アウトカム

成果

価値

アウトプット

価値

インプット人材と組織

テクノロジ

（システム）

プロセス

③アウトカム型

収益等の事業目的、成果をベースとした価格設定、契約を行う

範囲

事業全体

（システム開発、運用も含む） KPI例

・利益増大

・コスト削減

・満足度

②アウトプット型

情報サービス、システムにより実現される業務改善等のオペレーション価値をベースとした価格設定、契約を行う

範囲

システム開発、運用、オペレーション KPI例

・利用数・率

・欠品率

・作業時間

・在庫回転率

①インプット型

システム開発、運用そのものの価値をベースとした価格設定、契約を行う

範囲

システム開発、運用 KPI例

・システム稼働率

・バグ数

・応答時間

・保守時間

【参考：業績測定参照モデル（PRM：Performance Reference Model）】

PRM（Performance Reference Model：業績測定参照モデル）とは、情報化投資の効果を客観的に評価するための指標を集めた雛形モデルであり、汎用 KPI、各 KPI の測定方法、測定周期、各 KPI の金銭価値の換算方法等が整理されている。

図表 4-5 PRM のフレームワーク

最終成果を図る

KPI

プロセスを図る

プロセス

プロセス品質量

スピード

プロセス

プロセス品質量

スピード

KPI

ミッション・戦略

国民等に対する成果

国民等へのサービス向上国民等の参加

行政内部の効率化・改革経済的効果

国民等に対する成果

国民等へのサービス向上国民等の参加

行政内部の効率化・改革経済的効果

国民等に対する成果

国民等へのサービス向上国民等の参加

行政内部の効率化・改革経済的効果

価値

最終成果（アウトカム）

業務のミッションを達成したかどうかを直接的に測定する指標。業務の最終目的と連動している。主に、顧客の視点から測定する。

プロセス

プロセス品質量

スピード

出力（アウトプット）

主に、情報化投資の結果として直接的に表れる指標。これらのアウトプット指標を向上させた結果として、最終成果

（アウトカム）が達成できると考えている。

価値

恒常的な評価、モニタリ

人材と組織

利用者・職員のコンピテンシ利用者・職員の支援

組織

人材と組織

利用者・職員のコンピテンシ利用者・職員の支援

組織

利用者・職員のコンピテンシ利用者・職員の支援

組織

テクノロジ（革新）ＩＴ投資管理

テクノロジ（革新）

ＩＴ投資管理

ＩＴアーキテクチャシステム性能

プロダクト品質プロジェクト管理

テクノロジ（革新）

ＩＴ投資管理

ＩＴアーキテクチャシステム性能

プロダクト品質プロジェクト管理

ＩＴアーキテクチャシステム性能

投入資源内部費用外部費用

プロダクト品質プロジェクト管理

入力（インプット）

業務を実現するためのメカニズムであるテクノロジ、

人材と組織に関する指標。業務を実現するための前提となる条件ともいえる。

入力（インプット）

業務を実現するための投入資源であるコストに関する指標。情報化投資における判断のベースとなる指標である。

投入資源

内部費用外部費用

投入資源

内部費用外部費用

ングの実施

情報システム構想

（xxxx://xxx.xxxx.xx.xx/xxxxxx/xx_xxxxxx/xx/xxxxxx/xxxxx/xxx/xxxxx.xxxx）

4-2 PBC モデルの検討

PBC モデルの検討として、情報システムの開発形態の分類から PBC の適用可能性を検討した。

（1）情報システムの開発形態の分類

PBC のモデルを検討するにあたって、PBC の適用可能性と関係性が高いと想定される「事業モデル」、「システム導入プロセス」、「契約形態」の各観点に着眼した。以下に、本検討における事業モデル、システム導入プロセス、契約形態の定義を示す。

1）事業モデル

本検討では『情報サービス・ソフトウェア産業維新』の事業モデルをベースに各モデルの定義を補足した。

事業モデルは、「委託／請負開発モデル」、「ライセンスモデル」、「サービスモデル」、

「IT アウトソーシングモデル」、「BPO モデル」の 5 つに分類される。各々の事業モデルにおける概要、開発の具体例等を「図表 4-7 事業モデルの定義（補足）」に示す。

図表 4-6 事業モデルの定義

出典：『情報サービス・ソフトウェア産業維新～魅力ある情報サービス・ソフトウェア産業の実現に向けて～（案）』産業構造審議会情報経済分科会情報サービス・ソフトウェア小委員会中間とりまとめ

図表 4-7 事業モデルの定義（補足）

取引形態	概要	例	システム所有	開発有無	運用者	利用者
委託/ 請負開発モデル	ユーザの要求仕様にもとづいて開発を行う	スクラッチによるx x開発	ユーザ	有	ユーザ	ユーザ
ライセンスモデル	開発済みのソフトウェアを使用許諾のもとに提供する	パッケージソフトウェアや ERP （ Enterprise Resource	ユーザ	無	ユーザ	ユーザ
		Planning）など
IT アウトソーシングモデル	ユーザの要求に基づく開発を行い、ハードウ	サーバのホスティングや情報システム部	ベンダ※	有	ベンダ	ユーザ
	ェアの運用･管理に至	門の行う運用管理業
	るまでベンダに委託す	務の委託
	る
サービスモデル	インターネット等を経由して、ベンダが提供するアプリケーションをサービスとして利用する	SaaS/ASP	ベンダ	有 ( カスタマイズ)	ベンダ	ユーザ
BPO モデル	ユーザの要求にもとづ	コールセンター、物	ベンダ※	有	ベンダ	ベンダ
	く開発を行い、ハード	流センターの委託
	ウェアの運用･管理に
	至るまでベンダに委託
	する。委託範囲は情報
	システムのみでなく、
	ユーザ側の業務まで含
	む

※ IT アウトソーシングモデルと BPO モデルでは、ユーザが情報システムを所有し、ベンダに運用業務のみを委託する形態も考えられるが、ここでは調達や所有も含めて委託することを想定

2）システム導入プロセス

本検討では、『モデル取引・契約書』（経済産業省）をベースに、システム導入プロセスを企画・要件定義、外部設計書作成業務、ソフトウェア開発業務、ソフトウェア運用準備・意向支援業務、運用業務、保守業務の 6 つに再定義した。

図表 4-8 システム導入プロセスの定義

企画・要件定義段階

開発段階

運用段階

保守段階

モデル取引･契約書システム化

におけるプロセスの方向性

企画支援サービス業務

要件定義書作成支援業務

外部設計書作成業務

ソフトウェア開発業務

ソフトウェア運用準備･移行支援業務

運用業務

保守業務

企画・要件定義

外部設計書作成業務

ソフトウェア開発業務

ソフトウェア運用準備･移行支援業務

運用業務

保守業務

定義

本検討におけるプロセス定義

システム化計画

要件定義

システム設計 (システム外部設計)

シスソフトウェ

ア設計/ シス

テムプログラ

方式ミング/ソテム

フトウェア結合

設計テスト

システムテスト

導入･受入支援

運用テスト

運用保守

出典：『情報システムの信頼性向上のための取引慣行・契約に関する研究会～情報システム・モデル取引・契約書～』経済産業省

3）契約形態

本検討では、事業モデル、システム導入プロセス毎に、一般的に利用される契約形態を 19 の形態に分類した。

・請負契約

③

・準委任契約✢SLA

・請負契約✢SLA

図表 4-9 事業モデル、システム導入プロセス毎の主な契約形態

企画･要件定義

外部設計書作成業務

ソフトウェア開発業務

ソフトウェア運用準備･移行支援業務

運用業務

保守業務

委託／請負開発モデル

・準委任契約

①

・準委任契約

・請負契約

②

・請負契約

③

・準委任契約

・請負契約

④

・準委任契約

・請負契約

⑤

・準委任契約

・請負契約

⑥

ライセンスモデル

・準委任契約

⑦

・準委任契約

・請負契約

⑧

・使用許諾契約

⑨

・準委任契約

・請負契約

⑩

・準委任契約

・請負契約

➃

・準委任契約

・請負契約

⑫

ITアウトソーシングモデル

・準委任契約

⑬

・準委任契約

・請負契約

⑭

・準委任契約✢SLA

・請負契約✢SLA

⑮

サービスモデル

・準委任契約

⑯

・準委任契約

・請負契約

⑰

・使用許諾契約✢SLA

⑱

BPOモデル

・準委任契約✢SLA

・請負契約✢SLA

⑲

※1. システム導入プロセス毎の工程単位で契約する前提とした

※2. IT アウトソーシングモデル、サービスモデル、BPO モデルについては、サービスの利用、委託となるため、一部、もしくは全プロセス単位での契約を想定した

（2）PBC の適用可能性の定義

PBC の適用可能性については、「適用の難易度」と「PBC の分類」による 2 つの尺度を用いて評価した。

1）適用の難易度

PBC を適用するにあたっての難易度として、普及度、測定に要するコスト、成果の明解度の観点で評価した。

• 普及度：

現状において、既に導入されており、契約に対する考え方が認知されているか？

• 測定に要するコスト：PBC の評価対象となる成果を測定しやすいか？

• 成果の明解度：ユーザ、ベンダ間の成果に対する貢献度合いは把握可能か？

2）PBC の分類

PBC の分類は、図表 4-4 で整理したアウトカム型、アウトプット型、インプット型を活用した。

図表 4-10 PBC 契約の適用可能性のフレームワーク

適用可能性適用可能性

適用の適用の難易難易度度

・普及度（既に導入されているか？）

・測定コスト（成果を評価し易いか？）

・成果明解度（ユーザ／ベンダ間の成果に対する貢献度合いは把握可能か？）

PBPBCCの分の分類類

・アウトカム型／アウトプット型／

インプット型

PBCの分類

・アウトカム型／アウトプット型／インプット型

適用の難易度

・普及度（既に導入されているか？）

・測定コスト（成果を評価し易いか？）

・成果明解度（ユーザ／ベンダ間の成果に対する貢献度合いは把握可能か？）

適用可能性

＝ ×

PBC分類

アウトカム型

各

事業モデルのプロセス毎にマッピングを試みる

アウトプット型

インプット型

難易度

難易

（3）各事業モデルの PBC 適用可能性のマッピング

事業モデル毎に PBC の適用可能性のマッピングを検討した結果を示す。

1）委託／請負開発モデル

企画・要件定義（①※）、開発全般（②～④）、保守・運用（⑤、⑥）毎に PBC の適用可能性に対する課題が異なる。また、保守・運用については、SLA 導入、常駐稼動の場合で分類される。

※ 図表 4-9「事業モデル」、「システム導入プロセス」毎の主な契約形態の番号を参照（以降の各事業モデルも同様）

図表 4-11 委託／請負開発モデルのマッピング結果

・SLAを既に導は受け入れ

・基本的にはベ

し易い（ベンダ

①

保守・運用保守・運用（（SLSL

PBC分類

アウトカム型

企画・要件定義

・現状はユーザの領域であるが、ベンダも関与できないか

・成果に対するユーザ／ベンダ間の貢献

度合いは把握し辛い

①

保守・運用（SLA導入）

・SLAを既に導入した実績のあるユーザは受け入れ易い

・基本的にはベンダの貢献度合いを把握

し易い（ベンダ主体のため）

アウトプット型

インプット型

保守・運用（常駐稼動型）

・運用・保守要員を常駐させるため、成果を評価しにくい

難易度

難

易

開発全般

・評価項目がプロジェクト管理の対象と共通であれば、コスト負担は軽減される

・基本的にはベンダの貢献度合いを把握し易

い(開発工程であり、ベンダ主体のため）

⑤ ⑥

② ③ ④

② ③ ④ ⑤ ⑥

⑤ ⑥

2）ライセンスモデル

基本的には委託／請負開発モデルと類似したマッピングとなった。ライセンスモデルはレディメイドであるという条件が、企画・要件定義（⑦）において、企画内容に対して制約事項となる可能性がある。

図表 4-12 ライセンスモデルのマッピング結果

⑦

PBC分類

企画・要件定義

アウトカム型

・現状はユーザの領域であるが、ベンダも関与できないか

・成果に対するユーザ／ベンダ間の貢献度合いは把握し辛い

・レディメイドであるため、企画内容に制約事項が発生する可能性あり

アウトプット型

⑦

保守・運用（SLA導入）

保

・SLは

・基

・SLAを既に導入した実績のあるユーザは受け入れ易い

し

⑧ ⑩ ➃ ⑫

➃ ⑫

・基本的にはベンダの貢献度合いを把握し易い（ベンダ主体のため）

保守・運用（常駐稼動型）

インプット型

➃ ⑫

⑧ ⑩ ➃ ⑫

・運用・保守要員を常駐させるため、成果を評価しにくい

難

開発全般

・評価項目がプロジェクト管理の対象と共通であれば、コスト負担は軽減される

・基本的にはベンダの貢献度合いを把握し易い(開発工程であり、ベンダ主体のため）

難易度

易

※ソフトウェア開発業務（⑨使用許諾契約）はライセンスモデルの場合、既に開発されているため、ここでは対象外とした

3）IT アウトソーシングモデル

IT アウトソーシングの開発から保守・運用まではインプット型の領域にマッピングされるが、ユーザからはアウトプット型の領域での貢献が期待されている。

図表 4-13 IT アウトソーシングモデルのマッピング結果

➉ ⑮

ユーザ側は、ベンダ

がアウトプット型へシフトするニーズあり

⑬

PBC分類

アウトカム型

企画・要件定義

・現状はユーザの領域であるが、ベンダも関与できないか

・成果に対するユーザ／ベンダ間の貢献度合いは把握し辛い

アウトプット型

ソフトウェア開発業務～保守・運用

・SLA提示を前提としているため、ユーザは受け入れ易い

インプット型

・基本的にはベンダの貢献度合いを把握

し易い（ベンダ主体のため）

難易度

難易

ソフトウェア開発業務

・評価項目がプロジェクト管理の対象と共通であれば、コスト負担は軽減される

・基本的にはベンダの貢献度合いを把握し易

い(ベンダ主体のため）

⑮

➉

ユーザ側は、ベンダがアウトプット型へシフトするニーズあり

⑬

4）サービスモデル

サービスモデルは、アウトプット型の領域にマッピングできるが、ユーザからはアウトカム型の領域での貢献が期待されている。

図表 4-14 サービスモデルのマッピング結果

PBC分類

⑱

➃

ユーザ側は、ベンダ

がアウトカム型へシフ

トするニーズあり

⑯

アウトカム型

企画・要件定義

・現状はユーザの領域であるが、ベンダも関与できないか

・成果に対するユーザ／ベンダ間の貢献度合いは把握し辛い

・イージーメイドであるため、企画内容に制約事項が発生する可能性あり（委託

／請負開発モデルとの相違点）

アウトプット型

インプット型

ソフトウェア開発業務～保守・運用

・SLA提示を前提としているため、ユーザは受け入れ易い

・基本的にはベンダの貢献度合いを把握し易い（ベンダ主体のため）

難

ソフトウェア開発業務

・評価項目がプロジェクト管理の対象と共通であれば、コスト負担は軽減される

・基本的にはベンダの貢献度合いを把握し易い(ベンダ主体のため）

難易度

易

5）BPO モデル

事業や業務そのものをアウトソーシングするモデルであり、アウトカム型の領域に適している。

図表 4-15 BPO モデルのマッピング結果

PBC分類

アウトカム型

アウトプット型

インプット型

⑲

BPOモデル

・SLA提示を前提としているため、ユーザは受け入れ易い

・基本的にはベンダの貢献度合いを把握し易い（開発から業務まで全てがベンダ主体のため）

難易度

難易

（4）PBC 適用可能性のカテゴライズ

PBC 適用可能性として契約形態①～⑲をマッピングした結果をもとに、6 つのカテゴリに整理した。

1）カテゴリⅠ（企画・要件定義型）

企画・要件定義はユーザの領域であるが、ベンダも関与することによりアウトカム型の PBC が実現できないか。ただし、システム構築の上流工程であるため、システム導入の成果に対するユーザ／ベンダ間の貢献度合いは把握しづらい。

2）カテゴリⅡ（開発工程型）

システム設計、開発では QCD などを KPI としたインプット型の PBC が想定させる。PBC 事例も少なく、PBC 適用にあたってのユーザ側のメリットがどの程度あるか、あるいは KPI の設定をどのように行うかなど課題は多いと想定されるが、ベンダの貢献度合いを比較的測定しやすい領域ではある。

3）カテゴリⅢ（常駐稼動型）

運用・保守要員を常駐させ稼動を提供するモデルであるため、成果を評価しにくい。

4）カテゴリⅣ（ITO 型）

システム運用委託や IT アウトソーシングについては、SLA を前提とした PBC の導入を想定しており、ユーザは受け入れやすいのではないか。特に IT アウトソーシングの場合は、よりユーザの事業・業務に近いアウトプット型の KPI での PBC のニーズがあると考えられる。また、カテゴリⅡと同様に、ベンダの貢献度合いを把握しやすい領域である。

5）カテゴリⅤ（サービスモデル型）

SaaS/ASP などのサービスモデルは、事例などからアウトプット型の KPI を設定することが想定される。提供するサービスによっては、よりユーザの事業成果に近いアウトカム型の KPI での PBC のニーズがあると考えられる。

事例がいくつか存在することもあり、また、ユーザの事業や業務に近い事業モデルであるため、PBC への適用性が高い。

6）カテゴリⅥ（BPO モデル型）

BPO モデルは、事例などからアウトカム型の KPI を設定することが想定される。事業や業務そのものをアウトソーシングするモデルであるため、事業成果の設定、測定が容易であり PBC への適用性が高い。

図表 4-16 情報システムの契約形態のマッピング結果

PBC分類

① ⑦ ⑲

⑬ ⑯

アウトカム型

カテゴリⅥ（BPOモデル型）

⑤ ⑥ ➃

⑫ ➉ ⑮

② ③ ④

⑧ ⑩

⑤ ⑥

➃ ⑫

➃ ⑱

⑬ ⑯

⑲

① ⑦

・SLA提示を前提としているため、ユーザは受け入れ易い

➃ ⑱

・基本的にはベンダの貢献度合いを把握し易い（開発から業務まで全てがベンダ主体のため）

カテゴリⅠ（企画・要件定義型）

・現状はユーザの領域であるが、ベンダも関与できないか

・成果に対するユーザ／ベンダ間の貢献度合いは把握し辛い

アウトプット型

インプット型

カテゴリⅤ（サービスモデル型）

・SLA提示を前提としているため、ユーザは受け入れ易い

・基本的にはベンダの貢献度合いを把握し易い（ベンダ主体のため）

カテゴリⅣ（ITO型）

⑤ ⑥ ➃

② ③ ④ ⑫ ➉ ⑮

⑤ ⑥ ⑧ ⑩

➃ ⑫

・SLA提示を前提としているため、ユーザは受け入れ易い

・基本的にはベンダの貢献度合いを把握し易い（ベンダ主体のため）

カテゴリⅢ（常駐稼動型）難

・運用・保守要員を常駐させ

るため、成果を評価しにくい

易

カテゴリⅡ（開発工程型）

・評価項目がプロジェクト管理の対象と共通であれば、コスト負担は軽減される

・基本的にはベンダの貢献度合いを把握し易い(開発工程であり、ベンダ主体のため）

難易度

6 つのカテゴライズした結果を図表 4-9 事業モデル、システム導入プロセス毎の主な契約形態に分類すると下表のとおりとなる。

・使用許諾契約

⑨⑨

・準委任契約

・請負契約

➉

⑮

・準委任契約

・請負契約・使用許諾契約✢SLA

➃ ⑱

・準委任契約✢SLA

・請負契約✢SLA

・・準委任準委任契約契約✢S✢SLALA

・請・請負負契約✢契約✢SSLLAA

カテカテゴ BPBPOO➉➉モ

・・・準委任準委任準委任契約契約契約

①①①

・・・準委任準委任準委任契約契約契約

カテカテゴリゴリⅠⅠ

⑦⑦⑦

企画企画・・要要件件

・・・準委任準委任準委任定義型定義契約契約契約型

⑬⑬⑬

・・・準委任準委任準委任契約契約契約

⑯⑯⑯

・準委・準委・準委任xxxx契約約約

・請負・請負・請負xx契約約約

②②②

・準委・準委・準委任xxxx契約約約

・請負・請負・請負xx契約約約

⑧⑧⑧

・請・請・請負xxxx契約約約・・・準

カテカテゴリゴリⅡⅡ ・請

③③③③ 型開発開発③③③工程工程型

委任契約任契約任契約負xx契約約約

④④④

・準委・準委・準委任契約任契約任契約

・請負・請負・請負xx契約約約

⑩⑩⑩

・使・使用許用許諾契約諾契約

－－

（対象（対⑨⑨⑨象外外））

・準委・準委任xx契約約

・請負・請負契契約約・準委任契約✢SLA カテカテゴゴリリⅣⅣ

・請負契約✢SLA

➉➉ ITITOO型型 ⑮⑮

・準委・準委任xx契約約

・請負・請負契契約約・・使用許使用許諾契諾契約✢S約✢SLALA カテカテゴリゴリⅤⅤ

➃➃ サービスモデルサービスモデル型型⑱⑱

・・準準委任委任契約契約✢✢SSLLAA

・・請請負xx契約✢S約✢SLLAA リⅥⅥ

➉デル型

図表 4-17 情報システムの契約形態とカテゴリの関連性

カテゴリⅥ BPOモデル型

BPOモデル

カテゴリⅤ

サービスモデル型

サービスモデル

ITアウトソーシングモデル

カテゴリⅣ ITO型

・準委任契約

・請負契約

⑫

・準委任契約

・請負契約

－

（対象外）

ライセンスモデル

常⑤駐稼動型

・請負契約

・準委任契カ約テゴリⅢ・準委任契約

カテゴリⅡ 開発工程型

カテゴリⅠ 企画・要件定義型

委託／請負開発モデル

保守業務

運用業務

ソフトウェア運用準備･移行支援業務

ソフトウェア開発業務

外部設計書作成業務

企画･要件定義

（5）PBC モデルの方向性

2 章の事例調査、3 章の問題意識調査、4.（4）PBC 適用可能性のカテゴライズ結果

（図表 4-16 参照）を考慮すると PBC モデルとしては、大きく 3 つの方向性で展開可能と想定した。

【方向性① サービス提供による PBC 実施】

– ユーザのノウハウ、ベンダのノウハウを補完する形でパートナーシップを組む事例がある

– 事業成果に近いアウトカム、アウトプットの KPI による PBC を目指す

【方向性② システム開発による PBC 実施】

– システム開発の PBC 事例はほとんど見られない

– 納期など設定容易なインプットの KPI やシステム開発の QCD の KPI を設定、計測する PBC を目指す

【方向性③ システム運用による PBC 実施】

– システム運用の SLA にインセンティブ（ペナルティ）契約を適用する事例がある

– 運用の SLA の KPI を設定、計測する PBC を目指す

図表 4-18 情報システムの開発形態とカテゴリの関連性

適用可能性によるカテゴライズ方向性

PBC分類

アウトカム型

カテゴリⅠ※

カテゴリⅥ（BPOモデル型）

• サービスとPBCの親和性は高く、事例もいくつか存在する

方向性1

サービス提供によるPBC実施

• 事業成果に近いアウトカム、アウトプ

（企画・要件定義型）

ットのKPIによるPBCを目指す

カテゴリⅤ（サービスモデル型）

アウトプット型

インプット型

難

易難易度

当面の適用範囲

• システム開発のPBC事例はほとんど見られない

カテゴリⅣ（ITO型）

カテゴリⅢ

（常駐稼動型）カテゴリⅡ（開発工程型）

方向性2

システム開発による PBC実施

• 納期（D）など設定容易なインプットの KPIやシステム開発のQCD※1のKPIを設定、計測するPBCを目指す

方向性3

システム運用による PBC実施

• システム運用のSLAにインセンティブ

（ペナルティ）契約を行う事例がある

• 運用のSLA※1のKPIを設定、計測するPBCを目指す

※1：システム開発のQCDやリスクのKPIについてはJUAS、JEITA、JISA等で検討中、システム運用SLAのKPIはJEITAで整備済

※カテゴリⅠについては、コンサルサービスの PBC として別の整理が必要である

【参考】研究会における議論

PBC のモデルや適用可能性について、本研究会での主な意見を示す。

• ユーザ、ベンダ間の PBC の合意形成について

– パフォーマンスにコミットするのは誰なのか、またパフォーマンスとは何を指すのか、という議論が必要である

– 工程毎に契約を分割するのは合意に向けて工数を要するため、PBC のメリットが感じられないかもしれない

– 米国の事例を見ても、当該企業間の信頼関係が影響すると考える。資本関係があるなど信頼関係がなければ PBC の適用は難しいのではないか

– IT 投資評価の考えが浸透してきているということは、PBC が適用しやすいと想定されるので望ましいことである

– 固定＋インセンティブ型の契約においては、固定額の部分に対して品質面を条件にした入札方式や KPI 自体をベンダに提案させる入札方式が有効ではないか

• 価格、インセンティブの設定について

– SLA はインセンティブまたはペナルティの両方で評価基準として使用されるが、一般的にユーザは SLA をペナルティに使用する傾向がある

– JISA では本来の価格のあり方として、基本価格に品質、リスクが価格を変動させる要因として組み込まれたモデルを策定している。この考え方においては、品質をインセンティブという形で評価するのは違和感がある

– 企業や製品、サービスのブランドは PBC の評価対象に含まれるのか

– 高度 IT 人材の育成を図るためにも、高いスキルを持つ人材あるいは企業が高い報酬を得ることのできるインセンティブ設計や契約制度を整備する必要がある

– 過去の事例では、インセンティブの配分をユーザ、ベンダで取りあえず 50％ずつの折半にしているというケースが多い

– インセンティブが情報システム価格の 1％とか 2％程度であっても、「PBC を実施してみよう」というモチベーションをベンダに持たせることが重要である

• KPI の設定について

– 品質の低下、コストの超過の主な要因として、仕様変更の影響が高いのであれば、仕様変更率というような KPI を定めることによって、例えば、5％超過分についてはインセンティブを付与するといったモデルも成り立つかもしれない

• 先進事例の調査について

– 米国では、予算全体の何％かを PBC で実施するというような方針が明確にされており、先進事例として研究することが有効である

5 まとめ～今後の課題など～

本調査研究では、国内外の PBC 事例より IT サービスにおける PBC の適用が実際に効果を上げていることが確認でき、他産業の類似事例調査結果とあわせて、実際に PBC を導入するにあたってのいくつか示唆を整理することができた。特に、ユーザ、ベンダ双方における事業目標の共有や双方に分かりやすい指標の設定など、パートナーシップが重要な要素であるといえる。また、ユーザ、ベンダに情報システムの価格の問題意識、および PBCの適用可能性等について調査を行い、その結果、PBC の適用については、時期尚早という意見と実際に PBC を実施した経験もあり十分可能であるという意見があるが、総じて PBCの効果については肯定的な意見が多い。

これらの調査結果をもとに、PBC の定義を行い、PRM のフレームワークをベースに、ITサービスにおける PBC を「①インプット型」、「②アウトプット型」、「③アウトカム型」の 3 つに分類するとともに、情報システムの開発形態の分類から PBC の適用可能性を 6 つのカテゴリに整理した。

今後、IT サービスにおける PBC の実施、普及を図るために、PBC 実施のための環境整備が求められる。例えば、PBC の適用領域や実施プロセス、KPI の設定や価格設定などの例、留意事項などを示したガイドラインの整備、あるいは会計上、法律上の対応を整理した上で契約書の雛形となるモデル契約書の整備などが必要である。また、PBC の成功事例は少なからず国内外に存在するため、今後、それらの事例をさらに広範囲かつ詳細に探索・検証することで、PBC 実施の課題や留意点を整理することが有効ではないか。さらに、「何はともあれ実際に行ってみることが重要である」「机上の検討ではなく、実フィールドでの検証を行うことで、リアリティのある成果が期待できる」という意見が多いため、試行的な実施（実証実験）等を行った上で、実施結果を検証することにより、PBC の課題や効果を把握するとともに、ガイドラインのリファインも期待できるのではないか。

一方、IT サービスにおける PBC は国内では議論の緒についた段階であるため、PBC の認知度も極めて低く、その効果や課題などもユーザ、ベンダ双方に十分に理解されていない状況である。PBC を広く認知させるための情報発信や意見交換などを行うことにより、更なる PBC の議論の活性化が期待される。

（別紙１）事例調査結果詳細

１．国内事例調査結果

【システム開発／IT アウトソーシング】

（1）システム運用 SLA（JAL）

JAL（日本航空）では重要度の高いシステムを対象にペナルティ付き SLA（Service Level Agreement）を導入してした。導入後、システム停止件数の半減という効果をあげている。

表 1 国内先行事例（JAL）

ユーザ企業	JAL
ベンダ企業	日本 IBM
委託・サービス提供形態	システム運用委託（IT アウトソーシング）
契約期間	2006 年 4 月～
契約金額	不明
KPI	システム障害件数、復旧時間
支払形態	固定＋ペナルティ
報酬・インセンティブ金額	不明
概要	・運行管理、搭乗券予約販売等の重要度の高い 30 システムが対象・ 2001 年より運用委託契約を結んでおり、当時はペナルティなしの SLA による契約であったが、海外の事例を参考にペナルティ付き SLA に変更・目的は「安定稼動」に向けた動機付け（コスト減ではない）・システム停止件数が 99 件（2005 年 4～12 月）から 44 件（2006 年 4～12 月）に半減・サービス停止から復旧までの時間と、障害の発生回数に応じてペナルティを設定

出典：日経コンピュータ 2006/12/11; 日経情報ストラテジー2007/1/29

（2）システム運用 SLA（リクルート）

リクルートでは自社システムの運用委託業務のコスト削減に対する動機付けとして、インセンティブを含む SLA 契約を導入している。

表 2 国内先行事例（リクルート）

ユーザ企業	リクルート
ベンダ企業	アークシステム、シーエーシー
委託・サービス提供形態	システム運用委託（IT アウトソーシング）
契約期間	2005 年 4 月～
契約金額	不明
KPI	CLA※（Collaboration Level Agreement）
支払形態	定額固定＋SLA によるインセンティブ
報酬・インセンティブ金額	不明
概要	・対象システムは、会計業務システム、アンケート集計システム、データウェアハウス、定期刊行誌製作システム・ SLA により、運用委託における品質の確保が目的・各運用サービスの適正な委託費を計算できる仕組みを構築（CLA の導入）・半期ごとの契約見直し時に CLA の削減目標を掲げ、達成した場合に効果の半分をベンダに還元する

出典：日経ソリューションビジネス 2006/12/11

※CLA（Collaboration Level Agreement）とは、リクルートが、自社システムの運用委託費を「見える化」するためにベンダ間で構築した、運用委託費算出の仕組みである。事前に定めたエリア毎に業務項目を洗い出し、その業務量と難易度、システムの重要性を加味した数値「CLA ポイント」を算出する。また、翌年度以降、定義した CLA ポイントに対して削減目標を立て、目標が達成できた場合は、削減額をリクルート・ベンダ間で 50%ずつ分配する。これにより、ベンダ側は効率化により売上額自体は減少するが利益率は向上する。（図 1 参照）

図 1 CLA を利用した契約のイメージ

出典：日経ソリューションビジネス 2006/12/11

図 2 CLA ポイントの算出例

（例）

CLA＝業務量×必要スキル×システムの重要度今年度： 100 × 1.2 × 1.5 ＝180

業務量2割削減

翌年度： 80 ×

（目標値）

1.2

× 1.5 ＝144

リクルート側の

効率化による成果

CLA point

達成できた場合

（180－144）×10万円（ポイント単価）＝

360万円コスト削減

⇒削減額の50%となる180万円をベンダに還元

180

50%

144

ベンダに

還元

今年度

翌年度

time

出典：日経ソリューションビジネス 2006/12/11

（3）システム運用 SLA（岐阜県）

岐阜県では、情報システムの開発・運用委託サービスを対象にペナルティ付き SLAを導入しており、情報システムの再開発で 66 億円、7 年間の運営経費で 35 億円のコスト削減効果を期待している。

表 3 国内先行事例（岐阜県）

ユーザ企業	岐阜県
ベンダ企業	NTT コミュニケーションズ（再委託先：アクセンチュア、 EDS、セイノー情報サービス、河合塾等）
委託・サービス提供形態	情報関連業務を対象とした戦略的アウトソーシング
契約期間	2001 年 4 月～2008 年 3 月
契約金額	115 億 5 千万（7 年間）
KPI	• SLA（情報システム分野の業務で 43 項目を設定） • VE（Value Engineering）提案
支払形態	• 固定＋SLA によるペナルティ • VE 提案によるインセンティブ
報酬・インセンティブ金額	VE 提案によるインセンティブはコスト削減分の 50%
概要	・県の情報システムに関する業務と県内の情報関連産業の振興に関する包括的なアウトソーシング契約である・情報システム関連経費の削減や事務効率の向上を図るほか、アウトソーサーのもつ専門知識・グローバルネットワークの活用により県内産業の活性化を図るという戦略的目標を掲げている。これにより、行政の情報システムの再構築で 66 億円、運営経費を 7 年間で 35億円節減の成果を期待している・新技術や発案等によってサービスのコストを低減できる場合は、ベンダから VE 提案を行うことができる

出典：日経コンピュータ 2006/12/11

（4）SNS サービス導入支援（キールネットワークス）

キールネットワークスでは、SNS（Social Networking Service）ビジネス立ち上げを行う企業に対し、SNS 導入の全コストを自社で受け持ち、提供サービスによって顧客が得た売上をベースに報酬を受け取る成果報酬の方式で契約を締結している。

表 4 国内先行事例（キールネットワークス）

ユーザ企業	SNS のビジネス企画を持つ企業
ベンダ企業	キールネットワークス
委託・サービス提供形態	IT アウトソーシング
契約期間	2005 年 4 月～
契約金額	不明
KPI	売上
支払形態	成果報酬
報酬・インセンティブ金額	不明
概要	・ SNS のビジネス企画を持つ企業に対し、ソフト込みのサーバを無料で提供し、売り上げの一定割合を得る仕組み・顧客側に初期導入コストはほとんど発生しない・ SaaS ベースでもサービス提供を行う予定

出典：日経ソリューションビジネス 2007/3/15

【SaaS／ASP】

（5）たのめーるプラス（xx商会）

たのめーるプラスはxx商会が提供する企業向け ASP 調達システムで、取引量に応じた従量課金契約を採用している。

表 5 国内先行事例（xx商会）

ユーザ企業	一般企業
ベンダ企業	xx商会
委託・サービス提供形態	調達システムの ASP サービス
契約期間	－
契約金額	不明
KPI	取引量
支払形態	従量課金
報酬・インセンティブ金額	不明
概要	・間接財、直接財などあらゆる商材の調達のxx管理を実現・初期導入費用不要、運用コスト等不要の完全従量型・ 243 社が利用（2006 年 12 月時点）

出典：日経ソリューションビジネス 2007/3/30;

xx商会 HP, xxxx://xxx.xxxxxx-xxxxxx.xx.xx/xxxxxxxx/xxx/

（6）フーズインフォマート（インフォマート）

フーズインフォマートはインフォマートが提供する外食産業向け受発注システムで、売り手企業は定額固定と従量課金の 2 パターンの支払形態から選択することができる。

表 6 国内先行事例（インフォマート）

ユーザ企業	食品メーカーや商社などの企業
ベンダ企業	インフォマート
委託・サービス提供形態	外食産業向け受発注システムの ASP サービス
契約期間	－
契約金額	・定額固定契約：25,000 円～／月・従量課金契約：売上額の 1%
KPI	取引量
支払形態	定額固定または従量課金契約
報酬・インセンティブ金額	不明
概要	・食品、食材の e-マーケットプレイスを ASP で提供・ 1 xxの顧客が利用、取引額は 2,000 億円／年（2006年）でフード業界 No.1 のサービス・売り手企業は、契約形態を定額固定と従量課金の 2 種類から選択可能

出典：日経ソリューションビジネス 2007/3/30

（7）ジェネリック通知サービス（NTT データ）

NTT データが提供する医療費削減の実現に向けた情報提供サービスであり、従量課金と成果報酬の 2 パターンの支払形態から選択することができる。

表 7 国内先行事例（NTT データ）

ユーザ企業	医療保険者（健保組合など）
ベンダ企業	NTT データ、データホライズン
委託・サービス提供形態	情報提供サービス（ASP）
契約期間	－
契約金額	－（初期費なし）
KPI	医療費、情報提供件数
支払形態	従量課金または成果報酬
報酬・インセンティブ金額	・従量課金：レセプト件数 1 件あたり 50 円を支払う・成果報酬：薬剤費削減額の 50%を支払う
概要	・医療保険者の持つ被保険者のレセプトデータを分析して、ジェネリック医薬品処方による薬剤費個人負担削減額を通知する「ジェネリック医薬品促進通知書」を出力し、被保険者ごとに情報提供を行う・ジェネリック普及率が欧米並みの 50%になれば（現状 16%）、約 1 兆円の医療費削減効果が期待できる

出典：NTT データ HP, xxxx://xxx.xxxxxxx.xx.xx/xxxxxxx/0000/000000.xxxx

（8）レコメンドサービス（シルバーエッグ・テクノロジー）

シルバーエッグ・テクノロジーは WEB サイト向けにレコメンドサービスを提供し、サービスによって生じた売上の 5～10%を受け取る成果報酬を採用している。

表 8 国内先行事例（シルバーエッグ･テクノロジー）

ユーザ企業	WEB ショッピングサイト業者
ベンダ企業	シルバーエッグ・テクノロジー
委託・サービス提供形態	レコメンドサービス（ASP）
契約期間	－
契約金額	不明
KPI	売上
支払形態	成果報酬
報酬・インセンティブ金額	売上の 5~10%
概要	・顧客ごとにお薦めの商品を WEB 上へ自動表示させることができるレコメンド（推奨）サービス・過去の商品購入者が他にどの商品情報を見たかを分析し、現在の利用者が閲覧している商品と関連性の高い品物を推薦する仕組み・初期費用は不要・報酬の割合は、サイトの規模などによって決定する

出典：シルバーエッグ・テクノロジーHP, xxxx://xxx.xxxxxxxxx.xx.xx/xx/xxxxxxxx/xxxxxxxx/;日経産業新聞 2007/05/15

【BPO】

（9）イーサポートリンクシステム（イーサポートリンク）

イーサポートリンクのイーサポートリンクシステムは、青果物の受発注を ASP で提供するサービスで、ASP サービスに加え販売店と小売店の需給調整等の BPO サービスも提供している。ASP はシステム処理件数および顧客の取扱高に応じた従量課金、BPOは取扱事務の作業量と顧客の取扱高に応じた従量課金を採用している。

表 9 国内先行事例（イーサポートリンク）

ユーザ企業	青果物生産者、流通業者、小売店
ベンダ企業	イーサポートリンク
委託・サービス提供形態	・青果物受発注システム（ASP）・需給調整、受注代行など 8 領域の業務委託（BPO）
契約期間	－
契約金額	不明
KPI	ASP：処理件数、顧客の取扱高 BPO：作業量、顧客の取扱高
支払形態	従量課金
報酬・インセンティブ金額	不明
概要	・青果物の受発注から入荷・出荷、入金・支払いまでの機能を ASP で提供・取扱高等に応じた従量課金契約のため、ある季節しか利用しないような小規模生産者でも利用可能・生鮮食品の国内市場におけるシステム活用による売買金額シェア：5%

出典：日経ソリューションビジネス 2007/3/30

（10）BPS（Business Processing Services）（日本 IBM）

日本 IBM が提供する業務プロセス改善の ASP 型のアウトソーシングサービスは、債権回収業務は成果報酬、それ以外は従量課金の支払形態が設定されている。

表 10 国内先行事例（日本 IBM）

ユーザ企業	一般企業
ベンダ企業	日本 IBM
委託・サービス提供形態	業務処理サービス（ASP）
契約期間	－
契約金額	不明
KPI	社員数、コスト等
支払形態	・成果報酬（債権回収業務）・従量課金（債権回収業務以外）
報酬・インセンティブ金額	不明
概要	・業務ノウハウを標準化して提供する ASP サービス・「購買」、「人材育成」、「債権回収」、「文書管理」、「人事」の 5 つのメニューを用意・ 2 ヶ月～5 ヶ月の短期間での導入が可能

出典：IBM, xxxx://xxx-00.xxx.xxx/xx/xxxxxxxxx/xx00/xxx/00_xxx0.xxx;日経ソリューションビジネス 2007/5/15;

日刊工業新聞 2007/3/14

（11）コクヨ BPO（コクヨビジネスサービス）

コクヨが提供するバックオフィス系の BPO サービスは、定額固定と成果報酬の 2 パターンの支払形態を用意している。

表 11 国内先行事例（コクヨビジネスサービス）

ユーザ企業	一般企業
ベンダ企業	コクヨビジネスサービス
委託・サービス提供形態	オフィス業務運用委託（BPO）
契約期間	－
契約金額	不明
KPI	コスト、利益
支払形態	定額固定または成果報酬
報酬・インセンティブ金額	不明
概要	・人事、総務、経理業務について、顧客企業のすべての業務と人員を一括して請け負うサービス・支払タイプ（定額固定または成果報酬）は請負内容により協議の上決定される

出典：コクヨビジネスサービス HP, xxxx://xxx.xxxxxx-xxxxxxx.xx.xx/

２．海外事例調査結果

【システム開発／IT アウトソーシング】

（1）ネットワークインフラ構築・運用（コネティカットコンベンションセンター）

コネティカットコンベンションセンターでは、コンベンションセンターの収入の一部をトータルコミュニケーションズと分配する総収入を分配する契約を締結することで、予算不足の解消および継続的な設備改善を実現している。

表 12 海外事例（コネティカットコンベンションセンター）

ユーザ企業	コネティカットコンベンションセンター（Connecticut Convention Center ; CCC）
ベンダ企業	トータルコミュニケーションズ（Total Communications）
委託・サービス提供形態	ネットワークの構築、管理（IT アウトソーシング）
契約期間	2004 年 11 月～
契約金額	不明
KPI	コンベンションセンターの収入
支払形態	成果報酬（総収入を分配）
報酬・インセンティブ金額	不明
概要	・コンベンションセンター設立に際して、競合センターとの差別化として無線のネットワーク設備を構築する計画を立てた・予算が不足していた中でネットワーク環境を計画通り構築するために、構築費用としては支払わず（ベンダ負担）、イベント等で得られたコンベンションセンターの収入に対して一定の割合をベンダに支払う総収入を分配する契約を締結した・本契約により、CCC は 30 万ドルのコストを削減できたと評価している・本契約により、CCC はベンダに顧客側の要望や新技術に対応してネットワーク環境を定期的にアップグレードするインセンティブを持たせている・ SLA によるペナルティ／インセンティブを含んだ契約かどうかは不明

出典：Outsourcing Journal, “Service Provider Shares Risks, Rewards, and Revenue with Major Convention Center,” January, 2007,

URL: xxxx://xxx.xxxxxxxxxxx-xxxxxxx.xxx/xxx0000-xxxxxxx.xxxx

（2）IT サービスセンター運営 SLA（保健社会福祉省）

保健社会福祉省は、ユニシスと運用保守に関する SLA を導入し、この達成レベルに応じたインセンティブ／ペナルティを含む契約を結んでいる。

表 13 海外事例（保健社会福祉省）

ユーザ企業

保健社会福祉省（U.S.Department of Health and Hu

man Services ; HHS）

ベンダ企業

（米）ユニシス

委託・サービス提供形態

IT サービスセンターの開発、運用、ネットワーク管理、

ヘルプデスク等（IT アウトソーシング）

契約期間

2005 年から 3 年間（1 年×2 回の延長オプション付き）

契約金額

6500 万ドル（2 年延長時、最大で合計 1 億ドル）

KPI

SLA（①ネットワーク可用性、②アプリケーション可用性、③データ可用性、④ヘルプデスク着信時間、⑤⑥ヘルプデスクリードタイム（2 項目）、⑦データ消失率、⑧

データ復旧時間、⑨アカウント管理の 9 項目）

支払形態

固定＋インセンティブ／ペナルティ

報酬・インセンティブ金額

契約の 85%が金額固定、残りの 15%が SLA によるイン

センティブまたはペナルティ

概要

・契約期間の中で支払金額が逓減する支払方法を採用することで、HHS へコスト削減を保証すると共に、ユニシスへ業務改善の意識を強く植え付けた

・改善例の一つとして、システムの問題発生からユーザへの初回連絡時間について、契約前の IT サービスセンターで実施できた改善は 22%程度だったが、ユニシスはリモート管理装置を導入することにより 94%改

善した

出典：HHS, “Exhibit 300: IT Service Center,” February 5, 2007, URL: http:

//xxx.xxx.xxx/xxxx/xxxxxxxxxxxxxxx/xxxxxxx000/XXX/xxxxxxxxxxxxxxxxx. pdf; Federal Computer Week, “CIOs Chart New Path of Partnership,” J anuary 9, 2006, URL: xxxx://xxx.xxx.xxx/xxxxxxx00000-00-00-00-Xxxxx; HHS, “Fiscal Year 2008: Justification of Estimates for Appropriatio ns Committees,” URL:xxxx://xxx.xxxx.xxx/xxxxxx/xxx/xx00xxxx.x xx

（3）基幹系システム構築 SLA（バンガードカーレンタル）

バンガードカーレンタルは、SLA の達成／未達成が及ぼすビジネスへの影響を考慮したインセンティブ／ペナルティを付加した SI 契約をペローシステムズと結んでいる。

表 14 海外事例（バンガードカーレンタル）

ユーザ企業	バンガードカーレンタル（Vanguard Car Rental）
ベンダ企業	ペローシステムズ（Perot Systems）
委託・サービス提供形態	基幹系システムの構築委託
契約期間	2003 年 11 月から 10 年間
契約金額	2 憶 7500 万ドル
KPI	SLA（リードタイム等）
支払形態	固定＋インセンティブ／ペナルティ
報酬・インセンティブ金額	不明
概要	・バンガードカーレンタルは、ペローシステムズと取り決めた SLA をもとに、その達成／未達成がバンガードカーレンタルのビジネスにどのようなインパクトを与えるかを試算し、試算結果からインセンティブ／ペナルティ額を設定した・ヘルプデスクサービスにおいて、通常の問い合わせに対して 4 時間以内に解決するとした SLA に対して、平均 3 時間以内での解決を達成といった実績が得られている・契約変更やスコープ外の業務が発生した場合も、ペローシステムズは価格の再査定を実施せず対応した。その見返りとして、年間である一定レベルのビジネスをペローシステムズに発注することを保証する契約が取り交わされた

出典：Computerworld, “Mechanics of a Merger,” February 14, 2005, URL: http:/

/xxx.xxxxxxxxxxxxx.xxx/xxxxxxxxx/0000/0,0000,00000,00.xxxx; Outsourcing Journal, “Best ITO: Buyer Backs Out of Bankruptcy and Drives Into Xxxxx cial Success by Outsourcing Everything IT,” August, 2006, URL: xxxx://x xx.xxxxxxxxxxx-xxxxxxx.xxx/xxx0000-xxxxx.xxxx

（4）ネットワークインフラ構築（米国運輸保安局）

米国運輸保安局では空港間のネットワークインフラ構築に関するユニシスとの契約において、固定価格、コストプラス、インセンティブ型等の複数を組み合わせた支払形態を採用している。

表 15 海外事例（米国運輸保安局）

ユーザ企業	米国運輸保安局（Transportation Security Administration ; TSA）
ベンダ企業	（米）ユニシス
委託・サービス提供形態	ネットワークインフラ構築委託
契約期間	2002 年 8 月～3 年間（2 年×2 回のオプション付き）
契約金額	最大 10 億ドル
KPI	不明
支払形態	固定＋インセンティブ／ペナルティ
報酬・インセンティブ金額	不明
概要	・ 2002 年 11 月 19 日までに、本部と国内の 429 空港等を結ぶネットワークインフラを構築した・ 2002 年 12 月 31 日までに、国内の空港間を高速のインフラで接続し、電子監視装置を導入、エアポート・コマンドセンター、国土安全保障省のアプリケーションとの統合、地上移動無線の相互連携等の実現した・ 2006 年初めまでで、支払は 8 億 3400 万ドルを超えている

出典：米国国土安全保障省（DHS：Department of Homeland Security）, xxxx://xxx.xxx.xxx/xxxx/xxxxxx/xxxxxxxx/XXX_00-00_Xxx00.xxx

（5）既存税金システム更改（アリゾナ州税務局）

アリゾナ州税務局では、歳入の増加を KPI として徴税率の向上に対するインセンティブをベンダに与え、結果として当初計画を上回る歳入増になる見込みである。

表 16 海外事例（アリゾナ州税務局）

ユーザ企業	アリゾナ州税務局（Arizona State Department of Revenue ; AZDOR）
ベンダ企業	（米）アクセンチュア
委託・サービス提供形態	システム開発・運用委託
契約期間	2002 年 8 月から 10 年間
契約金額	－（初期費なし）
KPI	州の歳入増加
支払形態	成果報酬（総収入の分配）
報酬・インセンティブ金額	不明（ベンダのコスト額回収までは、歳入増加分の 85％を受け取る）
概要	・老朽化した既存の税金システムの更改・政策上の優先事項や財政難のため、必要な予算の獲得が困難であった・初期投資コストはベンダの負担とし、歳入の増加分を発注者とベンダでシェアするスキームとした・システムの近代化に伴う徴税率のxxxにより、当初は 10 年間で 4 億円の歳入増が期待されていた・最終的な歳入増は当初計画を上回る見込みである

出典： NASCIO(全米州政府 CIO 協議会), ”Innovative Funding for Innovative State IT: New Trends and Approaches for State IT Funding”

【SaaS／ASP】

（6）オンデマンド型の保険アプリケーション（カナダ生命）

カナダ生命は、保険加入者数にもとづいた従量課金契約を IBM と結んでいる。

表 17 海外事例（カナダ生命）

ユーザ企業	カナダ生命（Canada Life）
ベンダ企業	（米）IBM
委託・サービス提供形態	オンデマンド型の保険アプリケーションの提供（ASP）
契約期間	2003 年 3 月～
契約金額	不明
KPI	保険契約者数
支払形態	従量課金
報酬・インセンティブ金額	不明
概要	・アプリケーションで処理された保険証の数にもとづいた契約である・「カナダ生命から要求されたアプリケーションの変更要求に対して、一定期間内に実装を行う」という内容の条件が契約に含まれている

出典：IPA ニューヨークだより 2006 年 2 月 xxxx://xxx.xxx.xx.xx/xxxxx/XXxxxxxx/0 00602.pdf; Network World, “New Deals Tie Fees to Revenue,” May 26, 200 3, URL: xxxx://xxx.xxxxxxxxxxxx.xxx/xxxx/0000/0000xxxxxxxxx.xxx x

【BPO】

（7）人事管理 BPO（ブリティッシュテレコム）

ブリティッシュテレコムは、アクセンチュアと人事管理に関するアウトソーシングサービス契約を結んでおり、対象の業務量または、サービスの利用量にもとづく従量課金体系を採用している。

表 18 海外事例（ブリティッシュテレコム）

ユーザ企業	ブリティッシュテレコム（British Telecom ; BT）
ベンダ企業	（米）アクセンチュア
委託・サービス提供形態	人事管理業務委託（BPO）
契約期間	2005 年 2 月から 10 年間
契約金額	5 億 7500 万ドル（想定額）
KPI	業務量、利用量、SLA（コスト、従業員満足、品質、サイクルタイムを基準としたもの）
支払形態	従量課金＋SLA によるインセンティブ／ペナルティ
報酬・インセンティブ金額	不明
概要	・ 2000 年～2004 年までの間は、BT とアクセンチュアの共同出資で設立した会社からアウトソーシングサービスを提供されていたが、2005 年に 10 年間でコストを 34%削減する目標を立て、再契約を行った・ BT は、人事管理業務のコスト管理について各部門長へ動機付けを行いたいと考え、業務量、あるいは利用量に応じたプライシングに変更した・ SLA 未達成の場合はペナルティに加えて改善措置を要求される・提供している 190 のサービスにつき 1 つ以上の SLAが設定されている（基本的に、コスト、従業員満足、品質、サイクルタイムを基準に測定）・効果測定に対する負担を軽減するために、パフォーマンスの測定は190 のサービスのうち費用の80%を占める 30 項目のみ行うこととした

出典：Outsourcing Journal, “Calling For Help: Outsourcing Helps BT Reinvent Itself,” August, 2006, URL: xxxx://xxx.xxxxxxxxxxx-xxxxxxx.xxx/xxx00 0 6-accenture.html; HRO Europe, “Second Time Around,” May, 2005, URL: h ttp://xxx.xxxxxxxxx.xxx/Xxxxxxxx.xxx?xxxXXx00 0

（8）罰金徴収センター業務 BPO（ミズーリ州立裁判所）

ミズーリ州立裁判所では、罰金徴収センター業務の BPO をアフィリエーテッド・コンピューター・サービシズに委託し、罰金徴収件数を KPI とした契約を締結している。

表 19 海外事例（ミズーリ州立裁判所）

ユーザ企業	ミズーリ州立裁判所（Missouri Office of the State Co urt Administrator）
ベンダ企業	アフィリエーテッド・コンピューター・サービシズ（Affiliated Computer Services ; ACS）
委託・サービス提供形態	罰金徴収センターの業務改善（BPO）
契約期間	2004 年 5 月から 6 年間（5 年延長のオプション付き）
契約金額	－（初期費なし）
KPI	罰金の徴収件数
支払形態	従量課金
報酬・インセンティブ金額	1 件の罰金徴収ごとに 6.95 ドル
概要	・罰金徴収センターの職員が本来業務に注力するために、それまで非常に多くの時間を要していた徴収業務のアウトソーシングを委託した・徴収できた額の大きさに関係なく、1 件の徴収成功ごとに 6.95 ドルを支払う契約である（1 件あたりの平均罰金額：110 ドル、罰金額の幅：10～458 ドル）・罰金支払のオンライン化等、センターの運営業務改善を実現した・アウトソーシング開始前は 27 人の職員で州立裁判所と 65 の市立裁判所を対象に 132,700 件を処理していたが、開始後は 19 人の職員で州立裁判所と 90 の市立裁判所を対象に 187,700 件を処理・本サービスにより、ACS はミズーリ州に約 200 万ドルの価値を生み出したと評価されている・ ACS は以前よりミズーリ州からシステム開発を受託しており、本件が更なる関係強化につながった

出典：IPA ニューヨークだより 2006 年 2 月 xxxx://xxx.xxx.xx.xx/xxxxx/XXxxxxxx/0 00602.pdf; Washington Technology, “ACS Picks Up Fine Collection Work in Missouri,” May 19, 2004, URL:xxxx://xxx.xxxxxxxxxxxxxxxxxxxx.xxx/xxxxxx

/1_1/23538-1.html

（9）電子政府ポータルサイト運営 BPO（テキサス州情報リソース局）

テキサス州情報リソース局では、ポータルサイトの収益の一部を支払う総収入を分配する契約を結んでおり、プライシングではベンダ側の事業リスクに対するヘッジとインセンティブをもたらすような工夫を行っている。

表 20 海外事例（テキサス州情報リソース局）

ユーザ企業	テキサス州情報リソース局
ベンダ企業	（米）ベリングポイント
委託・サービス提供形態	電子政府ポータルサイトのアウトソーシング（BPO）
契約期間	2000 年 9 月から 9 年間（最初の 1 年間＋1 年間の延長× 4 回＋4 年間の延長）
契約金額	－（初期費なし）
KPI	ポータルサイトの収益
支払形態	成果報酬（総収入の分配）
報酬・インセンティブ金額	不明（ベンダの損益分岐点に達するまではポータルの収益の 90％、到達以降は 50％を獲得）
概要	・州政府および地方の政府機関による市民に対するオンラインサービス提供のための電子政府ポータルサイトである TexasOnline の開発、運用、メンテナンス・ TexasOnline は、ポータルの運用をサポートするインフラサービスと、州の各政府機関および地方の政府機関を代表して開発・運用されるアプリケーションサービスよりなる・税収からの支出は行わず、データ販売、およびサブスクリプション・フィーまたはコンビニエンス・フィーの徴収を許可するハイブリッドモデルを採用・ 2005 年にはベンダは損益分岐点に到達している

出典： NASCIO(全米州政府 CIO 協議会), ”Innovative Funding for Innovative State IT: New Trends and Approaches for State IT Funding”

（別紙２）問題意識調査結果詳細

ユーザ企業およびベンダ企業への調査結果の詳細をそれぞれ以下に示す。なお、インタビュー先企業の希望もあり、すべての企業名を明示しないこととした。

（1）ユーザ企業へのインタビュー結果

1）情報システムの価格に関する問題意識

🞏 自社で懸案となっている情報システムの価格に関する問題点

【まとめ】

パフォーマンスベース契約やシステム開発におけるインセンティブ支払といった、ソフトウェアの付加価値を評価（特に経営の視点から）する方法論がはっきりとしていないのが大きな問題であり、例えばパッケージ価格に対する納得感が得られないといった現状がある。

【インタビュー結果】

⮚ システムを適用するプロセスが可視化されていない等の個々の問題もあるが、大きな問題はパフォーマンスベース契約やシステム開発におけるインセンティブ支払といった仕組みを、どのように適用するかという方法論がはっきりとしていないことである。

⮚ ソフトウェアビジネスを付加価値型産業にどのように移行するかが課題となっているのではないか。米国は既に移行していると思う。

⮚ ユーザ側としては、情報システムの価格の原価構造をしっかり把握したい。

⮚ 業務パッケージやミドルウェアそのものは必要だと考えているが、パッケージソフト

（CD1 枚）が数億円といわれると非常に割高感がある。また、価格に対して、品質が低すぎるパッケージも存在する等、パッケージソフトの価格には納得がいかないことが多い。

⮚ 情報システムに係るコストの妥当性について根拠を適切に説明できないことが、経営会議において問題となっている。

⮚ 経営の視点での情報システムの価値貢献という観点で根拠を説明できるようにしなければならないと考えている。

🞏 従来型（人月価格ベース）の見積や価格交渉に対する問題意識

【まとめ】

ユーザ企業の経営目線（アウトカム）から、システムにおける KPI を決定し、そこからシステム価格が算出されるのが本来あるべき姿だという意見と、人月価格そのものではなく人月価格にエンジニアの業務知識や開発経験が反映されていない現状が問題だという意見があった。

【インタビュー結果】

⮚ ソフトウェアビジネスを付加価値型産業にどのように移行するかが課題となっているのでは。米国は既に移行していると思う。

⮚ 現在の新規システム開発は、何を作るかが決まっている世界であり、KPI もインプットまでしか見られない傾向があるが、ユーザからすると、アウトカムからトップダウンで KPI を決めるのが本来の姿ではないか。ただし、ユーザ企業にベンダを使いこなす CIO がなかなかいない現状がある。

⮚ 人月価格ベースが主流のままだと、必ず価格競争になり、その結果、大手ベンダしか生き残れないだろう。

⮚ 人月価格の手法そのものが悪いのではなく、現状において、人月価格にエンジニアの業務知識や開発経験が反映されていないのが問題ではないか。ゼネコン業界と比較しても、IT 業界は個々人のスキルの良し悪しが非常に分かりにくいため、エンジニアリングや経済産業省の ITSS（IT Skill Standard）等を活用して、もっと可視化できればいいと思う。

⮚ 基本的にファンクションポイントにもとづく人月価格ベースでの価格交渉を行っているものの、実際はファンクションポイントの生産性を人月単価で算定せざるを得ない現状がある。

⮚ 開発ベンダもさらに再委託している場合が多いため、ベンダと再委託先との間での価格交渉も適正に実施される必要がある。

⮚ 特定のベンダとの取引を長期的に維持しながら育成するという観点では、人月価格での契約の方が良いかもしれない。

2）自社における開発調達時・保守運用時の QCD 評価の実態

🞏 システム調達および保守運用における QCD の評価の取組み、評価項目

【まとめ】

システム開発においては、QCD のバランスに加え、開発におけるリスクも評価している。また、保守運用については RFP や契約条項に SLA を活用することにより、トラブル件数の削減、トラブル発生時のユーザ・ベンダ間の責任分担の明確化を実現している。

【インタビュー結果】

⮚ オフショアを活用する場合は、リスクプレミアムを考慮する必要がある。例えば、インドの人件費の相場がたとえ日本の 30％でも、リスクプレミアムを考慮すると、実際の投資額は 50％程度にしか抑えられない。

⮚ 保守運用は、10 年前は自前だったが、現在は、基本的に複数ベンダにアウトソーシングしている。その際には、RFP や契約内容を細かく規定し、SLA を活用している。そのため、トラブル件数の削減、およびトラブル発生時のユーザ、ベンダ間の役割分担がより明確になった。ユーザ側だけでなく、ベンダ側の負担も低減されているはずである。

⮚ システム規模の大きさに応じて、システム開発に関する報告をプロジェクトの開始時、完了時に経営会議で実施している。

⮚ 開発中のバグ数といった指標よりも、開発後のそのシステムを活用したユーザ満足度を報告することによって経営戦略に寄与できているかどうかを判断してもらえると考えている。

⮚ システム運用における長時間停止の回避、障害時の早期復旧といった SLA を過去に設けていた実績がある。現在は運用ベンダのレベルがかなり向上したこともあり、 SLA をあえて設けていない。

⮚ システム開発後のファンクションポイントの妥当性や品質の分析については、開発ベンダと共同で行っている。分析結果を即、次年度の契約に活用できるわけではないが、長期的視野で捉えると、開発の委託先間との適切な契約締結への改善に寄与していると考えている。

⮚ システム運用の評価指標については、毎年見直しをかけており、過去のデータを蓄積することによって結果数値の妥当性を判断できるようにしていきたいと考えている。

🞏 自社の業界、あるいは自社としての情報システムの価格、品質の標準の有無

【まとめ】

競争が激しい業界・業種では、価格、品質だけではなく、サービスをカットオーバーするまでに時間をいかに削減できるかの関心が高まっている。また、ベンダロックインによるシステム投資額の高止まりを防止するためのオープン化、マルチベンダを採用しているユーザも存在する。

【インタビュー結果】

⮚ 競争が激しい業界では、新商品のアイディアはどの企業も保有しているが、システム構築も含めどれだけ速くリリースできるかが勝負となる。また、そのような業界では機会費用（オポチュニティ・コスト）をベンダへのインセンティブに回す傾向がある。具体的には、システムが早く完成すれば、その分の機会費用をインセンティブにする。

⮚ SaaS のようなサービスを利用するとしても、同じサービスを自前で構築した場合のコスト試算は、社内を納得させるためにも不可欠となる。

⮚ 現状のシステムはオープン化が推進されているが、1 社に取り込まれることがないよう、マルチベンダ方式を採用している。その際には、ベンダ側に他社製品を使った SIに対応してもらったり、システム部門に優秀な人材を保有することにより、ベンダへの丸投げは行わないよう留意してベンダからの提案が妥当かどうかを判断できるようにしている。

⮚ 品質面に関する評価指標の立案は、ベンダ主体で実施しており、内容の確認をこちら

（ユーザ）とともにレビューしている。評価指標は、現状はプロジェクト毎に設定しているが、プロジェクトに依存しない標準化した評価体系にしてほしいという要望もあがっている。

🞏 開発完了時および一定期間の運用後のベンダへのインセンティブ（追加費用）支払実績の有無

【まとめ】

IT アウトソーシングにおける生産性向上、ASP サービスの利用といったシーンで、成果のパフォーマンスに応じたインセンティブを支払うケースが見られる。

【インタビュー結果】

⮚ IT アウトソーシングにおいて、生産効率の向上分に合わせてインセンティブを付与した。具体的にはベンダ独自の開発手法により、毎年 15％の開発効率向上という提案があったので、実現した際に改善された金額の 50％をインセンティブとして付与することにした。

⮚ 当初はカスタムメイドで構築予定であったシステムを、ベンダが新規開発する ASPサービスとして提案してきたので、支払形態を「新サービスの開発費用を販売予定ユーザ数で割った金額＋5 年間の利用料（インセンティブ）」という形にして利用することにした。このスキームにおけるベンダ側のメリットは、サービス開発前からファーストユーザがつくことによる初期投資額を抑制できることである一方、ユーザ側のメリットはカスタムメイドの場合よりも大幅に少ない金額で投資を実現できたことである。

⮚ 10 年くらい前、1 度だけ実施したことがある。ただし、当初からインセンティブ契約を行おうというものではなく、あくまで結果的にインセンティブ契約に結びついたというものである。具体的には、多大な時間をかけて調整した結果、ユーザが自前で運用するよりも、xx 億のコストが下がるのだから、削減分をユーザ・ベンダ間で折半するという流れになった。

🞏 自社におけるパフォーマンスベース契約の実績

【まとめ】

民間のユーザが公開するモチベーションがわかないことから世の中に広く知られていないが、パフォーマンスベース契約を実施しているユーザは確実に存在している。その一部ではユーザの社内制度と連動させた（ex．業績評価制度と連動）高度な取組みも見られる。

【インタビュー結果】

⮚ パフォーマンスベース契約のシステム開発を実施した際には、成果を IT 部門の人員の業績評価に結びつけた。具体的には、利益を創出した金額に応じてボーナスを支給した。しかし、こういった成功事例は、ユーザ側のモチベーションがわかないため、なかなか公開されない現状がある。

⮚ 過去の海外事業展開時に海外の SIer と一度、パフォーマンスベース契約を実施したことがある。

⮚ （IT 以外の）資材調達において、当初の予算額より実際の額が軽減できた際に、その差額をメーカーと折半したケースがあったため、システム開発においてもインセンティブをベンダと折半しようという考えはあるが実現には至っていない。

3）パフォーマンスベース契約の実現性

🞏 パフォーマンスベース契約実施の背景や定義・分類の妥当性

【まとめ】

「アウトカム」→「アウトプット」→「インプット」という順でシステムを評価すべきという議論をすると、業界・業種別の定義にはならないという意見があった。一方で、成熟していないソフトウェア業界でパフォーマンスベース契約を適用するのは時期尚早といった意見もあった。

【インタビュー結果】

⮚ 「インプット型」、「アウトプット型」、「アウトカム型」という分類は、ユーザからみても理解しやすい。また、インセンティブを付与する方法は、「インプット型」の場合は工数に対して、「アウトプット型」は実際に使えるシステムかどうか、「アウトカム型」の場合は、（開発したシステムを用いる事業において）創出されたベネフィット（利益やコスト削減額等）を折半する「Win-Win」というやり方になるのではないか。

⮚ ベンダ側の議論では、インプット型からの議論を始めることになりやすいが、そうなると「業界毎に異なる」という流れになりがちである。しかし、アウトカム型から議論をすると、それほど業界毎に違いはでないのではないか。

⮚ まだまだ属人的で、建設業界のようにエンジニアリングとして成熟していないソフトウェア業界で、いきなり PBC をやるのはxx、時期尚早である。現時点でも価格が不透明な状況なのに、この時点で PBC を実施するとますます価格の不透明となってしまい、ユーザから見ると納得感が得られず問題となる。

⮚ 従来型（人月価格ベース）より望ましい契約形態かもしれないが、ユーザ、ベンダの両方が積極的に取り組まなければ実現は困難だろう。

⮚ ベンダ側は、多重下請けにより利益をはじき出したいところが透けて見えるので、

PBC 実施を本当に望んでいるのか分からない。

⮚ PBC 実施には、ベンダ側の業界構造を変えていく必要があるのではないか。ゼネコン業界よりも複雑な構造だと思う。

🞏 パフォーマンスベース契約の適用可能範囲

【まとめ】

システム開発工程においても、再利用による削減コストのシェア、短納期開発、ハイレベルなエンジニアへのインセンティブ付与といった形で PBC を適用できそうである。ただし、業種・業務、アプリケーション種別、工期、ベンダとの関係等によっては PBC の適用が困難になる可能性が高い。

【インタビュー結果】

⮚ システム開発工程だけでも、KPI を適切に設定すればインセンティブを付与することは可能である。システム開発の RFP であっても、本来、事業目的や目標数値などアウトカムを明記すべきである。システムの仕様しか書かない RFP が多い現状は課題であるといえよう。

⮚ 枯れた技術の領域にパフォーマンスベースと言われても納得感は得られないだろう。

⮚ 既存システムをテンプレートとして活用することによって、別システムの開発コストが削減できるのであれば、削減分を既存システム保有企業と新規システム保有企業で折半するようなモデルは Win-Win の関係となるのではないか。

⮚ 在庫削減や売上向上（アウトカム型）となると、要因が多種多様になるため、システムの効果として因果関係を明確化するのは非常に難しいと思う。

⮚ 開発納期（QCD の D）の短縮や運用での作業時間の短縮（SLA）といった成果が分かりやすく、PBC の適用が可能だろう。

⮚ 大規模開発（2～3 年）については、インセンティブを入れやすいが、1 年程度の小規模開発については、改善といっている余裕もないので PBC を実施するのは難しいかもしれない。

⮚ スキルの高い SE やリスクマネジメントに秀でたプロジェクトマネージャーに対して、相応の価格が提示されるのはユーザとしては全く問題ではない。

⮚ システムにおけるコアな領域（例えば全社インフラ）は自社で、ノンコアな領域（個々の業務（パッケージ使用））はベンダ依存という条件で可能性を模索していくことになるだろう。

⮚ アウトプット型については、業務を改善することが、即システム開発・更新に結びつくと考えるのは現実的には難しい。

⮚ パフォーマンスベース契約を実現するには、目標を達成するためのユーザ、ベンダ双方の技術力強化が必要である。

⮚ これまでずっと人月価格でやってきた委託／請負開発モデルに比べて、SaaS、ASPといった領域は PBC を適用しやすい領域ではないかと思う

⮚ ベンダがユーザの情報システム子会社の場合は、長期での関係改善の方がより重視されるため、PBC には不向きな条件かもしれない。

🞏 パフォーマンスベース契約が実現した際のメリットや課題

【まとめ】

ユーザのメリットは、ベンダの能力を最大限引き出すことにより、システムの QCDを向上できる点である。ただし、ユーザ側に IT を活用する能力がある程度備わっていることや、改善効果を可視化することが前提となる。また、現時点で経営層や投資家に対してパフォーマンスベース契約の説明をするのは困難との声もある。

【インタビュー結果】

⮚ 成果にインセンティブを付与するパフォーマンスベース契約を使う目的は、ベンダがプロジェクトに本当に自信があるかどうかの試金石とすることである。特に何よりもベンダ側の優秀なチームを引き出したいのだが、本来はベンダから「優秀なリーダーをつけるから、インセンティブを付与してよ」という提案があるべきである。

⮚ システム開発でインセンティブ付与を実施すると、ユーザ、ベンダともに業務改善の提案を行うようになる。

⮚ ベンダの力を引き出そうとするのは、やはりベンダの方がシステム開発力が高いということと、ユーザの得意分野にリソースを集中投入するためである。

⮚ 課題としては、「アウトカム型」に近づくほど、評価が困難になるのではないか。

⮚ IT を活用する組織力がないと、IT 投資の効果が発揮されないため、まずはセルフチェック等により、組織力をはかることが重要である。

⮚ パフォーマンスベース契約実施時に、実際に改善された工数も示してくれれば、ユーザ、ベンダでコスト削減分を折半しようという納得感が得られる。しかも、改善の効果が小さかったとしても報告会のモチベーションが高められる。逆に改善成果をブラックボックス化されると、ユーザからみればどうしても懐疑的になってしまう。その意味では、ユーザが作業工数を把握することは、ベンダ、ユーザ間の信頼感を高めるためにも必要不可欠である。

⮚ 現在は、一流ベンダでも請負契約から委任契約にシフトする傾向が強いといったように、ベンダ側はリスクを排除することばかり考えているが、パフォーマンスベース契約をするには、ベンダ側にもリスクをシェアする覚悟が必要となる。

⮚ ただ現時点では、社内の経営層や投資家に対してパフォーマンスベース契約の考え方を説明するのは難しいと思う。

⮚ ベンダを萎縮させないためにも、ペナルティではなく、インセンティブに目を向けることが重要である。

⮚ アウトカム型のような目標に対しては、その目標達成にシステムがどの程度寄与したか測れるように定義する必要がある。

⮚ PBC を実現するために社内の予算制度の仕組みを見直す必要があり、適用へのハードルは高いといえよう。

（2）ベンダ企業へのインタビュー結果

1）情報システムの価格に関する問題意識

🞏 自社で懸案となっている情報システムの価格に関する問題点

【まとめ】

情報化戦略を策定しているか、強力な情報システム部門が存在する一部のユーザでは、開発工程における情報システムの価格設定により品質をコントロールしようとする試みがみられている。一方でシステム企画や保守・運用工程においては、ユーザ・ベンダ間の役割分担が不明確であり、価格設定も不明瞭になりやすい。

【インタビュー結果】

⮚ 何をどの位の価格で作るかが明確になっている建設業界に比べると、IT 業界は何をつくるかが見えにくいため、価格付けの根拠も不明瞭になりがちな点が問題である。

⮚ 情報システムの価格が機能ベースで決定されているが、本来は効能ベースで決定されるべきである。

⮚ ユーザが大企業であり、情報化戦略や情報システム部門がしっかりしている場合は、適切な価格での契約が実現できている。

⮚ システム開発においてコストオーバーするプロジェクトが多数存在する現状を改善するために、人月ベースの積み上げに、プラスαの追加事項を契約に組み込むことによって実現している事例も存在するといったように、情報システムの品質を、契約やプライシングによってコントロールできるのではないかと考えている。

⮚ 保守・運用フェーズに本格的にベンダが携わるようになったのは最近であることから、現状はベンダ・ユーザともに契約やプライシングに習熟していない。他にも、保守・運用のプロセスが、現状では明確に規定されていないため、ベンダ・ユーザ間の役割分担が不明瞭になり、システムの信頼性の低下やコストオーバーのリスクが生じているのではないか。

⮚ ベンダが携わる工程が、システム開発から、システム企画または保守・運用へと拡大される傾向がある一方で、ベンダ・ユーザともにコスト算出に習熟できていない。結果、例えば、次期システムの提案に SE が無償で対応していることが多い現状があったり、保守・運用に関わるあらゆる作業をベンダが実施しなければならなくなる結果としてコストオーバーとなったりとしている。

🞏 従来型（人月価格ベース）の見積や価格交渉に対する問題意識

【まとめ】

ユーザ側の IT の理解度や、見積を適用する業務範囲（ex.設計工程のコンサル等）によっては、人月ベースの見積や価格交渉をしても問題は生じないのでは。ただし、人月をかけるほど売上・利益につながる産業構造が優秀な人材を集まりにくくさせていると考えられる IT 業界の現状は問題である。

【インタビュー結果】

⮚ システム開発のうち、設計工程（特にコンサル業務）については、人月価格でも顧客の納得感が得やすい。

⮚ 情報システムの価格が機能ベース（あるいは人月ベース）で決定されるため、ベンダが提供する価値を適切に価格に反映できない。とりわけ、社会インフラとしての重要度を増している情報システムの価値は、人月では表しきれないのではないか。

⮚ 日本の IT 業界が人月をかけるほど売上および利益につながる産業構造であり、開発効率を高めるような工学的アプローチを適用しにくい現状になっている結果、優秀な人材（特に学生）が集まりにくくなっていることが何よりも問題である。

⮚ ユーザ側に IT に対する理解が備わっていると、人月ベースの見積でも、単価と工数を説明できれば、本来は問題にならないはずである。逆に情報システム部門の規模が小さい、もしくはそもそも設置していないユーザに対しては、契約金額の妥当性に関する説明がより重要となる。

⮚ 価格交渉については、ユーザ・ベンダ間での役割分担を明確化することが重要である。そうでなければ、どんな問題が発生してもベンダに丸投げされてしまい、結果としてコストオーバーとなるからである（特に、保守・運用フェーズ）。

⮚ ユーザの視点で見ると、商品がコモディティ(定価がある)か、そうでないかで価格に対する説明ロジックが異なってくると思う。

⮚ コンサルか、保守運用対応かといった業務内容によって、人月の考え方が異なる上、ユーザがシステム開発を理解しているかで、コストオーバーのリスクは異なる。

2）自社における価格の課題に関する取組み状況

🞏 見積や価格交渉における改善策

【まとめ】

内部統制への対応もあり、ベンダの多くが過去の開発経験に基づいたリスクの算定、開発標準導入による工数見積のベースライン整備、工程別契約といった取組みにより、見積精度の向上をはかっている。また、システム企画段階における IT 投資効果の算定も少しずつであるが普及しはじめている。

【インタビュー結果】

⮚ 顧客の次年度システム予算算定のために、開発計画にあがっていた情報システムの定量的なパフォーマンスを計測した経験があり、今後も積極的に顧客に提案して行きたい。

⮚ 見積精度の向上という点では、各システムのデータ収集や見積方法の精緻化、価格決定プロセスの標準化などに取り組んでいる。

⮚ あるユーザとの間では、システムの見積、価格および契約のやり方を、xx試行錯誤してきた結果、過去のシステム開発プロジェクト経験にもとづいたリスクを加味した見積の実施、ユーザの予算作成時に IT 投資効果の算出も含めた提案の実施等が実現できており、双方が満足できる関係を構築できている。

⮚ IT コーディネータ協会提供による『RFP･SLA ドキュメント見本」を利用する中小企業も増えてきているため、中小規模のユーザも SLA の指標測定といった考え方には慣れつつある。

⮚ 上流工程では、人月工数の視点ではなく、問題を解決するためのソリューションに視点を向けることによって、人月積み上げの従来の手法から脱却できないかと考えている。

⮚ 運用工程では SLA にもとづくプライシングが導入しやすいが、上流工程での SLA 適用には、非常に時間を要するのではないか。

⮚ ベンダが、ITSS を活用していく、または CMMI（ Capability Maturity Model Integration：能力成熟度モデル統合）のレベルを向上させる等により、見積もり精度を向上させることも重要である。

⮚ 標準化開発手法の導入による工数見積もりのベースライン整備、契約を一括請負ではなく工程ごとの契約にするといった、見積もり精度を向上させるための施策に取り組んでいる。

⮚ 内部統制等の観点から、契約内容にベンダ・ユーザ間の約束ごとをしっかり明記して、契約内容が客観的に問題ないことを証明することに着手している。

🞏 自社におけるパフォーマンスベース契約の実績

【まとめ】

ユーザとの間では、ASP（SaaS）方式のサービスや、保守・運用業務における SLA締結において一部実績が見られるが、大半は提案ベースにとどまっている。一方で、開発を他のベンダに外部委託する際には、ITSS や過去の開発実績をもとにした契約が行われている。

【インタビュー結果】

⮚ ASP（SaaS）方式のサービスにおいて、成果報酬型と従量課金型の 2 通りの契約タイプを用意している。

⮚ 当社から別会社に開発委託する場合は、ITSS を利用したスキル評価や実績にもとづく単価から契約金額を決めているので、パフォーマンスベースで契約金額が決定されると解釈できる。

⮚ あるユーザとの維持管理･運用業務の契約では SLA を締結しているが、ペナルティの導入までは行っていない。

⮚ 提案ベースでは、xxxからもパフォーマンスベースの話題があがることがあるが、実際の契約に結びついた実績は存在しない。

⮚ ASP サービスであれば、某企業と提携して医薬品情報提供サービスを実施している。

3）パフォーマンスベース契約の実現性

🞏 パフォーマンスベース契約実施の背景や定義・分類の妥当性

【まとめ】

まずは情報システムの「パフォーマンス」の定義や整理が必要だという声が多い。具体的な方法としては、事業モデル（請負、ライセンス、サービス等）ごとにリスク、品質、信頼性、ブランドといった観点で指標を整備していく。

【インタビュー結果】

⮚ インプット型（コストベース）のパフォーマンスベース契約の実施はリスクの可視化に近いのではないか。

⮚ パフォーマンスベース契約を実施するためには、IT を超えたコンサルティングの能力も重要になってくるだろう。

⮚ 「パフォーマンス」の定義が必要である。さらに品質や信頼性といった要素も価格に反映されるべきではないか。

⮚ PRM をベースにしたパフォーマンスベース契約の分類は、「請負」といった事業モデルをベースにした方が良いのではないか。ただし、経済産業省による 5 つの事業モデルでは各事業モデルの開発フェーズによる差異が考慮されない恐れがある。

⮚ パフォーマンスベース契約の実現には、商慣習の醸成やベンダ・ユーザ間の取引の可視化が必要条件となるため、非常に時間を要すると思う。

⮚ 「A さんが PM なら」といったブランドも、ユーザからみれば、価値（信頼感）を与えるかもしれない重要な要素といえるのではないか。例えば、パッケージベンダなどはブランドだけで高い価格での契約が可能である。

⮚ パフォーマンスベースとコストベースの定義にあいまいな点があるのではないか。例えば、SLA はパフォーマンスベースと関連性が高いと考えられているが、例えば、定期保守におけるパッチ対応は、SLA を満たすための作業としてパフォーマンスベースとして捉えられるのだろうか。

🞏 パフォーマンスベース契約の適用可能範囲

【まとめ】

システム開発以外の領域に対しては、パフォーマンスベース契約の適用のハードルは高くないが、システム開発に適用するためには、ベンダがこれまでのように言われたことだけをやるのではなく、何を作るべきかまで設計するといった IT コンサルの領域もカバーする必要がある。

【インタビュー結果】

⮚ システム開発において、納期短縮を実現した際の対価（特急料金）は PBC 実現の可能性がある。この場合はソフトウェア自体ではなく、開発プロセス・エンジニアリングのパフォーマンスに対する価格付けとなる。それとは別にサービス（BPO や SaaSなど）の、このモデルで言うアウトカム型やアウトプット型のパフォーマンスベース契約があるのではないか。

⮚ 運用・保守工程ではパフォーマンスベースの契約が考えられるが、システム開発における上流工程以外への適用はやはり難しいのではないか。上流工程では建築業界におけるコンサル（設計・監理）のように、全工程のモニタリングとチェックを実施する IT コンサルであれば適用できるかもしれない。

⮚ 例えば契約額の 80%を固定として 20%をパフォーマンスベースとするといったインセンティブは考えられないだろうか。

⮚ SaaS ではアウトカムを効果に訴求した提案が可能と思う。ただし、これは SaaS ベンダではなく、BPR を含めた IT コンサルの仕事であろう。

⮚ パフォーマンスベース契約を適用するための主な切り口としては、工程、契約形態となってくるだろう。

⮚ 「ユーザに見えやすい領域かどうか」という視点で適用しやすさを判断した場合、システム開発はユーザに見えにくい領域であるため、適用が困難といえよう。実現するには、調達仕様書の不足事項やユーザが認識できていない潜在ニーズの指摘といった領域をベンダが設計できるようになる必要がある。

⮚ ライセンスモデルのビジネスやレガシーからオープン化への移行が早い業界はパフォーマンスベース契約が促進されやすいのではないか。

🞏 パフォーマンスベース契約が実現した際のメリットや課題

【まとめ】

ベンダのメリットは、システム品質の向上、バリューへの対価の明確化等が考えられるが、特に開発効率化の追求を始めとするにエンジニアリング面での取組みに対するモチベーションが高まる点が大きい。反面、ベンダのビジネスリスクは増加する可能性もある。

【インタビュー結果】

⮚ ユーザ側から見たメリットとしては、説明責任が果たせる IT 投資の実現があげられる。一方、ベンダ側から見たメリットとしては、システム価値に見合った対価が得られることによる開発効率化へのモチベーション向上があげられる。

⮚ 最近のシステムは、使いようによって効果が変わるというのが背景にあるため、教育などによりシステムの効能を最大化するということがポイントになる。

⮚ ユーザ側の課題としては、投資効果の測定の煩雑さがまずあげられる。一方ベンダのビジネスリスクはこれまでよりも増加する可能性が高い。

⮚ ベンダのメリットとしては、収益の改善や、それによる社員への還元、システムの信頼性向上、実績による単価の向上が見込める、知名度向上によって受託する範囲(特に開発フェーズの上流)の拡大などが考えられる。

⮚ 現在ベンダはビジネスリスク管理ばかりに重点を置いているが、本来は開発手法などのソフトウェアエンジニアリングの向上に注力すべきである。ソフトウェアエンジニアリングへの取組み不足は、パフォーマンスベース契約の実現により打開できると思う。さらに日本のベンダがソフトウェアエンジニアリング）の強化にもっと取り組めれば、国際競争力を高めていくことにもつながるであろう。

🞏 パフォーマンスベース契約実施にあたって必要となる環境整備

【まとめ】

パフォーマンスベース契約の仕組みをある程度整備した上で、ユーザや関連団体の協力を得ながら、実フィールドに展開し、広く世の中に認識してもらうと同時に、実績データの蓄積およびフィードバック、リスク評価の標準化、法整備等による日本の IT 商習慣の変革を推進していく必要がある。

【インタビュー結果】

⮚ まずは世の中にパフォーマンスベース契約を広く認識してもらう必要がある。例えば納期短縮や機能別・工程別の調達等をする際に、難易度がどの程度あがり、リスクがどれだけ高くなるかを明確にする必要がある。さらに、この際のメリットおよびリスクを一覧化してマッピングできれば良いのではないか。

⮚ ベンダとしては、機能や仕様に対する価格に対する詳細な説明をできるようして、顧客から納得感を得られるようにする必要があり、そのためには、ベンダ内部でも営業担当者の教育の実施、各種資料・テンプレート等の準備と同時に、実績を蓄積、フィードバックできる仕組みを構築することが重要である。

⮚ パフォーマンスベース契約の定義やカテゴライズを精緻に行い、合意を得ることは難しいため、ある程度の整理をした上で、実フィールドに展開していくことが望ましい。この際には IPA（独立行政法人情報処理推進機構）、JIPDEC（財団法人日本情報処理開発協会）、財団法人機械振興協会等の関連外郭団体でモデル的な事業を立ち上げるのもよいのではないか。

⮚ ベンダは優秀な SE を提供する、一方ユーザは高い単価設定で報いるといった、ユーザとのパートナーシップが重要である。また、一括請負を行う SIer はユーザのパートナーとしてアウトカム指標の実現を目指すべきである。

⮚ アウトカムは業務範囲への踏み込みが必要となり、業務コンサルの領域に近いといえるが、SIer には経験が少ないため、業務の成果に対するコミットが障壁となるだろう。

⮚ 生産性やプライシングに高い影響を与えるアプリケーションドメイン（金融系の勘定系、法人系のポータル系等）毎に主要な属性を決めて、基礎データを蓄積する必要がある。

⮚ システム開発におけるリスクの評価手法を標準化する必要があるだろう。現状はユーザとの協力体制もままならず、まだまだ未成熟の状態といえる。

⮚ 法律の整備も含め、日本の IT 商習慣を変えていく努力が必要である。その結果としてパフォーマンスベース契約が受け入れられる土壌が整備されてくるように思う。

⮚ KPI は、開発アーキテクチャによって異なってくることを考慮すべきである。

（別紙３）研究会委員名簿

xx xx 城西国際大学経営情報学部客員教授＜座長＞xx xx 学習院大学経済学部教授

xx xx （社）日本情報システム・ユーザー協会専務理事

xx xx （社）電子情報技術産業協会

（(株)日立製作所

情報・通信グループ公共システム営業統括部公共ビジネス企画本部長）

xxxxx （社）電子情報技術産業協会

（日本ユニシス(株) 政策推進センターチーフ・スペシャリスト）

xx xx （社）情報サービス産業協会

（（株）オージス総研技術部長）

xx xx （社）情報サービス産業協会調査企画部次長

xx x 経済産業省商務情報政策局情報処理振興課課長補佐

（オブザーバ）

xxx xx 経済産業省商務情報政策局情報処理振興課係長

（事務局）

xx xxx （株）NTT データ経営研究所情報戦略コンサルティング本部パートナー xx xx （株）NTT データ経営研究所情報戦略コンサルティング本部マネージャー

xx xx （株）NTT データ経営研究所情報戦略コンサルティング本部ｼﾆｱｺﾝｻﾙﾀﾝﾄxx xx （株）NTT データ経営研究所情報戦略コンサルティング本部コンサルタントxx xx （株）NTT データ経営研究所情報戦略コンサルティング本部コンサルタントxx xx （株）NTT データ経営研究所情報戦略コンサルティング本部コンサルタント

Document Metadata

Table of Contents

4 PBC の定義とモデル 24

Document Metadata

4 PBC の定義とモデル 24

サービス提供形態

プライシング／支払形態

適用可能性適用 可能性

適用の適用の難易難易度度

PBPBCCの分の分類類

PBCの分類

適用の難易度

適用可能性

＝ ×

Document Metadata

適用可能性適用可能性