スマートキャンプでエンジニアをしている瀧川です。
みなさん、NoCode(ノーコード)やLowCode(ローコード)をご存知でしょうか？
考え方としては昔からありましたが最近国内で急速に注目されてきており、今月始めにはNoCodeツールであるAdaloを使って開発されたアプリが資金調達したことでさらに勢いが増したと感じています。
日本初！Nocodeで作成されたUnion -大学生のためのSNSがシードラウンドにて1,000万円の資金調達を実施｜Anlimited株式会社のプレスリリース
NoCodeの利点といえばなんと言っても、エンジニアがプログラムを書くことなくアプリケーションが作成でき、かつ公開までできるところにあると思っています。
ではすでにエンジニアが在籍しているITベンチャーにとって、NoCodeはどんな価値があるのでしょうか？
そして働くエンジニアとしてどのようにNoCodeと向き合っているのか、そういったことを社内の取り組みを紹介するとともにまとめてみようと思います！
NoCodeとは
NoCodeとは特定のサービスや機能を指すのではなく概念なので決まった定義はないのですが、私は プログラミングをはじめとした専門知識がなくとも、アプリケーションを実装できる ツールやサービスの総称だと捉えています。 (LowCodeは一部分にプログラミングを用いる)
一般的に以下のようなメリットがあります。
- 必要な専門知識が少ない(非エンジニアでも実装が可能)
- GUIで抽象化されているため少ない工数で実装ができる
- インフラなども隠蔽されているため気にする必要がない
具体的なサービスだと、先に取り上げたモバイルアプリ構築のためのAdalo、静的Webサイトを構築するためのSTUDIO、データベースなども内包したWebアプリ構築のためのBubbleなどが挙げられます。
NoCodeと自社の向き合い方
そもそもなぜこのタイミングで、組織的にNoCodeに注目しているのか。
その理由は大きく分けて以下の2つになります。
- NoCode黎明期での早期キャッチアップ
- 社内の課題解決
1つ目については、言わずもがなですが流行の移り変わりが激しいIT業界において、「なにか怪しいもの」のように思われている状態からキャッチアップすることで先行者利益を得ている事例はネットの歴史上多いと考えています。 例えば毛色は違うものの、仮想通貨は良い例だと思います。
NoCodeについては、すでに遅いかもしれませんが、ここからの成長性も考えて今からでも動くべきだと判断しました。
また2つ目については、弊社は私含めエンジニアが在籍し、日々既存サービスであるBOXILやBALES CLOUDの改修や新規サービスの実装に取り組んでいます。
ただ潤沢にエンジニアリソースがあるわけではなく、社内の業務課題やアイディアの実現に手が回っていないという実感がありました。
そこでエンジニアの担当領域を、非エンジニアに分散できる可能性があるNoCodeツールを試すことにしました。
また昨今のWeb系技術(Next.js, Vercel, Firebase等)の進歩で開発速度も向上しているものの、やはり特定の領域まではNoCodeの方が圧倒的に早いのではという思い、どこまでなにができるのかをエンジニアとして理解したいという気持ちもありました。
想定している使いみち
実際に今NoCodeの使いみちとして考えているのが以下の2つです。
- 業務効率化のための社内ツール作成
- 新規サービスのプロトタイプ作成
これらがどの程度、どのツールで実現可能かを社内で検討しています。
1. 業務効率化のための社内ツール作成
バックオフィス系や部署や役職毎に細々とした業務が社内には数多あり、ツールやSaaS導入ができてないものも多いです。
そういった場合、以下のようなアプローチをとることが多いと思います。
- 商用ツールやSaaSの導入検討
- エンジニアに開発を相談
- 自分たちでSpreadsheetなど使い効率化
これらにはそれぞれいくつかの課題があると感じています。
「1. 商用ツールやSaaSの導入検討」では、そもそも業務がドメインに特化しているためサポートしているツールやSaaSが見つからないことは多いですし、「2. エンジニアに開発を相談」では、改善の効果と実装コストが見合わずリソースが割けないとなりがちです。
「3. 自分たちでSpreadsheetなど使い効率化」は良いアプローチだと思いますが、何枚ものシートが関連し、いくつもの関数が組み合わさり...と負債化しているものをエンジニアがヘルプにいくといった構図が今までも何度かあり、運用やメンテナンス性を考えると限界があると感じています。 (コピペミスで関数が壊れましたといった相談を受けることもありますね)
こういった問題点をNoCodeを使うことで解消できるのではと考えています。
- ドメインに特化した機能を実装できる
- エンジニアリソースを使わない
- Spreadsheetなどより機能の制限ができるのでオペレーションミスなど起きにくい
※ 後述しますが、負債化についてはNoCodeでも完全には解決せず、エンジニアが入る方がいいと考えています
2. 新規サービスのプロトタイプ作成
新規のサービスや機能を作る際には以下のようなフローになることが多いかと思います。
- 仮説
- 検証
- プロトタイプ実装
- 検証
- プロトタイプ修正
- 検証
- ...
仮に、「仮説や検証は企画職が担当、プロトタイプは初期ではGoogleFormを利用、検証が進んだらエンジニアが再度プロトタイプ作成」のようなフローだった場合と比べ、NoCodeを使うことで早い段階でクオリティの高いプロトタイプが導入でき、検証精度の向上が期待できます。
また検証中のプロトタイプ修正も、エンジニアが入ることが減り、修正して検証のサイクルも早くなると思っています。
社内NoCode勉強会開催
ここでは実際に社内で実施している取り組みのNoCode勉強会を紹介します。
目的は前述した社内ツール作成やプロトタイプ作成を念頭に置いたNoCodeツールの調査及び習熟となります。
今年3月くらいから発足し、毎週1時間ランチを食べながらも可というルールで実施しています。
参加者については現在はプロダクト開発に直接関わるメンバーとして、プロダクトマネージャー、プランナー、デザイナー、エンジニアが任意で参加しています。
今の参加者が推進者として、セールスやメディアの部署に展開できるようになるとよいかなと感じています。
直近の内容としては、Bubbleをメインに触っており、モブプロ風にチュートリアルを実施したり、業務課題改善についてどの機能を使えば実装できそうかディスカッションしたりしています。
またNoCodeに関する事例やアイディアを集めるために、Slackチャンネルも作りわいわい盛り上がっています。
実施しているなかで参加者からは、NoCode開発合宿がしたい、部署立ち上げても面白いかもといった声があがったりと、今後社内の文化の一つになればいいなと思っています。
エンジニアのNoCodeへの向き合い方
NoCodeによりエンジニアが不要になることはない、というのはよく言及される内容なので理解されている方も多かと思います。
今回エンジニアの私がNoCode勉強会や個人でNoCodeツールを触っていく中で、現状エンジニアが主導する必要があると感じたのは以下になります。
- アプリ開発に必要な概念(DB、イベント、条件分岐など)の教示
- 業務や要件の整理
- 外部のAPI連携などNoCodeツールで完結しない要件のサポート
GUIで操作可能で抽象化されているとはいえ、データベースやスキーマの概念や、イベントや条件分岐、エラーハンドリングといった要素は、勉強会をするなかでも非エンジニアの方が難しいと感じているようでした。 それを更に組み合わせてアプリケーションを作成していくのはやはりそれなりの経験値が必要なので、この点はエンジニアが指導者になるほうがいいと感じました。
業務や要件の整理は、「業務効率化のための社内ツール作成」についてでも書きましたが、複雑な業務をそのままNoCodeで実装したとしても、作るコストも管理コストも高くなってしまいます。 その点についてもエンジニアが一日の長があると考えているので、サポートしていく必要があると思います。
あとは実際に実装のアイディアを考えてみるとNoCodeツールだけで完結するものは少なく、例えば自社サービスのデータを取得する必要があったり、Gmailをフックする必要があったりといった要件が挙がります。 そういった場合に、エンジニアが実装する必要があるのか、それとも他のツールと連携させるとよいのかといった判断にまずエンジニアが関わる必要があると感じています。
そして必要であればプログラミングをすることになるかなと思います。
余談ですが、エンジニア視点でもNoCodeツールを使い実装するのはどんなフレームワークで実装するよりも早いと思うので、スキルの一つとして学んでおくのがいいと感じています。
ここからさらに急速に成熟する可能性もあり、しっかりとキャッチアップしていくべきだと思います。
まとめ
弊社がNoCodeとどのように向き合っているか、実際の取組みを含めて紹介させていただきました。
当初はできないことも多いのではといった懸念もありましたが、実際に触っているとNoCodeの盛り上がりを裏付けるようなツールとしての成熟度の高さを感じていますし、これから更に事例も増えていくと思います。
ケースバイケースで必要な技術を使えるのがエンジニアの本質的な強みだと思うので、手段の一つとしてNoCodeに触れていくのは大切だと感じています。
そんな今後のNoCodeの発展がエンジニアとしてとても楽しみです！
