一人のスタジオで次に何を作るかを決める方法

• すべてのアイデアは、本物のアイデアとして認められる前に一文テストにかけられる

• ほとんどのアイデアは、曖昧な熱意の欠如ではなく、3つの具体的な理由のいずれかで却下される

• アイデアがビルド枠を獲得するのは、現実的で繰り返し発生する問題に触れた後に限られる

• 「あとで検討」リストに残ったアイデアは意図的に放置され、思われているよりはるかに少ない頻度で確認される

アイデアになる前に実行する一文テスト

私は、実際に作れる数よりも多くのアイデアを抱えている。それは自慢ではなく、管理しなければ負債になる。なぜなら、それらのアイデアはどれも約20分間は興奮を感じさせるが、興奮は「実際に夜を費やす価値があるか」を判断するのに最悪のフィルターだからだ。だから、アイデアが何らかのリストに載る前に、まず一つのテストを通過しなければならない。最小限の有用なバージョンを「and」を使わずに一文で記述できるかどうか。

これは小さな条件のように聞こえるが、このプロセスの中で最も多くのアイデアを却下する。「Claudeの使用状況を追跡し、分析情報も表示し、コミュニティ機能も持つツール」という文章は通らない。「使用制限に達する前に警告するツール」という文章は通る。前者はプラットフォームの売り文句で、後者は火曜日の夜に作れるものの売り文句だ。私は後者の種類を望む。なぜなら、後者の種類こそが実際に完成させられるからだ。

私は最初からこのように働いていたわけではない。初期は、アイデアが興味深く聞こえた瞬間にリストに載せていたため、リストは段落で説明が必要な中途半端な計画の墓場と化した。今や段落は警告のサインであり、機能ではない。最小限のバージョンが何をするのかを一文以上で説明しなければならないなら、そのアイデアはまだ形を成していない。ただ熱意を獲得しただけであり、それらは異なるものだ。

このテストは、実際に時間を費やす前に、スコープに関する正直さを強いる。「and」が必要なアイデアは、通常、トレンチコートを着た2つか3つのアイデアであり、文の段階でそれらを分離するのは、ビルド開始から3週間後にスコープの膨張に気づいてから分離するよりはるかに安上がりだ。一つの大きな製品ではなく小さなツールを継続的にリリースし続ける理由について書いたとき、その規律のほとんどは実際にはコードが存在するずっと前の、文の段階で始まっていると正直に答えた。

エディタを開く前にアイデアが却下される理由

一文テストを通過したアイデアも、常に却下される。そして、それらのほとんどは「十分に良くない」という曖昧な感覚ではなく、3つの具体的な理由のいずれかで却下される。

最初の理由は、そのアイデアが新しいから良く聞こえるだけだということだ。新規性は最も安価な興奮であり、すぐに色褪せる。これを確認するためのチェックはシンプルだ。文を少なくとも数日間置いてから判断する。最初の火花が消えた後も、まだ作る価値があると思えるなら、それが本当のシグナルだ。思いついた夜にだけ良く聞こえたなら、それは通常、夜が語っていたのであり、アイデアが語っていたのではない。

2番目の理由は、それがすでにリリースしているものと重複しているということだ。たとえラッピングが違っていてもだ。すべての新しいアイデアは、スタジオ全体で既に存在するものと正直に比較される。Git Dojo、OhNine、Statusline Builder、Claude Blueprint、RAXXO Studio、そして商品ラインだ。正直な答えが「これは基本的にOhNineを別の名前で呼んだものだ」なら、それは新しいものとして作られるのではなく、OhNineを改善するためのメモに折り込まれる。同じ根本的な問題を2つの異なる名前で2回追うのは、どちらかのバージョンが十分に活用できたはずの注意を無駄にする。

3番目の理由は、解決する具体的な問題に、具体的な人物がぶつかっている瞬間を想像できないということだ。デモグラフィックではなく、実際の瞬間だ。Git Dojoの場合、その瞬間は明確だった。誰かが初めてrebase -iと入力し、ここでミスをすると高くつくように感じて固まってしまう瞬間だ。その瞬間を具体的に想像できないとき、アイデアは通常、永遠に抽象的なままになる。これは、問題ではなく感情を解決しようとしていたことの強い兆候だ。

このようにアイデアを却下するのは、以前は無駄に感じていた。可能性を捨てているように思えたからだ。今では、その逆だと考えるようになった。早期に却下するすべてのアイデアは、4つ目の未完成のものを始める代わりに、何か別のものを完成させるために費やせる時間になる。複数の製品を別々に保つ構造的な側面について書いたとき、罪悪感から却下したアイデアを既存のツールにマージし直すのではなく、きれいに分離しておくことの重要性を説明した。そして、この2つの規律は互いを強化する。最初に厳しく切り分け、生き残ったものはビルド後にきれいに分離しておく。

実際にアイデアがビルド枠を獲得する条件

却下を生き残ることは必要だが、十分ではない。アイデアが実際にビルド枠を獲得するのは、もう一つの基準をクリアしたときだ。根本的な問題を、私自身が実際に、1回以上、具体的に、修正がどのように見えるかを正確に記述できるほどに経験している必要がある。

このルールが存在するのは、他人が何を必要としているかについての私の推測を信用していないからだ。私は、自分が個人的に何度も遭遇した問題を信用する。なぜなら、繰り返しは、一度限りの迷惑で二度と考えることのないものと、本当の繰り返し発生する問題を分ける要素だからだ。Statusline Builderが存在するのは、同じ種類のJSON設定を手動で編集し続け、手作業で同じ小さなミスを繰り返していたからだ。それは、開発者が欲しがるかもしれないという推測ではなく、私が個人的に何度も繰り返した迷惑であり、それを修正するものを構築することがもはや任意ではなくなったということだ。

具体性の要件は、繰り返しと同じくらい重要だ。「より良い開発者ツールが欲しい」は、構築するための具体性に欠ける。それはムードだ。「ミスをしてもコストのかからないリポジトリでrebaseの練習をしたい」は、その日のうちに座って取りかかれるほどに具体的だ。アイデアが、私が強制しなくても、そのレベルの詳細に自ら到達したとき、それが準備ができているという最も明確なシグナルであることが多い。

これら2つの下には、より静かなチェックがある。完成したものを誰かに一文で説明できるかどうかだ。これは最初の一文テストと同じもので、ピッチではなく結果に2回目に適用したものだ。完成版が実際に何をするのかを説明するのに段落が必要なら、ビルド中に何かが逸れたということであり、それはリリース後ではなくリリース前に捉える価値がある。出荷と呼ぶ前にすべてのツールに対して実行するレビューパスについて以前書いたが、この一文レベルのチェックは、その同じ習慣の最も初期のバージョンであり、完成品ではなくアイデアに適用したものだ。

これらのどれも、アイデアがうまくいくことを保証するものではない。ビルド枠を獲得したアイデアが、少なくとも現実的なもの、繰り返し発生し、具体的で、記述可能な問題から始まったことを保証する。ある夜、ムードのように感じたものからではない。

意図的に無視する「あとで検討」リスト

却下されたすべてのアイデアが削除されるわけではない。多くのアイデアは、「あとで検討」と考える別のリストに載せられる。そして意図的なのは、そのリストを実際に意図的に開く頻度が極めて低いということだ。

どんなバックログでも、それを絶えず手入れし、優先順位を並べ替え、古いエントリを読み返し、何も忘れられないようにする必要がある生き物として扱いたくなる。私は以前、まさにそれを行っていた。そしてそれは静かに、それ自体が一種の先延ばし行為となった。目の前のものを構築する代わりに、構築していないもののリストを確認するようになった。今では、「あとで検討」リストは、ビルドの合間で本当に新しい何かを入れる余地があるときなど、決められた瞬間にのみ開かれる。古いアイデアを閲覧してドーパミンを得たいと思ったときではない。

そのリストのエントリのほとんどは、卒業することはない。数ヶ月間座っていて、私の状況について何も変わっていないアイデアは、通常、最初からそれほど強くなかったという兆候だ。ただ、その時点で即座に却下されなかっただけだ。卒業するアイデアは、ほぼ常に、何か具体的なことが変わったために卒業する。私は同じ問題を別の場所で再び経験したか、すでにリリースしているツールが、その古いアイデアがちょうど埋めるギャップを明らかにした。

また、そのリストからアイデアを静かに、儀式もなく消滅させることを学んだ。すべてのアイデアが正式な却下を必要とするわけではない。一部のアイデアは、スタジオの実際の製品がその周りで形を変えるにつれて、関連性を失うだけだ。そして、古くなったアイデアを剪定することは、漠然とした義務感から数週間ごとに再検討し続けるコストに比べれば、何のコストもかからない。一人のAIスタジオを実際に運営することがどのようなものかで詳述した、5つの別々のツールが1つの肥大化したプラットフォームに統合されるのを防ぐのと同じ本能が、このリストが、ただ延期されただけの2番目の、より静かなスコープクリープの形になるのを防ぐ本能だ。

要約

フィルターは紙の上ではシンプルだ。一文、「and」がない、数日間興奮しなくても価値があると思えること、すでにリリースしているものと重複しないこと、そして実際に1回以上経験した具体的な問題に遡ることができることだ。それが機能するのは、アイデアが緊急に感じられるときにステップをスキップすることを拒否するからだ。なぜなら、緊急性こそが、完成させなかったものを構築するように私を説得していた感情だったからだ。

これらのどれも、私を悪い判断から守るものではない。私は今でも、おそらくもっと忍耐すべきだったアイデアを、ある週に却下している。しかし、代替案、つまりその瞬間に興奮するものを何でも構築する、というのは、このスタジオがラフなドラフトを超えたものを一度も出荷しなかったバージョンだ。このフィルターは、アイデアを完璧にするためのものではない。生き残ったものが実際に完成することを確実にするためのものだ。

これらすべての下に、単独で名前を付ける価値のある習慣が1つあるとすれば、それは却下に対する忍耐だ。一文の段階で、または繰り返しのチェックで、または「あとで検討」リストで静かに消滅させるすべてのアイデアは、すでにその場所を獲得した何かを完成させるために戻ってくる時間だ。そのトレードオフは華やかではなく、良さげなアイデアが却下された瞬間に進捗のように感じることはない。それは後になって、実際にリリースされたもののリストの中で、進捗のように見える。