顧客の声をプロダクトに変える「第二の脳」
Shunsuke Kimura
SENDAI事業部 プロダクトマネージャー
株式会社STAR UPでアパレル業界向けAIプラットフォーム「SENDAI」のプロダクトマネージャーを務めております、木村です。
SENDAIは、どの商品をどの店舗にいくつ届けるか（配分）や、発注の計画づくりをAIで支援するプロダクトです。
今回は、私が日々のプロダクトづくりで使っている「ドキュメントの運用のしかた」について、実践の記録としてまとめてみたいと思います。
プロダクトのドキュメントというと、仕様書のような「何を作るか」をまとめた資料を思い浮かべる方が多いと思います。
でもこの記事で紹介するのは、その枠をはみ出して、顧客の声から事業の判断までまるごと抱え込んだ、ちょっと変わった使い方です。
1枚のドキュメントではなく「Gitリポジトリまるごと」として運用する、エンジニア出身であることを活かしたやり方でもあります。
顧客の声をプロダクトに反映しきれていない気がするPdMや、顧客の声に耳を傾けられていないかもしれないと感じているエンジニアの方の参考になればうれしいです。
顧客の一次情報がすべての起点
PdMをやっていて痛感するのは、機能のアイデアも優先順位の判断も、結局は顧客との接点から生まれるということです。
商談で顧客がぽろっと口にした一言が、半年後の主力機能になったりします。
ただ、この一次情報は扱いが難しく、プロダクトに届くまでの間にどんどん劣化していきます。
私自身、こんな失敗を何度もしてきました。
- 商談メモを要約で残していたら、2週間後に読み返しても顧客が実際に何と言ったのか思い出せない
- 記録がSlackや議事録、スプレッドシートに散らばっていて、機能検討のときに探し出せない
- 「あの顧客も同じことを言っていた気がする」が記憶頼みで、確信が持てない
要約すればニュアンスが消え、散らばれば参照されなくなります。
だとすると、やるべきことはシンプルでした。
顧客の発言をそのまま、もれなく集めること。そして、集めた情報をプロダクトの情報と同じ場所で一元管理すること。この2つです。
リポジトリまるごとを「第二の脳」にする
そこで、プロダクトのドキュメントを1つのGitリポジトリとして作り直しました。
それを「第二の脳」と呼んでいます。
商談の記録からプロダクト仕様、ロードマップまで、プロダクトに関する情報はすべてここに集まります。
prd/
├── CLAUDE.md # 運用ルール（毎セッション読み込まれる）
├── customers/ # 契約済み顧客の商談記録・導入・フォロー実データ
├── prospects/ # 商談中顧客
├── insights/ # 顧客接点から得た気づき（flow）
├── knowledge/ # 確立した知見（stock）
│ ├── domain/ # 業界知識
│ └── product/ # プロダクト仕様
├── skills/ # 業務の型（約30本）
├── reviews/ # 週次・月次レビューの成果物
├── roadmap/ # ロードマップ反映候補
└── proposals/ # 顧客向け提案資料
中身はぜんぶMarkdownです。
人間はObsidianで読み書きし、AIはClaude Codeで読み書きします。
肝心なのは、プロダクト仕様（knowledge/product/）と、その根拠になった一次情報（customers/ と insights/）が同じリポジトリにあることです。
仕様の「なぜ」を遡っていくと、元になった顧客の発言までたどり着けます。
記憶（顧客接点）と判断（仕様やロードマップ）が同じ場所でつながっているので、「脳」という呼び名はわりと実態に近いと思っています。
このうち insights/ と knowledge/ は、一時的な気づきの置き場（flow）と確立した知見の置き場（stock）という役割分担にしています。
発言そのままの一次情報は customers/ と prospects/ に残し、そこから抽出した気づきを insights/ に置き、複数の顧客で確かめられた知見だけを knowledge/ に上げる。
ディレクトリの並びが、そのまま情報の確からしさの段階になっています。
flowとstockを分けているのは、未検証の気づきと確立した知見が同じ場所に混ざっていると、AIが、1社からしか出ていない要望を確立した前提として仕様や提案資料に書き込んでしまうからです。
場所が確からしさを表していれば、AIへの指示は「仕様の根拠には knowledge/ だけを使う」で済みます。
ディレクトリの切り方は今も試行錯誤の途中です。
顧客の発言は「そのまま」残す
一次情報がいちばん劣化しやすいのは、実は記録の瞬間です。
人はメモを取るときに無意識に要約していて、要約には解釈が混ざります。
そこで議事録には「主観と事実を分ける」というルールを置きました。
- 顧客の発言は要約せず、引用ブロックでそのまま残す
- 自分の解釈や推測には 📝 マークを付けて分ける
> 「配分表を作るのに毎回半日かかっていて、その間は他の業務が止まる」
📝 配分業務の工数がボトルネックという解釈。「半日」が毎回なのかは次回要確認。地味なルールですが、これが効きます。
「工数がかかっている」という要約からは何も設計できません。
でも「その間は他の業務が止まる」という発言そのままからは、割り込みに耐える業務設計という論点が読み取れます。
あわせて、全ファイルのfrontmatterに「情報の型」を持たせています。
---
name: 配分業務のペイン
description: 店舗配分業務の構造的課題の整理
type: insight
judgment: 反映 | 保留 | 反映しない
reproducibility: 1社特有 | N社共通 | アパレル業界共通 | 業界横断
updated: 2026-07-10
---型があると、「このペインは何社で再現しているか」をAIが機械的に集計できます。
AIに読ませる前提でデータの型を決めておいたことが、あとになって一元管理を支える土台になりました。
顧客の声をプロダクトの仕様へ昇格させる
集めた一次情報は、こんな流れでプロダクトに反映されていきます。
商談（発言そのまま記録）→ インサイト抽出 → 再観測で再現性を更新 → knowledge へ統合 → ロードマップ反映
- 顧客接点で得た気づきは
insights/に記録する - 別の顧客で再観測されたら再現性のレベルを上げる（1社特有 → N社共通）
- 「反映すると判断済み、かつN社共通以上」になったら
knowledge/へ統合し、insights/からは削除する
一方で、1社の発言だけで仕様を動かすと、プロダクトが特定の顧客に引っ張られてしまいます。
再現性を確認できた気づきだけを仕様に上げるという絞り込みが、御用聞きにならず顧客の要望を捉えるうえで効きます。
定型業務はClaudeのSkillに任せる
このリポジトリの上で、PdMの定型業務を「Skill」として約30本定義しています。
1業務=1ファイルで手順と判断基準を書いておき、自然言語で呼び出す形です。
| 呼びかけ | 実行される業務 |
|---|---|
| 「〇〇社の商談準備して」 | 過去接点の整理 + 事前リサーチ + ヒアリング設計 |
| 「振り返って」 | 議事録を現状/課題/理想の3軸で構造化（発言そのままルール適用） |
| 「〇〇って言ってた顧客は？」 | リポジトリ全体を横断して発言そのままで検索 |
| 「提案資料作って」 | 顧客のペインと過去接点から提案資料のドラフトを生成 |
| 「ロードマップ反映」 | 昇格基準を満たしたインサイトから機能化候補を抽出 |
いちばん重宝しているのは顧客横断検索です。
「過去に似たことを言っていた顧客」が、発言そのままの検索結果として数秒で出てきます。
記憶に頼っていたころには考えられなかった体験です。
もうひとつ、Skillに任せてよかったのが顧客情報のステータス管理です。
顧客ファイルのfrontmatterに lead → active → proposed → won / lost というステータスを持たせていて、「〇〇社をlostにして」と頼めば、遷移理由つきで履歴が残ります。
効いているのは、週次レビューでの「ステータスと実態のずれ」の検出です。
商談が止まっているのにステータスは「商談中」のまま。
このずれは、記憶頼みの管理だとどうしても起きます。
そこで週次レビューのSkillに、「activeのまま21日動きなし」といった放置を拾わせています。
拾った顧客をlostに落とすか、それとも動かすかは、毎週私が確認して決めます。
ステータスが実態からずれない状態を、仕組みで保っています。
ただし、AIに任せるのは定型業務の実行までにしています。
各Skillの判断基準は対話で決めたもので、AIが勝手に書き換えることはCLAUDE.md（リポジトリの運用ルール）で禁止しました。
インサイトを仕様に昇格させるか、どの機能をロードマップに乗せるか。
そういう重要な判断は、AIが揃えた材料を見ながら自分で下します。
運用してみて
良かったのは、判断の根拠を顧客の発言そのものまで遡れるようになったことです。
「なぜこの機能を作るのか」と聞かれたら、元になった顧客の発言をリンクで示せます。
もうひとつ実感しているのは、顧客の声から作った機能が、あとからほかの顧客にも刺さる場面が増えたことです。
1社の要望に引っ張られず、再現性を確かめてから仕様に上げていたからだと思います。
あとから刺さった例を1つ挙げます。
導入を進めていたある顧客が、発注フローの最後に必ずレビューの工程を置いて、遠い店舗への在庫の移動や配分の偏りがないかを人の目で確かめていました。
店舗から店舗への在庫移動は、移動元の在庫を実際に減らします。
間違えたときの痛みが大きいから、自動の計算結果を鵜呑みにしない工程を業務側で作っていたわけです。
この話も、発言そのまま記録してありました。
それが根拠になり、SENDAIにも確定前のレビュー工程と、遠距離の店舗間移動を抑える仕組みを入れました。
この仕組みが、後日、別の会社との商談で刺さりました。
配分のミスに痛い思いをしてきたのは、1社だけではなかったのです。
最近は、営業メンバーも使うようになりました。
とっつきにくいと思われがちなGitリポジトリですが、GitHubの操作さえ覚えてもらえれば、あとは自然言語でSkillを呼ぶだけです。
営業が自分で「商談の準備をして」と頼むだけで、過去の接点や業界知識を踏まえた下調べが数分で整います。
エンジニアやPdMだけのものにせず、営業の商談や提案の効率化にもつながっています。
一方で、大変なことも正直あります。
いちばんは、運用ルールのメンテナンスが想像以上に手間だということです。
ディレクトリを1つ増やすだけでも、配置ルールやfrontmatterの定義、Skillへの影響をまとめて見直すことになります。
AIがルールの隙間を「よかれと思って」埋めてくるたび、細かいガードを追記しておく必要も出てきます。
この仕組みは事業とプロダクトの成長に合わせて形を変え続けるものなので、一度作って終わりにはできません。
使う人は増えてきましたが、ルールそのものを書いて整備しているのは今のところ私一人です。
規模が大きくなり複数人で整備するとなれば、別の形へ組み直すことになりそうです。
まとめ
顧客の一次情報は、要約したり散らばったりした瞬間に情報量が落ちます。
だからこそ、発言そのまま記録して一元管理し、再現性を確かめてから仕様に上げる。
定型業務はClaudeのSkillに任せて、人間は重要な判断に集中する。
この仕組みを「第二の脳」として運用するようになってから、顧客の要望とプロダクトの距離は確実に縮まったという実感があります。
顧客の声をどう受け止め、どうプロダクトに変えていくか。
それを仕組みとして磨き続けることが、いまの私の仕事の中心なのだと思っています。