「NoCode」との付き合い方

どうも、エンジニアのgamiです。

前回、「NoCode」ってときには幻想だよね、という主旨のnoteを書きました。

少し強めのタイトルがシェア欲を掻き立てたのか、僕の書いてきたnoteの中では過去一番の反響を頂きました。ありがとうございます。

前回のnoteにもあるように「本当はNoCodeツールの良い使い所についても書こうと思ってい」ましたが、記事が長くなりすぎたので前後編に分かれてしまいました。僕は「NoCode」という言葉が生む誤解を否定したかったのであって、NoCodeツールが生む価値を否定したかったわけではありません。後編である今回は、どんな状況ならNoCodeツールを使う合理性があるかについて考えます。

「NoCode」が幻想じゃないケース

前回の記事では、NoCodeの定義を次のように置きました。

本来はプログラムを書いて開発するようなアプリケーションを、プログラムを書かずに実装できるようにすること

置かれた状況によっては、所謂NoCodeツールで作られたソフトウェアが最後までそのまま使われ続けるというケースもあります。主に、実現したい内容が十分にシンプルで、独立性が高く、変化が少ないような場合、最後までNoCodeのまま完結する確率が上がります。

たとえば、「Zapierを使ってスプレッドシートの更新をSlackに通知する仕組みを作る」という内容は、十分にシンプルに見えます。STUDIOが得意とするイベントサイトやサービスサイトなどは、一般に他のシステムからの独立性が高いです。何年も変わっていない小さな定型業務をAirtableで業務アプリ化しても、予想外の要求が飛んでくることは少ないかもしれません。

ソフトウェアへの要求は次第に高度になる

一方で、使われ続けるソフトウェアには当初の想定を超えた要求が集まってくるものです。人間の欲望とは恐ろしいもので、「そんな便利なソフトウェアがあるなら、こんなことも合わせてできないか？」とついつい頼ってしまいます。もちろん、こうした要求を突っぱねて、すべての変化を拒むという道もあります。しかし、業務や生活様式は常に変化する以上、ソフトウェアも変化しなければ使われ続けません。

NoCodeツールで実現したかった目的がどんなに「シンプルで独立性が高く変化が少ない」と感じられたとしても、ずっとそのままの状況であり続ける保証はありません。当初はNoCodeに適した状況だったものが次第にその範疇を超えていくというのは、日常茶飯事です。

では、目の前のソフトウェアがNoCodeの手に負えなくなった場合、どうすればいいのでしょうか？

それ、既存のSaaSでできない？

NoCodeの話に限らず何らかのソフトウェアを独自に構築しようとしているときには、「そもそも世にある既存のもので代替できないか？」と問いかけることは非常に重要です。

特にそれが業務アプリケーションの場合、その業務領域に特化したSaaSを探してみるというのが解決策になる場合があります。たとえば、事業フェーズが進んでスプレッドシートによる商談管理では手に負えなくなりSalesforceなど営業支援系のSaaSを導入する、といったことはよくあります。

「そのシステムは必要」という話になると、すぐに「じゃあシステムの開発をしよう」という判断をしがちです。その気持ちをグッと抑えて、「すでに世の中にあるソフトウェアで実現できないか？」を考えます。ご存知の通り、システムを内製したり外注したりするには、それなりのコストとリスクを伴います。誰かがすでに近いものを開発しているなら、なるべくそれに乗っかるべきです。（中略）昨今のSaaSブームで大抵の汎用的な業務は既存SaaSの利用でカバーすることができます。

https://note.com/jumpei_ikegami/n/nf04adc9749a5

もちろんSaaSを使ったところで、今度はSaaSを使って構築された業務システムに対する要求が高度化し手に負えなくなる、という可能性もあります。しかし、優れたSaaSプロダクトは、特定の業務領域で出てくる多種多様な課題を汎用的な機能で綺麗に解いています。昨今のSaaSは外部サービスとの連携に力を入れているケースも多く、複数のSaaSを組み合わせてより複雑な要求に応えていくという解決方法も一般的になってきました。

本当の「NoCode」とは、「何も作らないこと」です。SaaSを駆使して「そもそも作る必要が無かった」という状況に持っていくことができれば、独自構築したソフトウェアのメンテナンスに苦しむことも無くなります。

価値検証のためのNoCode

一方で、いずれNoCodeツールを捨てるべき状況になるとしても、それ即ち初めからNoCodeツールを使うべきではなかったということにはなりません。特に不確実性が高いケースでは、「まずNoCodeでサクッと作って試そう」というアプローチが「何をつくるべきか」を素早く見極めるのに役立つことがあります。

ソフトウェア開発プロジェクトのマネジメントについて書かれた本には、よく「不確実性コーン」という図が登場します。当初は高かった不確実性も、プロジェクトを進めるうちに学習が進んで、だんだんと削減されていきます。

（『エンジニアリング組織論への招待』1-2. 不確実性とエンジニアリング より引用）

ソフトウェア開発においては、「どうしたら効率よく不確実性を減らせるか？」という考え方がとても重要になります。特に広く色んな人間が直接的に使うソフトウェアの場合、実際に作って使い始めてもらわないとわからないこともたくさんあります。

不確実なことの例
・そもそも使い始めてくれる？価値を感じてくれる？
・使い勝手はどう？ストレス無い？
・継続的に使い続けてくれる？
・ユーザー数は増えそう？コストに見合うだけのリターンある？

不確実性が十分に削減されていない初期フェーズで「自分たちが考えた最強のソフトウェア」を作るためにエンジニアを雇っていきなり本格的な開発を始めてしまうのは、わかりやすいアンチパターンです。まずはクイックに作ってユーザーに使ってもらい、本当に価値があるかを検証することが重要になります。そんなときに、NoCodeツールの価値が発揮されます。

新規事業立ち上げ時の価値検証にNoCodeツールを使うというのは、最もわかりやすい例の一つです。たとえば、前回も紹介したUnionは、まさに資金調達までの価値検証をAdaloというNoCodeツールで実現した好例でした。

NoCodeで資金調達まで走ってその後作り直すというのは、まさにNoCodeの正しい使い方という感じする。
"UnionはNocodeツールのAdaloを使用して作成されています。しかし、Nocodeで作成されたアプリは依然として速度、操作性の観点からUI/UXが劣るため今後はFlutterを用い..."https://t.co/kQvk7iEvN6

— gami@デジタル教育系YouTuber兼エンジニア (@jumpei_ikegami) April 3, 2021

全く新しい事業を立ち上げるときに、最低限機能する製品をひとまず作ってみるというのは、今後もNoCodeツールの重要な使い道になりそうです。若い起業家は、プログラミングを学ぶよりまずNoCodeツールを使いこなせるようになった方が有利かもしれません。

17歳の高校生が、一度諦めた事業をNoCodeの力で復活させた話

コード書けなかったら結局プロダクトをデプロイ、世界に配列すること、並べること、世界に実装することができなくて、なんか「やっぱコードを書けなきゃいけないのかな……」みたいのを思ってて、半分もう泣いてました。
（中略）
だけど、NoCodeというツールがあることで、私はこのサービスを1人で完成させることができました。NoCodeって、やる気さえあれば誰でも社会に実装できるんだなって。
（中略）
みんなもうこれで学ぶ時間はあんまりいらないんですよ。それこそつくりたいプロダクトがあれば「こういうふうに作るのか」みたいに失敗しながら学んでいって、「おっ、なんかYouTubeめっちゃわかりやすくない？」みたいな、「全然いけんじゃん？」みたいになって、全然1人でサービスってリリースできるんですよ。

「事業を立ち上げる」というほどのことでなくても、成功するかわからない実験的な試みをとりあえずやってみるという状況に対してNoCodeツールは広く役立ちます。たとえば、僕がいるプレイドという会社では、NotionとGoogleスプレッドシートなどを組み合わせて実験的な採用プラットフォームを高速に立ち上げたりしてました。

（企業連合の実験的な採用プロジェクト「issue club」をプレイドがはじめた理由）

見方を変えれば、NoCodeツールを使いたくなるようなシチュエーションは、すべて実験的な状況であるともいえます。未来の状況や要求を完全には予測できない以上は、作ったものを捨てる覚悟を常に持ってNoCodeツールを使うということが重要になりそうです。

「NoCode」をめぐるグラデーション

最後に、マガジン購読者の方に向けて、より突っ込んだ話を載せておきます。

一口に「NoCode」と言っても、それが指す実際のツールやプラットフォームにはかなりの多様性があります。「NoCode」が指すものは、特定用途に特化したSaaSを使うことと、普通にプログラムを書いて独自開発することの間に位置するはずです。しかし、そこにはグラデーションがあります。

（5分くらいで書いた雑な図）

上の図は、雑にそのグラデーションをマトリクスで表現してみたものです。横軸が拡張性、縦軸が汎用性です。

僕の中での各象限の具体例は、たとえば次の通りです。

・特化型SaaS：
SmartHR、freee、Dropbox

・特化型PaaS：
Salesforce、Shopify

・汎用型SaaS：
Zapier、Googleスプレッドシート、Airtable、Bubble

「汎用性」は「色んな業界や職種で使えるよ」という性質を、「拡張性」は「その中で独自の要求を実現できる懐の広さがあるよ」という性質をイメージしています。

上述したように、SaaSには「SaaSを使って構築された業務システムに対する要求が高度化し手に負えなくなる」という懸念があります。一方で、優れたSaaSは常に機能が追加されていきます。中でも外部連携機能やプラグイン機能などを実装し、PaaSに近付いていくということがあります。たとえばSalesforceも当初は営業支援のためのSaaSだったはずですが、その上で独自システムを構築できるようになり、PaaSを自称し始めています。また、特定業務に特化していたSaaSが周辺領域の業務でも使えるように手を広げていくという発展もあります。結果として、「使っているSaaSの進化によって、想定外の要求がうまく吸収され解決した」というケースがあったりします。

この図の中に無理やりNoCodeやLowCodeを当てはめると、次のようになります。

SaaSが一定の汎用性や拡張性を帯びてくると、「これはNoCodeだ！」と言われるようになります。あるシステムを別の領域にも転用したり、新しい機能を追加したりする場合、普通はプログラムを書いて開発する必要がありました。それを不要にしているという意味で、NoCodeの定義に合致するようになるわけです。このように、特化型のSaaSとNoCodeツールとの間は、連続的につながっています。

ちなみに、ここまでの議論は業務システムに寄っています。BtoC領域の場合は若干事情が異なってくると思いますが、似たようなグラデーションはあると思います。たとえば、新しくリテール事業を始めたいとき、Amazonや楽天などのプラットフォーム上で売る、Shopifyなどを使って構築する、普通に開発する、といったグラデーションがあります。SNSを始めたいとき、まずはFacebookグループで検証するといった手段もあるかもしれません。

別の話として、「普通に開発する」というのと「NoCodeツールを使う」という行為の間にもグラデーションがあります。前回記事でも触れたように、NoCodeツールの拡張性が極まると、もはやそれは新たな高水準プログラミング言語に近い存在になります。

もっと踏み込んだことを言えば、個々のNoCodeツールというのは新たな高水準プログラミング言語に近い存在であるともいえます。NoCodeツールを上手に使えるということは、「比較的簡単なプログラミング言語が使える」ということと同義の可能性があるということです。

たとえば、最近Excelの数式がチューリング完全になったというニュースが話題になりました。

Excelの新機能「Lambda関数」によって「Excelの数式がチューリング完全になった」とナデラCEO。プログラミング言語としてのExcel数式であらゆる計算が可能に

「チューリング完全」とは、おおまかに言えば、コンピュータで計算できるあらゆる計算を表現できること、ということになります。
一般に、プログラミング言語はチューリング完全であり、ExcelもマクロやVBAなどExcelに備わっているプログラミング言語を利用すれば以前からチューリング完全の状態でした。
しかし今回ナデラ氏がツイートしたのは、そうしたプログラミング言語を用いず、Excelのセルに入力される数式だけでチューリング完全を満たした、ということなのです。
しかもナデラ氏は「世界で最も人気のあるプログラミング言語の」と、あたかもExcelの数式がプログラミング言語であるように表現しています。

NoCodeツールだと思って使っていたら、もはや気付かないうちにプログラミングをしていた、と言えるような状況もあります。

さらにわかりやすい例として、「NoCodeツールを謳っているが実はソースコードの一部を直接編集できる」というようなツールもあります。たとえばShopifyでは既存のテーマを元にECサイトの見た目の一部をGUIで変更する機能だけでなく、テンプレートファイルのHTMLを直接編集する手段を提供しています。こうしたツールがLowCodeと呼ばれる場合もあります。

逆の方向からも考えてみましょう。NoCodeツールなどを使わず「普通に開発する」ケースであっても、実は1から全て開発をするということは稀です。現代のモダンなソフトウェアのほとんどは、何らかのフレームワークやライブラリ、開発者向けのクラウドサービスなどを組み合わせて開発されます。結局そこにあるのは、「どのくらい独自に開発をするのか」という程度問題でしかありません。

というわけで、「NoCode」という表面的な言葉で理解した気になるのではなく、こうしたグラデーションの中で戦略的にNoCodeを謳っているツールを組み入れていくことが必要になりそうです。