ノーコード／ローコードは
万能ではない

　ただしベンダーロックインを必要以上に恐れては意味がありません。マネージドサービスはいずれも、ある程度はロックインされることが利用の前提となります。もしロックインを100％避けようとするなら、オンプレミスに戻るという選択になってしまいます。それはもう一度、全てを自前でメンテナンスし、運用するコストが発生することを意味します。このトレードオフを理解し、許容できるリスクの範囲内のツールやサービスを選び取っていくことが大事です。

　4つ目は、「人材育成の観点から見た注意点」です。今、DX人材の育成のため、リスキリングの一環として一般社員にプログラムを学ばせる企業も増えています。そのときに「Python（パイソン）」のようなテキストプログラム言語ではなく、ノーコード／ローコードツールで進める会社もあるかと思います。そのこと自体は悪くはありませんが「いずれはより複雑なプログラムも扱ってもらおう」と考えているのなら、ノーコード／ローコード環境に必要以上に慣れさせすぎるのは、よくないのではないかと感じます。

　テキストプログラミングを始めてみるとわかることですが、ノーコード／ローコードに比べてテキストプログラミングは基本的に面倒くさいのです。そこで、ある程度までなら頑張ってノーコード／ローコードツールで作った方が楽だと思われがちです。ところが、さらに高度な処理を行おうとすると、ノーコード／ローコードでは実現できません。逆にある程度以上の複雑さになると、テキストプログラミングで実装した方が効率的で楽になっていきます。

　1つ目で「適材適所」と述べましたが、人材育成の観点から見てもノーコード／ローコードツールの利用は無理せずにできるところまでにとどめておくべきです。それ以上にやりたいことがあるなら本格的なテキストプログラミングを学ぶように、社内の人材育成の仕組みを設計した方がよいのではないかと思います。

　現在の学校のプログラミング教育でも、最初はビジュアルプログラミングからスタートして、プログラミングの概念を学びます。条件分岐や代入、ファイルの入出力やデータベースへのアクセスなど、プログラミングの基礎的な考え方は、ビジュアルプログラミングでも学べます。その考え方はテキストプログラミングでも当然、必要となる部分です。そこから無理にビジュアルプログラミングで高度なことをやろうとせずに、早い段階で「この先はテキストでなければプログラミングできない」という方向で教育するのがよいのではないかと考えます。

（クライス＆カンパニー顧問／Tably代表　及川卓也、構成／ムコハタワカコ）