システム導入の『成功』の定義とは〜「独⽴したプロジェクト」ではなく「戦略プロジェクトの⼀部」としての評価が本当の満足度〜

株式会社エル・ティー・エス
執行役員

山本政樹

2018年7月13日

皆さんは「システム導入が成功する」とはどういう状態だと考えますか。ITの世界ではこれまでQCD（品質、コスト、納期）でシステム導入の成否を計るという考え方が主流でした。しかしながらQCDで計る考え方だけで良いのでしょうか。
新しい手法での開発や導入するシステムの特性によっては、旧来のQCDの観点では成否をうまく計れないこともあります。
今回のレポートではシステム導入の成否をどう定義するのかについて考察していきます。
なお、本レポート内の提言・意見については、著者の私見であることをあらかじめお断りいたします。

なお2003年と2008年の調査では「品質を満たした状態」を“QCD”による成功率の算出「（ユーザーが）計画通りに利用しており満足」と定義しています。一般的にソフトウェア品質というとソフトウェアに要求された機能を達成できたかという機能充足と、バグや誤システム開発の成功を計る考え方は多々ありますが、過去に動作、異常停止などはないかといった欠陥防止が主な観点で多用されてきた方法は「求められる品質を満たしたか」、すが、ここでは少しニュアンスが異なります。そしてこの品「予算内に収まったか」そして「予定納期に間に合ったか」

質という項目は2018年の調査から「品質」ではなく「満足という、“QCD（Qualty：品質, Cost：コスト, Delivery：納度」という項目に改められています。システムは最終的な期・スケジュール）”を指標として成功率を計るというもの

ユーザーの満足度が大切という観点からの改訂はとても納得です。日経コンピュータが数年おきに行っているシステム開できますが、過去の品質の定義も上記のようなものなので実発の成功率に関する調査（※1）では、QCD全てを満たした質的に同じ評価方法と考えて良いと思います。

プロジェクトを「成功したプロジェクト」として成功率の算出をしています。

このようなQCDを成功率の基本とする考え方は他の調査にも見て取ることができます。ユーザー企業のIT部門のコミュニティであるJUAS（日本情報システム・ユーザー協会）が毎年※1 システム開発の成功率に関する調査
過去3回実施
1回目：2003年「情報化実態調査」
2回目：2008年「プロジェクト実態調査」
3回目：2018年「システム導入/刷新プロジェクト実態調査」

行っている「企業IT動向調査」や「ソフトウェアメトリクス調査」でもQCDについては重点的に言及されており、システム開発において重視されている指標であることがよく分かります。

Open Copyright ©2018 LTS Inc. All rights reserved.

1

“QCD”では計れない本当の満足度

本来であればQCDを全て満たしたかという観点よりも、最終的に投入したコストやかけた時間以上の満足度を得られたか

日経コンピュータの調査では、プロジェクト成功率は回を追という観点で評価すべきです。

うごとに「26.7%（2003年）」「31.1%（2008年）」「52.8%（2018年）」と向上しています。特に10年の開きがアジャイルの時代にコスト・納期順守は必ずしも成功の条件ではないある2008年から2018年の間では成功率が20%以上も向上しており、関係者の方の努力の跡が見て取れます。この2018年の調査を扱った日経コンピュータ（2018年3月1日号）の表紙のタイトルは『半数が「失敗」』というセンセーショナルな

このような例だけでなく、当初予定したQCDを評価の尺度とタイトルでしたが、三つの項目をすべて満たして「成功」とすることは、すでに時代にそぐわなくなりつつあります。近

いう定義ですので、もう少し前向きなタイトルでも良かった

年、システム開発の方法論は要求機能を事前に完全に洗い出ように思います。

し、コストとスケジュールをしっかり見積もって計画的にプロジェクトを進める「ウォーターフォール型」から、小さなそれぞれの項目を見ると7割から8割程度は満足していますが、モジュール単位で動くソフトウェア（＝プロダクト）を作る

どれか一つでも欠けている要素があると「失敗」になってしことを重視し、要求機能の提示とプロダクト開発とスパイラまいます。三項目を完全に満たす案件が半数を超えるというル式に進める「アジャイル型」の案件が増えています。アのは素晴らしいことで、この10年で「システム開発は失敗がジャイル型のシステム開発では事前に完全な計画を立てるこ当たり前」から「成功が普通」となったことが分かります。とを重視せず、計画も頻繁に変わることを前提とします。このような「変わり続ける計画や要求に迅速に対応する」という前提の中では、これまでのようなQCDを基準としたプロプ ロジ ェク ト の成 否を計 る各 指標 の評価

81.8

80

ジェクト評価は機能しません。
78.5

79.0

コスト

イル開発ではソフトウェアを細かいモジュール単位に分割し、「計画通りの金額」「少ない金額」に収まる

75

特に影響を受けるのがコスト（C）と納期（D）です。アジャ
設計＆開発＆テストを繰り返して徐々にソフトウェア全体を構築していきます。当初に構築したモジュールの評価を受けて、後続のモジュールの開発計画が変わるため、当初の計画

72.0

満足度

70

ユーザー企業の経営層とエンドユーザーが「満足している」「やや満足している」と回答

スケジュール「計画通り」「前倒し」で完了0％に対する評価が成り立ちません。よって予定したコストやスケジュールに対して評価するのではなく、個々のモジュール単位で生産性やリードタイムを計ることが重要になります。
これらを計ることで、ある規模のモジュールに対してどの程度のコスト（工数）や時間がかかるのかを予測および評価可

スケジュール

コスト満足しているユーザ企業の経営層 エンドユーザー能になり、先の見通しが立てやすくなったり、開発チームごとの能力を比較評価することができるようになります。

出典：日経コンピュータ（ 2018 年 3 月 1 日号 ）なお「品質（満足度）」についても「当初予定した要求を中でも注目すべきは「品質（満足度）」です。システムは納しっかり実装したか」という狭い意味での「品質」は成り立期を満たそうが、予算内に収まろうがユーザーの役に立たなたないため、ソフトウェアへの要求の前提となるビジネスければ全く意味がありません。ですから三つの指標の中では（事業）の目標達成に寄与したかという観点が重要になりま

品質（満足度）が一番大切なのですが、2003年調査ではす。事業貢献度を直接、売り上げや顧客獲得数で計れるなら46.4%だった品質は、満足度に項目が変わった2018年調査でそれが一番ですが、目的達成度をユーザー満足度で計る、そは経営層で78.5%、エンドユーザーで79%ですから、素晴らのソフトウェアが想定していたユーザーにしっかり使われてしい変化です。

いるかを利用率で計るといった視点が大切になります。

例えば「大変に野心的なシステム開発で、途中に大きな困難かつて今があり予算の追加投入やスケジュールの見直しがありつつも、最後は素晴らしいシステムを稼動させた」案件があったとします。そして数年後に振り返り「その基盤があったからこそ

Q ：品質（言われたことを実現する）
・ 当初要求した機能の実装度
・ 欠陥（誤作動等）の少なさ（言われることは変わる）
・ ユーザー満足度・ リピート利用率

C：コスト（コスト総額）・ プロジェクトのコスト総額（開発生産性）
・ ある規模の開発にかけたコスト
・ 個々の要求に対する見積もりと実際の誤差

D ：納期（終わりがある）・ プロジェクト完了期限の順守（終わりがない）・ 個々の要求の実装期限の順守
・ 個々の要求の実装リードタイム

会社は大きな成⻑を遂げることができた」という事実に経営側も事業部側も合意しているシステムがあった場合、多くの人はこれを「成功」と考えると思います。しかし、前述の「QCD三項目全部を満たす」という前提に立つとこのシステム開発は「失敗」になってしまいます。苦労した関係者からすれば、これではあまりに残念です。

Open Copyright ©2018 LTS Inc. All rights reserved.

システム導入の目的に適した満足度評価が大切※2 現場のオペレーションを自動化して工数を削減する単純な自動化を狙ったシステムでも「効率化されて成功」ではありません。
そこには「効率化されたことによって空いた時間をなにに使うのか」という説明責任が生じます。
新しいシステムによって現場の仕事は楽になりエンドユーザーは喜ぶかもしれません。
しかし、システム化によって空いた時間は本当に事業の最終的なコスト低減に寄与したのでしょうか。
もしくはより高付加価値な業務に時間をシフトさせ、新たな価値の創出に寄与したのでしょうか。そこを計る必要があります。

ウォーターフォール開発であろうと、アジャイル開発であろうと、大切なのは最終的なユーザーの満足度です。コストや納期も大切な要素ではありますが、これが予定より多くかかったとしても経営や事業部といったユーザー側がその費用や時間の追加投入を超える満足をしてもらえるなら、その案件は「成功」と考えて良いでしょう。しかし、ここでしっかり問うべきことは「“経営やエンドユーザーが満足した“とはどういう状態なのか」ということです。”経営やエンドユーザーが満足すれば成功”という定義にも当然、落とし穴があ本当に大切なのはそのシステムが戦略目標の達成に寄与したかります。
例えば、過去の営業事例や提案書を共有して営業社員がより効果的に営業活動を出来るようにするナレッジマネジメント

このように大切なのは満足度を重視しつつ、その満足の中身のシステムを導入したとします。システムを積極的に使ってをしっかり問うことです。最終的に行きつくところはビジネいる人にとっては提案書作成が効率的になり、過去の知見のスの戦略目標の達成でなくてはいけません。このように考え活用でより高い品質で提案できるようになるので、評価は高るとシステム導入に際して、純粋にシステム関連のKPIだけく満足度が高いと言えます。一方で、この種のシステムはで導入成否を計ることが難しいということが分かります。さしっかりした啓蒙活動なしではシステムが定着しません。実きほど例に出したナレッジマネジメントの案件についても、際に想定通りの活用の仕方をした人はユーザーのごく一部で、システムのQCDより最終的にナレッジがしっかり活用され提営業社員の大半の人は「ちょっとした調べものが楽になっ案の質やスピードがあがり事業成⻑に寄与しているかを受注た」もしくは「それほど使っていないが、別に不満があるわ率やコンペにおける勝率といった業務上のKPIで計る必要がけではない」という程度の満足だとしたらどうでしょう。開あります。

発側からすれば当初の意図通りの機能を実装して、実際使っている人からの評判は良いのだから「満足度は高い」と言い

下記の調査はIT導入の案件をどのように評価するかに関して、たいところでしょうが、ビジネス上の効果を見ると疑念が残日本と世界を比べた調査の結果です。2015年の段階で日本でります。

は8割近くの企業がITを独立したプロジェクト投資と考えて、単独で評価するとしています。一方で世界の企業の実に6割

逆に導入後のタイミングで不満足ばかりのシステムが失敗とがITを戦略プロジェクト投資の一部に含め、単独で評価しなも言えません。ナレッジマネジメント関連のシステムは、導いとしています。世界ではもはやITは単独の評価尺度ではな入した後に価値あるナレッジを蓄積し、活用されてはじめていのです。

価値が出るため、効果がでるまでに時間がかかることがあります。ですから導入当初はナレッジが全然入っておらずユー

全世界

日本

ザーの満足度が低くなることは珍しくありませんが、それは時間と共にあがっていくこともあります。実際、弊社が関わった不動産会社のナレッジマネジメントシステム導入では、当初の大多数のユーザーの評判は必ずしも良いものではありませんでした。しかし、導入を推進したリーダーがナレッジの蓄積を推進し、活用を促した結果、徐々に定着しその会社になくてはならない仕組みになりました。このときは、このような効果が出るまでに2年〜3年かかりました。このように満足度は評価タイミングにも依存することがありますが、シITを独立したプロジェクト投資と考え、単独で評価する

ステム稼働後に数年経ってから満足度を計ることはあまりあITを戦略プロジェクト投資の一部に含め、単独で評価しないりません。
出典： ASCII.jp 「 ガートナーの CIO サーベイで浮き彫りになる日本の CIO の課題」
（ http://ascii.jp/elem/000/000/971/971970/ ） (2015/1/23)

システム導入の目的が単純な効率化、つまり自動化による人の作業時間の削減であれば効果は短時間で実感できますし、これからのITを含む戦略プロジェクト投資の評価は二段階に効果も定量的で算出しやすいところがあります（※2）。しなります。事業や戦略上の目標とKPI（評価指標）があり、かしここで例にあげたナレッジマネジメントやCRM、管理会

あくまでもその一部としてIT上の目標とKPIが紐づきます。以計、データ分析基盤といった情報分析や活用系のシステムは下に全社的にデータ重視のマーケティングを推進する活動を効果が出るまでに時間がかかる上、効果の創出はユーザー側するためにデータ分析基盤の構築を含む大きな取り組みを行の意識といった必ずしもシステムの出来の良し悪しではないう際を例にとって考えてみましょう。

要素に左右されます。

Open Copyright ©2018 LTS Inc. All rights reserved.

3【取り組みの目的】
マーケティングデータをより広く分析、活用することで、意思決定の迅速化や予測精度の向上を図る
開発プロジェクトの目標を達成しても、戦略目標が達成されなければ意味がない。

マーケティング部門の目標（こちらが戦略目標）

・各部門がデータを活用している（ユーザー利用率等）
・意思決定が迅速化している（市場投入サイクル等）
・予測精度が向上している（顧客需要等）
・これらが業績に反映されている（売上や顧客満足度等）

データ分析基盤開発の目標（開発プロジェクトの目標）

・ 要求した機能が実装されている
・ ユーザビリティへの満足度が高い・ 欠陥が少ない・ 期限までにシステムリリースされる・ 割り当てられたコスト内で開発される基盤を提供

最終的な目標はデータを活用することにより意思決定や予測

さらにいえばITプロジェクトにおいて導入後の評価がしっか精度を向上させることです。ですから、マーケティング部門りされることは多くはありません。事前評価、つまりプロ全体の目標として、データ活用により意思決定が迅速化してジェクト前の投資判断に対して、システム導入後の事後評価いることを市場投入サイクルで計ったり、需要予測の精度をが行われる割合はぐっと下がります。

予実比較で計ったりと、多方面からやり方そのものが変わっていることを測定しています。仮に想定した効果が出ていないとしても必ずしもシステム側の問題とは限りません。人・【ITプロジェクトにおける事前・事後評価の実施状況】

組織や業務、そしてシステムそれぞれの観点から対策を練る

事前評価

必要があります。この場合はQCD（アジャイルであれば生産事後評価性など）のIT関連のKPIは戦略プロジェクトを構成するKPIの常に実施

33.6%

常に実施

12.5%

一部であり、しかも決して最終的な成否を決めるKPIではあ

一部実施

46.6%

一部実施

59.4%

実施しない

19.8%

実施しない

28.2%

りません。このようなKPIの体系を決めていくには、ビジネ
スプロセスマネジメントを理解し、社内の主要なビジネスプロセス（業務）の目標達成度をどのようなKPIで計るのかという知見を持つ必要があります。
このようにシステムの評価には事業目標やビジネスプロセスのKPIといった事業の目線からみた戦略目標に対する評価と、その取り組みの一部であるシステム構築上の目標に対する評価の二段階で評価する必要があります。そして最終的な評価はあくまでも戦略目標に対する評価なのです。

“IT側からも積極的に評価尺度の提案を”JUAS （日本情報システムユーザー協会 ） 『 企業 IT 動向調査 2016 』 より

その意味ではQCDが尺度であったとしても、まずは事後評価がしっかりされているだけでよしとしなくてはならないのかもしれません。その先で経営や事業を巻き込んで戦略プロジェクト投資全体の評価指標を決めていくということは、一朝一夕には難しいようにも思えます。ただIT部門などのシステム導入側がビジネスプロセスとそのマネジメント手法を理解し、ITプロジェクトのQCDを超えた評価尺度を経営や事業側に提案していくことは可能だと思います。

このように考えるとシステム導入の最終的な成否はIT部門ではなく、経営側や事業部門側でないと計れないということがその際に必要となるのはビジネスプロセスに対する理解です。

分かります。よく考えれば当たり前のことですが、現実にはビジネスプロセスマネジメントにおける目標設定の考え方はシステム導入の一切はIT部門に任されてしまい、主体的に経決して事業側だけのものではありません。IT部門などのシス営や事業部門がその立場から戦略プロジェクト全体（と、そテム導入側もビジネスプロセスマネジメントへの理解を深めの一部であるところのIT）を評価するとはなかなかなりませることで、自分たちの責任の範囲内で計れるQCDでシステムん。前述のようにIT導入が単独のプロジェクトとして評価さ導入の成否を定義するのではなく、戦略プロジェクト全体とれてしまう日本だと、IT部門としては自分たちの責任の範囲してのシステム導入が事業や戦略上の目標をどれだけ達成で内で計れるQCDで成否を定義せざるを得ないというのが実情きたかという観点で成否を定義することが可能となります。

です。

株式会社エル・ティー・エス
https://lt-s.jp/
info@lt-s.jp

本書の全部または一部の複製・転載を禁じます。
本レポートは慎重に作成しておりますが、その正確性・完全性に関して、いかなる保証もするものではありません。
本レポートをもとに読者がとられる行動による一切の損害について、当社はいかなる責任も負うものではありません。
Open Copyright ©2018 LTS Inc. All rights reserved.