プロダクト管理にAIをどう活用できますか？
プロダクトマネージャーにとってAIが最も役立つのは、大量の資料を素早く読み、下書きを作る役割です。大量のメモを処理し、フィードバックを分類し、数分で仕様書の骨組みを作れます。一方、プロダクトマネージャーの価値を支える仕事は最も苦手です。どの根拠が全体を代表しているか、どの顧客が戦略上重要か、どの妥協点なら事業として受け入れられるかを見極めることです。
会社が共有を許可した資料を使って、汎用アシスタントが支援できる業務は次のとおりです。
インタビューメモを整理・統合する
複数のインタビューに共通するテーマを整理し、各テーマを出典となるインタビューにひも付け、そのテーマに言及したインタビューの件数を示します。
フィードバックと問い合わせを分類する
サポートへの問い合わせや機能要望をまとめて課題別に分類し、必要なものを全文確認できるようにします。
仕様書の骨子を作成
課題、ユーザー、目標、対象外の事項、受け入れ基準、未解決の疑問を含む要件定義書の構成を作成してください。
例外的なケースを生成
正常に進む場合の説明では見落とされている、その機能が対応すべき状況を洗い出してください。
レビューに備える
懐疑的なエンジニア、財務責任者、顧客の立場で、あなたの提案に反論するようアシスタントに依頼してください。
リリースノートを作成する
リリース済みの変更一覧をもとに、同じ事実から顧客向けと社内チーム向けの案内を作成します。
AIで顧客インタビューを要約すると、どのような問題が起きますか？
よくある問題は、言い過ぎです。'主なテーマ'を求められたモデルが、2人の意見を'ユーザーが求めていること'として示したり、意見の対立をならして消したり、誰も発言していない言葉を引用として生成したりすることがあります。その要約を基に製品の判断をすれば、存在しない証拠に頼ることになります。
架空の事例です。レジャリーは小規模な請求書作成アプリです。プロダクトマネージャーは、6件の顧客インタビューのメモを持っています。2人の顧客が支払いの自動リマインダーを要望しました。1人は、リマインダーは顧客に迷惑なので無効にすると答えました。3人はリマインダーに言及せず、主に銀行取引の消し込みに時間がかかることを話しました。
「これらのインタビューから主なテーマを要約してください」という曖昧なプロンプトに対し、次の回答が生成されました。「利用者は支払いリマインダーの自動送信を強く求めています。ある顧客は『リマインダーには追加料金を払ってもよい』と述べています。照合処理は二次的な関心事です。」引用された発言をした人はいません。最も多くの裏付けがあった照合処理の優先度が下げられ、反対意見も消えていました。
改善したプロンプト：'各テーマについて、言及したインタビューの件数、インタビューID、メモからそのまま抜き出した引用を一つ示してください。そのテーマに反する内容のインタビューがあれば列挙してください。テーマを重要度順に並べないでください。' 確認後の要約は、照合作業は6件中3件のインタビューで言及（I2、I4、I6）、支払いリマインダーは6件中2件で要望があり（I1、I3）、反対意見が1件（I5）、という内容になりました。プロダクトマネージャーは、共有する前にすべての引用をメモと照合しました。
AIでよりよい仕様書を書くにはどうすればよいですか？
AIには仕様書の代筆ではなく、仕様書に足りない点の発見を手伝ってもらいます。課題と目標を自分で書いたプロダクトマネージャーは、その内容を理解しています。生成されたものをそのまま採用した人は、レビューで根拠を説明できないことが少なくありません。
レジャリーの例の続きとして、チームが実際にリマインダー機能を開発するとします。プロダクトマネージャーは1段落の説明文を書き、次のように依頼します。『この機能が対応すべき例外的なケースを挙げてください。請求、タイミング、顧客体験に分けて整理してください。』有用な一覧には、一部入金済みの請求書、顧客が異議を申し立てている請求書、異なるタイムゾーンにいる顧客、祝日に送信予定のリマインダー、連絡を希望しないと伝えている顧客、リマインダー送信後に編集された請求書などが含まれます。
その後、プロダクトマネージャーは、どの例外的なケースを初回リリースの対象に含めるか、どれを明確に対象外とするか、どれに技術者の意見が必要かを決めます。その判断と理由こそが仕様書で最も重要な部分であり、ほかに委ねるべきものではありません。
AIはプロダクトデザインやプロダクトマネージャーの仕事ができますか？
AIは、どちらの作業も部分的に支援できます。画面に表示する文言の下書き、レイアウト案の提案、一部のツールでの簡易的な試作品の作成、多数の別案の迅速な生成が可能です。選択肢を探る際には役立ちますが、どの案が利用者、ブランド、制約条件に合うかは、引き続きデザイナーやプロダクトマネージャーが判断する必要があります。
プロダクトマネージャーの中心的な仕事は、選ぶことです。どの課題を解決し、どの顧客を対象にし、何を優先して何を諦め、何を作らないかを選びます。こうした選択には、会社の戦略、特定の顧客との約束、開発チームが継続して対応できる範囲など、モデルが持っていない背景情報が必要です。私たちは、どの職種がどのくらいの速さで変わるかについて予測はしません。
職種とのつながりを確認してみませんか？
計画中のチーム向けトライアルを見る ↗AIプロダクトマネージャーと、AIを使うプロダクトマネージャーは同じですか？
いいえ。AIプロダクトマネージャーとは通常、AI機能を開発する人を指します。モデルがどう振る舞うべきかの定義、評価の設計、失敗事例への対応、推論コストの管理などを担います。これは独自の講座や採用市場がある専門分野です。
このガイドは、既存の業務をよりよく行うためにAIツールを使う、より多くのプロダクトマネージャーを対象としています。AI機能を開発する場合は、このページの日常業務向けスキルと、ここでは扱っていないモデルの評価や挙動に関する別途の基礎知識の両方が必要です。
製品に関する根拠資料のうち、AIツールに入力してはいけないものは何ですか？
使用するツールでの利用を会社が承認していない情報はすべて対象です。インタビューのメモには、氏名、勤務先、個人を特定できる情報が含まれることが多いため、貼り付ける前に削除し、インタビュー識別番号に置き換えてください。未公開の開発計画、価格設定の計画、契約条件は、社内規程で制限されている場合があります。
個人アカウントではなく会社が承認したワークスペースを使い、調査の録音や文字起こしをアップロードする前に、組織のAI利用方針を確認してください。個人データを扱う場合、どのツールを使うかにかかわらず、組織にはデータ保護の義務があります。
プロダクトチームはAIの活用をどのように練習すべきですか？
根拠と結果がすでに分かっている過去の判断を題材に練習します。
以前の情報整理・統合をやり直します
すでに分析した調査のメモを匿名化し、テーマを抽出するよう依頼します。出力を自分の結論と比較します。
数を数え、引用する
「件数、ID、正確な引用、矛盾点」を求める指示で再度実行し、すべての引用をメモと照合します。
仕様に問題がないか厳しく検証します
すでにリリースした仕様について、想定の境界となるケースと、最も有力な反論を挙げてもらいます。自分が見落としていたことと、モデルが作り上げたことを記録します。
判断は自分で書く
各練習課題について、何を判断し、その理由は何かを2文で書いてください。鍛えるのはプロンプトではなく、その判断力です。
この方法が適していないのは、どのような場合ですか？
調査が数件のインタビューであれば、自分で読んでください。AIによる情報の統合で節約できる時間はわずかであり、記録を読むことで、要約では得られない文脈がわかります。AIが役立つのは、1人では注意深く読み切れない量の資料がある場合です。その場合でも、読むことの代わりにするのではなく、何を読むべきかを示すために使うべきです。
Tosheo.aiは、AIプロダクトマネジメントやモデル評価の講座ではありません。汎用AIツールを日常業務で使う方法を学べるように構築を進めており、プロダクト職向けのコース、短いレッスン、明示された採点基準に沿って採点される実践課題を予定しています。AI製品開発のキャリア形成プログラムが必要な場合は、専門講座のほうが適しています。