Issue Tracking System（課題管理システム）とは、不具合・タスク・要望といった「判断が必要なもの」を一か所に記録し、担当を決め、クローズまで追跡する台帳です。選定は結局4点で決まります——課題がどう入ってくるか、どう流れるか、誰が見られるか、自社の席数でいくらになるか。 多くのチームは機能表を比べて選び、半年後に気づきます。ツールは悪くない、壊れているのは入口だと。課題はチャットのメッセージで届き、スクリーンショットはフォルダに散らばり、「これ見てもらえます？」で終わる。未対応が何件あるのか誰も言えず、台帳には誰かがわざわざ打ち直した分しか残っていません。 この記事は両方を扱います。本当に選定を決める9つの基準と、ほぼすべての比較記事が飛ばしている「入口」の話です。
Issue Tracking System とは何か
Issue Tracking System（issue tracker、課題管理システム。範囲を狭くすれば bug tracking system や defect tracking system）がやることは4つです。- 記録：他の人が動けるだけの情報量で問題を残す。
- 割当：担当者を決め、責任の所在を見えるようにする。
- 追跡：ステータスを 新規 から クローズ まで運び、誰が何を変えたかを残す。
- 測定：未対応が何件か、どれだけ滞留しているか、どこで詰まっているかを答える。
Issue Tracking System / Bug Tracker / ヘルプデスクの違い
言葉は重なっていて、ベンダーも緩く使っています。実務上の違いは範囲です。| システム | 典型的な範囲 | 主な所管 |
|---|---|---|
| Issue Tracking System | 判断が必要なすべて：不具合、タスク、要望、質問 | プロダクト / 開発 |
| Bug Tracker / Defect Tracker | 不具合のみ。多くの場合ビルドやテストサイクルに紐づく | QA |
| ヘルプデスク / サービスデスク | 外部ユーザーからの依頼と対応期限 | サポート / IT |
| テスト管理ツール | テストケース、実行、結果。不具合はケースに紐づく | QA |
選定を決める9つの基準
トライアルを開く前に並べてください。順番のほうが答えより重要です。| # | 基準 | なぜ結果を決めるか | 確認すること |
|---|---|---|---|
| 1 | 入口 | 台帳の質は入ってくるものの質で決まる | 非技術者がワンクリックで送れるか。注釈付きスクリーンショット、Console エラー、失敗したリクエスト、ブラウザ/OS/ビューポートが自動で付くか |
| 2 | ワークフロー | 硬すぎるフローは迂回され、緩すぎるフローは状態を隠す | 状態をコンサルなしで追加できるか。遷移は記録されるか |
| 3 | フィールド | 深刻度と優先度は別のフィールド | severity（技術的影響）と priority（ビジネス上の緊急度）が分かれているか。プロジェクト別のカスタム項目 |
| 4 | 重複検出 | トリアージが詰まる最大の理由は重複 | タイトルとページURLで入力中の検索ができるか。履歴を保ったまま統合できるか |
| 5 | 外向きの連携 | 台帳は人が既に見ている場所に届く必要がある | チャット（Slack / Teams）、コード管理、リリースノート、そして残りを拾う汎用 Webhook |
| 6 | 権限 | 外部の報告者にバックログ全体を見せてはいけない | ゲスト権限が自分の起票分だけか。プロジェクト単位の公開範囲 |
| 7 | 測定 | 滞留時間が出せなければ队列は回せない | 経過日数別の未対応、担当者別の負荷、再オープン率、サイクルタイム、エクスポート可否 |
| 8 | 自社の席数でのコスト | 席数の計算のほうが機能より結論を変える | 5 / 20 / 50 席で試算。閲覧者・ゲスト・起票者は席数に数えるか |
| 9 | 移行コスト | 少なくとも一度は移行する | 添付とコメントを含む完全エクスポート。API は公開されているか |
Issue Tracking System 9製品の比較（2026）
価格は課金モデルの形だけを書き、具体的な金額は書きません。定価は変わり、地域差もあります。最新の数字は各社サイトで確認してください。| ツール | 向いているチーム | 課題の入り口 | 課金モデル | 注意点 |
|---|---|---|---|---|
| Jira（Atlassian） | ワークフローを柔軟に組みたい、すでに Atlassian 圏内のチーム | 手入力フォーム、メール、連携 | 無料枠あり、以降は席数課金 | 設定負債。すぐに「管理者」という専任役が生まれる |
| Linear | 速度とキーボード操作を重視するプロダクトチーム | 手入力、Slack、連携 | 席数課金 | 意図的に主張が強い。非開発の依頼队列には不向き |
| GitHub Issues | 作業がすでにリポジトリに密着しているチーム | 手入力、テンプレート、API | リポジトリのプランに含まれる | 非コードの依頼とリポジトリ横断の集計が弱い |
| GitLab | issue、マージリクエスト、CI を1か所に置きたいチーム | 手入力、テンプレート、API | 段階制のサブスク、無料のセルフホスト版あり | 段階間の機能差が細かい |
| YouTrack（JetBrains） | クエリ駆動のビューと独自ワークフローが欲しいチーム | 手入力、メール、連携 | 席数課金、小規模チームは無料 | 画面の情報密度が高い。非技術者の学習コスト |
| Azure DevOps Boards | テスト計画とパイプラインを使う Microsoft スタックのチーム | 手入力、パイプライン、連携 | ユーザー課金 | Azure DevOps の他機能も使う場合のみ割に合う |
| Bugzilla | 実績ある自己ホスト型の不具合データベースが要る長期プロジェクト | 手入力、メール | 無料、オープンソース | UI が古い。レポートは拡張頼み |
| Redmine | 運用担当がいて、モジュールと完全な統制を求めるチーム | 手入力、メール | 無料、オープンソース | プラグインが増えがち。アップグレードは実作業 |
| MantisBT | シンプルな自己ホスト型トラッカーが欲しい小規模チーム | 手入力、メール | 無料、オープンソース | 自動化が少なく、現代的な連携も少ない |
ほぼすべての選定が飛ばす工程：課題はどう入ってくるか
上の表のツールはすべて「課題はすでに説明済み」という前提です。そして時間はまさにそこで消えます。- テスターが「決済ボタンが反応しない」と書き、開発は DevTools を開く前に3つ質問する。
- スクリーンショットはチャットに残り、ページURL とブラウザ情報から切り離されている。
- すべてを説明する Console エラーは取得されていない。報告者は Console を知らないからだ。
- 再現できず「こちらでは動きます」で閉じられ、2スプリント後に戻ってくる。
| 修正に必要な情報 | 手入力の報告 | 自動コンテキスト付きの報告 |
|---|---|---|
| どこで起きたか | 「決済ページ、たぶん」 | 正確な URL とページタイトル |
| 何をクリックしたか | 報告者の言葉で1文 | 要素を指す注釈付きスクショとセレクタ |
| 何が壊れたか | 「動かない」 | Console エラーと失敗したネットワークリクエスト（原文） |
| 環境 | 「Chrome、たぶん Mac？」 | ブラウザ、OS、ビューポート、タイムスタンプ |
| 誰が再現できるか | 報告者の手が空くまで誰も | リンクを持つ誰でも、すぐに |
60分で終わる選定プロセス
実際いくらかかるか
請求額を決める数字は3つで、価格ページに載っているのは1つだけです。- 席数 × 月数：まず「席」の定義を確認。外部の報告者や閲覧専用ユーザーが席を消費するなら、実額は人数よりはるかに大きくなります。
- 連携と自動化の追加費用：「安い」プランは自動化回数・API コール・連携数を制限しがちで、それはまさにトラッカーを有用にする部分です。
- 管理工数：ワークフロー設計、項目の整理、重複の統合は継続作業。月に数時間を確保しないと台帳は荒れます。
移行チェックリスト
トラッカーの乗り換えは、項目の話ではなく添付とコメントの話です。- すべてエクスポートする：課題、コメント、添付、ウォッチャー、ステータス履歴。
- ステータスは移行先の状態に寄せる。1対1で対応させない。必要な状態はほぼ必ず今より少なくなります。
- 12か月以上前のクローズ済み課題の扱いを、移す前に決める。
- 旧システムは少なくとも1四半期は読み取り専用で残す。リンクが必要な人が必ず出ます。
- 先に連携を切り替え、その後にユーザーを招待する。逆順だと1週間、通知が二重に飛びます。
- 二重入力は P0/P1 のみ1週間。その後切り替える。
- 切り替え後に入口を必ず確認する。移行を一番早く殺す方法は、報告ボタンを壊すことです。