CHAPTER 03BUG

第3章|トラブルへの備え

【IT用語】「バグ」とは?期待した動きとの「ずれ」

バグとは何かを、仕様とのずれ、実装・要件・使いやすさの問題、発生する原因、見つけた後に再発を防ぐ考え方まで解説します。

「ボタンを押したら画面が止まった」

「計算結果が合わない」

こうした不具合は、よく「バグ(Bug)」と呼ばれます。では、エラーが表示されなければバグではないのでしょうか?

今回は、バグを「設計図と完成品のずれ」に例えて解説します。

結論:「バグ」=「期待・仕様と、実際の動きがずれている状態」

バグとは、一般に「ソフトウェアが、求められた動きや意図した結果と異なる状態」を指します。

画面が止まるような分かりやすい不具合だけではありません。

  • 計算結果が間違っている
  • 保存したはずのデータが消える
  • 特定の端末だけでボタンが押せない
  • 権限のない人が情報を見られる

見た目は動いていても、仕様や安全性を満たしていなければ問題です。

「本物の虫」が語源なの?

1947年、コンピュータのリレーに蛾が挟まり、記録帳へ貼られた有名な出来事があります。

ただし、「bug」という言葉は、それ以前から機械や電気回路の不具合を表す言葉として使われていました。蛾の事件は言葉の始まりではなく、コンピュータの世界で「バグ」という表現が広まる象徴的な出来事です。

バグにもいろいろある

1. 実装のバグ

プログラムの条件や計算を間違え、意図と異なる動きをする状態です。

例:合計金額へ送料を足すはずが、同じ送料を2回足してしまう。

2. 仕様・要件の問題

プログラムは設計書通りに動いていても、設計そのものが利用目的と合っていない場合があります。

これは「仕様バグ」と呼ばれることもありますが、チームによっては「要件漏れ」「仕様不備」と分けて扱います。

3. 使いやすさの問題

ボタンが小さすぎる、文字のコントラストが低い、操作の流れが分かりにくい。こうした問題は、UX上の課題やアクセシビリティ不具合です。

チームによってはバグとして管理し、別のチームでは改善課題として扱います。大切なのは呼び名より、ユーザーが困っている事実を見落とさないことです。

なぜバグは生まれるの?

ソフトウェアは、多くの条件が組み合わさって動きます。

  • 要件の認識がずれていた
  • 条件分岐や計算を間違えた
  • 想定していない入力が届いた
  • OSやブラウザの違いが影響した
  • 別の変更と組み合わさって問題が起きた

原因は単純な書き間違いだけではありません。だから開発では、レビューやテスト、監視を組み合わせます。

「バグは出るもの」の本当の意味

この言葉は、ミスを放置するための言い訳ではありません。

すべての条件を最初から完全に予測するのは難しい。だからこそ、問題を早く見つけ、影響を小さくし、同じ問題を繰り返さない仕組みを用意する、という考え方です。

バグが見つかった時は、誰かを責めるよりも、再現条件と原因を確かめることが解決への近道になります。

KatakataLabで実際に確認したこと

トップページの作品一覧は、JavaScriptが projects.json を取得した後には表示されていました。しかし初期HTMLには読み込み中の骨組みしかなく、通信やJavaScriptに失敗すると主要ツールの説明が消える状態でした。普段のブラウザでは動くため見落としやすい、表示設計上のバグです。

修正では、主要カードを初期HTMLにも生成し、JSON取得に失敗した時はその内容を残すようにしました。さらに「初期HTMLだけでもQRコードやパスワードのツールを確認できる」というテストを追加し、同じ状態へ戻った時に検出できるようにしています。

この言葉が会話に出てくるとき

例えば、「期待した計算結果と、画面の数字が違う」と報告するときです。感想ではなく、ずれた点を共有します。

例えば、直したあとに「同じ操作で再発しないか」を見るときです。出たこと自体より、再現と範囲が話題になります。

勘違いしやすい点

  • 下手だから起きる: 条件の漏れ、前提の違い、環境の差でも起きます。
  • 見た目の崩れだけ: 仕様とのずれ、使いにくさ、データの不整合も対象になります。
  • 直したら終わり: なぜ起きたかと、戻らない確認が残ります。

伝えるときは、何をしたか、何を期待したか、何が起きたか、の3点があると調べやすくなります。

まとめ

  • バグ「期待・仕様と、実際の動きのずれ」
  • 原因「実装、要件、環境、変更の組み合わせなどさまざま」
  • 大切なこと「早く見つけ、原因を確かめ、再発を防ぐ」

「使いにくい」と感じた時も、ユーザーのせいとは限りません。その違和感は、製品を良くする大切な手がかりです。

次の記事では、バグの原因を調べて直す「デバッグ」について解説します。

ここまでお読みいただきありがとうございました!

不具合報告で助かる情報の型

「動きません」だけでは再現が難しく、修正判断が遅れます。問い合わせでは、OS・ブラウザ・URL・操作手順・期待と実際の差、があると一気に早くなります。

  • いつから・どのページで起きるか
  • 毎回か、時々か
  • スクショやエラー文言があれば添付

不具合は恥ずかしいものではなく、公開して使う以上つきものの差分です。再現手順が揃うほど、直す側の仮説が減ります。

QUICK CHECK

よくある質問

使いにくさもバグですか?

仕様どおり動いていても、目的を達成できないほど分かりにくければ重要な問題です。ただし実装ミス、仕様不足、改善要望は分けて記録すると、対応方法を決めやすくなります。

次に読むなら?

DEBUGの記事へ進むと、開発や通信の流れを順番に理解できます。

参考資料

用語の定義や仕様を確認するため、公式文書・標準文書を参照しています。リンク先の内容は更新される場合があります。