DX（デジタルトランスフォーメーション）とはなにか、そして何ではないのか

DX（デジタルトランスフォーメーション）という単語について、巷で多く聞かれるようになり、自分のもとにも様々ご相談をいただくことが増えてきた。また、マーケティングワード的な使われ方に対する批判など色々と聞かれるようになってきている。こうしたバズワードを強く押し出した記事を書くことはあまり好まないのだが、多くの企業においてソフトウェアがより導入され生かされる好機であると見てDXについて書いてみようと思う。

下記の元同僚のツイートが執筆のきっかけとなるが、自分なりのDXについての解釈を整理し簡単に示しておくことで、今後DXについてご相談に来られる方やDX推進される方々の参考になれば幸いである。

俺たちがちゃんと継続的リファクタをできていればDXなんて不要で、もっと緩やかなイテレーションでトランスフォームしていたはずなのだ。

— Seiji Takahashi - timakin (@__timakin__) May 30, 2020

 DXとは「失敗をコントロールし継続的に改善し続ける」ことだ

DMMの改革を進める中で、ソフトウェアでより成長を加速する、より多くの事業を立ち上げられる会社にしていこうと取り組んできた。その中で一番意識しているのは表題の「失敗をコントロールし継続的に改善し続ける」状態に至ることだと考えている。これは、近年のソフトウェアスタートアップがなぜ成長しているか、ということに答える重要な特徴だと考えている。

近年のソフトウェア企業とそうでない企業の事業改善の施策リリース数は一桁、二桁というレベルで差がある。参考までにGunosyの開発を率いていたころ、常時ABテストが幾つも実行されており、一つのサービスあたりの機能リリース数は細かなものを含めれば毎日数回以上、日々なんらか新しものが公開されている状態を続けていた。しかもプロダクトあたり10人にも満たないチームでだ。年間に換算すれば相当なリリース回数となる。参考までにどういったフローで改善しているのかなどは下記のブログなど参考にされるといいかもしれない。

Gunosyでの仮説検証 - Gunosy Tech Blog

この改善サイクルは事業の理解をより促進する仕組みにもなり、ただ闇雲に改善するでなく、ある程度の打率を持った改善へ向かっていく手助けにもなる。最終的には改善回数が複利的効果を持って事業数値を向上させ競争優位性・成長速度につながっていたのだ。

また、こうした多くの改善サイクルを回すことは当然一定の失敗・障害リスクを伴う。このようなリスクを局所化する、素早く復旧するという観点でソフトウェアが強く活かせる。適切なソフトウェア設計はこうした失敗のコントロールを可能にする。

こういった背景から、失敗をコントロールしながら、素早く事業を改善し続ける、そのためにソフトウェアと正しく付き合い、事業を科学的に理解する、この状態に至ることこそがDX（デジタルトランスフォーメーション）の目的なのではないかと私は考えている。DXとは技術・組織・文化・事業・経営など全てで取り組む総力戦なのである。

最近発信している「ソフトウェアと経営」マガジンはそうしたソフトウェアを交えた経営手法に対しての自分なりの整理を示したものである。何らか参考になればと願う。

ソフトウェアと経営について｜Matsumoto Yuki｜note

DXとは何でないか

ここまでの話を踏まえて、DXとは何ではないのか考えてみよう。

まず、技術負債を返済し新しいシステムに置き換えることや、新しいサービスを導入することではない。もちろんソフトウェアにおける技術的負債は付き合っていく必要があるが、必ずしも返済そのものはDXの目的ではない。技術的負債の返済はコストとリスク、リターンを考えながら推進されるべきものだと私は考えている。

また、様々な企業が特定の技術やサービスを以てDX推進というキーワードで売り込んでいるが、そうしたサービスをただ入れるだけでは事業改善が促進されるわけではない。あくまで、サービスは手段、戦術レベルの話である。どんなサービスであれ、事業課題を理解しどうすればより改善活動が頻度高く行われるか、目的に対して適切に導入されるべき性質のものだ。

また、AI（ないし機械学習）やBlockchain（ないし分散台帳）などの特定技術を導入すればいいということでもない。これらは非常に重要な技術であると言える。正しく用いることで継続的改善に資するものである。だが、あくまで技術も手段である。まずは事業改善におけるボトルネックやコストパフォーマンスを把握し、その突破のために必要とあらば技術を導入していく、という姿勢が重要である。

さらに、必ずしも完全内製に持っていこうということでもない。目的はあくまで「継続的改善が可能な事業体制」の構築だ。ソフトウェアやその障害影響のコントロールができていれば、実際の開発を外部のパートナーとすすめる事自体は間違いではないと考えている。もちろん、パートナーとの利害が一致するような契約スキームを用いることがよりよい結果をもたらすだろことを踏まえた新しい取り組み方が必要だと思う。

パートナー連携について見かけた良い事例を一つ紹介する。マルイの決算やこれまでの発信を見ていくと面白い。マルイでは、下記引用画像の通り、内製化の中でも特に「何を作るか」「結果としてのアウトプットの確認」という部分にフォーカスし、システムの開発面では外部のパートナーと連携し頻度高い改善を進めている。

参考資料https://www.0101maruigroup.co.jp/ir/pdf/i_report/2019/i_report2019_11.pdf

また、2020年3月期決算資料の中に下記のような結果が掲載されている。自社によるソフトウェアのコントロール領域を広げることで大きな成果を上げていると言っていいのではないだろうか。

だからこそ、パートナーと付き合うことと内製化はグラデーションがある取り組みであることを認識し、「何を作るか」というところにフォーカスし継続的に改善する、その失敗影響をコントロールする、といった活動の強化を優先していくべきだと思う。

最後に

BigDataやAI、Blockchain、そして今回のDXも、背景や目的、その内実をうまく把握することなく戦略にキーワードだけが取り入れられ、実効性を持たない、成果が出ないというケースは多かったのではないだろうか。しかし今回は世界的にソフトウェアを活用せねばならないという認識が高まったタイミングである。その中でソフトウェアが活かされ、より競争力ある企業が増えていけばと願う。

2020/06/04追記：続編書きました。

DXでお悩みの方々、ぜひご購読を。

ソフトウェアと経営について｜Matsumoto Yuki｜note