説明コストの大きさが文化資本の質の差を生む　開発体験の良さと企業のデジタルトランスフォーメーションのつながり

2つのDXは両輪でつながっている

このダイナミックケイパビリティの文脈でDXを語ることが、最近増えてきています。それは『ものづくり白書』のことだけではなく、こういった論文にも出ています。デジタルトランスフォーメーションとは、組織の日常生活の中で新しいデジタル技術を活用する継続的なプロセスである。組織のビジネスモデル、協調的なアプローチ、文化の変革の中心となるメカニズムは、アジリティであるようなことが語られています。

「これってもしかして？」……。ダイナミックケイパビリティとして語られる話と、ソフトウェアエンジニアリングの中で出てくる文化資本として語られる、心理的安全性、フロー効率性、マイクロサービス、DevOps、うんぬんかんぬん……。これはとても類似した概念です。

こういった開発者体験に注目しながら僕はこのようなイベントもしていますが、いろいろと思うところはあります。デジタルトランスフォーメーションという言葉を出している企業で、開発者体験があまり良くない状況だったりすると、「これはデジタルトランスフォーメーションできないんじゃない？」と、いろいろな会社を見ていると思ってくるわけです。

でも、開発者体験が悪い環境ほど危機感を覚えていて。2つのDXは、実はつながっているものなのに、それらが分断されて理解されていることに僕は違和感を覚えて、「実はその2つのDXは、両輪でつながっています」と伝えて、開発者体験の良さと企業のデジタルトランスフォーメーションという、非常に重要なつながりを持っている2つのDXというメッセージを展開するに至っていきます。

労働人口の1.6%しかいないソフトウェアエンジニア

「プログラミングをできなくても、専門職に任せればいいよね」みたいな話もよく出てきますが、プログラミングという活動へのニーズは次第に高まっている。どんどんニーズが高くなっています。似たようなことで、4000年ぐらい前は文字が書ける人が限られていて「専門職に任せればいいね」という時代がありました。古代エジプトの書記官がそうだったそうです。

非常に高級でレアな人たちで、体験の記録などが残っています。倍率が高く、みんな勉強したいと思っていたものの、「文字は難しいよね」みたいなことを言っていたらしいです。それは現在のソフトウェアエンジニアと近くて。今、文字はみなさん書けるんじゃないかなとは思います。

このように、100年後からしてみたら「ソフトウェアエンジニア、ソフトウェアに関わる、コンピューターに指示が出せる人はそんなに少なかったの？」と。実は今、エンジニアは日本の労働人口の1.6%しかいなくて、さらにソフトウェアエンジニアになってくるともうちょっと少ない状況なので、こんな状況でいいのかなと。

ダイバーシティが重要になる理由

どんどん人口が減り、私たちは効率を求めて生産をしていかないといけない。こんなときに、コンピューターはどんどん安くなって利用しやすくなっている。

旧来型の組織は何でもかんでも人でやっていたから、その部署にいて長いこと経験を積んで、書類の書き方などを覚えて何かすることがけっこう当たり前でした。しかし、徐々にそれが機械で簡単に行えるようになってくると、それらはコンピューターに任せ、人には一段上の、ちょっと抽象的でクリエイティブなことが求められるようになってきます。

そうすると、今まで部長や課長に求められていた役割と同じぐらいの意思決定やクリエイティビティが、一般の現場の人たちにも求められるようになっていきます。その結果、いろいろなスペシャリティの人と対話をしながら仕事をすることが当たり前になってきます。これが「ダイバーシティが重要」という話をする背景です。

ソフトウェアとコンピューティングの取り扱いは経営学である

「ワークスタイルをシフトさせましょう」「働き方改革をしましょう」みたいなことを近年言われることがあります。このワークスタイルのシフトは置き換えられた結果、人の仕事が変わってきていて、それに合ったかたちに組織も書き換えなければいけないことになった。

官僚型の職能別組織から全体論的多様性のあるチームになったり、コマンド＆コントロールの目標管理から、権限委譲と透明性のあるOKR型の目標を持ったり、メンバーシップ型の人事制度からジョブディスクリプション型の人事制度に変わっていく必要がある、というようなことが言われるようになってきました。これは人がレアになり、コンピューターがコモディティ化していく中で、避けられない変化だと考えられます。

マネジメントに求められるものも、人に指示するスキルから、人と共創し、コンピューターに指示するようなスキルに変わっていくするわけです。

こういったソフトウェアとコンピューティングの取り扱い方は、もはやその技術論だけで語られることではなく、経営学だということが、僕が前著からずっと伝えたいメッセージです。そこを理解して、日本や世界がコンピューターをうまく使ったビジネスの展開ができるようになるといいなと思っています。

説明に費やされるコストの差分が文化資本の質を決める

でも組織の文化としてソフトウェア作りが定着する前に、日本の大きな企業や行政機関は、いろいろなものをユーザー企業が丸投げしてしまったりするので、このノウハウが消失してしまいます。ソフトウェアを作ることが、どういうことなのかを理解する間もなく、徐々に消えていってしまう。

一方で、いい文化資本が蓄積する企業や、ソフトウェアエンジニアリングの文化資本、開発者体験を高めていくさまざまな工夫がどんどん蓄積していく環境の会社には就職したいと思ったり、自分のスキルアップになるんじゃないかと思うエンジニアが多い。そうじゃない会社は不遇な目に合うかもしれないし、嫌な思いをするかもしれないので、就職するのは止めておこうという気持ちになったりします。

こういった差が生まれるのは、文化資本の獲得をする際に、説明・説得に費やされるコストの差が、やはり大きいのではないかなと思っています。当たり前のように自動テストを書くことが習慣になっている会社と、「なんでそれをやらないといけないの？　CIのツールはなんでそれを使わないといけないの？」と、いちいち説明・説得に費やされるコストがかかる会社は、なかなか定着していきません。

説明責任のズレと合理性

何かやりたいのなら合理的に説明するという責任があるにはあります。しかし、実はその説明責任をどちらに求めるのかに関しても、非常にバイアスがかかる部分です。例えばPCのスペックであれば「採用競合に比べて悪くする理由」の説明を求める上司なのか、「去年に比べて高くする理由」の説明を求めるかによって、無意識な上長の選好、好き嫌いの部分が説明責任の方針に反映されてしまう。

合理的な説明を求めることに対して、何の認知も歪みもないと錯覚している人がしばしばいますが、何に対して合理性を求めるかは、実は権力の構造が内包されています。「なんでその説明を求めるんだろう」と、最適化していってしまうと、ソフトウェアエンジニアリングの文化資本の獲得の方向はどんどん変わっていってしまうわけです。

例えばCIにしても、「『どういう観点でCIツールを選べば』とか、『自動テストを書けばテストが技術的負債になりにくく、かつ効率的にスピーディーに開発を進められるか』を説明できるような観点で、1つのCIツールを選んでみてね」という話をすればいいところを、逆に「テストをしたから効率が良くなるって説明してよ」のようなところになると、ずれてしまいます。

例えば月額4,000円の新聞を当たり前に読む家と読まない家があって、新聞を読むことが合理的で、読まない家が合理的でないことを説明するのは、非常に大変です。

この種の良い習慣は、常に合理的に説明できるわけではありません。CI/CD、ユニットテスト、最近だとContinuous TrainingやContinuous Modelingのようなことも言われますが、今では考えられない。かつてはユニットテストを書くべきか、書いたほうがコストはかかるかの議論がありました。今でも場所によってはそんな議論が存在する。しかし、今では馬に乗って通勤する人がいないぐらいに常識的なことになりました。

これはユニットテストを書くことが常識になり、過剰なほどテストに工数を費やさずに済むことになったことで、快感的なメリットが理解されていった。

かつてはプログラマーが使う端末が貧弱で、キーボードも選べなかった。今は、陸軍に竹槍を持たせる人がいないくらいに、ちゃんとしたスペックのものを持たせるのが重要になってきました。人的資源の価値が、他の業種よりも生産性に劇的な差をもたらすため、コストではなく、競争優位で比較するようになっていったわけです。

かたちから入っても習熟すれば高いレベルになる

今になってみたら説明できる習慣は多々ありますが、説明することがなかなか難です。だから、かたちからでも入る必要がありますが、体験したことがないのに良いもの・悪いものは難しいです。スクラム、ペアプロ、DevOps、IaC、トランクベース開発、犠牲的アーキテクチャ、うんぬんかんぬん。

これらは、実は多くの場合、かたちだけ真似しても意味がありません。ソフトウェア工学で、ある種の習慣に価値があるかどうかを対照実験することは非常に難しく、成果が出ないこともありました。例えば、TDDを慣れていない人にTDDをやらせて、そうでない場合と比較して優位な差が出ないどころか、マイナスになることは想像に難くないわけです。自転車は乗り始めから走るより速いわけではありません。

しかし、TDDに習熟したチームは生産性が高くなるなと経験的に知られている。これはかたちから入ったとしても、目的を持ってやり続ければ習熟し、高いレベルになるということでもあります。そのため、自明ではないし、すぐに効果があるわけでもない習慣をうまく取り入れていきながら、自分たちにフィットしたかたちに変形していくことや、自分たちにフィットした体感を持って開発者体験につなげていくことが、文化的な資本につながっていくわけです。