あちこちでツールを探すのをやめよう。どんなことでも、Claudeには答えがある。
忠実度を、贅沢品から日用品へ。
これがこの方法論の最高の前提。以降のすべては、この一文から導かれる。
「これを実装するのはどれだけ難しいか」に縛られず、伝えたいことを明確に言葉にするだけでいい。
そしてアイデアを明確に言葉にすることこそ、プロダクトマネージャーの本領だ。
この方法論は絵空事ではない。成立させるには省けない3つの前提がある——一つでも欠ければ、あとは全部割引きになる。
これに決める。あれこれ試すのをやめる。今最も優秀なのはこれだ——そう信じることで、エネルギーを節約できる。
ウェブのチャットではなく、実際に動くプロトタイプを直接作れる形態。高忠実度優先を実現するのは、これだ。
Claude Maxがスタートライン。十分に使え、レート制限で中断されない環境があってこそ、毎日高忠実度のプロダクトが作れる。生産性ツールだから、節約する場所ではない。
3つの条件は本質的に同じこと：自分に十分な武器を持たせること。
ワイヤーフレームにはFigma、フロー図にはAxure、グラフにはプラグイン、アニメーションにはまた別のツール……
エネルギーの大半がツールの選定、学習、組み合わせに費やされ、本当の問題は放置される。
ツールの海で迷い、探せば探すほど不安になる
各ツールは小さな部分しか解決せず、つなぎ合わせが必要
学習コストが高く、やっと慣れたら新しいツールが出る
ツール間で連携できず、断片だらけのアウトプットになる
どんな問題に当たっても、最初の反応は「どのツールを使うか」ではなく、「Claudeにどう伝えるか」であるべきだ。
あることのコストが「贅沢品」から「日用品」に変わったとき、やり方を根本から変えるべきだ。
曖昧さが最大。人それぞれに違うものを頭の中で描く。
形は似ているが、本質は違う。枠は見えても、本当の体験は見えない。
クリックでき、インタラクションでき、ユーザーが本当に使える。これが真実だ。
従来のPMはL1〜L2に留まっていた。AI-Native PMは直接L3へ。
これは「今までと同じことをより速くやる」ではない。以前はできなかったことをやる——
製品が議論される前に、触れる現実として存在させること。
本物に対する人の反応と、スケッチに対する反応はまったく違う。低忠実度のテストで得られるのは「コンセプトへの礼儀的な評価」。高忠実度のテストで得られるのは真の行動だ。
上司や同僚は動くものを見れば5秒で理解できる。ワイヤーフレームは想像力に頼るため、理解はすべてズレる。
高忠実度のプロトタイプ自体が最も正確な要件定義書だ。開発チームは推測しなくていい、見たままが手に入る。
本物のプロトタイプは、エッジケース、インタラクションの細部、パフォーマンス問題を浮かび上がらせる——低忠実度では永遠に見えないものだ。
スケッチに時間を使わず、そのステップをClaudeに任せる。
仮のデータでも本物の構造で。Lorem ipsumや「タイトルの仮置き」はNG。
ローディング中 / データなし / エラー / 成功、happy pathだけでなく。
クリックでき、入力でき、フィードバックがある。人が本当に「使える」状態にする。
見たままが手に入る。自分の目で確認して初めて本物だ。
シンプルな低忠実度のほうが判断を誤らせる。高忠実度から始めてこそ、真実が見える。
それは過去の話。いまはClaudeに任せれば当日中に動く——もう時間はかからない。
できないし、それは重要でもない。最も正確な要件定義書として機能し、開発チームがプロダクション版を書き直す。
次の要件で、ワイヤーフレームを描くのはやめよう。Claudeを開いて、言葉にして、動かして、本物の人間に使ってもらおう。今日から試してみよう。