昨今、メガバンクと言われる銀行を中心に、情報システムの不祥事が頻発しています。
私のような門外漢でも、２０１８年に経産省が指摘したとおり、既に日本は「2025年の崖」へ転落し始めたと、危機感を感じています。
崖っぷちにある何かにしがみつこうと思って上を見上げても、今にも枯れそうで頼りない雑草の葉っぱくらいしか見当たりません。
このメガバンクの現象は、２０１８年に経済産業省が指摘した通りの状況になっているようです。
（エリック・ストルターマン教授が提唱した概念を、日本向けにわかりやすく定義したものが2018年に経済産業省が2018年12月に発表した「デジタルトランスフォーメーションを推進するためのガイドライン（DX推進ガイドライン）」。）
「DX を本格的に展開していく上では、そもそも、既存の IT システムが老朽化・複雑化・ブラックボックス化する中では、データを十分に活用しきれず、新しいデジタル技術を 導入したとしても、データの利活用・連携が限定的であるため、その効果も限定的となって しまうという問題が指摘されている。
加えて、既存の IT システムがビジネスプロセスに密 結合していることが多いため、既存の IT システムの問題を解消しようとすると、ビジネス プロセスそのものの刷新が必要となり、これに対する現場サイドの抵抗が大きいため、いか にこれを実行するかが課題となっているとの指摘もなされている。
「2025年の崖」とは、このレポートで用いられている言葉ですが、日本企業がこのままDXを推進できなかった場合の経済的な損失を、最大で年間12兆円と算出しています。これはあくまで「年間」であり、2025年以降毎年12兆円もの経済損失が生じるとして、経済産業省は強く警鐘を鳴らしていたのです。
でも、この提言は本当に「笛吹けど、踊らず」だったのでしょうか？
私には、経産省の他人事のような対応としか思えません。誰も耳を貸さないような小さな音で、「DX、DX・・・」と囃し立てていただけではなかったのではないでしょうか？
本当に経産省は自国のこととして心配して、危機感を持って行動をしていたのでしょうか？
年間12兆円もの経済損失の発生する理由を、経済産業省は、「レガシーシステムに起因するシステムリスク」と端的に説明しています。
DXを進められなければ、現在使用しているシステム＝レガシーシステムが2025年以降も残り続けることになります。
経産省のレポートをもう少し詳しくみてみますと、
2014年段階でデータ損失やシステムダウンなどのシステム障害による損失が国内全体で約4.96兆円にのぼるとの調査結果をベースにしています。
レガシーシステムに起因するシステムトラブルが全体の約8割であるとして、現在（2018年当時）の段階でも「4.96兆円×8割＝約4兆円」の経済損失が発生すると推定していたようです。
そのうえで、企業の基幹系システムの稼働年数を調査した報告書の内容から、2025年段階で21年以上システムが稼働している企業の割合を60％と見積もっています。この点を踏まえると、レガシーシステムによるシステムリスクも現在の3倍に上昇するとして、2025年以降の経済損失額を年間で約12兆円と推定したのです。
この経産省の警告ですが、世界の潮流からすると全く遅れた内容です。
それでも、それをまともに受け止めてカイゼンしようとしないのが、日本企業の実態なようです。
その他の企業からの問題も早晩顕在化してくるものと思われます。
サイバーセキュリティの問題も、すでに大きく顕在化しています。
２０２２年２月末、トヨタに内外装部品を提供する小島プレス工業（愛知県豊田市）がサイバー攻撃を受け、同社のシステムに障害が発生した。この影響により3月1日の丸1日（2直分）、トヨタが国内に有する全ての完成車工場（14工場28ライン、日野自動車の羽村工場とダイハツ工業の京都工場を含む）が稼働を停止。約1万3000台の生産の遅れが発生した。
日本の製造業は今、ハッカーから狙われていると言っても過言ではない。全般に「セキュリティー対策が甘い企業が多い」（専門家）と見られているからだ。
今回、小島プレスが受けたのはランサムウエア（身代金要求型ウイルス）の攻撃。だが、日本の自動車業界では2020年6月にホンダが同じくランサムウエアの被害を受け、「国内外の9工場」（同社）の生産が一時停止する事態に見舞われた。
「ホンダの事件は大々的に報じられたため、他の日本の製造業はランサムウエアの危険性を十分に認識できたはずだった」（専門家）。にもかかわらず、日本の自動車業界で同様の事件が発生してしまった。（2022年3月8日 日本経済新聞）
日本では、コンピュータソフトの開発プロセスが従来型のウォーター・フォール型と呼ばるもので、元請企業がコンセプトを設定し、それを下請、孫請、曾孫請企業へと発注し、相当な長い時間をかけて、一つのソフトを完成するやり方だと聞いています。
これは、ゼネコン方式と非常に似通ったやり方です。
このやり方の欠点は、基本条件の変化に対して柔軟な対応ができない点にあると言います。
そこで、アジャイルという名の柔軟すぎるほど変更ができるプロセスを採用したというのです。
アジャイル（迅速に）という意味は理解できるのですが、この方法はやり直しが多すぎるので、私は評価していません。
今日ソフトウエア開発は、アメリカのカーネギーメロン大学をはじめとして、国防総省が中心になって先進の開発プロセスが進められています。
DevOps更には、DevSecOpsというプロセスに進化しています。
Dev: Development
Sec: Security
Ops: Operations
ソフトウエアの世界は、Securityが非常に重要になっていますので、開発段階からSecurity重視で進められています。
アジャイルは比較的小規模なシステムには対応できますが、大規模システムには向いていません。
なぜDevSecOpsが必要かという理由は、タイミングと開発のペースが重要であるからです。さらに、セキュリティの基本的な考え方も必要です。
ですから、セキュリティ内蔵型（Baked-In Security）のソフトウェア開発が必要になります。
このような世界の潮流から見ると、日本の大手ベンダー任せのゼネコン式のソフトウエア開発はすでに時代遅れになっています。
私はソフトウエア開発に関しては全くの門外漢ですが、「開発プロセス」という抽象度で眺めてみると、DevSecOpsでは、フロントローディング、モジュール化、自動化などがキーワードとなっており、共通点を多く見出すことができます。
Amazonなどは、１日に何千回とソースコードを自動でカイゼンして書き換えているそうです。
例えば、設計プロセスの自動化（IT化）という事例で見てみると、下記のような教訓が見えてきます。
設計プロセスは下の図のように、顧客からの要求情報を、営業⇨設計⇨資材調達⇨製造にような順番で加工して、物理的な製品に仕上げて納品します。
無駄のない開発は、黒い矢印の流れのように繋がって、それぞれの工程が、前工程情報にムダなく付加価値をつけていき、最終的に顧客の要求通りの製品が仕上がっていきます。
このようなプロセスなら、すぐに自動化ができます。
しかしこ、赤い矢印のように問い合わせなどで、情報の流れが遡ってしまうようでは、必ずムダが存在しています。これらは、すべてやり直しです。
具体的には、前工程からもらった情報の不明点を聞き返えしたり、もらった情報が間違えていることで、手戻りが発生するというような問題があります。
このように仕事の流れをカイゼンせずにそのままにして、途中のプロセスのみをアプリケーションソフトに置き換えようとしてしまうことがよくあります。
安易な自動化はしない！
問題を全て出し切ってから自動化する！
主なプロセス自体はIT化により、迅速な処理ができ流かもしれませんが、プロセスの繋ぎ部分で必ずやり直しが発生します。全体としては、ソフトのお世話係の仕事が増えてしまいます。
問題は赤い矢印です。この赤い矢印の原因を追求して、完全に取り去ってしまわなければ、どんなに良いソフトを使っても、やり直しがなくなることはありません。