私のプロダクト観を作ってくれた本が2冊ある。Marty Cagan の Inspired と、Joca Torres の Gestão de Produtos だ。Joca 本人にメンタリングしてもらえる幸運にも恵まれた。長年この2冊は私の地図だった。PM とは何か、プロダクトデザイナーとは何か、エンジニアとは何か、誰が何をやるのか。それぞれの役割にくっきりした輪郭があった。
この1年、Prolog で自分のチームが AI と働くのを見ていて、その輪郭がずれていくのを感じ始めた。本が間違いになったわけではない。各役割が起きるレイヤーが一段上がったのだ。
シリーズの第1回では、Prolog でテックを作り直し始めるきっかけになった違和感を語り、第2回では harness とは何か、AI を実際に働かせるインフラについて書いた。第1回の最後で、ある具体的な部分を開いてみせると約束した。AI が作る側になったとき、それぞれの職種の仕事がどう変わるのか。それがここのテーマだ。
仕事は消えない、一段上のレイヤーへ上がる
AI は各職種の役割を消しているのではない。役割が起きるレイヤーを変えているのだ。
わかりやすい読み方、恐怖を売る読み方は「AI が職種 X を置き換える」だが、それは私が見たことではない。私が見たのは、仕事の中身が場所を変えたことだ。かつてやることだったものが、やる人をディレクションし批評することになった。
コードを書いていたエンジニアは、いまエージェントが書いたものをレビューする。スペックを書いていた PM は、いまそこから数時間で出てきたプロトタイプを判断する。人は同じで、その手の中にある道具が変わったのだ。
これを頭に置いて Cagan と Joca に戻ったとき、腑に落ち方が違った。2人とも、各役割の実行を丁寧に描いている。具体的なタスク、成果物、1日の終わりに自分の手から出ていくもの。そしてそれこそが AI が引き受けているものだ。人間に残るのはもう半分だ。何を作る価値があるかを決め、作られたものの穴を見つけ、何が良いかを知るテイストを持つこと。実行ではなく、判断だ。
だから私は自分に対してやったことをやる。各役割の定義を本から取り出し、そのうち何を AI が食い、何が残る(そしてより高価になる)かを問う。
本による、3人のチーム
役割ごとに分ける前に、本がチームをどう組み立てるかを思い出す価値がある。Joca はストレートだ。成功するプロダクトは、望ましく、実現可能で、作れるものでなければならず、それが「成功するプロダクトを作るための3つの本質的な機能」(第2章)を定義する。UX デザイナー、プロダクトマネジメント、開発者、彼が core team と呼ぶトリオだ。Cagan は Inspired の冒頭の章「Key Roles and Responsibilities」で同じ役割を描いている。
2人とも、最後にまた戻ってくる1点を強く言っている。上司と部下の関係ではない、ということだ。Joca の言葉では「プロダクトエンジニアリング、プロダクトマネジメント、UX はチームであり、これらのグループのあいだに従属関係はない」(第31章)、そして Cagan では同じ考えが、PM とエンジニアリングは「対等で、どちらの立場も他方に従属しない」(第5章、私の訳)として現れる。AI がトリオの真ん中に入り込むとき、最も形を変えるのはこのパートナーシップだ。
表:テックの各職種が一段上へ。エンジニアリングはコードの生産者からエージェントの批評家へ、プロダクトはスペックの書き手からイテレーションのアーキテクトへ、デザインは画面の生産者から実験の指揮者へ、品質はテスターから検証の作り手へ。
テックにおける各職種の役割
同じ役割が、一段上へ
実行はエージェントへ · 判断はあなたに残る:決める、批評する、taste を持つ
エンジニア:コードの生産者からエージェントの批評家へ
エンジニアリングにとって、価値があるのはどれだけコードを生産するかではなくなった。エージェントが生産したものをどれだけうまく批評するかになった。
Joca の定義は、いま見返すと痛いほど明快だ。「プロダクトエンジニアリングはプロダクトを開発し、稼働し続けさせる責任を負う」、そして少し先で、エンジニアリングは「プロダクトを作る」(第31章)。作ることが動詞だった。Cagan はプロダクトとの関係の側からこれを補う。「プロダクトマネージャーはソリューションを定義する責任を負うが、何が可能かを最もよく知っているのはエンジニアリングチームであり、最終的にそのソリューションを届けるのも彼らだ」(第5章、私の訳)。片方で定義し、もう片方で届ける。
いまや最初のバージョンを届けるのはエージェントだ。変わらず、そしてより高価になったのは、Cagan がイノベーションの源泉としてエンジニアに貼り付けていたすべてだ。「エンジニアは何が可能かを誰よりもよく知っている」(第5章)。何が可能かを知ること、エージェントが提案した計画の穴を見つけること、それに見えていないパフォーマンスやセキュリティのトレードオフを見抜くこと、いつ介入し、いつ走らせておくかを決めること。これが月ごとに重くなる。記憶からのシンタックス、手書きのボイラープレート、Stack Overflow を漁ること、個人のトロフィーとしてのコード量、これは軽くなる。
Prolog では、チームにはっきり言葉にして言った。誰もコードの行数で評価されることはない、と。ずっと「穴を見つける」のが得意だった人はより価値が高まり、「速くたくさんコードを生産する」ことに自分を重ねていた人は、どこに投資するかを再調整しないといけなくなる。そしてこれはエンジニアリングの価値を下げない。その価値はいつも、速く生産することより、何が信頼できるかを知ることの側にあった。いまそれがただ明示的になるだけだ。
PM:スペックの書き手からイテレーションのアーキテクトへ
PM がそれを感じるのは、プロトタイプが安くなったときだ。彼の仕事はドキュメントを書くことであるのをやめ、どのアイデアがチームの時間に値するかを選ぶことになる。
Cagan は仕事の核心について断定的だ。「誰かがソリューション、プロダクトが何であるかを、機能、ユーザー体験、リリース基準を含めて発見しなければならない。その誰かがプロダクトマネージャーであり、そのタスクが彼の仕事の核心だ」(第1章、私の訳)。Joca は広い輪郭を与える。プロダクトマネジメントは「そのプロダクトの構想から寿命の終わりまで、ライフサイクル全体を通じて、ソフトウェアプロダクトのあらゆる側面に責任を負う機能」(第2章)だ。
2人ともキーワードは指定するではなく発見するであることに注目してほしい。Cagan は、仕事は「要求仕様」ではなくディスカバリーだと主張するためだけに丸ごと1章を割いている。ソフトウェアには2つの段階がある。「何を作るかを発見すること(正しいプロダクト)と、作ること(正しいやり方でプロダクトを)。前者はディスカバリーが支配し、後者は実行だ」(第12章、私の訳)。これはずっと彼のメッセージで、AI はそれを文字どおりにしただけだ。
なぜなら、ビルドが数週間から数時間に縮まると、ボトルネックは作ることではなくなり、何を作る価値があるかを決めることになる。委員会でレビューされる長いスペック、締め切った四半期プランニング、成果物としてのステータスレポート、エンジニアリングとデザインのあいだの交通整理、これらはすべて軽くなる。重くなるのは、速いディスカバリー(作るためにスペックを書くのではなく、理解するためにプロトタイプする)、仮説のキュレーション(どのアイデアがチームの時間に値するか)、そしてやらないことをより頻繁に決めることだ。この PM をすでに「エディター」や「アーキテクト」と呼び始めている会社もある。PM が減るのではない。別の PM だ。キュレーションする人、テイストで決める人、方向を与える人。古い版で中心だったスペックを書くこと、それが軽くなったものだ。
プロダクトデザイナー:画面の生産者から実験の指揮者へ
デザインでは、仕事の単位が画面から離れ、画面を生産するシステムへ移る。そしてプロダクトデザイナーは、どのバリエーションが生き残るかを選ぶようになる。
Joca では、UX の定義は描くために理解することだ。「UX はユーザーと、そのユーザーのために解決したい問題を深く理解する責任を負う」(第32章)。そして彼が描くフローは、誰もが知っている儀式だ。ペーパープロトタイプ、次にワイヤーフレーム、次に「UX のビジュアルデザイナーがそれらの画面に色と形を置き始める」。Cagan は同じロジックで役割を2つに切る。interaction designer は「ユーザーへの深い理解を築き、タスク、ナビゲーション、フローを作り」、それをワイヤーフレームに落とし、visual designer に渡す。ビジュアルデザイナーは「ワイヤーフレームに肉をつける」(第4章、私の訳)。
この連なり、理解し、スケッチし、画面ごとに磨き上げる、それこそが AI が短くするものだ。仕事の単位は「画面」であることをやめ、「画面を生成するシステム」になる。同じバリエーションを Figma で5回作り直すこと、コンポーネントごとに指定すること、儀式としてのピクセルパーフェクトなハンドオフ、これは軽くなる。イテレーションの速度でプロトタイプすること(複数の選択肢を並行して、悪いものは捨てる)、各画面を単独でではなくビジュアルシステムを定義すること、そして速いビジュアル批評(AI が何かを提案するのを見て、ユーザーが気づく前に間違っていると一目で見抜く)、これは重くなる。
そしてここで Cagan は、2008年に、プロダクトデザイナーが自分はボタン押し係になったと思い込むのを守る一言を言っている。彼の仕事は決してただ綺麗に描くことだけではなかった。「良いプロダクトは良いユーザー体験を要する。そして良いユーザー体験は、プロダクトとデザインの緊密な協働を要する」(第4章、私の訳)。AI はバリエーションを生成する。そのうちどれがユーザーに届く価値があるかを決めるのは、いまもテイストを持った人間だ。
QA:テスターから検証の作り手へ
QA は最も興味深いケースだ。本がほとんど独立させなかった役割であり、そして AI が最も動かす役割だからだ。
注目してほしい。Joca のトリオ(デザイナー、PM、開発者)でも Cagan の役割でも、品質は薄まって現れる。独自の方法を持った独自の座席としてではなく、チームの責任として。長いあいだそれは理にかなっていた。だがいまはもう理にかなわない。理由はシンプルだ。エージェントが速く作り、検証が手作業のままなら、あなたは高速で技術的負債を生産しただけだ。
だから QA は、テストケースを手で回す人であることをやめ、testing harness、システムをテストするシステムを設計する人になる。あるAIが書いたコードのテストを書くようAIを構成し、ユーザーの前にリグレッションを検出し、欠陥がどこに現れがちかを考えること。実際には、私たちが採り入れた運用上の問いになった。すり抜けたバグはすべて「次はこれをどう自動で検出するか?」になる。既知のフローの網羅的な手動テスト、リリースごとに手で回すリグレッション、出す前の単一のゲートとしての QA、これは軽くなる。ラインの終わりでのパス回しとしてではなく、システムとしての検証だ。
最も定義されていなかったからこそ、最もレイヤーが上がる役割だ。本が輪郭を刻まなかったところに、AI が新しい輪郭を描いている。
変わらないもの:本がすでに最も大事だと言っていたこと
変わらないものが1つある。それは2冊の本の中で、丸見えの場所に隠れていた。彼らが最も重要なものとして挙げるものこそ、まさに AI がやらないことだ。
Joca は良い PM の特性の章を、はぐらかさずに開く。「すべての中で最も重要なのは、疑いなく、共感だ」(第4章)。機能表でも成果物でもない。使う人の立場に自分を置く能力だ。Cagan は彼の側で、プロセスよりもディスカバリー、テイスト、判断を擁護することに本まるごとを費やす。そして2人は、それぞれのやり方で、同じことを言っていた。良い人と平凡な人を分けるのは、決して仕事の機械的な部分ではなかった。
そしてその機械的な部分こそ、エージェントに行ったものだ。スペックを書く、画面を描く、コードを書く、テストを回す。残ったもの、そしてより高価になったものは、批判的思考、テイスト(何が良いかを知ること)、曖昧さの中での判断、好奇心、自分が作るものを使う人へのケアだ。チームに使った一言でまとめると、仕事の中身は変わる、それをやる人は変わらない。
2層の図。上は、私たちに残ってより高価になったもの:taste(何が良いかを知る)、曖昧さのなかでの判断、使う人への共感、何をやらないかを決める、本がすでに最も大事だと言っていたもの。仕事が一段上がった。下は、エージェントに行ったもの:スペックを書く、画面を描く、コードを書く、手動テストを回す。
私たちに残った · そして高くなった
本がすでに最も大事だと言っていたもの
仕事が一段上がった
エージェントに行った
これが何を求めるか(クリシェ抜きで)
これをあまり綺麗に締めたくない。実際そうではないからだ。この変化は具体的なものを求めるし、そのどれも心地よくない。
まず、10年ぶんの習慣を後ろに置いていくこと。5年、10年と古いやり方にいる人は、ここまで来るのを助けてくれたパターンを背負っている。そしてその同じパターンこそ、変わるのに重くのしかかるものだ。近道はないし、その居心地の悪さは織り込み済みだ。
次に、AI と一緒に作るのと同じくらい、AI を批評すること。出てきた提案を受け入れるのは仕事ではない。それが提案した計画の穴を見つけるのは、仕事だ。ずっと高価だったもの(批判的思考、テイスト、判断)がより高価になる。
それから、人としてではなくチームとして間違えること。私たちは本番のバグでエンジニアを解雇しない、レビューを良くする。そして AI が間違えたときは、強くするのは harness だ。エージェントのバグはプロセスであって人ではない。スローガンではなく、1つのコミットメントだ。
そして最も居心地の悪いもの。ある機能は他より大きく変わることを受け入れること。これはこれまであまり変わらなかった人に不快を生むし、すべて同じだとふりをすることはできない。できるのは、それを開かれた会話に持ち込むことだ。
そして、到達した人のように聞こえないために。Prolog はまだこれの始まりにいる。私たちは依然として AI-assisted で、10〜20%の伸びだ。5倍や10倍の AI-first ではない。私が語っているのは、当たりと外れを伴って私たちが作っている途中の方向であって、勝利ではない。
私がここから持ち帰るもの
本は間違いになったわけではない。彼らは各役割の実行を、私がいまになってようやく本当に理解できた精度で描いていた(スペックを書く、画面を描く、プロダクトを作る、テストを回す)。そしてその実行はいまエージェントのものだ。人間に残ったのはもう一方の部分だ。判断し、批評し、テイストを持ち、使う人をケアすること。Cagan と Joca に戻れば、それこそ彼らが最初のページから最も大事だと言っていたことだ。
たぶんそこが良い部分だ。AI が私たちの手から取り上げた仕事は最も反復的な部分で、残したものはいつも最も難しく、最も面白かったものだ。どうなっていくか、これからも語り続ける。
出典
- Marty Cagan, Inspired: How to Create Products Customers Love(初版、2008年)。役割の定義は第1章(Key Roles and Responsibilities)、第4章(Product Management vs. Design)、第5章(Product Management vs. Engineering)、第12章(Product Discovery)から。引用箇所の訳は私によるもの。
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software(Casa do Código)。定義は第2章(ソフトウェアプロダクトマネジメントとは何か?)、第4章(プロダクトマネージャーの主な特性)、第31章(プロダクトエンジニアリングとプロダクトマネジメント)、第32章(UX とプロダクトマネジメント)から。
- 役割が一段上のレイヤーへ上がるという読みは、このシリーズを支えている。OpenAI, Harness Engineering、そして Peter Pang、CREAO の CTO。