役割は収束しているのではなく、拡張している：AIビルダー時代のAtlassianのPMの働き方

イェホシュアは、1〜2年前には「誰もが他人の職能を指差して」、それがなくなると予言していたと振り返った。PMはエンジニアに仕事がなくなると言い、デザイナーはPMに同じことを言い、人々は本気で不安を感じていた。イェホシュアによれば、そうした会話はほぼ聞かれなくなった。今議論されているのは、仕事が重なり合うことであり、そしてAIビルダーという新しい役割についてだ。

イェホシュアは、この役割は実在するものだと述べた。PMやデザイナーではなく「ビルダー」を採用し、それに合わせた職務記述書を用意しているスタートアップもあり、ビルダーは小さな企業にも大企業にも存在する。創業者は昔からこのように働いてきたとも指摘した。会社を立ち上げるときには、いくつもの役割を兼ねるものだ。今回の講演のテーマは、それが大規模な組織ではどのような形になるかということだった。多くの人が5人規模のスタートアップについてのポッドキャストを聞いても、それが自分たちの現実にどう当てはまるのかわからずにいる、とイェホシュアは指摘した。チームがコーディングエージェントを使ってコードベースをリファクタリングしているようなエンジニアリング側の話はひとまず脇に置き、PMだけに焦点を当てることにしたという。

イェホシュアの見方では、PMの中核となる仕事は変わっていない。今もプロダクトマーケットフィットを見つけ、人々に愛されるプロダクトを作り、顧客がお金を払ってくれるビジネスであることを確かなものにすることだ。変わったのはその方法である。

1つ目の変化はツールで、急速に進化し続けている。どうすれば追いつけるのかとよく聞かれるが、イェホシュアの答えは「追いつけない」であり、誰にもできないのではないかと考えている。Xに書かれていることを何でも信じるのではなく、自分たちの顧客にとって実際に役立つものに集中すべきだというのがその助言だ。

2つ目の変化はコンテキストだ。イェホシュアは、昨今話題になっているコンテキストグラフや「エンタープライズブレイン」に触れ、それは非常に現実的なものだと述べた。Atlassianでは、組織の全コンテキストを可視化するために、チームワークグラフと呼ぶものを構築した。その結果、PMはもはや会議のメモを取ったり、アクションアイテムを追いかけたり、ゴートゥーマーケットチームにローンチ時期を伝えたりする役目を担う必要がなくなった。イェホシュアは前の週の出来事を例に挙げた。CEOのマイクが、イェホシュアとあるプロダクトリードに、ある機能のローンチ時期を尋ねるメッセージを送ってきた。その5分後、マイクはAtlassianのAIプロダクトであるRovoからの回答のスクリーンショットを送り、これで合っているかと尋ねた。回答は正しく、マイクは時間を無駄にさせたことを詫びた。イェホシュアが言いたかったのは、人々はこうした情報にアクセスできるにもかかわらず、実際に活用するにはまだ手助けが必要だということだ。これはチェンジマネジメントの問題であり、PMはそれを最前列で目の当たりにしている。

イェホシュアは、PMにとってのチャンスを「加速」と位置づけた。Atlassianではチームを目的地に向かう船と捉えており、より速く到達する方法の1つが、インテリジェンスとコンテキストの組み合わせ、つまりモデルの知能と組織のコンテキストを掛け合わせることだ。

この比喩の中で、PMにとっての問いは、自分が漕いでいるのか、舵を取っているのかということになる。Atlassianは実験を行い、チームをさまざまな形で編成し、アウトプットを測定した。イェホシュアによれば、結論は「場合による」、つまりプロダクトの種類とフェーズ次第だった。続いてイェホシュアは3つの例を紹介した。

• 既存のコードベースにおける新機能
• ゼロからイチを生み出すプロダクト
• 非常に大規模な既存コードベースの機能強化

Confluenceは最近、AIベースの機能を2つリリースした。Remix with Rovoでは、ユーザーがテキストをハイライトし、選んだ形式に変換できる。Confluence Slidesは、ワンクリックでページをスライドに変換する。イェホシュアは、チームが単に何を作るかを決めただけではないことを強調した。チームは、はるかに速く開発し、働き方を大きく変えるという課題を自らに課した。そしてそれは、まっさらな状態から始める場合とは大企業の中では事情が異なるという。

PMがコードをチェックインした。 PMのヤーは、それまでコードを書いたこともターミナルを使ったこともなかった。エンジニアリングのパートナーが、ヤーがフロントエンドのコードをチェックインしやすくなるハーネスを構築した。イェホシュアはこれを例に、より大きなポイントを示した。ツールをうまく使うには、ときに誰かと組む必要があるということだ。ヤーは1か月で26件のPRをチェックインし、イェホシュアによれば、これはチームのほとんどのエンジニアよりも多かった。理由を尋ねられたヤーは、必要なUXの修正が数多くあったのに対応できるエンジニアが足りず、エンジニアにはより高度な仕事に集中してほしかったと答えた。ヤーはこれを、プロジェクトを加速させるために自分にできることだと考えていた。

評価（eval）。 イェホシュアは、ほとんどのPMが、評価が今や仕事の重要な一部であることを理解していることを願っていると述べた。PMが評価を担当するチームもあれば、エンジニアが担当するチームもある。Confluence Slidesでは評価を正しく行うことが非常に重要だったため、従来評価を担ってきたPMがエンジニアと協力し、プロダクトをどのように評価したいかを伝えた。これにより、評価のスループットは2倍になった。PMはまた、Atlassianがデバッグに使っているLLMプラットフォームのArizeを使ってプロンプトの問題を見つけ、より速くエンジニアに送った。

デザインバグの自動修正。 イェホシュアはこれを一番のお気に入りだと語った。コードがデザインと一致しないことはよくあるため、チームはFigma MCPを使ってFigmaのデザインを実際のコードに対応づけ、その不一致をコーディングエージェントに修正させた。1時間でおよそ14件のバグを修正できたという。

テストの作成。 エンジニアがテストの作成に費やす時間は、半日から約10分に短縮された。

成果。 Remixは6週間で、スライド機能は8週間でリリースされた。イェホシュアは、スタートアップにとっては長く聞こえるかもしれないと認めつつ、エンタープライズソフトウェアはコンプライアンスとセキュリティを満たす必要があり、その作業にこそ最も時間がかかることが多いと述べた。AI以前であれば約6か月かかっていただろうとイェホシュアは見積もっている。ベータ顧客や社内ユーザーとのイテレーションのサイクルもはるかに短くなった。

成功の要因。 このケースでは、PMが漕いでいた。コードをチェックインすることが船を進める最速の方法だとヤーが判断したからだ。エンジニアリングマネージャーは、より大きなリポジトリを壊さないよう、クリーンで隔離されたリポジトリをヤーに用意した。イェホシュアはこれを非常に重要だと述べた。チームはまた、意図的な貢献モデルについて事前に合意していた。意図的に役割の境界を曖昧にし、既存のプロセスを問い直すことを約束したのだ。

RovoClawはRovoの機能ではなく、ゼロから構築されたゼロイチのプロジェクトだった。始まりはPMのジョシュとデザイナーのケビンで、2人はすべてをバイブコーディングし、社内の顧客が使える動作するアルファ版まで仕上げた。手応えをつかんだところでエンジニアを加えた。PMとデザイナーは、その後もエンジニアと並んでコードをチェックインし続けた。

その後ジョシュは、自分がコーディングに忙しくしているせいで、エンジニアたちが軌道から外れ始めていることに気づいた。ジョシュは、コーディングが本当に自分にとって最もレバレッジの高い活動なのかと自問した。そして一歩引き、PMが通常行うこと、つまり方向性を定め、優先順位をつけ、障害を取り除くことに専念すると決めた。イェホシュアによれば、そこから物事ははるかに速く進むようになった。初期にコーディングしていたことは大いに役立ったとも付け加えた。ジョシュは障害や課題を理解していたため、より上手に舵を取れたのだ。

ジョシュはまた、AIを使ってほかの作業をやめた。イェホシュアは、いまだに週次レポートを手作業で書いている人は、そのためのエージェントを作るべきだと促した。ジョシュはRovoClawの中に、RovoClawプロジェクト自体の週次アップデートを書くエージェントを構築した。イェホシュアはこれを「とても面白い」と評した。ジョシュはもう週次アップデートを書いていない。

イェホシュアの結論はこうだ。PMは最初は漕いでいたが、プロジェクトが別のフェーズに入ったため、舵取りに移った。その時々でチームの障害を取り除くことに集中し、コードを書ける能力がそれを助けた。

Jiraは20年以上の歴史を持ち、大規模で複雑なコードベースを抱えている。データセンター版から始まり、クラウドへと移行した。アイソレートされたクラウド、FedRAMP、カスタマイズをサポートし、「失敗が許されない」数十万の顧客にサービスを提供している。イェホシュアによれば、この環境でPMがコードをチェックインするのは危険になりうるため、Atlassianはそうさせないことを選んだ。

それでも目標は、JiraをAIファーストにすることだった。PMとエンジニアは、顧客がソフトウェア開発でAIを活用できるよう支援するAI機能を構築した。ソフトウェア開発ライフサイクルの見直し、エージェントへの作業の割り当て、Jira全体でのシームレスなエージェントの活用などだ。着手からリリースまでのスループットは通常の約3倍となり、チームは約10週間で22のユーザー向け機能をリリースした。イェホシュアは、その背景にあるいくつかの変化を説明した。

実際の環境でのプロトタイピング。 プロトタイプはLoomから始まった。PMは、変更したいUIを録画したり、トークトラックを付けてFigmaのデザインを順に説明したり、単にブレインストーミングしたりできた。Loomはその録画から自動的にワークアイテムを作成できた。PMがワークアイテムを「進行中」に移すと、コーディングエージェントが自動的に起動した。そのエージェントはクラウド上のマネージドエージェントを使って実際のフロントエンドリポジトリにコードを書くため、PMはローカル環境に対処する必要がなかった。生成されたコードは、最初からコンプライアンスとアクセシビリティを満たし、Atlassianのデザイン言語に沿っていた。チームがプロトタイプを実装したい場合、開発者への引き継ぎもはるかに速かった。イェホシュアは、適切なプロトタイピング環境を持つことが鍵であり、「大きなブレイクスルー」だったと述べた。

社内フィードバックのトリアージ。 Atlassianでは全員がJiraを使っているため、変更を加えると大量のフィードバックが寄せられる。Slackに届くフィードバックやバグは、Slack内のJiraエージェントによってトリアージされ、修正のために自動的にコーディングエージェントに送られた。イェホシュアによれば、これによってエンジニアリングの時間が大幅に節約された。

顧客インサイト。 チームは多数のユーザー調査を実施し、Jira Service Managementを使ってすべての動画をレビューし、900件以上のフィードバックを集めた。その後、Rovoエージェントがそれらをトリアージし、分類した。イェホシュアによれば、チームはトリアージの質に「とてもうれしい驚き」を感じたという。そしてそれによって、何をエンジニアリングに送るべきかがわかった。

ここでは、PMは明らかに舵を取っていた。エンジニアの障害を取り除き、社内外のフィードバックをより効果的に処理し、再利用できるように設計されたプロトタイプを作っていた。PMが本番環境にコードをチェックインすることはなかった。

イェホシュアは、これらの例全体を通じて、PMの新たな活動として次のものを挙げた。プロトタイピングとテスト、評価の作成、顧客フィードバックへのより深い取り組み、そしてはるかに高いペースでの情報の取り込みだ。これらはすべて、AIツールが組織のコンテキストを理解していることに依存しており、Atlassianではそれがチームワークグラフの上に構築されているという。

PMがやめたことには、手作業でのアップデート、リサーチの手作業での取りまとめ、スライドのゼロからの作成などがある。イェホシュアは、同期型の会議がなくなったと言えればうれしいが、それは誇張になるだろうと述べた。減ってはいるとイェホシュアは考えている。

スタートアップのリーダーたちは、AIネイティブな人材を採用すべきだとよくイェホシュアに言う。Atlassianにはすでに優秀なPMが大勢いるため、目標は彼らがAIネイティブになるのを支援することだ。

そのために、同社は6つの能力を対象とするAI Fluency Indexを導入した。イェホシュアが挙げた例は次のとおりだ。

• ツールの使い方を理解していること
• 評価を書くこと
• データインサイトを自動化すること
• プロトタイピング
• 必要な技術リテラシーを備えていること

各能力は1から5で評価される。1は「好奇心がある（curious）」、3は「対応できる（capable）」、5は「先駆的（pioneering）」だ。イェホシュアは、これはキャリアラダーではなく育成ツールであり、変化し続けるスキルの北極星だと強調した。キャリアラダーは顧客にとっての成果に関するものだ。Atlassianは、すべてのPMがすべての項目で5に達することを期待しているわけではない。ただし、時間をかけて全員がすべての能力でレベル3に達し、自分のチームにとって最も重要なものでは5に達することを期待している。

Atlassianが試したトレーニング手法のうち、最も定着したのはAI Builder Weekだったとイェホシュアは語った。四半期に1度、PMとデザイナーは1週間通常業務を離れる。まず外部スピーカーの講演で始まる（イェホシュアは、直近の回で講演したクレアに謝意を述べた）。次に、より進んだ社内のPMが、ほかのメンバーに特定のスキルを教える。最後に、参加者は学んだことを応用するプロジェクトに、自分のチームまたはほかのメンバーと取り組む。

イェホシュアはこれを大成功と評した。参加者は1,000人を超え、期間中に作られた120以上の新しいワークフローが今も使われている。各回は1つのトピックに焦点を当てる。これまでのトピックは、プロトタイピング、評価、エージェントの構築、そして直近ではコードのチェックインだった。顧客と話し合ったうえで、Atlassianはこれまで使ってきたアジェンダを含む「AI Builder Week in a box」を自社のウェブサイトで公開した。

Atlassianは成果をどう測定しているのか、と顧客からよく聞かれる。イェホシュアは率直に、同社はまだその答えを見つけておらず、見つけた企業はないのではないかと述べた。イェホシュアはこれを、開発者のベロシティを測定するという昔からの問題になぞらえた。

Atlassianは現在、書かれたPRではなく本番環境にデプロイされたPRを測定している。また、アイデアから顧客の手に届き使われるまでの、デリバリーされた機能も測定しているが、ある機能がいつ始まったのかを特定するのは難しいとイェホシュアは述べた。OKRが達成されているかどうか、そして全体のスループットも追跡している。イェホシュアは、スループットは組織全体よりも1つのチームのほうが測定しやすいことが多いため、両方に注意を払う必要があると指摘した。チームは四半期ごとに実験を行い、会社はどのような成果を測定できるかを検討している。イェホシュアは聴衆にアイデアを共有してほしいと呼びかけた。

イェホシュアは、自身の主張の核心に立ち返った。それぞれの役割は拡張している。PMは仕事を効果的にこなすためにより多くのことができ、顧客により多くを届けられる。イェホシュアは、今こそPMにとって最高の時代だと述べ、自らを楽観主義者だと称し、この会場にいる全員が10年後もこの仕事を続けているだろうと語った。