ノーコードが普及したらプログラミングはどうなるのか？
後藤智氏（以下、後藤）：みなさんもご存じのように、コードを書くのはそんなに簡単ではないですよね。システムを作るのもそう簡単ではないですし、これを見える化するのが1つのテーマだと思います。
その中で最近、「ノーコードツール」というのが出てきました。例えば「Bubble」や「UNREAL ENGINE」「ブループリント」「Unity」などにも、最近はノーコードツールがあります。
そういったものを使って、コードを書かなくてもロジックだけでいける状態ができつつありますが、こういったものに関する、高橋さんの見方はどうでしょうか？
高橋直大氏（以下、高橋）：ノーコードですか、なかなか難しいですね。あれも、「ノーコードって言うの？」と思っている部分がいろいろあります。例えば、「Scratch」のGUIプログラミングが「あれは、ノーコードなの？」というと、別にノーコードではない気がするんですよね。
組み合わせても結局ロジックは書かないといけないノーコードと、もうサービス単体であって、基本的に1クリック、2クリックで終わるノーコードと、いろいろなノーコードがあると思います。
「ノーコードが出てきたことによってプログラミングは要らなくなるのか」とメッチャ聞かれるんですけど、そんなことはないと思います。結局、ロジックを組み立てる系のノーコードは、僕がコードを書いていると思っているので、そういうのを作る人が結局要るし、そういうのは陳腐化して、誰でも使えるようになったら……便利なものもたくさんありますが、それは目玉にならないので、結局サービスとしてなにか違うものを作らないといけない。
サービスといってもいろいろなものがあって、BtoBの社内のやつで、「みんなが同じものを使えればいいよ」と言うのだったら、たぶんこれはノーコードでわざわざロジックを組まなくても、もともとあるもの自体ですでにけっこうできるし当然、コードを書く負担は減る部分もあるんだろうなとは思います。コードを書かなくてできることは、当然どんどん増えてくるし、それはソフトウェアの進歩によってノーコードがなくても増えていると思うんですが、そういうものと同じで、進歩はしているけれども、すごく大きく変わる変化かと言われると、あまりそうは思っていないです。
もう1個ちょっと情報を言っておくと、「うちはプログラミングコンテストをやって、人を集めて、ノーコードを開発します」と言っている企業さんがいるのですが、今のところノーコード開発とプログラム好きな人は相性が悪いらしいです。
「ノーコードです」と言われると、「えっ、ちょっと入りたくないな」という印象になるプログラマーが多いみたいなので、プログラミングができる人はむしろノーコードで離れちゃう部分があるのかなと、個人的にはちょっと思っています。
後藤：ありがとうございます。よくわかりますね。
ローコードに自分の仕事を取られるというイメージはあまりない
後藤：まつもとさん、言語開発者からすれば、ノーコードはどちらかといえば敵になるんですかね。ノーコードに関して、どういうお考えをお持ちですか？
まつもとゆきひろ氏（以下、まつもと）：そうですね。ノーコードとかローコードとか言われているものがいくつかありますが、今高橋さんがおっしゃったように、まだ定義がいまいちはっきりしないんですよね。
「これがノーコードです」と言っているものが、本当にノーコードの定義なのかというと、会社によって、「私のところがノーコードです」と、言っているものが違うし、あるいは、あるプロダクトに対して批判しても別のプロダクトでは成立しないことがあるかもしれないので、なかなか扱いにくいところではあります。
1つあるのは、まず、ノーコードと言われているもののほとんどの場合は、ある種のアプリケーションのカスタマイズであることが多いですね。顧客管理や財務管理など、ある特定の目的があって、その企業に合わせるカスタマイズが簡単にできるというものが多いんですね。
それは、プログラミングではないわけですよ。コードを書いていないし、ある業務を自分の会社に合わせました。それをどこかに発注するのではなくて自分でできますという点では、コードを書いていないのでノーコードは間違いありません。
私たちがプログラミングという言葉から思いつくものというのは、コンピューターにロジックを教えて、人間の処理をさせてやりたいというところにあるわけですよね。ノーコードがもしアプリケーションのカスタマイズレベルであるとするならば、それはぜんぜん競合ではありません。
あるいは、ローコードと言われているものもあって、それはロジックを書くこともできるというものです。それも「Scratch」にあるようなビジュアルな表現で書けますというかたちで、部品を並べることによってわかりやすくロジックが書けますよというアプローチ。
わかるのはわかるんですけども。「Scratch」のプログラムを見てもらうとわかるのですが、わりと早く限界が来るんですよね。子どもたちが超巨大なScratchゲームを作るんですが、少なくとも私はそれをデバッグできない（笑）。
何画面もスクロールしないとロジックの端まで届かないやつを、子どもたちは平気で作るんですが、正直に言うとデバッグしにくいし、生産性が高いとはとても言えないというところがあるんですね。
それを考えると、ノーコードはアプリケーションのカスタマイズレベルだし、ローコードと言われているものに関しては、ロジックが書けるけれども、早晩限界が来るので、プログラミング言語を作っている人や、それを駆使しているプログラマーからすると、裾野を広げる効果はあっても、自分の仕事を取られるというイメージはあまりないですね。
ですが、ただ一般的に言われている格言として、「年寄りがなにかを否定したら、それは信じるな」というのがあって（笑）。なので、もしかしたらこれから先、私たちの想像もつかないようなすばらしいノーコード、ローコードツールができて、プログラマーの仕事を奪うかもしれないのですが、今現れている、私の知っている範囲内のもの、あるいは私の想像がつく範囲内のものであれば、プログラマーの仕事を奪うようなものではないという印象を持っています。
後藤：ありがとうございます。
ローコードによって、より本質を考える仕事が増えてくる
後藤：楠さん、先ほどのブラックボックス化の話の流れで、例えばこういったノーコードも1つのソリューションにはなり得ると思うのですが、楠さんのお考えはどうでしょうか？
楠正憲氏（以下、楠）：そうですね。2年前に特別定額給付金で1,700の団体で同じように適用できるものを作ろうとした時にあまりうまくいかず、けっこう苦しんだのですが、例えば加古川市は、「kintone」というツールで市民用の申込画面を作って、すごく使い勝手がいいものを出しました。その後ろ側は、「Access」か「Excel」などでたぶん、VBAでやっていたんだと思いますが、1週間とか2週間とかかなり短期間で、行政職員が何十万人向けの申込みみたいなものをすごく上手に作っていました。
あるいは、2021年のワクチン接種の時も、同じ人ですが、確か経済学者が、「ワクチン接種は予約サイトだとアクセスが集中してすぐ動かなくなるから、むしろ抽選でやるべきだ」みたいな提言を、日経の経済教室で書いていたんですよね。「いや、本当にそのとおりだ」と、東京都でもやりたいなと思って、一生懸命ベンダーにお願いしたんだけど、どこも引き受けてくれませんでした。
でも加古川市は、最初に予約サイトがパンクした後すぐに、やはり「kintone」で申込画面を作って、同じように抽選を自分で書いたんですよ、多田さん（※兵庫県加古川市のスマートシティ推進担当課長 多田功氏）という方です。
こういうのを見ていると、やはり「業務を知っている人が扱える武器を与えられるとすごいな」という実感を持ちました。彼は結局、後ろの抽選の処理やVBAを書いていたので、別にノーコードで完結をしているわけではありません。
そして、ある意味、定型的な処理をモジュール化して自由に呼び出せるようにして、そこの部分を毎回書かないで済むようにするというのは、実はプログラミングの世界では極めてポピュラーな進化の方向です。
RubyはC言語と比べれば、手で書いていた部分をすごく簡単に抽象化できる。そういう意味では、僕はRubyはC言語に対しては十分ローコードだと思いますし、C言語だって、アセンブラに対してローコードなのかもしれない。
常にダーティワークを抽象化して、より高度なことを人間が考えるための仕組みとして発展してきたというプログラミングの歴史を考えれば、ローコードによってプログラマーの仕事がなくなるのではなくて、むしろ泥臭いところから解き放たれて、より本質を考える仕事が増えてくるんじゃないかと、そんなふうに思うことはあります。
後藤：なるほど、ありがとうございます。
（次回へつづく）
