Product
この一週間、別のコードに取り組んでいて、このプロジェクトにはほぼ触れなかった。戻ってきて改めて開いたとき、見え方が変わっていた。
毎日作っていると、どの機能にも粘着力を感じる。大量の時間を注いだのだから、どれも欠かせないと思える。でも一週間離れると、その粘りが消えて、物事がはっきり見えるようになる。
距離が見せてくれたもの
日々の慣性がなくなると、現実的な問いが浮かんできた。
以前、非常に ambitious なワークフローを設計していた。多段階、多分岐、細かく設定可能。構想は面白かったが、新鮮な目で見直すと、認知負荷の重さが見えた。あのフローを最後まで使い切る人がどれだけいるのか。確かな数字ではない。
正直に戻ると、あの基本の問いに行きつく。コア機能はちゃんと動くか。最も使いやすい形になっているか。
超高層ビルより先に土台
大きな青写真があること自体は賛成だ。でも一週目で超高層を建てようとするのは別の話。まず土台を固める。最上階のことは後でいい。
これは情熱や想像力の問題ではない。順序の問題だ。今すぐ必要なことと、将来のビジョンを見分けること。
今の段階で本当に問うべきは：既存の機能を磨いてプロダクトの輪を閉じるのか、それとも横に広げて新しいスレッドを増やすのか。驚くようなものを作る余地はたくさんある。でもそのひとつひとつが基本シナリオを磨く時間を削り、開発サイクルを伸ばす。
一ヶ月目と六ヶ月目
改めて見直したとき、ある機能は六ヶ月後のプロダクトに見えた。別の機能は一ヶ月目に解決すべきものだった。
だから六ヶ月目や一年目に属するものは、ほぼすべて現行バージョンから外した。削除ではなく保管。こうすることで、基礎をどう明確に伝えるかを考える余白が生まれる。
説明しすぎる傾向
作りながら気づいたことがある。毎日使っているのに、これが何をするものなのか、ちゃんと伝わっているかずっと不安だった。無意識にガイドを増やし、説明を重ね、あらゆる混乱を先回りして防ごうとしていた。
根にあるのは、他の人が使ってくれるか分からないということ。そして真実は、市場に出すまで分からない。最良のフィードバックは使い手のフィードバックだ。それがなければ、真空の中で磨き続ける傾向に陥る——実際の信号ではなく、自分の投入量に感動してしまう。
だから今週、機能の20%を削った。もっと具体的にしたかった。
一ヶ月前なら、こうはしなかった
一ヶ月前に「機能を減らせ」と言われたら、たぶん抵抗していた。想像力を制限される感覚、視野が狭くなる感覚。
でも今は分かる。良いアイデアだからといって、一度に全部を詰め込む必要はない。一口では太れない。いくつかのアイデアは寝かせておくべきで、問われるのは「今それが必要か」だ。
スイカとゴマ
タスクと問題が増えるほど、核心の問いが繰り返し戻ってくる。自分は一体何を作ろうとしているのか。何でもやろうとするプロダクトは、結局どれも中途半端になる。エネルギーが散る。
疲れたとき、答えは「もっと頑張る」ではない。一歩引いて、上から眺めること。この全体について、自分は何をしているのか。
大事なのは agent skill が十個あるか百個あるかではない。その十個がどれだけの価値を出しているか。三ヶ月後、これはどうあるべきか。六ヶ月後は。
一日からもっと多くの生産性を絞り出すことではない。時間の軸でプロダクトがどう進化するか——自分のエコシステムの中で、その立ち位置を見つけること。
ソフトウェアは表現の練習
このプロダクトはどうやって人と関わるのか。その関わりの中で、何が一番大事なのか。
人との会話と同じだ。早口は、伝えたいことが多い証拠にはならない。むしろ伝えたいことが山ほどあるときこそ、何が最も重要かを見極めて、それを言う。
全部を並べるのではなく、双方が実際に噛み合えるものを選んで伝える。
ソフトウェアを書くと、この問いに向き合わされる。自分は一体何を言いたいのか。何が一番大事なのか。
結局、コードを書くことは、自分を明確に表現する練習でもある。
これは宣伝ではなく、作りながら実際にはまった落とし穴の記録です。