生成AI×PMO：「7種のインシデント型」でバグ予測と横展開
みなさん、こんにちは。サービス開発部の大坪です。
本記事では、PMO（Project Management Officer）の立場で生成AIをどう品質改善に使うかについて、試した取り組みを紹介します。
- 生成AI×PMO：「7種のインシデント型」でバグ予測と横展開
- この記事で書くこと・対象読者
- PMOで生成AIに何をさせたいのか
- 生成AIは「確率で次の単語を当てるマシン」
- 成果物をそのまま渡しただけではイマイチだった
- 7種のインシデントに整理してみた
- インシデント統計から「残存バグっぽさ」をざっくり測る
- 7種のインシデントを教えたうえで、バグ候補とアクション候補を出してもらう
- やってみて分かったこと：AIよりも先に「インシデントの言語化」が効いた
- まとめ
この記事で書くこと・対象読者
この記事では、
- 生成AIを「次に来そうな単語を当てる確率マシン」として捉え直し
- 過去のインシデントを7種類に分類して生成AIに教えることで、残存バグ候補や横展開アクションのヒントを出させる
という PMO 視点の使い方を紹介します。
想定している読者は、
- プロジェクトマネージャ / PMO
- チームリーダーとして品質やリスクを俯瞰したいエンジニア
です。
生成AIのモデルやアルゴリズムの詳細ではなく、現場でどう使うかのストーリー寄りの内容になっています。
PMOで生成AIに何をさせたいのか
最近は、「議事録を書いてもらう」「要約してもらう」といった形で、生成AIをPMO業務に使う話をよく聞きます。
- 会議のログからタスクを抜き出してくれる
- チケットの説明から、ざっくりしたステータスをまとめてくれる
こういった 「ドキュメントを整理する仕事」には、生成AIはかなり強い と感じます。
一方で、PMやPMOに求められる役割は、ここ数年でさらに広がっています。
いわゆる「指示を出す人」ではなく、チームを支える サーバントリーダー 的な立ち位置が期待される場面も増えました。
- メンバーやステークホルダーの状況を把握する
- チームの学びや振り返りを設計する
- 進捗・リスク・品質を俯瞰して、先回りの打ち手を考える
すべてを人力でやろうとすると、「見るべきなのに、見切れないところ」が必ず出てきます。
その中でも、PMOとして特にしんどいのが、
- 「この成果物には、まだどんなバグが潜んでいそうか？」
- 「このチームのやり方だと、どこでトラブルが起きやすいか？」
- 「どこにどんな横展開（標準化・教育・仕組み化）を入れるべきか？」
といった、“これから起こりそうな問題” を予測して先回りする部分です。
今回のテーマは、この「予測と先回り」を、どこまで生成AIに手伝ってもらえるか、というチャレンジです。
生成AIは「確率で次の単語を当てるマシン」
まず前提として、生成AI（LLM）はとても賢そうに見えますが、本質的にはシンプルです。
直前までの文脈を見て、
「次に来そうな単語（トークン）」を確率的に予測しているだけ
です。
大量のテキストを学習することで、
- こういう文脈のときは、こんな言い回しが続きやすい
- こういう要件のときは、こういう注意点が一緒に書かれていることが多い
といった「パターン認識」ができるようになっています。
これを品質の文脈で言い換えると、
「過去のプロジェクトでよく起きていたパターン」を学習させておけば、
「今の成果物に、どんな事故が起こりそうか」をそれっぽく推測してくれるかもしれない
という発想が見えてきます。
成果物をそのまま渡しただけではイマイチだった
そこで最初は、設計書やソース、テスト仕様書などをそのまま生成AIに渡し、
「この資料に潜んでいそうな問題を教えてください」
と聞いてみました。
ところが、実際に試してみると、こんな印象でした。
- まったく的外れではないが、「どのプロジェクトにも当てはまりそうな一般論」が多い
- 「テストを充実させましょう」「レビューを行いましょう」といった、正論だけど具体性のないアドバイスが大量に返ってくる
- プロジェクト特有の、“うちの現場でよくやらかす事故パターン” までは、なかなか当ててくれない
つまり、
成果物だけを渡しても、
「この現場でいつも起きているインシデントのパターン」までは伝わらない
ということがわかってきました。
ここから方針を変えて、
まずは こちらから「インシデントの型」を整理して、生成AIに教えてしまおう
というアプローチをとることにしました。
7種のインシデントに整理してみた
そこで、過去のインシデントや振り返りの記録を俯瞰しながら、
「原因の違いが、打ち手の違いにつながる」
という観点で、インシデントを7種類に整理しました。
実務寄りに表現すると、次のようなイメージです。
標準違反（ルール・ガイドラインの未遵守）
- コーディング規約や命名ルールなど、チームで決めた標準に従っていないことで起こるタイプ
前工程からの要件漏れ
- 要件定義には書いてあるのに、自分の工程（設計・実装・テスト）に反映されていないようなタイプ
自己内矛盾（同じ成果物内での整合性崩れ）
- 同じ設計書・同じ機能の中で、前後の説明や条件が食い違ってしまっているタイプ
既存仕様・既存システムの理解不足
- 既存機能の挙動や制約を理解しないまま変更してしまい、想定外の影響や再発を招くタイプ
コミュニケーションロス（伝達漏れ・認識の行き違い）
- 仕様変更や注意事項が十分に伝わっておらず、「聞いてない」「知らなかった」で起こるタイプ
単純ミス（ケアレスミス）
- 誤字・脱字、コピペミス、うっかり漏れなど、作業者の注意不足が主な原因となるタイプ
表現不明瞭（あいまいな書き方・読みにくさ）
- 設計書やテスト仕様書の書き方があいまいで、読む人によって解釈が変わってしまうタイプ
ポイントは、
- 「どのインシデントタイプなのか」によって、取るべき対策や横展開が変わる
- ならば、生成AIにもこの「インシデントの型」を理解させた方が、PMOとして考えるべきアクションが出てきやすい
という発想です。
インシデント統計から「残存バグっぽさ」をざっくり測る
7種のインシデントに分類できるようになると、「どんなインシデントが、どのくらい発生しているか」を集計できるようになります。
この情報を使って、裏側では次のようなことも試しました。
過去のインシデント傾向から、
「まだバグが残っていそうな成果物」を簡単な重回帰分析であたり付けする
というものです。
ここで欲しいのは厳密な予測値ではなく、
- 「この成果物は、他と比べて少し怪しそうだ」
- 「このチームは、日付の扱いまわりでヒヤリハットが多い」
といった、PMOが深掘り対象を決めるためのラフなメーターです。
重回帰分析そのものの手法や精度検証については、また別の機会に整理して書ければと思います。
（例えば、担当者の経験年数や過去のインシデント件数、機能ごとの規模感など、直感的にイメージしやすい数字をいくつか説明変数として使っています。）
7種のインシデントを教えたうえで、バグ候補とアクション候補を出してもらう
重回帰分析で「残存バグリスクが高そうだ」と分かった成果物に対して、
7種のインシデントを前提に、生成AIに次のような手順で働いてもらいました。
ステップ1：インシデントの定義をまとめてインプットする
まず最初に、先ほどの 7種のインシデントの説明と具体例 を、まとめて生成AIに渡します。
「私たちのプロジェクトでは、インシデントを次の7種類に分類しています……」
という形で、タイプごとの説明を書き、
「これは品質管理チームだけが知っている暗黙知です」という前提も合わせて伝えます。
ステップ2：『残存バグリスクが高そうな成果物』に対して、インシデント候補と横展開アクションを聞く
次に、すでにレビューやテストが一通り完了している成果物のうち、残存バグリスクが高めと出たものを対象にします。
その成果物（設計書やコードなど）の一部と、過去のインシデント傾向をセットで生成AIに渡し、次のように問い合わせます。
この成果物の内容と前提条件を読んで、
- 追加で発生しそうなインシデントのタイプ（上記7種のどれか）
- その「起きやすさ」の理由（過去の傾向や書きぶりから見た仮説）
- PMOとして打っておくべき横展開アクション（チェックリスト化・教育・運用ルールなど）
を列挙してください。
イメージとしては、例えばこんなアウトプットです。
インシデントタイプ：標準違反（ルール・ガイドラインの未遵守）
- 理由（仮説）：この担当者は、過去のイテレーションでも「設計標準に従っていない」というインシデントを複数発生させています。一方で、今回の成果物では標準違反に関するレビュー指摘がほとんど出ていません。
- 横展開アクション案：担当者に設計標準をもう一度読み返してもらい、自己チェックリストに沿って対応漏れがないか洗い出してもらいます。レビュー側ではその結果を確認する運用にし、同様のモジュールを担当する他メンバーにも同じ自己チェックを横展開してください。
インシデントタイプ：既存仕様・既存システムの理解不足
- 理由（仮説）：担当者は当該機能を今回初めて担当しており、過去の類似ケースでは「既存仕様の理解不足」によるインシデントが発生していますが、今回のレビューではその観点での指摘が少ない状況です。
- 横展開アクション案：当該機能を熟知したメンバーを追加レビュアとしてアサインし、周辺影響や例外パターンにフォーカスした追加レビューを実施します。同様の「初担当機能」についても、経験者を巻き込んだレビューを行うルールとして横展開してください。
ここで生成AIに期待しているのは、「レビューの自動化」ではなく、
- どのインシデントタイプを深掘りすべきか
- どんなルールや教育を横展開すると効きそうか
といった、PMOが考えるべき「次の一手」のヒントを出してもらうことです。
やってみて分かったこと：AIよりも先に「インシデントの言語化」が効いた
この仕組みを試してみて、個人的に一番効いたと感じているのは、
生成AIそのものの性能向上よりも、
インシデントを7種類に整理して言語化したことそのもの
です。
- 「なんとなくモヤモヤしていた事故のパターン」を、7つのカテゴリに分けて棚卸しした
- それを生成AIに覚えさせることで、「このプロジェクト特有のやらかしパターン」という暗黙知を、AIにも一部共有できた
- 結果として、生成AIから出てくる提案も、「うちの現場っぽい指摘」や「横展開につながる打ち手」に近づいていった
よく「AI導入の前にデータ整備が大事」と言われますが、PMO領域ではそれは、
インシデントの型を決めて、過去の事例をその型で振り返る
という作業そのものだと感じました。
ここをやることで、生成AIは「レビューの自動化ツール」ではなく、PMOが俯瞰するための補助線として機能し始めます。
まとめ
最後に、本記事のポイントを簡単にまとめます。
- 生成AIは 「次に来そうな単語を当てる確率マシン」 ですが、過去のインシデントの「型」を教えることで、PMO視点のヒントを返してくれるようになります。
- インシデントを 7種類に分類して言語化 すると、統計的には「残存バグリスクの高そうな成果物」をあたり付けでき、生成AIには「深掘りすべき観点」や「横展開アクション」の案出しを手伝ってもらえるようになりました。
- 一番効いたのは、AIを入れる前に「インシデントの言語化」と「PMOが見たい観点の明確化」をやったことでした。
今後も、「生成AI×PMO」というテーマで、インシデント分類や指標の工夫、プロンプト設計の具体例、チームや組織への横展開の進め方などを、少しずつ紹介していければと思います。
