AIで作ったアプリが最初のバージョンを卒業するとき：リファクタリングか、作り直しか

あなたは何かをリリースしました。ユーザーに気に入られました。今や10人のユーザーがいて、彼らは最初の形には収まらない機能をほしがっています。あなたは分かれ道に立っています。新しいユースケースに合うようにアプリにつぎはぎするか、それとも最初のバージョンは試作品だったと認めて、ちゃんと作り直すか。これは、ほかのどんな問題よりも多くの小さなプロジェクトを葬ってきた問いです。なぜなら、これには技術的な答えがないからです — あるのはビジネス上の答えだけです。

アプリが成功していると気づく瞬間

AIで作ったアプリのほとんどは、あるものとして始まり、別のものになっていきます。コーチング業のためにクライアントの問診フォームを作ったら、今度はクライアントが過去の予約を見たり、自分で予約を取り直したりしたいと言い出す。リードのスコアリングツールを作ったら、今度は営業チームが要約をCRMに書き出してほしいと言う。ファイリングのシステムを作ったら、今度はその中で共同作業をしたいと言われる。

どのリクエストも筋が通っています。そして、そのどれもがアプリを、作られた本来の姿から少しずつ引き離していきます。そしてある時点で — 半年後か、二ヶ月後か、ときには二週間後に — あなたは摩擦を感じます。追加するものすべてが土台と戦っています。新しい機能には「ああ、まずその部分を作り直さないと」が必要になる。アプリの動きが遅くなる。変更にかかる時間が長くなる。

その感覚こそ、これがまだ同じアプリなのか、それとも卒業してしまったのかを考えるべきサインです。

リファクタリングで得られるもの、失うもの

リファクタリングとは、同じアプリを保ちつつ、その上にもっと積み上げられるように整理することです。AIビルダーに、コードを整理し直す、複雑になりすぎたワークフローを分割する、機能の寄せ集めになった画面を設計し直す、といったことを頼みます。数時間で済みます。新しい機能は増えません。ただ土台が強くなるだけです。

リファクタリングがうまくいくと、まるで魔法です。アプリと戦っているように感じていたのが、突然そうではなくなる。以前なら3週間かかったような新機能を、1週間で3つ追加できたりします。

ですが、リファクタリングが効くのは 問題が、今あるものの「形」にある場合だけ です。問診フォームを作って、ユーザーがもっと速い問診フォームをほしがっているなら、遅い部分のリファクタリングは半日仕事です。彼らが、速くてかつ履歴も保存する問診フォームをほしがっているなら、それでもまだ一つのアプリであり、リファクタリングが助けになるかもしれません。でも、彼らが予約履歴、カレンダー連携、SMSリマインダー、請求書発行をほしがっているなら、もはやあなたが作っているのは「より良い問診フォーム」ではありません — コーチング業の事務処理一式を作っているのです。それは別のプロダクトです。

作り直しで得られるもの、失うもの

作り直しとは、アプリが本来どうあるべきかを学んだので、その知識をもってゼロから作り直す、ということです。最初のバージョンを捨てるわけではありません — ユーザーはまだそれに依存しています。でも、古いものが教えてくれたことを踏まえて 新しい アプリを土台から作り、準備が整ったらユーザーを移行させるのです。

作り直しは、無駄に感じられます。せっかく何かを作ったのに、また作り直すのですから。それが心理的なコストです。実際的なコストは時間です。ユーザーを移行できる状態になるまで、新しいバージョンに二、三ヶ月から四ヶ月を費やすことになります。もはや最初のバージョンを松葉杖にすることもできません — セーフティネットなしで前へ進むのです。

ですが、作り直しがもたらすものは、ほかの何にも得られないものが一つあります。自由です。新しいアプリは、古いものの形に縛られません。もとが単純なフォームで、新しいものが本格的な事務処理システムであるべきなら、最初からそのために設計します。性能が大事なら、そのために設計する。セキュリティや連携やワークフローが大事なら、それらは後付けではなく — 土台そのものになります。

作り直しのあとに成功するアプリは、たいてい、問題への理解が元のコードからあまりにかけ離れてしまい、つぎはぎするのがサイズの合わない服を着るようなものになったから、そうしているのです。作り直すということは、自分たちのために作る、ということでした。

どちらを選ぶか、判断するための3つの問い

問い1：核となる形は、まだ正しいか？

核となる形とは、アプリを定義する1つか2つの主なワークフローのことです。コーチングの問診フォームなら「クライアントが問診票を記入し、コーチが確認し、コーチが予約を入れる」です。もしあなたが 異なる ワークフロー — 請求書発行、カレンダー管理、クライアントへのメッセージ送信 — を足しているなら、核を拡張しているのではなく、横っちょに別機能をボルトで留めているのです。それは、あなたが別のプロダクトを作っているサインであり、つまり作り直しを意味します。

もしあなたが同じ核のバリエーション — 「個人向けの問診、チーム向けの問診、カスタム項目つきの問診」 — を足しているなら、それはまだ同じアプリです。リファクタリングして拡張しましょう。

問い2：今日リファクタリングしたら、次に摩擦がくるまであと何ヶ月か？

正直に。摩擦が半年消えるなら、リファクタリングが正しい一手です。問題がコードの形ではなく土台そのものにあって、二ヶ月後にまた痛みが出るなら、作り直しが、二度つぎはぎするという見せかけの節約からあなたを救います。AIビルダーにこう聞いてみてください。「これを整理したら、また同じことをやる必要が出るまでどれくらいもつ？」答えが「たぶん長くはもたない」なら、作り直しの時です。

問い3：ユーザーは実際、何に依存しているか？

v1にアクティブなユーザーが3人いて、作り直しを考えているなら、一、二日で移せます。現在のアプリに本番依存しているユーザーが50人いるなら、作り直しは両方のバージョンを何ヶ月も動かし続けることを意味し、それはそれで独特の苦しみです。

たいていうまくいく道筋

作り直しに成功する創業者のほとんどは、並行して進めます。元のアプリを動かし続けながら、空いている時間で新しいものを作るのです。新しいほうが古いものと機能的に同等になったら、一週間かけてデータとユーザーを移行し、それで完了です。

たいていうまくいかない道筋：リファクタリング、リファクタリング、リファクタリングを繰り返し、三回目になってようやくアーキテクチャがまだ間違っていると気づき、しかしもう「古い」バージョンに入れ込みすぎていて、それを認めて一からやり直すことができない。

決断すべきタイミング

次に摩擦を感じたら、自分にこう問いかけてください。「私は、このアプリが本来やるべきだったことを、より良くやらせようとしているのか？それとも、それが設計された覚えのない何かになるよう求めているのか？」前者ならリファクタリング。後者なら、最初からそうあるべきだったものを作ることに、何の恥もありません。成功しているアプリのほとんどは、核のバージョン1ではなく、バージョン2なのです。