同じ画面を二通りの方法で作る
ノーコードと自社開発を比べるとき、たいてい機能一覧を並べて検討する。会員登録はできるか、決済はつくか、管理画面はあるか。しかしこの一覧では答えが出ない。いまのノーコードツールはほとんどの項目に「できる」と答えるからだ。
実際に分かれるのはデータである。自社開発のバックエンドなら、会員情報も注文履歴も自分たちが契約したデータベースの中にある。ノーコードではそのツール提供会社のシステムの中にあり、画面とエクスポート機能を通してしか触れない。画面だけ見れば二つのサービスは同じように動く。違いは、その会社との関係が切れたときに現れる。
ここで誤解がひとつ生まれる。ノーコードは間に合わせで、自社開発が本来の形だという区分だ。そうではない。予約受付、社内申請フォーム、小規模なショップのように、データ構造が単純で規模が読めるサービスはノーコードで何年も問題なく運用できる。作り直しが起きるのはツールが悪いからではなく、選んだ時点で想定していなかった方向にサービスが育った場合だ。
ノーコードが実際に詰まる三つの地点
一つ目は、料金が利用量に連動して上がる構造である。ノーコードツールは多くの場合、レコード数、実行回数、ユーザー数の単位で課金する。利用者が増えれば売上も増えるサービスなら問題にならない。しかし無料利用者が多く有料転換が一部という構造だと、増えるのは費用だけで売上がついてこない。計算は今の料金プランではなく、利用者が十倍になったときの請求額でやってみる必要がある。
二つ目は、複数の人が同時に同じデータを触るときだ。在庫が残り一つの商品を二人が同時に購入したらどうなるか。自社で作ったバックエンドにはこの状況を処理する定石がある。ノーコードの自動化は順番に実行される前提で組まれていることが多いため、処理が重なった瞬間にツールがどう振る舞うかを提供元のドキュメントで確認しておく。普段は見えず、いちばん忙しい日に表面化する。
三つ目は、外部サービス連携が標準提供の範囲を超えるときである。決済、SMS、地図のように広く使われる連携はたいてい用意されている。問題は、地域の物流会社や税務システムのように、そのツールが直接対応していない相手だ。ここで迂回路を作って繋ぐことになるが、迂回路が三つ四つ積み上がると保守の難度が自社開発より高くなる。コードがないのではなく、コードが複数のツールに散らばっている状態になる。
移すときの費用を先に下げておく
三つとも先の話なので、いま判断するのは難しい。だからどちらを選ぶにせよ、今のうちに確認しておくことが二つある。
データを丸ごと取り出せるかを見る。 ツールを選ぶ前にエクスポート機能を先に確認する。画面に見えている表を表計算ファイルで受け取る水準なのか、関連付けまで含めてデータ全体をファイルや API で受け取れるのかは別物だ。将来の移行費用の大半はここで決まる。データさえ無事に出てくれば画面は作り直せるが、閉じ込められていれば人手で移す作業が発生する。
計算ルールをどこに書くか決めておく。 割引率、ランク判定、精算方法のように、自社の事業にしかないルールがある。これをノーコードツールの自動化ブロックにあちこち分けて仕込むと、移行のときにまずそのルールがどこにあるかを探すところから作業になる。逆に一箇所にまとめておけば、ツールを変えてもその部分はそのまま持っていける。
まとめると、最初に決めるのはノーコードか自社開発かではない。このサービスでデータがどう育つのか、そのデータをいつでも取り出せるのか、である。ここが決まればツール選びはその後についてくる。
すでにお使いのツールがあれば、名前だけ教えていただければ十分です。ウィプルは今の構成でどこまで進めるかをまず確認し、移す必要があるなら何から取り出すべきか順序を整理します。まだ何も選んでいない段階でしたら、作りたいサービスのお話から伺います。
似た状況なら
今の状況を送っていただければ、24時間以内に範囲と料金を返信します。