1ヶ月で1000件の申込みを捌くフォームを Retool で構築した話
はじめに
こんにちは！ダイニーのソフトウェアエンジニアの ta21cos です。
今回はローコードツールの Retool を使って弊社が提供する新規サービスの申込みフォーム、および導入プロセスの管理システムを構築した事例を紹介します。
この事例を通じて、ローコードツールの採用を検討している方、もしくはこういった裏側の作業の効率化に悩んでいる方の参考になればということで記事を書いています。
まずは構築したシステムについて触れたあと、Retool を導入したことで得られた成果、そしてその過程で感じたメリットや課題点を共有します。最後に、将来的に Retool から脱却するという意思決定に至った理由についても触れていきます。
画像は実際に使っている申込みフォームの一部です。
背景
ダイニーキャッシュレスは、2024年9月にリリースした飲食店向けの決済端末の提供サービスです（https://dinii.jp/service/cashless/）。リリース直後から多くの店舗様にお申し込みをいただいています。
一方、申込後導入完了までには「複数ツールによる審査」「設定作業」「端末の発送」など多くのステップがあります。これらのステップをスプレッドシートで管理するのではミスが起こることが容易に想像できました。
この課題を解決するため、Retool を活用して情報回収から導入プロセスの進捗管理まで一気通貫で対応する仕組みを構築しました。
まずは Retool についての簡単な紹介です。
背景
ダイニーキャッシュレスは、2024年9月にリリースした飲食店向けの決済端末の提供サービスです（https://dinii.jp/service/cashless/）。リリース直後から多くの店舗様にお申し込みをいただいています。
一方、申込後導入完了までには「複数ツールによる審査」「設定作業」「端末の発送」など多くのステップがあります。これらのステップをスプレッドシートで管理するのではミスが起こることが容易に想像できました。
この課題を解決するため、Retool を活用して情報回収から導入プロセスの進捗管理まで一気通貫で対応する仕組みを構築しました。
まずは Retool についての簡単な紹介です。
Retool とは
Retool は、ローコードでアプリケーションを構築できるツールです。ドラッグ＆ドロップ操作で直感的に UI を構築でき、また、データベースや外部 API との接続も可能です。
https://retool.com/
また以下のような周辺機能も充実しています。今回はこれらの機能をフル活用しました。
Retool DB：PostgreSQL によるデータベース
Retool Storage：ファイルストレージ
Retool Email：メール送信機能
Retool Workflow：自動タスクの実行やバックエンド的な機能を提供
Retool の紹介もできたので、実際に構築したシステムを紹介します。
実際に構築した仕組み
構築したシステムの図を示します。Retool でどのようなことができるかをイメージしていただけると思います。（Retool WF = Retool Workflow と略記しています）
各コンポーネントについて補足します。
申込みフォーム
必要な情報を入力できるフォームです。
審査の関係で集める情報が多く、50項目近くあります。
フォーム回答内容閲覧画面
営業の方向けに、お客様に記入していただいたフォームの内容に問題がないか確認するための画面です。
オンボード運用状況管理画面
運用担当の方向けに、各ステップの状況を更新・確認するための画面です。
メール送信
申込み完了時など、お客様にメールを送信する際に利用します。
Slack 通知
社内で導入プロセスの進捗を共有するために使います。
次にこのシステムを構築するために、ローコードツール、特に Retool を選んだ理由について話します。
ローコードツール（Retool）を採用した理由
実装の早さと、リソースの節約の両立
実装が始まった時期では、まだダイニーキャッシュレスの開発も並行していました。そのため割ける人員・時間が少なく、最小限のリソースで実現できる手段が必要でした。
フォームのみ提供するサービスも検討しましたが、カスタマイズ性が低く採用には至りませんでした。外部 API を呼んで入力を補完するなどの要望があり、これを実現しやすいツールであることが求められたためです。一方フルスクラッチでの実装をするリソースもなさそうでした（今だったら AI エージェントを導入すれば解決するかもしれませんね）。
柔軟なフローにし、すばやく変更できるようにしたい
設計した導入プロセスがうまく進むかどうか分からなかったため、後ほどの修正もやりやすい構造が求められました。また効率化のため、管理上のステップを追加したりすることも想定する必要がありました。
このようなニーズがあるのに通常のサービスの基盤に載せてしまうと、リリースサイクルが決まっているため頻繁な変更が難しくなることが想像できました。
Retool を社内ですでに利用していた
Retool は主にデータの可視化のために広く使われており、その有用さはすでに社内で共有されていました。使い方が分かるメンバーが複数いたので、そういったリスクは非常に低い状態でした。
Retool で構築したことで得られた成果
Retool でシステムを構築したことで、次のような成果を得ることができました。
2ヶ月 x 一人のリソースでシステムの構築に成功できた
運用の変更があった場合に30分で修正・リリースができた
3ヶ月で3000件の流入があっても致命的な問題なく動作し続けている
ざっくりとした計算ですが、おおよそ一人が専属で担当し、2ヶ月でシステムを作成することができました。さらにこのメンバーは Retool を触るのが初めてでしたが、難なく実装をこなしていました。
また、狙い通り導入プロセスの変更があった際も、すぐに修正し反映させることができました。フローの改善を議論し終わった30分後には反映できていたケースもあります。加えて、プランの追加という導入プロセスに大きく影響する変更も、スムーズに実装することができました。
このサービスはリリースから3ヶ月で3000件という想定以上の申込みがありましたが、現時点で致命的な問題なく導入プロセスを進められています。
次は Retool でシステムを実装・運用をしていて良かった点と課題となった点を挙げていきます。
Retool の良かった点
まずは Retool の良かった点です。
ハイスピードなリリースを行える
Retool というよりは、レビューやリリースフローを用意しないことの恩恵です。デプロイプロセスなど様々なセットアップが不要で、すぐに修正・リリースできるので非常に開発者体験が良かったです。
もちろんレビューを行っていないので品質管理は捨てています。今回のケースでは、ユーザーが完全に一人で進めるプロセスではなく、何かエラーが起きたらすぐ修正できる状況でした。なので、一定の不具合は許容できていました。
またRetool はリリースバージョンを管理する機能も持っているので、リリースするときの安心感もありました。また何かあった場合には revert も可能でした。
UI のあるアプリケーションの構築が楽
データをクエリして、それを利用するというアプリケーションの構築体験が非常に良かったです。クエリしたデータをテーブルに一覧表示するのもすぐできますし、またデータを編集する機能も簡単に導入できます。
Retool Workflow が便利
開発を通して一番お世話になったのは Retool Workflow だと言っても過言ではありません。
行いたい処理をグラフィカルに実装できるだけでなく、バックエンドの API を作成する感覚でまとまった処理を用意できます。
cron のように定期実行もできますし、外部のサーバから叩いてもらうこともできます。Retool のシステム側で動作するので、バックエンドの様に使え、プライベートなデータをフィルタする用途にも使えます。
また Workflow は Retool アプリケーションだけでなく、別の Workflow からも呼べるので、処理を細かく作っておくとメンテナンス性が上がります。
ありがたいのは、Workflow は各実行のログが残るので、成功・失敗したかを追うことができます。Retool アプリケーション上の処理はクライアントで動作するためエラーを追うことができないのですが、Workflow 化し Retool アプリケーションから呼ぶことで、エラーの検知もしやすくなります（監視性については後でも触れます）。
次は課題となった点です。
課題となった点
大規模な UI のメンテナンスが大変
Retool アプリケーションの編集画面では、コンポーネントのステータスをコードで編集する機能がないので、すべてを GUI で作業していく必要があります。
Retool アプリケーションで構築した申込みフォームは、初期状態で50コンポーネント、店舗を追加していくと200近いコンポーネント数のある画面です。そのため、フォーム全体に影響する修正を行うにはコンポーネントの数だけ GUI を操作する必要がありました。
特に位置については絶対座標なので、コンポーネントが下に続けば続くほど調整が必要なコンポーネントが膨れ上がっていくという構造になっていました。
（2024年終盤に Stack という、CSS でいう Flexbox な機能がリリースされたのですが、ところどころ使い勝手が悪く、位置の問題を解消するには至らない印象でした。いつか改善されるのを期待したいです。）
以上から、一度作成したフォームを大幅に刷新する、という修正は諦めざるを得ませんでした。特に影響が大きかったのはレスポンシブ対応でした。ニーズはあるのに実装できなかったのが悔やまれるところです。
（レスポンシブ対応を行うには、各コンポーネントで Desktop / Mobiile のどちらの画面に表示するか選択が必要なことに加え、位置情報もそれぞれの画面で設定する必要があります。このことから Retool でレスポンシブ対応を行えるのは小規模な画面に限られると考えています。）
一方で dashboard のようなデータの可視化・編集画面の方は非常に作りやすかったので、個人の意見としては、Retool は「データを扱う小〜中規模の画面」に向いていると思っています。
監視性が低い
Retool アプリケーション上の処理はクライアントで呼ばれるため、エラーログを出すにはそのための実装をする必要があります。もちろん様々なケースを想定してエラーハンドリングを行うことができますが、そこまでするなら普段のやり方でのシステム構築を視野に入れたいですね。
この問題は Retool Workflow を使えばある程度改善できます。前述の通り Retool Workflow は各実行のログが残るので成功・失敗を確認でき、その原因も調査ができます。
しかしこのログにもいくつか使いづらい点がありました。
まずはログのアクセス方法が（調べた限りでは）Web UI しかないので、目視が必要になる点です。加えて、過去ログのフィルタができないので、大昔のログの調査を行うのは大変です。
今回は妥協策として、Global Error Handler（https://docs.retool.com/workflows/guides/error-handlers）という機能を用いて Workflow のどこかでエラーが発生したときに Slack に通知するようにしました。
Retool 自体の制限
アカウントや契約における Retool の制限もいくつかやりにくい点がありました。
まず、アプリケーションを編集するための Editor アカウントに高いお金がかかります。Retool 自体も SaaS なので当たり前ですが…。少ない人数で開発したと前述しましたが、そうせざるを得なかった背景もあります。
また公開していないアプリケーションを閲覧するためには Viewer 権限のアカウントが必要になります（こちらも有料）。完全社内ならこれでよいのですが、業務委託先に共有する際に面倒なことになります。
あとは新機能に限る話なのですが、バグで想定通りに動かないケースに遭遇したこともありました（しばらくしたら治っていました）。
最後に、本サービスでは将来的に Retool を脱却する、という意志決定をしたので、その背景について触れます。
Retool からの脱却に向けて
本システムが動き始めてからもうすぐ4ヶ月が経過するタイミングで、申込みフォームについて Retool からリプレイスする意思決定をしました。次がその理由になります。
サービス・運用フローが軌道に乗り、変更が生じるリスクが減った
サービスをやめます、のリスクが大幅に減った状態。
また運用フローも固まってきており、大幅な修正が求められるリスクが低い状態。
監視性を中心に、手作業での運用に限界が来た
初期では手作業による監視や運用を許容していましたが、生産性という意味で犠牲にしたものは大きかったです。時間も経過し、サービスも軌道に乗ったことで、この運用が許容されなくなってきました。
ログの調査のしづらさなどもあり、エラーハンドリングを綿密に実装して解決しやすいようにしたいフェーズになったと考えています。
申込みフォームの UI を改善したい
フォームが長い、スマホ非対応という点はずっと課題でしたが、フォームの UI の規模が大きいことで手を付けられずにいました。
お客様に見える画面なので、デザイナーの手も借りちゃんとしたものを作りたいフェーズになりました。
様々な理由を挙げましたが、総じてサービスが次のフェーズに進んだから、とまとめることができると思います。
おわりに
これまで、新サービスの申込みフォーム・導入プロセスに Retool というローコードツールを選択し、効率よく実装できた事例および得た学びについてを紹介しました。最後にはサービスが次のフェーズに移ったことで、Retool から脱却するという選択をした理由にも触れました。
この記事が、リソースやスピードを理由にローコードツールを検討している方々の参考になれば幸いです。
ダイニーでは新規メンバーを募集しています。高いスピードで日々開発をしているチームに興味がある方は、ぜひ一度お話しましょう。
