【レポート】システム導入の『成功』の定義とは

山本 政樹（LTS 執行役員）

アクセンチュア、フリーコンサルタントを経てLTSに入社。ビジネスプロセス変革案件を手掛け、ビジネスプロセスマネジメント及びビジネスアナリシスの手法や人材育成に関する啓蒙活動に注力している。近年、組織能力「ビジネスアジリティ」の研究家としても活動している。（2021年6月時点） 　⇒プロフィールの詳細はこちら

“QCD”による成功率の算出

システム開発の成功を計る考え方は多々ありますが、過去に多用されてきた方法は「求められる品質を満たしたか」、「予算内に収まったか」そして「予定納期に間に合ったか」という、“QCD（Qualty：品質, Cost：コスト, Delivery：納期・スケジュール）”を指標として成功率を計るというものです。日経コンピュータが数年おきに行っているシステム開発の成功率に関する調査^※1では、QCD全てを満たしたプロジェクトを「成功したプロジェクト」として成功率の算出をしています。

なお2003年と2008年の調査では「品質を満たした状態」を「（ユーザーが）計画通りに利用しており満足」と定義しています。一般的にソフトウェア品質というとソフトウェアに要求された機能を達成できたかという機能充足と、バグや誤動作、異常停止などはないかといった欠陥防止が主な観点ですが、ここでは少しニュアンスが異なります。そしてこの品質という項目は2018年の調査から「品質」ではなく「満足度」という項目に改められています。システムは最終的なユーザーの満足度が大切という観点からの改訂はとても納得できますが、過去の品質の定義も上記のようなものなので実質的に同じ評価方法と考えて良いと思います。

このようなQCDを成功率の基本とする考え方は他の調査にも見て取ることができます。ユーザー企業のIT部門のコミュニティであるJUAS（日本情報システム・ユーザー協会）が毎年行っている「企業IT動向調査」や「ソフトウェアメトリクス調査」でもQCDについては重点的に言及されており、システム開発において重視されている指標であることがよく分かります。

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

日経コンピュータの調査では、プロジェクト成功率は回を追うごとに「26.7%（2003年）」「31.1%（2008年）」「52.8%（2018年）」と向上しています。特に10年の開きがある2008年から2018年の間では成功率が20%以上も向上しており、関係者の方の努力の跡が見て取れます。この2018年の調査を扱った日経コンピュータ（2018年3月1日号）の表紙のタイトルは『半数が「失敗」』というセンセーショナルなタイトルでしたが、三つの項目をすべて満たして「成功」という定義ですので、もう少し前向きなタイトルでも良かったように思います。

それぞれの項目を見ると7割から8割程度は満足していますが、どれか一つでも欠けている要素があると「失敗」になってしまいます。三項目を完全に満たす案件が半数を超えるというのは素晴らしいことで、この10年で「システム開発は失敗が当たり前」から「成功が普通」となったことが分かります。

中でも注目すべきは「品質（満足度）」です。システムは納期を満たそうが、予算内に収まろうがユーザーの役に立たなければ全く意味がありません。ですから三つの指標の中では品質（満足度）が一番大切なのですが、2003年調査では46.4%だった品質は、満足度に項目が変わった2018年調査では経営層で78.5%、エンドユーザーで79%ですから、素晴らしい変化です。

例えば「大変に野心的なシステム開発で、途中に大きな困難があり予算の追加投入やスケジュールの見直しがありつつも、最後は素晴らしいシステムを稼動させた」案件があったとします。そして数年後に振り返り「その基盤があったからこそ会社は大きな成長を遂げることができた」という事実に経営側も事業部側も合意しているシステムがあった場合、多くの人はこれを「成功」と考えると思います。しかし、前述の「QCD三項目全部を満たす」という前提に立つとこのシステム開発は「失敗」になってしまいます。苦労した関係者からすれば、これではあまりに残念です。本来であればQCDを全て満たしたかという観点よりも、最終的に投入したコストやかけた時間以上の満足度を得られたかという観点で評価すべきです。

アジャイルの時代にコスト・納期順守は必ずしも成功の条件ではない

このような例だけでなく、当初予定したQCDを評価の尺度とすることは、すでに時代にそぐわなくなりつつあります。近年、システム開発の方法論は要求機能を事前に完全に洗い出し、コストとスケジュールをしっかり見積もって計画的にプロジェクトを進める「ウォーターフォール型」から、小さなモジュール単位で動くソフトウェア（＝プロダクト）を作ることを重視し、要求機能の提示とプロダクト開発とスパイラル式に進める「アジャイル型」の案件が増えています。アジャイル型のシステム開発では事前に完全な計画を立てることを重視せず、計画も頻繁に変わることを前提とします。このような「変わり続ける計画や要求に迅速に対応する」という前提の中では、これまでのようなQCDを基準としたプロジェクト評価は機能しません。

特に影響を受けるのがコスト（C）と納期（D）です。アジャイル開発ではソフトウェアを細かいモジュール単位に分割し、設計＆開発＆テストを繰り返して徐々にソフトウェア全体を構築していきます。当初に構築したモジュールの評価を受けて、後続のモジュールの開発計画が変わるため、当初の計画に対する評価が成り立ちません。よって予定したコストやスケジュールに対して評価するのではなく、個々のモジュール単位で生産性やリードタイムを計ることが重要になります。これらを計ることで、ある規模のモジュールに対してどの程度のコスト（工数）や時間がかかるのかを予測および評価可能になり、先の見通しが立てやすくなったり、開発チームごとの能力を比較評価することができるようになります。

なお「品質（満足度）」についても「当初予定した要求をしっかり実装したか」という狭い意味での「品質」は成り立たないため、ソフトウェアへの要求の前提となるビジネス（事業）の目標達成に寄与したかという観点が重要になります。事業貢献度を直接、売り上げや顧客獲得数で計れるならそれが一番ですが、目的達成度をユーザー満足度で計る、そのソフトウェアが想定していたユーザーにしっかり使われているかを利用率で計るといった視点が大切になります。

システム導入の目的に適した満足度評価が大切

ウォーターフォール開発であろうと、アジャイル開発であろうと、大切なのは最終的なユーザーの満足度です。コストや納期も大切な要素ではありますが、これが予定より多くかかったとしても経営や事業部といったユーザー側がその費用や時間の追加投入を超える満足をしてもらえるなら、その案件は「成功」と考えて良いでしょう。しかし、ここでしっかり問うべきことは「“経営やエンドユーザーが満足した“とはどういう状態なのか」ということです。”経営やエンドユーザーが満足すれば成功”という定義にも当然、落とし穴があります。

例えば、過去の営業事例や提案書を共有して営業社員がより効果的に営業活動を出来るようにするナレッジマネジメントのシステムを導入したとします。システムを積極的に使っている人にとっては提案書作成が効率的になり、過去の知見の活用でより高い品質で提案できるようになるので、評価は高く満足度が高いと言えます。一方で、この種のシステムはしっかりした啓蒙活動なしではシステムが定着しません。実際に想定通りの活用の仕方をした人はユーザーのごく一部で、営業社員の大半の人は「ちょっとした調べものが楽になった」もしくは「それほど使っていないが、別に不満があるわけではない」という程度の満足だとしたらどうでしょう。開発側からすれば当初の意図通りの機能を実装して、実際使っている人からの評判は良いのだから「満足度は高い」と言いたいところでしょうが、ビジネス上の効果を見ると疑念が残ります。

逆に導入後のタイミングで不満足ばかりのシステムが失敗とも言えません。ナレッジマネジメント関連のシステムは、導入した後に価値あるナレッジを蓄積し、活用されてはじめて価値が出るため、効果がでるまでに時間がかかることがあります。ですから導入当初はナレッジが全然入っておらずユーザーの満足度が低くなることは珍しくありませんが、それは時間と共にあがっていくこともあります。実際、弊社が関わった不動産会社のナレッジマネジメントシステム導入では、当初の大多数のユーザーの評判は必ずしも良いものではありませんでした。しかし、導入を推進したリーダーがナレッジの蓄積を推進し、活用を促した結果、徐々に定着しその会社になくてはならない仕組みになりました。このときは、このような効果が出るまでに2年～3年かかりました。このように満足度は評価タイミングにも依存することがありますが、システム稼働後に数年経ってから満足度を計ることはあまりありません。

システム導入の目的が単純な効率化、つまり自動化による人の作業時間の削減であれば効果は短時間で実感できますし、効果も定量的で算出しやすいところがあります^※2。しかしここで例にあげたナレッジマネジメントやCRM、管理会計、データ分析基盤といった情報分析や活用系のシステムは効果が出るまでに時間がかかる上、効果の創出はユーザー側の意識といった必ずしもシステムの出来の良し悪しではない要素に左右されます。

本当に大切なのはそのシステムが戦略目標の達成に寄与したか

このように大切なのは満足度を重視しつつ、その満足の中身をしっかり問うことです。最終的に行きつくところはビジネスの戦略目標の達成でなくてはいけません。このように考えるとシステム導入に際して、純粋にシステム関連のKPIだけで導入成否を計ることが難しいということが分かります。さきほど例に出したナレッジマネジメントの案件についても、システムのQCDより最終的にナレッジがしっかり活用され提案の質やスピードがあがり事業成長に寄与しているかを受注率やコンペにおける勝率といった業務上のKPIで計る必要があります。

下記の調査はIT導入の案件をどのように評価するかに関して、日本と世界を比べた調査の結果です。2015年の段階で日本では8割近くの企業がITを独立したプロジェクト投資と考えて、単独で評価するとしています。一方で世界の企業の実に6割がITを戦略プロジェクト投資の一部に含め、単独で評価しないとしています。世界ではもはやITは単独の評価尺度ではないのです。

これからのITを含む戦略プロジェクト投資の評価は二段階になります。事業や戦略上の目標とKPI（評価指標）があり、あくまでもその一部としてIT上の目標とKPIが紐づきます。以下に全社的にデータ重視のマーケティングを推進する活動をするためにデータ分析基盤の構築を含む大きな取り組みを行う際を例にとって考えてみましょう。

最終的な目標はデータを活用することにより意思決定や予測精度を向上させることです。ですから、マーケティング部門全体の目標として、データ活用により意思決定が迅速化していることを市場投入サイクルで計ったり、需要予測の精度を予実比較で計ったりと、多方面からやり方そのものが変わっていることを測定しています。仮に想定した効果が出ていないとしても必ずしもシステム側の問題とは限りません。人・組織や業務、そしてシステムそれぞれの観点から対策を練る必要があります。この場合はQCD（アジャイルであれば生産性など）のIT関連のKPIは戦略プロジェクトを構成するKPIの一部であり、しかも決して最終的な成否を決めるKPIではありません。このようなKPIの体系を決めていくには、ビジネスプロセスマネジメントを理解し、社内の主要なビジネスプロセス（業務）の目標達成度をどのようなKPIで計るのかという知見を持つ必要があります。

このようにシステムの評価には事業目標やビジネスプロセスのKPIといった事業の目線からみた戦略目標に対する評価と、その取り組みの一部であるシステム構築上の目標に対する評価の二段階で評価する必要があります。そして最終的な評価はあくまでも戦略目標に対する評価なのです。

“IT側からも積極的に評価尺度の提案を”

このように考えるとシステム導入の最終的な成否はIT部門ではなく、経営側や事業部門側でないと計れないということが分かります。よく考えれば当たり前のことですが、現実にはシステム導入の一切はIT部門に任されてしまい、主体的に経営や事業部門がその立場から戦略プロジェクト全体（と、その一部であるところのIT）を評価するとはなかなかなりません。前述のようにIT導入が単独のプロジェクトとして評価されてしまう日本だと、IT部門としては自分たちの責任の範囲内で計れるQCDで成否を定義せざるを得ないというのが実情です。

さらにいえばITプロジェクトにおいて導入後の評価がしっかりされることは多くはありません。事前評価、つまりプロジェクト前の投資判断に対して、システム導入後の事後評価が行われる割合はぐっと下がります。

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

その際に必要となるのはビジネスプロセスに対する理解です。ビジネスプロセスマネジメントにおける目標設定の考え方は決して事業側だけのものではありません。IT部門などのシステム導入側もビジネスプロセスマネジメントへの理解を深めることで、自分たちの責任の範囲内で計れるQCDでシステム導入の成否を定義するのではなく、戦略プロジェクト全体としてのシステム導入が事業や戦略上の目標をどれだけ達成できたかという観点で成否を定義することが可能となります。