使いこなせなくなったRetoolアプリの置き換え. 説明用のワークド・エグザンプルであり、顧客の実績ではありません。チームと数字は仮定です。肥大したRetoolアプリの置き換えを検討する価値があるのは、運用チームが使う社内ツールが、時間を節約するどころか時間を奪い始めたときです。兆候は、誰も文書化していない壊れたクエリのほぐしにエンジニアが1週間を費やすことや、使うチームより速く増えるライセンス料です。置き換えるとは、コード、認証、監査証跡を借りるのではなく、自分で所有することです。
チームには、社内運用を回すRetoolアプリがあると仮定します。返金、アカウント変更、サポートのエスカレーションです。当初はなかった3つの性質も持っています。1人のエンジニアしか理解できない形で壊れます。画面を1つ開くだけの人にも課金されます。そして、どの修正も、誰も持ちたがらない設定の編集になります。アプリは失敗していません。チームが使いこなせる範囲を超えたのです。
#Retoolから移行すべきタイミングはどう見極めるのか
それを決めるユーザー数の基準はない。私たちが見るのは4つのシグナルだ。アプリを維持するために週に何エンジニア時間が費やされているか。1つの画面しか見ない人にどれだけの有料シートが割り当てられているか。誰も信頼できる監査証跡がないまま出荷される変更がどれだけあるか。そして新しく入ったオペレーション担当者が、エンジニアに変更を頼まなくなるまでにどれくらいかかるか。この4つのうち3つが悪い方向に傾いているなら、ボトルネックはチームではなくツールだ。
Retoolアプリを自社所有の社内ツールに置き換えるのは、いつですか
Retoolアプリの保守が節約する以上のエンジニアリング時間を食うとき、ライセンス費用が使うチームより速く増えるとき、または変更が信頼できる監査証跡なしにリリースされるときです。限界を超えた1つか2つのワークフローを、認証、ロール、ログを備えた自社所有のツールとして作り直します。残りは、困るまで置いておきます。
置き換えはどのようなものになりますか
仮定として、約40人のB2B SaaSプロダクトチームを考えます。そのRetoolアプリは、数十のクエリと、手作業で維持された権限設定に膨らんでいます。設計は、一度にすべてを作り直しません。後付けではなく最初から3つの要素を組み込んだ、自社所有の社内運用ツールで、運用チームはワークフローごとに移行します。
- アクセスの付与と剥奪を一箇所で行えるログイン機能（認証）
- サポート担当者と管理者で異なる画面を表示するロールベースのアクセス制御（RBAC）
- 誰が何をいつ変更したかを記録する監査ログ
エンジニアの時間はどこから戻ってきますか
このようなRetoolアプリは、毎週エンジニアの時間を奪います。壊れたクエリ、手作業で処理されるアクセス申請、運用チームが安全に行えないためエンジニアが必要になる変更に消えます。自社所有のツールは、その仕事を運用チームに移します。測る数字は、運用ツールにかかるエンジニアの週あたりの時間で、導入の前後で比べます。こうしたワークド・エグザンプルはジャーナルに書いています。
これはワークド・エグザンプルです。チームとすべての数字は仮定であり、顧客の実績ではありません。ここでは実在の案件は報告していません。
これは結局、より大きなベンダーロックインにすぎないのではないか
We are
私たちは、Retoolでは対応しきれなくなったワークフローの範囲を定め、認証、ロール、監査ログを組み込んだ自社所有の社内ツールとして作り直し、最初からコードベースはあなたのものです。
We aren't
永遠に借り続けるもう一つのプラットフォームではありませんし、動いているアプリを白紙に置き換える全面的なカスタム再構築でもありません。
このようなチームが最も気にかける違いは、所有権です。ホスト型のプラットフォームでは、コードは他社の側にあります。この方法で作ったツールは、最初からあなたが所有するリポジトリとして納品され、締め出されるプラットフォームはありません。これが、私たちのAI導入の仕事が社内運用ツールに取り組む方法です。
テストはこうです。古いアプリへのパッチ当てをやめた週に、エンジニアが戻ってきます。それがすべての目的です。
チームが誰も持ちたがらないRetoolアプリにパッチを当て続けているなら、解決策は別のパッチではありません。ツール、認証、監査証跡を所有することです。どのワークフローを移す価値があり、どれを残すかは、AIコンサルティングで見極め、そのうえで古いツールを超えた部分だけを作ります。何を作っているか教えてください。
