バグではなく、機能です — 本質、起源、違い

「バグではなく、機能です」の意味

「バグではなく、機能です」 — 開発者やマネージャーが、プログラムの予期しない動作が誤りではなく意図的であることを示すために使うフレーズです。典型的なケースでは、これはジョークです。全員が動作が間違っていることを理解していますが、緊張を和らげるために「機能」と呼びます。しかし、実際のプロジェクトでは、このフレーズは本気でも使われます — 動作が実際に仕様に一致しているが、ユーザーの期待を満たしていない場合です。

バグと機能の違いはしばしば主観的です。コードを書いた開発者にとって、特定の動作は論理的に見えるかもしれません。ユーザーにとっては、予期せず誤っているように見えるかもしれません。認識の主観性が、このフレーズがこれほど根強い主な理由です。会話を「誰が悪いのか」から「そう設計された」に移行させます。UX Collectiveによると、ユーザーが報告するバグの40%は実際にはUXの問題であり、コードのエラーではありません。

アジャイルチームでは、デモの際にこのフレーズが防御メカニズムとしてよく使われます。開発者が予期しない動作を示し、プロダクトオーナーが眉をひそめ、運命的なフレーズ「バグではなく、機能です」が発せられます。チーム内の信頼が、このフレーズがジョークとして受け入れられるか、問題を隠そうとする試みとして受け取られるかを決定します。健全なチームでは、そのようなジョークは雰囲気を和らげますが、毒性のあるチームでは衝突を引き起こします。

象徴的なフレーズの起源の歴史

このフレーズの最初の既知の使用は1976年にDECUS（Digital Equipment Corporation User Society）の掲示板で記録されました。ユーザーがRUNOFFテキストプロセッサが空白行を正しく処理しないと苦情を言いました。開発者の回答：「バグではなく、機能です — 段落はこうやって処理されるのです。」それ以来、このフレーズは実際の品質に関係なく、「あるがまま」に書かれたコードを守る象徴になりました。

このフレーズの普及に貢献したのはJargon File — ハッカー用語の辞書で、1990年代に「The New Hacker’s Dictionary」の基礎となりました。Jargon Fileでは、「feature」の項目は修正が不可能または望ましくないために機能になったバグを直接参照しています。例：初期の端末のCaps Lockキーにはインジケーターがありませんでした — これは「ブラインドタイピング用」の機能になったバグでした。

2000年代には、このフレーズはインターネットミームを通じて大衆文化に移行しました。「It’s not a bug, it’s a feature」というキャプションが付いた猫の画像がフォーラムやソーシャルメディアに広がりました。ゲーム業界では、このフレーズは特に頻繁に使われます：ゲームプレイに影響を与えないグリッチは、雰囲気のために「機能」と宣言されます。文化的現象はITをはるかに超えて広がりました — このフレーズは、エラーを正当化するあらゆる文脈で耳にすることができます。

言い訳の心理：なぜそう言われるのか

このフレーズの心理的基盤は認知的不協和です。開発者はコードを書くのに何時間も費やし、結果が間違っていると認めることは自分の仕事を過小評価することになります。「バグではなく、機能です」というフレーズは不協和を減らします：エラーは意図的な決定に変わり、開発者は責められる側からアイデアの作者になります。これは自尊心を保つ心理的防御メカニズムです。

2番目の理由はやり直しへの恐れです。バグを認めることは、コードレビュー、テスト、デプロイを再度行うことを意味します。「機能」は修正を必要としません — タスクはクローズされ、作業負荷が減ります。Microsoft Researchによると、開発者は23%のケースでやり直しを避けるために意図的にバグの深刻度を低く見積もります。このフレーズはそのような低く見積もりの軽い形です。

3番目の理由は企業文化です。一部の企業では、バグが開発者のKPIに影響し、コードレビューでバグを見つけることが作成者のミスと見なされます。そのような環境では、「バグではなく、機能です」というフレーズはキャリアへの悪影響を避ける方法です。健全なエラー文化（非難のない文化）はこの理由を排除します：バグが罰せられなければ、認めるのが容易になります。

バグと機能の境界線はどこか

明確な境界は受け入れ基準がある場合にのみ存在します。動作がいずれの受け入れ基準項目にも一致しない場合 — それはバグです。動作が受け入れ基準に一致するがユーザーが好まない場合 — それはUXの問題であり、バグではありません。受け入れ基準がない場合 — どのような動作でも機能と宣言でき、これがフレーズが根強い主な理由です。

実用的なルール：バグとは、プログラムが仕様に従ってすべきでないことをする、またはすべきことをしない場合です。機能とは、結果がユーザーを驚かせる場合でも、プログラムが意図されたことをする場合です。グレーゾーン：未定義動作（言語が結果を定義しない）、レースコンディション（不安定に現れる）、エッジケース（99%のデータで機能する）。

明確にするために、決定マトリックスを使用します：

• 動作が仕様に記述され、正しく実装されている — 機能、気に入らなくても
• 動作は記述されているが、正しく実装されていない — バグ、修正が必要
• 動作は記述されていないが、要件から論理的に導かれる — 文書化されていない機能、仕様に追加が必要
• 動作は記述されておらず、非論理的 — バグ、要件の明確化が必要

最も危険なケースは、仕様が存在せず、開発者が自分で何が機能かを決定する場合です。そのようなプロジェクトでは、どのようなエラーでも「機能」と宣言でき、チーム全体にとってコードが予測不可能になります。各タスクに明確な受け入れ基準があることが — 客観的に線を引く唯一の方法です。

チームにおける概念のすり替えの危険性

最初の危険は品質の低下です。すべてのバグを機能と宣言できるなら、チームに質の高いコードを書くインセンティブがありません。エラーは修正されなくなり、技術的負債が増え、ユーザーは「奇妙な動作」に慣れてしまいます。遅かれ早かれ、競合他社が予測可能に動作する製品をリリースし、ユーザーは離れていきます。

2番目の危険はチーム内の対立です。QAエンジニアがバグを発見し、開発者が「それは機能です」と言います。客観的な基準（受け入れ基準）がなければ、議論は個人的なレベルに陥ります：「テストが下手」vs「プログラミングが下手」。PractiTest State of Testing 2023によると、「バグ vs 機能」の論争はQAと開発者の間の摩擦の3大原因の一つです。

3番目の危険は法的リスクです。規制産業（医療、金融、航空）では、「バグ」と「機能」の概念には法的な重みがあります。医療ソフトウェアで動作が機能と宣言され、それが誤った投薬計算につながる場合 — それはジョークではなく、規制要件の違反です。安全性重視のシステムは概念のすり替えを許さないため、常に形式検証を使用します。

バグと機能の混乱を防ぐ方法

主なツールは、各タスクにおける明確な受け入れ基準です。受け入れ基準は開発開始前に書かれます：「Xを入力すると、システムはYを出力しなければならない」。動作が記述されていない場合 — デフォルトでバグであり、開発者が別の意見を持っていても同様です。受け入れ基準は測定可能で検証可能でなければなりません：「ボタンは緑色」は悪く、「HEX #00FF00」は良いです。

2番目のツールは、チーム内の完了の定義です。「タスク完了」の意味の明確な説明：コードが書かれた、テストが書かれた、テストに合格した、コードレビューが完了した、ステージングにデプロイされた、QAによってテストされた。完了の定義のすべての項目が満たされ、ユーザーがまだ苦情を言う場合 — それはバグではなく、バックログに新機能として入る見落とされた要件です。

3番目のツールは非難のないポストモーテム文化です。バグが機能と宣言されて本番環境に送られた場合 — 原因を分析し、責任者を探しません。なぜ開発者はそれを機能だと思ったのか？なぜQAは見逃したのか？なぜ受け入れ基準が不完全だったのか？これらの質問への回答はプロセスを改善し、人を罰しません。システム的な改善は、「バグではなく、機能です」というフレーズを禁止するよりも効果的に機能します。