DX（デジタルトランスフォーメーション）は、「デジタルを利用した変革」と翻訳されます。その真意は「製品・サービス・ビジネスモデル・業務プロセス・組織・企業文化の変革と競争力の確保」です。つまり、企業活動の大半がデジタル化の対象となります。こうした変革を支えるためには、確固たるIT基盤の確立が必須です。
一方、日本のITプロジェクトは、決して成功率が高いとは言えない状況にあります。ユーザー視点でのITプロジェクト成功率は52.8%※1、ベンダー視点では71.9%※2という調査結果もあるほどで、約3割～5割は失敗に終わっているのが実情です。そこで今回は、DX時代におけるIT導入の成功要因を、ユーザー視点から分析していきます。
1.日本におけるIT導入の実情
前述の調査結果にあるように、企業へのIT導入は、「ユーザー視点」と「ベンダー視点」で成功の定義が異なります。
・ユーザー視点での成功...納期と予算の要件を満たし、「総体として満足」であること
・ベンダー視点での成功...納期と予算の要件を満たし、「本番稼働後の不具合が計画内」であること
厳密に言えば、どちらの視点でもQCD（品質・コスト・スケジュール）の充足が成功の条件ですが、その捉え方が異なることで定義の差が生じています。
○なぜ日本のIT導入は失敗するのか
特に、冒頭でも述べたようにユーザー視点でのIT導入成功は5割強に留まるレベルであり、約半数のITプロジェクトは「失敗」と判断されています。日本企業のIT導入は、伝統的に「ウォーターフォール型」が採用され、要件定義フェーズ完了時点の出来が後工程の難易度に大きな影響を及ぼします。つまり、要件定義フェーズ完了時点での「詰め」が甘ければ、その後の開発・テスト工程で問題が生じやすくなります。また、要件定義のやり直しはクライアント側の時間と労力（当然費用も）を奪いがちであり、タブー視されることも珍しくありません。こうした事情から、要件定義の詰めの甘さを後工程で取り戻すしかなく、歪なプロジェクト進行となってしまうわけです。以下は、IT導入の失敗要因をQCDの観点からまとめたものです。
○真の成功率はさらに低い
実際に企業のIT導入に携わる担当者の方であれば、「5割も成功していないのでは？」と感じられるかもしれません。おそらく、その肌感覚に間違いはないでしょう。なぜならIT導入の向こう側にある変革、つまり「DXの成功率」は、さらに低いという結果があるからです。
マッキンゼー社の調査によればDXの成功率は16%※3とされています。また、ボストンコンサルティング社の調査では14%※4と算出されており、実に8割以上が「失敗」と判断されているのです。
DXの成功率が著しく低い理由は、「IT導入が成功したか」ではなく、「ビジネス変革が達成されたか」で判断されるためと考えられます。同様の視点をIT導入に当てはめると、「真のIT導入成功率」はさらに低くなると推測できます。
〇IT導入の「真の成功」の定義と必要な視点
以上を踏まえ、IT導入によるビジネスの変革という「IT導入の真の成功」に向けては、次の3ステップが必要と言えます。
ステップ1：QCD（品質・コスト・納期）を充足したIT導入
ステップ2：（導入後の）ツール、システムの業務定着と活用
ステップ3：導入目的の達成（＝変革実現）
つまり、導入したら終わり、ではなく、導入してからが始まり、ということに他なりません。
2.IT導入成功のための3つの鉄則（ユーザー視点）とは
上記のような成功をつかみ取るうえで、ユーザーが有すべき視点とは何か。言い換えれば、IT導入成功のための鉄則とは何か。端的に言えば、以下３つが挙げられます。
・入念な準備
・「作る」ではなく「使う」
・使い続け、「育てる」
以降でこれら3つの視点を順に解説していきます。
2-1.入念な準備
1つ目の鉄則は、「準備フェーズを入念に」です。上流工程の準備フェーズは、大きく以下3つに分類されますが、それぞれをじっくりとしっかり取り組むことが重要です。
〇方針の決定
まず、「なぜ必要なのか」「手段が目的化していないか」「単に流行に乗っているだけではないか」など"そもそも論"を入念に話し合い、方針を決定することが重要です。
弊社のこれまでの経験を振り返ると、RPAなど先進テクノロジーの導入の場合、「経営トップがやりたいから」といった動機が多かった印象です。そして、いざトップにお話を伺うと、「知り合いの経営者がやっていたから」といったケースも珍しくありませんでした。こうしたケースでは、IT導入の目的がはっきりせず、次のような事態を招きがちです。
・RPA化する対象業務が見つけられない
・ライセンスは購入したが使いこなせず、イニシャルコストが無駄になる
こうした事態を防ぐためにも、まずはIT導入の目的を明らかにしたうえで、その目的を達成する「期間、費用、体制」といった前提条件の輪郭をはっきりさせましょう。特にプロジェクトの旗振り役ともいえる「CoE（Center of Excellence=目的実行のための中心組織、人物）」の設置は、IT導入を真の成功に導くための鍵となります。
〇製品選定
ここ数年の変化でXaaSならではの「複数製品トライアル or PoC」が可能になりました。これは、ユーザー側で「対象ツールの真の効果」や、「価格の妥当性」を"本格導入前"に"比較的容易に"検証できるようになったことを意味します。事前に検証項目を用意したうえで、トライアル、PoCに臨むことで、自社要件にフィットした製品選定の確度を高められます。また、製品に最も精通しているのは他ならぬ製品ベンダーの営業担当者です。彼らから必要な情報を可能な限り入手し、製品理解を深めましょう。製品仕様や機能、価格といった基本的な情報に加え、今後の製品ロードマップやサポート体制、サクセス内容もチェックすることを推奨します。なお、並行して、「ITreview」等BtoB向けITツールのレビューサイトやWeb上での評判・口コミなど活用することで、営業担当者の"セールストーク"を裏付ける材料も入手しておきたいところです。
〇ベンダー選定
導入製品確定後のベンダー選定は、必ずしも必須ではありません。導入したい製品自体の難易度が高くない、もしくは精通した人材が社内にいるため自社自力で導入する場合（＝セルフインプリ）は、そもそも導入ベンダーが不要になります。また導入ベンダーによる支援が必要な場合でも、製品ベンダーしか導入を支援できないケース（製品ベンダー＝導入ベンダー）、もしくは製品ベンダーが指定する導入ベンダーが決まっているケースなども考えられます。
一方、導入ベンダーの候補が複数存在する場合は、製品選定と同様に選定軸を定め、選びましょう。その際は、特に、「ベンダーに期待する期待値」を明確にしておくことが重要です。
「コストは高いが、その分しっかりと個社の事情・要件に踏み込み、提案・提言しつつ導入をリードしてくれるベンダー」と、「（相対的にコストは廉価だが）正確に要求を伝えれば、その通りの機能を正しく実装してくれるベンダー」のどちらを選ぶべきかといった、ベンダーへの期待水準。「上流工程のみ」「導入・構築のみ」「上流工程から導入・構築、稼働後の伴走まで」といった期待工程。こういった観点を、上記方針と照らし合わせつつ検討し、ベンダーへの期待値として明らかにしましょう。
なお、やや余談ですが、米国では、BtoB向けITツールのレビューサイトがその範囲を徐々に拡張し、製品・サービス自体の評価のみならず「ベンダー評価」も掲載され、容易に比較可能な状況です（「G2」など）。日本国内でも、上記「ITreview」などBtoB領域でのITツールのレビューサイトが出始めており、近い将来、米国と同様の流れが到来するかもしれません。
参考として以下に、MA導入までの検討ステップを例示します。
2-2.「作る」ではなく「使う」
2つ目の鉄則は、「作るよりも使う」を重視することです。具体的には、次のような事柄を意識してみてください。
〇組合せで「巨人の肩に乗る」戦略
日本におけるパッケージ導入プロジェクトは、その8割以上が受託開発という統計があります。つまり、標準仕様のまま導入せずに、カスタマイズや追加開発を行うケースが大半ということです。しかし、さまざまなツールが雨後の筍のように出現している今、製品の組合せを工夫するだけで大抵のことは実現できてしまいます。要は「カスタマイズや追加開発はマストではない」ということです。特にXaaSには、特定領域のナレッジ・ベストプラクティスが凝縮されたサービスが多数存在します。これらを上手く組み合わせることで、「巨人の肩に乗る」戦略が可能となるでしょう。「作る」工数とコストを低減しつつ、「使う」ことを重視したIT導入が可能になるわけです。
〇本当に「特殊・独特」か？フィッティングで解決
お客様からは、「うちは特殊、独特だから標準仕様はフィットしない」というお話よく伺います。しかし、IT導入を支援し、リードする側として、俯瞰的にみて抽象度をあげていくと、「完全に独自なガラパゴス化した業務」は少ないという印象です。つまり、しっかりと業務分析を行い、製品仕様と比較していけば「カスタマイズ・追加開発（作りこみ）」ではなく「フィッティング（設定の最適化）」で対応できる可能性が高いのです。一例として、システムリプレイス案件の際の「あるある」ですが、「既存システムにあるからこの機能は絶対必要」という展開になりがちです。ただ、本当に必要か、どれくらい使われているかを詳細に詰めていくと、結局「不要」という着地も非常に多い認識です。このように、まず、「業務を一切見直さずにシステムを合わせる」のではなく、「実態を把握し現場の業務をシステムに近づける」という歩み寄りの姿勢が必要です。
カスタマイズ・追加開発による作りこみは、確かに現場への負担が少ない手法です。その一方で、XaaSの強みである「バージョンアップ」の恩恵が受けられなくなるというデメリットもあります。要否と範囲を正しく見極めましょう。
その際、業務を「コア領域」と「ノンコア領域」に分け、作りこみの範囲を限定していく方法もおすすめです。自社にとってのコア領域の業務は「付加価値創出」や「差別化」が必要となるため、ITシステムにも独自の作りこみが必要になるでしょう（そうすべきとも言えます）。これに対して、ノンコア領域の業務は、「効率化」が目的であり、必ずしも作りこみを必要としません。こうした業務領域による違いにも配慮しながら「作るよりも使う」視点で導入を進めたいところです
〇「旗振り役」COEの重要性
COEとは、ある目的を達成するための中央機関のことです。COEは、社内に散逸するベストプラクティスやナレッジを集約して横展開し、プロジェクトの成功角度を高めるという役割を担います。COEが役割を果たしているケースとそうでないケースでは、プロジェクトの成功率がかなり変わります。弊社でも、COEが機能しているプロジェクトは8割近くが成功している、という印象を持っています。
COEにはスキルセット（製品理解・キャッチアップが早い）、マインドセット（やる気がある、チームワーカー）を有した人材をアサインし、プロジェクトリーダーと同等クラスの権限、役割を与えると良いでしょう。
2-3.「使い続け」「育てる」
3つ目の鉄則は、「育てる」ことです。この「育てる」には、以下2種類の意味が込められています。
〇自社の「環境」と「人材」を育てる
・利用機能の拡大、利用範囲（対象ユーザー、部門）の拡大、ナレッジの蓄積
・製品ベンダー提供コンテンツ、ユーザーコミュニティ、フォーラムなどの活用
・外部から取得した情報をベースにナレッジ化を行い、社内へ還元
・社員スキルの底上げ
〇製品・サービスを育てる
・作りこみを行わず「機能の要望」を製品ベンダーに共有する
・製品ベンダーによるアップデート（新機能の実装）を待ち、さらにアップデートされた機能への要望を出すという好循環を狙う
〇ベンダーとの協調路線でWin-Winの関係構築を目指す
このように、自社のナレッジや人材育成を進めながら、製品ベンダーへも機能改善要望を出すことで、「人」「業務」「システム」が成長していきます。まずは自分たちで選び抜いた製品で提供されている機能を使い続け、徐々にユーザーを増やすことから始めてみてください。自然と機能に対する要望やナレッジが蓄積されていくと思います。その後は、社内でナレッジを共有しつつ、適宜製品ベンダーへ機能改善要望を出していきましょう。正しく使い続け、ユーザー数も増えている、そんな「顧客」は、製品ベンダーにとっても当然大切にすべき優良顧客であるはずです。そして優良顧客から上がってくる機能改善要望なのであれば、少なからず応じてくれるはずです。また、裏を返せば、顧客の声に耳を傾け、継続的に機能改善を行う意思を持つ製品ベンダーを選定することも、IT導入を真の成功に導くための秘訣と言えます。
3.まとめ
本記事では、日本のIT導入の現状を踏まえ、IT導入を真の成功に導くための鉄則について、ユーザー側の視点から解説してきました。DX時代のIT導入は、従来の視点（QCDの充足）に加えて、「ビジネス変革」までを見据える必要があります。そのためには、「入念に準備し方針を明確にする」「作りこみに固執しない」「使い続け、育てる」という3つの視点を持ち、IT（導入）と向き合っていくことが非常に大切です。
バーチャレクス・コンサルティングでは、IT導入の最上流であるコンサルティングから開発・構築・運用までを一気通貫で提供し、ビジネス変革をゴールとした伴走型サービスを提供しております。お困りごとや課題等お持ちでしたら、まずはお気軽にお問い合わせください。
次回、後編では「ベンダー側の視点」からIT導入成功の鉄則を解説いたします。
参考：
※1：日経xTECH/日経コンピュータ「ITプロジェクト実態調査 2018」
※2：IPA「ソフトウェア開発データ白書2018-2019」
※3：「マッキンゼー企業変革調査」 2020/9
※4：「デジタルトランスフォーメーションに関するグローバル調査」 2020/10/28
執筆者紹介
ビジネスインキュベーション＆コンサルティング部 部長
