問題追跡システム

問題追跡システム（ITS、トラブルチケットシステム、サポートチケット、リクエスト管理、インシデントチケットシステムとも呼ばれる）は、問題のリストを管理および維持するコンピュータソフトウェアパッケージです。 [ 1 ]^問題追跡システムは、一般的に共同作業の設定、特に大規模または分散型の共同作業で使用されますが、時間管理や個人の生産性管理の一環として個人が使用することもできます。これらのシステムには、集中型の問題レジストリの実装に加えて、リソース割り当て、時間計算、優先順位管理、監視ワークフロー が含まれることがよくあります。

組織の設定では、問題追跡システムは、組織のカスタマー サポート コール センターで、報告された顧客の問題、またはその組織の他の従業員によって報告された問題を作成、更新、解決するためによく使用されます。サポート チケットには、関係するアカウントと発生した問題に関する重要な情報が含まれている必要があります。^{[2]問題追跡システムには、各顧客に関する情報、一般的な問題の解決策、およびその他のそのようなデータを含む}ナレッジ ベースも含まれることがよくあります。

問題追跡システムは「バグトラッカー」に似ており、多くの場合、ソフトウェア会社は両方を販売しており、バグトラッカーの中には問題追跡システムとして使用可能なものもあり、その逆も可能です。問題追跡システムまたはバグ追跡システムを一貫して使用することは、「優れたソフトウェアチームの特徴」の1つと考えられています。^[3]

問題追跡システム内のチケット要素は、特定の問題、そのステータス、およびその他の関連データに関する実行中のレポートです。チケット要素は、通常、ヘルプ デスクまたはコール センター環境で作成され、ほとんどの場合、ケース番号、問題番号、またはコール ログ番号とも呼ばれる一意の参照番号を持ちます。この番号は、ユーザーまたはヘルプ スタッフがユーザーの問題またはリクエストのステータスをすばやく見つけたり、追加したり、伝達したりできるようにするために使用されます。

これらのチケットは、この種のサポートが始まったときに、従来の壁掛け作業計画システム内の小さなカードとして始まったため、このように呼ばれています。ユーザーからの電話や問い合わせを受けたオペレーターまたはスタッフは、ユーザーの詳細とリクエストの簡単な概要を記した小さなカードを記入し、適切なエンジニアの保留スロットの列の位置 (通常は最後) に配置します。これにより、問い合わせに対応するスタッフとリクエストの優先度が決まります。

問題追跡システムとバグトラッカーの共通の概念的基盤は、有効な問題は決定的な解決（「完了」、「修正済み」、または「問題ではない」または「修正されない」など、その問題を解決する価値がないというグループの合意など）に従わなければならないこと、各問題は一意であること（重複した問題報告はほとんどの場合、1 つのアクティブな問題またはチケットに即座に統合される）、およびスクリーニング段階を超えて、問題を前進させる正式な責任を割り当てられた 1 人の人物が存在すること（この正式なバトンは、問題が進化するにつれて何度も跳ね返ることが多い）です。バグトラッカーでは、問題は一般にコードベース（本質的にプロジェクト管理の設定）に関して品質または機能に関連していますが、一般化された問題追跡システムでは、チケットはサービス関連または関係ベースであることが多く、顧客関係管理（CRM）の問題とより密接に関連しています。^[4]

問題にはいくつかの側面があります。システム内の各問題には、その問題の全体的な重要度に基づいて緊急度の値が割り当てられている場合があります。緊急度が低い、または緊急度がゼロの問題は軽微な問題であり、時間の許す限り解決する必要があります。

問題のその他の詳細には、問題が発生している顧客（外部または内部）、提出日、^[5]発生している問題の詳細な説明、試みられた解決策または回避策、およびその他の関連情報が含まれます。各問題には、各変更の履歴が保持されます。

問題追跡システムは、特に次のようなさまざまな機能を果たします。

• 機能不全、エラー、リクエストの入力（例：手動または電子メールによる応答管理システム）
• 担当者への課題の分配と割り当て
• 作業の取り扱い、所要時間、品質の監視
• ワークフローの助けを借りて強制制御による内部プロセスの監視を確実にする
• チケット数の統計分析
• ネットワーク監視などの警報システムによるチケットの自動生成
• 外部サービス契約の履行（サービスレベル契約、SLA）
• FAQの質問と回答を体系的に収集
• 問題の全体的な重要度、顧客、提出日、SLAに基づいて各問題に優先順位を割り当てます。
• 発生している問題の詳細な説明、試みられた解決策や回避策、その他の関連情報を含む
• 各変更の履歴の維持

一般的な問題追跡システムがどのように機能するかを示すサンプルシナリオを示します。

1. 顧客サービス技術者は、顧客から問題についての電話、電子メール、またはその他の連絡を受け取ります。一部のアプリケーションでは、組み込みのメッセージング システムと、例外処理ブロックからの自動エラー レポートが提供されます。
2. 技術者は、問題が単なる認識ではなく、実際に存在するものであることを確認します。また、技術者は、顧客から問題に関する十分な情報を確実に取得します。この情報には通常、顧客の環境、問題の発生時期と状況、およびその他の関連する状況が含まれます。
3. 技術者は、顧客から提供されたすべての関連データを入力して、システムに問題を作成します。
4. 問題に対する作業が完了すると、技術者によって新しいデータがシステムで更新されます。問題解決の試みはすべて問題システムに記録されます。チケットのステータスは、おそらくオープンから保留に変更されます。
5. 問題が完全に解決されると、問題追跡システムで解決済みとしてマークされます。

問題が完全に解決されていない場合は、技術者が顧客から新しい情報を受け取ると、チケットが再度オープンされます。これらのワークフローのベスト プラクティスを実装し、IT 担当者の効率性を高めるRun Book Automationプロセスは、非常に一般的になりつつあります。

一部の政府サービスでは、問題を追跡して公開するために問題追跡システムを使用しています。問題追跡システムでは、政府がまだ実行していないすべてのタスク (待機キュー内)、完了したタスク、進行中のタスク、注文の順序などが表示されます。^{[引用が必要]}完了したタスクもレポートで予測でき、問題に対して正確に何が行われたかを示します。^{[引用が必要]}

問題追跡システムは、例えば、どの法案 が投票にかけられているか、そしてその結果がどうなるかを追跡するために使用されます。^[6]

交通やインフラに関する問題（道路の障害、苦情など）も問題追跡システムを使って報告することができます。^[7]その後、関連する政府サービスが問題に対処します。

• ヘルプデスクソフトウェア
• ヘルプデスク問題追跡ソフトウェアの比較
• 問題追跡システムの比較
• 気候行動トラッカー
• アルゴリズムによる政府
• 問題ログ
• 国家優先事項リスト
• 提案箱
• オープンソースソフトウェア開発
• 優先順位
• プッシュ・プル戦略
• リソースの割り当て
• ユーザーのイノベーション

: このカテゴリの名前は、バグ追跡システムと問題追跡システムの両方をリストしているため、誤解を招く可能性があります。
: DMOZ のヘルプデスクおよび問題追跡ソフトウェア: このカテゴリには、 Java
で開発された問題追跡システムがリストされます。