ローコードツールで、“属人性”から“チーム開発”へ　ツールで解決する「社内ツール開発」の課題

ローコードツール導入への抵抗感と課題

及川卓也氏（以下、及川）：じゃあちょっと画面をこちらにもらって、このあと3人でトークしていくようなかたちを取りたいと思います。一応トークテーマはこのように決めていますが、必ずしもこれに沿う必要はないので、ざっくりこんな話をしたいなと。あとやはり「クエリア」を連呼していますけども、クエリアみたいなノーコード、ローコードかな？　ローコード管理ツールというふうに、聞いている方は置き換えていただいてもいいと思います。

だいたいやはり使う勘所とか、使う時に気をつけなければいけないこととか、もしくは使う前がどんな状態だったかというところがみなさんに伝わればなと思います。この「クエリアを使うきっかけ」というのは、正直に話をすると私が吉田さんと知り合いで、吉田さんの会社の応援をしていたというところで、「クエリアってなんかすごいらしいぞ」と。

吉田暁氏（以下、吉田）：はい（笑）。

及川：というのを、田中さんに「使えるところは使おうよ」と、ずっと言っていたという感じなわけですよね。田中さんは存在も知っていたわけですけれども、一番最初の印象とか、及川から「使ったほうがいいんじゃないですか？」と言われた時の正直な印象というのは、どんな感じだったんですかね？

田中洋一郎氏（以下、田中）：確か記憶だと、始めに「こんなのがあるから使ってみたら？」と言われて、半年以上使わなかったような記憶があります（笑）。

及川：（笑）。どうしてですか？

田中：なぜかと言うと、まず新しいものを覚えるのが「なんだかなぁ」という、この老害っぷりな僕の性格と、あとはやはり自分で作れる自信があるし、時間さえあればきっとできる。自分で作れば当然自由に作れるし、何か変えたい時も自分の裁量でできる。つまり、できなかった時にどうしようと悩む必要が、自分で作れば当然ないわけです。なので「自分で作ればいいかぁ」と思っちゃうのが先行していた感じですね。

及川：なるほど。吉田さんにちょっと聞きたいんですけど、なんか今の田中洋一郎さんみたいな感じで嫌厭する人って多いんですかね？

吉田：けっこうそこが個人的に課題だと思っているんですけど。そもそもクエリアを着想したきっかけ自体が、表のReactとか、Vueとか、HTMLとかがあまりわからない人。特にバックエンドのエンジニア向けに作ったというのが最初でして。だからわりと全部できちゃう人にとっては、全部作れちゃうというのが正直なところだと思うんですけど。必ずしもそういう人ばかりじゃないと思っているんですね。

なのでけっこうバックエンドの人ってSQLとかは得意だし、APIを作るのは得意だし、インフラを作るのは得意だけど、意外とHTMLとかCSSはあまりわからないみたいな人がけっこういると思うんですよ。そういう人がパズルみたいな感じでUIを構築できるというのが、そもそもの着想だったんですよね。なのでけっこうReactまでわかっちゃう人だと、なんか「作ればいいや」というふうに最初は思っちゃうと思うんですけど、でも実際に使っていただければこの良さがわかってくれるかなというのが今の状況ですね。

及川：なるほど。

田中：あと加えるとすると、当然僕も49歳になるんですけど、いろんな会社でいろんな管理ツール、社内向けの管理アプリをずっと作ってきました。そこで求められるものって先ほどは性善説みたいな話があったんですけど、昨今コンプライアンス重視の中でなかなか性善説ではもう立ち行かなくなってくるんですよね。誰が・何をしたのかという証跡を全部残さなくちゃいけない。

それがお金を扱うものになると監査の対象になったりとかするので、そういったちょっと監査の話までいっちゃうとあれですけど。少なくとも誰に何をさせるのか、何を許可するのかというところがちゃんと整備されている状況でないと、企業として「社内だから」というのでけっこう許されない感じになってきて、そういったところも作り込みとかというのをやっていかなくちゃいけないというのを知っている身からすると、なんかそういったところまでカバーしてくれるのかな？　みたいな（笑）。

そういったところもあって、じゃあそのツールはどこまでできるんだろうみたいなところを、やはり調べるところから入らないといけないんですよね。なんかそういったところも、なかなか僕の腰が上がらなかった理由かもしれないですね（笑）。

吉田：逆に言うと、けっこう画面をただ作るのって、Adobeライブラリとかを使えば簡単だと思うんですよね。でも意外とそれこそ権限管理とか、監査ログを取らないといけないとか、なんか管理画面における周辺のいわゆるコンプライアンス的な機能のところを全部揃えるとなると、プロダクトレベルで作り込まないといけなかったりするので、けっこう実装が大変だったりするんですよね。

なんかそういうのが全部入っているというのがわかっていただければ、「なるほどな」と思っていただけるんですけど、なんかそれをうまく伝えるところはけっこう難しいなと思いつつ、実際に使っていただければその便利さがわかっていただけるんじゃないかなというところですね。

ローコードツール導入のきっかけと決断

及川：じゃあ、そういう、なんか使い始めて、いざ何かやろうとしたらできなくて結局自分で作らないといけないやということが起きるのを恐れていた田中洋一郎さんは……。

田中：（笑）。

及川：でもそういうわけじゃないですか。

田中：そうですね。

及川：どうして「これ使ってみてもいいかもな」と思ってくれたんですか？

田中：やはり、いざ作らなくちゃいけないという自分がそのタイミングになった時に、じゃあ果たしてイチから作るべきなのか。本当に便利そうなら使ってみようかという選択を迫られるタイミングが来たんですね。そこでJasmine Teaであれば運用する、実際に裏側で運用している人間、しかもデータベースを触ってゴニョゴニョするのって、はっきり言えば最初は僕だけだったんですよ。

なので例えば使えなかったとしても、あとで僕が作ればいいだけの話だし。実際に使えるんだったら「おぉ、それはめっけもんだな」と思って、じゃあ試しにやってみるかというふうにチャレンジしてみたというのが使い始めたきっかけですかね。

及川：なるほど。じゃあちょっとこの次のところの2つ。使わなかったらどうしたかと、出会う以前はどうしていたかと。同じ質問なので、もし使わないという決断をしていたら田中さんはどうしていました？

田中：しばらくは、たぶん画面を作らなかったと思います。コマンドラインのスクリプトで何とかしちゃっていたんじゃないかなと思いますね。それで完全に属人性が発生する状況になって、誰かが何かを運用したいとなった時には必ず僕にお願いをして、僕がコマンドを叩くみたいなところがしばらく続いたんじゃないかなと、想像します。

及川：吉田さん、おそらくそういう組織ってけっこう多いんですよね？

吉田：めちゃくちゃ多いと思いますね。そうですね。なので実はけっこうエンジニアの採用とかをいろいろがんばっている会社さんっていろいろあると思うんですけど、既存のエンジニアが今何をしているのかという話って、あまり着目されないというか。なんかエンジニアが1人増えたけど、1人分のエンジニアリソースを既存のエンジニアリソースから捻出できる可能性もあるかもしれない。

だから実は1日に何十分か、そのスクリプトを実行してくださいという依頼に頭を使うことで、今やっていた対応を止めなきゃいけなかったりとか。なんかそれってたぶん10分以上の損失になると思うんですよね。なんかそういったところがもちろん属人性も上がってきますし、なんかそういったところが1個、ローコード／ノーコードに社内ツールを置き換える大きなメリットなのかなとかは思ったりしますね。

ローコードツールによる組織への影響

及川：それとあともう1つ大事だなと思うのが、開発組織の生産性がテーマなんですけれども、今言われたように本当に必要なところに貴重なエンジニアリングリソースを配分するというのがあると同時に、例えばエンジニアじゃない人から「これやってよ」というふうに頼まれてエンジニアがやるというのは、組織にもよるかもしれないんですけど、頼む人も心苦しいことが多いんですよ。

ちょっとこんな簡単なことなんだけれど、自分じゃできないから忙しそうなエンジニアにまた頼まなきゃいけない。ついつい、本当はいろいろとデータを集めたかったり、何かお客さんのためにやる処理をしなきゃいけないんだけれども申し訳ないからって後回しにしちゃったりして、でもビジネスの損失になるかもしれないし、会社全体のコミュニケーションが非常にギスギスしたものになるというところがあるかなというふうにも思います。

だからちょっとJasmine Teaとは別のプロダクトなんですけれども、我々が社内ツール的に使っていたもので、なんかFirestoreみたいな、たぶんこうだろうとわかったら私が昔動かして自分で直に直したらサービスがいきなり動かなくなったんですね。「田中さん、なんか動かなくなった」って言って、「及川さん、何やりました？」と言われて話しをしたら「そんなことやったらダメですよ」って言われて、ひたすら謝ったことがあるんです（笑）。

なんかやはり、何でしょうか。先ほど言った性善説が成り立たないというところもそうだし、だから僕もそこで田中さんに頼むのが申し訳ないなと思ったから、技術者だから「たぶんこれはこうだから、ここはこう直せばいいだろう」と思ったら大間違いだったというのがあるわけで、そういうのをやはりちゃんとなくせるというところが非常に価値があるかなというふうに思いましたね。

田中：即、権限をはく奪しましたね。

（一同笑）

及川：ですよね（笑）。

田中：「危険！」って（笑）。

クエリア導入後の変化と利点

及川：じゃあ、ちょっともう少しだけ話してラップアップにいきたいんですけども。クエリアを使ってどう変わったか。田中さんに話してもらうのがいいかなと思うんですけど、Jasmine Teaの先ほどの管理画面をどういうふうに使うようになっているかですね。

そこらへんを、Jasmine Tea自身は最初からクエリアが画面を作っちゃっている。管理画面を作っているんですけど、仮にコマンドラインでやっていたとか、以前の社内ツールはそういった直にデータで触るようなかたちだと思うんですけれども、それからどういうふうに変わったかというのを話してもらうと、どうなりますか？

田中：まず、コマンドラインからボタンを押せるようになったというのはすごく大きいのと、お手製で画面を作っていくのって慣れていてもやはり面倒くさいんですよね。なので本当に昔でいう「Visual Basic」の画面ポチポチで画面を作って。

及川：コントロールを並べるようなやつですね。

田中：そうです、そうです。あんな感覚で作れれば、本当にそれに越したことはないなというのと、先ほどデモでデータソースを作って画面から引っ張ってきてテーブルを表示してとか、その逆ももちろんできると思うんですけど、そういった管理ツールがやることって、データベースに何かを投入したり、表示したりということが8割、9割。ほぼそれで占められるので、やることって意外と単調だったりします。

なのでやることが単調で、しかも画面が決まり切っているのであれば、もうプログラムをほとんど書かなくてもやれるものがあれば、やはりそれに越したことはないなと。しかも自分でなんか少ない時間で作ったものよりも見た目がそれなりにきれいに整うので、それに越したことはないじゃないですか。

あと、社内でもけっこう及川さんと話している中で、僕がクエリアで画面を作って、ちょっと及川さんから「使い方のレクチャーをしてくれ」と言われたり、「マニュアルを作ってくれ」と言われて、僕からすると「え、いる？」みたいなぐらい、クエリアで作った画面ってけっこう直感的になるなと。なぜなのかはわからないけど。なんかそんな印象があって、実際に及川さんに見てもらった時にも「これなら使い方もわかりますね」みたいな感想でしたよね？

及川：そう、田中さんが「（マニュアルは）いらない。作りたくない」。いらないだろうというのをすごく醸し出していたので、「じゃあいったん見てみます。わからなかったら作ってもらいます」と言ったら、見たらもうまったく必要なかったので、「これはマニュアルなんか不要ですね」という、直感的な操作でできるようなところは感じますね。

吉田：けっこう管理ツールといえど、エンジニアが作れるは作れる。先ほど話があったと思うんですけど、じゃあ果たしてデザイン的に使いやすいものが作れるかという話は、また別じゃないですか。

そうなった時に、わざわざそこにデザイナーが入ってくるのかとか、なんかじゃあデザイナーが入ってくるんだったらデザインバグとか、まったく違うものができたということに気を遣いだすと、それはそれで求められるエンジニアリングのレベルが上がってきて、時間がどんどん増えていくみたいなことも発生するので、なんかそういうところも含めてやはり誰が作ってもなんかいい感じにできるみたいなのは、ローコード／ノーコードの1個の特徴かなとは思いますね。

田中：そう思います。

及川：そうですね。

田中：適度な制約があったほうがたぶんやりやすいんですよね。出来も良くなると思うんですよ。そこの制約がうまい具合に入っているなという印象がありますね。

（次回へつづく）