どうしてバグを発生させてしまうのか。

  • このエントリーをはてなブックマークに追加

システム開発をしていると必ずバグが発生します。
人間がやっている作業なのだから当然と言えば当然ですが、許されるものではありません。

「ちゃんと確認をしているの?」「テストした?」

あまりにバグが多いとこういった物言いで上司や先輩から問い詰められた経験のあるエンジニアも多いのではないでしょうか?エンジニア本人にとってみると確認した「つもり」なのですが、どうして気が付かなかったのだろう、というバグが発生するものです。

システムのテストをしたことのある方なら分かると思うのですが、たいてい初回のテストではかなりのバグがボロボロと発生したりします。確認をしていて「どうしてエンジニアってこんなにミスが多いの?」と疑問に思った経験のある方もいらっしゃるかと思います。

例えば文章を打つ時にタイプミスをすることは誰にでもあると思いますが、これをプログラムでやると一文字の打ち間違いが大きなバグになったりするのです。プログラムというのは同じミスでも表面的に現れる影響力が大きいのです。

だからこそきちんと認識して慎重に開発作業をしないといけないとは思うのですが、多くのエンジニアがバグを生んでしまうのです。ではどうしてそういう事になってしまうのでしょうか。

今回は自戒の念も込めてバグを発生させる過程をきちんと考え直してみたいと思います。

 

そもそも実行確認していない。

一番ポピュラーな原因なのではないかと思います。

プログラムのロジック上で修正したのを確認して安心しているケースです。
入力するテストデータや操作の手順が少し面倒な場合、修正だけをして大丈夫であろうと判断してしまい、ちゃんと実行しないで作業を完了してしまうのです。

これは言い訳かもしれませんが、沢山のバグ修正や開発作業が納期という制約の中であると、確認作業というのが非常に手間になります。この手間を怠ってしまうエンジニアが多いのです。
ですので、これをサポートするためにテストをする第三者は必須なのです。
間違ってもエンジニアの確認だけでそのままシステムを納品してしまうことがないように、企業であれば体制を整えたいものです。

 

影響範囲の確認をしていない。

これはバグを修正した時に新たなバグを生んでしまうようなケースです。
目の前のバグを修正して他の部分に影響が出てしまう、もしくは触ってはいけない場所を触ってしまい新たなバグを生んでしまうのです。

確認すれば良い話なのですが、本人は無意識なので確認しようがなく第三者に発見されるのです。

エンジニアのよく言うセリフのひとつに「そこは何も触ってないんで」というものがあります。
これはバグが発生した時に、触ってない箇所だから問題はないはず!という意味で使われます。

蓋を開けてみると「触ってない」のではなくて実は「影響がない触り方をした」という場合が結構あり、その影響ない触り方がバグを引き起こしていたりするのです。

 

関係のないサイトなどを見ていて集中していない。

これも多いと思います。
人間集中力は続きませんからしょうがないと言えばしょうがないのですが、長期的なプログラミングになると少し進めて、SNSやネットサーフィンを楽しんでまた作業に戻る、という感じで作業をする方も多いのではないでしょうか。

ミスした時のお叱りとして「集中してないからミスをするんだ!」なんていうことを耳にすることもありますが確かにその通りで、切りの良いところまで集中しないで中途半端な状態で異なることに神経を集中させると、本当はやらなくてはいけなかった作業を忘れて飛ばしてしまうということが起きてしまうのです。

 

クライアントと対面しないことによる緊張感の欠落。

本番などで大バグをやらかしてしまった経験のある方なら分かると思いますが、脂汗をかくようなミスをした後は人間非常に慎重になりますので、同じようなバグを起こすようなことは稀です。
(逆にテンパって作業して新しいバグを連鎖的に発生させてしまい、滅茶苦茶になってしまう方もいらっしゃるかとは思いますが。。)

多くのエンジニアというのは管理する役目の人、ディレクターなどがクライアントとの間に入るので、バグなどもクレームもディレクターが受けて謝罪をします。

そういう意味で緊張感がなくなっているので、気の緩みからケアレスミスが発生するのも事実です。
ふざけたテストデータを掲載したままクライアントにシステムの確認を依頼してしまうようなことも緊張感の欠如からくるものだと思います。

同じバグを起こしても社内で注意されるより、クライアントに直接怒鳴りつけられたりし他方が緊張感は否が応でも上がり、今後同じ目には二度と合わないようにするものです。
どういうことをするとクレームになり怒られるというのを身を持って経験することで、同じ過ちを起こさないことにも繋がるので、もしバグなどでクライアントに謝罪しないといけない場合は、作業した本人もきちんと同行させる、というのも教育のひとつではないかと思っています。

====

「なんでバグを起こしちゃうの??」ということに分析をして答えるとするとこんなところかと思います。

とはいえ、エンジニア一人に色々な完璧さを求めるのは現実的ではなく、きちんと検品をする第三者の存在は必要不可欠です。小規模な会社でテスターという専任者を設けられない場合は、ディレクターにもそこそこのテストに対しての知識があると良いのではないかと思います。

執筆者:高本

株式会社8bit 取締役の高本です。 社内のWebサービス企画、プログラミングや、売上・請求管理にいたるまで幅広く担当しております。

関連記事

プログラミング

【PHP8】関数を作るときにしっかりと型宣言をするお話

目次1 天国でもあり地獄のようなPHPの変数事情2 関数も型宣言する時代 天国でもあり地獄のようなPHPの変数事情 PHPは昔から良くも悪くも変数の型に対して寛容でした。 いきなり型宣言をせずに使えますし、なんなら $hoge .= “宣言しなくても追加”; ですら怒られないくらいでした。 ただ、PHP5あたりからうっすらとまずいよねってことになり、PHP5系では非推奨、PHP8以降になると、warningとしてしっかりとアラートが出るようになりました […]

プログラミング

【PHP】古いWordPressで絵文字を使えるようにするお話

WordPressはLAMP環境で動くCMSとして昔から有名ですが、昔から使われているサイトの場合、絵文字が使えないことがあります。 今回はそういう場合の絵文字を使えるようにしてみましょう 目次1 MySQLのバージョンを調べる2 テーブルの照合順序を変更する3 最近の事情 MySQLのバージョンを調べる 使えるようにしましょうといいつつ、実は大前提があります。 それはMySQLのバージョンが5.5以降であることです。 それ未満のバージョンは「utf8mb4」にできないため、 […]

Webサイト制作

【さくらのレンタルサーバー】環境ごとにPHPのバージョンを変更するお話

最近何かとAI関係で話題の「さくらインターネット」ですが、レンタルサーバーはコスパもよく、かなり使いやすいサービスだと思います。 特にWordPressなどのLAMP環境に最適化された環境であり、PHPもいろいろなバージョンを選ぶことができます。 変更方法も簡単でコンパネからボタン一つでできるので楽ちんですね。 ただ当然なのですがマルチドメインで運用している場合もすべての環境にPHPのバージョンが一斉に反映されてしまいます。 それはそれで便利なのですが、例えばこの環境のみバー […]

株式会社8bit (エイトビット)

東京都目黒区でWebサイト制作、Webシステム開発などを行っております。
コーポレートサイトやWebサービスの企画・提案を得意としており、自社での経験を元にアイデアをカタチにするお手伝いをさせていただいております。

Web制作に関するご相談はお気軽にどうぞ

弊社に制作をご依頼いただく際の費用感をご確認いただける、
見積りシミュレーションをご用意いたしました。