日本企業がDXにつまずく理由と、経営・管理・現場層、それぞれの役割：特集：日本型デジタルトランスフォーメーション成功への道（8）（1/3 ページ）

DX（デジタルトランスフォーメーション）のトレンドが高まり、多くの企業が取り組みに乗り出している。だが「具体的に何をすればいいのか分からない」、取り組みを進めてみても「なかなか成果につながらない」など、プロジェクトを推進できていない例が多い。その真因は何なのか？――既存資産を持たないスタートアップや新興企業ではなく、一般的な企業が既存資産を守りながらDXを推進するためのポイントを聞いた。

[文:斎藤公二／インタビュー・構成:内野宏信／＠IT]

　ビジネスが「体験価値による差別化」「ソフトウェアの戦い」に変容し、およそ全ての企業がテクノロジー企業へと変革することを迫られている。こうした中、DX（デジタルトランスフォーメーション）の推進に当たり、「デジタル推進室」などの専門組織を作る動きも高まっているが、自社が立脚してきた既存業務／既存システムとの連携がない、SoE（システムオブエンゲージメント）とSoR（システムオブレコード）の取り組みが完全に分断されているなど、既存のコア事業とは切り離されている傾向が強い。結果、DXの主軸となるSoE領域の取り組みは試行に終始し、全社レベルの変革、ビジネスモデルの変革にまでは至っていないケースが大半のようだ。

　では日本企業が真にDXを推進し、テクノロジーを差別化の源泉としていくためには、何をそろえ、どのようなステップを踏めばよいのだろうか。今回は、テクノロジー、開発プロセス、組織文化なども含め、“企業としてのデジタル変革”を包括的に支援しているグロース・アーキテクチャ＆チームス 代表取締役社長　鈴木雄介氏に話を聞いた。

ビジネスモデルを変える話が、開発手法を変える話になってしまっている

編集部　ここ数年で、DXという言葉は社会一般に認知され、取り組みを進める企業も増えていると思います。しかし、一部では「AIを使って何かやれ」など、ただ単に「新たな技術を取り入れること」がDXだと誤解されている傾向もあるようです。鈴木さんは近年の状況をどう見ていらっしゃいますか？

グロース・アーキテクチャ＆チームス 代表取締役社長　鈴木雄介氏

鈴木氏　既存のビジネスをサービス型に変え、「継続的に収益を得る仕組みを作ること」「継続的な改善を含めて収益を得ていくこと」がDXの本質だと思います。経営環境変化を予測しにくい中、売り切りでお金をもらう時代は終わり、初期コストをできるだけ小さくして、継続的に収益を得ていく形にビジネスモデルを変えていかなければなりません。そうした危機感を持つ経営層は多くいますし、そのためにITを活用していこうとしています。DXのトレンドは、「何とかして変わらなければならない」という経営層の危機感の表れだと思っています。

編集部　確かに、経営層が危機感を抱いていることは多数聞かれます。ただ、取り組みをうまく進められない、成果が出ない、といった声も多いようです。

鈴木氏　「実際にどうすればいいか」という点でつまずく原因になりやすいのは、DXを「システム開発の問題」と捉えてしまうことです。DXは「テクノロジーを前提に、ビジネスモデルを変えること」であり、「システム開発のやり方を変える」という問題ではありません。にもかかわらず、「従来のウオーターフォール型開発を変えなくては」という議論になってしまう。

　開発のやり方を変えることはもちろん重要ですが、変えるべきは「開発部分」だけではありません。「ソフトウェア開発をビジネスモデルの中にどう組み込むか」が議論のスタートであるはずなんです。

　しかし、「どんなITサービスを作るか」は決まっていても、その前提となる部分――「差別化に資する価値を生み出すために、サービスの仕様はどうあるべきか」「ニーズに応え続けるために、ユーザーとどう対話するのか」といった部分が考えられていない例が目立ちます。開発スタイルは、そうした“前提”に最適なものを選ぶべきでありながら、前提がしっかりと検討されないまま、手段の話だけを注視してしまう。

編集部　つまりDXに取り組もうと考えながら、「ビジネスモデル全体」を見ていない。開発に対するアプローチも、アジャイル開発を取り入れようとしておきながら、最初に作るものの計画を立てて、計画通りに作るウオーターフォール型のまま、ということですね。

鈴木氏　そうです。ウオーターフォール型の、「戦略に6カ月、開発に6カ月」という時間軸のまま、開発の手段だけをアジャイル開発に変えようとしている。それでは開発成果物が顧客に届くまでのリードタイムは変わりません。「ニーズの変化に応えるスピード」が最大の差別化要素となっている中で、リリースが遅くなる上、変化に応じて事業企画をチューニングすることもできません。

スピードを上げるためには、企画〜開発のリードタイムを短くする

編集部　貴社に相談に来られる方は、そうした課題を認識されているのでしょうか？

鈴木氏　サービスのリリースサイクルを一周終わらせてみて、課題に気付かれることが多い印象です。「開発スタイルをアジャイルに変えてみたが、結局、ウオーターフォールと同じじゃないか」と。

　そこで、「スピードを上げるためには、ITを提供するまでのリードタイムを短くしましょう」と提案しています。リードタイムというのは「戦略を思いついてから、開発をして、顧客にサービスを提供するまで」にかかる時間です。この時間こそが、変化に応えるスピードなんです。これは開発だけではなく、「どのように戦略を立て、サービスに落とし込み、リリースするか」「どのようにユーザーからのフィードバックを得て、どのようにサービスに反映するか」という議論も必要になります。

　もちろん「何を作るか」を決めるのは事業部門です。研究開発ではなく、実ビジネスとしてリターンを得ることが目的ですから、事業部や経営企画室などが主幹となってサービスを定義します。それが本当に世の中に受け入れられるか否かを確認したり、よりもうかる方法は何かを模索したりする活動の中に、ソフトウェア開発を織り込んでいくのです。しかし多くの場合、「事業計画はできたので、後は開発をよろしく」となってしまう。

編集部　事業部門が作るものを考え、IT部門はただそれを請け負う、という以前からの構図ですね。

鈴木氏　「後はよろしく」という話にしてしまうから、開発側も「ではアジャイルで」となってしまう。そうではなく、サービス企画・運営のやり方から変える必要があり、それに開発、運用が主体的に関わっていくことが大切です。

編集部　その意味では、エンタープライズでDevOpsに取り組むケースも増えてきました。コンテナやコンテナ管理、マイクロサービスも注目を集めていますが、これらもあくまで「ソフトウェア開発をビジネスモデルの中にどう組み込むか」という視点で選ぶべき手段だということですね。

鈴木氏　そうですね。ただしDevOpsは「開発と運用が仲良くしよう」といった甘い話ではないことに注意すべきです。リードタイムを短縮するという目的に基づいて、手作業による運用業務を減らす、場合によっては運用部門をなくすという話です。運用自動化が進むことで業務が減って人が余るといわれていますが、それはやってみなければ分かりません。私は従来の運用業務がなくなっても“やるべき仕事”がなくなることはないと思いますが、いずれにせよビジネスの戦略・企画ありきで、DevOpsから考えるものではありません。

　コンテナなどについても同様です。例えば「サービスを支えるコンテナの数が増え、100個以上あるコンテナを上げ下げするために自動化スクリプトを組んだが、動きを把握できるか不安だ」といったように、DXのビジネスを推進する上で困ったらKubernetesの力を借りればいい。3台のコンテナで十分なシーンに適用しても全く意味はありません。

　もちろん技術は非常に重要です。しかし、エンタープライズでは新しい技術が必ず必要になるわけではなく、技術が古いからといってできないということもほとんどありません。むしろ、技術を正しく機能させるために、まずはプロセスや人の役割をきちんと知っていくことが大切だと思います。