ノーコードの限界は意外と近い
ーー小学校でプログラミングを勉強することになったり、プログラミングスクールが増加したりと、プログラミング自体はより普及が進んでいる時期だと感じます。そんな中で、ノーコード開発が普及することに、どのような印象をお持ちでしょうか。
まつもとゆきひろ氏（以下、まつもと）：私自身はプログラミングができる立場なので、なかなかノーコードとローコードの領域に対して、魅力を感じにくいところがあると思います。ただ、懸念に思っていることはあります。例えばノーコードと言っても、本当になにもしないで望むものを得られるわけではありません。なんらかのかたちで、何を望んでいるかを伝えないといけないわけです。
ノーコード開発と言われているものでそれができるのは、領域を非常に絞って、既存の部品の組み合わせによって目的を達成できるからだと思うんですよ。しかし、人間のやりたいことは多岐にわたっていて。既存の簡単な組み合わせでできることでは、早晩に限界が来てしまいそうな気がするんですよね。そうなった時に、そこから脱することはすごく難しい。そこがノーコードの限界になるんじゃないかという気はします。
ノーコードをイメージさせるものの典型例で、Scratchのようなものがあります。ブロックを組み合わせていることで、子どもでもロジックを書くけるものですが、子たちにScratchさせると、ある程度から嫌がる子が出てくるんです。
なぜかというと、ゲームのルールがどんどん複雑になると、ロジックが一画面で収まらなくなります。ロジック書くだけでもガンガンスクロールさせないといけなくて。そうすると生産性が下がってきて、小学校5、6年になると「RubyなりPythonなりで直接書かせてくれ」という子が出てくるんです。
プログラミングって、開発してみると、わりと簡単に複雑になるんですよね。私もノーコードがどういうことをやるのかを完璧に知っているわけではありませんが、普通に想像する範囲内では、ロジックがある程度複雑になった時、あるいは作りたいものが複雑になった時に、限界が出てくる可能性がある。そして、その限界は意外と近いんじゃないかと思っています。
ーーー小学校5、6年生で、嫌がる子が出てくるのは意外です。
まつもと：私の知人で子どもたちにプログラミングを教えたことのある方の経験から言うと、特に日本では小学校1、2年生は、キーボードを打つのが難しいんですよね。「Rubyをやりましょう」と言われて、いきなり「C・L・A・S・Sと打ってください」みたいなこと言われてしまうと、正直だいぶ挫折してしまう子が多いので。
その点、Scratchのようなものはだいぶありがたいそうです。「ネコのキャラクターが壁に当たるまで繰り返す」というようなメニューから選んで、ブロックで組み合わせるというのは入門としてはありがたいし、ロジックの組み合わせを知るには意味があるとは思います。
しかし、ロジックに凝るタイプの子どもたちもけっこういて。もちろん全員ではありませんが、そういう子どもたちは、ある程度ロジックが複雑になってくるとブロックの組み合わせが巨大になってしまって、「画面に収まらないからデバッグしづらい」「むしろRubyとかで書かせてください」となる子が実際にいるのは事実です。
ーーでは、ノーコードの良さはどのようなところにあるでしょうか。
まつもと：ノーコードの良さの1つはとっつきやすさがあると思います。あまりロジック的なこだわりがなかったり、あるいは「ちょっとカスタマイズするぐらいで、ほとんどは既存のものでOKです」みたいなものをたくさん作るのであればいいんじゃないかと思います。
一方、ロジックやルールの複雑さに対して、あまり書かなくても済むことは、真っ向から矛盾します。そうなった時には、汎用プログラミング言語は複雑さを取り扱うものとして進歩してきたので、向いているのではないでしょうか。自分の作りたいものが、どちらに所属するかによって判断は変わってくると思います。
汎用プログラミングとノーコードは、実は意外と連続していないんですよね。ターゲットが若干違います。ローコードだと、一応ロジックも書けますが、その延長線上で「なんでもできる」と思ってしまうと、どこかで高い壁にぶつかる気はします。
汎用プログラミング言語であればノーコード、ローコードがやることはもちろんできるけど、逆はそうはいきません。
一度広まった言語はなかなか消えない
ーー最近ではノーコードのような、新たな開発手法が登場しているわけですが、プログラミング言語だけを見ても、さまざまな言語が生まれては消え、使われやすい言語が変わり･･･と歴史を辿ってきています。長い歴史があるなかで、これまで使われ続けている言語には、何か特徴があるのでしょうか。
まつもと：まず、プログラミング言語の発展は、すごくたくさん生まれ、少しだけが生き残って広がり、そのなかでも多くの人に広がったものは、人気は下がっても生き残り続ける傾向があります。例えば、1950年代の古い言語で、FORTRANやCOBOLなどがあります。60年ぐらい前に生まれた言語で、少なくなってはいますが、60年経っても消えてはいません。
人気に関して言うと、どんどん新しいものが出てくるので、人気は下がったり、あるいは使われているアプリケーションが減ったりは当然あります。でも、いったん広まった言語は何十年単位で生き残って、なかなか死なないんです。
ーー言語が広まる着火剤というか、きっかけは何かあるのでしょうか。
まつもと：ものによって違うので難しいですが、“キラーアプリケーション”というか。「このジャンルのソフトウェアを書くなら、この言語がいいよ」というジャンルが存在しているかどうかが、広まる条件になるんじゃないかと思います。
科学技術計算なら普通はFORTRANを使う、ひと昔前の話で、ビジネスプログラミングを書くならCOBOLを使う、とか。最近流行りの機械学習をやるならPythonがいい、というような感じで、ジャンルと言語が結びついたりすると、その言語は広く使われて、かつ、生き延びやすいかなと思います。
プログラマーの仕事は、機械を相手にするものではない
ーー相性の良い組み合わせがあることが大切なんですね。プログラマーというと、一般的には「コードを書く人」と捉えられがちですが、まつもとさんはプログラマーという仕事をどのように捉えていらっしゃいますか？
まつもと：一言にプログラマーと言っても、そのジャンルはさまざまです。ソフトウェア開発もかなり広い領域があるので、領域の中のどこに関わっているかによって、一言では言えないところがあります。かつ、どのプログラマーに聞いても自分の近い領域のことしかよくわからないので、与える印象が違うはあると思います。
じゃあ私はどう思っているかと言うと、プログラマーは、ソフトウェア開発全般に関わる人だと思っています。つまり、「どんなソフトウェアを作るべきか」から始まり、「そのソフトウェアが本当にその自分の作るべきものだったか」を確認するところまでする人、ということです。
プログラマーの仕事は、一般的に機械相手の仕事と思われがちです。確かにコンピュータに向かって仕事はしていますが、そのソフトを使うのはだいたい人間なんですよね。
その人間がどういうものを欲しているのか、あるいはどういうふうなもの作ると人間にとって役に立つかとか。コンピュータに向かっていたとしても、「何が欲しいんですか」とインタビューしたり。そういう意味でいうと、意外と機械相手の仕事ではなくて、人間相手の仕事である印象を持っています。
ーー「プログラミングはツールだから」と言われることがあることを思い出しました。
まつもと：役に立ってなんぼなので。そのためには、“役に立つ”ということをまず定義しないといけません。でもそれは機械からは出てこなくて、使う人に聞かないといけないんですよね。「あなた本当は何が欲しいんですか」と。
ただ、『顧客の本当に欲しかったもの』という絵にあるように、言うとおりに作ると、だいたいろくなものができません（笑）。顧客としては欲しいと思っていたものなんだけど、本当に欲しいものは、実はそれとは違うものかもしれません。
そこまで引き出さないといけないことも考えると、プログラミング作ることは、最初の段階からけっこう大変だなと思います。
プログラマーと言葉の定義が広くてまちまちだという話をしましたが、一方でわりと狭めに捉える人もいます。作るべきソフトウェアどんなもので、何をする仕事で、どういうデザインで、というの完全に決まっていて。決められた仕様を満たすようなものを書いて「以上終わり」と。次のチームに渡したらテストしてくれるので、テストで問題見つかったらそれを直します、という感じ。
こんなふうにソフトウェア開発全体の真ん中の一部の部分をする仕事を、プログラマーと捉える人もけっこういて。かつ、チームで働くからこそ、このような働き方をしている人はすごく多いです。
ですが、それはソフトウェア開発のすごく楽しい部分、デザインの部分みたいなものを放棄している感じがするんです。どういうソフトウェアを作るべきか。それによってどういう目的を達成すべきか。その仕様を決める部分の設計から関われるのは、プログラマーの仕事の中でも、すごくエキサイティングで楽しい部分だと思うんですよね。
それを「言語でキーボード叩いて記述することではないから、プログラマーの仕事ではない」と言ってしまうのは、そこを捨ててしまうのは、すごくもったいないなと思います。