DX : 企業の競争領域(≠コストセンター)で発生する製品・サービス・ビジネスモデルの変革
最近、いろんなベンダーが DX について語っています。しかし、中にはただの IT 化のことを DX と呼んでいたり、製品・サービス・ビジネスモデルの変革を抜きに単純に業務のデジタル化を DX と呼んでいるケースが多い状況です。
ガートナー社はそんな状況を悲観してか、以下のような発表をおこなっています。
日本国内でデジタル化やデジタル・トランスフォーメーション (DX) という言葉が氾濫し、テクノロジに直接関わらないビジネス層も、「デジタル化」に取り組むよう強く求めるようになっています。一方、デジタル化がバズワードとなった結果、今は「何でもデジタル化」と捉えられ、デジタル化の意味がかつてのIT化／情報化と混同されているケースも多くみられるなど混乱が生じています。https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20220314 より引用。
DX の定義
では DX の定義をいくつか調べてみます。
ガートナー社の定義
このサイトによると、以下がガートナー社による DX の定義です。
1. 業務プロセスの変革
2. ビジネスと企業、人を結び付けて統合する
3. 仮想と物理の世界を融合して人／モノ／ビジネスが直接つながり、顧客との関係が瞬時に変化していく状態が当たり前となるガートナーはこの第3段階の状態をデジタルビジネスと呼び、「仮想世界と物理的世界が融合され、モノのインターネット（IoT）を通じてプロセスや業界の動きを変革する新しいビジネスデザイン」と定義している。 また、このデジタルビジネスへの改革プロセスを「デジタルビジネストランスフォーメーション」と定義している。
経済産業省の定義
経済産業省の定義は以下の通りです。
企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズをもとに、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立することIDC Japan の DX の定義
IDC Japan の DX の定義は以下の通りです。
企業が外部エコシステム（顧客、市場）の破壊的な変化に対応しつつ、内部エコシステム（組織、文化、従業員）の変革を牽引しながら、第３のプラットフォーム（クラウド、モビリティ、ビッグデータ／アナリティクス、ソーシャル技術）を利用して、新しい製品やサービス、新しいビジネスモデルを通して、ネットとリアルの両面での顧客エクスペリエンス（経験、体験）の変革を図ることで価値を創出し、競争上の優位性を確立することどの定義にも製品やサービス、ビジネスモデルの変革が明示的に使われています(ガートナーはビジネスモデルの代わりにビジネスデザインという言葉を使用)。
特に経済産業省や IDC Japan の定義における DX は
- 製品やサービス、ビジネスモデルを変革する
- 組織、プロセス、企業文化、風土の変革も同時におこなわれる
1 と 2両方が実施されてかつ、競争上の優位性を確立できて初めて DX と呼べると言えるものです。1 か 2 片方ではダメです。
製品/サービス/ビジネスモデルの変革
製品の変革
製品の変革はとてもわかりやすいのではないでしょうか。代表例は Apple の iPhone や Tesla の Model 3等がこれにあたります。
サービスの変革
サービス自体もわかりやすいです。Netflix におけるビデオ視聴サービスや米国における Uber の配車サービスがこれにあたります。Netflix のように後述するビジネスモデルの変革によって、製造業からサービス業へ舵を切る企業もあります。
さて、コンタクトセンター等のカスタマーサービスはこのサービスに含まれるでしょうか。個人的にはカスタマーサービスは「サービスの変革」には含まないと考えています。カスタマーサービス自体は企業の競争領域ではない(コアドメインではない)こと、後述する経済産業省の DX レポートにおける協調領域であることが理由です。
製品・サービスの変革のいずれのケースにおいても既存の携帯電話や一眼レフ・タクシー・ビデオレンタル店等、既存のビジネスモデルを展開する企業に大きな打撃を与え、有名になった例です。いわゆるディスラプションが発生した事例です。
こうして考えると製品やサービスはその会社における競争領域(コアドメイン)周辺で発生するものだと考えられます。
ビジネスモデルの変革
では残ったビジネスモデルの変革は何を意味するのでしょうか。
https://www.nri.com/jp/knowledge/glossary/lst/ha/busi_method によるとビジネスモデルとは
当該ビジネスが、誰に（Who）、何を（What）、どうやって（How）、付加価値を提供し、収益を得るのかが盛り込まれたビジネスの仕組み。ビジネスモデルとは、商品やサービスなどの付加価値の提供と、それによって得られる収益の獲得の仕組みを指します。あらゆる企業にとって、優れたビジネスモデルを構築することは持続的成長を実現するために必要になります。
のことを指します。収益を発生させうるビジネスのやり方そのもののことです。
実は Netflix はビジネスモデルの変革の良い事例でもあります。
今のNetflixというと、オンデマンドストリーミングのイメージしかない方も多いでしょう。しかし、Netflixはも元々DVDの郵便レンタルからスタートした会社です。Netflix は DVD の郵便レンタルを元々のビジネスモデルとしていましたが、IT を使ってビジネスモデルそのものを変革し、ストリーミングサービスに転換、顧客の再生に合わせて、リコメンドするサービスを展開する会社に変貌を遂げています。DX にふさわしい事例の一つであると考えます。
ちなみに Netflix も Uber も私の得意領域である Apache Kafka が使用されています(DX の領域ではほぼ必須のプロダクトです)。
日本国内では、コマツが良い代表例だと考えます。それまで機器販売だけだった収入モデルでした。販売した各機器にセンサーを導入し、機器を管理するサービスの展開を実現しています。DAIKIN におけるエアコン販売からビル管理サービスの展開もこれにあたります。これらはガートナーの定義する DX における「仮想世界と物理的世界が融合され、モノのインターネット（IoT）を通じてプロセスや業界の動きを変革する新しいビジネスデザイン」そのものであると考えます。
DX かどうか怪しい変革
経済産業省やガートナー、IDC Japan の定義においては製品・サービス・ビジネスモデルの変革がなければそれは DX ではありません。多くの企業が謳っている DX は残念ながら経産省・ガートナー・IDC Japan の定義上はただの IT 化です。
特に以下の文脈で語られる DX は DX とは呼べません。
- コストセンターで語られる DX(よくある単語 : 脱ハンコ、脱 Excel、脱手作業)
- IT 部門単独の文脈で語られる DX(よくある単語 : 自動化、脱手作業)
正しい DX とは
DX を推進するにはビジネス部門の力が必要です。なぜなら、製品・サービス・ビジネスモデルの変革すべてが、企業の稼ぎ頭であるコアドメインを中心に発生するものであり、コストセンターでは実現できないからです。
これは経済産業省が出している「DX レポート 〜IT システム「2025年の崖」の克服と DX の本格的な展開〜」というレポートの中でも触れられています。
システム投資を行うプロジェクトにおいては、事業部門と情報システム部門の役割分担も重要である。この際、システム投資を行う目的は、システムが開発できたかではなく、ビジネスがうまくいくようになったかどうかで判断されるべきである。そのためには、事業部門がプロジェクトのオーナーシップを持って、仕様決定、受入テスト等を実施していくことが必要である。- システム開発が IT 部門主体からビジネス部門主体に変わること。
実は解決策が多く記載されてある、「DX レポート」
「DX レポート」にはシステム開発が IT 部門主体からビジネス部門に変わること以外にも、さまざまな問題に対する良質な解決方法が載っています。いくつか例を見てみます。
DX を実行しようとするユーザ企業の中で、ビジネス・モデルを変革すべく、新たなデジタル技術を活用できるように既存システムを刷新する判断を行うユーザ企業はまだ少ないのが実態である。ただ、そうした判断を行っている企業は、必ずと言っていいほど経営層の強いコミットがある。- DX 実現には経営層による強いコミットが必要であること。
既存システムの刷新となると、大規模・長期なプロジェクトとなる恐れがある。他方で、3.3.1 で述べたように、ビジネス上頻繁に更新することが求められる機能につい ては、刷新後のシステムにおいて、新たなデジタル技術が導入され、ビジネス・モデルの変 化に迅速に追従できるようになっている必要がある。すなわち、システムがモジュール化さ れた機能に分割され、短いサイクルでリリースができる状態にしていくことが求められる。これによって、ビジネス上頻繁に更新することが求められる機能については、システム刷 新における移行時において、マイクロサービス化することによって細分化し、アジャイル開 発方法により段階的に刷新するアプローチも考えられる。これにより、仕様を明確にできる ところから開発を進めることとなるため、刷新に伴うリスクの軽減も期待できる。
- 既存システムは刷新の際にモジュラーモノリス化を検討。
- 場合によってはマイクロサービス化し、改修の影響範囲を極小化する。
- サービスごとの開発形態をアジャイル(スクラム)開発とする。
モジュラーモノリスやマイクロサービスへの分割の手法は過去記事の「マイクロサービスの上手な分割手法」を参照ください(これらの解決策は2年前に実施した下記オンラインセミナーで触れています)。
レポートの内容をチェリーピッキングするベンダー
多くのベンダーはこのレポートの詳細まで確認せず、自社の都合の良いように解釈した自論を展開しているところが多いです。
いくつか例を挙げます。
共通プラットフォーム / 第３のプラットフォーム
特に経済産業省の DX レポートに登場する「共通プラットフォーム」や IDC Japan における「第３のプラットフォーム」という単語だけを自分たちの都合の良いように解釈して話している企業が多く見受けられます。
「DX レポート」の詳細を確認すると、共通プラットフォームはコモディティ化して競争領域となっていない、協調領域を他社と共同で使用・開発するプラットフォームのことであって、競争領域となる DX システムを載せるプラットフォームではありません。
ユーザ企業における非競争領域、すなわち協調領域には、標準パッケージの導入や業種ごとの共通プラットフォームの利用等、コスト削減や競争領域へのリソースの重点配分を図っているか第3のプラットフォームも「クラウド・ビッグデータ/アナリティクス・ソーシャル技術・モビリティー」が挙げられており、協調領域ではなく競争領域に使うべきプラットフォームであることがわかります。
なんでも改修
既存システムの改修において、「DX レポート」に記載されているような「モジュラーモノリス」や「マイクロサービス」の手法を使い、なんでもかんでも改修させることを推奨するベンダーもいます。ミドルウェアを提供するベンダーは自社の製品が売れた方が良いに決まっているので、ミドルウェアを使った改修を提案してきます。
しかし「DX レポート」によると、競争領域ではない協調領域は SaaS のような共通プラットフォームも検討すべきと記載されています。競争領域ではない領域を自社の開発リソースを使って何億もかけて保守・運用するのは時代遅れになりつつあります。
逆に競走領域を SaaS で実現するとどこもかしこも似たようなシステムになり差別化が図れません。
本当の意味の DX を推進するにあたってのベストな手順
DX を推進するには「DX レポート」にあるとおり、経営層自らが DX を推し進める必要があります。そしてそのためには仮説検証型のビジネス(リーンスタートアップ)を遂行する必要があると考えます。
なぜならビジネスモデルの変革にはこれまでの知識が通用しない可能性が高いためです。
今までの知識が全く通用しない中で、今までのやり方を使用してもうまく進められないはずです。
- ウォーターフォール開発
- SIer への丸投げ
ウォーターフォールは最初から完成形を定義して開発していく手法で、逆にいうと仮説・検証が既に終わっている状態であれば有意義な開発手法と言えます。仮説・検証を繰り返しながら開発していく手法としては不向きです。
重要なのは経営層もアジャイル開発のノウハウを知っている必要があるということです。経営層には経営層にしかできない組織の文化・規律を変革してもらう必要があります。段階的に予算を取得するようなリーンバジェットのような考え方、開発と運用の組織を一緒にして DevOps を推進するような変革が必要になります。Scaled Agile Framework にはこの手のノウハウが詰まっています。
(技術的な話をすると仮説検証型ビジネスの展開には AB テスト やカナリアデプロイ等ができた方がよいでしょう)。
もちろんビジネス部門もアジャイル開発、特にスクラムの知識が必要になります。ビジネス部門はプロダクトオーナーとしてプロジェクトに参加して、システム開発の主体となる必要があります。
プロダクトオーナーにプロジェクト部門が参加していないプロジェクトは全く持って意味がないと個人的には考えています。結局のところシステムが他人事になってしまいます。
理想ではドメインごとに区切ったサービスが1つのスクラムチーム(2 Pizza Rule にのっとり、1チーム 6–8名の開発チーム)を形成し、サービスを開発していくことになります。コードを記述できる運用者(最も日本にはそんな技術者はデジタルネイティブ(Web 系、ゲーム系、メディア系)領域に集中しておりエンタープライズには稀だと考えますが)は Site Reliability Engineer (SRE) として運用を自動化するコードを記述できるようになれば、最強のチームになること間違いなしです。
ただしこの時、プラットフォームの運用がコードで記述できる必要があるので Infrastructure As Code を実現可能なプラットフォームを選択しましょう。
ServiceNow が DX で貢献できる領域
ServiceNow は実は Scaled Agile Framework に対応しています。プログラムの管理やエピックの管理、カンバン等に対応しています。DX プロジェクトの予実管理の状況やプロジェクト状況を可視化して経営層に見せることも可能です。各サービスで発生した問題・インシデント・変更をそのままサービスに紐づけて管理することも可能です。
また SRE チームが管理すべきエラーバジェットを管理したり、さまざまなイベントを収集し(例えば Observability ツールと連携し、それらツールから発生する Web システムの応答時間等)、インシデントを自動生成して、SRE に割り当てることも可能になります(Site Reliability Operations)。
