ノーコード・ローコードの落とし穴
yoshida-r
「ノーコード·ローコード」社員がお手軽にアプリ·自動化フローを作成できる！
聞こえは良いが、現実はそう甘くない。
いわゆる「パズル感覚」でできる自動化は良くも悪くもお遊び程度しか実現できない。
既に何かしらシステムを導入しているならば、
同じものを作り上げるのに、どれだけの労力·知識が必要になるか絶望することだろう。
クラウドサービスを導入してみて、一番よくある意見は「思っていたのと違う」ということなのではないか
そして、自分たちが普段行っている業務が、どれほど選択肢まみれで、複雑な判定をしていて、高度な処理なのかということを実感することになる。
プログラムは高速で間違いなく、いつも安定した出力を吐き出してくれる
それゆえに、優秀に感じるし、誰もが夢を抱く。
しかし、実のところ応用性はないし、柔軟性もない。
「いやいやそんなことないよ」というシステムを知っているというのであれば、それはそのシステムの設計者のスキルレベルが高いことに他ならない
素人が作った「ローコード·ノーコード」のシステムは、基本的に応用が利かないし、運用制限が生じるまくる。
でもそれは仕方のないことでもある。
他に本業がある人間が、独自に勉強してアプリ·自動化フローを組み立てる
これを「市民開発」と呼ぶが、本業でプログラミングだけをしているわけではなく、本業の合間にシステムを組み立てるので、当然そうなる。
もともとプログラミングを勉強していたかというと、すべての方がそういうわけではない。
仮にプログラミングを勉強していたとしても、落とし穴は無数に存在する。
プログラミングに詳しいと、使用者の気持ちがわからなくなることが多い。
これは、マーケットインかプロダクトアウトかいう観点の話になるが、プログラマーは「こんなこともできる。こんな便利機能も組み込んだ！」と、嬉々として機能を伝えるが、実際の使用者はそんなことまで希望していないし関心がないことが多い。
プログラマーからすると、「え？そんなこと？」というレベルのもので大きく喜び、プログラマーが歓喜する内容では、ポカーンとしてしまう。
「ノーコード·ローコード」と言いながらもそれなりにしっかりしたものを作るとなると、そもそもプログラミングを学んでいた人間や、前職がシステムエンジニアという社員がかなり気合を入れてシステムを組むこととなる。
その職場でも使っていこうと大体は舵を切ることになるのだが、転職や異動で、そのシステム構築者が職場からいなくなると、途端に破綻する。
ルールが変わったタイミングで、このシステムはお蔵入りになる。高度に組まれたシステムは思いがけない要素が入力として使われることが多いからだ。ルールの上にシステムが組まれているという以上仕方のないことではある。
そのたびにリテラシー教育が必要と議論され、アプリ·自動化の勘所（運用·拡張方法等）をまとめたマニュアル資料作成を要求される。
ここでまたもや問題が発生する。
プログラマーに限らないが人間は基本的にマニュアル作成が嫌いだ。
特にプログラマーにとって、エラー回避するための「当たり前のこと」をわざわざ時間をかけて整理し、形に残さなくてはならない。
「マニュアルがあること」に理解や関心はあるが、その内容に関しては、基本的に使用者からの関心は低い。
更新の都度、該当箇所を修正しなくてはならないという面倒くさいおまけつきである。
「本質的で核となるところはしっかり書いて残したい」という気持ちはあるため、積極的に作ることはあるが、そのプログラマーのレベルに達していない人間からしたら、奇々怪々の何を語っているのか全く分からない資料となるだけでもある。
結局話が戻るが、すべての従業員をそのアプリ·自動化フローを構築できるまでのレベルに引き上げねば、「ノーコード・ローコード」というお手軽ツールでさえ、話にならないのである。
手紙がOutlookやGmailに代表されるEメールに取って代わったように、連絡手段はチャット化し、自動化処理·アプリケーション作成が誰でも当たり前にできるような世界は本当に来るのだろうか。
かなり尖った知識·スキルのため、そうなることは大分厳しいとは感じながらも、日本人のような勤勉でまじめな人種ならもしかしたら···と期待してしまう一面もある。
私たちは得手不得手も、身長も体重も、趣味嗜好も一人一人全然違うが、人間という点においてはみな同じである。
誰かができたことは、もちろん他の誰でもできるはず
ただ、できるようになるまでにかかる時間がかかるし、同じことやものを目の前にしても感じ方は十人十色
自分が簡単にできることでも他人は難しく感じるし、自分が難しいと感じることは他人は結構簡単にやってのけたりする
自分の感覚で相手を理解したと勘違いした時から、途端に地獄の苦しみになる
