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

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

日本企業がDXを推進しにくい真因と、「変革の現実解」

編集部　とはいえ、事業部門とIT部門の分断は根が深い問題です。組織変革を進めるステップのようなものはあるのでしょうか。

鈴木氏　確かに、アジャイル開発やDevOpsをすんなりと実践できる準備が整っている企業は、現時点では決して多くありません。そこで、まずは現在の土台の上で「ビジネスをどう変えていくか」を議論しながら、リードタイムを短くするためのトライアルを始めましょうと勧めています。

　具体的には、営業、企画、開発、運用、品質管理、サービス、コンプライアンスなど、サービスの関係者全員が集まってそれぞれのタスクを洗い出すワークショップを勧めています。ワークショップの中では、サービスの企画から、見積もり、稟議（りんぎ）書作成、予算確保、設計、実装、受け入れ試験、運用チェック、リリース準備、リリース、顧客への周知、顧客へのデリバリーまで、リリースサイクルの全てにわたって全員で検討します。冒頭で話したソフトウェア開発が占める割合は、こうしたサイクル全体のうち3分の1ほど、実装期間は4分の1もないほどです。

　このワークショップをやると、サービスの企画からリリースまでに必要な時間が、案件の規模感に応じて分かるようになります。例えば、大規模なものなら2カ月、小規模なものなら2週間といった具合です。すると、「このサービスで、このリードタイムなら、既存の開発プロセスでサービスを提供できるね」、もしくは「新しい開発プロセスが必要だね」といった話をお互いに交わせるようになる。その上で、「では、リードタイムを半分にするにはどうするか」「4分の1にするにはどうするか」を関係者全員で検討していくのです。

編集部　一般に「バリューストリームマッピング」と呼ばれるものだと思うのですが、関係者全員でサイクル全体を見ることで、それぞれの意識を含めて変えていくことができるのですね。

鈴木氏　日本企業にとってDXの取り組みが難しいのは、この点にあると思います。組織の中での役割や責務がはっきり決まっていて、その範囲の中で取り組みを進めざるを得ない。たとえ経営層が危機感を持っていても、現場の危機感が薄い例が多いのも、それぞれの役割や職掌があるから。それを超えた取り組みは越権になるため、上から「やれ」と言われてもできない。

　難しいのは、この役割や職掌を変えていくことにあります。DXで一番重要なのは顧客に届けるまでのリードタイム。これを理解した上で、どうすればリードタイムを短縮できるか、どうすれば関係者間で協業しやすくなるかを一緒に考えることで、具体的な改善策につなげていくことがワークショップの狙いなのです。

　特にエンタープライズにとっては、DXのための新しいやり方が必要と分かっていても、既存のやり方を捨てられない事情があります。既存のやり方は、「自社製品・サービスを、安心・安全に社会に届ける」ための重要なプロセスであるため、いきなり捨てることはできません。従って、既存のチェックプロセスを踏まえた上でサービスをリリースしたいが、一方でスピードも上げなければならないという難しさがあるわけです。

　そうした課題を踏まえると、関係者それぞれが全体を見る意識を持ちながら、具体的な改善活動を重ねて少しずつ変えていくことが現実解だと思います。エンタープライズにとって、DXの取り組みは決して華やかなものではなく、非常に地道なものなんです。

経営者のレビューを数多く入れ、現場が経営者に直接意見を伝える

編集部　一方で、経営層に「何かやれ」と言われて困っているという声も多いわけですが、経営層側に求められることはありますか？

鈴木氏　意外かもしれませんが、経営者の方は驚くほど思考が柔軟で、少なくとも私の周囲では、アジャイルの本質もよくお分かりの方が少なくありません。アジャイルの本質が分かっていない経営者はそもそもDXという言葉すら使いません。ただ経営層がDXの重要性を認識していても、現場に正しく伝えられないことはありますし、前述のように現場には現場の事情がある。そこをどうすり合わせていくかは、われわれも模索中ですが、現時点では、やはり現場レベルで改善を進めるボトムアップのアプローチが有効だと考えます。

　経営者にとっても、ITサービスという具体的なモノを見せられて初めて「これはこうあるべきだよね」「こういう打ち出し方にしよう」といった具合に考えることができます。経営者だからといって全知全能ではありませんし、先を予測することも難しい。経営層に具体的な指示を期待するよりも、実際にモノを見せて、フィードバックを受けて、みんなで正解を模索する方がよほど有効です。

編集部　ただ、経営層や管理層も一定の技術理解があるべきだという意見もあります。どの程度、技術を理解しておく必要があると思いますか。

鈴木氏　目安は「プログラミングできるかできないか」だと思います。できないなら現場に任せるべきで、余計なことは言わないでおくべきです。「Kubernetesはおしゃれだね」とは誰でも言えます。「オレでもKubernetesを動かせるんだから、おまえもできるだろ」と言えるくらいでないと意味がない。それができないなら、技術ではなく経営を学ぶべきです。

　DXの現場では、「経営層に具体的なビジョンがないため何をすればいいか分からない」というセリフをよく耳にします。しかし、これは言い訳にすぎないと思います。誤解を恐れずに言えば、経営者は経営者でしかなく、最終顧客に直接接しているわけでもありませんから、具体的な事業のアイデアなど出てくる方が珍しいのではないでしょうか。つまり「事業や企画を考えるのは、プロダクトオーナーであるあなたでしょう？」という話なんです。

　ただ、経営者が上から「変われ」と号令を掛けて変わればいいですが、人や組織は簡単には変われません。「会社の体質、文化を変えましょう」という声掛けもほぼ意味がない。やはり現場レベルで変えていくべきで、「企画の人がこう関わってくれるから、開発はここまでできるはずだよね」と自分たちで具体的な気付きを得ながら少しずつ変えていく。それ以外に解決策はないのかなと最近は思います。

編集部　DXのプロジェクトを進める上ではKPI（重要業績評価指標）の設定が重要だと言われます。何か指針はありますか。

鈴木氏　管理層からそうした質問をよく受けます。今までのKPIはQCD（品質、コスト、納期）で、最初に決めた正しい品質、正しいコスト、正しい納期でやり切ることが重要でした。しかし、アジャイルはそうではない。では、何を見て現場が正しく回っているかを判断すべきか――企業ごとにKPIは少しずつ異なりますし、これは本当に難しい問題です。例えばECサイトなら「売り上げ5％向上」など明確な数値をKPIにしてもいいですが、DXのプロジェクトは先が予測できない中、正解を模索しなければならない。

　そこでお勧めしているのは、経営者のレビューを入れることです。ビジネスとして進めるべきか否かの判断は、最終的には経営層でなければ決められません。間にいろんな立場の人が入ると、そうした判断はだいたい歪みます。経営者によるレビューの回数を増やし、現場のメンバーは経営者に対して「こういう考えに基づき、こうやりました」と直接かつ具体的に伝える。サービスを判断し、改善すべきは企画なのか、営業なのかといった話も平等に採点できるのは経営者しかいません。