【16,000字超】DX組織の成長を阻む壁〜進まないDX…打開するには？〜
はじめに
株式会社cross-Xの古嶋です。
DX戦略立案・推進やデータ・AI活用の支援をしています。
前回のブログで、組織立ち上げ期のDX組織が直面する課題について、その内容と対応策を解説しました。
今回は、立ち上げ後1年ほど経過したDX組織が直面する課題と対応策について解説します。
以下、本ブログで取り扱う想定ケースを示します。今回はCase2についての解説です。
DX組織を立ち上げたばかりの状況。これからDXの実現に向けて各種取り組みを推進していきたいと考えているが、やるべきことが多く、まずはタスクの洗い出しと優先順位付けを行っている。
弊社cross-Xへの相談事項は、「DX人材の要件定義」について。実際の実務で活躍するDX人材を育成するために必要な観点を網羅的に整理し、計画的な育成計画を敷きたい。
目下作成を急いでいるのは、DX人材の育成推進のロードマップ。半年後には自律的なDX人材が各事業部に輩出されているようにしたいという経営側の要望を実現する必要がある。
Case2：組織立ち上げから１年程度経過したDX組織（今回）
DX組織を立ち上げて1年程度が経過した状況。DX組織は経営直下で配置されており、各事業部を支援する形での活動を期待されている。少しずつ整備され、本格的に各事業部への支援に踏み込んでいきたい。
弊社cross-Xへの相談事項は、事業部への支援の入り込み方について。1年程度が経過したが、各事業部への支援が思うように進まず、成果創出に苦慮している。DX組織が事業部支援で成功を収めている事例や典型的なパターンが知りたい。
目下急いでいるのは、社内での成功事例の創出。自社独自の成功パターンを生み出し、それを各事業部に横展開していきたい。
Case3：組織立ち上げから2〜3年程度経過したDX組織
DX組織を立ち上げて2〜3年が経過した状況。DX組織が主体となって各種施策を推進中で、各種施策の成果が表れてきているところ。
弊社cross-Xへの相談事項は、各種DX施策の状況整理と立て直し。各種DX施策について未だに目に見える成果が出ず、所々炎上している案件も出てきていて、早期の成果創出に向けて経営からプレッシャーがかかっている
目下急いでいるのは、特にシステム開発で難航することが多く、期待していたような成果を出せていない部分について、再発を防止するための仕組み化をしていきたい。
これからDX組織を立ち上げる、もしくは今まさにDX組織の活動を進めている方々にとって、リスクの事前回避や推進上のヒントなど、何かしら役に立てれば幸いです。
DX組織を立ち上げて1年程度が経つと発生する課題のパターン
私の経験上、DX組織の立ち上げから1年ほど経過すると、いずれの組織も経験することになる、典型的な課題のパターンが存在するように見受けられます。本稿では、立ち上げから1年ほど経過したDX組織が直面しがちな以下の5つの課題について、私独自の視点から解説していきます。
データ：
各種施策で利活用したいデータが思うように収集できず、プロジェクトが進まない。
データ取得のための協力を関係各所に依頼しても、遅々として進まない。
データが手元にあっても活用するための処理が難しく、分析が出来ない。
プロジェクトマネジメント：
プロジェクト開始後、当初想定よりスコープが膨らむことが判明してリソース不足となり、実務を進めることが難しくなる。もしくは、スケジュールを再設計する必要に迫られる。
プロジェクトに関わる関係各所で別件対応が発生し、必要なリソース管理が実務上困難となる。
システム調査やデータ取得など、特にIT面で各タスク完了までの想定所要時間が膨らみ、後続するタスクに着手出来ない。
目的：
計画当初から「DXのために何をすべきか」というスタンスで施策が企画されており、そもそも目的と手段が入れ替わっている。
各種施策で達成すべき成果が不明瞭。そのため、担当者のミッションが実質的に存在せず、コミットメントやモチベーションが生まれづらい。
施策を担当者に伝える際、起案当初には存在していたはずの目的がどこかのタイミングで抜け落ちてしまい、「やること」だけが現場に伝わってしまう。結果、戦略と実務が事実上分断してしまう。
ドメイン知識：
特にITシステム開発を社外のベンダーに発注した際、IT関連の知識・経験が少ないためシステム開発全体が丸投げ状態となり、システム品質管理を社内メンバーが十分に対応出来ていない。結果、実務で使えるどころか「使いづらくて負担・ストレスとなる」システムが実務に実装される。
システムを使う事業側と、システムを開発する開発側の双方の考え方や仕事の進め方を調整するための“翻訳・橋渡し“が至るところで必要となる。
技術調査や先行事例のリサーチが不十分で、“車輪の再発明”が起こりがちとなる。また、リサーチ不十分なことが起因してAIやシステム開発に必要となるナレッジが不十分となりがち。結果として、開発テーマの難易度が想定当初で見極められず、例えば技術的限界を無視したAIモデルやシステム開発を決行してしまう。
PDCA：
施策の計画時点で「この施策をどのように見直し・効果改善していくか」という観点が抜け落ちている。
PDCAの基準となる指標が不明瞭で、施策遂行において活動を集中させるべき焦点が定まらない。
データ起点で効果を高めていくPDCAを推進した経験が無く、設定すべきKPIの粒度や人員配置、ミッション設定、タスクの粒度などが手探りの状況。
以下、一つずつ見ていきましょう。
1. DXではデータ活用が大前提！ですが…
まずは「データ」について、課題を再掲します。
データ：
各種施策で利活用したいデータが思うように収集できず、プロジェクトが進まない。
データ取得のための協力を関係各所に依頼しても、遅々として進まない。
データが手元にあっても活用するための処理が難しく、分析が出来ない。
弊社Blogの【戦略と技術を繋ぎ、DXを成功に導く「7つのポイント」】でも解説しているように、DXではデータ活用を起点としてあらゆる活動でサイクルを描き、各種施策の効果を継続的に改善・強化していきます。
コンセプト：戦略のコンセプトを企画する
①実現したいビジョンを描く。その中で、DXが果たす役割を言語化する
②ビジョン具現化によって実現される顧客体験（UX）を明確化する
③顧客体験（UX）において、顧客に提供される価値（バリュー）を明確化する
メカニズム：戦略を実現する仕組みを企画する
④UXの実現度合いを図るKPIを設計する
⑤KPI算出やITシステム、AI活用に必須となるデータを収集する
⑥データ活用サイクルを通じて成長し続けるAIを実装する
⑦ITシステムやAIを活用するなど、開発/施策の創出・実行を通じて価値を実現する
図中に示している①〜⑦の考察ポイントは、DX戦略・施策において欠かすことの出来ないものです。その中でも実務推進上で中核となるのは「データ」です。ITシステムの開発、AIモデルの開発、データ分析など、DXで実現したい各種施策のエンジンとなるのは、データです。データが集まらないことには、話が進みません。
例えば、ITシステムの開発では、基本設計を企画する段階で「UI・機能・データ」の3つを定めます。そもそもITシステムとは、データベースに格納されているデータをあらかじめ定めた機能に従って出力し、UIを通じて要件を果たすものです。つまり、データが無ければ何もできません。
また、AIモデルの開発では、収集したデータを前処理・特徴量エンジニアリングを繰り返して有効な特徴量を作り出し、それを用いてAIモデルを訓練して精度を高めるというプロセスをたどります。その際、データは質も量も高ければ高いほど高精度のAI開発が期待できます。
さらに、データ分析では、誰でもデータテーブルにアクセス可能で、各種データの定義がデータカタログなどで整理されていて、データとして欠損値が少なく、粒度が細かく、大量に収集できていて…といった「データの整備・前処理」がどの程度行われているかが、実務上の生産性を大きく左右します。
しかし、このデータの質と量が、DX推進上のボトルネックとなっている様子を私は幾度となく見てきました。例えば以下のような課題は、DXのスタートを切る際に“出鼻を挫かれる”典型的かつ頻出事項のように見受けられます。
そもそも必要なデータが見つからない
属人的にデータが記入されていて、命名規則も単位も集計ロジックもバラバラで使いものにならない
どのファイルに格納されているデータが最新か分からない
外部ベンダーがデータベースを管理しているため、必要なデータを要求してから入手できるまで毎回最低でも1週間は必要となる
データを見ても、データの定義や単位など、そのデータが何を意味しているのかが理解できず、限られた人間にしか読み解けない
顧客IDがサービスや部署ごとにバラバラで、各種データの紐付け（名寄せ）が出来ない
関係各所にデータ入力などの協力依頼をしても、依頼通りに対応してくれない
顧客データやマーケティング関連のデータを「新たに入手」するには各種施策の実施によるデータ獲得や、データ収集プロセスを新たに企画・実施する必要があり、予算的にも技術的にも敷居が高くなる
社内システムがオンプレミスであるため、現代的な技術やツールが採用できず、データ連携やデータ活用で大きな支障となっている
このような課題に直面し、DXが進まない状況は至るところで起きています。この状況を打破するために、各社ではID統合やクラウドサービスの導入、システムのモダナイゼーションなどデータ整備に奔走しており、最近はそういった取り組みに関する事例やニュースをよく見かけます。
例えば、保険業界ではZurichがエンタープライズ IT インフラストラクチャを AWS 上に移行することを発表したり、ソニー生命がソニー生命が営業支援システムを刷新、Azure×マイクロサービスでモダナイズするなど、業界全体としてモダナイズが加速している様子が伺えます。
余談ですが、保険業界ではトレンドとして埋込み型保険（エンベデッド・インシュアランス）による保険サービスの拡大を狙う戦略が多くの企業で採用されています。しかし、そのためには他のシステムから保険サービスを呼び出し、手続き等がシステム上で完結可能にする“保険API”の実現のために、システムのモダナイズが急務だという事情があります。ここに出遅れることは、例えば保険APIが実現する「オンデマンド型保険」の領域で競合他社に大きく出遅れることを意味します。今後も開発競争が激化することが想定されます。
保険業界に限らず、不動産領域では不動産の売却価格をAIが瞬時に査定するAI査定サービス、小売領域ではECとリアル店舗の購買履歴を統合・活用するOMO(Online merge with Offline)アプローチなど、各業界においてデータ活用施策が進んでいます。特にOMOのアプローチでは、各携帯キャリアがポイントプログラムを活用してECとリアル店舗の双方での購買促進を促す取り組みが加速しています。例えば楽天では西友と「楽天ポイント」を軸とするOMO戦略の新協業体制を本格展開し、ソフトバンクグループではPayPayポイントを共通ポイント化し、決済・ポイントを軸としたOMOを展開しています。現在、OMOの領域はポイントプログラムと決済手段を巡って熾烈な競争が繰り広げられています。
話を「DX組織」に戻します。言うまでもなく、これらの施策には必ずデータ整備が伴いますが、組織を立ち上げて1年ほど経過すると、さまざまな場面で「当初“出来る”と想定していたことが出来なかった」という現実に遭遇します。その1つが、データの取得と活用です。
そもそも、データ活用を想定してこなかった企業で、蓄積されたデータがアクセス・分析しづらい・できない状態になっているのは「当たり前」です。この点に悩んだり、組織に不満を持つといったスタンスは不要であり、ひたすら克服に向けて前進あるのみです。
しかし、いざ取り組みを始めると、各種データにアクセス出来るように、社内に散在するデータを調査し、特定の場所に集めて保管し、社内メンバーがアクセス可能にするだけでも膨大な労力を要します。
この点、データ整備のスコープを広げすぎて苦労している様子をしばしば見かけます。例えば、データ整備の立ち上げ時点で、実際には使うか分からないデータまでプロジェクトのスコープに入っていて、業務を膨らませているような状況です。
データ整備は、ただでさえ地道かつ苦しい取り組みです。この点、とにかくやり続けるといった号令・命令のもとで仕事が“苦行”のようになっている状態では、関わる方々のモチベーションは著しく損なわれるのではないでしょうか。
DXの実務で見落としがちですが、大切なのは「できるだけ早く成果を“実感”出来ること」です。成功実感の無い、先の見えない取り組みに粛々と立ち向かえる人は非常に稀であり、そのような社員など居ない、と想定しておいたほうが良いです。ですので、まずはスコープを小さくしつつ、成果を実感出来る目的を定めてデータを集め、分析してみることから始めるのが得策です。
典型的なテーマは、営業活動のレポーティング業務でしょう。例えば、高コストのセールス支援システムを導入しなくても、ExcelやSpreadsheet上でデータを集めて分析出来るなら、アクセス権限設定も容易で、誰でも閲覧・編集可能です。グラフ作成によってデータの可視化も可能です。
つまり、最初からデータ基盤構築のための調査業務やシステム開発、新規ツール導入などの大掛かりな取り組みをせずとも、既存のツールにデータを集め、手元で分析するような取り組みから始めることは誰でも可能だ、ということです。これは、私がデータ活用関連のアドバイザリーをする際に常に推奨している手法で、成功確度が高いアプローチです。
このような進め方は遠回りで、全社的に実現したいDXとはかなりギャップがあるように見受けられます。特に、DXで際立った成果を目指している企業や担当者にとっては、あまり“ウケ”が良くないでしょう。しかしこういったテーマで始めたほうが、成功確度が高く、DXの活動そのものが定着しやすいです。なぜでしょうか？理由は3つあります。
1つ目。そもそもデータ分析系のプロジェクトは、有効な示唆を得られるかどうかは「やってみないと分からない」ものです。さまざまな角度からデータをひたすら分析しても、目的に沿った示唆を抽出できるかどうかは、もちろんデータ分析への経験値も重要ですが、結局は分析するまで分かりません。最初から大きな投資を行って、結果的に投資回収に見合うものには遠く及ばない示唆しか得られなかった取り組みは、至る所に転がっているのではないでしょうか。
であれば、重要なのは、とにかくクイックに分析してみて、示唆が出るかどうかを確認するというサイクルを素早く回すことでしょう。この機動的なスタイルを採用できるかどうかが、データ関連の施策推進では極めて重要な分岐点です。
2つ目。データ分析系の取り組みでは、そもそも失敗はほとんど起きません。ただしこれは“条件付き”で、「成功するまで分析を続けるならば」、失敗はほとんど起きない、ということです。
「それならば、何だってそうだろう？」という意見が聞こえてきそうですが、
「であれば、成功するまで実務をやり続けたことはありますか？」と私は問い返したことがあります。
この点、確かに実務では「成功するまでやり切るなど、到底できない」という例は、実際にたくさんあると思います。しかし、データ分析に関してはその範疇ではないというのが私の考えです。
データは日々どこかで生まれ、集めるほど増えていきます。そうすれば、分析出来るデータも増え続け、さまざまな分析パターンを試すことができ、結果として、分析を継続すれば必ずどこかで良い示唆が得られます。
データ分析を続ければ、分析担当者の中でデータへの“土地勘”のようなものが生まれ、仮説が磨かれていきます。すると、分析によって得られる示唆も、より事業活動において意味のあるものに洗練されていくはずです。ただし、そのデータ分析が機械的な処理ではなく、事業理解したうえで、課題発見や解決を志向したものである、という前提は、もちろんあります。
この点、データ分析によって得られる成果目標を過大に設定しすぎると、途端に実現難易度が高まり、折角の取り組みも容易く頓挫させてしまいます。「とにかく何でも良いから使える分析結果を出せ」と、言い方・言い回しの違いはあれど主張する人に何度かプロジェクトで出くわしたこともありますが、これはもう、どうしようもありません。
3つ目。データ分析によるDXでの最大の難関は、組織に浸透・定着させることです。例えば、データ分析業務を通じて行われることは、定常的な分析業務に加え、分析結果のレポーティングや、分析結果を踏まえた現状の活動改善、さらには改善結果の定量的計測などです。
つまり、データ起点で実務のPDCAを回すということです。これは、これまで取り組んだことのない組織にとっては異質の活動であり、異質であるがゆえに、さまざまな理由で形骸化していきます。
例えば、そもそもレポート内容が関係各所で読まれていない、分析結果を見ても改善施策を考察する時間的余力がない、そもそも分析結果が見慣れない仕様で読み方が分からない、などなど、データ分析を行ったとしても、それを活かすためには後工程でさまざまな障壁が立ちはだかります。
その障壁を取り除くために、データ分析チームは関係各所と分析テーマのすり合わせや、分析対象となるデータの変更、可視化の際に用いているグラフの改廃など、実務側にとって役に立つ分析となるよう継続的にPDCAを行います。
一方、分析結果を活用してもらいたい事業部側は、実務対応に追われて多忙であり、分析結果を活かしたくても十分な時間を割けないのが通常です。しかし、そこに対してしつこくレポーティングし、分析結果の価値が届くまでやり続けることが、DX組織にとっては大事なスタンスです。
価値が届き、分析結果を読み解くリテラシーが事業部側で高まれば、今度は事業部側からデータ分析の追加依頼が来ます。すると、今度はDX組織・データ分析チームのリソースが逼迫してきます。これまでExcelなどの簡易的な表計算ツールで対応していた分析業務が、関係各所からの分析依頼に追われて対応しきれなくなってくるのです。
そして、この状況になって初めて、データ分析プロセスを自動化するための投資を開始します。データの処理プロセスを自動化する簡易的なデータパイプライン設計や、これまでの業務で「必要不可欠だと判断されたデータ」を格納したデータベースの構築、さらにデータベースと接続して分析結果を出力する可視化ツールの導入などを進めます。これまでの実務を経たからこそ、これらの投資は自信を持って「絶対に必要であり、投資対効果が高い」と言い切れるものになっているはずです。
さて、まだ1つめの課題に関する考察ですが、ここまで大幅に紙面を割きました。上記のように、データ分析を起点として、DX組織が直面する課題解決に順次取り組めば、自ずとDX組織として成熟していくのではないか、というのが私の経験上得られた有効なアプローチです。もちろん、直面する課題は組織ごとにさまざまですが、これらの壁を克服した先には、以前よりも遥かに足腰の強いDX組織へと成長していることは間違いないでしょう。参考として頂ければ幸いです。
2. DXのプロジェクトマネジメントは、なぜ難しいのか？
続いて「プロジェクトマネジメント」について、課題を再掲します。
プロジェクトマネジメント：
プロジェクト開始後、当初想定よりスコープが膨らむことが判明してリソース不足となり、実務を進めることが難しくなる。もしくは、スケジュールを再設計する必要に迫られる。
プロジェクトに関わる関係各所で別件対応が発生し、必要なリソース管理が実務上困難となる。
システム調査やデータ取得など、特にIT面で各タスク完了までの想定所要時間が膨らみ、後続するタスクに着手出来ない。
DX関連のプロジェクトを始めると、上記のような
「必要かつ想定外のタスクが判明してスコープが拡大」
「他の業務が重なってDXプロジェクトへのコミットが困難」
「技術面でのタスク推進で想定以上の所要時間が発生」
といったことはほぼ間違いなく起こります。この点、こういったミスを無くしていく取り組みは確かに大事なのですが、それ以上に重要なのは組織的な「学習」と「改善」です。
最近、「失敗しないDX」といった謳い文句を見かけますが、そんなことは不可能です。DXでは、失敗することが「当たり前」です。このマインドセットがそもそもの大前提であり、その前提で、以降の解説を進めます。
まずは学習についてですが、学習には「静的」な学習と「動的」な学習があります。
静的な学習とは、座学や研修、過去の事例参照や専門家へのヒアリングなど、テーマによって求められる必要最低限の知識をプロジェクトの“外”で獲得することです。システム開発に関わるなら、要求定義や要件定義、システム設計に関する知識は必須でしょうし、AIシステムに関わるならデータ前処理・特徴量エンジニアリングの意義と手法や機械学習システムの設計パターンごとの特徴、昨今のAIモデルのトレンドやモデルごとの特徴などの理解が実務では求められます。
この点、DXの領域では技術の進歩が速く、実務に打ち込みながら各分野のトレンドに追随し続けることは大変な労力を伴います。しかし、残念ながらここに効率的なアプローチは存在せず、絶えず学び続けるしかありません。
この点、「これさえ理解すれば良い」といった謳い文句でDXスキルのトレーニングを提供しているサービスが昨今は有象無象で存在しますが、はっきり言って、全部嘘です。DXの領域では、「これさえ知っていれば良い」「これさえ出来れば大丈夫」といったものは、存在しません。
ただ、幸いなことに昨今はWebページやブログ、書籍などでかなり詳しく各種テーマを取り扱っている情報ソースがあります。特に書籍は、最近は網羅的かつ詳しく各テーマを解説している書籍が各ジャンルで少なくとも2〜3冊はある印象です。私の経験上、これらをしっかり読み込めば、十分な知識・リテラシーを獲得出来ます。
昨今はリスキリングというキーワードが頻繁に紙面を賑わせていますが、そもそも「学び続ける力」こそが、最初に獲得すべき欠かせないスキルです。DXは、「分かる」ことによって見える景色がパッと「変わる」瞬間を何度も体験できる領域だと思います。この「変わる」を体験することは、学びの醍醐味です。（そもそも、DXが意味するTransformationが「変わること」を指しているのだから、DXの推進主体が「学ぶ」ことで「変わる」ことをしなければ、概念矛盾してしまっているのでは？とさえ思います。）
続いて、動的な学習です。これはつまり、実践から得られる学びで、「やってみたから気づいた、得られた学び」を指します。
「愚者は経験に学び、賢者は歴史に学ぶ」と言います。これはドイツの宰相オットー・フォン・ビスマルク（1815年〜1898年）の格言です。この言葉には、「やってみてから気づくような行動・行為は愚かなことだ」という意味が暗に含まれているように思います。
さて、この格言、本当に真に受けて良いのでしょうか？
私は元メジャーリーガーのイチロー氏の大ファンなのですが、彼の引退会見の言葉の中で、折に触れて読み返す一節があります。
会見を聞きながらメモを取ったので若干発言と異なる部分もあるかもしれませんが、大凡、このような内容でした。
「本を読んだり情報をとっても、『体験』しないと自分からは生まれない。その体験は未来の自分にとって大きな支えになる。だから、辛いこと、しんどいことから逃げず、エネルギーのある元気なときにそれに立ち向かっていくことは、人として、重要なことだと思います。」
何度読み返しても、言葉の力に圧倒されます。
これを長い会見の最後に、よどみなく言い切るところに、イチロー氏の人間としての大きさや深さが色濃く表れていると思います。
さて、「賢者は歴史に学ぶ」と言いますが、恐らくその「賢者」自身も、相当な「経験」を積んだ上で、歴史に学んでいるのだと思います。そもそも、この世界は経験してみなければ分からないことばかりです。新しい挑戦ばかりのDXでは、尚更でしょう。
とはいえ、経験重視で無鉄砲に実務を推進していたら、いくら予算と時間があっても足りません。ここで大事になるのが「改善」です。
システム開発の領域では、アジャイル開発が既に国内各社の開発組織でかなり浸透してきていると思います。
アジャイル開発では、「スクラム」と呼ばれるチームが編成され、少人数のチームで1日毎、長くても2週間程度で個別開発テーマを「スプリント」と呼ばれる形式で開発を実践します。この期間設定に正解は無く、各組織や取り組むテーマによってスクラムマスターが判断するところでしょう。
このプロセスでは、開発しながら早期に問題点を発見し、対応策を協議し、改善施策を実施し、目的（＝要件）を満たすプロダクト開発を推進します。これは見方を変えれば、計画上や企画段階では予見していなかった問題が発生することを前提とし、早期に問題点を潰しながらプロダクトを磨き上げていくという、PDCAサイクルです。
ここで特に重要なのは、実際に開発を進めたからこそ得られた「発見」から、組織的な活動を「改善」することです。この改善活動を通じて、DX組織としての成熟度が高まります。
この「実践を通じた改善」は、組織の競争優位性に直結します。先程のイチロー氏の話を借りて説明すると、「ヒアリングや事例からインプットして、頭で分かっている状態」と、「実際に身をもって経験したからこそ、その状況や対応策を解像度高く思い描ける状態」の間には、雲泥の差があります。
ここまでの内容をまとめます。
DXのプロジェクトマネジメントにおいて、想定外や失敗は「当たり前」です。しかし、自主的な学びが不足していたために起きた失敗は、十分に反省すべきであり、学び続ける努力が必須でしょう。一方、学ぶばかりで「改善」が伴わなければ、成熟したDX組織に変わることはできません。学習と改善を質的・量的観点でどこまで高められるかが、競争優位性に直結するでしょう。
3. なぜDXでは、手段と目的が逆転するのか？
続いて「目的」について、課題を再掲します。
目的：
計画当初から「DXのために何をすべきか」というスタンスで施策が企画されており、そもそも目的と手段が入れ替わっている。
各種施策で達成すべき成果が不明瞭。そのため、担当者のミッションが実質的に存在せず、コミットメントやモチベーションが生まれづらい。
施策を担当者に伝える際、起案当初には存在していたはずの目的がどこかのタイミングで抜け落ちてしまい、「やること」だけが現場に伝わってしまう。結果、戦略と実務が事実上分断してしまう。
組織の規模が大きくなるほど、実務担当者が目的不鮮明な取り組みを背負わされている状況をよく見かけます。このあたりは、経営・事業運営の手腕の巧拙がはっきりと伺い知れるところです。
そもそも、1点目で挙げているような「DXで達成したいビジョンや目的が不在の状況」は、例示するまでもなく実務運営上で数多くの不整合を伴います。組織のモチベーションも、経営や上層部への信頼も、極めて低い状態になっていると思われます。この点については「ビジョンや目的をはっきりさせるしかない」としか、言いようがありません。
問題となるのは、ビジョンや目的は示しているはずなのに、実務に浸透しない状況です。この点、私がよく見かける典型的な状況は、「目的を“指標”に変換出来ていないこと」です。
実務においては、事業目標（KGI: Key Goal Indicator）を達成するためにKPIを設定し、各KPIについてミッションを持つ担当者を任命し、施策実施を通じてKPI達成に向けて活動を推進します。この点、DXの実務では従来型のKPI運用に加えて、より細かなメッシュでのデータ活用が可能となるため、データ集計・分析がより細かくなり、それに合わせる形でPDCAサイクルの頻度が高まり、PDCAの観点も増えることが通常です。
つまり、データを活かすために必要なスキルが高度化する、ということです。
この点、特に難しいのはKGIを分解してKPIに落とし込む中で、実務担当者が担うべきKPIの粒度をいかにして定めるか、という点です。
そもそも集計分析が不可能なKPIを設定してしまうと、担当者のKPI達成度合いを評価できません。また、KPIの粒度が大きすぎると、担当者にとっては重責となり、過剰なミッションとなってしまって大きな負担となってしまいます。逆に、KPIの粒度が細かすぎると、実務が単調過ぎてモチベーションが生まれづらいといった弊害も起こり得ます。
経営層や事業責任者は、DXのビジョンや目的をしっかりと理解しつつ、それが現場実務を推進することで達成出来るよう、KPIの設計からミッション設定、施策設計に至るまでしっかりと目を光らせ、整合性を担保することが常に求められます。この点、非常によく見かけるのは、ビジョンや目的だけ設定して、あとは現場に丸投げの状態です。このような進め方で、うまくいくはずがありません。実際、うまくいっていない様子を何度も見てきました。
このKPIツリーの設計から担当者のミッション設定、適切な施策・技術選定、実行計画策定、PDCA推進に至るまでの実務を円滑に進めるには、非常に高度なリテラシーを必要とします。この点、詳細は拙著『DXの実務』（英治出版、2022年）に解説していますので、よろしければ御覧ください。
話を戻します。
DXのビジョン・目的が浸透しない要因として私がよく見かけるのは、上記のように、実務への落とし込みの段階で、目的と実務の間に分断が起きているような状態です。
DXの実務では、「戦略と実務」、「実務と技術」、「事業と組織」といった、複眼的な考察と改善を幾度となく繰り返すことになります。これらの考察と改善は、どこかが欠ければ必ず不整合が生じます。多くのDX組織で疲弊とも言える様子を目の当たりにしてきましたが、その主な理由は、DX担当者が上記のような状況への対応に追われ続けているからです。
この機動的なPDCAを志向したいためか、昨今はアジャイルな実務・開発推進の重要性が取り上げられることが多くなってきたように見受けられます。しかし、これもアジャイルな推進そのものが目的化してしまうと、本末転倒です。アジャイルな推進方法を採用したとしても、本来達成すべき目的と、アジャイルな実務・開発推進で達成したい成果の間には、常に整合性が担保されていなければなりません。その整合性を担保するのは、言うまでもなく経営・事業責任者の役割です。
4. DXで必要な知識とは？
4つ目の「ドメイン知識」について、課題を再掲します。
ドメイン知識：
特にITシステム開発を社外のベンダーに発注した際、IT関連の知識・経験が少ないためシステム開発全体が丸投げ状態となり、システム品質管理を社内メンバーが十分に対応出来ていない。結果、実務で使えるどころか「使いづらくて負担・ストレスとなる」システムが実務に実装される。
システムを使う事業側と、システムを開発する開発側の双方の考え方や仕事の進め方を調整するための“翻訳・橋渡し“が至るところで必要となる。
技術調査や先行事例のリサーチが不十分で、“車輪の再発明”が起こりがちとなる。また、リサーチ不十分なことが起因してAIやシステム開発に必要となるナレッジが不十分となりがち。結果として、開発テーマの難易度が想定当初で見極められず、例えば技術的限界を無視したAIモデルやシステム開発を決行してしまう。
先述した「プロジェクトマネジメント」の節で、学習の重要性について私見を述べました。ここでは、DXで必要な「知識」について、より具体的に書いていきます。
実務で求められる知識は、大別して「自社業務固有・特有の知識」と「業界・テーマ全体で汎用的かつ共通して求められる知識」の2種類があると思います。
例えば、とある製品を販売している企業で、「マーケティングから営業に至るプロセスをデジタル化・自動化したい」というテーマがDX施策として挙がったとします。
そもそもこの取り組もを進める前に、達成すべき「目的」を定めることは言うまでもないですが、目的設定に次いで着手すべきは「業務理解」です。
業務理解を行う上で重要なのは、対象となる業務フローを精緻に可視化することです。どのような担当者が、どのようなタスクを、どのように連携しながら推進しているのかが細かく把握できなければ、施策の打ちようがありません。可視化を行うことでチーム全体で“指差し確認”しながら議論を進めることは、DXのように関係者が多くなりがちな取り組みでは必須です。
「マーケティングから営業に至るプロセスをデジタル化・自動化したい」というテーマで業務理解をする際、ヒアリングや業務分析を通じて整理した情報のアウトプットとして、例えば下図のような可視化を行うことになるでしょう。これはまさに、「自社業務固有・特有の知識」と言えます。
議論しながらこのような業務フローを描いていると、不鮮明・不透明な箇所が浮かび上がります。そこがまさに「欠けている知識」であり、実態把握を進めるべきポイントです。コンサルティングプロジェクトでは、このような資料を数十枚、場合によっては100枚を超えるレベルで作成しますが、その理由は極めてシンプルで、「業務が分からなければ課題が見つからず、結果として有効な解決策を案出できないから」です。
この点、可視化した業務フローを活用したDX施策の一つとして「ITシステムの導入による活動の効率化」を目指す際は、少なくとも以下の3つのプロセスをたどります。
現状の業務内容を精緻に理解し、属人化してしまっているポイントをあぶり出す
属人化した業務をいかにして標準化するかを熟議し、得られた示唆をITシステム等の開発において要求定義・要件定義等に最大限活用する
経営層、特に事業責任者が現場にコミットし、システム導入等による実務変化に組織全体が対応できるよう最後まで伴走する
この点、詳細はダイヤモンド・オンラインで連載している〈戦略と技術を結びつける「DXの実務」〉の第5回で解説している【DXの難易度を左右する3つの要素】を御覧ください。
上記のような活動を進めながら、自社特有の求められる知識に習熟していきます。そもそも、知らない問題・課題は、解決できません。
一方、「業界・テーマ全体で汎用的かつ共通して求められる知識」については、「プロジェクトマネジメント」の節で述べたとおり、継続的な学習が必要となります。ここでは、基本的な技術理解のきっかけとして参考となる書籍を以下に列挙します。この4冊をしっかりと理解すれば、かなり汎用的な知見が身につくはずですので、参考として頂ければ幸いです。いずれもITに関わる方なら、必ず知っていると言っても過言ではないほど有名な書籍です。
ここでは私見をもとに推薦書籍を提示しましたが、こういった専門領域の書籍に最初に手を出す際に重要なのは、とにかく分かりやすい解説をしてくれている書籍を読むことに尽きます。
敷居の高い専門書は、数式やシステム構成図、抽象的な表現やテクニカルタームなど、背景・前提となる知識を質的にも量的にも高いレベルで読者に求めます。そういった内容を読破できるようになることは、この領域を専門として身を置いている場合は重要ですが、実務と並行して習得することは茨の道だと思います。
私自身、過去に専門書に手を出し、内容をほとんど理解できず時間を浪費した挙げ句、関連分野について初学者向けにわかりやすく解説している書籍を見つけて読み、霧が晴れたような気持ちになった体験を何度もしています。もちろん、難解な専門書を読んだ時間が無駄だったとは思いませんが、今思い返すと、もう少し効率良く学習を進められたのではないかと思います。
幸い、現在はDXの各分野で、専門的かつ重要なテーマを初学者でも分かりやすく解説している書籍が充実しています。この点、書籍と読者には相性があるので、自分の求めている知識と、自分のレベルに合った解説の仕方をしている本を探すことは、実は重要な作業です。私としては、書店に足を運んで実際に書籍を読み比べ、納得のいく本を購入し、腰を据えて読み進めるという学習スタイルを強く推奨します。
5. DXにおけるPDCAとは？
課題を再掲します。いよいよ最後の論点です。
PDCA：
施策の計画時点で「この施策をどのように見直し・効果改善していくか」という観点が抜け落ちている。
PDCAの基準となる指標が不明瞭で、施策遂行において活動を集中させるべき焦点が定まらない。
データ起点で効果を高めていくPDCAを推進した経験が無く、設定すべきKPIの粒度や人員配置、ミッション設定、タスクの粒度などが手探りの状況。
さて、ここまで読み進めて頂ければ、これらの課題を解決するための「答え」は、自ずと想起されるのではないでしょうか？
上記の３つの課題について、一つずつ簡単に見ていきましょう。
施策の企画時点でPDCAの観点が抜け落ちているのは、目的やビジョンの欠如、戦略と実務の分断、目的と実務の整合性を担保する活動の欠如、といった要因が挙げられるでしょう。
PDCAの指標が不明瞭という点については、KPIに関する解説で指摘した通りです。
データ起点でのPDCAの経験の有無については、「学習」と「改善」の考察で解説した通りです。
つまり、PDCAに関連する課題の解決指針のヒントは、本ブログの中に散りばめています。また、本ブログを読み進める中で、きっと読者の皆さまの中で思い当たる点や、本稿に書かれていなくても連想的に気付いた点があったかと思います（そうであれば、嬉しい限りです）。
PDCAとは、すなわち実務です。この点、読者の皆さまがDXに関連するチームに所属されるなら、本稿を議論のきっかけに用いて、「いかにしてDXの『実務』を成熟させていくか」を議論出来ると思います。そうすれば、地に足のついた、密度の濃い議論をしていただけるのではないかと、勝手ながらご提案したく思います。
おわりに
ここまで、DX部門の組織立ち上げから１年程度経過した状況を想定して、典型的な課題とその解決策について解説しました。
私の知る限り、DX組織の成長プロセスに、近道も正解も存在しないと思います。業界ごと、さらには各業界内での企業ごとに、経営や事業の歴史は異なりますし、組織のキャラクターも、得意不得意も千差万別でしょう。であれば、各企業・組織ごとのDX組織のあり方は、多様であって然るべきです。
DX組織の立ち上げから1年前後は、非常に苦しい時期です。首尾よく上手く進み、順調に成長しているDX組織など存在しないと思います。多くの場合、大小様々な課題を抱え、多方面からプレッシャーを受け、何とかして成果を出そうと日々奮闘されていることと思います。そのような中でブレイクスルーを生み出すための定形パターンなどは存在せず、ただ真っ直ぐに学習と改善を続け、課題を一つずつ取り除き、歩みを止めずに前進し続けるだけだと思います。
一方で、その中でも小さな成功体験を短いサイクルで確実に得ていくことは、組織のモチベーションや成長実感、ひいてはDXの実現に向けて、見落としがちですが極めて重要な“工夫”です。時間の経過とともに成果創出のプレッシャーが高まり続けるだけでは、組織は疲弊するだけです。重要なのは、小さな成功体験を生み出し、組織の熱量を高め、いつの日か大きな変革を実現するまで歩みを止めずに、一枚岩となって邁進し続けることだと思います。
ここだけ読めば「当たり前ではないか」と思われるかもしれませんが、これが途端に難しくなる典型的なテーマがDXだと、強く思います。こういったチャレンジを支援し、クライアントと一緒に成功を勝ち取っていくことが目下私のテーマだと考え、日々「学習」と「改善」を続けています。
今回も長いブログとなってしまいましたが、最後までお読み頂き、ありがとうございました。
より具体的な質問やご相談などあれば、お気軽に弊社までお問い合わせください。
この記事が気に入ったらサポートをしてみませんか？