経営のデジタルファースト

2022/1/5 16:472026/5/14 9:37

経営のデジタルファーストはなぜ重要か？

簡単に言うと、経営のデジタルファーストは「経営陣が先頭に立ってデジタル化を推進すること」です。企業変革をスポーツチームの改革に例えてみましょう。監督やコーチが旧来の練習方法に固執し、選手だけが新しいトレーニング法を試そうとしても、チーム全体の変革は実現しません。監督自身が最新のスポーツ科学を学び、データ分析を活用し、戦略を明確にし、それを選手に示してこそ、チーム全体が変わります。企業のデジタルトランスフォーメーションも同じです。経営層がデジタル技術への理解を深め、明確なビジョンを示し、技術戦略を策定し、競争領域を内製でコントロールし、適切な投資判断を行うことで、組織全体のDXが加速するわけです。

もう少し正確に言うと、経営のデジタルファーストはDX推進の成否を決定づける最重要要素です。IPA（情報処理推進機構）の「DX推進指標自己診断結果分析レポート」によれば、DXに成功している企業では、経営層がデジタルビジョンを明文化し、推進指標を設定し、技術戦略を主導的に策定しています。また、ソフトウェアエンジニアとしての業務経験を持つCTOまたは技術担当取締役が存在し、CDO（Chief Digital Officer）が経営変革を担っています。一方、日本の大企業では、IT予算の過半をソフトウェア資産として計上し、予算決裁に1か月以上かかる意思決定フローを挟んでおり、仮説検証サイクルを迅速に回せない状況が続いています。また、プロダクトマネジメント経験者がおらず、開発チームとの関係が受発注構造になっている情報子会社問題も深刻です。

具体的には、MicrosoftのCEOサティア・ナデラは電気工学とコンピュータサイエンスのバックグラウンドを持ち、AmazonのCEOアンディ・ジャシーはAWS創設者として深い技術理解を持ち、自らデジタル戦略を策定し、全社に発信しています。競争領域のプロダクト開発は内製人材でコントロールし、非競争領域はSaaSに業務をフィットさせることで、リソースを効果的に配分しています。また、デジタル事業および人材獲得に向けたM&A・投資部隊を持ち、外部の技術や人材を積極的に取り込んでいます。一方、日本の大企業では、非競争領域のシステムについても既存の業務フローに合わせてパッケージソフトをカスタマイズし、結果として保守コストが高騰し、変更が困難になるという悪循環に陥っています。経営層がデジタル技術を理解せず、情報システム部門に任せきりになっていることが、こうした問題の根本原因となっているわけです。

経営層のデジタルリーダーシップ

経営のデジタルファーストを実現する第一歩は、経営層自身がデジタル技術への理解を深め、明確なビジョンを示すことです。

デジタルビジョンの策定と発信においては、データとデジタル技術を用いた事業変革のビジョンを明文化し、経営メッセージとして社内外に発信します。ビジョンには、デジタル技術によって実現したい事業変革、顧客体験の向上、業務効率化などを具体的に記述します。また、DX推進指標（デジタル売上比率、顧客のデジタル接点利用率、業務の自動化率、クラウド移行率など）を設定し、四半期ごとに進捗を測定します。ビジョンが抽象的すぎると、現場は何をすべきか分かりませんので、具体的な事業目標とデジタル施策を結びつけ、実行可能なアクションプランに落とし込むことが重要です。

技術戦略を主導するCTOの配置も不可欠です。ソフトウェアエンジニアとしての実務経験を持つCTOまたは技術担当取締役を任命し、技術戦略の策定を主導してもらいます。技術戦略とは、経営戦略に基づいた技術に関する意思決定ないしは基本的な方針のことで、技術スタックの選定、アーキテクチャ方針、内製と外製の判断、技術投資の優先順位などを含みます。CEOが元ソフトウェアエンジニアでCTOを兼務している場合も評価されます。CTOに技術的バックグラウンドがない場合、技術的な意思決定が遅れたり、不適切な判断が行われたりするリスクがあります。CTOが経営層の一員として経営会議に参加し、技術的観点から経営判断に関与することが重要です。

デジタル変革担当役員（CDO）の配置により、組織横断的なDXを推進します。CDOまたはそれに相当する役員を任命し、組織のデジタル変革を経営の視点で推進してもらいます。CDOは、デジタルビジョンの策定、DX推進計画の立案、各事業部のDX支援、デジタル人材の育成、デジタル投資の優先順位付けなどを担当します。情報システム部門長がDX推進責任者の場合は評価されず、経営メンバーが責任者である必要があります。CDOは情報システム部門のトップとは異なる役割を持ち、既存システムの運用・保守ではなく、事業変革とイノベーションを推進する役割です。

競争領域と非競争領域の戦略的区分

限られた技術リソースを効果的に配分するには、自社システムを競争領域と非競争領域に明確に分類することが不可欠です。

競争領域の内製コントロールにより、事業の競争優位を確保します。自社システムを競争領域と非競争領域に分類し、競争領域のプロダクト開発を内製人材でコードレベルまでコントロールします。開発を一部外部に委託していても、内製人材がソースコードをレビューし、アーキテクチャを判断し、技術的負債を管理していれば評価されます。競争領域とは、売上や利益の増大を生み出すもの、自社事業の競争優位につながるものであり、ここに技術投資を集中させます。全てを内製化することが目的ではなく、戦略的に重要な部分を内製でコントロールすることが重要です。

非競争領域のSaaS活用により、保守コストを削減し、最新機能を利用します。競争領域ではないシステム（経費精算、勤怠管理、人事管理など）については、既存の業務フローに合わせてパッケージソフトをカスタマイズするのではなく、SaaSの標準機能に業務をフィットさせます。提供されているサービスのAPIを使った連携開発は許容されますが、ソフトウェア本体のカスタマイズは避けます。カスタマイズすると、保守コストが高騰し、バージョンアップが困難になり、結果として技術的負債が蓄積します。業務フローの変更には従業員の抵抗が予想されますので、経営層が明確に方針を示し、なぜSaaSに合わせるのか、それが組織にどんなメリットをもたらすのかを丁寧に説明することが重要です。

プロダクトマネジメント体制の構築により、継続的な改善を実現します。継続的なシステム改善のためのプロダクトマネジメント経験者を採用・育成し、開発チームと協働してプロダクトを改善する体制を作ります。プロダクトマネジメントとは、製品開発を導く戦略的役割を指し、継続的改善とビジネス目標との整合性に焦点を当てます。要件分析とプロジェクト管理だけでは不十分で、プロダクトビジョンの策定、ロードマップの作成、優先順位付け、成果測定などが必要です。情報子会社に開発を丸投げし、事業部門が要件を投げるだけという受発注構造では、継続的な改善が実現せず、市場の変化に対応できません。

迅速な仮説検証サイクルの実現

デジタル事業の成功には、仮説を立て、迅速に検証し、学習するサイクルを高速で回すことが不可欠です。

IT予算配分の柔軟化により、仮説検証を促進します。IT予算の大半をソフトウェア資産の減価償却費用に充てるのではなく、仮説検証やプロトタイピングのための費用を十分確保します。予算決裁のリードタイムを1か月未満に短縮し、迅速な意思決定を可能にします。市販目的のソフトウェアの場合、完成まで研究開発費として処理でき、その後無形固定資産として処理できるという柔軟性を活用します。システムを資産として開発すること自体は問題ではありませんが、それによって仮説検証予算が不足し、承認に時間がかかるようでは、DX推進の障害となります。財務・経理部門と協力し、柔軟な予算執行を可能にする仕組みを作ることが重要です。

M&A・投資戦略により、外部の技術と人材を取り込みます。デジタル事業および人材獲得に向けたM&A・投資戦略を策定し、それを遂行するための専門部隊を設置します。専門部隊がいない場合でも、独立した計画と予算があれば評価されます。M&Aによって外部の技術やプロダクト、人材を取り込むことで、内製開発だけでは実現できないスピードで事業を拡大できます。M&Aは統合後のPMI（Post Merger Integration）が成功の鍵となりますので、買収した企業の文化や技術を適切に統合し、シナジーを実現するための計画と実行力が必要です。

DX推進指標の継続的測定により、進捗を可視化します。DX推進指標を設定し、四半期ごとに進捗を測定し、経営層と共有します。IPAが提供するDX推進指標のような成熟度評価フレームワークを活用し、経営のビジョン、戦略、組織・制度、ITシステムの各観点から自社の状況を評価します。推進指標は定期的に見直し、事業環境の変化に対応する必要があります。定量的な測定により、DXの進捗が可視化され、改善のための施策を科学的に決定できます。

カテゴリ内クライテリアの解説

CORPORATE-7-1: データとデジタル技術を用いて、どのように事業変革をしていくのかのビジョンを明文化して経営メッセージとして発信し、その推進経営指標をもっているか。

目的: データとデジタル技術を用いた事業変革のビジョンを明文化し、推進経営指標を設定することです。

実装のポイント: 経営層がデジタルビジョンを策定し、経営メッセージとして社内外に発信します。ビジョンには、デジタル技術によって実現したい事業変革、顧客体験の向上、業務効率化などを具体的に記述します。また、DX推進指標（デジタル売上比率、顧客のデジタル接点利用率、業務の自動化率、クラウド移行率など）を設定し、四半期ごとに進捗を測定します。Chief Digital Officerがいなくても、明確なビジョンと推進指標があれば評価されます。

注意点: ビジョンが抽象的すぎると、現場は何をすべきか分かりません。具体的な事業目標とデジタル施策を結びつけ、実行可能なアクションプランに落とし込むことが重要です。また、推進指標は定期的に見直し、事業環境の変化に対応する必要があります。

CORPORATE-7-2: ソフトウェアエンジニアとしての業務経験のあるCTOないし技術担当取締役が存在し、技術戦略についての策定を主導的に行っているか。

目的: 技術的バックグラウンドを持つCTOまたは技術担当取締役を置き、技術戦略を主導的に策定することです。

実装のポイント: ソフトウェアエンジニアとしての実務経験を持つCTOまたは技術担当取締役を任命し、技術戦略の策定を主導してもらいます。技術戦略とは、経営戦略に基づいた技術に関する意思決定ないしは基本的な方針のことで、技術スタックの選定、アーキテクチャ方針、内製と外製の判断、技術投資の優先順位などを含みます。CEOが元ソフトウェアエンジニアでCTOを兼務している場合も評価されます。

注意点: CTOに技術的バックグラウンドがない場合、技術的な意思決定が遅れたり、不適切な判断が行われたりするリスクがあります。また、CTOが経営層の一員として経営会議に参加し、技術的観点から経営判断に関与することが重要です。

CORPORATE-7-3: デジタル技術を活用した経営変革を担う担当役員（CDO等）が存在するか。

目的: デジタル技術を活用した経営変革を担う担当役員を置き、組織横断的なDXを推進することです。

実装のポイント: CDO（Chief Digital Officer）またはそれに相当する役員を任命し、組織のデジタル変革を経営の視点で推進してもらいます。CDOは、デジタルビジョンの策定、DX推進計画の立案、各事業部のDX支援、デジタル人材の育成、デジタル投資の優先順位付けなどを担当します。情報システム部門長がDX推進責任者の場合は評価されず、経営メンバーが責任者である必要があります。

注意点: CDOは情報システム部門のトップとは異なる役割を持ちます。情報システム部門は既存システムの運用・保守が主な役割ですが、CDOは事業変革とイノベーションを推進する役割です。両者の役割分担を明確にし、協力関係を構築することが重要です。

CORPORATE-7-4: 自社システムの戦略(競争領域・非競争領域の定義)を明確化しており、競争領域のプロダクト開発を内製人材でコントロールできているか。

目的: 自社システムの戦略を明確化し、競争領域のプロダクト開発を内製人材でコントロールすることです。

実装のポイント: 自社システムを競争領域と非競争領域に分類し、競争領域のプロダクト開発を内製人材でコードレベルまでコントロールします。開発を一部外部に委託していても、内製人材がソースコードをレビューし、アーキテクチャを判断し、技術的負債を管理していれば評価されます。競争領域とは、売上や利益の増大を生み出すもの、自社事業の競争優位につながるものであり、ここに技術投資を集中させます。

注意点: 全てを内製化することが目的ではなく、戦略的に重要な部分を内製でコントロールすることが重要です。非競争領域は外部サービスやパッケージソフトを活用し、限られたリソースを効果的に配分します。

CORPORATE-7-5: デジタル事業および人材獲得に向けたM&A・投資戦略を遂行するための部隊が存在するか。

目的: デジタル事業および人材獲得に向けたM&A・投資を戦略的に実行することです。

実装のポイント: デジタル事業および人材獲得に向けたM&A・投資戦略を策定し、それを遂行するための専門部隊を設置します。専門部隊がいない場合でも、独立した計画と予算があれば評価されます。M&Aによって外部の技術やプロダクト、人材を取り込むことで、内製開発だけでは実現できないスピードで事業を拡大できます。

注意点: M&Aは統合後のPMI（Post Merger Integration）が成功の鍵となります。買収した企業の文化や技術を適切に統合し、シナジーを実現するための計画と実行力が必要です。

CORPORATE-7-6: IT予算の過半をソフトウェア資産として計上し、予算決裁のためにリードタイムの長い（１ヶ月以上かかるような）意思決定フローを挟んでいる。（アンチパターン）

目的: 仮説検証サイクルを迅速に回せるよう、IT予算配分と決裁フローを最適化することです。

実装のポイント: IT予算の大半をソフトウェア資産の減価償却費用に充てるのではなく、仮説検証やプロトタイピングのための費用を十分確保します。予算決裁のリードタイムを1か月未満に短縮し、迅速な意思決定を可能にします。市販目的のソフトウェアの場合、完成まで研究開発費として処理でき、その後無形固定資産として処理できるという柔軟性を活用します。

注意点: システムを資産として開発すること自体は問題ではありませんが、それによって仮説検証予算が不足し、承認に時間がかかるようでは、DX推進の障害となります。財務・経理部門と協力し、柔軟な予算執行を可能にする仕組みを作ることが重要です。

CORPORATE-7-7: 継続的なシステム改善のためのプロダクトマネジメント経験者がいない。そのため、開発チームとの関係が受発注構造になっている。（情報子会社問題）（アンチパターン）

目的: プロダクトマネジメント経験者を配置し、開発チームとの協働体制を構築することです。

実装のポイント: 継続的なシステム改善のためのプロダクトマネジメント経験者を採用・育成し、開発チームと協働してプロダクトを改善する体制を作ります。プロダクトマネジメントとは、製品開発を導く戦略的役割を指し、継続的改善とビジネス目標との整合性に焦点を当てます。要件分析とプロジェクト管理だけでは不十分で、プロダクトビジョンの策定、ロードマップの作成、優先順位付け、成果測定などが必要です。

注意点: 日本企業では、情報子会社に開発を丸投げし、事業部門が要件を投げるだけという受発注構造になりがちです。これでは継続的な改善が実現せず、市場の変化に対応できません。プロダクトマネージャーが開発チームと一体となって働くアジャイル型の体制を構築することが重要です。

CORPORATE-7-8: 競争領域ではないシステムについて、業務フローをSaaSに合わせて変更するのではなく、既存の業務フローに合わせてパッケージソフト等をカスタマイズしている。（アンチパターン）

目的: 非競争領域のシステムについては、業務フローをSaaSに合わせて変更し、カスタマイズを避けることです。

実装のポイント: 競争領域ではないシステム（経費精算、勤怠管理、人事管理など）については、既存の業務フローに合わせてパッケージソフトをカスタマイズするのではなく、SaaSの標準機能に業務をフィットさせます。提供されているサービスのAPIを使った連携開発は許容されますが、ソフトウェア本体のカスタマイズは避けます。カスタマイズすると、保守コストが高騰し、バージョンアップが困難になり、結果として技術的負債が蓄積します。

注意点: 業務フローの変更には従業員の抵抗が予想されます。経営層が明確に方針を示し、なぜSaaSに合わせるのか、それが組織にどんなメリットをもたらすのかを丁寧に説明することが重要です。また、段階的な移行と十分なトレーニングが必要です。

参考資料・ツール

参考書籍・記事

IPA「DX推進指標自己診断結果分析レポート（2019年版）」: 日本企業のDX推進状況を分析した公式レポートです。成功企業の共通点として、経営層のコミットメント、明確なビジョン、推進指標の設定などが示されています。

freee Developers Blog: プロダクト開発を重視する企業における技術戦略の策定方法、開発組織の運営、技術的意思決定のプロセスなどが公開されています。

Wikipedia「情報子会社問題」: 日本企業に特有の情報子会社問題の背景、問題点、解決策が説明されています。ITシステム部門のアウトソーシングが企業のITガバナンスを低下させる可能性について理解できます。

国税庁 No.5461「ソフトウェアの取得価額と使用年数」: ソフトウェア資産の会計処理、減価償却の方法、研究開発費との区分などが公式に示されています。