見出し画像

2030年 「エンジニアです。コードは書けません。」

昨年、メルカリのようなサービスを、10万円で作る方法を考えてみるというnoteを書いたところ、6万回近く読んでいただけました。ノーコードというプログラミングのコードを書かずにいろいろなwebサービスやアプリを作れるツール群についてのnoteだったわけですが、その中に下記のようなツイートを貼り付けていました。

こちら、Bubbleというノーコードツールを用いて作ったのですが、多くの方にBubbleを使ってみたいという反応をいただきましたので、YouTubeにBubbleの使い方シリーズを投稿しました。合計およそ5時間の動画になってしまいましたが、多くの方に「わかりやすい」と評判をいただいているので、初めてBubbleを触る方にはぜひご覧いただけると幸いです。

Glideというノーコードツールに関しても似たような反応があったので、併せてYouTubeに投稿しております。

これらの動画をYouTubeチャンネル「NoCode School」にアップしているわけですが、台本づくりから含めるとおよそ300時間ほどこのチャンネルにつぎ込んでいるものの、下記のようにまだまだチャンネルの収益化条件すら突破してないような底辺YouTuberでございます(笑)。

スクリーンショット 2020-06-21 16.52.42

僕のYouTubeの勢いが微妙な一方、2020年に入ってにわかにノーコードへの関心が高まってきました。Googleトレンドによるノーコードの検索回数やTwitter上での言及も増えているようです(参考記事)。国内外でさまざまなツールが次から次へと生まれています。

前置きが長くなりましたが、ここ1年ほど国内外のノーコードに関する動向をウォッチしてきて、今後ノーコードはどうなっていくのか、それが与える影響は何か、さまざまな事例を参考に一旦まとめてみたいと思います。皆さんがプログラミングの未来を考えるにあたって参考になれば幸いです。

プログラミング ≠ コードを書くこと

現在のプログラミングといえば、パソコンを使ってコードを入力することですが、時代とともにプログラミングの入力方法は変わってきました。初期のプログラミングは、パンチカードと呼ばれるカードに穴をあけ、これをコンピュータに読み込ませて処理を実行していました。

画像6

現代のテキストエディタのような文字単位の編集は後から一切できないという欠点から、鉛筆などを用いてカードの上辺の間隔が空く位置に書き込んでおき、あとでまとめてパンチ(穴をあける)していたようです。そして穴をあける作業を行う人をパンチャーと呼んでいました。

画像7

当時のプログラミングというのは、こういった作業のことを指していました。ちなみに下記の写真は、軍用コンピュータへ命令を出すための5MB分(62,500枚)のパンチカードの束です。

画像8

Wikipediaにはプログラミングについてこう述べられています。

ある特定のコンピューティングの結果を得ることを目的として、実行可能なコンピュータープログラムを設計・構築するプロセスのことである。

この定義内で、時代とともに変化してきたということですね。「プログラミング=コードを書くこと」というわけではありません

ノーコードはあたらしいプログラミング

この流れでノーコードについて話せば、ノーコードツールでソフトウェアの構築を行うこともプログラミングだといえます。ここからはプログラミングの入力形式以外にも焦点を当ててみましょう。

Uberでプロダクトマネージャー・テックリードを務めていたJeremy Ho氏が、昨年「ノーコードはあたらしいプログラミング」という記事を投稿しました。

記事内でこのように述べています。

画像2

今日のすべてのソフトウェアは、開発者がより効率的に作業ができるように、抽象化された層の重なりの上に構築されており、それぞれの層が複雑さをうまく隠しています。ソフトウェアライブラリは一般的なロジックを抽象化し、フレームワークは一般的なパターンを抽象化し、APIはビジネスドメイン全体を抽象化しています。すべてのプログラマはすでに巨人の肩の上に立っているわけです。
ノーコードも何ら変わりありません。ソフトウェアにおいて、コードを抽象化してくれるのです。

小難しい話にきこえるかもしれませんが、抽象化というのは、複雑なものをかんたんに扱えるようにすることだと認識していただければOKです。一般的に多くのプログラマは、いくつか独自のコードは書きながらも、オープンソースなどで先人が築いてきたコードの資産によって抽象化された処理をつなぎあわせてwebサービスなどを構築しています。すべての処理を自分でコードを書いて実装しているわけではありません。このように、現在のソフトウェア開発でも、ある意味で部分的にノーコードで実装しており、巨人の肩の上に立っていると表現されています。ノーコードはコードをすべて抽象化してくれるというだけで、本質的にはプログラミングになります。

プログラミングの歴史 = 抽象化の歴史

もう少しわかりやすくするために、もう一度過去に遡ってみましょう。専門家の方からすると少し乱暴なまとめかもしれませんがお許しください。プログラミングの歴史は抽象化の歴史ともいえます。まず、最も原始的なプログラミング言語のことを機械語(マシン語)と呼び、下記のように1と0の組み合わせで書かれたコードのことを言います。

画像3

機械語はCPUの全ての機能を直接操作可能で、CPUのパフォーマンスという点では最も効率よくプログラムを記述できる可能性があります。しかし、見てわかるとおり、人間にとってあまりにも読みにくく、書くのが大変なので、英単語や記号を機械語の処理に1対1で対応させたアセンブリ言語というものが生まれました。下記画像の左側がアセンブリ言語です。

画像4

アセンブリ言語は、アセンブラという変換器を通して機械語に変換されてCPUにわたされます。こういった機械語やアセンブリ言語のことを総称して低級言語と呼びます。これをさらに人間が読み書きしやすい形式にしたのが、我々がよく知っているC、PHP、Ruby、Javaといった高級言語です。

画像5

例えば、C言語はコンパイラを通してアセンブリ言語に変換されます。Rubyなどはまた違ったプロセスを通して実行されますが、いずれにしてもプログラミングは、人間がより理解しやすい方向に進化してきました。機械語ほどCPUを自由自在に操ることはできません。多少の制限はありつつも、充分な機能を備えた上で人間が理解しやすく抽象化されてきたということです。

この観点で考えれば、高級言語をさらに抽象化し、ノーコードへとつながるのは自然な進歩といえるのではないでしょうか。そういった意見が米国電気電子学会 (IEEE)の機関誌にも寄せられています。

ノーコードプログラミングは、ソフトウェア開発における自然な進歩です。アセンブリ言語を使用した低レベルのプログラミングから始まったもの(プログラマーが機械語に近い命令を行えるもの)は、Java、Python、C、JavaScript、および他のプログラミング言語に進化しました。この進化には、抽象化によって機械語の複雑さを背後に隠し、ソフトウェア開発者にとってプログラミングを容易にすることが含まれます。

「ノーコード vs コード」という対立構造で、ノーコードに対して「制限がつよい」「ベンダーロックインがある」といった見方がありますが、より抽象度の低いレイヤーからみれば、現在我々が一般的に使っている高級言語にも似たような問題があります。抽象度が高くなるにしたがって、自由度と簡易性はトレードオフになるのは間違いないので、そういったリスクはあるということを念頭におきつつ、自分が何をやりたいかによって最適なものを冷静に選択するべきです。

ノーコードから始めるプログラミング学習

ここまで、プログラミング言語の抽象化の歴史と、入力方法の変化について述べてきました。抽象化の未来にノーコードがあると考えると下記のようなイメージになります。

画像9

現在、プログラミング学習を始めようとするとき、一般的には高級言語のコードの書き方から学びます。アセンブリ言語を学ぼうという方は大学でコンピュータ・サイエンスを学んでいたり、低級言語に興味がある方くらいではないでしょうか?同様に考えると、ノーコードから始めるプログラミング学習というのも成り立つのではないかと思うのです。

すでに子ども向けのプログラミング教材では、「Scratch(スクラッチ)」というアメリカ・マサチューセッツ工科大学のメディアラボが無償で公開しているビジュアルプログラミング言語が使われており、世界中に5600万人以上のユーザーがいます。これもノーコードから始めるプログラミング学習といえるでしょう。

画像10

ちなみに、このnoteの冒頭で、僕がYouTubeに投稿した「Bubbleを学ぶシリーズ」のリンクを貼っていましたが、このシリーズでwebアプリケーションを作る方法を学ぶと、ざっくり下記のようなことが学べます。

画像11

これと同じ内容をコードの書き方から学ぶ場合、間違いなくもっと多くの時間がかかります。さらにコード初心者だと、構文エラー・権限エラー・環境設定ミス・セキュリティーホール・バージョンの不一致などの影響で、まったく進捗がでないことが何度も発生するのではないかと思います。まずは落とし穴の少ないノーコードでweb開発の楽しさやメリットを短時間で学び、興味があればコードを学ぶという流れの方がいいのではないでしょうか。もちろん、コードの仕組みを知っておいた方がノーコードツールへの理解も早いというのは間違いありません。ただこのあたりは学習環境の発展によってカバーできるのではないかと思っています。まだまだノーコードに関する教材が少ないので、今のところ環境的に難しい面はありますが、世界中でノーコードを学習できるサービスが立ち上がりつつあります。

日本では、僕の運営するYouTubeチャンネル「NoCode School」や、ブログ形式の「ノーコードラボ」、サロン形式の「NoCodeCamp」があります。

ノーコードからweb開発を学び、「エンジニアです。コードはかけません。」という方も将来でてくるかもしれません。抽象度の低い機械語やアセンブリ言語はまだしも、C言語すら知らない方も現在エンジニアとして働いているのですから。

画像12

プログラマの行く末

ここまでのnoteの内容だと、まるでノーコードによって従来のコードは淘汰されるといった印象を受けたかもしれませんが、そういうわけではありません。ただ、あまりにも対象範囲が広すぎるので、O'Reilly Mediaのコンテンツ戦略担当副社長であるMike Loukides氏の言葉から考えてみます。

プログラマには二種類のタイプがあるという話から始める。具体的には、いくつかのものを組み合わせてものを作る「ブルーカラー」タイプと、他の人が組み合わせに使うものそのものを作る「アカデミック」タイプの二種類というわけだが、どっちのほうが価値があるとか重要というのを言いたいわけではなくて、両方のタイプの存在とも必要なのだが、数でいえば前者のほうが、後者よりも多いはずだ。つまり、ウェブアプリケーションを作るプログラマのほうが、ウェブフレームワークを作ったり、新しいアルゴリズムを考案したり、基礎研究をやるプログラマより数が多いということ。

この記事は非常に示唆に富む内容で、後日書かれた「未来のプログラミングについて再考(機械学習とソフトウェア2.0、配管工プログラマ、オープンソースでは十分でない?)」と併せて読んでいただければと思うのですが、さらにこのように述べています。

そこでマイク・ルキダスは、コンピュータ分野の配管工はアルゴリズムのデザイナーと同じツールを使うべきだろうか? と問う。そうじゃないと彼は考えており、この既存のものを組み合わせて目的を達する、コンピュータ分野の配管工向けのプログラミング言語は視覚的にできるのではないかというのが彼の主張である。

この文にでてくる「配管工」というのは、先に引用した文内の「ブルーカラー」的なプログラマーのことを指すのですが、AIやノーコードによって配管工型プログラマー向けに特化した新しいプログラミングツールが生まれるのではないかというお話です。

これこそ半世紀の歴史がある既存のプログラミング言語ではなく、またそのパラダイムをビジュアル化しただけのビジュアルプログラミング言語でもない、「配管工」向けの視覚的なプログラミングツールがあるのではないかというのがマイク・ルキダスの見立てである。

この話をふまえると、Googleが今年の初めに買収したAppSheetがどんな方向に進化するかとても気になるところです。

配管工型プログラマーのプログラミングスタイルはより抽象度の高い方向へと向かうのでしょう。ただ、思い出していただきたいのは、抽象度が高いものほど、機能的な制限も強くなるということです。今でもシビアで高速な処理を行う場合は、高級言語の中でも低レイヤーのC言語が使われているように、行いたいことの特殊性や性能によって引き続きコードの有用性は変わりません。現在の配管工型プログラマーのコードがすべてノーコードに取って代わるというような大胆な変化ではなく、例えばエディタが便利になったり、「ローコード」という形式でコードを書く効率が上がったりといった従来のコーディングをエンパワーしていくような方向の抽象化と、「ノーコード」という形式で開発の敷居を下げ、非エンジニアをエンパワーしてくような方向の抽象化が同時進行していくと思っています。

ノーコードの影響を考えるにあたって、もう少し身近な例えをつかうとこんな感じです。

ノーコードはソフトウェアのDIYのようなものだ

便利な工具が出現することによって、例えば家具などを素人でも簡単につくれるようになりました。だからといって大工の需要がなくなるわけではありませんし、今でも大工の供給は足りていないようです(大工の人口は減っていますがこれは労働環境や若い人がいないといった問題から)。ノーコードによる影響もこれと似たようなものと考えておけばいいのではないかと思います。いずれにしても、プログラミングを低レイヤーから理解してる人であれば、新しい「構築」手法がでてきたとしても、別の新しい価値を見つけるのも容易いのではないかと思っています。

開発の民主化

ノーコードによって非エンジニアをエンパワーしてくような方向の抽象化のことを、「開発の民主化」といいます。今までコードを書ける人に頼るしかなかったweb開発が、ノーコードによって非エンジニアの方でもできるようになるという意味です。以前のnoteにも書きましたが、個人的には、業界に知見のある方が、今までコストやスキルの問題で諦めるしかなかった事業をノーコードを使って挑戦し、収益を産んでさらにエンジニアの雇用を生むというポジティブな未来に期待しています。既に国内外でいろいろな事例がでています。

新規事業としてwebサービスを立ち上げる際に注意してほしいことがあります。それは、完璧なものを作ろうとしないということです。まぁ、このあたりは僕が話すような内容でもないので、下記のような記事を参考にしてください。

もう一度ノーコードに触れてみてください

IT業界の長い方ほどノーコードに対して懐疑的になるのは仕方ない面があります。ノーコードの概念自体は新しいものではなく、これまで何度も「コーディング不要!」を謳ったツールが現れ、そのたびに期待を裏切られたり、そのツールで作られたシステムの尻ぬぐいを行ってきた悲しい歴史があるからです。「将来、プログラマは一掃される」といった過激な言葉で煽られたこともあるのではないかと思います。

8年ほど前、WixやWeeblyのようなノーコードツールが全てのプログラマの職を奪うので、ソフトウェア開発に取り組むべきではないという人たちがいた。
彼らの予測を無視したのは、自分の人生で最も良い判断だったと思う。

エンジニアの働き方も、数億〜円規模の案件を行うSIerから小規模のHP制作会社、スタートアップ企業、インフラ系などなど、企業や業界によってさまざまなタイプがあり、人によってはノーコードツールがおもちゃのように映るかもしれませんし、素晴らしいツールになる場合もあります。立場や働き方によって専門家でも意見が分かれるので、いくつか実際に触っていただき、自分なりの見方をしていただければと思います

プログラミングの抽象化は進んでいきます。いろんなツールが次から次へと生まれています。個人的に楽しみにしているのが、スマホでアプリを作れる(ツイートではウェブページといってますが、アプリが作れるようです)下記のようなツールです。

出版の民主化が起こり、本の数が爆発的に増えたように。音楽制作の民主化が起こり、音楽の数が爆発的に増えたように。映画製作の民主化が起こり、映画の数が爆発的に増えたように。ノーコードによって開発の民主化が起こり、エキサイティングな未来へとつながることを願って、最後にお気に入りの画像を載せておきます。

画像13

画像14

最後までお読みいただきありがとうございました。twitterYouTubeで引き続きノーコードについて発信していくので、よかったらフォローお願いします。



この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
ありがとうございます!
583
プログラムを書けない方でもノーコードでいろんなwebサービスをつくる方法を発信していきます!NoCode情報YouTube http://bit.ly/2KGJ4wR 個人開発 エンジリッシュ http://e-lish.io アイテマス http://aitemasu.me

こちらでもピックアップされています

#エンジニア 系記事まとめ
#エンジニア 系記事まとめ
  • 714本

noteに投稿されたエンジニア系の記事のまとめ。コーディングTIPSよりは、考察や意見などを中心に。

コメント (1)
私はプログラミングに精通しているわけでもないのですが、nocode最近職場でも興味ある人が増えてきたので、これからも楽しみにしています。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。