フレームワーク活用ガイドひとことで言うと#
発生した問題やインシデントを「R（直近性）: いつ起きたか」「F（頻度）: どれくらい起きているか」「I（影響度）: どれだけ深刻か」の3軸でスコアリングし、対応すべき優先順位を客観的に決める分析手法。
押さえておきたい用語#
- Recency（リーセンシー）
- 問題が最後に発生した時期の新しさを示す軸のこと。最近発生した問題ほどスコアが高く、対応の緊急性が高い。
- Frequency（フリクエンシー）
- 問題が一定期間内に発生した回数を示す軸を指す。頻繁に発生する問題ほどスコアが高い。
- Impact（インパクト）
- 問題が発生したときの影響の深刻度を示す軸のこと。サービス停止レベルから見栄えの問題まで段階がある。
- RFIスコア
- R×F×Iの積で算出される総合優先度を表す数値である。最大125点（各5点満点の場合）で、スコアが高い問題から対応する。
RFI分析の全体像#
こんな悩みに効く#
- バグや障害が溜まっていて、どれから対応すればいいかわからない
- 声の大きい人の要望から対応してしまい、本当に重要な問題が後回しになる
- インシデントの重要度を「高・中・低」と感覚で決めているが、基準が曖昧
基本の使い方#
評価したいインシデントや問題をすべてリストアップする。
- バグレポート、障害チケット、顧客クレーム、ヒヤリハット など
- 各イベントに以下の情報を付与する:
- 最後に発生した日時
- 過去N期間の発生回数
- 1回あたりの影響の大きさ
ポイント: 漏れなく一覧化することが重要。記録されていない問題は評価できない。
各イベントに1〜5点のスコアをつける。
R（Recency / 直近性）:
| スコア | 基準 |
|---|---|
| 5 | 直近1週間以内に発生 |
| 4 | 直近1ヶ月以内に発生 |
| 3 | 直近3ヶ月以内に発生 |
| 2 | 直近6ヶ月以内に発生 |
| 1 | 6ヶ月以上前に発生 |
F（Frequency / 頻度）:
| スコア | 基準 |
|---|---|
| 5 | 毎日発生 |
| 4 | 週に数回発生 |
| 3 | 月に数回発生 |
| 2 | 四半期に数回発生 |
| 1 | 年に1回程度 |
I（Impact / 影響度）:
| スコア | 基準 |
|---|---|
| 5 | サービス全体が停止 |
| 4 | 主要機能が使えない |
| 3 | 一部機能に支障 |
| 2 | 軽微な不具合 |
| 1 | 見栄えの問題のみ |
ポイント: スコア基準は自社の状況に合わせてカスタマイズする。重要なのは一貫した基準で評価すること。
3つのスコアを掛け合わせてRFIスコアを算出する。
RFIスコア = R × F × I（最大125点、最小1点）
必要に応じて重みづけも可能:
- 影響度を重視: RFIスコア = R × F × I²
- 頻度を重視: RFIスコア = R × F² × I
スコアの高い順に対応することで、最もリスクの高い問題から効率的に解決できる。
RFIスコアに基づいて対応のアクションレベルを設定する。
| RFIスコア | アクションレベル | 対応方針 |
|---|---|---|
| 60以上 | 緊急 | 即座に対応チームをアサイン |
| 30〜59 | 高 | 今週中に対応計画を策定 |
| 10〜29 | 中 | 次のスプリントで対応 |
| 10未満 | 低 | バックログに積む |
ポイント: 定期的（週次・月次）にRFIスコアを再計算する。新しいインシデントの追加や、状況の変化を反映させる。
具体例#
状況: 従業員60名のSaaS企業。バグチケットが50件溜まっており、エンジニア5名で対応中。「声の大きい顧客の要望順」で対応していた。
RFI分析の結果（上位5件）:
| バグ | R | F | I | RFIスコア | 内容 |
|---|---|---|---|---|---|
| BUG-042 | 5 | 5 | 4 | 100 | ログイン失敗が頻発（直近も発生中） |
| BUG-031 | 4 | 4 | 5 | 80 | データエクスポートでデータ欠損 |
| BUG-048 | 5 | 3 | 4 | 60 | ダッシュボードの数値が不正確 |
| BUG-015 | 3 | 4 | 3 | 36 | 特定ブラウザでレイアウト崩れ |
| BUG-037 | 2 | 2 | 4 | 16 | PDF出力で文字化け |
顧客満足度調査のスコアは3ヶ月で**15%**改善。「声の大きい顧客」順ではなく、最も多くのユーザーに影響する問題から解決する――RFI分析がその切り替えを可能にした。
状況: 従業員300名の電子部品メーカー。月間の品質不良報告が平均40件あるが、品質管理チーム3名では全件に対応しきれない。
RFI分析の結果:
| 品質問題 | R | F | I | RFIスコア |
|---|---|---|---|---|
| はんだ不良 | 5 | 5 | 4 | 100 |
| 基板の歪み | 4 | 3 | 5 | 60 |
| 端子の接触不良 | 5 | 4 | 3 | 60 |
| ラベルの貼り間違い | 3 | 3 | 2 | 18 |
| 梱包の傷 | 2 | 2 | 1 | 4 |
アクション:
- はんだ不良（RFI=100）: 即座にはんだ工程の全数検査を実施。原因は新ロットのフラックスの品質低下と判明
- 基板の歪み（RFI=60）: リフロー炉の温度プロファイルを再調整
- 端子の接触不良（RFI=60）: コネクタ挿入治具の摩耗を確認し交換
スコア60以上の3件に集中した結果、月間不良率は2.8%→0.9%に改善。年間の不良品コストを約4,200万円削減できた。全件を均等に扱っていた頃とは対照的な成果だった。
状況: 月間問い合わせ1,200件のWebサービス。サポートチーム5名で対応しているが、同じ内容の問い合わせが繰り返し発生。根本対策に手が回っていない。
RFI分析（問い合わせカテゴリ別）:
| カテゴリ | R | F | I | RFIスコア | 月間件数 |
|---|---|---|---|---|---|
| パスワードリセット方法 | 5 | 5 | 2 | 50 | 280件 |
| 請求書のダウンロード方法 | 5 | 4 | 2 | 40 | 180件 |
| 解約手続きのエラー | 4 | 3 | 5 | 60 | 45件 |
| APIの仕様確認 | 3 | 2 | 3 | 18 | 60件 |
アクション:
- 解約手続きエラー（RFI=60）: エンジニアチームにエスカレーションし、2週間で修正
- パスワードリセット（RFI=50）: セルフサービスのFAQページとチャットボットを導入
- 請求書ダウンロード（RFI=40）: UIにガイドツアーを追加
月間問い合わせ数は1,200件→740件（38%削減）。サポートチームが根本対策に使える時間は月40時間増えた。「件数は少ないが影響度が高い問題」を最優先にした判断が、この結果をもたらした。
やりがちな失敗パターン#
- スコア基準を曖昧にする — 「影響度が高い」の定義が人によって異なると、スコアリングがバラつく。具体的な数値や条件で基準を定義し、チーム内で合意する
- 一度スコアリングして放置する — 状況は変わる。先月はスコアが低かったバグが、今月は頻発しているかもしれない。最低でも月1回はスコアを再評価する
- RFIスコアだけで機械的に判断する — スコアが低くても、特定の大口顧客に影響する問題は優先すべき場合がある。RFIスコアは判断材料の1つであり、ビジネスコンテキストと合わせて最終判断する
- 記録されていない問題を見落とす — RFI分析はリストにある問題しか評価できない。問題を漏れなく記録する仕組み（チケットシステム等）の整備が前提条件
まとめ#
RFI分析は、直近性・頻度・影響度の3軸で問題やインシデントの優先順位を客観的に決定する手法。限られたリソースで最大の効果を出すために、「何から手をつけるべきか」を数値で示せる。まずは今抱えているバグやインシデントのリストにR・F・Iのスコアをつけて、対応順序を見直すところから始めよう。