スコープクリープの罠：よさそうに聞こえるけど実は違う機能に「ノー」と言う方法

アプリをリリースした。ユーザーがやってきた。そして今、あなたの受信箱は、どれもいいアイデアに聞こえる機能要望でいっぱいです。

「Excelへのエクスポートを追加できる？」もっともです。「請求書を自動で送れる？」なるほど。「Stripeと連携できる？」本物のお金が動くところですね。「モバイルアプリを追加できる？」みんなが求めるやつです。「これを自分の顧客向けにホワイトラベルにできる？」おや、そこにはビジネスモデルが見えてきました。

一つひとつの要望は、それぞれ賢く聞こえます。けれど合わせてみると、まるで5つの別々のプロダクトを作っているように聞こえるのです。

これがスコープクリープです。そしてこれは、技術的な問題よりもはるかに多くの小さなAI製アプリを殺します。機能を作るからではなく — 作ろうとして、時間も、お金も、正気も尽き果ててしまうからです。

スコープクリープは、どうやって動くアプリを殺すのか

こういうことが起こります。最初の3つの要望には、もっともらしいのでイエスと言う。AIビルダーに追加を頼む。すると、1週間で済むはずが2週間かかる。新しい機能のそれぞれが、既存のコードにぶつかるからです。今やアプリは5つのことをこなし、そのうち3つはうまく、2つはまあまあ、という状態になります。

そこへ4つ目の要望が届く。「権限レベルを分けられる？」突然、すべての画面で誰が何を見られるかを考え直さなければならなくなります。それは機能ではありません。アーキテクチャの変更です。AIビルダーにやってもらう。すると、それはすべてに触れます。2週間が3週間になる。すべてのビューにロジックを追加したせいで、アプリは遅くなります。

8つ目の要望のころには、もともとのユーザーに向けた新しいものを出すのをやめてしまっています。機能要望の機械を回し続けるのに忙しすぎるからです。3か月前にアプリを愛していた人たちは、頼んだものが何ひとつ仕上がらないのでいら立っています。新しい要望を出している人たちは、機能がいつまでも出てこないのでいら立っています。

あなたは動くものを作りました。そして、あらゆるものになろうとして、それを壊したのです。

判断のフレームワーク

ゲートが必要です。すべての機能要望は、3つの問いを通り抜けます。

問い1：これはこのアプリに属するものか、それとも別のアプリか？

最初のアプリは、ひとつの仕事を本当にうまくこなします。スケジュール管理アプリはスケジュールを管理する。請求アプリは請求をする。それらは別々のアプリです。もし誰かがあなたのスケジュール管理アプリに請求をさせようとしているなら、あなたは機能を追加しているのではありません — スケジュール管理アプリに会計をやらせようとしているのです。それは別のプロダクトです。

いいテストがあります。「この機能を取り出して単体でリリースしたら、人はそれを買いたがるだろうか？」もしイエスなら、それはたぶん別のアプリに属します。もし答えが「いや、もっと大きなものの一部としてしか意味をなさない」なら、あなたは正しいスコープを作っています。

「うちのCRMと連携して」といった要望が来るでしょう。それが本当に意味するのは「あなた自身がCRMになって」ということです。それは別のアプリです。CRMとの連携はあとからできます。けれど、CRMになることなしに、CRM一個分の機能を追加することはできません。

問い2：これは大半のユーザーの問題を解決するのか、それともこの一人だけの問題か？

ある顧客があなたのアプリを愛していて、機能のアイデアを持っている。それはその人が実際に抱えている本物の問題です。そしてそれは、その人だけが抱えている本物の問題でもあります。

もしユーザーが20人いて、そのうち1人が何かを求めているなら、確かめましょう。ほかの19人もこれを待っているのか、それともこの人がたまたま思いついただけなのか？直接こう尋ねられます。「あなたの前に、これが必要かどうかほかの誰かに聞いてみようと思ったことはありますか？」たいてい答えはノーです。

これが危険な問いなのは、要望を出している一人の顧客が、あなたのいちばん大切な顧客かもしれないからです。その人を満足させ続ける必要があるかもしれません。それはビジネスの判断であって、プロダクトの判断ではありません。けれど目を開いたまま臨んでください。もし一人の顧客のために何かを作るなら、あなたはアプリを成長させているのではなく、受託の仕事を作っているのです。

問い3：これにはどんなコストがかかり、もとのアイデアへのコストはどれくらいか？

何にでもコストはかかります。Excelへのエクスポートは、あなたのエンジニアリングの時間を奪います。アプリの複雑さを増やします。集中を奪います。それを、ユーザーが毎日のように不満を漏らしているパフォーマンス改善の代わりに作ったなら、あなたは選択をしたのです。

具体的に問いましょう。「これを作るなら、何を作らないのか？」もし答えが「何も。うちには無限の時間がある」なら、あなたは正直ではありません。私たちにはないのです。時間は有限です。

もとのアイデアへのコストは、しばしば目に見えません。機能要望に深く没頭しているとき、あなたは人々に愛された核心を保守するのをやめてしまいます。核心は遅くなる。核心はバグが増える。核心はおろそかにされていると感じられる。そしてやがて人は去っていきます。素晴らしく動いていたアプリが今やまあまあにしか動かず、しかも設計されたこともないことをやっているからです。

実例：受付フォーム

ある人が、シンプルなクライアント受付フォームを作りました。クライアントが記入し、コーチがそれを確認し、予約を入れる。それがそのアプリです。

要望その1：「緊急の受付に印をつけられる？」イエス、それは核心のワークフローのバリエーションです。作りましょう。

要望その2：「記録のために受付をExcelにエクスポートできる？」これはドキュメントの機能です。アプリの仕事ではありません。受付はアプリの中に存在します。Excelが必要なら、コピー＆ペーストできます。でも、まあ、エクスポートは便利機能として意味があるかもしれません。作りましょう。

要望その3：「受付から自動でカレンダーの予定を作れる？」今や、あなたはスケジュール管理をしています。アプリは受付のためのもので、スケジュール管理のためではありませんでした。もし誰かが両方ほしいなら、その人はたぶん、無理やり貼りつけた小細工ではなく、本物のスケジュール管理システムがほしいのです。丁重に断りましょう。

要望その4：「コーチが受付のフォローアップをSMSで送れる？」今や、あなたはコミュニケーションシステムです。ノー。

要望その3で、あなたは境界に達しています。アプリは受付です。それ以外はすべて別のアプリです。それらのアプリとはあとから連携できます。けれど、それらのアプリになることなしに、それらを追加することはできません。

「ノー」の言い方

いちばん難しいのは、実際にそれを口にすることです。ユーザーをがっかりさせたくはありませんから。

正直に言いましょう。「素晴らしいアイデアですが、それは私たちがここで作っているものとは別のプロダクトなんです。私たちが作っているのは［あなたのひとつの仕事］です。もしスケジュール管理や請求やCRMのようなことをやろうとすれば、そのどれもがまあまあで、どれも素晴らしくはならないでしょう。」

たいていの場合、顧客は理解してくれます。彼らが尋ねたのは、アイデアが浮かんだからであって、あなたを試しているからではないのです。

ときには押し返してくることもあります。「でも両方必要なんだ。」そんなときには、こう勧めましょう。本物のスケジュール管理アプリを使う。本物の請求アプリを使う。本物のCRMを使う。そして、このアプリは、それが得意とすることのために使う。それが正直な答えです。

あらゆるものになりたいという誘惑

小さなプロダクトを作るうえでいちばん難しいのは、ノーと言うことです。ノーは、お金をテーブルに置き去りにしているように感じられます。あの顧客は本当に両方にお金を払ってくれたかもしれないのでは？あの機能があれば10倍大きくなれたのでは？

そうかもしれません。けれど、リリースしなければ、あなたは10倍大きいプロダクトにはなりません。あなたは、5つのことを下手にこなす、作りかけのプロダクトです。核心を愛していた人たちはいら立っています。新しい機能を求めていた人たちもいら立っています。そして、何か新しいものを追加するには、まず5つの古いものをリファクタリングしなければならない、という袋小路に自分を追い込んでいるのです。

成長するプロダクトとは、ひとつの仕事を本当にうまくこなし、そのうえで慎重に追加していくものです。初日からSalesforceになろうとはしません。それは、そのひとつのことをやる必要があるときに手を伸ばすアプリであり、やるときには速く確実だと信頼できるアプリなのです。

ノーと言う。核心を守る。それをやれば、人が本当に使いたくなるものを作れます。