「市民開発」情シス部門の役割[20240911]
今週は、情報システムの「市民開発」について話していきたい。
「市民開発」とは、情報システム部員ではなくユーザー部門が自身で業務用アプリケーションを開発することを指す。
「ノーコード」「ローコード」と呼ばれるツールを利用して市民開発を実行するのである。
ノーコードと呼ばれるツール、十分に使用に耐え得るローコードツールと、様々な選択肢が出てきた。
「どの製品を使えば良いですか? 」
こういうご質問も多いが、個別にご相談にのらせていただきたいと思う。
企業によって状況がいろいろと違うので一概に「コレが良い」とは言えないからだ。
どうぞ、ご遠慮なく弊社までお問い合せいただきたい。
さて、今日の本題に入る。
EUC時代に最も問題になったのは「データ」である。
「データをEUC環境（PCやW/S）まで、いかに持ってくるのか? 」が結構な問題になったのだ。
更に問題になったことがある。
EUC環境にて作成されたデータを「ホストやサーバーにアップロードしたい」というニーズだ。
私の情シス時代に経験したEUC推進の時には「想定の範囲内」だったのだが、アップロードというニーズが意外に多くて驚いたものだ。
まずは、データを如何に準備したのか?
現在の市民開発環境下ではもう少し上手なやり方があるのだが、基本は変わらないので紹介したい。
情シス管理下のデータベースから（EUC環境下で新設された）ローカルサーバーにオンデマンドでデータファイルをセットしたのだ。
当時は残念ながら、情シスが手作業でターゲットファイルを作成してローカルサーバーにセットするという作業をしていた。
しかし、EUCを円滑に進め、情シスの運用チームも前向きに取り組んでくれたため、申請書が上がってきてから翌日にはデータファイルがセットされた。
いちいち申請書ベースだなんて古臭いと言われそうだが90年代半ば頃の話なのでご容赦願いたい。
データファイルを作るのにはいくつか留意点があったため、申請書ベースにしたのだ。
（１）機密情報がダウンロードされないこと
（２）漢字コードをS-JISなどEUC環境で扱えるようにすること
（３）データファイルがEUC環境で扱える大きさにすること
当時のEUC環境は、こういう基礎的な課題を解決しなければならなかった。
というわけで、手作業でデータファイルをセットするというところからスタートした訳だ。
大問題はEUC環境下で作成したデータをアップロードさせて欲しいというニーズを如何に対処したのか、だ。
まずは「アップロードして何をしたいのか? 」の調査から。
アップロードをしたい部署は、商品開発部門だったのだが、商品部に研究開発の成果としてデータを共有したいというものだった。
確かに、他の部署とデータを共有しようと思うとEUCサーバーが違うので簡単ではない。
しかし、EUC環境下で生成された成果を情シスが管理しているデータベースにアップするのは気持ちが悪い。
従って、商品開発部門のローカルサーバーと商品部のローカルサーバーを当該ファイルに限って共有出来るようにした。
しかし、これは「例外中の例外」として取り扱うことを納得してもらった。
データの取り扱いを間違うと「スパゲティ」状態を助長するからだ。
情シスやお抱えのベンダー（などのプロ達）にしても、他人が作ったプログラムを解析して修正するのは至難の業だ。
だからドキュメントを残す（はず）。
いやいや、ドキュメントがきちんと残っていることは「たいへん有難い」が、私の知る限り「ドキュメントに助けられることは極稀」である。
ちなみに、プログラムを修正したらそれでOKではない。
修正箇所が正しく動作するかどうかテストが必要である。
しかも、このテストは「新規開発」した時と同じかそれよりも多い項目数になるのが通例である。
新規開発時と同じかそれ以上のテストが必要なのは、概ね新規開発時よりも周辺システムとの関連性が高く（複雑性が増して）なっているためだ。
ほとんどが「データ連携」をはじめるからなので、データを如何に連携するのかを「ユーザーの言いなり」で作ってはならない。
情シス部門は「市民開発」を本格的に導入するためにかなりの「下準備」をする必要がある。
社内にある様々なデータを如何に取り扱うのかという「Data Principle；データ原則」を定めて厳に運用しなければならない。
実は、この作業が「めちゃくちゃ大変」なのだが、一旦出来上がってしまえばかなり合理的かつ経済的にシステム運用が可能である。
一般的なアプリケーションエンジニアの方には「何を言っているのかわからん」と言うことになっているかもしれない。
ただ、これ以上の細かい説明をここですると混乱するかもしれないので、個別にご質問を承ることでご容赦いただきたい。
合同会社タッチコア 小西一有