TouchCore Blog | 「市民開発」導入で変わる-情シスの役割と未来[File:20]
TouchCore Blog

「市民開発」導入で変わる-情シスの役割と未来[File:20]

「市民開発とは」についてあらためて説明をする必要はないかもしれません。
企業内の情報システムをIT部門やITベンダーではなく、ユーザー部門がローコード・ノーコードツールを用いて自ら開発することです。
背景は、もちろん、ローコード・ノーコードツールの発達もありますが、
一義には、迅速な問題解決のためのソリューションを開発することが求められる中、IT部門のリソースに依存していてはビジネスのスピードに追い付けないという危機感の高まりといえるでしょう。
情報システム部門は開発にかかるIT支出を爆下げでき、ユーザー部門は「人がいない」「予算がない」「時間がない」と待たされてばかりのストレスから解放されますし、IT民度も爆上がりするでしょう。
しかし、いまだに企業から市民開発導入に後ろ向きな声も聞こえてきます。
それは、市民開発によって現在の情報システムや情報システム部門はどう変わるのか、変わるべきなのかがはっきりと見えていないからなのではなでしょうか。
今回は、導入された場合のIT部門の対応や、役割について話したいと思います。

■市民開発をうまく使えば
■情シス部門が後ろ向きな理由と解消方法
■情シスの役割ーデータ
■情シスの役割ー教育

*IT民度:「特定の施設・サービスの利用者(ユーザー)・参加者・ファン等のある集団の平均的な知的水準、教育水準、文化水準、マナー、行動様式などの成熟度の程度を指すことから、自社従業員のITに関する成熟度を示します
*「情報システム部門」以降「情シス」と記します

■市民開発をうまく使えば
「順序を間違えないで正しく導入出来れば」企業情報システムに革命をもたらすと、私は考えています。
一般的に社内でシステム開発の必要性に迫られると、情報システム部、最近ではDX部などにお願いすることになるでしょう。
「システム開発変更依頼書」にお願いしたいこと(システム開発として)を書いて上長のハンコを貰って情シスに提出する。
すると「金無い、人無い、時間無い」の3本立てで無下にお断りされる…という経験をされた方も多いでしょう。
市民開発はユーザー部門が自身で業務用アプリケーション開発ができるので、情シスと折衝するストレスから解放され、スピーディな業務の変更が可能になるのです。
一方で、情シスはアプリケーション開発予算を持つ必要がなくなり、IT支出を大幅に削減することが可能です。


■市民開発に情シスが後ろ向きである理由と解消方法

「どうせEUCがゾンビのように蘇っただけだろ? 」
EUC時代の残骸を今なお不良資産のように持ち続けている企業は多く「市民開発」と言う言葉自体に拒絶反応を示すことが少なくありません。*EUC(End User Computing)1990年代初頭に流行した
本格的なプログラミング言語を使用したアプリも少なくありませんが、MS-ExcelマクロやIBM-Notes等で開発されたアプリが残っていることが多いでしょう。
(固有名詞の記述についてご容赦ください)
90年代後半以降は、これら乱立したアプリのメンテを情シスが担当するしかなくなり、いまだにその残骸のお守りに泣いていると言われるほどです。
そのため企業は「市民開発はリスク」と見てしまうのです。
EUCで開発されたアプリはユーザー部門の人が開発したので、以下のような事態になっています。
(1)プログラム仕様書が無い
(2)機能仕様も明らかではなく詳細を知るユーザーがいなくなった
(3)開発されたアプリケーションがOSや特定ツールのバージョンに依存していて、いつまでもそれらの古いバージョンを引きずることになる
ユーザーサイドで自由(勝手に)に開発された「野良アプリ」の為に、情シスの負担が何倍にもなったのです。
先般、世間からはDXを積極的に進めていると評判高い企業のデジタル部門のトップと話をしました。
この企業も、市民開発はリスクが高いので許可しない方針だといいます。
そのリスクについて尋ねてみると、やはりEUC時代の不良資産が未だに社内に点在しておりデジタル化の妨げになっているのだそうです。
本当によくある話です。
しかし、現在はスマホを片手に持って産まれてきたような(あり得ないけれど)Z世代が入社している時代です。
「リスクが高くて市民開発を導入できない」という環境を目の当たりにして、彼らは会社に残ってくれるでしょうか?
デジタル人材を育成することが急務であると当該企業は表明しているのですが、市民開発も許可しないでどのように人材育成するつもりなのでしょうか。
そもそもデジタル人材って何だろう、ですが。
具体的な人材像もなく、ただただ「デジタルに詳しい」などと大雑把なことを言っても人材育成など無理な話です。
このあたりの話は、別の回でしたいと思います。
さて、では「市民開発」を成功させるためにはどうすれば良いのでしょうか?
ユーザーにも情シスにもどちらにも覚悟が必要です。
まず「市民開発されたアプリは、情シスでは一切の面倒を見ません」を貫き通すことです。
更に、市民開発導入を希望する部署・部門は情シスに後始末を頼まないことを約束しなければなりません。
もしこれが、現実的に不可能だと考えるのであれば「話はそれまで」になってしまいます。


■情シスの役割-データ

市民開発導入は、情シスが責任を放棄しているように見えるというご意見をいただくこともあります。
いえいえ、それは勘違いなのです。
市民開発を導入してその体制を維持するためには、情シスは新たな役割を担うことになり、一筋縄ではいかない責任を負うことになります。
まず、データの話です。
EUC時代に最も問題になったのは「データ」です。
データをEUC環境(PCやW/S)までいかに持ってくるのかが結構な問題になりました。
更に問題になったこともあります。
EUC環境にて作成されたデータを「ホストやサーバーにアップロードしたい」というニーズです。
私の情シス時代に経験した話ですが、EUC環境構築ではアップロードも想定の範囲内だったのですが、このニーズの多さに驚いていました。
まずは、データをどのように準備した(つまりダウンロード)のかについてです。
現在の市民開発環境下ではもう少し上手なやり方がありますが、基本は変わらないので紹介したいと思います。
情シス管理下のデータベースから(EUC環境下で新設された)ローカルサーバーにオンデマンドでデータファイルをセットしたのです。
当時は残念ながら、情シスが手作業でターゲットファイルを作成してローカルサーバーにセットするという作業をしていました。
しかし、EUCを円滑に進めることに、情シスの運用チームも前向きに取り組んでくれたので、申請書が上がった翌日にはデータファイルがセットされるというスピードでした。
申請書だなんて古臭いと言われそうですが、90年代半ば頃の話だということと、データファイルを作るのにはいくつか留意点があったので、申請書ベースにしたのです。
(1)機密情報がダウンロードされないこと
(2)漢字コードをS-JISなどEUC環境で扱えるようにすること
(3)データファイルがEUC環境で扱える大きさにすること
当時のEUC環境は、こういう基礎的な課題を解決しなければなりませんでした。
さて、次に説明するのは、「ニーズが多すぎて驚かされた」と先述したEUC環境下で作成したデータをアップロードさせて欲しいというニーズを如何に対処するのかでした。
まずは「アップロードして何をしたいのか」の調査からです。
希望した部署は、商品開発部門で、商品部に研究開発の成果としてデータを共有したいというものでした。
※商品開発部は、新商品を開発したり既存商品の新しい売り方を開発したりを担当し、商品部とは大口顧客向けに商品を販売する部署
確かに、他の部署とデータを共有しようと思うとEUCサーバーが違うので簡単ではありません。
EUC環境下で生成された成果を、情シスが管理しているデータベースにアップするのは気持ちが悪い。
なので、商品開発部門のローカルサーバーと商品部のローカルサーバーを当該ファイルに限って共有できるようにしました。
ただし、これは「例外中の例外」としての取り扱いとしました。
データの取り扱いを間違うと「スパゲティ」状態を助長します。
市民開発で作られたアプリは、ほとんどがデータ連携をはじめるので、データをどのように連携するのかを「ユーザーの言いなり」で作ってはなりません。
情シス部門は市民開発を本格的に導入するために下準備をする必要があります。
社内にある様々なデータをどう取り扱うのかという「Data Principle;データ原則」を定めて厳に運用しなければなりません。
この作業が「めちゃくちゃ大変」なのですが、一旦出来上がってしまえばかなり合理的かつ経済的にシステム運用が可能になります。
「めちゃくちゃ大変」なのでデータ原則についての話は、別の回に持ち越したいと思います。
(すぐに知りたい!という方は、ご遠慮なく相談ください)


■情シスの役割-教育

市民開発導入における情シスの役割のひとつに「教育」があります。
ノーコードやローコードのツールをエンドユーザーが使えるようになるまで教えることです。
ツールを供給する会社が「ユーザーマニュアル」よろしく使い方講習会を開催してくれるかもしれません。
しかし、社内のデータをどうやって引っ張ってくるのかというところは、自社でしか教えてあげることはできません。
丁寧に教えてあげて欲しいのです。
対象は、部門(イメージとしては本部単位、事業部単位くらい)代表者だけで良いでしょう。
部門代表者が、部門の担当者に教えていくような体制を構築したいということです。
もちろん、部門代表者がノーコードやローコードのツール習得担当者に教える際には、情シスからも助っ人として立ち会うことは必須です。
こういう勉強会の開催は情シスが最大限の支援をするべきです。
さて、その前に、部単位に担当者をアサインするように促す必要があります。
全社一斉でなくとも、ノーコードやローコードのツールを導入したい圧力の強い部門から順で良いでしょう。
概ねニーズの強いところと一緒に始めて「ユーザーサイドの味方」を増やしていくのです。


■情シスの役割-変革すること

情シスの役割はまだあります。
業務系システムに取り込むかの判定も、情シスの役割です。
市民開発環境下で新たに生まれた業務は「業務設計チーム」での精査が必要です。
データの流れが変わっていないか、ビジネスプロセスに変化があったのか。
新たに生まれた理由をフィードバックし、何がどのように変化したのかをCIO含めて情シス全体で共有しなければなりません。
市民開発を導入することで、情シスは業務が減る訳ではありません。
新たな役割に対する責任が生まれ、むしろ情シス自身が大きく変革することを求められるはずです。
しかしそれが、常に成長し続ける情シスを目指すことになるのです。


合同会社タッチコア 代表 小西一有


ゼヒトモ内でのプロフィール: 合同会社タッチコア, ゼヒトモのコンサルティングサービス, 仕事をお願いしたい依頼者と様々な「プロ」をつなぐサービス