issue-triage

分類システム

受け付けたすべてのイシューには、以下の分類体系に基づいて主ラベルを付与し、該当する場合は副ラベルも付与します。

ラベル	対象範囲	典型的な兆候
不具合	仕様や想定に反したプロダクトの動作	エラーメッセージ、クラッシュ、データの誤表示、デグレード、想定外の出力
案内	手順や説明を求めるお客様からの問い合わせ	「どうすれば……」「どこで確認できますか……」、セットアップに関する質問、設定のサポート
機能改善	新機能または機能変更のリクエスト	「……ができると助かります」「……を追加できますか」「……の予定はありますか」
請求	料金、サブスクリプション、請求書、価格、返金	支払いの失敗、予期しない請求、プラン変更、クレジットのリクエスト
アクセス	ログイン、権限、SSO、ユーザー管理	アカウントへのアクセス不能、パスワードリセット、ロールの割り当て、MFA の問題
インテグレーション	外部ツールや API との接続	Webhook の失敗、OAuth エラー、同期の問題、API レスポンスの問題
セキュリティ	脅威、データ漏えい、コンプライアンスに関する問い合わせ	不正アクセス、脆弱性の報告、GDPR／SOC 2 に関する質問
データ	データの整合性、移行、インポート／エクスポートに関する懸念	レコードの欠落、重複エントリ、インポートの失敗、エクスポートの書式
信頼性	速度、稼働時間、またはサービスの品質低下	タイムアウト、読み込みの遅延、5xx エラー、サービスの利用不能

適切なラベルの選び方

• お客様が複数の懸念事項（例：不具合と機能改善の要望）を述べている場合、根本的な問題に基づいて主ラベルを決めます。
• お客様が以前利用できていたワークフローが使えなくなった場合は、機能改善ではなく不具合です。
• プロダクトに新しい動作を求めるリクエストは、お客様が「動作していない」と表現していても、機能改善です。
• 判断に迷う場合は不具合を優先します。不具合の可能性を調査するほうが、不具合ではないと判断してしまうより安全です。

重大度レベル

P1 -- 停止／緊急事態

プロダクトが完全に利用不能である、データが危険にさらされている、またはセキュリティインシデントが進行中です。影響範囲が広く（ほとんど、またはすべてのユーザーが影響を受ける）、または取り返しのつかない結果につながる可能性があります。

• サービスが全面的に利用不能
• データの損失、破損、または不正な漏えいが進行中
• セキュリティ侵害が進行中
• 介入しなければ状況が悪化している

対応の約束： 60 分以内に初回返信します。問題が緩和されるまで継続して対応します。1～2 時間ごとに状況を更新します。

P2 -- 深刻な業務中断

重要な機能が動作せず、多数のユーザーが利用できない状態で、実用的な回避策がありません。

• 中核的なワークフローが停止しているが、付随機能は引き続き動作している
• 複数のユーザー、または戦略上重要なアカウントが影響を受けている
• 時間的制約のある業務が滞っている
• 妥当な代替手段がない

対応の約束： 4 時間以内に初回返信します。当日中に調査します。4 時間ごとに状況を更新します。

P3 -- 中程度の影響

機能の品質が低下しているものの、別の手段で利用できる場合、または影響を受けるユーザーが限られている場合です。

• 機能に支障があるが、実行可能な回避策がある
• 業務を妨げるほどではなく、不便な状態である
• 少数のユーザーが影響を受けている
• お客様からの緊急の要請はない

対応の約束： 1 営業日以内に初回返信します。3 営業日以内に進捗をお知らせします。

P4 -- 軽微／情報提供

見た目上の不具合、一般的な問い合わせ、機能改善のアイデア、または文書化された解決策がある問題です。

• 機能への影響がない見た目上の不具合
• 機能改善の提案やフィードバック
• ドキュメントで回答できる一般的な質問
• 既存の手順に従えば解決できる問題

対応の約束： 2 営業日以内に初回返信します。標準的なペースで解決します。

深刻度の引き上げが妥当な条件

次のいずれかが発生した場合は、深刻度を引き上げます。

• 解決しないまま SLA の期限を過ぎた
• 同じ症状を報告する顧客が 3 人以上に増え、パターンが見られる
• 顧客が経営陣の対応を明示的に求める、または解約を示唆する
• 以前は有効だった回避策が機能しなくなる
• 影響範囲が拡大する（影響を受けるユーザー、システム、データが増える）

振り分けガイドライン

各問題を、最も適切に解決できるチームに振り分けます。

振り分け先	該当するケース
一次サポート	解決策が既知の問題、ドキュメントで回答できる質問、パスワードのリセット、簡単な請求に関する問い合わせ
シニア／テクニカルサポート	調査が必要なバグ、複雑な設定、連携機能のデバッグ、複雑なアカウント関連のケース
エンジニアリング	コードの変更が必要な、確認済みの不具合、インフラストラクチャのインシデント、パフォーマンスの低下
プロダクトマネジメント	需要の高い機能リクエスト、設計レベルのワークフロー上のギャップ、優先順位の決定
セキュリティチーム	脆弱性の報告、データ漏えいに関する懸念、コンプライアンス関連の問い合わせ
財務／請求	返金の承認、契約上の請求に関する紛争、標準外の価格調整

重複する報告の特定

新しい問題を振り分ける前に、既存の問題と重複していないか確認します。

1. 症状の検索： エラーテキストや動作の説明が一致する、未解決の問題を探します。
2. 顧客履歴： 同じ顧客が関連する報告をすでに提出していないか確認します。
3. 機能領域の確認： 同じプロダクト領域に関する最近の問題を確認します。
4. 既知の問題の登録簿： 記録されている対応中の問題と照合します。

一致する問題が見つかった場合：

• 新しい報告を既存の問題に関連付けます。
• 問題を追跡しており、対応中であることを顧客に伝えます。
• 新しい報告で得られた追加情報や再現状況を追記します。
• 追加の報告によって影響が広がる場合は、深刻度を再評価します。

初回応答のパターン

不具合の場合

Thanks for letting us know about this. I understand that [specific
disruption] is affecting your work.

This has been logged at [severity] and our team is looking into it.
[If a workaround exists: "While we investigate, you can [workaround]."]

Expect an update from us by [timeframe based on SLA].

案内を求める問い合わせの場合

Good question! [Concise answer or pointer to documentation]

[For multi-step answers: "Here is a walkthrough:"]
[Numbered steps or explanation]

Let me know if this resolves things or if anything else comes up.

機能強化のアイデアの場合

Appreciate you sharing this idea -- I can see how [desired capability]
would improve your workflow.

I have forwarded this to our product team. I cannot promise a specific
delivery date, but input like this directly shapes our priorities.

[If a partial solution exists: "In the meantime, [alternative approach]
may help."]

請求に関する懸念の場合

I know billing matters need quick resolution. Let me take a look.

[If straightforward: provide resolution details]
[If investigation needed: "I am reviewing your account and will
follow up by [timeframe]."]

セキュリティ報告の場合

Thank you for raising this -- we treat security matters with the
highest urgency.

This has been routed to our security team for immediate review.
You will hear back by [timeframe].

[If protective steps are advisable: "We recommend [action] in the
meantime."]

運用ガイドライン

1. ラベルを割り当てる前にスレッド全体を読みます。後のメッセージによって状況が変わることがよくあります。
2. 表面的な症状だけでなく、根本原因に基づいて分類します。
3. 深刻度に確信が持てない場合は、高めに見積もります。後から引き下げるほうが、対応の約束を果たせなかった場合の挽回よりはるかに簡単です。
4. 振り分ける前に、必ず重複や既知の問題を確認します。
5. 次の担当者が再調査せずに対応できるよう、評価内容と除外した可能性をまとめた内部メモを添付します。
6. 新たなパターンに注意します。同じトピックに関する深刻度の低い報告が繰り返される場合、より高い注意を要するシステム上の問題を示している可能性があります。