今や、付和雷同にDXブームに乗せられ、製造業ＤＸ、自治体ＤＸ、医療ＤＸ等々、業界業種を問わず××ＤＸブームです。ＤＸについては既にこのブログで取上げていますが、何十年か前、経営を情報システム面でサポートするというＳＩＳ（Strategic Information System）という言葉やＳＩＳを主導する役割を持つＣＩＯ（Chief Information Officer）という言葉と共に、ＩＳＡ（Information ｓystem Architecture）という言葉がありました。ＤＸはこのＩＳＡと同じコンセプトと思って間違いありません。昔のＩＳＡを知っている皆さんは、ＤＸという新語が出てきても付和雷同に慌てることはないでしょう。強いて当時との違いはといえば、利用可能な技術、製品、有形無形な環境でしょう。今と昔の違い･･･例えば、ネットワークが当たり前になり、処理能力の高いパソコンと様々なソフトウェアが安価で出回り、無線環境が充実している点です。
以上を理解したうえで、（必要性があるのかないのか分かりませんが）ＤＸブームで開発需要が急増して開発作業が間に合わない状況になり、外部のＳＩｅｒも開発需要に応じきれない状態になっていることから、内製化を図る動きがあります。もちろん自社のシステム部門をフル活用するのは当然ですが、出来合いの業務パッケージばかりを導入してきたつけで、システム部門に自主開発能力がない場合があります。業務も分からないし、開発能力もないシステム部門では役にたちませんが、現状はそのようです。そこで短期間で習得できるというローコード開発という発想がでてきました。なかにはローコードではなく全くプログラムを書かないで済むというノーコード開発などというものまででてきました。業務を知らないシステム部門に対して実際に仕事をしている業務部門要員は作業内容、作業手順、必要な情報を知っているので、その記述方法（プログラミング）さえ分かればシステムができあがります。少しの訓練でその記述方法を習得すればＤＸの開発需要をまかなう戦力になるかもしれません。
しかし、少し考えてみましょう。このブログをご覧になっている皆さんは理解されていることと思いますが、内製化の潮流に乗って現場の皆さんがシステムを作るようになったらどうなるでしょう。会社（組織）全体として収拾がつかなくなってしまうことは自明です。そうです、ＩＳＡというシステム整備方針に沿っていなければならないし、ユーザインターフェイスも統一しなければなりません。もちろん、現状の仕事の仕方をそのまま映しとるような現状是認型のシステムではいけません。この辺はこのブログで幾度となく書いていますが、システムの仕様を作る前にＢＰＲしなければなりません。すなわち、業務内容を記述する便利なツールが出てきても、それだけではシステムはできないというか作ってはいけないということです。
ＯＡがブームになったのは昭和５７年前後からですが、趣味ではなく実用に供することができる機能、性能を持ったパソコンが普及し始めた頃、それを使って身の回りの仕事を処理させてみようという動きがありました。ＥＵＣ（End User Computing）や、ＥＵＤ（End-User Develpoment）といわれるものです。Basic言語や表計算ソフト、パソコン向けデーターベースなどが出回り、『ちょっとやってみる』ことができる環境が出てきたことが背景にありますが、いちいちシステム部門に頼まなくても身近にあるパソコンで処理できる便利さが受けて、このＥＵＣ、ＥＵＤがブームになりました。仕様書を作って作るのではなく、自分で理解できれば良いというメモ程度もので作られるものがほとんどだったこのＥＵＣ、ＥＵＤで作られたものが、仕事の仕方の変更があったときのシステム（プログラム？）への反映や作った人が移動したりすると誰もメンテできないという弊害がでてきました。そもそも目の届く範囲しか考えていないので、変更に強いとか先を見越してパラメタにしておく等と言う作り方になっていなかったわけです。当初、便利なものができた！ということで受け入れられ、このＥＵＣ、ＥＵＤですが、間もなくして忘れ去られました。それはシステムではなく、いわばＰＡ（Personal Automation）だったということです。
今回の内製化ブームで自社内で作ることになり、それを支援するツール類が出てきたのは結構なことですが、ＥＵＣ、ＥＵＤの二の舞にならないように気を付けなければなりません。それを避けるには･･･順不同で列挙すると以下のとおりです。
①ＩＳＡを策定すること
②作る前に業務を見直すこと
③利用可能な機能を公開すること
④使っている情報（データ）を公開すること
⑤既存のデーターベースの情報は参照するだけで更新しないこと
（やむを得ず行う場合は、関連する他部門を交えてデザインレビューをすること）
⑥ローカルに（勝手に）データーベースを作らないこと
⑦仕様のデザインレビューをすること
⑧作ったシステム（プログラム）の使い方を公開すること
⑨他システムとの連携を前提とせず、単独で動くこと
（やむを得ず行う場合は、関連する他部門を交えてデザインレビューをすること）
⑩作ったシステム（プログラム）を責任を持って保守・管理すること
※質問はosugisama@gmail.comにどうぞ。
※リブログを除き、本ブログの無断転載、流用を禁じます。