はじめに 今年2月にDASAプロダクトマネジメント研修を受講しました。 これまでプロジェクトマネジメントは学んできましたが、プロダクトマネジメントを体系的に学ぶのは初めてでした。 本記事では、研修で得た学びと、それを踏まえて過去案件をプロダクトマネジメントの視点で振り返った内容をまとめます。 プロダクトマネジメント研修で学んだこと DASAプロダクトマネジメント認定研修の概要 DASAプロダクトマネジメント認定研修は、DevOps環境を前提に、プロダクト中心の組織への変革を実践的に学ぶ体系的なプログラムです。 全体は「プロダクトを見極める」から始まり、「ライフサイクル管理」「

テスト管理では、テストケースの消化率や不具合件数を確認していても、「本当に品質は十分なのか」「リリースして問題ないのか」を判断しきれない場面があります。 消化率が高くても重要機能の確認が残っている場合や、不具合件数が少なくてもテスト観点が不足している場合があるためです。 そこで重要になるのが、テスト管理におけるメトリクスです。 メトリクスを活用すると、テストの進捗、品質状態、欠陥傾向、カバレッジ、修正状況などを数値で可視化できます。 これにより、感覚的な報告ではなく、根拠に基づいて品質状況やリスクを説明しやすくなります。 そこで今回はテスト管理におけるメトリクスの基本的な意味から、代表的な指標の種類、具体的な計算方法、管理・活用の流れ、運用時の注意点までを解説します。 品質会議やリリース判定で使える指標を整理したい場合は、ぜひ参考にしてください。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テスト管理ツール11製品の完全比較はこちら▼ 【2026年最新】テスト管理ツール11製品の徹底比較！【脱Excel】 メトリクスとは、品質や進捗を数値で可視化するための指標 テスト管理におけるメトリクスとは、ソフトウェアテストの状況を数値で把握するための指標です。 対象になるのは、テストの進捗、品質、欠陥状況、カバレッジ、プロセス効率などです。 たとえば、テストケース消化率、不具合件数、バグ密度、テスト密度、テストカバレッジ、欠陥修正リードタイムなどが代表例です。 重要なのは、メトリクスの目的が「数値を集めること」ではなく、「判断や改善に使うこと」にある点です。 テストケースを何件実行したか、不具合が何件出たかを記録するだけでは、品質管理としては不十分です。 その数値から、予定どおり進んでいるのか、特定機能にリスクが集中していないか、リリース前に追加確認が必要かを判断して、次のアクションにつなげる必要があります。 これらを組み合わせることで、感覚ではなくデータに基づいてテスト状況を説明しやすくなります。 テストメトリクスが必要とされる理由 テストメトリクスが必要とされる理由は、テスト状況を感覚ではなく客観的に把握するためです。 たとえば「テストは順調です」という報告だけでは、どの機能が完了していて、どこに遅れや品質リスクがあるのかが伝わりません。 一方で、テストケース消化率、未実行件数、Fail件数、Blocked件数、重大不具合の残数などを示せば、現状と課題を具体的に共有できます。 また、計画値と実績値を比較することで、進捗遅延や品質リスクを早期に発見できます。 テスト実行数が計画より少ない、特定機能で不具合が集中している、重大度の高い欠陥の修正が長期化しているといった兆候は、リリース直前ではなく途中段階で把握することが重要です。 プロジェクトマネージャー、プロダクトオーナー、顧客などのステークホルダーに対しても、メトリクスは品質状況を定量的に報告する材料になります。 メトリクスとKPIの違い メトリクスとKPIは似た言葉ですが、役割が異なります。メトリクスは、状態を測るための数値指標です。 不具合件数、テストケース消化率、テスト密度、バグ密度、修正リードタイムなど、テスト活動や品質状態を把握するための数値は広くメトリクスに含まれます。 一方、KPIは目的達成度を判断するために特に重要な指標です。 たとえば、不具合件数そのものはメトリクスですが、「リリース判定時点で重大不具合ゼロ」「高リスク機能のテスト完了率100％」「欠陥除去効率が基準値以上」といった形で、プロジェクトの目標や判定基準に直結する場合はKPIとして扱えます。 注意したいのは、測れるものを何でもKPIにしないことです。 指標が増えすぎると、入力や集計に時間がかかる一方で、何を見て判断すべきかが曖昧になります。 テスト管理では、プロジェクトの目的に照らして、進捗、品質、リスク、リリース判断に関係する指標を選ぶことが重要です。 テスト管理で見るべき主要メトリクスの種類 進捗管理に関するメトリクス 進捗管理に関するメトリクスは、予定どおりテストが進んでいるか、どこで作業が止まっているかを把握するために使います。 代表的な指標には、テストケース作成数、テストケース実行数、テストケース消化率、Pass／Fail／Blocked／未実行の割合、計画工数に対する実績工数、テスト環境の利用可能時間などがあります。 テストケース消化率だけを見ると、進捗が良好に見える場合があります。 しかし、FailやBlockedが多い場合、実際には品質確認が完了していない可能性があります。 また、未実行のテストが高リスク機能に集中している場合、消化率が高くてもリリース判断には注意が必要です。 進捗管理では、単なる件数ではなく、遅延箇所やブロッカーを特定できる形で見ることが大切です。 品質評価に関するメトリクス 品質評価に関するメトリクスは、成果物やテスト対象の品質状態を把握するために使います。 代表例は、不具合件数、バグ密度、テスト密度、レビュー指摘密度、欠陥除去効率、重大度別・優先度別の不具合件数などです。 レビュー指摘件数はレビュー指摘密度、テストケース数はテスト密度、バグ件数はバグ密度の算出に使われます。 品質評価では、不具合件数が少ないことをそのまま「品質が高い」と判断しないことが重要です。 テストが十分に実施されていないために不具合が見つかっていない可能性もあります。 バグ密度、テスト密度、レビュー指摘密度、重大度別の不具合分布などを組み合わせることで、品質を立体的に判断しやすくなります。 カバレッジに関するメトリクス カバレッジに関するメトリクスは、テストがどの範囲を確認できているかを把握するための指標です。 代表的なものには、要件カバレッジ、テスト条件カバレッジ、テストケースカバレッジ、コードカバレッジ、リスクカバレッジがあります。 要件カバレッジは、すべての要件のうち、どの要件がテストで確認済みかを見る指標です。 コードカバレッジは、ソースコードのうちテストで実行された範囲を示します。リスクカバレッジは、重要度や影響度が高いリスクに対して、どこまでテストが実施されているかを確認するために使います。 カバレッジは網羅性を確認するうえで有効ですが、カバレッジが高いことだけで品質が保証されるわけではありません。重要機能や高リスク領域が適切な観点で確認されているかまで見る必要があります。 不具合分析に関するメトリクス 不具合分析に関するメトリクスは、欠陥の発生傾向や修正状況を把握し、品質リスクの原因を探るために使います。 代表的な指標には、修正済み欠陥数／発見済み欠陥数、欠陥修正リードタイム、再オープン率、デグレード発生率、機能別・画面別・モジュール別の不具合分布、重大度別・原因別の不具合傾向などがあります。 たとえば、特定機能に不具合が集中している場合、設計が複雑なのか、仕様理解が不十分なのか、レビュー観点が不足していたのか、テスト設計が浅かったのかを確認する必要があります。 重大度の高い不具合が特定モジュールに偏っている場合は、追加テストやコードレビューの強化が必要になることもあります。 たとえばメトリクスに加えて、What、Where、When、Who、How、Whyの5W1Hで不具合を分析すると、原因を深掘りしやすくなるでしょう。 数値だけで終わらせず、原因と対策に結びつけることが不具合分析のポイントです。 プロセス改善に関するメトリクス プロセス改善に関するメトリクスは、テスト活動そのものの効率や改善余地を把握するために使います。 代表的な指標には、テスト実行効率、欠陥修正時間、再テスト回数、レビューで検出できた欠陥の割合、自動化率、手戻り率などがあります。 たとえばテスト実行効率が低い場合、テストケースの粒度が細かすぎる、環境準備に時間がかかっている、手順が複雑で属人化している、といった原因が考えられます。 欠陥修正時間が長い場合は、仕様確認に時間がかかっている、担当者が不足している、再現手順が不十分であるなどの課題が隠れている可能性があります。 プロセス改善メトリクスは、現場の負担を増やすためではなく、ボトルネックを見つけて作業しやすい状態を作るために活用します。 テストメトリクスの具体例と計算方法 テストケース消化率 テストケース消化率は、テスト進捗を把握するための基本的なメトリクスです。 計算式は「実行済みテストケース数 ÷ 全テストケース数 × 100」です。たとえば、全1,000件のテストケースのうち700件を実行済みであれば、消化率は70％です。 ただし、消化率が高いからといって品質が十分とは限りません。 重要機能や高リスク領域のテストが未実行のまま残っている場合、全体の消化率が80％や90％であっても、リリース判断には慎重さが必要です。 また、実行済みの中にFailやBlockedが多い場合、確認が完了しているとは言えません。 そのため、テストケース消化率は、Pass率、Fail率、Blocked率、未実行率と組み合わせて見る必要があります。 さらに、機能別、担当者別、優先度別に分解すると、どの領域で進捗が止まっているのかを把握しやすくなります。 テスト密度 テスト密度は、開発規模に対して十分なテストケースが用意されているかを確認するための指標です。 計算式は「テストケース数 ÷ 規模」です。規模には、LOC、FP、画面数、機能数などが使われます。 また同じプロジェクト内でも、重要度や影響度によって機能ごとにテスト密度を変える場合があるとされています。 注意したいのは、テストケース数が多いほど品質が高いとは限らない点です。 重複したテストケースや観点の浅いテストケースが多くても、品質リスクを十分に下げられない場合があります。 重要機能、高頻度で使われる機能、障害時の影響が大きい機能では、リスクに応じてテスト密度を高める判断が必要です。 バグ密度 バグ密度は、対象プログラムや機能の品質を把握するための指標です。 計算式は「バグ件数 ÷ 規模」です。 規模には、LOC、FP、機能数、画面数などが使われます。単純な不具合件数だけでは、規模の大きな機能ほど不具合が多く見えやすいため、密度で見ることで比較しやすくなります。 また、規模の異なるソフトウェアやチーム間でも、傾向比較がしやすくなるとされています。 ただし、バグ密度が低い場合でも安心はできません。 テスト密度が低ければ、そもそも十分にテストされておらず、バグが見つかっていないだけの可能性があります。 そのため、バグ密度はテスト密度、レビュー指摘密度、重大度別不具合件数などと組み合わせて判断する必要があります。 欠陥修正リードタイム 欠陥修正リードタイムは、欠陥が報告されてから修正完了までにかかった時間を示すメトリクスです。 計算式は「欠陥報告日時から修正完了日時までの経過時間」です。修正対応の遅れや、開発・検証プロセス上のボトルネックを把握するために使います。 この指標は単純な平均値だけでなく、優先度や重大度別に見るとリリース判断に活用しやすくなります。 たとえば、軽微な不具合の修正に時間がかかっていてもリリース影響は限定的かもしれません。 一方で、重大不具合やセキュリティ関連の欠陥の修正リードタイムが長期化している場合は、リリース可否に大きく関わります。 長期化している不具合については、仕様が不明確なのか、設計に問題があるのか、担当者が不足しているのか、再現環境が整っていないのかを確認する必要があります。 欠陥修正リードタイムは、開発チームを責めるためではなく、修正を妨げている要因を明らかにするための指標です。 欠陥除去効率 欠陥除去効率は、テスト工程でどれだけ欠陥を検出できたかを見る指標です。 計算式は「テスト工程で検出した欠陥数 ÷ 全欠陥数 × 100」です。全欠陥数には、テスト中に見つかった欠陥に加えて、リリース後に発見された欠陥も含めて考えることがあります。 この指標が低い場合、テスト工程で十分に欠陥を検出できていなかった可能性があります。 リリース後不具合が多い場合は、テスト観点の不足、レビュー工程の弱さ、リスク分析の不足、実運用に近いシナリオの不足などを見直す必要があります。 欠陥除去効率は、単体テスト、結合テスト、システムテスト、受入テストなど工程別に見ると改善点を特定しやすくなります。 たとえば、システムテストで本来見つけるべき欠陥がリリース後に多く発生している場合、テスト設計や環境条件、業務シナリオの網羅性を見直すきっかけになります。 テストメトリクスを管理・活用する流れ 目的を明確にする テストメトリクスを管理する最初のステップは、何のために測定するのかを明確にすることです。 目的の例としては、進捗遅延の早期発見、品質リスクの可視化、リリース判断、不具合傾向分析、プロセス改善などがあります。 目的が曖昧なまま指標を増やすと、集計作業だけが増え、実際の判断や改善に使われない状態になりがちです。 たとえば、テストケース消化率、不具合件数、修正リードタイム、自動化率などをすべて集計していても、会議で「結局どこにリスクがあるのか」が説明できなければ、メトリクスとして十分に機能していません。 まずは、品質会議やリリース判定で使う指標に絞ることが現実的です。 測定対象と収集ルールを定義する 目的を決めたら、次に測定対象と収集ルールを定義します。何を測るのか、誰が入力するのか、いつ更新するのか、どのタイミングで集計するのかを決めておく必要があります。 特に重要なのは、不具合1件のカウント基準です。同じ原因の不具合を1件とするのか、画面ごとに別件とするのかが曖昧だと、チームや担当者によって数値の意味が変わります。 また、重大度、優先度、原因分類、検出工程、発生機能、修正担当、再オープン有無などの入力ルールも揃える必要があります。 ルールが整っていないメトリクスは、あとから比較や分析に使いにくくなります。 最初から完璧を目指す必要はありませんが、最低限の定義をチームで共有することが重要です。 PDCAサイクルで運用する テストメトリクスは、一度集計して終わりではなく、PDCAサイクルで運用することが重要です。 Planでは、目標値、基準値、収集項目、集計頻度を決めます。 Doでは、テストを実行しながらデータを収集します。 Checkでは、計画値と実績値を比較し、異常値や傾向を確認します。 Actionでは、追加テスト、レビュー強化、担当調整、納期調整などの対策を行います。 たとえば、特定機能のバグ密度が高ければ追加レビューや重点テストを実施し、Blockedが多ければ環境や仕様確認の優先度を上げます。 メトリクスは、過去を振り返るためだけでなく、現在のプロジェクトで次に何をするかを決めるために使うことが大切です。 ダッシュボードやテスト管理ツールで可視化する テストメトリクスは、Excelで管理することもできますが、プロジェクト規模が大きくなるほど、Jira、TestRail、Azure DevOps、各種テスト管理ツールなどで一元管理するメリットが大きくなります。 テストケース、不具合、担当者、ステータス、期限、優先度、機能、リリースバージョンなどを紐づけることで、集計や分析がしやすくなります。 ダッシュボードでは、進捗率、未対応不具合数、重大不具合の残数、機能別不具合分布、Blocked件数、修正待ち件数、再テスト待ち件数などを見える化します。 会議のたびに手作業で集計するのではなく、できるだけ自動で最新状況を確認できる状態にしておくことが理想です。 メトリクス運用は、現場の入力負荷が高すぎると定着しません。 管理しやすい仕組みを作ることも、テスト管理の重要な役割です。 品質会議・リリース判定に活用する テストメトリクスは、品質会議やリリース判定で特に効果を発揮します。 見るべき観点は、予定どおりテストが進んでいるか、品質リスクはどこにあるか、リリースしてよい状態か、残課題に対してどのような対応方針を持っているかです。 確認すべき材料には、重大不具合の残数、高リスク機能のテスト完了状況、修正待ち・再テスト待ちの件数、リグレッションテストの結果、未解決のBlocked件数、残存リスクと対応方針などがあります。 単に「不具合は何件です」と報告するのではなく、「この領域にリスクが残っているため、追加テストを実施する」「重大不具合は解消済みだが、再テスト待ちが残っている」といった判断につなげます。 メトリクスは報告資料の飾りではなく、意思決定とアクションの材料です。数値を使うことで、感覚的な品質報告から、根拠に基づく品質判断へ移行しやすくなります。 テストメトリクスを使う際の注意点 メトリクスは単独で判断しない テストメトリクスは便利ですが、単独で品質を判断するのは危険です。 テストケース消化率が高くても、重要機能のテストが残っていれば安心できません。 不具合件数が少なくても、テスト観点が不足しているだけかもしれません。 バグ密度が低い場合も、本当に品質が高い場合と、十分にテストされていない場合の両方があります。 レビュー指摘密度も同じです。指摘が少ないからといって品質が高いとは限らず、レビュー工数やレビュー観点が不足していた可能性もあります。 品質を判断する際は、進捗、カバレッジ、不具合傾向、レビュー結果、修正状況など、複数のメトリクスを組み合わせて見ることが重要です。 数値の背景を確認する 異常値が出た場合は、数値だけで原因を決めつけないことが重要です。 不具合件数が多い場合でも、単純に実装品質が悪いとは限りません。 難易度の高い機能を担当している、仕様変更が多い、テスト観点が深くなった、過去よりも早い段階で欠陥を検出できている、といった背景がある場合もあります。 逆に不具合件数が少ない場合でも、テスト環境が使えず十分に実行できていない、確認観点が不足している、担当者が遠慮して不具合登録していない、といった問題が隠れている可能性があります。 また、データ分析後もコミュニケーションや現物確認が大切だとされています。 数値は出発点であり、背景確認まで行って初めて改善につながります。 報告相手に合わせて見せ方を変える テストメトリクスは、報告相手によって見せ方を変える必要があります。 開発チーム向けであれば、機能別不具合、原因分類、修正リードタイム、再オープン率など、具体的な改善につながる情報が有効です。 PM向けであれば、進捗率、遅延リスク、残課題、リリース影響を中心に示すと判断しやすくなります。 経営層や顧客向けの場合は、細かい件数よりも、重大リスク、リリース可否、ビジネス影響、残存リスクへの対応方針が重要になります。 同じメトリクスでも、詳細な分析表をそのまま見せるのではなく、相手が意思決定に使える形に整理することが大切です。 メトリクスを増やしすぎない メトリクスは多ければよいわけではありません。 指標が多すぎると、入力、集計、確認の負荷が増えます。 見る側も、どの数値が重要なのか判断しにくくなり、結果として会議で活用されないメトリクスが増えてしまいます。 最初から多くの指標を管理するのではなく、進捗、品質、不具合、カバレッジ、リリース判断に直結する指標に絞ることが現実的です。 たとえば、テストケース消化率、Pass／Fail／Blocked率、重大不具合の残数、バグ密度、テスト密度、要件カバレッジ、欠陥修正リードタイムなどから始めると運用しやすくなります。 個人評価や犯人探しに使わない テストメトリクスは、個人評価や犯人探しに使うものではありません。 担当者別の不具合件数や生産性をそのまま評価に使うと、現場の協力が得られにくくなります。 不具合を登録しづらくなったり、難しい機能を担当する人が不利になったり、数値をよく見せるための行動が増えたりする恐れがあります。 メトリクスの目的は、「誰が悪いか」を探すことではなく、「どこに改善余地があるか」を見つけることです。 特定機能で不具合が多い場合は、担当者を責めるのではなく、仕様の複雑さ、レビュー体制、テスト観点、スケジュール、環境などを確認する必要があります。 メトリクスは、チーム全体で品質を改善するための共通言語として扱うことが重要です。 まとめ テスト管理におけるメトリクスは、テストの進捗や品質を数値で可視化し、判断や改善につなげるための指標です。 代表的なものには、テストケース消化率、テスト密度、バグ密度、欠陥修正リードタイム、欠陥除去効率、要件カバレッジなどがあります。 ただし、メトリクスは単独で判断するものではありません。 たとえば、テストケース消化率が高くても高リスク領域のテストが残っていれば安心はできず、バグ密度が低くてもテスト不足によって不具合が見つかっていない可能性があります。 進捗、品質、不具合傾向、カバレッジ、修正状況などを組み合わせて見ることが重要です。 また、メトリクスは数値を集めること自体が目的ではありません。 品質会議での報告、リリース判定、追加テストの判断、レビュー強化、プロセス改善など、具体的なアクションにつなげてこそ意味があります。 まずは、進捗管理、品質評価、不具合分析、カバレッジ、リリース判断に直結する指標から選定し、収集ルールを明確にしたうえで運用を始めるとよいでしょう。 メトリクスをチーム共通の判断材料として活用できれば、属人的な品質判断を減らし、根拠に基づいたテスト管理を実現しやすくなります。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

― 作業は減るが、判断力は求められ、責任はより重くなる ― 目次 はじめに 生成AIによって、PMの「作業」は確かに減る むしろ、判断は難しくなる 負荷は「作業」から「認知」と「判断」に移る 生成AI時代に、PMが磨くべきもの 1. 論点を設定する力 2. 優先順位を付ける力 3. 出力を疑う力 4. 判断を引き受ける力 おわりに はじめに こんにちは。Insight EdgeでPM業務をしている小林です。 今回は、「生成AIの活用によってPM業務は楽になったのか」というテーマで整理してみます。 ※本記事は著者の個人的な経験と見解に基づくものであり、Insight Edgeとしての公式な見解ではありません。 生成AIの活用は、非常に速いスピードで広がっています。 その影響は、プロジェクトマネジメントの現場にも確実に及び始めています。 要件整理、議事録作成、資料のたたき台作成、リスクの洗い出し。 これまでPMが時間をかけて行っていた作業の一部は、生成AIによって効率化できるようになりました。 この変化だけを見ると、「PMの仕事は楽になる」と考えたくなります。 実際、作業単位で見ればその認識は間違っていません。 ただ、プロジェクト全体を前に進めるという観点で見ると、話はそれほど単純ではありません。 本記事では、生成AIによって何が軽くなり、逆に何が重くなるのかを整理しながら、 PMの仕事は減らず、むしろ判断と責任が重くなっていく という構造について考えます。 生成AIによって、PMの「作業」は確かに減る まず前提として、生成AIがPM業務の一部を効率化すること自体は間違いありません。 例えば、以下のような領域ではすでに有効に機能しています。 要件整理のたたき台作成 会議アジェンダや議事録の作成 想定リスクや論点の洗い出し 顧客説明資料や進捗報告資料の初稿作成 これらは、既存情報をもとに論点を整理し、一定の形式でアウトプットする仕事です。 生成AIは、この種の「整理する仕事」を比較的得意としています。 そのため、PMが手を動かしていた作業時間は、今後も一定程度削減されていくはずです。 一方で、ここで押さえておきたいのは、 作業が減ることと、仕事が減ることは同じではない という点です。 PMの仕事は、単に情報を整理することではありません。 実際には、以下のような役割が含まれています。 何を論点として扱うかを決める どの情報を採用し、どの情報を捨てるかを決める スコープ・納期・品質の優先順位を決める 関係者の期待を調整し、合意形成する 最終的な判断を引き受ける 生成AIは選択肢を提示することはできますが、 どの選択肢を採るべきかを、責任を持って決めることはできません。 つまり、生成AIが減らすのはあくまで前処理です。 PMの中心的な仕事である「決めること」は、引き続き人が担う必要があります。 むしろ、判断は難しくなる 生成AIの導入によって、判断の難易度が下がるわけではありません。 むしろ、難しくなる場面も増えているように感じます。 従来、PMは情報不足の中で判断することが多くありました。 一方で、生成AIを使うと、短時間で大量の論点や選択肢を得ることができます。 これは一見望ましい変化です。 ただ、別の見方をすれば、 判断すべき候補が増える ということでもあります。 結果として、PMは次のような難しさに直面します。 選択肢が多すぎる 論点が広がりすぎる 何を優先すべきかが見えにくくなる さらに厄介なのは、「正しそうな間違い」が増えることです。 生成AIの出力は、多くの場合きれいに整理されており、一見すると妥当に見えます。 しかし実務で問題になるのは、 一見正しそうだが、この案件では使えない という出力です。 例えば、要件定義の粒度についてAIに相談すると、「品質を担保するために詳細な粒度で統一すべき」という一般的なベストプラクティスが返ってきます。論理としては正しいですが、実際のプロジェクトでは、納期重視の顧客要望があり、粗い粒度の要件定義で進めるべき案件かもしれません。PMはこの文脈の違いを見極めなければならないのです。 一般論としては正しい 論理としては整っている しかし顧客や現場の文脈には合っていない このような出力が増えることで、PMは従来以上に、出力を評価し、取捨選択しなければならなくなります。 負荷は「作業」から「認知」と「判断」に移る こうした変化を整理すると、PMの負荷はなくなるのではなく、別の場所へ移っていると考えられます。 項目 従来 生成AI導入後 作業負荷 高い 低い 判断負荷 高い さらに高い 認知負荷 中程度 非常に高い この表が示しているのは、生成AIによってPMの負荷が単純に減るわけではない、ということです。 手を動かす負荷は確かに減ります。 一方で、情報を読み解き、見極め、優先順位を付け、判断するための負荷はむしろ増えていきます。 つまり、PMの仕事は軽くなるというより、 より認知的で、より判断依存の仕事へ移っていく と整理できます。 生成AIは提案を行いますが、責任は負いません。 出力の正否に関わらず、その結果を引き受けるのはPMです。 例えば、 AIが整理した要件を採用した AIが提示した論点で顧客説明をした AIが出したリスク一覧を前提に計画した その結果として認識齟齬や判断ミスが起きたとしても、 「AIがそう言ったから」は責任の所在にはなりません。 むしろ、生成AIを使って効率化できるようになったからこそ、 最終的には それでも、なぜその判断をしたのか が、これまで以上に問われるようになります。 作業をAIに委ねられるようになった分だけ、 人間が担うべき判断と責任は、より明確になり、相対的に重くなっていく とも言えます。 生成AI時代に、PMが磨くべきもの では、この環境でPMに求められるものは何でしょうか。 生成AIを使いこなすこと自体も重要です。 ただ、それ以上に重要なのは、次のような力だと考えています。 1. 論点を設定する力 生成AIは、与えられた問いには答えられます。 しかし、何を問うべきかまでは決めてくれません。 どこが本当の争点なのか。 何を明らかにすればプロジェクトが前に進むのか。 この論点設定は、引き続きPMに求められる役割です。 2. 優先順位を付ける力 生成AIは選択肢を増やします。 しかし、限られた時間と予算の中で何を優先するかは、人が決めなければなりません。 選択肢が増えるほど、優先順位付けの重要性はむしろ高まります。 3. 出力を疑う力 便利であるがゆえに、AIの出力はつい信用したくなります。 しかし実務では、鵜呑みにせず、前提を確認し、文脈に照らして疑う姿勢が欠かせません。 特に「一見正しそうな間違い」を見抜く力は、これまで以上に重要になります。 4. 判断を引き受ける力 最終的には、ここに尽きます。 判断し、その結果を引き受けること。 これは作業ではなく、PMという役割そのものに近いものです。 生成AIが広がるほど、この役割の重要性はむしろ際立っていくように思います。 おわりに 生成AIによって、PMが担ってきた作業の一部は確実に効率化されます。 その意味で、手を動かす負荷は今後も減っていくはずです。 ただし、PMの仕事そのものが軽くなるわけではありません。 むしろ、生成AIによって情報整理や初稿作成が容易になるほど、 PMには「何を信じるか」「何を捨てるか」「なぜそう判断するか」が、より直接的に問われるようになります。 プロジェクトを前に進めるという意味では、 仕事は減らず、判断と責任はむしろ重くなる。 生成AIの時代に起きているのは、仕事がなくなることではなく、 負荷のかかる場所が移っている ということなのかもしれません。