2023/02/28ノーコードやローコードが抱える問題には、管理しきれないのらアプリの存在があります。これまでも誰が作成したかわからない仕組みが業務で利用されている、修正が必要になったけど誰も対応できないといった状況になることがあり、気軽にアプリを作成できるノーコードやローコードを危険視している人も多いのではないでしょうか。私の思想としても、無制限にフル機能を利用できる状況はリスクが大きすぎると考えているところがあり、ある程度の制限と管理を設ける必要はあると考えています。その度合いに関してはかなり低いレベル、不要な外部サービス連携を閉じるといった本当に必要最低限の制限であるのがよいとも考えています。呼ばれるデータ損失ポリシーを設定して、データ流出が起こる可能性を減らす仕組みがあります。接続する機能を制限することで、処理で利用しているデータを意図的かどうかを問わず、外部に流出させることを防ぐことが可能です。活用するアプリを作ることが不可能となり、もしかしたら作り出すことができたかもしれない新しいメリットを生まれる前に潰してしまうことにもなります。企業規模が大きくなると、どうしてもリスクに対して過剰ともいえるレベルで対応をとる必要があります。新しいアプリを用意して効率が向上するメリットよりも、不適切な流出を起こしてダメージを負うデメリットが企業にとっては認められないためです。規模が小さいうちはメリットを優先しやすいですが、大きくなればなるほど簡単にはメリットを選択できない背景は残念ながらあります。最終的には何を選択するかという点に尽きるのですが、ノーコードやローコードを採用するならばメリットを多く採用する方向を選択しなくてはならない、と言えるのではないでしょうか。ノーコードやローコードを採用する理由は、現場でアプリを開発できるように開発行為の敷居を下げる点もあります。できる限り自由な発想で作成することで、これまででは実現できなかった現場に即したアプリを構築することが可能になるためです、ここを、強固な制限を用いて不自由にしてしまうと、ノーコードやローコードを利用したアプリ開発がそもそも行えなくなる可能性が非常に高まります。業務に適用したい機能が利用できないとか社内で多くの手続きを踏まないと作成を許可されないとしてしまうことは、サービスを利用しようという気持ちを起こさないことへ繋がります。サービスを採用し現場での開発力を高めたい考えを優先するならば、リスクを感じるところがあっても強固すぎる制約は設けないのがベターです。発生するかもしれないリスクを考えすぎるあまり、当初の目的であった現場での開発力向上を阻止してしまうのは本末転倒とも言えるでしょう。目的を達成させるためには、制限の緩和も含めた形で利用方法や形式を考えていく必要があるのだと思います。実のところ、個人的にはもう少し放置するような環境でもよいかもと考えています。外部へデータを連携するような場合は第三者のレビューを行う、内部に閉じた場合は自由に作り利用する、その程度のルールでも十分に恩恵を受け取ることが可能なはずです。なんだというためには必要なのかもしれません。いう単語自体は嫌いですが。名前を記憶しておくコメント:SpecialPRスポンサーからのお知らせPRAhf「試される大地」で働くエンジニア。貪欲に前へ進もうとやみくもに生きています。久しぶりの対面研修で思ったことよく学びよく遊びよく寝る、頭の回転が良い子供がたくさん育つ国になるといいな。新着記事SpecialPR@ITメールマガジンのお申し込み新着記事をいち早く知りたい、オリジナルコラムを読みたい――メールマガジンに登録して、@ITを120%使いこなそう。ITmediaはアイティメディア株式会社の登録商標です。