ブログ

【技術】知っておきたいトレンド技術、DX白書2021第4部を徹底解説

目まぐるしいスピードで進歩していくデータ利活用技術をあなたは把握できていますか? データ利活用技術を駆使できるようになることが目的であるDXの成功に、最新技術の勉強を避けて通ることはできません。この記事では「DX白書2021」の第4部「DXを支える手法と技術」の解説から、最新技術の概要や活用に当たっての検討のポイント、事例を見ていきます。

DX白書はIPA公式サイトからpdfでダウンロードできます。

【目次】

  1. 第4部の構成
  2. 第1章 開発手法・技術
    • 企画開発手法
    • ITシステム開発技術
    • 開発手法・技術の活用状況と課題
  3. 第2章 データ利活用技術
  4. まとめ

第4部の構成

DX白書2021の第4部では、2章に分かれ約120ページ(175ページから290ページ、企業インタビューを除く)に渡りDXを支える企画開発手法、最新のデータ利活用技術の解説と活用方法が紹介されています。

専門用語が多く登場し、ある程度デジタル技術に知見のある人でなければ読み進めるのは難しいパートです。しかし、DX後の企業に務めるビジネスマンであれば、自分たちが使用している技術の概要を理解しておくべきです。第4部を読み、技術のトレンドを把握しましょう。

第1章 開発手法・技術

現在は「VUCA」の時代と呼ばれ、ビジネスや市場、組織、個人の環境変化の激しく、企業は、移り変わりの早い消費者ニーズ、トレンドに対応していかなければなりません。経済産業省が提唱する「2025年の崖」で懸念されているように、従来のITシステム、開発手法では競争力の維持は困難です。

本章ではDXの実現に必要な開発手法と、ITシステム開発技術、それら開発手法・技術の活用状況と課題の調査、活用の方向性の検討を行っています。

<「デザイン思考」で素早く消費者ニーズを具体化>

デザイン思考とは、課題の発見から企画・デザインまでデザイナー的な思考プロセスを取り入れてプロダクトやサービスの検討に適用する、人間中心の開発方法のことです。

従来は、物理現象がどう連鎖するのかのみを考えれば良い機械の設計に留まっていました。しかし、多くのユーザーが、自身の持つニーズに気づくことができていないことから、ユーザーに「共感」することでニーズを類推し、絞り込み、解決のアイデアを導出するデザイン思考が注目されはじめました。

本章では、デザイン思考の定義、活用する際の注意点について解説しています。

デザイン思考のプロセス、5ステージ

スタンフォード大学のd.schoolの5ステージのプロセスを用いて、デザイン思考のプロセスが説明されています。

図表41-2

「DX白書2021」から引用(179頁)

①共感(Empathise)

最初のステージです。行動観察やインタビューを行い、ユーザーの社会や環境に対する考え方、感情を理解します。

②問題定義(Define)

ユーザーが持つ真の問題を特定するステージです。問題定義文のフレームとして頻繁に用いられるものに「How Might We 〇〇?」(HMW)=「私たちはどうすれば〇〇できるか?」があります。

③創造(Ideate)

とにかく多数のアイデアを出すことが重要です。ブレインストーミングやマインドマップなどのツールを上手く活用してアイデア出しに集中します。

④プロトタイプ(Prototype)

テストに向けた準備を行うステージです。重要なのはテストしたい事柄、テストでユーザーに反応して欲しいことを先に考えから、プロトタイプの作成に臨むことです。

⑤テスト(Test)

作成したプロトタイプを用いて、ユーザーからフィードバックを得ます。単純に機能の利用についての可否を問うのではなく、ユーザーがどのように動くかの観察と、どのように感じるかのフィードバックを得ることが重要です。

デザイン思考に失敗しないために気をつけたい5つのこと

5ステージのプロセスの実践の際に取るべき態度について、英コンサルタント会社The Value EngineersのKamil Michlewskiが「Design Attitude」で提唱している5つの要素を紹介しています。

  1. 不確実性および曖昧性を受け入れる
  2. 深い共感に従う
  3. 五感の力を用いる
  4. 遊び心を持つことで物事に命を持たせる
  5. 複雑性から新たな意味を想像する

<「アジャイル開発」で素早く開発し、環境変化やニーズに即時対応する>

アジャイル開発とは、短期の計画を作り、実行し、見直すというサイクルを繰り返していく開発手法です。従来の、中長期な計画を厳格に実行していくウォーターフォール開発に代わり、「ビジネス変化と開発スピードのギャップ」を解消できる開発手法として期待されています。

アジャイル開発は、いくつかの枠組みや手法に分かれていますが、本章では、「スクラム」と呼ばれるフレームワークを例に取り上げ、アジャイル開発の定義と、開発を進める際の注意点を解説しています。

スクラムとは

3〜9名からなる開発チームである「スクラムチーム」が、ソフトウェアの実装からテストまでを実施する「スプリント」と呼ばれる短期間を繰り返していく手法です。

「プロダクトオーナー(PO)」は、スクラムチームが開発に専念できるよう、スクラムチームとユーザーや事業組織、経営層をつなぐ役割を担います。

「スクラムマスター(SM)」は、スクラムチーム内の障害を取り除き、スプリントが円滑に回るようにチームメンバーを後押しする役割を担います。

スクラムの手法をさらに詳しく知りたい方は、まずスクラムの定義や理論について説明する
スクラムガイドを参照してみることをおすすめします

アジャイル開発を進めるにあたり注意したい3点

①経営層がアジャイル開発を理解する

マネジメント側が、ウォーターフォール型開発の考え方に支配されていると、現場のレベル感と異なる報告を要求してしまい、開発側の負担になってしまいます。

②アジャイル領域の見極め方

「コーポレートIT」にもアジャイル開発を導入する価値はある

本紙では、「ビジネスIT(収益の源泉となる中核ビジネス、対顧客価値を提供するIT)」システムに限らず、「コーポレートIT(社内で利用する業務サービスITなど)」システムのアジャイル開発を推奨しています。

「要件が明確」「改修などの頻度が少ない」ことがあらかじめわかっているか

この場合、ウォーターフォール型開発が向いています。しかし、「要件が十分に明確でない」、「改修が起こらないという思い込み」であることも多いため、注意が必要です。

開発規模が大きい場合

大規模なシステムの開発で、スクラムチーム(3〜9名)より多人数の開発メンバーを必要とする場合、2通りの手段があると説明します。

  1. 細かいシステムに分割し、開発チームを割り当てる
  2. 分割が難しいなら、システム全体をウォーターフォールで一括開発する

③人材をどこから集め、どう配置するか

スクラムチームは「ビジネスIT」の開発に携わることが多いことから、自社メンバーで構成するのが良いとされています。

しかし、スクラムにおいて重要な役割を担うプロダクトオーナー(PO)やスクラムマスター(SM)、 チームのある側面における担当管理者(品質保証担当やセキュリティチャンピオン、技術リーダー、UIデザイナーなど)を自社内で集めることは難しいケースが多いです。

日本では、開発をITベンダーに委託するケースが多く、その一例を本紙で紹介しています。(図41-3)

図表41-3

「DX白書2021」から引用(184頁)

<「DevOps」で素早くリリースし、アジャイル開発を支える>

DevOps(デブオプス)とは、従来、分業・分断されていた開発と運用を一体運営するとともに、そのプロセスを自動化することを指します。開発プロセスにおける「スピードをあげたい開発部門と、安全性・安定性を重視する運用部門とのギャップ」を解消すると期待されています。

本章では、DevOpsを実現するためのポイントが解説されています。

コードデプロイプロセスでコードコミットから本番環境へのリリースまでのプロセス全体を自動化すべき

開発したソフトウェアを実際のサービスとして利用可能な状態にすることを「デプロイ」と言います。デプロイは「リリース」と同義です。

リリースまでに、ソフトウェアにはいくつかの環境(ステージ)の下で動作確認のテストが行われます。これを、「コードデプロイプロセス」と言います。(コードデプロイプロセスについては下の項を参照)

従来は、コードデプロイプロセスを省略、また確実に検証するために、コードコミットステージの段階で、構文解析・バグ検出ツールを導入し、自動化することが一般的でした。

しかし、これからは可能な限り全体プロセスを自動化するさまざまな検証を一気通貫して行ってしまう自動検証サービスを作る必要があります。アジャイル開発やDevOpsにおいて自動化は、スピードとアジリティの実現に不可欠だからです。

リリースまでの各プロセスステージ

本紙では、リリースまでの一般的なプロセスステージの例を、家を建てることと対比しながら説明しています。

リリースまでのプロセスステージのイメージ

DX白書2021の内容から著者が作成

図表41-4

「DX白書2021」から引用(186頁)

コードデプロイプロセスの自動化を実現させる2つの要素(CMとCD/CI)

①品質を左右する「構成管理(Configuration Management:CM)」

(定義)構成管理(CM)とは、各種の設定情報やプロジェクトの内外を含めた環境などを管理することです。

(必要性)一般的にソフトウェアは、ある決まった環境で実行されることを想定しています。検証の際には、その前提とされている適切な環境を設定しなければなりません。

しかし、コンピューターは数多くのソフトウェアが連携作動するため、適切な環境を設定することが難しくなります。

あらかじめ構成管理によって、必要となる適切な環境を準備しておけば、検証がスムーズに行うことができるのです。

(効果)リリース時の品質を左右し、管理の必要なアプリケーションの数や、その組み合わせた環境数が多いほど構成管理が重要となります。利用環境の数が多くなりがちなエンタープライズシステムで特に重要となります。

②クリック一つで検証可能になるテストシナリオを作る「CI/CD(継続的インテグレーション(Continuous Integration)/継続的デリバリー(Continuous Delivery))」

(定義)CI(継続的インテグレーション)とは、コードコミットステージにおけるプログラムの開発と単体テストまでの検証を自動化することを指します。

CD(継続的デリバリー)は、CIが自動化範囲をコードコミットステージに絞っているのに対し、全てのプロセスステージの自動化を目指します。

コード変更が行われた段階(コードコミットステージの達成の段階)で、変更されたコードが実行可能なソフトウェアに自動的に組み込まれ、テストや運用環境へのリリースに向けた準備(コードコミットステージ以降の各ステージ)も自動的に済んでしまう状態を目指します。

(必要性)人手によるプログラムコードの修正や単体テストの実行は長時間を要します。また、解釈やミスに基づく検証のばらつきが生じることも多く、品質が低下しがちでした。CI/CDは、決まったテストシナリオを作成することでこれらの問題を解決します。

ノーコード/ローコードツールで開発すべきシステムとは

本紙では、「費用をかけてシステム化するほどではないが、実現できれば業務の効率化が見込めるシステム」(例:部内における案件・物品管理や、簡易な承認システム)からノーコード/ローコードツールの使用を勧めています。必要な業務ロジックが整理されており、失敗しても業務面、セキュリティ面などのリスクが少ないからです。

業務部門に任せきりにしてはいけない

ノーコード/ローコードツールは、業務部門でも開発できる点が最大のメリットですが、システム部門が全く関わらなくて良くなるわけではありません。

セキュリティの穴が生まれる可能性もありますから、システム部門が技術リーダー、アドバイザーとしてサポー(効果)リリースまでの各プロセスステージを一つの大きなプロセスとしてつなぎ、自動化にすることで、リリースの高速化と品質の画一化を実現することができ、またリリースまでの業務負荷を大幅に下げることができます。

CI/CDを行う際の3つの注意点

①セキュリティ検証の自動化を忘れない

一般的にCI/CDにおいては、必ずしもセキュリティ検証は含まれませんが、本紙では各種セキュリティ検証がより効率良い検証につながるため、組み込むことを強く推奨しています。

②無闇に自動化せず、自動化の範囲を定める

「ユーザー受入れ試験ステージ」は人間が実際に使用してみて評価を得るべきなど、「機能試験ステージ」や「性能試験ステージ」では、機械による自動化が不適切な場合があるため注意が必要です。誰がどんな環境で使うのか、システムの使用するシナリオを想像して判断しましょう。

③開発者にもテストを意識させる

開発者にも設計やコーディングの段階でテストを意識してもらいます。「対応する単体テストコードがすべて成功することを開発者自身が確認したうえでコードコミットする」という文化を徹底するものです。

図表41-5

「DX白書2021」から引用(187頁)

<「ノーコード/ローコードツール」でシステム開発を効率化>

近年、プログラミング言語無しでシステムを開発できるノーコードツールや、専門的な開発知識無しに簡単なプログラミング言語で開発可能なローコードツールが注目を集めています。

さまざまな業務を実装するためのテンプレートがあらかじめ準備されており、汎用性・拡張性も徐々に高まってきています。IT人材が不足する企業においては有益なツールです。

業務部門主導で、現場のニーズにマッチしたサービスを効率よく開発可能

ノーコード/ローコードツールにより非エンジニアでもシステムの開発が可能になります。ユーザーである業務ロジックや業務フローを熟知した業務部門が開発を主導できるため、サービスの有用性や開発の効率がアップします。

ツールを選定する前に知っておきたい3つのデメリット

①大規模な業務システム開発に向かない

ノーコード/ローコードツールは0から開発していない分、ツール間の互換性が無いため、多くの機能と接続するようなシステムの開発は難しいと言われています。

大規模な業務システムは、ほとんどの場合、他のさまざまな機能と接続する必要があります。

②実装機能に制限がある

ノーコードツールは、テンプレート等を用意して、一般的な機能の実現を効率化します。そのため、業界や社内特有の機能を実装しようとしても、テンプレートが存在しないために使用できない可能性があります。

一方、ローコードツールはコーディングの中に組み込むこともできるため、ノーコードツールと比較すると制約は少ないですが、ある程度の制約があることを理解しておきましょう。

③ベンダーロックインの可能性がある

ノーコード/ローコードツールは、ツール間の互換性が低いことに加えて、ライセンス費用が高額になることが多いため、一度使用すると他ツールサービスへ移行することが難しくなると言われています。

<導入プロセス>

小さく立ち上げて育てていく3つのポイント

DX実現のためには、デザイン思考、アジャイル開発、DevOps、ノーコード/ローコードツールといった新しい開発手法の導入は必要不可欠です。実際に導入する際に気をつけたいポイントが紹介されています。

①部分的なITシステム開発への導入から始める

新しい開発手法は業務への影響・リスクを考慮して導入する必要があります。一度に全てのITシステムに対して導入することは難しいですから、既存業務への影響を最小限にするため、一部のITシステムへの使用から考えていきましょう。

具体的には、エンドユーザーのニーズに合わせ、機能追加や改修が高い頻度で発生するシステムや、業務自体が「小さく立ち上げ育てていく」ことを目指している業務のITシステム化を検討すると良いでしょう。

②小さい組織への周囲の理解を深める

新しい開発手法に関するノウハウやスキルを持っている人材は不足しているます。そのため、新しい開発手法を実践していくのは、小さい組織で、外部人材が参加することも多いと考えられます。

徐々にメンバーのスキル・経験が蓄積され、組織の中のモデルケース、中規模組織への拡大というステップを踏んでいきますから、彼らが社内の理解を得られるよう組織間の連携体制、経営層の積極的な社内啓蒙活動が重要となります。

③ビジネス部門を巻き込んで体制を作る

DXの価値は、競争の優位性の確保にあります。新しい開発手法を取り入れる目的も、ユーザー部門にビジネス価値を素早く提供することにあります。IT部門はビジネス部門の業務、ニーズを理解する必要があり、ビジネス部門は自分たちの悩みを新しい開発手法で解決可能かどうかを検討するべきです。

両部門の間で人材ローテーションを行うなど、経営層がリーダーシップを発揮して部門間の壁を取り払うことが大事なポイントとなります。

【ITシステム開発技術】

開発スピードを高める方向にITアーキテクチャーは進化し続けている

ITアーキテクチャーとは、業務アプリケーション、データ、システム基盤を含むシステム全体の構造のことです。ITアーキテクチャーのトレンドの変遷を見てみると、

1980 年代末までのメインフレーム、1990年代のクライアント・サーバーシステムによるオープン化(脱メインフレーム)、2000年代のインターネットの普及によるWeb化を経て、現在はスマートフォンやクラウドの積極的な利用が主流となっています。

DX時代に求められるITアーキテクチャーの特徴

企業が保有するシステムの特性を踏まえ、現状維持機能を持つシステムと差別化機能を持つシステムの2つに大別します。

(現状維持機能)業務オペレーションを遂行するためのシステム群、社内ユーザーが利用する人事給与、財務会計、生産管理といった企業の業務と直接関わる業務向けシステムのこと。品質と安定性を重視して、ウォーターフォール型の開発が推奨されています。

(差別化機能)顧客との接点として利用するWebやモバイルアプリなどのシステム群のこと。事業のあり方に強く影響を及ぼすため、DX促進において特に重要視されます。アジャイル開発やDevOpsなどの新しい開発手法を積極的に活用して開発することが推奨されます。

知っておきたいEA(エンタープライズアーキテクチャー)の考え方

DX推進に欠かせない、高頻度の変更の要請に耐えられるアジリティの高いITアーキテクチャーの構築に有用な考え方としてEAがあります。

EA(Enterprise Arcitecture)とは、2000年頃に流行ったビジネス、データ、アプリケーション、テクノロジーの4つのアーキテクチャー階層からなるフレームワークです。

経営戦略とITシステムの一貫性を維持し、全体最適化を実現するのに有効な手段です。

ビジネス(BA)とデータ(DA)の2つの階層はビジネスモデルが変化しない限り大きく変化することはありません。一方、アプリケーション(AA)、テクノロジー(TA)の2つの階層は急速に進化する技術や、移り変わりの激しい技術トレンドの影響を受けます。

図表41-8

「DX白書2021」から引用(197頁)

本紙では、テクノロジーアーキテクチャー(TA)とアプリケーションアーキテクチャー(AA)の動向について詳しい説明が掲載されています。

<クラウド>

(定義)ITインフラである「クラウド」は、従来の自社のデータセンターやサーバーといった「オンプレミス」(on-premises、「敷地上」→「自社運用」という意味)のITインフラに変わるものとして利用されています。

明確な定義はされておらず、米国国立標準技術研究所(NIST)の2009年の公表資料によると、以下5つの特徴を併せ持つものと言われています。

    1. オンデマンド・セルフサービス
    2. 幅広いネットワークアクセス
    3. リソースの共用
    4. スピーディな拡張性
    5. サービスが計測可能であること

(利用形態、パターン)活用事例から、クラウドの利用パターンは特定の組織専用で利用する「プライベートクラウド」と、クラウドベンダーが広く一般向けにITインフラとして提供する「パブリッククラウド」に分類されます。

他にも、プライベートクラウドとパブリッククラウドを組み合わせた「ハイブリッドクラウド」、複数のパブリッククラウドを組み合わせた「マルチクラウド」等のパターンも存在します。

(クラウドサービスの種類)クラウドサービスは利用者が何をどこまで管理し、他をクラウド事業者の管理に任せるかによってサービス名が分類されています。全てを利用者が自社で管理する「オンプレミス」との対比でそれぞれのサービスを可視化した表が以下になります。

図表41-9

「DX白書2021」から引用(198頁)

メリット・デメリット
クラウド活用によるメリットとデメリット

DX白書2021の内容から著者が作成

クラウド利用を躊躇する理由と対策

多くの企業がクラウドの利用に踏み切れていない理由として2つ挙げられています。

1. クラウド利用に対応できる技術者が不足している

2. コストに直結するクラウドのメリット要素を適切に見積もるノウハウがない

これらを解決して利活用するには、中途採用や社内でのエンジニア育成、外部パートナーの積極的な活用が有効であると言われています。

CCoE(Cloud Center of Excellence)

クラウド関連の状況と情報を把握し対応を進めるための専門部署としてCCoEを導入する企業が増えています。

クラウドは日々進化しています。クラウドの導入時だけでなく、クラウドの導入後もどう活用していくかについて引き続き検討しなければなりません。

そのような状況に対応するため、利用者や管理者に最新のクラウド知識を共有する専門部署の新たな立ち上げは必要不可欠かもしれません。

図表41-13

「DX白書2021」から引用(206頁)

<コンテナ>

(定義)コンテナとは、物理的なサーバーの中に仮想環境(仮想のサーバー)を作る「仮想化」という技術の一つで、仮想化よりもアジャイルなシステム開発に向いた技術と言われています。

アプリケーションを動作させるOS(Windows/Linux…)は物理サーバーごとに一つしかないため、さまざまなアプリケーションを使用するためには、複数台の物理サーバーが必要でした。

仮想化技術は、仮想化ソフトウェアによって物理サーバー内に複数の仮想サーバーを生み出します。これにより、一つの物理サーバーで複数のOSを実行させ、複数のアプリケーションを使用することができるようになります。

コンテナによって作られる仮想サーバーであるコンテナサーバーは、OSを含まない形でアプリケーションの実行環境をパッケージ化したものです。

コンテナサーバーは従来の仮想サーバーよりも軽量であるため、仮想化よりも高速に実行環境を構築が可能です。また、稼働環境を移動しやすく、本番環境でアプリケーションが動くかどうか簡単に試すことができます。

図表41-10

「DX白書2021」から引用(201頁)

コンテナセキュリティガイド

日本の経済産業省に当たる米国の商務省にあるNIST(National Institute of Standards and Technology)が2017年に発行しました。

コンテナに関連する潜在的なセキュリティリスクと、リスクに対処するための推奨事項、ベストプラクティスが掲載されています。

ただし、IPAはセキュリティガイド等に頼りすぎず、導入対象となるシステム種別や特有の事情に合わせた判断、カスタマイズが必要であると主張しています。

<マイクロサービスアーキテクチャー / API>

(定義)あるサービスのプログラムと別のサービスのプログラムを疎結合させる(軽く連携させる)API(Application Programming Interface)と呼ばれる技術を使ってシステムを開発し、サービス毎に改修できるようにするマイクロなシステム設計のことです。

従来のサービス毎にプログラムを分割させることなく、全て同一のモジュールとして作り上げる設計はモノシリックな設計と言われます。

モノシリックなシステムでは、複数のサービス間でデータベースを共有している場合が多いです。一方、マイクロサービスアーキテクチャー(MS)ではデータベースも個々のサービス毎に管理されます。

サービスの連携の仕方の違いから生じるそれぞれのメリット・デメリットは図の通りです。

モノリシック&マイクロ

DX白書2021の内容から著者が作成

コンテナとマイクロサービスアーキテクチャー

サービス実装するためにコンテナを用いると、アプリケーションの可搬性と自由度が上がり、リリースが簡単になります。マイクロサービスアーキテクチャーのように各サービスをリリースする作り方との親和性が高いです。

サービスメッシュとマイクロサービスアーキテクチャー

サービスメッシュとは、マイクロサービスアーキテクチャーにおいて、各サービス間で行われる通信を支えるネットワークサービスのことです。主に、4つの利点をもたらします。

①サービスの発見(Service Discovery)

サービスがリリースされる度に依存関係にあるサービスを調査し、システム側で適切な接続先を決定する

②障害の分離(Fault Isolation)

通信障害が起きた時に他のAPIを遮断し、波及を防止する

③分散トレーシング(Observability)

サービス間の通信内容を監視、追跡して問題発生時に発生箇所の特適当を支援する

④認証・認可(Security)

セッション情報やアクセス権限などを一元管理する

図表41-12

「DX白書2021」から引用(204頁)

Netflixも導入

マイクロサービスアーキテクチャー導入の先進企業として有名なんのがNetflixです。

Netflixは開発スピードを加速するための手段としてマイクロサービスアーキテクチャを採用しました。マイクロサービスアーキテクチャーは、試行錯誤を重ねながら取り組むことを求められるため、その導入目的及びKPIを初期段階で設定することが重要となります。

各チームの最大人数は8名まで

マイクロサービスアーキテクチャーの導入には、各業務を最高速でこなせるようなシステム開発・運用体制への変更も必要になります。

Amazon創業者のJeff Bezosが提唱する“Two-Pizza Teams“(各チームの人数はピザ2枚を分けられる人数を超えてはならない)のルールによれば、各チームの最大人数は8名に制約されます。

Strangler Application Patternで段階的に切り替える

マイクロサービスアーキテクチャーの導入は大きな変革が必要となるため、一括ではなく段階的に切り替えていくことが有力な方針です。

Strangler Application Patternは、 段階的な切り替え方式として有名です。システム間連携を担うゲートウェイ(Strangler Facade)を通じて新システムと旧システムで連携を行う方式にシステム全体を切り替え、徐々にシステムを新システムへ切り替えていきます。

図表41-14

「DX白書2021」から引用(204頁)

【開発手法・技術の活用状況と課題】

日米で顕著なITシステムに必要とされる機能への意識の差

スピード・アジリティ、データ利活用などの「ビジネスニーズに対応するためにITシステムに求められる機能」について、日米企業に「重要度」と「達成度」をそれぞれ尋ねた結果、日本企業は多くの項目で「重要である」「まあまあ重要である」と回答しながら「達成している」「まあまあ達成している」と回答した割合は半分以下でした。

一方、米国企業は「達成度」が「重要度」に比べ低いですが、その差は小さく、重要視する機能を着実に実現していることがうかがえる結果となりました。

図表41-15

図表41-16

「DX白書2021」から引用(211,212頁)

スピード・アジリティに対する意識が高い米国

IPAは、日米企業の「ITシステムの開発手法・技術の導入目的」(図表41-18)について調査しました。

ソフトウェアのリリースサイクルの短縮、生産性や品質、保守性の向上、継続的デリバリーの実現などを目的として技術を積極的に導入している様子から、米国企業の「スピード・アジリティ」に対する意識の高さがうかがえます。

図表41-18

「DX白書2021」から引用(214頁)

日本のDX取組みの遅れは企業文化に関する課題認識の低さか

「ITシステム開発手法・技術の活用課題」について調査を行ったところ、米国企業が課題としている項目は「組織文化」「変化への抵抗」「経営の理解」「従来からの変更」「チームの一貫性」など企業の文化に関連したものが多い結果となりました。

日本では「特に課題はない」と回答した割合が米国企業と比較して高くなりました。IPAは、現在の日本企業は外部への委託・発注が多いが、これから変化への対応のため、アジリティを重視するシステムの内製比率をあげるのであれば、米国企業と同様の課題意識を持つことが大切であると述べています。

共通プラットフォームの利用は米7割に対し日本たった1割

「共通プラットフォーム」とは、企業が経営資源を競争領域に集中するため、自社の強みとは関係の薄い協調領域を業界内の他社と合意形成してプラットフォーム化することで、IT投資の効果を高める新たなベンダー企業像の形態の一つです。

共通プラットフォーム導入のメリットには、

  • ITコストを割り勘することによる低コスト化
  • プラットフォーム運用にかかる個社の負担の低下
  • セキュリティの確保
  • 異なる事業間でのデータ連携・利活用促進

などがあります。

日米企業に、共通プラットフォームの利用意向を尋ねたところ、「すでに利用している」「すでに利用しており、さらに対象領域を拡大したい」と回答した割合は、米国企業が7割近いのに対し、日本企業は1割程度でした。

日本における共通プラットフォーム利用への障壁

1.プラットフォーム化に対するニーズが少ない

日本では、取次店などの非システム的な共通ビジネスブロックが発達しています。出版産業における主要取次書店のように、類似した形態も存在するため、必ずしも共通プラットフォームが全く新しい考え方であるとは言えないことに注意が必要です。

2. 業務の可視化、モジュール化が目前の課題

日本では、欧米のように業務のモジュール化が進んでいません。それぞれの業務がすり合わせをしながら進んでいくため、プラットフォーム化のために必要な、共通化部分を切り出すためには、まず業務の可視化、モジュール化が必要となります。

他にも、以下のような課題があります。

  • 業界内の各社間で、個社の事情によりどこが共通化すべきかの理解が異なる
  • 共通プラットフォームのビジネスモデルや負担水準の設定がしにくい
  • 短期的には自社のITシステムの改修コストがメリットを上回ってしまうことがある

しかしながら、IPAは、日本企業は共通プラットフォームがないことが米国と比べて業務の生産性を低下させる要因となっていることを自覚し、導入に向けた地道な活動が重要であると主張しています。

第2章 データ利活用技術

データを分析から顧客のニーズを捉え、サービスの立ち上げ、改善のサイクルを回し顧客価値を高めることはDXの推進に欠かせません。本章では、進化し続けているデータ利活用技術として「データ活用基盤」「AI」「IoT」の概要と活用状況、課題について理解を深めることができます。

<データ活用基盤技術>

最近では、社内システムにあるデータに限らず、IoTデータや社外データなどさまざまなデータを収集・活用できるようになってきました。それに伴い、企業のデータ活用の範囲は、自社の経営・リスク管理や業務改善から、業務・商品・サービスの高度化や新たな価値創造へと拡大しています。

図表42-1

図表42-2

「DX白書2021」から引用(218,219頁)

データ活用基盤は機能を拡張する前提でスモールスタート「Think Big, Start Small」

データ活用基盤とは、サービスの高度化や新たな価値創造の実現に向けて、社内外のさまざまなデータを収集し、分析しやすい形に整形・蓄積し、活用を行うシステム群、プラットフォームを指します。

データ活用基盤を実装すると、「機能不足」や「拡張に時間・コストがかかる」、「使わない機能が実装され、投資が無駄になる」などの課題が散見されます。

これは、データ活用の「ビジネス環境変化に応じて必要なデータや分析手法が頻繁に変化する」という特徴を考慮できない場合に多い失敗です。

必要な機能に優先順位をつけ、機能を順次拡張する方針で構築を始めましょう。

図表42-20

「DX白書2021」から引用(232頁)

データ活用基盤の全体像と各技術について

データ活用基盤に使用される各技術の概要・特徴・活用する際のポイントは以下の図表42-6,42-8の通りです。各技術の役割と相互関係を把握しましょう。

図表42-6

「DX白書2021」から引用(221頁)

図表42-8

「DX白書2021」から引用(222頁)

データアーキテクチャーを定義する

データアーキテクチャーとは、ビジネスの中心となるコアデータ、コアデータを中心に構成されるデータモデル、そしてデータモデルで表現されるデータを活用するためのデータ活用基盤の3つの要素からなるものです。

図表42-18

「DX白書2021」から引用(230頁)

コアデータとデータモデルのイメージ

データアーキテクチャーからわかるように、データ活用基盤を構築する上でコアデータとデータモデルの整理は欠かせません。

コアデータはビジネスの目的に応じて決定する必要があります。たとえば、顧客視点に立って新たな価値創造を進めたいと考える小売業者の場合、ビジネスで扱う様々なデータのうちコアデータとなるのは「顧客」です。そして、定義したコアデータを中心に、他のデータの関係性を整理します。

図表42-19

「DX白書2021」から引用(231頁)

導入のため検討プロセス(5つのタスク)

本紙ではデータ活用基盤を導入するための流れは、データ活用要件の整理、現行システム整理、技術動向調査、システム全体像整理、全体プラン策定の5つのタスクによりデータ活用基盤の構築計画を進めることが推奨されています。

図表42-21

「DX白書2021」から引用(232頁)

既存のデータ活用基盤の再構築を検討する(ANAの事例)

データ活用基盤の導入事例として、ANAの事例が挙げられています。ANAは以前からデータ活用基盤を利用していましたが、データの戦略的な活用のため、データ活用基盤を刷新しました。

長年使い続けたシステムでは、十分なデータ活用を行うことができないというケースは少なくありません。今後さらに活用できるデータが増えると予想されています。IPAはデータ活用基盤の見直しの必要性を強く主張しています。

<AI技術>

様々な分野で活用が広がるAIについて、2020年3月に発行された「AI白書2020」を引用しながらその現状と複数分野における事例を紹介します。付録の第1部「AI技術」で、AIの基礎的な部分について知ることができるので、本項と合わせて読むことが推奨されています。

AIを理解するための9つのキーワード

本紙では、人間の知的活動を認識、理解、学習、判断、予測、言語、知識、身体性、創作の9つに分類することでAIへの理解を促しています。それぞれのキーワードとAI技術の関係は図表42-24のとおりです。

図表42-24

「DX白書2021」から引用(239頁)

注目すべき4つの先端技術

IPAは、本紙の中でAI技術のトレンドを理解するために注目すべき技術を4つピックアップしています。

①自然言語処理

自然言語処理とは、人間の言語(自然言語)を機械が理解する(処理する)ことです。2018年にGoogleが発表したBERT(Bidirectional Encoder Representations from Transformers)により大きく進展しました。

文章の中で前後して扱う指示語や代名詞などの処理が自然言語処理の壁になっていましたが、文章中の単語に焦点を当てることでその単語と関係する文章でのあらゆるつながりを見つける”Attention”という方法が生み出され解決されました。

Attentionを中心とした機械学習は「Transformer」と呼ばれ、特徴として「パラメーター数の拡大」「言語モデル」「Zero (Few) Shot学習」の3つが解説されています。

②AIの導入・運用を容易にするための技術(API化、AutoML、MLOps)

AIの導入には大量のデータをどのように扱えばよいのか、そもそもデータが集まるのかなど多くの課題があります。AIの導入・運用を容易にする新しい取り組みを3つ紹介します。

API化

AIタスクを毎回一から作るのではなく、API化することで、呼び出しと組み合わせでシステムを構築しようという取り組みがあります。

たとえば、アメリカのAIを研究する非営利団体OpenAIは、自然言語処理系のAIタスクをAPI化したGPT-3(https://gpt3demo.com/)というサービスを提供しています。

AutoML (Automated Machine Learning)

機械学習の各プロセスを自動化し、エンジニアの生産性の向上や誰でも械学習を使えることを目指した技術です。 具体的には、AutoMLは従来人が手作業で行ってきた「ハイパーパラメータチューニング」「モデル選択」「特徴エンジニアリング」の3つを行います。

MLOps

機械学習にDevOpsの概念を取り入れたものがMLOps (Machine Learning + Operations)です。なぜDevOpsの概念を取り入れるのでしょうか?

機械学習は既存の、過去のデータの学習によって機能しているため、新たなデータに必ず対応できるわけではありません。開発と運用を繰り返して、対応できない新たなデータを学習し、さらに推論の精度を高めていくことが重要です。

そのため、設計・開発・運用をシームレスに行うDevOpsの概念は機械学習と親和性が高いと言えます。

③フェデレーテッドラーニング学習と分散学習

データを移動する必要がないフェデレーテッドラーニング

フェデレーテッドラーニング(Federated learning、連合学習)とは、デバイスとクラウドを用いてより高いセキュリティで機械学習を行うことです。

その仕組みは、個々のデバイスでクラウドから「現状のモデル」をダウンロードし、データのあるデバイスで機械学習を行った後、そこで得られた改善点や変更点をクラウドに送信します。それを元に、クラウドでモデルを改善し、デバイスが「新しいモデル」をダウンロードすることを繰り返します。

従来は、機械学習に必要となる大量のデータを学習基盤に渡す必要があり、企業にとって重要な情報を外部に持ち出す危険性がありました。その点、フェデレーテッドラーニングは、データの保有者側で機械学習を行うことができるため注目を集めています。

データを分散させたままで良い分散学習

分散学習とは、データを1ヶ所に集約させることなく、全部のデータを1カ所に集めて学習したのと同等のモデルを得ることができる技術です。プライバシー保護の観点からデータをローカルなサーバー・機器にとどめておきたいという需要に応えることができます。

今後、IoTからの膨大なデータを集めるなど、データを1カ所に集めることがさらに難しくなると予想されるため、注目が集まる技術です。

④量子機械学習

量子計算アルゴリズムを使用することで、学習アルゴリズムの一部を置き換えた機械学習を量子機械学習と言います。量子コンピューターを使うことによる量子加速(従来のコンピューターより早く計算できることによる時間の短縮)と、消費電力が大幅に削減できる可能性が高いことから期待されている技術です。

各分野での利用動向

医療分野での利用(Pfizer, Saama、Moderna)

医療分野において、人工知能はこれまでアクセスできないことで有効利用できていなかった研究データ、生産データから重要な洞察を導き立つことで貢献しています。

Pfizerの迅速なCOVID-19ワクチンの開発も裏には、AIを用いて複雑で手間のかかる臨床データ解析を効率化させたSmart Data Query(SDQ)や、医療に特化した自然言語処理を行うSaama社のAIクラウドサービスの活用などがありました。

同じようにワクチンを開発したModernaも、ワクチン開発以前からAIを含むデジタルプラットフォームを活用してタンパク質の折りたたみ研究に不可欠なメッセンジャーリボ核酸(mRNA)の研究を行ってきました。

図表42-35

「DX白書2021」から引用(253頁)

エネルギー分野での利用(Royal Dutch Shell)

オランダとイギリスの石油会社であるRoyal Dutch Shellは、機器のメンテナンス時期の予測や、シェール鉱床を通るドリルビットの操縦支援、井戸の正確なコース把握にAIを活用し、コスト削減、従業員の負荷軽減、ドリル消耗の軽減に取り組んでいます。

航空分野での利用(Air France-KLM)

AIをMRO(Maintenance Repair Overhaul:整備・修理・分解点検)戦略に結びつける航空会社が増えています。メンテナンスの必要性を予測するAIを、メンテナンスチームの意思決定ツールにしようという取り組みです。

欧州最大の航空会社グループであるAir France-KLMは、自社のMROラボを設立し、Prognosを開発しました。Prognosは飛行中及び地上の航空機からデータを取得するソフトウェアで、これらのデータはリアルタイムでメンテナンス・コントロール・センターへ提供され、メンテナンス作業の指示につながります。

図表42-36

「DX白書2021」から引用(255頁)

海運分野での利用(Maersk)

海運コングロマリット企業であるMaerskは貨物内のコンテナの品質管理を行うリモート・コンテナ・マネジメント(RCM)技術、船内の温度や湿度、CO2レベルを監視し顧客に通知するAIバーチャルアシスタント、船の性能を理解させ船の燃費を向上させるAIの開発、利用を探っています。

購買テック(小売り)分野での利用(Walmart IRL (Intelligent Retail Lab)、Carrefour、Ocado)

アメリカの大手スーパーマーケットチェーンであるWalmartは、商品の動きに焦点を当て、毎週5億アイテムの需要予測をAIで行いました。

Walmart IRL (Intelligent Retail Lab)と呼ばれるAIは、多数のカメラで棚に並ぶ製品を把握し、在庫管理と需要予測を行います。

陳列棚の迅速な補充や、生鮮食品の鮮度の維持や廃棄、交換のタイミングなどもAIが認識、判断してくれるため、店員の負荷が軽減されました。

図表42-22

フランスのスーパーマーケット大手CarrefourのAI導入として注目されたのは、食料品店でのレジなし購買システム、AiFi(https://aifi.com/)です。

また、オンライン食料品大手のOcadoは、AIとロボットを駆使した最先端の顧客満足向上センター(CFC)と精緻な宅配システムを独自に確立しました。倉庫は完全に自動化されており、ピッキングロボットを自社開発したことでも有名です。

製造業での利用(BMW Group、Nokia、General Motors(GM) 、Autodesk)

BMW GroupはAIを使用して、進行中の生産ラインを評価し、標準からの逸脱をリアルタイムで発見することでコスト削減を確立しました。

フィンランドの通信会社Nokiaは、製造プロセスに不整合がある場合に、リアルタイムにオペレーターに警告する機械学習を使用したビデオアプリケーションを導入しました。Nokiaは自社での使用にとどまらず、SpaceTime scene analyticsというサービスを外部に提供しています。

General Motors(GM) はAutodeskと協力して、機械学習技術による精製的設計アルゴリズムを実装し、最適な製品設計を可能にしました。制約条件内で機能要件、材料、製造方法、およびその他の制約の定義を行うとAIが製品設計を行います。

図表42-38

「DX白書2021」から引用(258頁)

<IoT>

データ活用技術の進歩により、データの価値は高まっています。外部環境の変化に合わせてデータを収集できるIoT技術は、データ利活用の基盤を支える最も重要なデータ獲得手段として注目されています。IoTを構成する技術の進歩やIoT導入のプロセス、課題について見ていきます。

IoTとは

IoT(Internet of Things)とは、「モノ」をインターネットに接続させ、リアルタイムな情報収集を可能にする技術です。

センサーやカメラ、家具や工作機械などの様々な「モノ」が、他の「モノ」やコンピュータと接続し、データを収集したり相互に情報をやり取りします。身近な例では、スマートスピーカーやスマートウォッチ、スマートフォンで遠隔操作可能な家電などがあります。

IoTが注目されている理由は、離れた場所にあるデバイスが生成するデータをリアルタイムで取得できる点にあります。自社製品へIoTを搭載することで、顧客の製品の利用状況・利用頻度など、ビジネスに役立つデータを集めることができます。

また、IoTで取得したデータを、AIなどのデータ分析技術と組み合わせ、分析・予測・シミュレーションからコスト削減、生産性向上、異常発生の予測、機器のリアルタイム遠隔制御・操作が可能になることもIoTに期待が集まる理由です。

図表42-40

「DX白書2021」から引用(264頁)

IoTの構成要素の発達

IoTはいくつかの技術で構成されます。構成要素となる技術の発展は、取得できるデータのリアルタイム性の向上に繋がり、IoTによるデータがより精密になります。精密なデータが不可欠である遠隔手術や建機の遠隔操作、高度な自動運転などの実用化を予測するために、IoTの構成要素となる技術に注目していきましょう。DX白書の中では以下3つの技術に焦点が当てられています。

①5G、ローカル5G

5Gとは、第5世代移動通信システムの略で、超高速通信、超低遅延通信、多数同時接続を可能にする技術のことです。IoTにおいて、映像などの大容量データの高速伝送、リアルタイムな遠隔操作、膨大な数のセンサーからの精密なデータ収集に寄与します。

ローカル5Gとは、通信事業者による全国向け5Gネットワークと異なり、地域の企業や自治体が主体となり、工場内や施設内、地域内に限定された狭いエリアに構築される5Gネットワークのことです。ローカル5Gは、使用用途に応じてその性能を柔軟に設定できること、ローカルネットワークゆえに通信障害などの影響を受けにくいなどのメリットがあります。

図表42-41

「DX白書2021」から引用(265頁)

②エッジコンピューティング

データを収集する末端のIoT機器やその近辺(エッジ)でデータの処理を行うことを指し、データをクラウド上で集中処理するクラウドコンピューティングの対となる考え方です。

図表42-42

「DX白書2021」から引用(265頁)

エッジで処理できるため、少ない通信でよりリアルタイムな処理が可能であり、インターネットやクラウドの障害時でも処理を継続できます。自動運転や即時制御が必要とされる機器での利用が期待されています。

IoTで収集した生データを処理し、安全で必要なデータのみをサーバーへ送信できることから、高いセキュリティと通信コストやストレージのコストの軽減にもつながると言われています。

③デジタルツイン

IoTで収集した大量のデータを用いて、物理空間に存在するモノやヒトを仮想空間上に再現したもの、あるいはそれを活用したシステムを指します。仮想空間上で、現実に近いシミュレーションを行うことができ、デジタルツインからのフィードバックが設計や生産の効率化、改善に役立ちます。

図表42-43

「DX白書2021」から引用(266頁)

4つのIoT活用事例

①可視化(アクア株式会社、Rockwell Automation)

アクア株式会社は、コインランドリーのIoT化に取り組み、製品状態を可視化しました。各店舗の洗濯機の稼働状況をIoT化によって可視化し、機器の管理やメンテナンスに活かすことによる運営の効率化、稼働状況を顧客がweb上で確認できるようにすることで待ち時間短縮という顧客への価値提供を行っています。

アメリカの大手産業機械メーカーであるRockwell Automationは、IoTによるサプライチェーンの可視化を行いました。海上での石油掘削場からガソリンスタンドに至るまで、数百キロメートルにも及ぶサプライチェーンから自動でデータを収集・統合・構造化し、リアルタイムな洞察、予測や予防保守が可能となっています。

②ITとOTの連携(Daimler Trucks North America)

新型コロナウイルス感染症の感染拡大によって、稼働状況を遠隔監視する取組みの需要が高まり、OT(Operational Technology)領域のIoTプラットフォーム連携が加速しています。これまで外部ネットワークから切り離されていたOT環境を接続するため、セキュリティの確保が重要となります。

アメリカのトラック製造会社であるDaimler Trucks North Americaは、Cisco Systems(米国)及びRockwell Autoation(米国)と提携し、OTシステムとITシステムを統合しました。工場での生産を中断することなくシステムを移行し、部品管理の改善やダウンタイム(正常なサービスを提供するために必要なシステムの休止時間)の低減に成功しました。

③AIを用いた分析・予測(ASUS)

AI技術の発達によって、計算機では分析が難しかった画像や音声などのデータが活用可能になり、IoTセンサーによってこれらのデータを収集する事例が増えています。

台湾のPC、スマートフォン、周辺機器製造メーカーのASUSは、自社が取引する数百のサプライヤーの製造品質の改善・業務効率化のため、高精度で機械部品の欠陥を検出する自動光学検査や、ファンの回転音の波形分析による品質検査といったAIとIoTを組み合わせたソリューションをサプライヤーへ提供しています。

④デジタルツイン(キオクシア、BMW、シンガポール、日本、杭州市(中国))

キオクシアは、四日市工場を中心にデジタルツインを活用したスマートファクトリーの先進的な取り組みを進めています。膨大なセンサーデータや検査計測結果を集約・構造化し、人の作業履歴や判断結果、文書と組み合わせて作成されたデジタルツインの中で、AIを用いたデータ分析やシミュレーションを行いっています。不良になりそうな状態の事前検知・欠陥の原因特定に役立てており、その結果をフィードバックして生産性や品質の工場を見込んでいます。

ドイツのBMWは、NVIDIA(米国)と提携して、従業員を含む工場全体のデジタルツイン化に取り組んでいます。NVIDIAのプラットフォーム”Omniverse”を活用し、シミュレーションや機械学習によって工場のライン変更の効率化を可能にしました。

スマートファクトリーの事例の他には、都市のデジタルツインの事例があります。シンガポールの「バーチャル・シンガポール・プロジェクト」は、政府関係機関によって、3D都市モデルと交通状況・エネルギー関連情報などを組み合わせ、都市レベルでのデジタルツインの実現を目指しています。

日本国内では、国土交通省が全国約50都市の3D都市モデルを整備・オープンデータ化して、モニタリングや防災シミュレーションなどを行うことを目指す「PLATEAU」プロジェクトを進めています。

中国の杭州市では、Alibaba(中国)が主導してスマートシティ化を推進しており、渋滞緩和・治安向上といった成果をあげています。

データ収集を第一目標に、スモールスタートで始める

IoTシステムは大規模になりがちであるため、スモールスタートのアプローチが役に立ちます。これまで取得していなかったデータの収集・可視化を第一目標にして、一定の成果を出してからAIでの分析、システムの拡張を行っていくことが推奨されています。

導入・運用コストや導入までにかかる時間を抑える方法として、国内外の企業が提供するIoTプラットフォーム・ツールの活用も検討してみましょう。

複合技術であることによる導入・運用の障害

複数の技術で構成されているIoTは、構成要素の一部の変更によって他の要素に意図しない変化が起こってしまう場合があります。連携するシステムを含めたシステム全体のテストや、障害発生時の対応マニュアル、責任者の明確化などが必要です。

<データ利活用技術の活用状況と課題>

データ活用基盤技術やIoT、デジタルツインなどのデータ利活用技術に関する現状と課題について、調査、日米比較が行われました。日本企業のデータ利活用促進のポイントについて解説されています。

日本企業の約7倍の米国企業が「データ整備ツール」を活用している

「データ利活用に関する技術の活用状況」について日米企業を調査した結果が図表42-44です。全ての技術において日米差は大きいですが、特に顕著なのが「データ整備ツール」で、「全社的に活用している」が日本企業6.8%に対して米国企業は50.1%と約7倍になっています。

また、「この手法・技術を知らない」と回答した割合が日本企業3割前後に対し米国企業が1割前後であることも特徴です。

図表42-44

「DX白書2021」から引用(274頁)

IPAはこれらの結果から、米国企業は、経営や事業企画、営業や製造現場などあらゆる部門においてデータ利活用の文化が浸透し、関連技術の利用率を押し上げていると考えています。

データ活用技術導入の最大の課題は「人材の確保」

日本企業の最大の課題は「データ整備・管理・流通の課題」(42-45)「AI導入課題」(42-53)「IoT導入における課題」(42-60)ともに「人材の確保が難しい」が最も高い割合となりました。

米国企業の最大の課題は、「経営層のデータ活用技術への理解がない」「IT部門が最新のデータ関連技術に対応できない」など経営者や組織の課題が上位に来ています。

図表42-45

「DX白書2021」から引用(275頁)

図表42-53

「DX白書2021」から引用(283頁)

図表42-60

「DX白書2021」から引用(290頁)

また、IPAは「IoT導入における課題」(図表42-60)の回答のうち、「セキュリティーやプライバシーに関するリスクがある」と回答した割合が16.9%であることに危機感を覚えています。日本でもICカードやスマートフォンによる個人情報の扱いが問題になっていることを踏まえて、課題認識を強めるべきだと主張しています。

データ分析環境の整備で大幅に遅れをとる日本企業

データ分析(AIを含む)を実施するためのIT環境の整備状況を尋ねた結果、日本企業は各項目とも、「整備している」「おおむね整備している」を合わせても15%に届いていません。一方、米国企業の回答は全ての項目で60%以上となっています。

図表42-46

AIを顧客価値の向上に使う米国企業と業務改善に使う日本企業

AIを導入している企業にその導入目的を尋ねた結果が、図表42-49です。米国企業では、「新サービスの創出」「新製品の創出」など顧客価値の向上に関する項目が高くなりました。日本企業は、「業務効率化による業務負担の軽減」「生産性向上」など業務改善に関する項目が目立っています。

図表42-49

「DX白書2021」から引用(279頁)

AI導入による「売上増加」効果(図表42-50)、「コスト削減」効果(図表42-51)について調査した結果、顧客価値向上に使う傾向のある米国は、やはり高い売上増加効果を得ていることがわかります。

図表42-50

「DX白書2021」から引用(280頁)

業務改善に使う傾向のある日本企業でしたが、実際のコスト削減効果は米国企業より総じて低い結果となりました。

図表42-51

「DX白書2021」から引用(281頁)

深層学習以外の技術に注目せよ

活用しているAI技術について日米企業に尋ねた結果、データ関連技術の活用が進んでいる米国企業の方が総じて割合が高いが、「ディープラーニング(深層学習)」については日本企業の方が割合が高くなりました。

図表42-52

「DX白書2021」から引用(282頁)

職種に限らずAI人材が不足している

AI人材の充足度について尋ねた結果、日本企業の最大の課題である人材不足はどの職種にも当てはまることがわかりました。

「自社には必要ない」の回答が多かった「AI研究者」(47.0%)「AI開発者」(40.7%)の2つの職種は、AIの開発・導入場合のソーシング手段について尋ねた図表42-56のAIの「内製による自社開発」の日米差が大きいことと関連すると想定されています。

図表42-55

「DX白書2021」から引用(285頁)

図表42-56

「DX白書2021」から引用(286頁)

製造業、情報通信業で活用が盛んなIoT

IoTの活用状況について、業種別に日米企業に尋ねた結果が図表42-58です。日本企業は、データ収集・分析を実施するためのIT環境の整備の遅れから推定できるように、「全社的に活用している」「事業部で活用している」割合が米国と比較して低いことがわかりました。

「活用している」(青+オレンジ)と回答した割合が30%を超えた日本企業の業種は、「製造業」と「情報通信業」でした。

図表42-58

「DX白書2021」から引用(288頁)

米国の顧客価値志向はIoTの導入目的にもあらわれている

IoTの導入目的について尋ねた結果、「従業員の生産性向上」「業務プロセスの最適化」は日米ともに1、2位になりました。

しかし、「顧客の価値向上やロイヤリティ向上」「サプライチェーンの最適化」については、米国33.6%と27.1%、日本19.0%と14.1%となり、約2倍の差がありました。

図表42-59

「DX白書2021」から引用(289頁)

まとめ

AIやクラウド、IoTなどどこかで聞いたことのある用語も、その内容は常に変化し続けています。DX白書の中で、日本企業はデジタル技術の開発を、外注から内製へシフトする可能性が高いと指摘されており、そうなるとこれからは内製での開発が進んでいる米国企業を見習う形になります。

普段の業務で使用している技術を従業員が理解していることはビジネスを円滑にし、セキュリティ対策にもなります。使用する技術の検討のみがトレンドの技術を学ぶ目的ではありません。

従業員の技術リテラシーを向上させるためにも、誰がどの技術をよく理解し、それをどう伝えるのか考えることも、DXの必要な日本企業に求められていることの一つではないでしょうか。

DX白書2021では、他に「戦略」と「人材」に焦点を当てた第2部と第3部があります。そちらの内容も合わせて、デジタル技術を活用する戦略を策定しましょう。

サイバーウェーブは御社のDXを支援します

サイバーウェーブは、発注した段階でシステムの7割が完成している高品質・短納期・柔軟なシステム「VALUE KIT」をベースに、お客様のデジタルトランスフォーメーション(DX)を支援しています。どうぞお気軽にお問い合わせください。

おすすめ記事