AIツールがPMとエンジニアリングの境界を曖昧にする方法

なぜAIはPMとエンジニアの境界を変えるのか

長い間、プロダクトマネジメントとエンジニアリングの分担は比較的明確でした。PMはディスカバリーと意思決定（何を作るか、なぜ作るか）を担い、エンジニアは実装（どう作るか、どれくらい時間がかかるか、どのトレードオフが許容されるか）を担っていました。

AIツールがその分担を完全に消すわけではありませんが、これまで境界を保っていた受け渡しポイントを弱めます。

伝統的な分業はドキュメントに依存していた

多くのチームはドキュメントを共同作業の単位として扱ってきました：PRD、ユーザーストーリー、デザインファイル、テスト計画など。PMが入力を作り（あるいはキュレーションし）、エンジニアがそれを動くソフトウェアに変え、フィードバックループは何かが作られた後に起こりました。

このモデルは自然と境界を生み出しました：ドキュメントの作成者でなければ、主にレビュアーの立場だったのです。

AIは作業単位をドキュメントから“共有モデル”へと移す

AI支援のドラフト、要約、生成により、チームはますます「共有モデル」を扱うようになります。これはクエリでき、リファクタリングでき、フォーマット間で翻訳できる生きたコンテキストの束です。

同じコアの意図が素早く次のような成果物に変わります：

• スペックと受け入れ基準
• プロトタイプやUI文言
• 実装のスライスやAPIスケッチ
• テストアウトラインやエッジケース

翻訳が安価になると境界が移動します。PMはより早く実装面に問いかけられるようになり（「Xを変えたら何が必要か？」）、エンジニアは製品の意図を早く掴んで引けるようになります（「Yを最適化したら目標は保てるか？」）。

役割の置き換えではなく、責任のずれが起きる

AIは歴史的に自分のレーン外の作業を行う摩擦を減らします。それは有益ですが、期待も変わります：PMにはより厳密さが求められ、エンジニアにはスコープ形成への直接的な参加が求められることが増えます。

最初に曖昧になるのは実務です：スペック、小さなコード変更、テスト、データの問い合わせ—速度が重要でAIが意図を数分で成果物に翻訳できる分野です。

PRDからユーザーストーリーへ：AIは要件の共著者になる

AIツールはますます“ファーストパス”の要件作成者のように振る舞います。つまり、要件作業は白紙から始めるのではなく、しばしば批評・精練・整合が可能な下書きから始まります。

AIがドラフトできるもの（とその利点）

一般的なPMのアウトプットがより早く、標準化しやすくなります：

• PRDの下書き（問題、ゴール、非ゴール、仮定、依存関係、未解決の質問などの一貫したセクション）
• ロードマップの選択肢（例：「ファストフォロー」「プラットフォーム優先」「パイロット優先」）とそれぞれのトレードオフやリスク
• ユーザーストーリー（ペルソナやシナリオに紐づけ、チームが見落としがちなエッジケースを含む）
• 受け入れ基準（成果をテスト可能な文に翻訳する）

AIの強みは「プロダクトを知っている」ことではなく、構造を一貫して適用し、用語を揃え、代替案を素早く生成できる点です。結果としてPMとエンジニアはフォーマットの整形ではなく、意図と制約について議論する時間が増えます。

主な失敗モード：曖昧なプロンプト→曖昧な要件

AIは曖昧さを鏡のように反映します。プロンプトが「オンボーディングを改善して」とだけあれば、広範で抽象的なユーザーストーリーといい加減な受け入れ基準が返ってきます。その後、チームは「良い」状態が何か合意せずに実装を巡って議論します。

簡単な対処法：コンテキスト＋決定＋制約でプロンプトする。対象ユーザー、現行の挙動、成功指標、プラットフォームの制限、変えてはいけない点を含めます。

みんなを合わせる「ソース・オブ・トゥルース」ワークフロー

AI出力を提案として扱い、仕様そのものとしないでください。

1. バージョン管理をコードのように行う（ドキュメント履歴、チェンジログ、軽量RFCテンプレートなど）。
2. レビューを二段階で行う：PMが意図と優先度を確認；エンジニアが実現可能性を確認し隠れた作業を指摘する。
3. 明示的承認（誰がサインオフするか、どのフィールドが必須か、再承認を引き起こす条件）。
4. アーティファクトをリンク：PRD → エピック → ユーザーストーリー → 受け入れ基準。編集が静かに乖離しないようにする。

これにより速度を維持しながらアカウンタビリティを失わず、「ドキュメントに書いてあった」はずの驚きが減ります。

ディスカバリーが速くなる—だがより強いガードレールが必要

AIはサポートチケット、通話ノート、アプリレビュー、アンケートのコメント、コミュニティスレッドなどの雑多な入力を構造化テーマに圧縮して、数週間分のディスカバリーを数時間に短縮できます。全てを手で読む代わりに、プロダクトとエンジニアリングが同じサマリー（繰り返される痛点、それが現れる文脈、検討に値する機会のショートリスト）から始められます。

生のフィードバックから有用なテーマへ

現代のAIツールは「モバイルでチェックアウトが失敗する」といった類似の不満をクラスタリングし、ユーザーが達成しようとしていた“仕事”を抽出し、共通のトリガー（デバイス種別、プラン、ワークフローのステップ）を浮かび上がらせます。価値は速度だけでなく共有コンテキストにあります。エンジニアは技術的制約（レイテンシスパイク、統合のエッジケース）に紐づいたパターンを見、PMはユーザー成果につなげられます。

速くして正直でいるための軽量プロセス

ディスカバリーを速く保ちながらAI任せの推測にしないために、シンプルなループを使ってください：

1. 入力にタグを付ける：セグメント、チャネル、緊急度、機能領域などの基本メタデータ。数個の一貫したタグだけで後のサマリーは大きく改善します。
2. バッチで要約する：週単位またはリリース毎に、頻度・代表的な引用・トップ仮説を含む短いテーマレポートを作る。
3. 明示的基準で優先順位付け：リーチ、深刻度、収益リスク、戦略適合、信頼度などの合意したシグナルでスコアリングする。
4. コミット前に検証する：ターゲティッドインタビュー、短いアンケート、ファネル分析、ログクエリなどで1–2件の素早いチェックを行い、テーマが実態を反映するか確認する。

バイアスリスク：声の大きいユーザーと整いすぎた物語

AIは見つけやすく感情的なもの（パワーユーザー、怒りのチケット、文筆が上手いチャネル）に過度に適合することがあります。また矛盾を滑らかにしてしまい、製品上重要な違いを消してしまうこともあります。

ガードレールとしては、セグメント横断のサンプリング、ユーザーベース規模による重み付け、頻度と影響の分離、そして観察と解釈を明確に分けることが有効です。

まだ人間が必要なこと

AIは要約と提案を行えます。判断は人間が行います。

トレードオフの選択、戦略設定、何を作らないかの決定にはビジネスコンテキスト、タイミング、技術コスト、二次効果の理解が必要です。目標はディスカバリーを速めることであり、プロダクト思考を代行させることではありません。

デザインとUX：プロトタイプが共有される“生きた”アーティファクトになる

AIはチームが製品を“見る”方法を変えています。デザインが静的なモックを渡す代わりに、PM、デザイナー、エンジニアが日々進化するプロトタイプで共同作業することが増え、それがAIで生成・改訂されることも多いです。

より速いプロトタイプ：フロー、UI文言、状態

AI支援のデザインツールやLLMを使えば、チームは次のようなものを素早く作成できます：

• 主要なユーザーフロー（ハッピーパスと一般的な迂回経路）
• UIのマイクロコピー（ボタンラベル、空の状態、エラーメッセージ、オンボーディングのヒント）
• セグメント、権限、デバイスサイズごとの画面バリアント

初期のプロトタイプは「見た目」以上のものになります。状態ごとに「何を言うか」「どう振る舞うか」もエンコードされます。

エンジニアが早い段階でインタラクション案を提案する

エンジニアはAIを使ってインタラクションパターンを素早く検討し、重いデザイン作業が始まる前に選択肢を持ち寄れます。例えば、フィルタリング、バルクアクション、プログレッシブディスクロージャの代替案を生成し、パフォーマンス、アクセシビリティ、コンポーネントライブラリの制約と照らし合わせて現実性をチェックします。

これによりフィードバックループが短くなります：実現可能性と実装の詳細がUXが可塑的なうちに現れ、レイトステージの受け渡し後ではなくなります。

PMは開発前にメッセージとエッジケースを検証できる

PMはAIを使ってプロトタイプの文言やエッジケースをプレッシャーテストできます：「結果がないときユーザーは何を見るか？」「ユーザーを責めない形でエラーを説明するには？」「初めてのユーザーが混乱する箇所はどこか？」など。

また、FAQ、ツールチップ、A/Bテスト用の代替メッセージを生成できるため、プロダクトディスカバリーに言語が含まれるようになります。

新しいハンドオフ：モックは少なく、反復は多く

ハンドオフは「最終化された画面」から、共有プロトタイプと明確な決定事項へと移行します：スコープに含まれるもの、先送りされるもの、測定可能なこと。

プロトタイプはチーム全体が制約や学び、要件の変化に応じて更新する生きたアーティファクトになり、サプライズを減らしUXを継続的でクロスファンクショナルな責任領域にします。

コード生成がPMを実装に近づける

AIによるコード生成は、プロダクトの意図と動くソフトウェアとの距離を縮めます。PMがアシスタントに小さなUI、サンプルAPIリクエスト、最小限のスクリプトを頼めると、会話は抽象的な要件から具体的な振る舞いへと変わります。

ここで「vibe-coding」プラットフォームが協働ダイナミクスを変えます：たとえばKoder.aiのようなツールはチャットからウェブ、バックエンド、モバイルのスライスを直接構築できるので、PMがフローを提案し、エンジニアがそれを強化し、両者が同じアーティファクトを待たずに反復できます。

コード生成が得意なこと

多くのAIツールは、説明しやすくてフルエンジニアサイクルを正当化しにくいタスクで効果を発揮します：

• スキャフォールディング：基本的なプロジェクト構造、スタブのエンドポイント、シンプルなコンポーネントレイアウトを立ち上げる。
• グルーコード：システム間のフィールドマッピング、ペイロード整形、UIイベントの配線、小さなアダプタ作成。
• サンプルや参照スニペット：サンプルクエリ、バリデーションルール、エッジケースの処理パターン、「これをReact/Swift/Pythonでどう書くか？」の例。

このように使うと、AIのコードは早いスケッチになり—そのまま出荷するものではなく、反応するための材料になります。

PMが意図を明確にするためのプルーフ・オブ・コンセプト

PMはエンジニアになる必要はありません。小さなAI生成のPoCが曖昧さを減らし、合意を速めます。例：

• 期待するフローとエラー状態を示すクリック可能プロトタイプ
• 「ユーザーが1万行をインポートしたらどうなるか」をシミュレートする小さなスクリプト
• データ要件を明確にするモックのAPIリクエスト/レスポンスペア

目的は要件をより早くテスト可能で議論可能にすること：「これが我々の意味するところか？」を早期に確認するためです。

プロンプトで解決できない制約

“動く”コードが自動的に製品に適合するわけではありません。

セキュリティとプライバシー要件（シークレットの扱い、PII）、アーキテクチャの慣習（サービス境界、データモデル）、保守性（可読性、モニタリング、エラーハンドリング）は依然重要です。AI生成コードは内部ライブラリ、コンプライアンスルール、スケール期待のような文脈的制約を見落としがちです。

レビュー期待と所有権

良いチームのルール：本番コードはエンジニアが所有する。最初の下書きが誰によるものであれ、最終的なプロダクションコードの責任はエンジニアにあります。

PMが作ったスニペットはデザインアーティファクトや探索物と同じ扱いにしてください：意図の把握には役立つが、コードレビュー、テスト、脅威モデリング（該当する場合）と同じ基準でゲートを通す必要があります。

Koder.aiのようなAIビルドプラットフォームを使う場合も同様の原則が適用されます：たとえReact UIとGoバックエンドを迅速に生成できても、チームはマージとリリースに関する明確な所有権を持つ必要があります。スナップショット/ロールバックやソースコードエクスポートは役立ちますが、エンジニアの責任に取って代わるものではありません。

受け入れ基準、QA、テストがより密接に結びつく

AIツールは「我々が意図したこと」と「出したもの」のループを短くします。かつて受け入れ基準はPMが書き、後でエンジニアやQAが解釈していましたが、LLMはその基準を数分で具体的なテストケース（ユニット、API、E2E）に翻訳できます。

受け入れ基準からテストケースへ（高速）

基準が明確であれば、AIは実際のユーザー挙動を鏡像するテストシナリオを作れます。たとえば「ユーザーはメールを変更でき、再確認が必要になる」という基準は、無効なメール、期限切れの確認リンク、確認前にログインしようとしたケース等のテストに広げられます。

出現している実務フローは：

1. PMが受け入れ基準を提示（Gherkin形式や簡潔な箇条書き）
2. AIがテストスイートを提案（シナリオ＋推奨アサーション、データ、注意すべきトリッキーなケース）
3. エンジニアが検証・適用（実現可能性を確認し、適切なテストレベルを選ぶ）

これにより受け入れ基準は単なる手渡し文書ではなく、自動検証の種になります。

回帰リスク：自動テストは誤った安心感を生む

自動生成テストは説得力があるように見えても、重要な点を見逃すことがあります。よくある失敗モードは、ハッピーパスのみをテストする、間違った事柄をアサートする（例えば状態変化ではなくUIテキストをチェックする）、実際のシステムと合わない前提を組み込む、などです。

最大のリスクは回帰の盲点です：テストが存在するからといって十分に保護されていると誤信してマージしてしまうこと。

AI生成テストは草案として扱ってください。

チェックリスト：「テスト可能な要件」生成前に

基準を自動化しやすく誤読しにくくする簡単なチェックリスト：

• 観測可能な成果：成功/失敗を推測せずに検証できるか？
• Given/When/Thenの明確さ：前提条件、アクション、期待結果が明示されているか
• データルールの記載：バリデーションルール、制限、良い/悪い入力例
• エラーハンドリングの定義：失敗/タイムアウト/権限問題時の挙動
• 非機能要件の注記：パフォーマンス、監査ログ、アクセシビリティ、コンプライアンス
• スコープの境界：このリリースで明示的に対象外のもの

要件がテスト可能ならAIは実行を加速します。そうでなければ混乱を早めるだけです。

分析と実験：より速い回答と共有コンテキスト

AIは分析を会話的にします：「新しいオンボーディングはアクティベーションを上げたか？」と尋ねれば、SQL、グラフ、実験の読み取りメモが数分で返ってきます。

このスピードはワークフローを変えます—PMは待ち行列に並ばず仮説を検証でき、エンジニアはインストゥルメンテーション品質に集中できます。

AI生成のSQLとダッシュボード（有用な理由）

現代ツールはSQLをドラフトし、ファネル定義を提案し、ダッシュボードを生成し、A/Bテストを要約します（改善量、有意性、セグメント分割）。PMにとってはディスカバリーとポストローンチの監視のスピードが上がり、エンジニアはワンオフ要求を減らしてデータ取得改善に時間を使えます。

セルフサービス分析には共有定義が必要

問題は、AIは会社の定義の代わりにある定義で答えを返してしまう点です。セルフサービスは次の標準化があると最も効果的になります：

• イベント名とプロパティ（“signup_complete”が何を意味するか）
• 指標の計算式（アクティベーション、リテンション、収益帰属）
• 実験のガードレール（露出、除外、サンプル比チェック）

定義が一貫していれば、PM主導の分析は付加価値になります—エンジニアは数字を信頼し、調査結果を運用化するのに協力できます。

よくある失敗点：指標のドリフトと曖昧なイベント

繰り返し現れる問題は二つです：

• 指標ドリフト：製品進化に伴い“アクティブユーザー”の意味が徐々に変わり、トレンド比較が壊れる。
• 曖昧なイベント名："click_cta"が3箇所に存在するとAIは間違ったものを参照して説得力あるが誤った洞察を出す。

実用的な対処法：指標グロッサリと軽量レビュー

共有の指標グロッサリ（唯一の真実のソース）を作り、主要な分析にクイックレビューを要求してください：大規模ローンチ、実験の読み取り、ボード向けKPIなど。

15分の「分析PR」（PMがドラフト、アナリスト/エンジニアがレビュー）で定義の不一致を早期に発見し、意思決定後に数字をめぐって議論するのを防げます。

バックログ、優先順位付け、見積り：何が変わるか

AIはバックログ管理を置き換えませんが、その質感を変えます。グルーミングは半端なチケットを解読することよりも、意図的なトレードオフを明確にすることになります。

AIをうまく使うとバックログは単なるリストではなく、より明晰な作業マップになります。

グルーミングは速く（かつ具体的に）なる

リファインメントではAIがメモ、営業の通話、サポートスレッド、会議の書き起こしなどの雑多な入力を一貫した構造のチケットに素早く変えられます。特に有用なのは：

• チケットの明確化：問題の要約、受け入れ基準の提案、欠けているコンテキストの指摘（ユーザーセグメント、プラットフォーム、エッジケース）
• 規模感のヒント：過去の類似作業と比較して概算工数を提案
• 依存関係のマッピング：上流/下流の依存を表出させる

重要な変化は、PMは作成時間を削減して意図を検証することに時間を使い、エンジニアは推測を減らして早期に前提を疑えることです。

見積りはリスクが早期に出ると改善する

AI支援のレビューはチケットが“コミットされた作業”になる前にリスク信号を浮かび上がらせます：不明瞭な非機能要件、隠れたマイグレーション作業、セキュリティ/プライバシーの懸念、統合の複雑さなど。

これによりエンジニアは未知の要素をより早く表に出せます—多くはスプリント中ではなくグルーミング中に。見積りは時間ではなくリスクの会話になります。

実用パターンとして、AIに各候補項目と一緒に「リスクチェックリスト：これが2×難しくなる可能性、スパイクが必要な点、デザインやデータで検証すべきこと」を生成させるとよいでしょう。

優先順位付け：自動ランク付けに注意

自動優先付けは魅力的です：インパクト指標を与えてモデルにバックログをソートさせればよい。しかし危険なのは、計測しやすさを最適化してしまい、差別化、長期プラットフォーム作業、ブランド信頼といった戦略的に重要なものを無視してしまう点です。

シンプルなルールを使って決定を健全に保ってください：AIは提案する；人間が決めてその理由を記録する。 アイテムが上下したら、その理由（戦略的結びつき、リスク、顧客コミットメント）をチケット内に書いて共有コンテキストを残す。

AI支援ワークでの所有権、リスク、ガバナンス

PMとエンジニアが同じAIツールを共有する時、新しい失敗モードも共有されます。ガバナンスはチームを遅らせるためのものではなく、誰が決め、誰がチェックし、問題が起きたときに何をするかを明確にするためのものです。

何が起こり得るか（そしてそれが重要な理由）

AI支援の作業は見えにくい失敗を招き、コストがかかるまで気づかれないことがあります：

• データ流出：顧客の機密情報をプロンプトに貼り付ける、内部戦略が外部ツールにコピーされる
• 不安全なコード：生成されたスニペットが脆弱性、弱い認証、不安全な依存を導入する
• ライセンス問題：ポリシーに抵触するコピーや制限されたコードを含む出力
• 追跡不能な意思決定：プロンプト履歴が残らず、後で要件や変更の説明ができない

所有権を明確にする：決定には名前が必要

役職ではなくワークフローのレベルで所有権を定義してください：

• ツール承認：セキュリティ/ITがベンダーと導入モードを承認する。プロダクトとエンジニアは使いやすさ要件を共同で所有する。
• データアクセス：一人のオーナー（多くはセキュリティやデータチーム）がどのデータをどのモデルで許可するかを定義する。
• プロンプト/出力レビュー：変更をマージする人が最終出力の責任を持つ—要件アーティファクトはPM、コード変更はエンジニア、テストカバレッジはQAが所有する。

チームが本当に従う軽量ポリシー

ルールは小さく実行可能に：

• デフォルトでマスキング："プロンプトに顧客PIIを入れない"、簡単な編集チェックリスト
• 監査ログ：重要なアーティファクト（PRD、主要ユーザーストーリー、コードPR）のプロンプト/出力履歴を保存
• 承認済みモデルリスト：許可されたツールの短いリストと各ツールの用途ガイド

Koder.aiのようなプラットフォームを採用するなら、それをSDLCの一部として扱ってください：チャットから何が生成可能か、何をコードレビュー経由で出す必要があるか、スナップショット/ロールバックをどのように使うかを定義します。

インシデント対応とロールバック

AIのミスは他の本番リスクと同様に扱います：

• PRや仕様に"AI-assisted change"タグを作り影響を追跡する。
• ロールバック経路を定義する（コミットを戻す、フラグを無効にする、以前の文言を復元する）。
• 短いポストインシデントレビューを行い、次に備えてどの処理をブロック、レビュー、またはログすべきか検討する。

モダンなプロダクトチームに求められる新しいハイブリッドスキルと役割

AIは既存の作業を速めるだけでなく、PMとエンジニアのどちらにも明確に属さない“間の仕事”を生みます。これらのタスクを早期に認識しておくと混乱と手戻りを避けられます。

明確な所有権が必要な新しいハイブリッドタスク

繰り返し現れる責任は次の通りです：

• プロンプトライブラリ：フィードバック要約、リリースノート作成、ノートをユーザーストーリーに変えるなどのためのキュレーションされたバージョン管理されたプロンプト。個人のショートカットではなく再利用可能な資産として扱う。
• AI支援向けの仕様テンプレート：モデル前提、データ制約、「良い状態」の定義を含む軽量PRD/ユーザーストーリーフォーマット。
• 評価ハーネス：AI出力品質をチェックする簡易的手段—ゴールデン例、チェックリスト、テストセット。これはコード生成だけでなく、要件ドラフト、サポートマクロ、分析ナラティブにも適用される。

これらが皆の仕事になると誰の仕事でもなくなる傾向があります。オーナーを割り当て、更新頻度を定め、どこに置くか（Wiki、リポジトリ、または両方）を決めてください。

よく見られる新しい役割

• AIプロダクトリード：AI利用をプロダクト目標と揃え、成功指標を定義し、スピードとリスクのトレードオフを判断する。
• Developer Experience（DX）：AIツールがエンジニアリングワークフロー（CI/CD、コードレビュー、ドキュメント）に合うようにし、摩擦と不整合を減らす。
• ツールスチュワード（またはAI Opsスチュワード）：アクセス管理、権限、モデル選定、ベンダー契約、内部ガイドラインを管理し、セキュリティ/法務と連携する。

大きな組織では正式な役割、小規模では既存メンバーが兼任する形になります。

スキルアップ：PMとエンジニアが中間で出会う

PMは技術リテラシー（差分を高レベルで読む、APIを理解する、評価がどう機能するかを理解する）から利益を得ます。

エンジニアはプロダクト思考（問題の明確化、ユーザーインパクトや実験設計）から利益を得ます。

定着する実践的トレーニング

PMとエンジニアのペアセッションを行い、プロンプト、仕様、受け入れ基準を共同で作り、AI出力を実例と比較してください。うまくいった点を共有プレイブック（テンプレート、やること/やってはいけないこと、レビュー用チェックリスト）に残すと学習が累積します。

役割混乱を起こさずにAIを導入する実践プレイブック

少しの構造で多くが変わります。目的はあらゆる箇所にAIを入れることではなく、役割を明確に保ちつつ成果が改善するかを学ぶコントロールされたパイロットを回すことです。

ステップバイステップのパイロット計画（1つのフィーチャーチーム）

1. 実態のある1つの機能を選ぶ（単なる文言変更でも四半期をまたぐプラットフォーム改修でもない）。開始/終了点を定義：最初の要件ドラフトから本番リリースまで。

2. パイロット用の役割マップを1ページに書く：問題定義は誰が所有（PM）、技術アプローチは誰（エンジニア）、UX決定は誰（デザイン）、品質ゲートは誰（QA）か。提案できる人と決定できる人を明確に。

3. AIのユースケースを2–3個に絞る。例：

   • PRD/ユーザーストーリーと受け入れ基準のドラフト
   • 受け入れ基準からのテストケース生成
   • ステークホルダー向けの技術的トレードオフ要約

4. 入力を標準化する：共通のプロンプトテンプレートとAI出力に対する定義済みのDone条件（何を検証するか、何を信頼できるか）

5. 2–4スプリント実行し、その後拡大前にレビューする。

もしチームがドラフトを超えて迅速な実装実験に踏み込むなら、制御されたビルド環境（たとえばKoder.aiのプランニングモード＋スナップショット/ロールバック）でパイロットを行うことを検討してください。目的はエンジニアを迂回することではなく、反復を安くしつつレビューゲートを保つことです。

みんなを正直に保つ成功指標

過去の似た機能のベースラインを取り比較してください：

• サイクルタイム：アイデア→出荷
• 手戻り率：再オープンしたチケット、スコープチェンジ、ストーリー当たりの確認ミーティング数
• 欠陥率：QAやリリース後に見つかったバグ
• 明確さスコア：スプリント開始時点でのストーリー準備度をエンジニア/QAが1–5で評価

役割ズレを防ぐ儀式

共有プロンプトリポジトリを維持する（バージョン管理、有効/無効の例付き）。毎週20分のレビューを行い、チームでAI生成アーティファクトをサンプルしてラベリングする：正しい、誤解を招く、文脈不足、労力に見合わない。

最終的な原則：共有アーティファクト、明確な責任、可視化された意思決定。