これから始めるDX。傾向と課題と対策

はじめに

これからはじめるDXプロジェクトは、出来れば外向きのお客様向けテーマがお勧めだという話を前回しました。工場や研究開発などを対象とした、内向きのDXプロジェクトも大切ですがポイントは技術やシステムの導入を目的化してはいけないということです。DXプロジェクトの狙いは、他社との差別化で自社の強みや価値を高めることです。技術やシステムの導入を目的化すると、他社が同じモノを導入すれば違いが無くなってしまいます。重要なのは内容であり、つまりそれは企業によって異なる固有の“データ”の蓄積やそのデータを活用できる“ヒト”（データを活用出来る人材）だと思います。さて今回は、外向きDXプロジェクトの実行計画とシステム構成の考え方についてご説明します。

DXプロジェクトは“データ”を最大活用したサービス化にある

DXプロジェクトのテーマに何を選ぶかは各社それぞれの状況によりますが、国内製造業で先行事例が多いのは生産設備の予知保全や品質管理の画像解析といったテーマです。これらは、どの企業にもある課題であり、解決に紐づくデータの当たりがつけやすく、失敗リスクが少ないというメリットがあります。しかし、失敗リスクが低いことからも分かる通りどの企業でも取り組み易いテーマなので競争力向上の大きなアドバンテージは生まれません。このテーマはコスト削減や生産性向上に貢献するため、社内の評価は上がります。これも失敗しないDXプロジェクトなのでやらないよりはやったほうが良いのですが、継続的な効果を出し続けるのは難しく、PoCや局所的な導入に終わるケースが多いようです。欧米など海外では、売上向上や顧客満足度アップを狙うDXプロジェクトが多く、その理由は経営者や事業部門責任者が、業績を高めて報酬を上げる目的があるからだと言われています。リスクが少なく成功しやすいテーマを選ぶ日本の担当者と、リスクよりも業績アップを狙う欧米の責任者の意識の違いがあるのかもしれません。こうした背景を踏まえて、売上アップに貢献するとともにリスクが比較的少ないお客様向けアフターサービスのDXを考えてみたいと思います。今回は、完成品を作るメーカーのアフターサービスをテーマとしたDXプロジェクトとします。読者の皆様がイメージしやすい機械（車両、工作機械、搬送機など）で、定期的なメンテナンスや消耗品交換、故障による部品交換があるモノをイメージしてみてください。
経済産業省「DXレポート２のサマリー」では、デジタル企業への変革プロセスとして以下の通り８つのアクションと政策が「求められる変革」のステップごとに整理されています。
ここに「DX成功パターンの策定、DXフレームワーク」（※図表2）とその参考例「DX成功パターンの策定、製造プロセスのソフトウェア化」（※図表3）をベースに、これをアフターサービスDXに置き換えてみたいと思います。

（図表１：経済産業省「DXレポート２のサマリー」）

出所：経済産業省　DXレポート2
～デジタルトランスフォーメーションの加速に向けた研究会の中間報告書『DXレポート2（中間取りまとめ）』サマリーより～
https://www.meti.go.jp/press/2020/12/20201228004/20201228004.html

（図表2：DX成功パターンの策定、DXフレームワーク）

（図表3：DX成功パターンの策定、製造プロセスのソフトウェア化）

①お客様に製品の稼働状況を分かりやすく説明したい

②製品の故障やトラブルが生じた際の解決時間を短縮したい

③製品の故障やトラブルの対応コストを減らしたい（労務費と作業時間の短縮）

①製品の稼働状況／故障・トラブルの電子化
詳細：製品（機械設備）の稼働状況をモニターするセンサーやカメラなどをパック化して追加設置（保守契約をする）して各種データを取得する

②製品の稼働状況／故障・トラブル、トラブル対処のソフトウェア化
詳細：パック化した追加設備で取得した各種データを見える化するアプリをスマートフォン／タブレット向けに開発して顧客に提供

③製品アフターサービスの遠隔化
詳細：顧客がセルフサービスで問題解決できない場合や、トラブル対処がわからない場合は、アプリからコールセンターや営業へ連絡してアプリに蓄積されたデータなどを送って遠隔制御や近隣拠点からサービス技術者より対応

このように製品の稼働状況／故障・トラブルの各種データを蓄積して、そのデータを活用したノウハウよりアフターサービスを提供することが可能となります。対象とする製品を絞れば、小さく始めることも可能です。さらに、既に保守サポート対象から外れた古い製品や、他社製品などのアフターサービスも同様にサービス対象製品を広げることが可能なので、このサービスを新しい市場を開くビジネスとして応用できます。

このアフターサービスDXプロジェクトのポイントは、「独自に収集・解析したデータを活用したサービス」（データ駆動形サービス）なので、システムや仕組みが真似されてもデータとサービス技術者のノウハウは真似できないため企業の強みは継続的に維持出来ます。

（図表4：データ駆動型サービスプラットフォームの構築イメージ）

DXプロジェクトのシステムはウェブサービス型の新しい設計思想が有効

DX（デジタル・トランスフォーメーション）は、実現したい目的のためにデジタル技術を利用した仕組みをシステム化してサービス提供します。今回例にあげているアフターサービスDXプロジェクトの場合は、AS-IS現状のアフターサービスは人づてのアナログ的なサービスなので、これをTO-BEあるべき姿のデータを活用したサービス提供をデジタル化して実現します。そのシステム構成について、考えてみたいと思います。まず最も重要なのは、製品（機械設備）の稼働データを蓄積するためのシステム基盤（プラットフォーム）です。これは、稼働データを収集するデータベースとデータを蓄積するストレージ、ネットワークなどから構成されます。従来のデータベースは、構造化データに対応したリレーショナルデータベース（RDB）利用が一般的でしたが、最近は画像や動画、ドキュメントなど非構造化データにも対応できるデータベースなどを利用するケースが増えています。また、収集するデータ容量も膨大になるため維持コストからオンプレミスからクラウドへトレンドが移行しています。このようにクラウドへシステム基盤の移行が加速していて、企業の基幹システムであるERPのトレンドも、2021年には新規導入はオンプレミスとクラウド（IaaS/SaaS）の比率が逆転してクラウド比率が過半数を超えるという調査会社のレポートもあります。

（参考：ITR Market View、
https://www.itr.co.jp/company/press/210408PR.html　）

（図表5：ERPとMESの比較、構造化／非構造化データの比較）

こうしたニーズの変化とテクノロジーの進化から、システム基盤はオンプレミスからクラウド基盤へと急速に移り変わっています。システムごとにサーバーにシステムを構築するこれまでのやり方ではなく、用途や役割に合わせてクラウド基盤上にデータを集めてその上に複数のアプリケーションを置く考え方です。既に多くの企業では、複数のウェブサービスを利用していますから、ERPやCRMなど基幹系システムとECや物流サービスを組み合わせた基幹系とウェブ系の連携利用が更に加速すると考えられます。それぞれのサービスを連携するために、オンプレミスのシステムをバッチ連携するのではなくAPI連携を前提としたマルチクラウド（複数クラウド基盤の利用）、ハイブリッドクラウド（オンプレミスとクラウド基盤の連携）が今後は主流となります。パッケージシステムやウェブサービスの利用が急拡大していることから、システムではなく自社だけが持つ独自データが差別化の源泉となります。また、顧客向けサービスの利用端末もPCベースからスマートフォン／タブレットがメインとなります。一見すると簡単な変更に見えますが、システム運用の考え方やアプリケーション開発の手法が大きく変わります。サーバーとの常時接続を前提としたOLTP（オンライントランザクション処理）から、API連携などへ変わることでデータの分散処理やセキュリティなど見直しが必要となります。さらに、利用者の使い勝手や分かりやすさ、画面デザインなどが重要となります。ウェブブラウザーを利用したウェブアプリケーションなのか、モバイル端末のOS（iOSやAndroidなど）のネイティブアプリケーションなのかによってもシステム構築と運用の考え方が大きく変わります。更に追加要件として、サービスの拡張性や柔軟性を考慮して運用性を高めるDevOpsやローコード／ノーコードなど対応が必要です。システム内製化ニーズにも対応できるウェブベースの開発や、データ肥大化を想定した分散処理やデータ仮想化なども考慮しておく必要があります。5年先、10年先のデータ容量／利用者数などを想定して、中長期的な安定稼働を考慮したバランスの良い設計が求められます。企業向けの業務アプリケーションばかり開発してきた開発者は、こうしたクラウドやモバイル、新しい基盤技術の知見が足りないところが多くDXプロジェクトで機能や技術に偏った設計になってしまうケースが多く見られます。わかっているつもりで、開発してはじめて設計思想が違っていて実装できないケースが多いのが実情です。アフターサービスDXプロジェクトの対象となる製品（機械設備）のシステム開発は、多数の製品からデータを取得して解析する仕組みとなりますので、機能よりも将来の拡張性や柔軟性、セキュリティ対策などが重要です。まずは、小さい構成でテスト開発を行ってから、段階的に拡充しているウェブ開発手法を取り込む必要があります。また、既存システムとの連携サービスも必要となりますあら、連携サービスをデータ層／アプリケーション層／サービス層などレイヤを整理して考えることも重要です。「つくるよりつなぐ、つくるのは必要最小限、つかう人目線のサービス」を心がけなければなりません。

まとめ

クラウド基盤、モバイルアプリ、大容量データ、AIによるデータ解析などDXプロジェクトのシステムは、これまでのシステム開発に新しいテクノロジーや発想を追加して考える必要があります。しかし、より重要なのはシステム開発ではなく顧客向けサービスとして使いやすさや分かりやすさを追求したデザインシンキングにあります。また、「機能を提供するパッケージやツールなど」のシステム導入ではなく、「データ収集と解析で企業独自の強みを引き出す“データ駆動形サービス”をイメージしておく必要があります。固有データを活用したサービス提供と、これを使いこなせる人材が高い価値を生みます。DX人材とは、DXプロジェクトのシステム開発人材をイメージしがちですが、本当に必要なのはDXシステムを使って顧客ごとにサービス提供やコンサルティングが出来るDXスキル人材だと思います。