すでに使っている人を壊さずに、AIで作ったアプリを更新する方法

アプリの最初のバージョンは、変えるのが簡単でした。何かが壊れても、気づくのはあなただけ。それから本物の人が使い始めて — 今や、どんな変更も、目を覚ましている患者の手術のように感じられます。すでに使っている人を壊さずにAIで作ったアプリを更新することを学ぶのは、ほとんど段取りの問題で、その段取りは思うより小さなものです。

私たちが知っている、ある家庭教師ビジネスのオーナーは、これを痛い目を見て学びました。彼女のスケジュール管理アプリは何ヶ月も順調に動いていたので、ある晩、彼女はAIビルダーに小さな改善を頼みました。「Session」をどこも「Lesson」に名前を変えてほしい、と。家庭教師たちが実際に使っていた言葉がそれだったからです。ビルダーは喜んで名前を変えました — そして、判明したのは、既存の予約が保存されていた場所まで含めて変えてしまったことでした。翌朝、3人の家庭教師がカレンダーを開いて、空っぽなのを見つけました。データは消えていませんでしたが、アプリがもうそれを見つけられず、彼女はそれを再びつなぎ直すのに、ストレスの多い1日を費やしました。

その変更について、不合理なところは何もありませんでした。彼女はただ、ユーザーがついたあとにAIで作ったアプリをどう更新するかの段取りを、まだ持っていなかっただけです。この記事は、その段取りです — 1つの変更につきおそらく15分余分にかかるだけで、たいていの惨事を防ぐ、4つの習慣です。

ユーザーがつくと、更新が違って感じられる理由

誰か他の人があなたのアプリに頼った瞬間に、3つのことが変わります。

今やそこにはデータがある。 空のアプリでは無害だった変更 — 名前を変える、フォームを組み替える — が、すでに入力された情報を切り離したり、ぐちゃぐちゃにしたりしうる。
人には習慣がある。 ユーザーは、ボタンがどこにあるかを覚えました。改善であっても、毎日使うものを動かせば、それは混乱です。
問題のタイミングを選べない。 アプリが自分だけのものだったときは、壊れた夜はどうでもよかった。今や、壊れた火曜の朝は、カレンダーが空っぽの3人の家庭教師です。

これは、アプリを改善するのをやめるべき、という意味ではありません。変わらなくなったアプリは、突然ではなくゆっくりと死んでいきます。これは、変更には少しの儀式が必要、という意味です。

習慣1：何かに触れる前にバックアップする

これは、譲れないものです。誤字の修正より大きなどんな変更の前にも、アプリのデータの最新のバックアップがあること — そして、どう復元するかを知っていることを確かめましょう。

すでに自動バックアップを設定してあるなら、この習慣はAIビルダーへの1つの質問に縮みます。「最後のバックアップはいつで、どう復元しますか？」 答えが自信に満ちていて最近のものなら、進めましょう。まだバックアップを設定していないなら、次の更新の前にそれをやってください — 私たちは AIで作ったアプリをバックアップする完全ガイドを書きました。今月、あなたのプロダクトに費やす最良の1時間です。

上の家庭教師アプリの話がハッピーエンドになったのは、まさに彼女のプラットフォームがバックアップを保っていたからです。そうでなければ、ストレスの多い1日は、破滅的な1日になっていたでしょう。

習慣2：「はい」と言う前に「これは何を壊しうる？」と尋ねる

ここに、ほとんどのビルダーが尋ねようとも思わない質問があり、それは他の3つの習慣を合わせたよりも多くの仕事をします。AIビルダーに変更を説明したあと、それを承認する前に、1行足しましょう。

「この変更をする前に — 既存のどの機能やデータに影響しうる？」

これが効くのは、AIがたいてい、あなたには見えないつながりを見られるからです。家庭教師アプリのオーナーは、「Session」が予約が住んでいる場所の名前でもあると知りようがありませんでした。ビルダーは知っていた — 彼女がただ尋ねなかっただけです。あとで段取りを立て直したとき、このたった1つの質問が、問題を捕まえるステップになりました。価格フォームを変えると古い請求書2件に影響すること、必須欄を足すとそれなしでサインアップした既存のクライアントをブロックすることを、フラグで知らせてくれたのです。

答えは、パイロットが気象レポートを読むように読みましょう。「これは見た目だけで、ほかに何も触れません」 — 晴天、進め。「これは予約の保存のされ方を変えます」 — それが、速度を落とし、もう一度バックアップし、ことによるともっと穏やかな版の変更を頼む合図です。

習慣3：一度に1つだけ変えて、他人のようにテストする

5つの改善を1つの大きな更新に束ねるのは、効率的に感じられます。実際には逆です。何かが壊れたとき、5つのどれが原因か分からないし、壊れた1つを元に戻すには5つすべてを元に戻すことになります。

1つ変えて、確かめる。確かめることは、分けることと同じくらい大事です。

オーナーアカウントではなく、2つめのアカウントを使う。 あなたはアプリを管理者として見ています。ユーザーはそうではありません。普通のユーザーとしてログインして — まさにこのために、固定のテストアカウントを1つ持っておきましょう — 変更が触れた経路を歩いてください。（自分のアプリをテストしたことが一度もないなら、QAの経験なしでやる方法はこちら。）
変えたものと、その隣のものを確かめる。 予約フォームを更新したなら、予約をしてみる — それから、古い予約も開いて、まだちゃんと表示されることを確かめる。更新による不具合のほとんどは、新しいデータではなく、古いデータに現れます。
明日ではなく、今やる。 変更の直後、まだ新鮮で小さいうちにテストしましょう。更新の5分後に見つかった問題は、明らかに更新が原因です。金曜に見つかった問題は、何でもありえます。

習慣4：静かな時間を選び、元に戻す方法を知っておく

プロが使い、非開発者がめったに聞かない、タイミングの感覚を2つ最後に。

ユーザーがいないときに出す。 あなたはおそらく自分のアプリのリズムを知っています — 家庭教師アプリは平日の午後がいちばん忙しく、日曜の夜はほとんど静かでした。日曜の夜が、変更をするときです。何かおかしくなっても、誰かが来る前に直す時間が、数分ではなく、何時間もあります。

必要になる前に、元に戻す方法を知っておく。 AIビルダーに尋ねましょう。「この変更が問題を起こしたら、元に戻せる？それには何が必要？」 答えが「ワンクリック」のときもあります。「変更を元に戻すのは簡単だけど、変更後に作られたデータは古いバージョンに合わないかもしれない」のときもあります。その答えは、落ち着いているときに聞きたいものです。3人の家庭教師があなたにメッセージを送っている最中ではなく。

そして、変更がユーザーに見えるとき — 動いたボタン、名前の変わった欄、新しいステップ — 彼らに伝えましょう。短いメッセージ1つ（「Session が Lesson という名前になったことに気づくと思います — 予約は同じ、名前がより親しみやすくなっただけです」）が、混乱する不意打ちを、誰かが彼らの頼るプロダクトを能動的に世話しているという合図に変えます。

15分でできる版

段取り全体を、付箋に収まるくらい小さくしたものがこちらです。現在をバックアップ → 何が壊れうるか尋ねる → 一度に1つ変える → 古いデータも含めて他人としてテストする → 静かな時間に → 元に戻す方法を知っておく → ユーザーに伝える。

こういうものに従うオーナーは、無謀なオーナーよりAIで作ったアプリを更新する回数が少ないわけではありません — もっと更新します。なぜなら、各変更が賭けでなくなるからです。それが本当の見返りです。壊れるのを避けることではなく、人々が頼っているものを改善し続けるのに十分な自信を保つことです。

次にビルダーに変更を頼もうとするとき、習慣2の1行の質問を試して、それが何を浮かび上がらせるか見てください。そして、もしこれが、ついにあなたにバックアップを設定させる記事になったなら — ここから始めましょう。