Bug は defect の口語であり、defect は「ソフトウェアが要求を満たしていない」状態を指す正式な用語です。Issue はそれを含む上位概念で、不具合・機能要望・タスク・質問をまとめて扱います。 実務的には同じものを、儀式の度合いだけ変えて呼んでいるだけです。混乱を生むのは、ひとつのチーム内で3つを混ぜて使うことです。 違いが効くのは会話ではなく3か所です。何を測定するか、契約で何を約束するか、報告者に何を書かせるか。 この記事では、用語集に書いて議論を終わらせられる分け方を示します。
短い答え
| 用語 | 範囲 | よく見る場所 |
|---|---|---|
| Bug | defect の口語。以前は動いていた、あるいは明らかに動くべき箇所 | 朝会、チャット、「決済にバグがある」 |
| Defect（不具合） | 正式用語。実際の動作と期待動作のあらゆるズレ（以前動いていたかは問わない） | QA レポート、監査、契約、指標 |
| Issue | 上位概念。判断が必要なすべて——不具合、機能要望、タスク、質問 | トラッカーの起票、リリースノート |
| Error | 人が起こした、誤った結果につながる行為 | 原因分析、ポストモーテム |
| Fault | 失敗を引き起こす、ソフトウェア内の誤った命令やデータ | エンジニアリングの議論、規格 |
| Failure | 観測できる事象。システムが果たすべきことを果たさない | インシデントレビュー、監視 |
連鎖：Error / Fault / Failure
規格でも使われ、ポストモーテムでも有用な古典的モデルです。トラッカーでは「Issue」と呼ぶほうが良い理由
トラッカーに入るのは不具合だけではありません。対象を issue と呼べば（bug は日常語として残す）、次のすべてを1か所に置けます。- defect：動作が誤っている
- feature request：動作が意図的に欠けている
- task：動作を伴わない作業
- question：コード変更を伴わない疑問
区別がお金になる3つの場面
1. 契約と SLA。「重大な不具合は24時間で修正」と約束する契約には、defect と critical の文書定義が要ります。なければ毎回の議論が交渉になります。契約に「bug」と書くと、たいてい執行できません。 2. 指標。 不具合密度、流出率、再オープン率は、母集団が安定しているときだけ意味を持ちます。「bug」の半分が要望なら、どの数字も成立しません。 3. 監査とコンプライアンス。 規制産業では、深刻度・検証・クローズ根拠を備えた追跡可能な不具合記録が求められます。これは正式な成果物であり、defect という語自体がその正式さを示します。Bug か機能要望か
最も議論になる境界線です。| 不具合である条件 | 要望である条件 |
|---|---|
| 動作が文書化された要求や確定した設計と矛盾する | 要求が存在せず、その動作は一度も約束されていない |
| 以前できていた作業をユーザーが完了できなくなった | 完了はできるが、好む方法ではない |
| システム状態が不整合になる、またはデータが失われる | システムは整合しており、出力が単に望みと違う |
| アクセシビリティ、セキュリティ、データ整合性に関わる | レイアウト、文言、フローの好み |
Bug か「エラー表示」か
画面に出るエラーメッセージ自体は不具合ではありません。「メール形式が不正です」は正しい動作です。不具合は、メッセージの内容が誤っている・出るべきときに出ない・出るべきでないときに出す場合です。また「Console error」の error は実行時が記録した例外で、不具合のこともあれば、想定内で処理済みのこともあります。だからこそ報告には Console の出力をテキストで添付すべきです。スクリーンショットでは、トリアージに必要な文言・スタック・発生頻度が伝わりません。語彙をひとつ選び、書き残す
多くのチームが運用できる落としどころです。- Issue をトラッカーの対象にする。すべての型はその下に置く。
- Defect を「動作が誤っている」型とし、指標・契約・レポートで使う語にする。
- Bug は口語として残す。ダッシュボードには載せない。
- Error / Fault / Failure は原因分析の中だけで、この順に使う。
レポートへの影響
呼び方が何であれ、トリアージに必要な項目は同じです。- 正確なページまたはエンドポイント
- 何をして、何を期待し、実際どうなったか
- 証拠：スクリーンショット、Console エラー、失敗したリクエスト
- 環境：ブラウザ、OS、ビューポート、タイムスタンプ