今日本では、DXという新しい言葉を、あちらこちらで頻繁に見掛けられます。
もう新しい言葉ではなく、急速に浸透したと思います。
DXという言葉を、Googleで検索してみましたら、日経X Techの「DX基盤でアプリ構築 コンテナを適所に使う」というタイトルが目に止まりました。
記事の中には、下記のような文章がありました。
「DX（デジタルトランスフォーメーション）推進に向けたプラットフォームやシステムアーキテクチャーが決まったら、その上でさまざまなアプリケーションをどのように設計、構築していくかを検討する。」
私にはピンと来ませんでした。
IT業界の方々は、ソフトを導入することが仕事ですから、わからないではないですが、
ITを活用しようと思ったら、まず対象の仕事を絞って、それを分析してカイゼンすることが基本です。
ITはあくまでも手段です。
これを履き違えている人が多く、このDXブームが去った後には、非効率な仕事がたくさん残ります。
ITソフトで対応できなかった仕事、ITソフトをサポートするような仕事が山のように、新たに発生することもあります。
最初は「どんな仕事でもITで置き換えることができます。」という売り言葉は、DXになって始まったわけではなく、コンピュータが一般に浸透する過程で、どれくらい使われたことか？
そして、それを信じて活動して来たのに、「こんなはずじゃなかった」ということになってしまいます。
カイゼンのプロセスをしっかりと踏まえ、必要だったらソフトを活用するという本来の立ち位置を忘れてしまいと、幾度となく繰り返してきた失敗をまた、積み重ねることになってしまいそうです。
メガバンクが、ITがらみの不祥事をたくさん起こしています。
１説によると、メガバンクは、合併を繰り返して大きくなっていますから、合併前の各銀行のシステムを統合するのに失敗しているようです。
元々、各社のソフトの作成を引き受けた、ベンダーの仕事のやり方が、旧態依然とした、ウォーターホール型だから、自由に変えるのが困難なのだと言われています。
建設業界のジョイントベンチャーのやり方と同じ方法で、ソフトウエアが作られているそうです。
元請会社が、仕事を分割して、それぞれの下請け会社に割り付けていくというやり方です。
元請会社が下請け会社を完全に掌握できていれば良いのですが、利権がちらつきます。
日本は元請会社の利権があるので、なかなかこの形態を改革することが難しいと言われます。
一方で、アメリカの国防省などでは、ソフトウエア開発の方法がどんどん進化していて、
Dev OPs、Dev Sec Opsという名前で言われています。
Dev Sec Ops=Development, Security, Operationですが、開発とオペレーションがかなり連携して、開発初期段階から、Securityを重視してプロセスを進めるというやり方です。
Dev Sec Opsは、Lean Product Developmentから始まった、アジャイルを経て、今の姿になりました。
GAFAMなどの巨大IT企業は、Dev Sec Opsを採用していて、一旦開発したソフトウエアを毎日カイゼンしているそうです。
Dev Sec Opsは、アジャイルと違って大規模なソフトウエア開発を扱っていますので、開発手法としてはかなり成熟した手法になっています。
Lean Product Developmentは、トヨタ生産方式をベースにして、製品開発方式を作りましたが、生産方式をベースにしたものですから、出来上がったものは、トヨタ製品開発とは違ったものになっています。
車の開発もある意味では、ウォーターホール式のやり方です。
このブログでも何度も取り上げている、チーフエンジニア（CE)をリーダーとした製品開発システムです。
CEが開発から販売まで、一貫して責任を持っています。
初期に構築したCE構想をもとに、プロパーの設計者だけでなく、関連メーカーの開発担当までを、プロジェクトメンバーとして、一体となって開発を進める方法です。
CE構想には、お客さまの要望を取り入れた製品仕様が明確になっています。
また、新規採用の技術の成立性についてもあらかじめ検討しています。
トヨタの製品開発は、会社の存続のための原動力になっています。
長い間、お客さまに受け入れていただいていることを見れば、これが有効な仕組みであることはお分かりいただけると思います。
トヨタ製品開発は、多くのお客さまの満足に支えられています。
Dev Sec Opsも、お客さまの要求仕様の変化に柔軟に対応していくことを目的としたプロセスです。
ジョイントベンチャーや日本のソフトウエア開発は、利権を守る意識が働いているように見えます。
顧客企業や官公庁などが相手なので、なかなかこの構造に変化が起きないのでしょう。