フレームワーク活用ガイドひとことで言うと#
医療現場のトリアージ（緊急度による振り分け）をプロダクト開発に応用し、押し寄せる機能要望やバグ報告を緊急度×重要度の2軸で瞬時に4カテゴリに仕分けるフレームワーク。完璧な優先順位付けに時間をかけるのではなく、「今すぐ・次・いつか・やらない」を素早く決めることに特化している。
押さえておきたい用語#
- トリアージ（Triage）
- フランス語の「選別」が語源。限られたリソースを最大効果に配分するための迅速な振り分け手法。医療では患者の重症度で治療順を決める。
- 緊急度（Urgency）
- 今すぐ対応しないと被害が拡大するかの評価軸。顧客離脱、売上毀損、セキュリティリスクなど時間経過で悪化する度合い。
- 重要度（Importance）
- 中長期的な事業インパクトの大きさ。売上貢献、ユーザー体験の向上、戦略的ポジショニングへの影響など。
- バックログ債務（Backlog Debt）
- 判断が先送りされたまま溜まり続ける要望やバグのこと。放置するほど「何が入っているか誰も把握していない」状態になる。
プロダクトトリアージの全体像#
こんな悩みに効く#
- 機能要望やバグ報告が毎日増え、何から手をつけるか決められない
- 声の大きい顧客やセールスの要望に振り回されている
- バックログが数百件に膨らみ、誰も全体像を把握していない
- 優先順位付けに時間をかけすぎて、肝心の開発が進まない
基本の使い方#
トリアージの前提は「漏れなく集まっている」こと。
- カスタマーサポート、営業、社内Slack、GitHubのIssueなど、要望が散在していたら1つのボードに統合する
- 各要望には「誰が・いつ・どんな文脈で」要望したかの最低限のメタ情報を付ける
- 重複は統合し、件数（何人が同じことを言っているか）を記録する
週1〜2回のトリアージ会議で、新規の要望を1件あたり最大2分で振り分ける。
- 今すぐやる: 対応しないと24時間以内に顧客が離脱する、または法的・セキュリティリスクがある
- 次にやる: 事業インパクトは大きいが、今すぐでなくても被害は広がらない
- 応急処置: 急ぎだが根本解決は後でよい。ワークアラウンドで時間を稼ぐ
- やらない / いつか: インパクトも緊急性も低い。アイスボックスに入れるか、理由を付けてクローズ
仕分け結果を「判断の理由」とセットでチケットに残す。
- なぜその象限に入れたのかを一行で書く（後から判断を振り返るため）
- 「今すぐやる」はその場で担当者とスプリントを決定する
- 「やらない」と判断した要望にも理由を書き、要望者にフィードバックする
トリアージは一度やって終わりではない。
- 「次にやる」に入れたまま3スプリント以上動いていないものは再評価する
- 「やらない」と判断したが再び要望が増えたものは象限を格上げする
- 月次でトリアージの精度を振り返り、基準をチームでアップデートする
具体例#
BtoB SaaSを提供するスタートアップ。ARR1.2億円、顧客数180社。プロダクトチーム6名に対して、バックログのチケットが420件に膨れ上がっていた。スプリントプランニングのたびに「どれをやるか」で2時間以上議論していた。
トリアージ会議を週1回（火曜30分）導入:
- 420件をまず一括仕分け。今すぐ: 12件、次にやる: 85件、応急処置: 38件、やらない/いつか: 285件
- 285件のうち180件は1年以上前の要望で、すでに状況が変わっていたためクローズ
- 以降、新規要望は火曜のトリアージ会議で即座に仕分け
スプリントプランニングの所要時間は2時間→40分に短縮。「何をやるか」ではなく「どうやるか」に議論の時間を使えるようになり、スプリント完了率が**62%→88%**に改善した。
ECプラットフォームの開発チーム10名。カスタマーサポートから毎日平均4.2件の「至急対応依頼」がSlackで飛んでくる。エンジニアは常に割り込みに追われ、ロードマップの機能開発が**予定の55%**しか完了しない状態が半年続いていた。
トリアージの仕組みを導入:
- CSからの依頼はすべて専用フォーム経由に統一（Slackの「至急」を禁止）
- フォームに「影響を受けているユーザー数」「売上への影響額」を必須記入
- 毎朝10時に15分のトリアージ（PM1名+エンジニアリーダー1名）
仕分け結果: 1日平均4.2件のうち、本当に「今すぐ」だったのは0.8件。残りの3.4件は「応急処置」か「次にやる」に分類できた。
割り込み対応が1日平均4.2件→0.8件に減少。ロードマップ機能の完了率は**55%→82%**に回復し、同時にCSの顧客満足度スコアも改善された（応急処置のワークアラウンドを即座に案内できるようになったため）。
平日夜と週末だけで個人開発のタスク管理アプリを運営している28歳のエンジニア。月額ユーザー1,200人。Feature Requestが67件溜まっていて、どれから手をつけるべきか3か月間悩み続けていた。
1人トリアージを実施（所要時間45分）:
- 今すぐ: 2件（ログインできないバグ、データ消失リスク）
- 次にやる: 8件（有料化に直結する機能、競合との差別化）
- 応急処置: 5件（UIの軽微な不具合、ドキュメントで回避可能）
- やらない: 52件（特定ユーザーの個別要望、実装コストに見合わないもの）
52件には丁寧に理由を書いてクローズし、GitHubのディスカッションで方針を公開。批判を恐れていたが、実際には「判断が明確で信頼できる」という好意的な反応が多かった。
2件のクリティカルバグを翌週中に修正し、次の2か月で「次にやる」の8件に集中。有料プラン導入が実現し、月額課金ユーザー180人を獲得した。
やりがちな失敗パターン#
- 全部「今すぐやる」に入れてしまう — トリアージの意味がなくなる。「今すぐ」の上限を全体の**10〜15%**と決め、超えたら入れ替え制にする
- 「やらない」と言えない — 要望者への配慮から「いつかやる」に溜め込むと、バックログ債務が膨張する。やらない理由を明文化し、フィードバックすることが誠実な対応
- トリアージ会議が長引く — 1件2分のタイムボックスを守る。判断に迷ったら「次にやる」に仮置きし、翌週再評価する
- 判断基準が属人的 — PMの感覚だけで振り分けると、チーム内で不信感が生まれる。「影響ユーザー数」「売上インパクト」など定量基準を決めてドキュメント化する
まとめ#
プロダクトトリアージは、押し寄せる要望やバグを「今すぐ・次・応急処置・やらない」の4カテゴリに素早く振り分ける手法である。完璧な優先順位付けに時間をかけるより、短時間で「やらないこと」を決めるほうがチームの生産性は上がる。週次のトリアージ会議を習慣にし、判断基準をチームで共有・更新し続けることが、バックログ債務を防ぐ最良の方法だ。