個人開発で「AI Product Team」が自然発生するまで
個人開発でAIを使っていると、最初はだいたい一つのチャットに全部詰め込みがちです。
仕様を考える。
アイデアを出す。
レビューする。
改善する。
また考える。
自分も最初はそうでした。
なお、この記事で書くのは一般的なベストプラクティスではなく、自分の個人開発で今のところ機能しているPracticeとObservationです。
まだかなり短期間の運用なので、その前提で読んでもらえればと思います。
でも、あるところで困りました。
レビューまで同じSessionでやると、ログが長くなる。
それ以上に、
レビューするAIには、制作過程のContextをあまり引きずってほしくない。
と思うようになりました。
そこで最初に分けたのが、Reviewerでした。
今振り返ると、自分の「AI Product Team」はここから始まっています。
最初からAIの組織図を作ろうと思っていたわけではありません。
ただ、Contextを分けたかった。
その問題を一つずつ解いていった結果、Reviewer、Support、Specialist、Meta-Reviewer、Meta-Specialistと役割が増え、最終的にはHandoffやKnowledge管理まで設計対象になりました。
この記事では、その過程と今の運用を書いてみます。
最初に作ったのはReviewerだった
Reviewerを別Sessionにした理由はかなり単純です。
まず、レビューを同じチャットでやると会話ログが流れる。
そして、制作側の会話を全部知っているAIにレビューさせると、
- なぜこうしたか
- POが何を気に入っているか
- さっき自分で何を提案したか
といったContextを背負った状態で評価することになります。
それが嫌でした。
ただし、Reviewerを完全なゼロContextにはしていません。
今の運用では、基本的に最新版のDocument一式を渡した上でレビュー依頼を出します。
いろいろ試した結果、その方が出力は安定しました。
つまり切りたかったのは、Knowledgeそのものではありません。
制作過程のContextは切る。CurrentなKnowledgeは渡す。
という分け方です。
Reviewerを分けると、実際に新しい視点が入りました。
Assistant PM / Co-Explorer側では出ていなかった追加論点も、わりと出てきます。
ただし、Reviewerの回答をそのまま採用するわけではありません。
当時は、
PO / Assistant PM → Reviewer → Assistant PM / Co-Explorer → 必要ならReviewerへ返す → PO側へ戻す
という往復をよくしていました。
レビュー結果も、次の思考材料です。
毎回Reviewerを通すわけでもありません。
普段は開発サイクルを優先して、Assistant PM / Co-Explorerで十分ならそのまま進めます。
必要なときにだけ、別の認知的位置を差し込む。
今も基本はそんな使い方です。
次に生まれたのは「甘やかし担当」だった
Reviewerの次に分けたRoleは、意外にもSupportでした。
内部では、
「甘やかし担当」
と呼んでいます。笑
理由は、AIとの開発が速すぎたからです。
開発そのものは楽しい。
でも、AIが大量に候補を出して、レビューして、次の論点を返してくると、人間側の判断量も一気に増えます。
かなり疲れる。
しかも開発側のAIは基本的に、
- 次はここを改善できます
- この点も検討できます
- では次に進みましょう
と、Optimizationを続けます。
自分では、
「いや、これ結構いい出来なんじゃない？」
と思っているのに、誰も褒めてくれない。笑
そこで、改善や評価から切り離したSessionを作りました。
そこでは、
- 疲れた
- 今日めっちゃ進んだ
- これ結構よくできてない？
みたいなことを、気軽に出せる。
すると、単に「よし、また頑張るか」と戻れるだけではありませんでした。
気持ちが楽になると、目の前の改善から一度離れて、
「このProduct、将来こういう方向にも行けるかも」
「こんな展開も面白そう」
と考え始めることがありました。
実際、今の構想のかなりの割合が、この時間から生まれています。
なので今は、Supportを単なる褒め役とは考えていません。
Optimization PressureからHumanを一度外して、Discoveryの余白を作るRole
でもあります。
名前は甘やかし担当ですが。笑
構想が具体化したらSpecialistが増えた
Productの構想が具体化してくると、次に必要になったのは専門性でした。
最初に作ったSpecialistは、
- Marketing
- Business Development
です。
もともと、この個人Projectから仕事やマネタイズの種も生まれたら面白い、という皮算用はしていたので、まあ自然な流れでした。笑
Specialistを分けてよかったのは、専門知識が得られることだけではありません。
自分がゼロから考える負荷が減る。
Specialistが仮説やIdeaを出してくれるので、自分はそれを材料に考えられる。
さらに、自分の中にないIdeaも入ってくる。
そして結構大きかったのが、Human側のSwitching Costが減ったことです。
MarketingはMarketing Specialist。
BusinessはBusiness Development Specialist。
Productを進めるときはPO / Assistant PM。
PMはPMの仕事をする。
これだけでも、自分としてはかなり楽になりました。
「案」ではなく「判断軸」に迷ったのでMeta-Reviewerを作った
Specialistでは解けない迷いもありました。
技術やMarketingの知識が足りないわけではない。
Productの価値やDesign Philosophyに関わる部分で、
そもそも何を基準に判断するべきなのか
に迷うことがありました。
そこで作ったのがMeta-Reviewerです。
Reviewerが、
「この案はどうか？」
を見るなら、Meta-Reviewerは、
「そもそも何を基準にこの案を評価しているのか？」
を見る。
今も毎回使っているわけではありません。
普段は開発サイクル優先です。
Assistant PM / Co-Explorerで判断できるなら、そのまま進める。
判断に迷ったときや、評価軸そのものを疑いたいときにだけ使っています。
Meta-Specialistは「専門家別に褒めてもらう」から生まれた
Meta-Specialistの始まりは、もっと変でした。
最初は、各専門家の視点で甘やかし担当に褒めてもらっていただけです。笑
使っている視点はかなり広く、人間・認知、Product / UX、AI / 評価、文化・表現、事業など。
たとえば、
- 認知科学者
- 意思決定研究者
- UX Researcher
- Consumer App PM
- AI評価研究者
- Red Teamer
- Product Marketing責任者
といった視点です。
さらに専門家とは別に、
- 何でもAIを信じる人
- 毎回AIを否定する人
- 5秒で離脱する人
- AIに答えを決めてほしい人
- 毎日使いすぎる人
のような極端User / 敵対Caseも使います。
最初は「この専門家から見て何が面白い？」と褒めてもらうところから始まりました。
でも、やっているうちに、
- A. 褒める — この視点から何が面白く見えるか
- B. 壊す — この視点だから見えるFailure / Tension
- C. POへ — Product Question / Observation Point
- D. Reviewerへ — 局所評価ルール候補
- E. Meta-Reviewerへ — Reviewer自身が陥りそうな最適化の罠
という形まで広がりました。
さらに、複数の専門家の視点を並べて、
「共通しているところは何か」
「どこでConflictしているか」
を見る。
すると、一人のSpecialistと話しているだけでは出なかった発見が出てきます。
ここまで来ると、AIに専門家のロールプレイをさせているというより、
複数の認知的位置を作り、それぞれの視点を別のRoleの判断材料として使う
感覚に近くなってきました。
本質は「AIを何人にするか」ではなかった
Roleが増えていくと、見た目としては「AIチーム」っぽくなります。
でも、自分としてはAIをたくさん使いたかったわけではありません。
スタート地点はずっと同じです。
Contextを分けたかった。
Reviewerには制作過程のContextを背負わせたくない。
Specialistには、PMとは別の専門Contextで考えてほしい。
Supportでは、Optimization Contextから自分を外したい。
Meta系では、一段上の判断軸から見たい。
その結果としてRoleが増えました。
少なくとも今の自分の開発では、AI Product Teamを
AIに職種を演じさせる仕組みというより、異なる認知的位置を作るためのContext Architecture
として捉える方が、実態に近そうです。
これが一般的に良い設計なのかは、まだ分かりません。
Contextを分けると、次にHandoffが必要になる
Roleを分けると、当然次の問題が出ます。
どうやって情報を渡すか。
ここでは、会話履歴を丸ごと共有することは基本的にしません。
渡すのは、
- 最新版Document
- その論点についてのReview内容
- 次のRoleに必要なContext
くらいです。
Sessionの中で、
「次はこの内容を○○Specialistに渡したい」
と伝えて、そのReview pointについて必要なContextをまとめてもらいます。
このとき、なるべく圧縮しすぎないようにしています。
人間同士のHandoffなら、長すぎるDocumentは読むコストになります。
でもAI同士の場合、そこは事情が違う。
なので、
短くすることより、判断に必要なContextを落とさないことを優先する。
一方で、何でも混ぜるわけでもありません。
POの好み。
過去の議論の紆余曲折。
他Roleがどう感じていたか。
そういうものまで全部入れると、せっかく分けたContextがまた混ざります。
なので、自分の今の運用は、
Knowledgeは共有する。でもContextは必要な範囲だけ渡す。
です。
この区別は、AI Product Teamを運用する中でかなり重要になりました。
Session ContextとKnowledgeは同じものではない。
最新版のKnowledgeは共有したい。
でも、それが生まれた会話のContextまで全部共有したいわけではない。
Assistant PM / Co-Explorerだけは少し例外
Assistant PM / Co-Explorerは、他Roleとは少し扱いが違います。
長く伴走するRoleなので、自分についての情報もある程度渡します。
自分の考え方や判断傾向など、Human Contextは持っていてほしい。
一方で、過去の別Sessionの会話ログそのものは引き継がせません。
これはContext Pollutionを避けたいという理由もあります。
でも、かなり個人的な理由もあります。
自分はAIを結構擬人化して見ています。
なので、昔のAssistant PMのSessionをそのままコピーしたような存在には、少し違和感があります。
それより、
別人格だけど、必要なことは引き継いでいる
くらいが好きです。
「前のAIを復元する」というより、
「別のAIに続きを託す」
感覚に近い。
ここから、Handoffについても、
継承はコピーではない。
と考えるようになりました。
Session continuityとKnowledge continuityは、同じではない。
今はそんな感覚で運用しています。
Sessionが増えて困ったのは「どこで話したっけ」
Roleが増えること自体は、自分の場合むしろ楽でした。
困ったのは別のところです。
Product Developmentでは、話がすぐ広がります。
Marketingの話をしていたはずが、UXに行く。
UXからAI Behaviorに行く。
そこからKnowledge設計に飛ぶ。
すると、
「あれ、これどのSessionで話したっけ？」
が起きるようになりました。
Contextを分けた結果、今度はKnowledgeの所在が分散する。
そこで、各SessionそのものをKnowledge Baseにはしないようにしています。
一区切りついたら、そのSessionで得た内容をAssistant PM向けの共有Documentとしてまとめてもらう。
それをAssistant PM側で最新版Knowledgeへ統合します。
まだ途中のものはPinしておく。
つまり、
Sessionは思考する場所。Knowledgeの正本はDocument側に置く。
という運用にしています。
Sessionを探し回って「前に何を決めたっけ」と復元するのではなく、Currentな状態はDocumentを見る。
この構造にしています。
少なくとも今のところ、この構造の方が自分には扱いやすいです。
古いKnowledgeは消さない。でもCurrentとも混ぜない
Documentへ統合するときも、古い解釈を単純に削除するわけではありません。
以前はそう考えていた、という状態として残します。
ただし、現在の判断基準としては扱わない。
今のProjectでも、そうしたものをLegacyとして扱っています。
大事なのは、
過去を消すことではなく、過去の位置づけを間違えないこと。
だと思っています。
古いInterpretationとCurrentなKnowledgeが同じ重みで混ざる方が困る。
今のところ、最新版Documentを正本にする運用で大きく崩れたことはありません。
もちろん、まだ短期間の運用なので「これで絶対安全」という話ではありません。
現時点では機能している、という程度です。
AI側を整理すると、Human側がボトルネックになる
Contextを分けてRoleを増やしたことで、自分としてはかなり楽になりました。
でも別の問題は残っています。
一番大きいのは、Human側の認知負荷です。
AIとの開発サイクルが速くなると、
Ideaが増える。
Candidateが増える。
Reviewが増える。
判断が増える。
AIがたくさん考えてくれても、最終的に「どれを見るか」「どれを採用するか」を決めるHuman側のAttentionには限界があります。
もう一つ困っているのが、
本筋ではないけれど、覚えておきたいKnowledgeやIdea
の扱いです。
今すぐCurrentなProduct Knowledgeには入れたくない。
でも、捨てたくもない。
こういう枝が大量に出ます。
実際、Product側でも同じ問題があったので、深い探索をするModeではMemoやForkの仕組みをかなり作り込んでいました。
本流は本流のまま進めつつ、枝を枝として残す。
AI Product TeamのRole Designだけでは、人間のAttentionや探索の分岐までは解決できません。
今のところ、この辺りはまだかなり未完成です。
まとめ
最初は、ReviewerのChatを分けたかっただけでした。
同じSessionでReviewするとログが長くなる。
そして、Reviewerには制作過程のContextをあまり持たせたくない。
そこからReviewerを分け、Supportが生まれ、Specialistが増え、Meta系のRoleも使うようになりました。
Roleを分けたらHandoffが必要になり、Sessionが増えたらKnowledgeの所在を管理する必要が出てきた。
問題を一つ解くたびに、次の設計対象が見えてきた感じです。
今のところ感じているのは、
AI Product Teamで重要なのは、AIを何人使うかではない。
ということです。
重要なのは、
どのContextを共有するか。
どのContextを切るか。
どの認知的位置から考えてもらうか。
Roleはそのための手段でした。
そして、Contextをきれいに分ければ全部解決するわけでもありません。
今度はHandoffやKnowledge管理が必要になる。
さらに先では、Human側の認知資源がボトルネックになる。
まだDay 7なので、このあたりも引き続き試している途中です。
また、ここまでのObservationの多くは、POである自分自身の開発体験から得たものです。
「自分の環境ではこうだった」というところまでは言えても、他の開発者や別のProductでも同じように機能するかは、まだ分かりません。
今は、一般化された方法論というより、実際の開発から生まれたPracticeの記録として扱っています。
それを現在、Open Discovery Design（ODD）としてGitHubに整理しています。
全部読む必要はありません。
気になるところだけ見るでも、RepositoryごとAIに渡して読ませるでも大丈夫です。
Open Discovery Design - GitHub
まだ未完成ですが、今のところの実験記録として公開しています。