プロダクトマネージャー標準業務ガイド
プロダクトチームのすべてのPMへ、技術的な知識があるかどうかに関わらず。このガイドの目的：「使うのが怖い、使い方がわからない」から「手放せない」へ変えること。
まず最初に：恐れずに使いこなそう
Claude Codeに対して今「すごいと聞いたけど、どこから手をつければいいかわからない」という感覚があるなら、それは普通のことだ。まず3つの誤解を解こう。
誤解その1：コードがわからないから使えない
違う。むしろ逆で——技術を知らないことがむしろ強みだ。「これを実装するのはどれだけ難しいか」に縛られず、アイデアを明確に言葉にするだけでいい。そしてアイデアを明確に言葉にすることこそ、プロダクトマネージャーの本領だ。これからは「言葉にすれば、AIが作る」：一言で、AIがそれを実現してくれる。
誤解その2：壊してしまう、問題を起こしてしまう
違う。自分のプロジェクトディレクトリの中なら何をやっても大丈夫。最悪の結果は、うまくできないだけで、「違う、やり直して」と一言言えばいい。
誤解その3：ツールだから、「操作」を覚えなければならない
発想を変えよう：ツールではなく、部下だと思え。疲れを知らず、常にスタンバイしていて、何でも少しはできる万能インターンだ。人に仕事を頼むのと同じように、明確に指示するだけでいい。
第一歩：5分で対話の仕方を覚える
コマンドは何も覚えなくていい。プロジェクトフォルダに入って、自然な言葉で話しかけるだけ。核心は3つの言い回しだ。
最もシンプルなところから始める
ウェブページを作ってください。タイトルは「こんにちは」、背景は薄いブルーで、 ローカルサーバーを起動してブラウザで確認できるようにしてください。
ブラウザにページが表示されたら = おめでとう、もう使えている。
核心の3つの言い回し
- 「〜をやってください」——タスクを指示する
- 「ここが違います、〜にしてください」——フィードバックを伝える
- 「作業の前にいくつか質問してください」——一緒に考えさせる
コアの考え方：4つの前提
| 前提 | 意味 |
|---|---|
| コードが書けなくていい、言葉にできればいい | 「アイデア→成果物」の翻訳機。言葉にするほど正確に作られる。 |
| 誰でも使える、深さが違うだけ | 敷居はない、あるのは習熟度だけ。 |
| プロトタイプ＝実際に動くもの | クリックでき、インタラクションでき、ユーザーに試してもらえる。静的な画像ではない。 |
| チーム全員で転換する | 個人の実験ではなく、チームの新しいデフォルトの働き方。 |
5段階ワークフロー（詳細解説）
PMの仕事を5つのフェーズに分解する。各フェーズ：目標、伝え方、完了基準、初心者がつまずくポイント。
発見
目標：ユーザーが何を求めているか、競合が何をしているか、市場がどこへ向かっているかを把握する。
/competitor-watch [競合URL]を分析して、[価格設定/AI機能]に注目して、比較レポートにまとめてください
ユーザーの最大の痛みを3文で説明できる；競合の解決策と自分たちの差別化ポイントがわかっている。
質問が漠然としすぎる。解決法：具体的な対象＋具体的な注目点＋具体的なアウトプット形式を指定する。
定義
目標：曖昧なアイデアを、誰でも実行できる明確な要件（PRD）に変える。
/office-hours [アイデア]をやりたいんですが、まず解決策は提案せず、重要な質問を5つしてください → /prd-generator 完全なPRDを書いてください
明確な成功指標がある；エッジケースが列挙されている；参加していない人でも理解できる。
いきなり書かせると細部をでっち上げる。解決法：必ず「先に質問させる」ようにしてから書かせる。
設計
目標：作業を始める前に「大体どんな見た目か」を確認し、方向性を決める。
/design-shotgun ログインページを3つのスタイル案で：Aミニマル Bビジネス Cポップ、並べて比較できるページを作ってください
方向性が一つ決まっている；主要なページのイメージが頭の中にある。
最初から完璧を求めて延々と悩む。解決法：まず3つの粗削りな案を求め、見てから選ぶ。
プロトタイプ開発
目標：設計をクリックできる、インタラクションできる、ユーザーに試してもらえる本物のプロトタイプに変える。コアな心得：小さく速く動く。
/design-html プロトタイプにする → それから一度に一つの機能を追加： 「グラフをブランドブルーに」「CSVエクスポートボタンを追加」… 対話で反復
ブラウザで実際に動いている；メインフローを一通りクリックしてもエラーが出ない；仮データでデモが成立する。
一度に20個の要件を伝える。解決法：一度に一つだけ！プロトタイプのコード品質を気にしない。
検証
目標：実際のユーザーに試してもらい、感覚ではなくデータで意思決定する。
/qa このプロトタイプをテストして、クリックできるところを全部試して、エラー・詰まり・期待と異なる箇所を一覧にしてください
メインフローが通り明らかなバグがない；実際のユーザーに試してもらった；証拠をもって続行価値を判断できる。
自分で2〜3回クリックして結論を出す。解決法：必ず他の人に試させて、どこで詰まるか黙って見る。
スキルの成長パス
最初から完璧を目指さなくていい。このペースで伸びていこう。
底線：これはセーフティネット、制約ではない
この5つの底線があるからこそ、その範囲内で自由に試し、大胆に使える。
- 実際の機密データを渡さない——プロトタイプには仮のデータ/匿名化されたデータを使う。
- シークレットキーをコードに書かない——チームからテスト専用の認証情報をもらう。
- 取り返しのつかない操作は自分で確認する——リリース、削除、費用が発生する操作は、最後のボタンを自分で押す。
- 本番環境には触らない——プロトタイプはローカル/テスト環境でのみ動かす。
- 迷ったら聞く——コンプライアンス、費用、プライバシー、技術選定は先にチームリードに確認する。
3週間成長ロードマップ
| 週 | 目標 | 具体的な行動 |
|---|---|---|
| 第1週 | 恐れを取り除く | 環境を整え、最初のウェブページを動かし、毎日3回対話の練習をする。 |
| 第2週 | 実戦で一度経験する | 実際の小さな要件を一つ使い、「PRDを書く→プロトタイプを作る」を一通りやる。 |
| 第3週 | 独力でクローズドループ | 「アイデア→プロトタイプ→同僚に試してもらう→改善」を完全に一人でやり切る。 |
付録
A · プロンプトの4つの法則
| 法則 | ❌ この言い方 | ✅ この言い方 |
|---|---|---|
| 具体的に | いいページを作って | ログインページ、センタリングされたカード、メール+パスワード、青いボタン #3B82F6 |
| コンテキストを与える | エクスポート機能を追加して | カンバンの右上にエクスポートボタンを追加して、現在のフィルタ結果をCSVでダウンロード |
| 段階的に | 15個の要件を一度に伝える | 一度に一つ、結果を見てから次へ |
| 参考を与える | 色を調整して | メインカラー #3B82F6、Stripeのカラーリングを参考に |
B · よく使うスキルのクイックリファレンス
対話の中で / と打てば全部見られる。PMが最もよく使う：/office-hours アイデアの精緻化 · /prd-generator PRD作成 · /competitor-watch 競合調査 · /design-shotgun 複数案 · /design-html プロトタイプ · /qa テスト · /make-pdf PDF変換。
C · 初心者FAQ
Q：間違えてしまったとき、コードがわからないのにどう直せばいい？
「ここが違います、〜にしてほしいです」と直接伝えるだけ。自分で直してくれる。
Q：プロトタイプをそのままユーザー向けの正式なプロダクトとして使える？
小規模な試用はできるが、正式リリースはできない。リリースには開発チームがプロダクション品質の改修をする必要がある。
Q：プロトタイプはどれくらいで作れる？
シンプルなものなら数時間、複雑なものなら1日。1日経っても完成しなければ、要件が大きすぎるので分割しよう。
Q：試行錯誤に時間を無駄にしてしまわないか心配です。
試行錯誤こそがこの働き方のコアな価値だ。早く失敗するほど、正しい方向を早く見つけられる。
