課題の優先順位をAIで自動判定 — Pain Level活用ガイド

「全部重要」問題

「このバグ、優先度高いです」「この機能要望、重要なユーザーからです」「これ、今すぐ対応してほしいです」

報告される課題やバグが全て「重要」と言われる。限られたリソースで、何から手をつけるべきか分からない——この状態に陥っていませんか？

この記事では、AIによる深刻度スコアリング（Pain Level）を活用した優先順位付けの方法を解説します。

優先順位付けが難しい3つの理由

理由1: 報告者のバイアス

課題を報告する人は、自分の課題が最優先だと思っています。

営業からは「顧客が困っている」、サポートからは「問い合わせが殺到している」、経営からは「競合に負けている」——それぞれの視点から「重要」と主張されます。

全てを鵜呑みにすると、優先順位は付けられません。

理由2: 深刻度の基準が属人的

「これは深刻」「これは軽微」という判断が、人によって異なります。

あるエンジニアは「本番で動いているから大丈夫」と判断し、別のエンジニアは「潜在的なセキュリティリスクだ」と判断する。基準が揃っていないと、優先順位が安定しません。

理由3: 数が増えると全体俯瞰が困難

課題が10件なら、人間が全体を把握できます。

しかし、100件、500件と増えると、全体像が見えなくなります。結果として、目の前の課題から順に対応する「モグラ叩き」状態になります。

Pain Level: AIによる深刻度スコアリング

Pain Levelは、課題の深刻度を1〜5のスコアで自動判定する仕組みです。

スコアの定義

AIがどう判定するか

AIは、課題のテキストから以下の要素を分析して深刻度を判定します。

• キーワード: 「セキュリティ」「障害」「データ損失」などの深刻度を示す言葉
• 影響範囲: 「全ユーザー」「特定の操作」「一部環境」
• 緊急性: 「今すぐ」「可能なら」「いつか」
• 感情: 「困っている」「イライラする」「あると便利」

例1: 「決済処理中にエラーが発生し、注文が完了しない」
→ Pain Level: 5（本番障害、収益損失）

例2: 「ダッシュボードの読み込みが5秒以上かかることがある」
→ Pain Level: 3（UXを損なう問題）

例3: 「ボタンの角をもう少し丸くしてほしい」
→ Pain Level: 1（コスメティックな問題）

Pain Levelの活用方法

活用1: トリアージの自動化

課題が登録された時点でPain Levelが判定されるため、トリアージの初期判断が自動化されます。

Pain Level 5 → 即座に対応チームに通知
Pain Level 4 → 今週のスプリントに組み込み
Pain Level 3 → バックログに追加、次回検討
Pain Level 1-2 → nice-to-haveリストに

活用2: GitHub Issueのpriorityラベル自動付与

Pain LevelをGitHub Issueと連携すると、priorityラベルが自動で付与されます。

Issue作成と同時にトリアージが完了するため、後から優先度を付け直す手間がなくなります。

活用3: スプリント計画での活用

スプリント計画では、Pain Levelでフィルタリングすることで、対応すべき課題を効率的に選別できます。

今スプリントで対応:
- Pain Level 5 の課題（全て）
- Pain Level 4 の課題のうち、工数が小さいもの

次スプリント以降:
- Pain Level 4 の残り
- Pain Level 3 のうち、ユーザー影響が大きいもの

活用4: 優先順位の根拠として

「なぜこの課題を後回しにしたのか」と聞かれたとき、Pain Levelを根拠として示せます。

「この課題はPain Level 2と判定されています。
現在、Pain Level 4以上の課題が5件あるため、
そちらを優先しています」

属人的な判断ではなく、客観的な基準に基づいていることを示せます。

Pain Levelの限界と注意点

注意1: AIの判定は「入力の自動化」

Pain Levelは、人間の判断を完全に代替するものではありません。

あくまで「最初の判定を自動化する」ものであり、最終的な優先順位は人間が決めるべきです。特に、ビジネス上の戦略的判断はAIには分かりません。

注意2: 文脈の欠落

テキストだけでは、背景情報が分からないことがあります。

「ログイン画面が表示されない」
→ 一部ユーザーの環境依存問題？全ユーザーで発生？

追加情報があれば、Pain Levelは変わります。AIの初期判定は参考値として扱いましょう。

注意3: 戦略的優先度との違い

Pain Levelは「深刻度」であり、「戦略的優先度」とは異なります。

例: 新規機能Aの開発 vs バグBの修正

バグB: Pain Level 3（不便だが回避可能）
新規機能A: Pain Level なし（課題ではない）

しかし、戦略上は新規機能Aを優先すべき場合もある

Pain Levelは「課題のトリアージ」には有効ですが、「何を作るか」の判断には別の基準が必要です。

優先順位付けフレームワークとの組み合わせ

Pain LevelをICE、RICEなどのフレームワークと組み合わせると、より精度の高い優先順位付けが可能です。

RICE + Pain Level

RICE スコア:

• Reach（影響範囲）
• Impact（影響度）
• Confidence（確信度）
• Effort（工数）

Pain LevelをImpactの代替として使えます:

調整後RICEスコア = Reach × Pain Level × Confidence / Effort

ICE + Pain Level

ICE スコア:

• Impact（影響度）
• Confidence（確信度）
• Ease（容易さ）

同様に、Pain LevelをImpactとして活用:

調整後ICEスコア = Pain Level × Confidence × Ease

まとめ

AIによるPain Level活用のポイント:

1. 深刻度の自動判定 — 報告者のバイアスを排除
2. トリアージの自動化 — 初期判断を効率化
3. GitHub Issue連携 — priorityラベル自動付与
4. 客観的な根拠 — 優先順位の説明に使える
5. 最終判断は人間 — AIは入力の自動化、判断は人間

「全部重要」問題を解決するには、客観的な基準で深刻度を判定する仕組みが必要です。Pain Levelはその第一歩になります。

あわせて読みたい

課題管理・優先順位付けをさらに効率化したい方は、以下の記事もご覧ください。

• アイデアからGitHub Issueへ — 思考と実行の壁をなくす方法 — Pain Level判定後のIssue化ワークフロー
• アイデアの分類・タグ付けをAIで自動化する方法 — タイプ判定・タグ生成の自動化

---

「課題の深刻度を自動判定したい」なら、IdeaSpool のPain Level機能を試してみてください。

IdeaSpoolは、課題を記録した瞬間にAIが深刻度（Pain Level）を自動判定します。GitHub連携を有効にすれば、Pain Levelに基づいたpriorityラベルが自動で付与されます。「全部重要」問題から解放され、限られたリソースを最も重要な課題に集中できます。