撤退基準を先に書く

土日にAIで作った問診票の下書きツールが、気づけば3ヶ月動いている。同僚にも配って、何人かは使っている。ここで「このツール、続けますか」と聞かれたら、どう答えるか。

多くの人はこう答える。「手応えがあれば続けます」。

この一言が、あとで一番厄介になる。

「手応えがあれば」は条件ではない

条件とは、あとで誰が見ても同じ判定になるものを指す。「手応え」「良さそう」「反応がいい」は、そのときの気分で伸び縮みする。手応えがあると思えば続くし、忙しくて見なくなれば自然消滅する。どちらにしても、決めたのではなく、決めずに時間が判定してしまっている。

止める・続けるを決めるのに一番向いていないのは、作った本人の主観だ。自分が作ったものを「もうやめよう」と自分の感覚だけで判定するのは難しい。手を動かした時間が惜しくて、続ける理由を後から探してしまう。

条件を先に、観測可能な事実の形で書いておけば、この揺れが消える。判定日に条件と実測を並べるだけで、答えが出る。

書くのは3行だけでいい。

続ける条件: <観測可能な事実。「YYYY-MM-DDまでに◯◯が△△に達する」>
止める条件: <同上。達しなかったら、を明記>
次の判定日: YYYY-MM-DD

さっきの問診票ツールなら、こう埋まる。

続ける条件: 2026-12-01までに、説明なしで自力で使い始めた同僚が5人に届く
止める条件: 12-01時点で3人に届かなければ止める
次の判定日: 2026-12-01

「5人」「3人」は仮の数字でいい。判定日にメッセージを見て「誰が何人使っているか」を数えれば、迷わず答えが出る形にしておくことがポイントだ。人数でなくても構わない。「1ヶ月に◯回自分で使ったか」でも「エラー報告が0件だったか」でもいい。判定日に事実だけで割り切れることが条件になる。

止める条件は、だいたい次の4つのどれかに分類できる。

種類	条件の書き方の例
需要	判定日までに、説明なしで使い始めた人がN人に届かない
収益	判定日までに、有料に切り替えた人がN人／月次の売上がN円に届かない（値付け後の話。このコースの03で扱う）
コスト	月次のAPI利用料がN円を超え、かつそれに見合う需要がない
本人	判定日までに自分がそれを触る優先順位が動かなかった

最後の「本人」が一番効く。実装は終わっているのに、公開の作業だけが2ヶ月動かない。これは「意志が弱い」という話ではなく、実はそのツールの優先順位が自分の中で低い、という事実そのものだ。感情の問題として片付けず、事実として受け止めた方が判断は早くなる。

「止める」と聞くと、コードを消して謝って回る場面を想像しがちだ。そうではない。

止めるとは、更新を止め、ドメインとAPIの課金だけ止め、「凍結」と1行書いておくことを指す。コードもデータも残しておいていい。気が変わったり、状況が変わったりすれば、いつでも解凍して再開できる。

この違いは大きい。「消す」と思うと撤退の決断は重くなり、先延ばしにしたくなる。「凍結するだけ」だと分かっていれば、判定日に淡々と決められる。

ここが一番忘れられがちな部分になる。

判定日を設定しても、その日に忙しくて見なかった。翌週も見なかった。そのまま3ヶ月経った。これは「まだ判断していない」のではない。実際には、それを見る優先順位が自分の中になかった、という「止める」側の答えがもう出ている。

判定日を過ぎても判断しなかったことを、先延ばしとして扱わない。それ自体を、止める条件の「本人」の列が満たされた、という事実として読む。この読み方を持っておくと、いつまでも「休眠中」のまま注意力だけを食い続けるものが減っていく。

続ける・止めるの最終判断は本人が下す。AIの役割は、判定日に条件と実測を並べて提示するところまでにとどめる。

この線引きがあることで、撤退基準は「AIに任せて自動で切られる仕組み」ではなく、「本人が判断しやすくするための下ごしらえ」になる。

次のレッスンでは、この撤退基準と同時に入れておく計測の設計に進む。判定日に何を見て条件を判定するか、そのイベント設計を実装と同時に組み込む。

梶谷健人「AIとサービスを開発してリリースするまでの流れとポイント」（note, 2026-09-11）。このコースの骨格は同記事の11工程のうち後半3工程（価格設計・マーケ素材・計測設計）を起点に、撤退基準を先頭に足したAMPL版。記事本文は有料のため転載しない

1. 「手応えがあれば続けます」が撤退基準の条件として不十分な理由は何ですか？

2. 撤退基準で「止める」と決めたとき、実務として最初にやることは何ですか？

3. 判定日を過ぎても続ける・止めるを判断しなかった場合、この状況をどう扱うべきですか？