【解説】不具合（バグ）とは？主な原因・種類・不具合対応

不具合(バグ)とは

不具合(バグ)とは、「プログラムやシステムの誤りや不具合、欠陥(要求された機能が実行できない状態)」のことです。
例えエラーが出ていない状態でも、仕様や要求どおりに実装されていなければ、その機能はバグとなります。

不具合(バグ)が起こる主な原因

設計ミス

設計ミスは、要件定義や設計段階での不備、考慮漏れが原因で、顧客の要求についてきちんと理解できていない場合や、調査を怠っている場合などに起こります。
例えば、設計書に変更が発生した場合、仕様をしっかり確認した上で漏れなく変更内容を設計書に反映しなければなりませんが、それらを怠っていた場合、開発すべき内容と設計書の内容が異なる事態が発生します。
また、テストケースは設計書をもとに作成するため、設計書に変更が発生すると後続のテストにも影響します。

コーディングエラー

プログラムによるバグは原因の特定が難しいものの一つです。
そのため、問題を小さく分解し、段階的に解決して効率的におこなうことが重要です。
コーディングエラーを調査する場合は主としてデバッガを使います。
デバッガを使う事で、コードの実行状況を詳しく把握し、具体的なエラーの原因を特定できます。
また、コードにコメントを追加して、各ステップが何をしているかを明確にすることも重要です。
その他にも設定したデバッグメッセージを出力して、どの部分でエラーが発生しているのかを特定します。

環境の違い

開発環境、テスト環境、本番環境など、異なる環境での動作の違いによってバグが発生することがあります。
そのため、E2Eテストでは出来るだけ本番環境に近い状態でテストをおこないます。
また、環境変数、外部サービスなどの設定の反映も忘れずにおこないます。

人為的ミス

人為的ミスは開発者や設計者のミスや、誤解によるものが大半を占めています。
特に、設計書の仕様については、顧客との認識合わせが大事になってくるため、より高いコミュニケーションが大切です。

テスト不足

テストケースを作成し、実施してもテストケース自体がシステム全体を網羅しておらず、不十分なケースだった場合、後で問題となります。
また、本番環境、テスト環境、開発環境で差異があり、開発環境やテスト環境で問題なくても本番環境でバグが見つかるケースも少なくありません。

不具合(バグ)の種類について

システム開発において、不具合(バグ)は避けられない問題であり、様々な種類が存在します。

機能バグ

機能バグは、システムが仕様どおりに動作しないバグです。
例えば、入力された値が正しい結果にならない、特定の操作を実行すると異常終了を起こす、必要な機能が実装されていない、など、ユーザーからも目に見えやすいバグが主です。
そのため、対応には仕様書に記載された内容と実際の動作を比較し、原因を探すことが必要になります。

性能バグ

性能バグは、システムの動作が遅い、メモリの使用量が大きいなど、性能面の問題が発生するバグです。
例えば、画面表示に遅延が発生する、処理に時間がかかる、メモリ使用量が異常に多い、など、ユーザーの利便性を著しく低下させるものが主です。
そのため、性能バグはシステムの処理時間を測定し、システムのアルゴリズムやデータ構造を見直すことが必要になります。

データバグ

データバグは、データが破損している、または誤ったデータが入力されているなど、データに何らかの問題が発生するバグです。
例えば、ファイルが破損して開けない、データベースに誤ったデータが登録されている、データの整合性がとれない、など、データの正確性や信頼性を損なう場合が主です。
そのため、データのバックアップや様々なデータパターンでの検証が必要です。

セキュリティバグ

セキュリティバグは、外部からの攻撃を受けやすいバグです。
例えば、パスワードや個人情報の漏洩、不正アクセスを受ける、など、システムの安全を脅かすことになります。
そのため、プログラムの脆弱性を診断し、適切な対策を講じる必要があります。

システム開発における不具合(バグ)対応

システムの不具合(バグ)対応については、インシデント管理が重要となります。
インシデント管理とは「システムやサービス利用中に発生した予期せぬ出来事（インシデント）を、検知、記録、分類、対応、解決し、システムサービスの中断を最小限に抑えることです。
インシデント管理をおこなうことにより、システム障害を含む様々な問題の迅速な解決と再発防止につながります。

障害内容の確認

システムの障害報告や検知ツールからのアラートを受けた場合は、どの程度の障害が発生したかを早急に確認しなければなりません。初動で確認をおこなうのは、障害が起きた対象、障害内容や発生事象、障害が影響する範囲、障害の再現性、障害が発生した日時などです。

システム担当者に障害の連携をおこなう

障害の内容と範囲を確認したら、あらかじめ決めておいたフローに沿って関係者や責任者に連携します。障害によって影響を及ぼしそうなユーザーに対しても早期に連絡をおこないます。
連絡の際は、障害について詳細な情報を、時間をかけて伝えるよりも、今現在分かっていることを的確に迅速に伝えることを重要視します。

障害の影響調査をおこなう

適切かつ迅速に障害対応をおこなうために、ユーザーや社内におよぶ影響を細かく調査します。
このとき、外部を含めた他のシステムに影響がないかも合わせて調査をおこなう必要があります。
また、サービスや業務に影響が出ていたり、復旧作業に時間がかかった場合は、影響を抑えるために予備のサーバーやシステムを検討します。

障害の原因究明をおこなう

障害の原因を調査するために、障害が起きたシステムの監視データやログなどを確認します。
次に検証をおこないます。原因が特定出来なければ、検証結果や過去の類似障害を交えて原因の解明を進めます。

復旧作業をおこなう

障害の原因が解明できたら、最初に暫定的な対応をおこないます。
ユーザーがシステムの利用を継続できるように、応急処置として最低限の機能を復活させるか、代わりの機能を用意します。
このタイミングでユーザーに対し、復旧の目途や代替案の利用をアナウンスします。
暫定的な対応をおこなったあとは、恒久的な復旧作業に入ります。恒久的な復旧作業を行う際は作業計画を立ててしっかり手順を定めてから進めます。

再発防止策を考える

復旧作業が完了したら、再発防止のために障害分析をおこなった上で、関係者への報告をおこないます。この時、「なぜなぜ分析」で障害の原因を分析します。
なぜなぜ分析とは、発生した問題事象の根本原因を探る分析手法です。
起こった問題に対して、それがなぜ起こったのか原因を見極め、さらにその原因に対して「なぜ」を問うことを繰り返し、直接原因だけでなく背後にある根本原因を抽出します。
報告書には障害の概要や、時系列順の障害内容、障害が業務やサービスに支障を与えた影響、暫定対応と恒久対応の内容、障害の原因・対策、再発防止策などを記載し、関係者に共有します。

不具合(バグ)に対してベンダーが考慮すべき問題

システムに不具合(バグ)などの障害が発生した場合、ベンダーは契約上の債務不履行責任や、場合によっては不法行為責任を負う可能性があります。
こうした場合、システム障害に対して「ベンダー側の責任か」「発注元の不備か」という責任の所在が不明確になることが多く、問題が長期化する原因の一つにもなります。
そのため、日頃から責任分担の明確化と透明性の高い運用体制を構築することが大切です。

おわりに

不具合について解説いたしました。