ローコード・プログラミング

　最近「DX」「内製化」「ローコード」がIT業界で流行っていて、日経コンピュータでANAの内製化が紹介されていた。

　ITC業界で長く働いてきて、今は小さな事業所で「ほぼ1人情シス」をやっている。「ほぼ1人情シス」の立場で「内製化」を考えてみた。
「ほぼ1人情シス」は通常業務があるので大掛かりなシステムは作れない、手間や時間がかかる業務フローを効率化するくらいだ。

　今流行りのノーコード、ローコードプログラミングで簡単にシステムが作れるという、売り文句は　1/4くらい正しい。ツールを売る立場ならそう言うだろう。
用意されたテンプレートで間に合うかちょっと手を入れるくらいなら、Excelでデータベース関数が使えるくらいのスキルがあれば作れると思う。

　ところが、現実の業務がテンプレートにハマることは稀だ。業務をテンプレートに合わせなくてはならなくなる。

　例えば、PowerAutomateのテンプレートに休暇承認フローがある。
申請者がSharePointのリストにタイトル、取得日を入力すると、マネージャ(承認者)にメールとTeamsで通知され、メッセージ中の承認／却下ボタンを押すと、リストに、承認／却下が入力されるというもの。このフローは簡単で初心者でも作れるようにマイクロソフトが考えている。説明もあるので試してみるにはちょうどよい。

しかし、作れることと運用できることは違う。
現在、休暇承認を違うフローで運用している場合、変えられるかどうかが内製化の効果が現れるかどうかの分かれ目だ。

　さらに、テンプレートの構造まで手を入れてようとすると、プログラミングのスキルが必要になる。
たまたま、プログラミングのスキルを持った人、例えば、Excelマクロが書ける人がいる場合は、テンプレートを参考に独自にシステムが作れるだろう。

しかし、慎重に考えなければならない。
解決すべき問題と解決方法を考えないで、思いつきで初めたり、「ちょっとやってよ」のような要求を引き受けると、時間と労力をかけたけど使われないシステムが出来上がる。

外注しても解決したい問題を解決できるシステムが、内製できるなら価値がある。しかし、問題が解決できないなら内製しても価値はない。

ノーコード、ローコードで内製しようとしたときに、
標準の機能で実現できない場合、現状の作業の効率化になっていないか、考えたほうがよい。
紙＋ハンコでもクラウド＋RPAでも、その仕事がやらなくてよいなら、無駄だということだ。
やらなくて良い仕事を効率化しても意味はないのだ。

　さらに^2、
標準の機能だけで実現できず、拡張機能を使わなければならない場合は、「1人情シス」では難しいと思う。「1人情シス」に求められているのは内製化ではなく、解決すべき問題をを外注先に伝えられることだろう。

###

　PowerAutomate/PowerAppsのカスタムコネクタやOffice scriptを使うとできることが広がるのだけど、全然ローコードではない。

---

【最近の投稿】【プログラミング】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿】