自由と制約とノーコード
ノーコードやローコードが抱える問題には、管理しきれないのらアプリの存在があります。これまでも誰が作成したかわからない仕組みが業務で利用されている、修正が必要になったけど誰も対応できないといった状況になることがあり、気軽にアプリを作成できるノーコードやローコードを危険視している人も多いのではないでしょうか。
私の思想としても、無制限にフル機能を利用できる状況はリスクが大きすぎると考えているところがあり、ある程度の制限と管理を設ける必要はあると考えています。ですが、その度合いに関してはかなり低いレベル、不要な外部サービス連携を閉じるといった本当に必要最低限の制限であるのがよいとも考えています。
私がよく利用している Microsoft の Power Platform では DLP と呼ばれるデータ損失ポリシーを設定して、データ流出が起こる可能性を減らす仕組みがあります。例えば SNS に接続する機能を制限することで、処理で利用しているデータを意図的かどうかを問わず、外部に流出させることを防ぐことが可能です。このような仕組みを利用することでリスクを減らしていくことは可能ですが、反面 SNS を活用するアプリを作ることが不可能となり、もしかしたら作り出すことができたかもしれない新しいメリットを生まれる前に潰してしまうことにもなります。
企業規模が大きくなると、どうしてもリスクに対して過剰ともいえるレベルで対応をとる必要があります。新しいアプリを用意して効率が向上するメリットよりも、不適切な流出を起こしてダメージを負うデメリットが企業にとっては認められないためです。規模が小さいうちはメリットを優先しやすいですが、大きくなればなるほど簡単にはメリットを選択できない背景は残念ながらあります。最終的には何を選択するかという点に尽きるのですが、ノーコードやローコードを採用するならばメリットを多く採用する方向を選択しなくてはならない、と言えるのではないでしょうか。
元々ノーコードやローコードを採用する理由は、現場でアプリを開発できるように開発行為の敷居を下げる点もあります。できる限り自由な発想で作成することで、これまででは実現できなかった現場に即したアプリを構築することが可能になるためです、ここを、強固な制限を用いて不自由にしてしまうと、ノーコードやローコードを利用したアプリ開発がそもそも行えなくなる可能性が非常に高まります。業務に適用したい機能が利用できないとか社内で多くの手続きを踏まないと作成を許可されないとしてしまうことは、サービスを利用しようという気持ちを起こさないことへ繋がります。
サービスを採用し現場での開発力を高めたい考えを優先するならば、リスクを感じるところがあっても強固すぎる制約は設けないのがベターです。発生するかもしれないリスクを考えすぎるあまり、当初の目的であった現場での開発力向上を阻止してしまうのは本末転倒とも言えるでしょう。目的を達成させるためには、制限の緩和も含めた形で利用方法や形式を考えていく必要があるのだと思います。
実のところ、個人的にはもう少し放置するような環境でもよいかもと考えています。外部へデータを連携するような場合は第三者のレビューを行う、内部に閉じた場合は自由に作り利用する、その程度のルールでも十分に恩恵を受け取ることが可能なはずです。変にがんじがらめにするのではなく、可能な限り自由にできる場を整えることが、やれ DX だなんだというためには必要なのかもしれません。DX という単語自体は嫌いですが。