データ分析とインテリジェンス

ノーコードとの付き合い方

ノーコードについてひたすら書く

近頃「ノーコード」という言葉をよく聞くようになった。昔からツールは存在しており考え方は別に新しくもないが、なぜか急に盛り上がってきた感がある。

筆者はノーコードは結構好きだ。かといってデメリットもあるので全面的にノーコードにするわけにもいかない。結局のところ道具なので威力を発揮するかは使い手の力量次第。そこで、ノーコードとどう付き合っていくのがよさそうか自分の頭を整理してみる。

なおノーコードと言ってもいろいろあるが、SQLを書くツールを一番よく使ったことがあるのでその影響が出ていると思う。おそらく他も事情は(いまのところ)大して変わらないと思うが根本的に違うとところがあれば指摘してほしい。

ノーコードとはコードを書くことの代替

ノーコードといっても実際にやっているのはコードを書くのと同じこと。違いはツールでアイコンをクリックすることぐらい。

なのでツールを導入しただけで無駄になるのは、ツールの役割を勘違いしているからだでも書いたように、ノーコードを導入したらまったく新しいことができるとか、何を作るかを決めるのがうまくなることは無い。ある部分において実現がしやすくなるということだ。つまり他のツールと何ら違いは無い。

この認識がずれると「ノーコードを導入したら今まで誰にも実現できなかったことができるようになる」となってしまいそう。

代表的なノーコードは「ピボットテーブル」では

ノーコードと曖昧な表現をしているから過度な期待をしてしまう。もう少し具体的に考えてみるのがよいだろう。

Excelやスプレッドシートのピボットテーブルを使っている人は多い。実はピボットテーブルはノーコードそのものだ。

店舗Aの年ごとのUUと売上を集計することを考えてみよう。

ピボットテーブルでは行に年を指定し、値にUUと売上、フィルタで店舗を絞り込む。それをドラック&ドロップで行っている。

同じことをコード(クエリ)で書くと以下のようになる。SQLをまったく知らない人から見るとなんだか難しそうに見えるかもしれないが、ちょっと触ったことがある人にはごく簡単なレベルだ。

#店舗Aの年ごとのUUと売上を集計をするクエリ
select
年
,sum(UU)
,sum(売上)
from データ
where 店舗=A
group by 年

最終的にできるのは同じデータだ。

ノーコードのメリット

ノーコードのメリットを考えてみよう。

  • 細かい間違いが無くなる
  • 環境構築をしなくて済む
  • 手順がわかりやすい
  • 取り組みやすい

細かい間違いが無くなる

コードを書くとカラムや関数のスペルミス、カンマやJOINのonやcaseのendなどついうっかり忘れてクエリがエラーになることは頻繁にある。ノーコードではこの細かい間違いは一切起きなくなる。個人的にノーコードが好きな一番の理由はこれ。

特に初心者にとってこの細かいことを気にしなくて済む利点は大きいだろう。ロジックを組み立てることに集中できる。

環境構築をしなくて済む

DBやツールを自分で触ってみようとしても、環境構築の必要があり使い始めるところまでいけないことがよくある。

ノーコードであればデータソースからデータレイクに転送するには所定の位置にソースと認証情報を入力すればできる。BI(これも可視化ためのノーコードのツール)からデータベースにつないでデータが取れるのはまさにそう。

コードを書くことでも同じことは当然できるが、データをいじる以上にノーコードにすることで恩恵がある部分だと感じる。もしかしたらノーコードを導入することの最大のメリットはここにあるのかもしれない。

手順がわかりやすい

GUIでフロー図を書けるツールだと処理の流れがとても分かりやすい。コードだけだとwith句でばらすことはできるがやはりわかりづらい。

取り組みやすい

アイコンをクリックしたりドラッグ&ドロップすることは普段から慣れているためだろうが、初めて取り組む人には向いている。

非エンジニアには「コードで書く」ことはどうしても(主に心理的な)障壁があるらしい。前述のクエリもちょっとだけ勉強すればすぐ書けるのだが学ぶ人は少ない。ピボットテーブルはできてもクエリは判らない人が大多数だろう。

ノーコードのデメリット

メリットを考えたので今で感じたことのあるデメリットも考えてみよう。

  • ツールに実装されていないと使えない
  • そのツール独自の言語や機能に縛られる
  • そのツールでできる簡単なことしかやらなくなる
  • コードが書けない人がツールだけに慣れると大きな無駄を生み出す

ツールに実装されていないと使えない

当然のことながらノーコードのツールは別の誰かが作っている。すると必然的によく使う機能や関数が優先されることになる。あまり使う機会がなかったり、最近使われるようになった手法は使えないことが多い。

そのツール独自の言語や機能に縛られる

そのツールだけで使える独自の言語を多く使うことでツールの変更やコードへの移行が大変になる。

SQLをノーコードで書いているつもりが別の言語の習得も必要になり学習コストも上がる。初心者のハードルも高くなり結局なんのためのツールだったかわからなくなることも。

そのツールでできる簡単なことしかやらなくなる

観測している範囲(といっても10人以上はいる)では、ノーコードから入って誰も面倒を見ないとごく最小限のことだけしかしない。

ゼロから始める人は何ができるのか視野が狭く全体が見えていない。なので簡単なことだけで「できるようになった」と満足してしまうのではないか、と疑っている。

高価なツールを入れているのにふたを開けてみたらピボットテーブルぐらいしかしていない、なんてこともよくみかける。

コードが書けない人がツールだけに慣れると大きな無駄を生み出す

コードが書けない人がツールにちょっと慣れた時が危ない。クエリで書けばごく簡単に済むのにノーコードで無駄に複雑怪奇なことをしているのは何度も見た。

簡単なことなら適当にやってもさほど差は無いが、組み合わせが増えたり前処理が必要だったりとちょっと複雑になるとノーコードでの作業はとんでもない作業量になる。

クエリで書けば10分で終わる話を半日や1日かけてやり直すなんてことも当たり前におきる。しかも無駄なことをしている自覚が無いから改善しない。

ノーコードのツールをうまく使える条件とは

ここまで踏まえて、コードが書けない人が中心の組織においてノーコードのツールをうまく使える状況は以下のどれかになるだろう。

  • コードが書けない人が初歩的なことを自分で実現する
  • コードが書ける人が作ったものを運用する
  • そのツールで出来ることしかしないと割り切る

コードが書けない人が初歩的なことを自分で実現する

ノーコードはコードを書かなくても同じ(ような)ことを実現するツールなので、まずコードを書けない人が対象にはなる。ただ、前述のようにコードが書けない人がノーコードで複雑なことをしない方がいい。

ただコードで書くよりちょっとは複雑なことはできる、というところだろうか。SQLで言えばコードでは2つのテーブルのjoinやwindow関数を誰にでも書かせるのは危険だが、ノーコードならば大事故は起きにくい。

それ以上複雑なことはやはりできる人が担うか、できる人を育てるためにもコードでの習得に切り替えていくほうがいいのではないだろうか。

コードが書ける人が作ったものを運用する

いじれる部分が少ないのでコードを渡すよりは事故に繋がりにくそう。定期レポート作成用のロジックはコードが書ける人が作って特定の場所のパラメータだけを変更するだけにして運用するとか。

ただし定期レポートのためだけに導入してもコストに見合うかは要検証。

そのツールで出来ることしかしないと割り切る

ノーコードで完結しない部分をコードで補う方法も考えられる。しかしノーコードのツールからコードを作ったり、書いたコードをノーコードに読み込ませることはあまりできない。

であればいっそノーコードのツールで完結すること以上のことはしない、と割り切ってしまうのもよいだろう。本格的なツールであればできることは多いはず。

ただしコードで書けばすぐできるがノーコードだととんでもなく時間がかかるようなことはやらない、と握っておく必要はある。

コードが書ける人が多くいるならノーコードは必要か

コードが書ける人が多くいる組織でノーコードを使うとしたらどんな理由がありそうか。

まず、ロジックの共有がしやすいことが挙げられるだろう。メリットで「手順がわかりやすい」を挙げたがが、わかりやすいということは伝わりやすい。通常はコードを書くレベルには社内でも差があるので上級者だけがわかってあとは置いてけぼりにはなりづらい。

それから環境構築などをノーコードに担ってもらう使い方は今後広まっていきそう。

それ以外だと使う理由はあまり見当たらないような?

まったくコードを書けない人がノーコードから入るのはいいのかわるいのか

裏側で起きていることを理解できている人が監修するならあり。もしいないと、ノーコードから入ると最初に触ったツールの使い方に特化してしまう人が一定数出てくるために発展せず長期的に考えると導入に高いコストを払っても得られるものは少ないかもしれない。

理想的なノーコードツール

「ノーコード」で思いつく話をひたすら書いてみた。個人的にはコードを書くのが苦手なのでノーコードはもっと広まって欲しいとは思っている。

理想を言えば、ベースになるところはノーコードでさっと作り、細かい修正はコードでする。さらにそのコードをノーコードに反映して・・・を繰り返すことが出来るのがよい。

ただツールを提供する側からするといつでも切り替えられてしまうリスクがあるため実現は難しそうだ。そうなると使いどころや拡張性が限られてしまうために全面的に推奨する気にもなれず、悩ましい。

カテゴリー:データ分析のその他の話題