DX組織が克服すべき「3つの課題」〜立ち上げ2〜3年後の組織が直面する典型課題とその対応策〜

はじめに

cross-Xの古嶋です。DX戦略立案・推進やデータ・AI活用の支援をしています。

前回の記事で、立ち上げ後1年ほど経過したDX組織が直面する課題について、その内容と対応策を解説しました。

今回は、立ち上げ後2〜3年ほど経過したDX組織が直面する課題と対応策について解説します。

以下、本記事で取り扱う想定ケースを示します。今回はCase3についての解説です。

Case1：組織立ち上げ期のDX組織（前々回）

• 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組織を立ち上げて2~3年程度が経つと発生する課題のパターン

私の経験上、DX組織の立ち上げから2〜3年ほど経過すると、各社でDXの成果の“明暗”がハッキリと分かれる様子が伺えます。本稿では、このフェーズのDX組織の成果創出を阻む典型的な3つの課題と対応策について、独自の視点から解説していきます。

以下、一つずつ見ていきましょう。

1. DX推進では、至る所でプロジェクトが立ち上がる

まずは課題を再掲します。

DXの機運が高まった企業では、同時多発的にプロジェクトが発足します。

経営的な観点からは、CoE(Center of Excellence)のような組織が中心となり、管理統制を敷いた計画的なDX推進と成果創出を目指したいところですが、なかなかそのようには進まないのが実情でしょう。

この点、全体統制が上手く行かずに、計画通りに推進できないことを思い悩むDX担当者の方々のご意見をお伺いすることがしばしばありますが、私の見解としては、「そこは悩むべきところではなく、“活かすべき”ところですよ」と、常々提起しています。

そもそも、現場起点でDXの取り組みが生まれることは、歓迎すべきことです。DXのアプローチで解決すべき課題は、DX組織内ではなく、現場にあります。

また、DXの領域は、ChatGPTのような革新的AIが突如として台頭するなど変化の激しい領域であり、そもそも計画的に実務を推進するというスタイルはDXとの相性が悪い、と考えるべきです。この点、従来型のロードマップ的な経営管理手法は、現代においては再考を強く迫られるべきだと私は考えます。

であれば、DX組織が成すべきことは、同時多発的に生まれる社内のDX推進に柔軟かつ機動的に対応することです。そして、DXの専門チームとして参画し、各種取り組みの成功確度を高めることこそ、DX組織のミッションの中核に据えるべきでしょう。

間違っても、至るところでDXプロジェクトが発生してしまうことによる仕事の進めづらさ、やりづらさを解消することに注力してはいけません。そのようなことをしようとすると、組織間の軋轢すら生まれかねません。そうなれば、まさに本末転倒です。

実際に参画してみると、プロジェクトの至るところで課題が存在しており、貢献できる余地は非常に多く存在します。私の経験上、「人は十分に足りている」というDXプロジェクトは、滅多にありません。DX組織として存在感を発揮できる場所は、本当にたくさんあります。

こういった議論をすると、「それは本来自分のやりたい仕事ではない」という本音がDX担当者から垣間見えることがあります。しかし、そのスタンスだと、逆に成果創出の好機を逸し続けてしまいます。

「自分のやりたい仕事をする」ということは、そのテーマにフィットした課題が“運良く”社内に存在し、それを見つけ、その解決のためのプロジェクト起案を最上流から着手して全体設計し、関係各所と合意形成し、成功に向けてリードする、ということです。これはそもそも至難の業でしょう。独立・起業などをしない限り、そのような環境は無いと考えたほうが自然です。

一方で、とにかくDX関連の取り組みに参画し、何でも請け負って泥臭くやり切る、といったスタンスだけでは、DXの専門組織としての役割は十分には果たせないでしょう。

ここでさらに求められるのは、中長期的かつ組織横断的な視点です。なぜなら、中長期的な視点で経営全体のDXを考え、取り組みを進められるのは、DX専門組織しかないからです。

例えば、個別の施策ごとにデータサーバーが構築されるような状況だと、同じデータが各サーバーに多重保存されるような無駄が発生します。また、例えば売上を集計するロジックにおいても、各種施策ごとに集計単位が異なると、施策ごとに異なる売上集計結果が出力されます。いわゆる「サイロ化」と呼ばれる現象です。

このような事態は、局所的な活動では問題にならなくても、後々事業部横断や経営全体を俯瞰した取り組みを推進する際、深刻なボトルネックとなることも珍しくありません。

こういった状況を回避するために、昨今では「データマネジメント」と呼ばれる取り組みが浸透しています。詳しくはデータマネジメント知識体系ガイド 第二版に解説されていますが、この考え方を反映させた主な施策として、「データ基盤の構築」や「データカタログの作成」があります。

データ基盤の構築の目的の一つに、「散在しているデータを一元的に管理し、データ利活用とコスト効率を同時的に高めること」があります。各種データを使うために、その都度、情報システム部門や営業部門にデータに関する問い合わせが発生したり、各種施策ごとにクラウドサーバーの契約をしたりしていると、データ利活用の阻害要因となるだけでなく、データ探索の時間的浪費やデータ格納コストの多重発生など、さまざまな面で実務の非効率的の発生源となってしまいます。

よって、顧客との取引データやウェブシステムへのアクセスログなど、各種データは一元的に管理し、速やかに活用可能な状態にしておくことが実務的かつ実践的です。昨今のトレンドとしては、データをraw dataのまま一元的に管理するデータレイク（DL）、データを活用しやすいように変換・格納したデータウェアハウス（DWH）、さらに各用途ごとに集計し直したデータマート（DM）を構築・運用するスタイルが各社で採用されています。

データ基盤構築を企画する際は、以下のような観点でまずは全体像を整理しておくことと良いでしょう。

• データの把握：
  保有済みデータ、新たに取得したいデータを一覧化。各データについて、例えば CRUD(Create:生成/ Read:参照/ Update:更新/ Delete:削除)の観点 で各部署/担当者の権限設定状況を把握
• データの利用目的：
  各データを用いて各部署 /担当者が何をしているのか、今後何がしたいのかを整理する
• 利用ツール：
  データ利活用のために各部署/担当者が用いるツールやサービスを把握する
• データ/施策の品質：
  データ品質や分析結果の精度、タイミングなど、実務で求められるレベルを明確化する
• 懸念点の事前把握：
  データ/施策の品質が守られなかった場合に発生が想定される実務的な懸念を明確化。例えば、エラー等の障害発生時の対応優先度等を予め考察し、合わせて対応策を具体化しておく

続いて、データカタログについてです。そもそも社内にどのようなデータがあるのか、全体像及び詳細を整理しなければ効果的な活用は難しいです。しかし、各種データが社内のどこに存在するのか、明確に管理出来ている企業はまだまだ少ないようです。

この点、昨今はデータカタログという手法を用いてデータを管理・活用する動きが活発になってきています。これは、データカタログ作成をミッションとする担当者が、関係各所のデータ保有状況をヒアリングし、それらを統合・活用するためのカタログを下図のように作成し、そのカタログをデータベースとした検索システム等を設置して、誰でも社内のデータについて検索・閲覧可能にする仕組みです。

ここでは例として、データ基盤構築とデータカタログについて解説しましたが、このように横断的DXに後々効いてくる施策を周到に推進しつつ、目下実務の現場で熱量高く取り組まれているDX施策に深く入り込むことが、DX組織には求められます。つまり、先回りした対応を随所に散りばめながら各種プロジェクトを推進する複眼的なプロジェクトマネジメント能力が、DX組織には不可欠です。この中長期的な役割を担える組織は、DX専門組織を置いて他にありません。

---

ここまでの内容をまとめます。

DXの機運が高まった企業内で、同時多発的にDXプロジェクトや組織が生まれることは「よくある話」であり、これを組織マネジメントの問題にしていては、埒が明かないでしょう。

そうではなく、これを「好機」と捉え、各DX施策に入り込んでともに成果を創出していくスタンスと行動が、DX組織には強く求められます。

一方で、目先のプロジェクトでの成果創出のみに傾倒していては、各活動が局所最適な成果にとどまり、全社横断的なDXの実現に届きません。

DX組織としては、データ統合に向けたシステム整備などを並行して進め、全社横断的なDXへの仕掛けを周到に進めていくことも求められるでしょう。

つまり、短期と中長期の成果創出を狙うプロジェクト・ポートフォリオを綿密に組み立てることが、DX組織の手腕として求められます。

2. なぜ、DXではシステム開発・運用のトラブルが頻発するのか？

続いて、「システム開発・運用で相次ぐトラブル」について、課題を再掲します。

拙著『DXの実務』（英治出版、2022年）やダイヤモンド・オンライン様での連載「DXの進化」など、各方面で私が主張しているところですが、そもそもDXの実務推進では、至るところで「戦略」と「技術」を接続させるための複眼的な考察と取り組みが求められます。その実現の要となるのは「組織」であり、この「戦略と技術を強固に接続させられる組織の有無」が、DXの成否を決定的に左右します。

この点をより具体的に示すと下図のような組織連携が浮かび上がります。戦略（ビジネス）と技術（開発）を接続させるには、双方の意思疎通を滞りなく実現する担当者が不可欠です。事業担当側では、各種課題に通じているメンバーを取りまとめ、課題を整理し、システム要件化に向けた議論を開発側とともにリードする役割が期待されます。一方、開発担当側では、システムを実際に開発するメンバーとの開発内容のすり合わせをしつつ、事業側のニーズを適切に汲み取り、開発計画及び品質を適切にマネジメントする役割が期待されます。

DX組織立ち上げから2〜3年が経過すると、取り組むテーマの規模は次第に大きくなっていくことが通常でしょう。すると、プロジェクト遂行に必要となるタスク数が飛躍的に増加し、それに比例して関わるメンバー数も膨らみます。

これらの活動を束ねながら実務で求められるプロダクトを開発し、実務で運用して成果を創出できるかどうかは、開発とビジネスを橋渡しする役割を担うDX担当者の手腕が鍵を握ります。

DX関連の開発プロジェクトが失敗したり、プロジェクトの最中にトラブルが頻発したり、実装後の運用で狙い通りの効果が得られなかった場合は、上図の「プロダクト開発担当」と「事業担当」のような役割を担うメンバーが不在であるケースが目立ちます。

それもそのはずで、両者には開発・ビジネスの双方の視点が常に求められ、卓越したスキルが要求され、そのようなことが可能な人材は稀有だからです。

ビジネス側の実務課題を熟知しながら開発に必要な要件を取りまとめて開発をディレクションできる開発担当や、各種技術への理解及び技術的制約条件を理解した上で課題解決を実現するシステム要件を整理・議論できる事業担当は、私自身も数えられるぐらいの方にしか出会ったことがありません。

こういった状況を反映してか、例えば社内利用向けに限定的なユーザーを想定して開発されたプロダクトでは、「毎回ログインしなければならない」「ログイン後の画面表示まで10秒かかる」「ページ遷移に1分かかる」など、BtoC のサービスでは受け入れられないような状態のプロダクトを何度も目にしてきました。そのようなプロダクトを使わなければならない側としては、たまったものではありません。

業務効率化を目指した“DX”が、逆に生産性を下げてしまっている状態は、誰一人として報われないものです。

DX は影響範囲が非常に大きいです。プロダクト開発においては、機能要件だけでなく、このような非機能要件についても、事業特性やドメイン知識に習熟したうえで緻密に設計し、プロダクトの品質担保に努めるべきです。

さらに、システム開発後の実務への実装にも数々の障壁が存在します。実務担当者からすると、システム導入による業務オペレーションの変更はかなりのストレスです。どれだけ使いやすいシステムでも、順応するには、ある程度の時間を要します。

前回記事やダイヤモンド・オンラインでの連載第5回で詳述している通り、システム開発後に組織に浸透させるには、現場任せにするのではなく、実務に浸透しきるまでシステム利用者に伴走することが不可欠です。

実際に実務にシステムを組み込むと、想定外の不整合が少なからず発覚します。それらの阻害要因を一つずつ取り除き、実務でプロダクトが活用され、導入前よりも高い成果を創出するまで伴走しなければ、投資に見合う効果が発揮されることはない、と言っても過言ではありません。

また、ここでどれくらい現場の方々に丁寧に伴走するかが、DX組織への「心象」や「評判」に大きく影響します。ここを決して軽視してはいけません。ここを中途半端に済ませてしまうと、「仕事が雑だ」「結局役に立たない」「余計な仕事を増やされた」など、直接届かずとも、関係各所のどこかで不評が蔓延します。その後のDX施策の協力を得ようとしても、信用を回復することは非常に困難です。

DXは、単独組織で実現できるものではなく、数多くの協力があってはじめて実現されるものです。また、DX組織は新設部門で、既存組織とはその歴史も経営への貢献度も大きな差があるのは明白です。DX組織の取り組みは、大胆な推進も重要である一方、関係各所への謙虚かつ丁寧な配慮は、常に欠かせません。

---

ここまでの内容をまとめます。

システム開発・実装ではさまざまな方法論やフレームワーク・ノウハウが紹介されていますが、結局のところ、システム開発・実装・運用を成功させるためには、全行程において戦略と技術を接続させ、実務に落とし込むことに徹し続けるしかありません。

決まった手順通りに進めたり、外部ベンダーに任せたりするだけでうまくいくものではなく、あらゆる障壁を取り除きながら成果を出すまでやり切ることが求められます。

一定程度の規模のシステム開発では、特に外部ベンダーを活用する際、上記のようなプロセスに立ち向かえる推進体制を構築できるかどうかが、結果的な成否を左右するでしょう。

このあたりは、既に苦い思いをした方も少なくないのではないでしょうか。そういった失敗を繰り返さないためにも、組織の内部に、戦略と技術を強固に接続し、実務に落とし込める体制とケイパビリティを構築することが急務です。

3. なぜDX施策は、効果計測が難しいのか？

3つ目の課題、「不明確な投資対効果」について再掲します。

システム開発においては、要求定義→要件定義→システム設計と、ビジネス側の要望整理から現実的なシステムへの落とし込みに向けて順次粒度を細かく企画・設計を進めていきます。

しかし、一度でもこのプロセスに関わったことがあれば想像がつくのですが、このプロセスで必要となる情報収集と情報整理には、膨大な時間と労力が必要となります。理由はシンプルで、システム開発はそれだけ精緻な情報整理が求められるからです。

例えば、開発トラブルが起きた際の責任の所在を明確にするために、事前の開発内容のすり合わせは事細かく行う必要があります。また、システム開発中・開発後に不備が見つかると、ほとんどの場合で改修には大幅な計画変更と大きなコストが追加で必要となります。

このような理由から、本来は開発着手以前に、既存のシステム環境等を入念に調査する必要があるのですが、多くの場合で「急いで進めたい」などの経営上・事業運営上の都合から、時間的な制約が介在し、調査不十分な状態で見積もりを設計することになります。

よって、情報が不透明な中で各種要件定義を行った後、実際にシステム開発に着手した際、例えばアクセス可能だと考えられていたシステムが思うように扱えないなど、不足の事態が発生して追加的に工数がかかり、計画が崩れていくことになります。

こういった事態は、社内に新規システム開発の経験が蓄積されていない状況では、ある程度仕方の無いことでしょう。また、実務の性質上、全てを周到かつ計画的に進められるものではないと考えるべきところです。重要なのは、こういった失敗例から学び、再発防止に努めることです。最初から上手くいくものではありません。

また、拙著『DXの実務』（英治出版、2022年）やダイヤモンド・オンライン様での連載「DXの進化」で繰り返し私が主張しているように、そもそも、DXにおいてあらゆる課題の発生起点は、「膨大な変革スコープ」「各種技術の理解・実装・運用・改善の遂行」「DX人材への要求水準」にあると私は考えています。DXは求められる実務レベルのハードルが高く、とりわけこのシステムの投資対効果を見極めるフェーズでは、これらのハードルが一気に襲いかかってくるような状況だと考えても差し支えないと思います。

これらのハードルを回避するためにも、DXでは最初から大きな成果を狙うシステム開発は避けるべきです。システム面でも実務面でも影響範囲の大きい新規プロダクトの開発は、至難の業です。まずは局所的な実務課題を解決するシステム開発で着実に成功を収め、順次対応範囲を拡大していくことが得策です。

例えば、以下のように変革のスコープを縦軸に企画→調達／開発→製造／物流→広告→店頭販促→CRM→といった企業活動の流れ、横軸に認知→登録→来店→購入→評価といった顧客体験で整理し、これらがクロスする“マス”単位でDXを狙うことを考えることが、私の経験上有効なアプローチです。例えば、顧客の「来店」時に「広告」をプッシュ通知するといった施策をまずはしっかりとやり切る、といった具合です。

ここで主張したいのは、いきなり上図のパターン②、③のような横断的・全方位的なDXを企画推進しようとするケースはほとんどのケースで失敗するということです。端的に言って、難易度が高すぎます。既に開発レベルが成熟している企業なら問題にならないとしても、これからDXを本格化させていこうとする企業で横断的・全方位的な施策を推進することは、避けるべきです。

また、このような大きなテーマに着手すると、それだけ投資対効果の評価方法が難しくなるのは自然なことでしょう。よって、開発経験を組織内に蓄積させるだけでなく、評価を通じて施策のPDCAを回し続けるためにも、適切なスコープで投資対効果が現実的に判断可能な施策を積み上げていくべきです。

さて、施策の粒度を実現可能性を鑑みて適切に定めたとして、どのように投資対効果を評価すればよいのでしょうか？その際に用いる有効な指標が、KPIです。

前回のCase.2の解説でも掲載しましたが、DX施策の成否を判断するためには、あらかじめ施策が目標とする効果指標を定め、それを担当者の活動単位で分解し、各担当者が個別KPIの目標達成に向けて実務を推進する体制が要となります。

目標とする投資対効果は、実務で施策が実行されてはじめて確認されるものであり、それゆえ、実務面での効果計測は必須です。この点は、何度でも強調したいところです。

DX施策においては、活用するデータや施策実施後に収集されるデータは統合して管理・運用します。そして、各種施策で求める成果が得られたかどうかについて、データをもとに計測・評価する最も有効な経営管理手法の一つが、KPI管理です。

KPIを設計するには、少なくとも以下の4点は必ず考察すべきです。

ところが、施策の企画段階から「効果の計測方法」についての議論が丸ごと抜け落ちていて、実施後の効果が分からないまま「やりっ放し」になっているケースを数多く見てきました。

一方、効果計測の方法を検討していたとしても、KPI計測・集計などに使用したいデータが外部ITベンダーによって管理されるシステムに集積されている状況で、そのデータをリクエストしても手元に届くまで1週間以上かかる、といったケースも目の当たりにしてきました。これらは決して珍しいことではありません。

また、できる限りリアルタイムに確認することを企画当初から意図していたKPIにもかかわらず、データパイプラインが日次単位のバッチ処理のためシステム設計そのものがKPI管理との整合性が取れていない、という現象も頻繁に目の当たりにしてきました。リアルタイムなデータ処理すなわちストリーミング処理と、バッチ処理ではシステム設計が全くと言っていいほど異なるため、処理方法の変更には膨大なコストと時間が発生します。

上記のように、どこかに考察の甘さが残った状態で管理・運用プロセスを企画してしまうと、実務のステップに進んだ際に思わぬボトルネックと遭遇し、組織活動が急速に停滞します。こういった状況は、KPI運用に限らず、DXの活動で至るところに存在します。

ただし、こういった課題に直面することは、いずれの組織も割けては通れないでしょう。重要なのは、情報収集や外部知見の獲得などを通じてできる限り周到にこれらの課題を回避しつつ、課題に直面したら逐次対応し、組織的な学習を重ね、再発防止に努めることです。

問題であり、かつよく目の当たりにするのは、各種施策がやりっ放しの状態で、問題が起きても知らないうちに“火消し”が完了し、組織的な学習が積み上がらない状況です。組織的なDXの成熟度を高めていくためにも、早期に対策を講じるべきです。

なお、KPIの管理・運用については、ダイヤモンド・オンラインでの連載第5回に詳述していますので、是非ご参照ください。

---

ここまでの内容をまとめます。

DX施策の投資対効果を適切に評価するためには、そもそも組織のIT活用レベルの成熟度に合わせたテーマを選定して、開発推進することが肝要です。

また、投資対効果は実務で施策を活用して初めて計測されるものであり、であれば実務での効果計測手法をKPI等を通じて計測する活動が欠かせません。

まずは、少なくともこの2点に着眼して取り組みを新たに始める、または既存の取り組みを改善することを強く推奨します。

おわりに：立ち上げ→1年→3年の「壁」を乗り越えるために

ここまで、3回の記事にわたりDX組織の「立ち上げ時」「立ち上げ1年前後」「立ち上げ2〜3年後」に直面する典型的な課題について、その対応策も合わせて解説してきました。

エンジニアリングの領域では、「アンチパターン」と呼ばれる「典型的に陥りがちで、かつ避けるべき状態」を指し示す言葉があります。そして、アンチパターンと対応策を集合知化して組織の垣根を超えて共有し、再発防止と技術レベル向上を目指した風土が醸成されています。

一方、DXのビジネス領域における実務でも、至るところにアンチパターンが存在しています。それらは私の経験上、業種業界問わず共通して至るところで何度も再発しているように見受けられます。しかし、これらに対する集合知的なものはなかなか見当たらないのが現状です。

こういったDXのビジネス領域におけるアンチパターンに対し、対応策は時間の経過とともに成熟し、共有され、発展的に各種課題が解消していくように進むべきだと思います。そんな思いから、ここまでの記事を書きました。

DXの実務において、さまざまなフェーズで悩む方々にとって、本記事が少しでも役に立てば幸いです。

より具体的な質問やご相談などあれば、お気軽に弊社までお問い合わせください。