「まずは経営の意識改革だ」「まずは内製エンジニアだ」。 確かに経営の理解、SIer依存やレガシーシステムの解決は重要ですが、それは簡単には解けないパズルです。待っていても何も変わりません。
DXを前に進めるには、「意識が変わりきらない経営層」「金のかかるレガシーシステム」「足りない人材」の中で、どう動くかを考えるべきです。そのためには現場のリーダーがアジャイルをはじめとすると様々な技術をどう活用し、どう適用するのかを理解し、行動する必要があります。
「まずは経営層が」という言説の誤謬
最近、繰り返しウォーターフォールとアジャイルの話をしていますが、きっかけはAmazonの書評に星1をいただいたことで、その後のいくつかの記事を書きました。
論理的思考の違いから考えた、日本でアジャイルが機能しない理由と解決 - arclamp
ウォーターフォールとアジャイルをマネジメント手法としてフェアに評価してみる - arclamp
その後のはてブやSNSの反応で感じたのは、「経営層や組織が意識改革されない限り、何も変わらない」という言説への懸念です。
経産省が2018年に発行したDXレポートでは、DXの阻害要因としてレガシーシステムの問題を中心に取り上げた結果、「DXはシステムの問題」と誤認が進んだため、2020年以降のDXレポート2は「経営が推進すべき」という内容が中心となりました。
経営がDXを推進すべきなのは当然ですが「まずは経営が意識改革しなくてはダメだ」というのも誤認です。「会社でDXが進まないのは、経営|レガシーシステムのせいだ」というのは正しいですが、
という思考に向かうのは、非生産的です。屏風の虎は出てきません。
そんな解けない問題を前に腕を組んで批評だけしていても事態は一向に進みません。もう、2025年です。物事を自分の手で前に進める気がない人は黙ってていただきたい。害悪です。やる気のある若者でも、そういう言説に影響されて腕を組んでしまう。
そうじゃなくて、意識が変わりきらない経営層、色々な問題があるレガシーシステム、足りていない人材という中で「どうやったら会社のDXを進めることができるのか？」という視点に立つべきなのです。
少しでも前に進める
じゃ、お前には何か進めるためのアイデアがあるのか？というのに答えるのが拙著 DXリーダー必修講義 です。
6つのテクノロジーを活用し、コストをかけずにレガシーシステムを維持しながら全社視点で再構成を進める実践的なアプローチを示しています。
そのためには6つのテクノロジーであるアジャイル、クラウド、DevOps、マイクロサービス、クラウドネイティブ、プラットフォームエンジニアリングという言葉への理解が必要です。理解できれば非常に現実的な取り組みとして進めることができます。低コストで始められ、リスクも少なく、それでいて効果的です。地道ですが。
ただ、これらのテクノロジーについて全てを学ぶのは無理なので、ユーザー企業においてDXに取り組むリーダー層に最低限、理解しておいてほしいことを記載しました。なるべく理解しやすいように時系列に沿って技術の課題と解決の順に記載し、それらの解説と、実際にユーザー企業が取り組むために注意すべき点や参考になる情報を併記しています。
「車の運転をするのに、車の構造なんて知らないでいい」という人は読まないでいいです。カーレースで戦って勝ちたいなら、車の構造を理解しているべきです。現代のビジネスというレースで戦うなら、テクノロジーを理解していなくてはなりません。それを放棄するならDXなんか無理です。
経営層への意識改革に向けた提言がないとか、アジャイル文化への言及が足りないとか、そんなのは当たり前です。そんなことを言ってる暇があるなら、目の前の取り組みを少しでも進めて具体的な成果を出し、経営層にテクノロジーの価値を見せつけてやればいいのです。経営の意識改革や組織文化の変容なんか待っている暇はありません。
いくつかの事例も記載していますが、登場するユーザー企業は特に「アジャイル」とか「マイクロサービス」みたいな言葉にこだわらずに導入を進め、結果として、その価値を感じています。大事なのはビジネス成果です。それがあれば、経営の意識も組織の文化も変わります（少しずつですが）。
たとえば、スクラムガイドの誤謬
アジャイルも導入を間違えやすい技術です。アジャイルの文化へのリスペクトは大事ですが「組織がアジャイルにならないと、アジャイルは活用できない」とか言ってたら、いつまで経ってもアジャイルは活用できません。
1つの阻害要因はアジャイルソフトウェア開発宣言やスクラムガイドにあります。僕自身、何度も読んだし、良いこと書いてあるなと思いますが、日本企業がアジャイルを実践するための知恵や知識は書かれていませんし、場合によっては悪影響の言葉があります。
たとえば、スクラムガイドの以下のように記載されています。
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければならない。
内容には同意しますが、日本の組織においては実践的ではありません。むしろ「現場に権限委譲できない組織ではスクラムは機能しない」という言い訳を生み出すのです。本当に権限委譲できるならやればいいですが、日本企業においては権限委譲という言葉の裏で、一緒懸命な若者が部署間調整に疲弊するだけです。
そんな言い訳をしている暇があるなら、現実に向き合って、実践的に解決したほうがいい。私の推奨は、プロダクトオーナーを中心に組織内調整を支援するチームを作り、組織的決定を導くためのプロセスやルールを整備することです。
「それはスクラムではない/スクラムの範疇ではない」と言う人もいるでしょう。確かにスクラムガイドが推奨する考えとは違う方向です。「公式なスクラムじゃない」という意見にも同意します。でも「組織としてスクラムという素晴らしい仕組みを活用するにはやったほうがいい」ことです。それが「公式なスクラムか」なんて細かい話は僕にとってはどうでもいいです。
