昨年9月に経済産業省から公開されたDXレポートを読みました。
https://www.meti.go.jp/press/2018/09/20180907010/20180907010.html

DX（デジタルトランスフォーメーション）レポートは大学の先生と大手ベンダ関係者が主体のチームが議論して作ったようで、DXレポートに整理されている「現状と課題」は実際の企業現場の状況が十分に反映されていないのではないかと思います。

守秘義務問題もあるので細かい事例等まで例示するのは難しいですが、私が感じる各項の気になるポイントを列記します。

2.2.1　DXの足かせとなっている既存システム
DXレポートのレガシーシステムの定義ははっきりしませんが、現状で業務遂行や業務改革の足かせとなっているシステムとして相談が多いのは、メインフレームやＡＳ４００のようなオフコンではなく、オープン系のPKGシステム利用者からの方が圧倒的に多いです。PKGユーザからは「アーキテクチャーの陳腐化」「ベンダサポート停止」「時代遅れの管理ロジック採用」「データ利用の制限」などの相談が多く寄せられています。

2.2.2　既存システムの問題点
既存システムのブラックボックス化はスクラッチ開発システムだけではなくPKGでも同じ状況にあります。PKGベンダがなくなったり、サポート停止したり、開発ドキュメントを保存していないケースもあります。

また、9ページの要件定義の問題は、エンジニアの能力だけの問題ではありません。業務管理システムの場合は設計段階で要件定義を確定すること自体そもそも不可能です。それがウォーターフォール型スクラッチ開発がもつ最大の課題です。

2.2.3　既存システムの問題点の背景
有識者の退職によるノウハウの喪失は、ユーザ企業以上にベンダの方が深刻です。PKG開発が一般的になって以降、業務分析に関する知識を保有しているエンジニアが減っており、ベンダとユーザのコミュニケーションが十分にとれずにトラブルに発展するケースが多発しています。とくに生産管理はユーザがシステムに魂を入れる必要があります。他のシステム開発とは異なりプロセスフロー分析やデータ分析だけでは不十分で、マスタ値の設定がより重要となります。しかし、このことに対する両者のコミュニケーションギャップが業務運営に支障を起こすことがあります。

また、11ページのPKGならば同様のノウハウを持つ人材は世界中に存在するは何かの勘違いです。業務ノウハウは各企業の置かれている環境によって変わりますので、そうした人材を外部から探すことは不可能です。たとえば同じ自動車部品でもトヨタ向けと日産向けでは業務プロセスは大きく異なります。

2.2.4　既存システム問題の難解さ
12ページの訴訟に発展しやすいのは、取引先の要求に合わせた業務を必要とする企業がPKGで対応しようとしたときに対応できないケースで起きやすく、その背景として問題になりやすいのはRFPではなくフィットギャップ分析です。フィットギャップ分析で、大きなギャップがあるのが見つかったのにPKG利用を取り下げないベンダに非があるケースが多いです。ただし、この問題は当該PKGを選んだユーザ企業にも問題があります。

なお、私はそもそもRFP作成自体が時間とカネのムダと思っています。

私が専門としている生産管理システムではMRPロジックが日本の工場にあわないことによるトラブルが多発しています。この問題に関しての解説は拙著「誰も教えてくれない生産管理システムの正しい使い方（日刊工業新聞社）」に書きました。

14ページの技術的負債は、ユーザ企業でも問題になっていますが、それ以上に安易にSESによる下請け開発体制に依存したベンダ企業側の方が深刻です。継続サポートのできないPKGも急増しています。

2.3.1　経営者の危機意識とコミットにおける課題
経営者の問題では、最近流行に踊らされたトップの安易な指示でERPを導入し、納期遅れや生産ストップといった問題を起こす大企業工場が増えており、そんな工場から相談を受けるケースがよくあります。

2.3.2　CIOや情報システム部門における課題
トラブルが起きるとベンダの責任というのは過去の話です。最近はベンダのトラブルリスク対策の方が進んでおり、ユーザ側が泣き寝入りするというケースの方が増えています。

2.3.4　ユーザ企業におけるIT人材の不足
人材不足はベンダ企業の方が深刻ですが、SES依存による工数商売中心のベンダ企業はそれに気付いていないようです。私はJUAS殿や日刊工業新聞社殿で生産管理システムの有償研修を実施しています。大企業、中堅企業、情報子会社からは多数の関係者の参加をいただいていますが、SIベンダのSE参加者はほとんどいません。これで彼らがどうやってユーザ企業のサポートをするのか疑問です。

2.4.2　ユーザ企業とベンダー企業の責任関係
そもそもベンダー企業がフィットギャップ分析をした段階でギャップを理由にPKG採用を断らないことが最大の問題です。さらにマスタ設定やテスト作業などのユーザ作業に関するプロジェクト管理責任問題があいまいなこともトラブルを誘発します。

2.4.3　アジャイル開発における契約関係上のリスク
アジャイル開発は組込みソフト開発のような少人数のエキスパートで行う開発用の手法で、多数のユーザ関係者が参画する業務開発システムには適していません。これはJUASからも調査結果にもでていると思いますが、なぜこうした勘違いをしたのでしょうか。

この項でいいたいのはアジャイル開発ではなく、超高速開発ツールを用いたプロトタイプ開発（もしくはRAD開発）の勘違いではないかと思います。

2.5.3　ベンダー企業における人員の逼迫、スキルシフトの必要性
業務管理システムを使いこなすための業務管理知識の必要性が抜けています。たとえば生産管理システムを活用するには最低限の生産管理理論に関する知識が求められます。

2.6.1　既存システムの残存リスク
現在企業で大きな問題となっているのは、マイクロソフト製品やPKGのサポート切れ問題です。この点はメインフレームの方が安心だという声がきかれます。

2.6.2　既存ITシステムの崖
なぜかDXレポートで触れられていませんが、現在企業で大きな問題となっているのはEXCEL利用リスクです。PKGの機能不足などを理由に大企業の部門独自のEXCEL利用が急拡大しています。これはまさに「ブラックボックス化」「特定個人依存」「メンテ不備」「データ連携不備」といったレガシーシステム問題で挙げられている問題そのものです。

RPAのような小手先の逃げ道がもてはやされていますが、EXCELの過度な利用とそれに伴うEXCELリスクが放置されていることDX化に向けた最大の課題にすべきです。DXレポートにEXCEL問題の言及が全くないのはなぜでしょうか。

このことだけでもDX検討メンバが現場のIT利用の実態を知らないことの証ではないかと思います。