プロダクトの意思決定を、AIと開発者が使える形にした

普段は、プロダクトの意思決定まわりを横断して担当しています（便宜上、PdMと呼ばれることが多い立場です）。最近、その仕事をAIと一緒に回すための仕組みを作りました。やったことはざっくり言うと3つで、どれも「頭の中や、あちこちに散らばっている情報を、AIが読める形にする」という同じ考え方に基づいています。

効果を測れているわけではありません。数字で比べられるものがないからです。今回は成果報告ではなく、何をどう設計したかを、記録として書きたいと思います。

1. 判断の仕方を言語化して、開発者でもトレースできるようにした

きっかけは、AIの導入でアウトプットは増えたのに、アウトカムが増えないという壁にぶつかったことです。そこで、まず開発の速度を上げる方法を考えました。

私が何を見て、何を基準に、どう判断しているかを書き出しました。開発者がそれをなぞれば、ある程度同じ判断ができる粒度までです。PdMの役割をAIのスキル（手順書）にしたのも同じ狙いで、開発者がなぞることで思考の型が身につき、「こうしたらいいのでは？」と思いつくまでの速度が上がることを期待しています。

これができると、思いついたアイデアをAIに投げたときに、その良し悪しをすぐ評価してもらえます。良さそうなものは判断基準に沿って優先順位をつけ、バックログ（現時点で13件）に登録・管理する流れも、半自動で回る形にしました。

2. 意思決定の前提を、開発者が判断できる範囲として明文化した

仕様など開発に関わる意思決定の判断材料を、ドキュメントにしました。開発者が私に確認しなくても決めてよい範囲を明示し、AIに事前に読ませれば、その範囲の判断を一緒にできるようにする狙いです。

もう一つの狙いは、判断待ちで作業が止まらないようにすることです。これまで止まっていた作業を、止めずに進められる形にしました。

意思決定には、責任がついて回ります。そこで、その責任を担当者が負えるかどうかで、範囲を分けました。リスクが低いものは、担当者が積極的に進められるようにしています。今までなぜそうなっていなかったのか、と思われるかもしれません。AIが登場して、過去の資産から判断しやすくなったことが大きいと思います。

ただし、確認が減ったかどうかは、数字ではまだ測れていません（社内に展開してから1〜2か月です）。開発者から意思決定の確認が来たときは、「そのルールで判断できます」と返すようにしていて、それで開発者の主導で進んだ件が、目に見える形では現時点で1件あります。確認せずにルールどおり進めた件も、おそらくありますが、把握はできていません。また、これは過去の資産が大量にあるから成り立つ面があります。ゼロから始める環境では、同じやり方はそのまま使えないと思います。

3. 散らばっていたデータを統合して、横断で考えられるようにした

業務DB（個人情報を除去したもの）、行動解析、ネット広告、広告解析ツール、決済、検索流入、BigQueryやFirebaseなどのログ基盤の、合計8件のデータに、AIからアクセスできるようにしました。広告解析ツールを加えたことで、広告ごとのデータを統合した結果から、分析できるようになりました。また、まだデータベースの形になっていない過去の施策とその結果の情報が多いので、気づいたときに取り込んで、判断ツールの回答精度を上げています。手間はかかりますが、一度入れれば再利用できます。API連携がない媒体やアンケート回答などは、CSVを手動で取り込んでいます。

ただし、全部を入れているわけではありません。個人情報と機密情報には線引きがあり、入れないと決めたものは入れていません。何を入れていないかはここには書きませんが、どこまで入れるかは、それぞれの環境で判断してください。

以前はデータが断片的で、一つずつ処理して判断する必要がありました。統合できたことで、意思決定のスピードが上がり、質も上がり、できることが増えたと思います。数字では示せませんが、実感としてはハッキリあります。具体的には、次のような変化です。

データを見て湧いた仮説を、その場で定量的に検証できます。バックログに載せるほどでない内容でも、AIに投げれば、複数のデータを横断して参照し、統合した答えが返ってきます。
カスタマーサポートからエスカレーションされた不具合は、以前は開発者に確認してもらっていましたが、今は私がAIに投げて、ドキュメントやソースコードを参照した回答を得ています。開発者の時間を、できるだけ奪わないようにできたと思います。
AIの側から提案が出てくるので、人間には思いつかなかった部分を補ってもらえます。

もちろん、考えた施策をすべて実行できるわけではありません。

あわせて、定期的に見るものは定期タスク4件（週次2・月次1・四半期1）にして、ダッシュボードとトレンドCSVが更新されるようにしました。ただし4件のうち2件は、実行中に手動入力や添付を確認する工程を含み、完全な無人実行ではありません。経営判断が絡むものは、いくつかのシナリオを提示しつつ、そこから微調整して数字を動かして可能性を探れるシミュレーター（5件以上）を作り、判断してもらう形にしています。

では、人は何をするのか（仮説）

ここまでやってみて、この種の仕事の多くはAIで代替されてしまうと思います。では、自動化が進んだ先で、人には何が残るのでしょうか。私は、人が不要になるとは思っていません。

判断が分かれるのは、好みやポリシーのような、言語化や定量化がまだされていない（あるいは難しい）部分だと思います。とはいえ、好みも書き出せばその時点でドキュメントになり、AIが読めるようになります。世界観が言語化すれば模倣できる、という話は、以前のLVMHの記事でも書きました。

人に残るのは、判断基準をどれだけ速く更新し続けられるか、だと思います。 仮説を立てて決め、実行し、結果を確認して、基準を見直す。このPDCAの一周を、AIと一緒にどれだけ速く回せるかです。書き出した基準はストックとして残せますが、更新し続ける過程はフローで、実際に回した回数でしか積み上がりません。

これは今のところ仮説で、検証はこれからです。

再現するなら

これから導入するなら、次の4つが前提になると思います。

判断に足りる量のデータがあること：私の環境はユーザーが約330万人いるので、施策を打つと、統計的に問題のない量のデータがすぐ取れます。同じ規模がない場合は、そもそもその量でデータによる判断ができるのか、から確かめる必要があります。
すでにある資産：過去の意思決定やドキュメントに、AIがアクセスできること。ゼロからなら、まず溜めるところからになります。
AIに作業を任せることを前提にした、運営の方針とルール：セキュリティのリスクを正しく理解して、日頃から意識して使える人と組織であること。私の環境は情報セキュリティの国際規格（ISO27001）を取得していますが、あれば望ましい程度で、必須ではありません。認証があるから安全、という話ではないと考えています。何をAIに読ませるかの線引きも、それぞれで決めてください。
牽引・主導する人や部署：そういう人や部署がいないと、広がらないと思います。