このブログでは、時々IT系メディアのニュースを批判しています。特に、中身の薄い記事を平気で配信してくる場合には厳しく批判してきました。想像するに、記事を書く記者は泥をかぶり汗と恥をかきながらシステムを構築した経験がないのでしょう。レガシーシステムを批判する彼らですが、何十年もの間、その時々で利用可能な技術・製品を使って情報システムを作ってきた歴史を知らずに（調べずに）、何を聞きだそうとしてどの様な質問をし、得られた回答に更なる質問をして背景を理解し、事実を確認したか？と聞きたいものです。
情報システムが給与計算など一部業務のコンピュータ処理から、処理の対象となる業務が広がってきた経緯、そして全社全業務を包含する統合情報システム構築の必要性がうたわれ、経営を支援する戦略情報システムという概念が出てきた背景を理解しているのだろうか？戦略情報システム構築を指揮する情報システム担当役員（CIO）が出てきた経緯も知っておいて欲しいものです。初期には、そのCIOの位置づけが理解されずに、経理部長や人事部長、総務部長などが兼務したり横滑りした時代もありました。重大トラブルが続いたみずほ銀行のCIOは適材適所ではなく、適不適を問わず人事畑出身者が就任する指定席になっていたそうです。IT系専門誌の記者なら、こういう背景も理解しておくべきでしょう。
また、ブームに対する対応も調べておくべきでしょう。古くはOA、ERP、SISがあり、10年くらい前からはクラウド、ビッグデータ、データサイエンス、AI、そしてDXなどがあり、その都度起こるこの種のブームに迎合した上っ面な提灯記事を見ることが多々ありました。参考にされるIT系専門誌の記事を書く記者だったらブームの起こった背景を分析して欲しいものです。センセーショナルなキャッチで興味をひき、読んでもらえばOKという薄っぺらなことでは困ります。
今や、都知事３選を目指して立候補した小池さんが自治体DXと言い、厚労大臣の武見さんが医療DXで医療界を動かすと言ってしまう、猫も杓子もDXDXの大合唱です。
ブレーンと称する取巻きが、スローガンとして挙げておいた方が良い、話しをしておいた方が先見の明を持っていると思ってもらえると入れ知恵をしたのかもしれませんが、意味を理解して発言しているのかどうかは大いに疑問です。
で、そのDXですが、日経BPから配信されてきたものに、こんなものがありました。
さんざん、ローコード、ノーコードの開発ツールを紹介し、成功事例を喧伝しまくっていた日経BPが『いきなりツールを導入するのは最悪』とのこと。いや～参ったなぁ～！書いた記者は、日経系のIT雑誌が何を書いてきたのかを検証したのでしょうか？
DXブームに乗せられ、必要性を吟味せず、既存システムとの整合性も考慮せず、会社としてのシステム整備方針もなく、全体を俯瞰したスケジュールもなく、システムとは名ばかりの身の回り＆当面の作業をパソコンで動かす事例が多数紹介されてきました。専門部署や外部業者に頼んでいては、時間も費用も掛かるので、ノ－コード、ローコードを使って自分でやりたいことをパソコンでやってしまおうということですが、ブームを煽るテレビのCMも見かけます。
豊川悦司演じる部長が、自ら画面を操作し、必要とする視点の情報分析をする機能を作ってしまうというものです。
それで良いのか？というブログを書いたこともありますが、それは過去のOAブームや、EUC／EUDブームを経験しているからです。この時何が起きたかは、調べれば誰でも分かります。簡単に言えば、人事異動でローテーションされた人が作ったメンテされない野良アプリが溢れてしまったということです。もちろん、仕様書とか他のシステムとの接続仕様書などはありません。その前に、その様々なツールを使って作った局所的アプリが、当該組織、企業全体のシステムから見て、どの様な位置づけにあるのかの全体像が見えないまま、気が付いたところ必要になったと思うところをノ－コード、ローコード開発ができるツールを使って作るわけです。OA（office automation）どころか、PA（personal automation）です。もちろん、PAでも構いませんが、それがどうして野良になってしまうのかです。便利な局所的最適解のアプリは一過性だったということです。
企業経営を情報システム面で支えるのが戦略情報システム（SIS）ですが、その構築方針は、ISA（information system architecture）と呼ばれるものです。この方針に従って、予算、開発規模、重要度、緊急度、開発力を勘案して順次整備して行く進め方を採用することが必要で、それを主導／指揮するのがCIOです。その様な見識を持ったCIOがいればいいのですが･･･どの様に進めれば良いのかを順番を以下に。
①ISAが定められていなかったら、最初にこれを作る
②当該組織、会社のシステム全体像を描く
③システム化スケジュールを作る
（既にシステム化している部分、非システム化部分の明確化）
④今回システム化対象業務・作業の選択
（予算、開発規模、重要度、緊急度、開発力を勘案）
⑤業務分析
⑥無理無駄の発見
⑦無理無駄とされた業務、作業を担当していた部署、人に説明
⑧無理無駄以外の残った業務・作業のシステム化検討
⑨情報システム部門が担当するもの
⑩ツールを使って現場がやるもの（現場にやってもらうもの）
⑩まで来て初めて、ツールの出番です。今までのようなHowtoが全面にでたDXでは整合性の取れない個別最適化の野良アプリの残骸の山が出来上がってしまうでしょう。
※質問はosugisama@gmail.comにどうぞ！
※リブログを除き、本ブログの無断転載、流用を禁じます。