はじめに
ノーコードツールが出回っていますが、ソフトウェアエンジニアにとってはあまり馴染みがないものです。何故売れてるんだろう？と不思議に思いませんか。
だからこそ、ノーコードツールの価値、使いどころをソフトウェアエンジニアが分かっておいた方が良いのかもしれない。
ということで今回は、エンジニア視点とビジネスサイド両面から見たノーコードツールの価値と役割について掘り下げて考えてみます。
エンジニアの自分）ノーコードの存在意義が分からない。メンドイ
私自身、エンジニアとして日々コードを書いてきました。正直なところ、ノーコードやローコードツールでできることは大抵自分で実装できてしまう。
「GUIでチマチマやるより、コード書いた方が早い」と思ってしまう。
エディタでもない、ターミナルでもない、わざわざブラウザ上でポチポチやることに、なぜ時間をかけるのか。バッチ処理やワークフロー作成とかだってコード組んだり、CLIで実行できるほうが明確だしUIに振り回されることもなくラク。
マーケターの自分）他の人が面倒見れないツールを作ってしまう
しかし、現在、僕が身をおいているのはマーケチーム。ビジネスサイド。
エンジニア時のノリでツール用にコードを書いていて、ふと気づく。
僕がツールを作っても、同じチームのメンバーはコードメンテが出来ない。シェルスクリプトとか渡しても果たして動かしてくれるか…。
作るものに縛りがあるなぁ。他の人に使ってもらうにはUI必須だ。GASでつくれば他の人も使えそうだけど、バグった時のメンテは全部自分だよなぁ…など。
チームメンバーへの甘えに気づく
ビジネスサイドのメンバーはまずgit pullとかしたこともないし、シェルスクリプトも実行できないし、SQLも書けないし、デバックも出来ないし、コードベースのconfigファイルもイジれないし、ハードコーディングの一部分を書き直すことも出来ない。
これまでサクッと作ってたツールは、使い手を選ぶものだった。
よく考えたら今まで僕は「チームメンバーがソフトウェアエンジニアであることに甘えていた」んだな、と。
"スキマの改善"を救うのがノーコードツール
そうすると、ソフトウェアエンジニアが改善して、コードメンテすれば、チームとして取り組めて良いよな。
ということで、業務改善としてエンジニアに依頼しよう！
しかし、開発チームにも開発の優先度がある。つまり優先順位が低くてなかなか改善が進まない業務プロセスが無数に出てくるわけです。
これは前回のブログでも書いた内容です。 リンク：誰のための自動化？
このベン図の中の「スキマの業務」を埋めるのが、ノーコードツールです。
ノンプログラマーにとっての「実行環境」
改めて、手札が変わって気付かされたこと。
ビジネスサイドの人々は、根本的に「実行環境」がない。GitHubやCI/CDなどの環境もない。クラウド・インフラ環境へのアクセス権もなければ、そもそもインフラが無い。ソフトウェアエンジニア恵まれてたなぁ。
そんな中で、自分たちの手で業務効率化や自動化を実現できる唯一の「実行環境・選択肢」が、ノーコードツールなのかもしれません。
エンジニアにとっての「手離れの良さ」
もう一つ、大きな価値は、エンジニアの手離れの良さです。
社内向けのツールやちょっとした業務支援システムをエンジニアが作ってしまうと、その後のメンテナンス責任も伴います。機能追加・不具合対応・環境構築……すべて自分に返ってくる。
しかし、ノーコードツールを活用すれば、運用や保守はベンダー側に任せることができ、エンジニアは本当に重要な開発業務に集中できる。
CMSやSaaSと同じ発想：抽象レイヤーを上げる意味
ここまでを整理すると、ノーコードツールの価値は
- プログラムを抽象化し隠蔽すること
- ノンプログラマーであるビジネスサイドに「実行環境」を与えること
インフラを抽象化したIaaSやPaaSと同じように、「プログラミング」という行為を抽象化して、より多くの人が扱えるようにしたのがこれらのツールと言えそう。
昨今のCMSやSaaSもこの役割と言える。
つまり、「レイヤーを上げることで、扱える人口を増やす」ということ。
これはDockerとかもそう。プログラミング言語も機械語を抽象化してますね。その結果プログラマ人口を増やしていると言えそう。
適材適所としてのノーコード・ローコード
もちろん、業務に強く依存した独自仕様のものはエンジニアが設計・開発・運用するべき。しかし、ある程度の汎用性があって、自動化でカバーできる業務なら、ノーコード・ローコードで十分。
特に、初期構築だけエンジニアが関わり、その後はビジネスサイドに引き継いで運用を任せる形は、理想的な分担かもしれませんね。
ツール爆発、Config地獄、マニュアル地獄
ここまで、ノーコードツールはビジネスサイドの味方ではあるということを書いてきました。
でも正直、良いことばかりでもないです。
ツールが多様化・複雑化したときに起こることは何か？ツール爆発です。ツール多すぎ問題。
複数のツールをまたがるコンテキストスイッチ、入力内容の転記。コピペ。そこにまつわる人為的ミス。爆発したツール同士を結ぶのは人です。ツール間のインテグレーションはだいたい後回しになったり、プラグインがなかったりします。
また、秘伝のタレ的な設定値もツールの数だけ必要です。マニュアルも必要。ああだからGUI嫌なんだよ（）
ツールも経年劣化するし、お金がかかるし、サイロ化する
実行環境を得たとしても、ツールの品質やユーザビリティの影響をモロに受けてしまいます。導入すればいいってものでもない。ツール自体のバージョンアップや運用管理者なども必要ですよね。
もちろんお金もツールの数だけかかったりします。
また、部署ごとに「うちではこのツール使ってるから！」という局所最適を生み出しかねない。
銀の弾丸欲しいよ〜
今、考えるべきこと
ビジネスサイドをよく見ると、現場をワークさせているのはSaaS、CMS、SFA、CRM、MAなどたくさんのいわばノーコードツールです。そしてなぜノーコードツールのニーズがあるか？もう分かったと思います。そして「そこにある問題」「何故それが起こるべくして起こるのか」も。
エンジニアがそれらを理解し、適切に業務システムと使い分けることができれば、組織全体の開発力と生産性に良い影響を与えそうです。
ツールを使うべきか
「自分で作るべきか、それとも任せるべきか」その判断こそ、今エンジニアに求められているスキルかもしれません。
また、ビジネスサイドのメンバーも「ノーコードツールを選定すべきか、エンジニアに依頼すべきか」特性や領域を理解した棲み分けが重要になりそうです。
いつ捨てるべきか、標準化すべきか
あとは「捨てるべきツールは何か」を見極めるのも大事そうです。業務丸ごと要らないじゃないか？Fit to Standardなど考えることも大事ですね。ありがちな話ですが。
まとめ
ということで本当にとりとめもなく書きましたが、まとめます。
- ノーコードツールはビジネスサイドのための抽象化
- ノーコードツールが使われるのは、実行環境が無いから
- 便利だからといって導入しまくると、ツール爆発は起こり得る。銀の弾丸はない
- ツールにするか業務システムに落とし込むか。エンジニアとビジネスサイドが相互の視点で考えるべし
- ツールも業務システムも経年劣化する。捨て時、改善のタイミングが大事
- 「業務そのものが本当に必要か」まで考えれるとより本質的
ということで、ソフトウェアエンジニア、SRE，情シスエンジニア、ビジネスサイド、リーダー、経営陣とかみんなで考えていこうね！
