あとましーん

SIerで働き、外出で何か美味しいものをさがし、節操なく興味のままに行動するアラサー男の備忘録です。

EUC・ローコード開発が流行っていますが、デメリットへの対応も考える必要がありますよね。

本日は天候不良との予報が流れ、急遽在宅勤務になりました。
参加している会議も2週目になりはじめ、徐々に新鮮さが薄れてきますね。

 

今日はEUCとローコードについて書きます。
結論から書くと、EUC・ローコード活用は僕的には、細かめにルール整備やツール選定をし、継続的にモニタリングをしないと要注意だと考えています。

 

EUCってそもそも何?って言うと、
エンドユーザー・コンピューティングの略でプログラマーや技術者でなくてもアプリケーションを作成できるシステムのことです。
みんな大好きExcelのマクロやAccessもその一つと言えます。
ローコードは可能なかぎりソースコードを書かずに、アプリケーションを迅速に開発する手法やその支援ツールのことです。
ソースを書く必要が無いので、プログラマー以外の現場担当等でも開発可能です。
どちらも現場主体で開発可能という点で共通しています。

 

EUCについて調べてみると1970年代後半くらいから登場しているようです。僕がここ十数年働いている限りでは、大々的に流行っている感覚は無かったです。ただ、ここ2・3年でだんだんローコード開発と名前を変えて流行って来たような気がします。
現職ではローコード開発用の研修資料作っていたりしますしね。

 

そんなEUCなのですが、メリット・デメリットを整理すると

 

メリット
・自分たちの業務に合致するシステムを構築でき、効率化できる。
・IT専門部隊の労力を割く必要がない
・現場部門のリテラシーが向上する。
・お金が外部に出ていかない
・現場部門のみでの開発となり、スピードが速くなる

 

デメリット
・実現できる内容が仕組みに依存する
・ユーザー部門独自のIT環境が構築され、情報システム部門が認識できない。
そのため、統制やセキュリティのルールに準拠できない。
・属人化し、担当者が不在になった時に困る

 

です。

 

どうでしょう。パッと見メリットがデメリットを上回る気がしますよね。

 

ただ、僕はERPを導入する立場だったので、このデメリットになっている属人化が非常に曲者ということを度々目にして来ました。
これがきっかけで現状業務や人の異動がし辛く、苦労しているお客さんが沢山いました。
最終的にはその担当者の退職があり、入れ替えで結構なお金を払ったり、急に人が必要になったりしているケースも多々あります。
なので、結果的に痛い目を見た人が多く、EUCが徐々に廃れてきたと思っていました。

 

先ほどの通り、EUCが名前を変えてローコードとしてまた現場部門での開発が流行っています。
ツールはAccessからPowerPlatformやKintoneや各種大手ベンダーが提供しているシステムに代わってきていますが、ここ数年でその動きが増えたと思います。

 

何故また流行ったのかと言うと、調べてみると以下のような意見がありますね。
・IT活用領域の急速な拡大
・ITスキルを持たない人材によるシステム開発の登場
・ビジネス環境の急激な変化に応じた短納期開発の要請

 

うーん、正直あまりピンと来ません。聞こえはいいですけどね。

 

僕の感覚としては、こっちの理由の方がピンときます。
MicrosoftGoogle等の大手開発会社のツールリリース
SaaSを利用することが増えカスタマイズが減ったため、その周辺で開発する必要が出てきた
API実装によりシステム間連携が可能になり、実装範囲が拡張された
・DXブームとして何かやりたい

 

前より出来ること増えたし、大手がツール出したし、DXって何かやったほうがいい気がするし、なんとなくやってみようかな

 

こんな感じだと思います。

 

ということで流行ってきていると思いますが、僕としてはEUCのデメリットを忘れてい

るのでは・・・・と感じてしまいます。
また現場で色々開発が実施された後で、やっぱり属人化してダメじゃん・・・ってなりそうで。

 

なので何が言いたいかと言うと、EUCやローコード開発は属人化させないことが一番重要になると思います。
属人化させないためには、2つ考えられて、
・システム部門で集約して開発する、
・システム部門による開発ツールの選定・開発ルールの策定・開発状況のモニタリング
あたりが対策でしょうか。(もっとあると思いますが、ぱっと浮かぶ対策はこのあたり)
そういう意味では、システム部は今までと別の大変さが出てくるので要注意です。

特に後者の場合に、安易に「現場のみなさん、自分達で開発するならお好きにどうぞ」ってシステム部門が考えていると、いばらの道を歩むことになります。
まぁ、そんなシステム部門はあまりないと思いますが、開発ツールの選定やルール策定・モニタリングって結構大変ですから、そこに長けた人の需要ってありそうですよね。

 

と思う今日この頃でした。(あれ、バレンタインは・・・・?)
今日はこのあたりで。