製造業DXの現場では、日々多くの推進リーダーが壁にぶつかり、悩みを抱えています。
私たちマクニカは、組織のために奮闘する皆様を現場で支援し続けてきました。本連載ではその経験を踏まえ、DX推進リーダーを3つのタイプに分類し、それぞれの「よくある失敗」と「解決策」を解説します。
本連載が、DX推進に悩む皆様が再び前を向くヒントになれば幸いです。（この記事は1回目／全3回）
製造業DX推進リーダーの3タイプ
製造業DXの推進を主導するチームは、企業によって大きく異なります。
本記事では、そのチームの推進リーダーを以下の3パターンに分け、各タイプの「強み・弱み・よくある失敗・その解決策（次記事）」について、長年製造業のDXを伴走支援してきたデジタルインダストリー事業部 事業部長代理の阿部に聞きました。
まずは各タイプのリーダーのDX推進時における強み・弱みからご紹介します。
製造業DX推進リーダーの「強みと弱み」
タイプA：事業部門が主体となってDXを推進するケースのリーダー
—— まずは、事業部門が主体となってDXを推進するケースのリーダーが製造業DXプロジェクトの推進リーダーをする際の強みを教えてください。
阿部：タイプAの強みは、解決したい課題が明確であることです。
なぜなら、プロジェクトを実行する自分たちが、その恩恵を直接受ける受益者だからです。やる人と効果を受け取る人が同じなので、非常にシンプルな理屈で動くことができます。
通常、関係者が多いDXプロジェクトでは、誰が嬉しいのかが曖昧になり、勢いが失速することがよくあります。 しかし、彼らは成功した時の具体的なインパクトをイメージできています。そのため、高いモチベーションで推進力を維持し続けられるのです。
——逆にタイプAはDX推進時、どういった弱みを抱えていますか。
阿部：タイプAのDX推進における弱みは、工数（リソース）の確保が難しいことです。
なぜなら、彼らは既存のビジネスで多額の売上を作っており、非常に忙しいからです。
以前、『彼をプロジェクトに入れるのは、現金で1億円出すよりも難しい』と言われたことがあります。その事業部のエースが抜けると、回している数億円規模のビジネスが止まってしまうからです。
その結果、エース級の人材であるタイプAを専任にすることは困難となり、工数不足でプロジェクトが停滞したり、思わぬ問題が起きたりしやすくなります。
タイプB：IT/情報システム部門がDXを推進するケースのリーダー
阿部：タイプBの強みは、運用やガバナンスを含めた「全体最適」の視点を持っていることです。
なぜなら、システムは作って終わりではないからです。 事業部門はどうしても完成に意識が向きがちですが、実際にはその後に長い運用が続きます。一方タイプBは、その先まで見通す視点で意思決定を行えます。
また、会社では多くのシステムが動いています。 それらを横並びにして、全体への影響を考えられるのは、共通部門に所属するタイプBだけです。
つまり、個別のシステムを作るだけでなく、会社全体の仕組みを安全に動かし続ける力がある点が強みと言えます。
阿部：タイプBのDX推進における弱みは、システムという手段を用意することはできても、それを使って実際に利益を生み出す事業活動そのものを直接コントロールできない点にあります。
プロジェクトの立ち上げ当初は、データ統合基盤の構築といった技術的なビジョンや将来性に対して期待が集まります。しかし、時間が経過し、経営層から『この投資に対して具体的にどのようなビジネス成果が出たのか』を問われるフェーズになると、状況が厳しくなることがあります。
なぜなら、実際にシステムを活用して売上を上げたりコストを削減したりするのは事業部門の役割であり、彼らが動かない限り、数値としての成果が生まれないからです。
つまり、IT部門単独ではプロジェクトの投資対効果を完結させることが難しい構造にあるという点が弱みです。
タイプC：DX推進部/経営企画部門がDXを推進するケースのリーダー
阿部：タイプCの強みは、全体最適を描ける構想力と、ビジネスとITの双方を理解しながらプロジェクトを推進できるバランス感覚です。
事業部門は自部門の売上や効率を優先し、IT部門はシステムの安定稼働を優先する役割があります。これに対し、タイプCは全社を連携させるミッションを持っています。
そのため、各部署がバラバラになることを防ぎ、会社全体で共通化すべきデータや業務を整理できます。現場の要望と経営の方向性をすり合わせ、無駄のない投資判断ができるポジションだからこその強みです。
また、DXを進める際、IT部門はビジネスの収益構造に疎く、事業部門はシステムに疎いというすれ違いが起きることがあります。タイプCはちょうどその中間に位置し、お互いの意見を調整できる貴重な存在です。
ITの専門家ではないかもしれませんが、事業部門が求める利益の出し方と、IT部門が求めるシステム構築の考え方の両方を理解できます。そのためバランス感覚を持ちながら、全体最適と実行力を両立させられるポテンシャルを秘めています。
阿部：タイプCのDX推進における弱みは、自部門の圧倒的なリソース不足とそれを補うためのチーム統率による精神的な負荷です。
DX推進部や経営企画部は構造的に少数精鋭です。 IT部門や事業部門には何十人、何百人と社員がいますが、タイプCが所属する部署の人数は限られています。さらに組織の構造上、すぐに人を増やせる部署でもありません。その結果、プロジェクトを成功させるために必要な最低限の人数を割った状態で、スタートせざるを得ないのが実情です。
DXプロジェクト推進時は、リソース不足を補うためにも、他部門のキーマンをチームに引き入れる必要があります。 しかし、各部門のエース級人材は忙しく、個性が強いことがあり、彼らを束ねるのは至難の業です。タイプCはチームの調整業務に追われ、そのストレスを一身に受けることになります。
つまり、いくら正しいコンセプトを持っていても、自部門にリソースがないことや他部門との調整業務が重なり、リーダー自身が疲弊してしまうのです。これが、タイプCの推進力を削ぐ構造的な弱点となります。
リーダー別、製造業DXのよくある失敗事例
タイプAの失敗事例：個別最適
——タイプAが陥るよくある失敗事例にはどういったものがあるのでしょうか。
阿部：タイプAの典型的な失敗例は、個別最適、つまり自分たちの都合だけで突き進んでしまうという点です。
彼らは全社システムとの連携や、その後の運用・保守という視点から抜けがちです。その結果、拡張性がなかったり、メンテナンスにお金がかかるシステムになります。
自分たちにとっては良いものでも、IT部門からは運用に乗せられないと突き返されてしまい、プロジェクトは縮小してしまいます。
もちろんリーダーたちも頭では全体最適が大事だとわかっています。しかし、会社の評価制度がDXを全体最適に進める構造になっていません。
事業部門の責任者は、その事業の数字と実績だけで評価されます。他部門への貢献や全社最適は、評価の対象に入っていません。 その結果、どうしても自部門の利益を最優先に行動せざるを得ないのです。
タイプBの失敗事例：使う側とのミスマッチ
阿部：タイプBのリーダーが陥りやすい失敗は、大きく分けて2つのパターンがあります。
1つ目は、ビジネス部門との目的や仕様のミスマッチが起きてしまうことです。
IT部門単独では、ビジネス側の利益目標を設定することはできません。また、多岐にわたる現場の利用シナリオを、自力で解像度高く描くことも容易ではありません。その結果、機能的には要件定義を満たしていても、現場の業務実態に即さないシステムが構築されてしまうということが起こります。
これが避けられないのは、IT部門と事業部門とで、役割における目的が異なるからです。
通常、IT部門は組織の安定を守るため、ガバナンスや既存システムとの整合性を最優先します。これは管理の視点では大正解ですが、現場が求める市場への即応性や使い勝手などとは必ずしも一致しません。
つまり、それぞれの部門が自らの役割において正しい判断を下した結果として対立が生じるため、わかっていても避けられない失敗と言えます。
2つ目のよくある失敗は、開発の最終段階になって手戻りが発生してしまうことです。
プロジェクト初期にどれだけ綿密に合意形成を行っていても、完成後のシステムが日々の業務にどう組み込まれるかを現場が具体的にイメージすることは難しいからです。長期間の開発を経てリリースされた段階になって初めて、システムを使う側から『想定していたイメージと違う』、『業務フローに合わない』といった不満が噴出しやすくなります。
これが避けられない理由は、人間は実際に動く実物を見ない限り、具体的な要望や不満を言葉にできない特性を持っているからです。システムを使う人は、実際に完成したシステムを触って初めて潜在的に抱えていた要望に気付きます。そして、それがフィードバックとして言語化されます。
つまり、事前の合意プロセスの問題があるのではなく、実物に触れるまで本当のニーズに気付けないという人間の性質による問題のため、後工程での認識のズレを回避するのは難しいです。
タイプCの失敗事例：権限と調整による疲弊
阿部：タイプCにおいてよく見られる失敗は、変革を推進するための権限とリソースが、そのミッションの大きさと釣り合っていないことに起因します。
全社的なDXを推進するには、各部門の利害を調整し、時には全体最適のために個別最適を断るような強いプロジェクトマネジメント機能が必要です。しかし、実際にはDX推進担当者が他業務と兼務であったり、十分な決裁権限を持たされていないケースが多く見られます。
その結果、各部署からの要望を聞いて回るだけの調整役となってしまい、実行フェーズに進めず、担当者が疲労困憊してしまうという状況に陥りがちです。
また、社内の人間関係がある中で、特定の部署や役職者の意見を却下したり、優先順位をつけたりすることは、心理的にも政治的にも非常に困難です。社内のメンバーだけで客観的な判断を下すことには限界があるため、外部のパートナーを第三者視点として活用するといった“合意形成を進める体制”が作れていないことも要因の一つです。
——なぜ、このようなリソースや権限の不足が明らかであるにもかかわらず、状況が改善されないのでしょうか。
阿部：その背景には、組織として『現場の努力でなんとかなるだろう』という見通しを持ってしまう傾向があります。経営層も任命されたリーダー自身も、今の体制では負荷が高く、成果を出すのが難しいことは薄々認識しています。しかし、組織の変更や権限移譲、あるいは増員といった具体的な構造改革に踏み切るのは容易ではありません。
その結果、根本的な解決策が打たれないまま『まずは今のメンバーでやってみよう』とスタートしてしまい、結果的に実行不可能な目標に対して時間だけが過ぎてしまうというケースが多く発生しています。これは個人の能力の問題ではなく、プロジェクトの難易度に対するリソース配分の見積もりが、組織として適切に行われていないことが本質的な原因です。
では、各タイプのリーダーはこの失敗事例をどのようにしたら解決できるのでしょうか？
詳細は次の記事でご紹介します。
ソリューション
製造業DXを組織文化にするDigital Execution Factory
マクニカでは、製造業DXの各リーダーの強み・弱みに合わせて、パートナーとして失敗を一緒に乗り越える製造業DX支援サービスを提供しています。
具体的には以下のようなご支援を通じて、DXを組織文化にする「Digital Execution Factory」を提供しています。
- 全社を巻き込むガバナンス体制の強化
- 事業部門・IT部門を横断する専門組織（CoE）の構想設計から立ち上げ・定着に至るまでの伴走
- DX推進を現場でリードできるスペシャリスト人財の育成プログラム
- アジャイル開発で小さい成功体験を積めるローコード開発プラットフォームのMendixを活用した開発支援
など
「Digital Execution Factory」はDXが進んでいる欧米で確立された実学を、日本の製造業向けに最適化した日本でマクニカしか提供できないノウハウです。お客様それぞれにとって最適なDXが、「自発的かつ継続的に創出される」状態を目指し、伴走いたします。