この記事を読んでいただいているということはプログラミングをやっていてもバグが原因となるエラーが大量に出たり解消されずに「もしかしたら自分には向いていないのでは」と悩んでいるのではないでしょうか。
もしてプログラマへの道を断念しようと悩んでいるのであればちょっとだけ思い止まってこの記事を最後まで読んでから判断してからでも遅くはありません。
プログラマにとってバグとは切っても切り離せない縁。ちょっとオーバーな表現をするとまるで親戚のような存在なのです。
厳密にはバグとエラーは異なりますが、本書はプログラマを志す人や、プログラマになりたての人をターゲットにしていますので、バグとエラーは同義とします。
バグが出るのは品質や実力が足りないということか
古い体質の会社だとプログラミングが終わった直後にバグが出ると「品質が悪い」、「実力が足りない」と叱られるケースもありますが、それは大きな間違いです。
プログラマとしての実力はバグの有無とは一切関係がありませんし、逆にバグを積極的に出した方がいいフェーズというのは存在します。
それを否定する古い体質の人達がいるからこそ、バグを揉み消すために勝手にプログラムを改変したり、わざと報告しないことで後々大きなトラブルになることも多いです。
単体試験ではエラーを沢山出した方がいい
単体試験とは作ったプログラムが意図したとおりに動くかをテストする最初の試験です。
このフェーズでは作ったプログラムだけで完結するバグを摘出するのが目的のため、出来るだけバグを出した方がいいです。
作りたてのプログラムなので、意図したとおりに動作することは100%有り得ません。
そもそもコンパイルが通らないことすらありますし、変なエラーメッセージは山のように出ます。
このフェーズでバグを検知しても責めるのはお門違いであり、寧ろ正常に摘出できていることに対して一定の評価を与えるべきだとすら考えています。
単体試験での品質の目標というのは配属されるプロジェクトによってルールはあるかもしれませんが、どのようなプロジェクトであっても概ね以下のような指標があります。
- テスト項目数 ≧ プログラムの行数 ÷ 5
- バグ率 ≧ テスト項目数 ÷ 10
です。
つまり1000行のプログラムを書いたとしたらテストするべき横目数は最低でも200件あり、バグは最低でも20件あるという意味です。
上記の計算式よりテスト項目数が少なかったらそれはテストの粒度が荒すぎるという意味になりますし、バグ件数が少なければ杜撰なテストをしていたと思われても仕方がありません。
品質目標に満たない場合は、リーダーやお客様が受理しないケースもあります。
このフェーズで不具合を出したことを責める人がいるのであれば、寧ろその人の方が適性がありません。そもそも単体試験という観点を完全に勘違いしています。
単体テストの目的はプロうグラムが正常に動いていることを確認することではなく、プログラムのバグを摘出することが目的になります。
総合試験ではバグを出さないようにする
単体試験ではバグを沢山出すように述べましたが、バグを限りなくゼロにしなければいけないフェーズというのがあります。
それが総合試験フェーズになります。
総合試験とは一般的にリリース直前の最終テストとしてプログラムだけではなく、ネットワークやデータの連携などシステム全体が正しく動作していることを確認するフェーズになります。
ここでバグが出るとかなり致命的になり、下手をすると損害賠償請求に発展することもあります。
総合試験をやるためには
- プログラム単体のバグを摘出する単体試験
- プログラム間の連携やデータの連携が正常に行われることを確認する結合試験
- その量フェーズで発生した不具合に対して対処を行ったときの修正試験
といった数段階の試験を行っているため、ここでバグが出るということはどこかの試験に大きな欠陥があったということになります。
そのため軽微な物であっても全てのプログラムに対して類似がないか総点検を行ったり、類似があった場合、類似があったことを報告して、その影響範囲も全て報告して修正の承諾を得るというかなり面倒な手続きが必要になります。
当然このフェーズでの修正作業は見積もりには入っていないため、修正をするとプロジェクトとして損失になりますし、エンジニアも本来の総合試験の業務とは別にプログラム修正や単体試験をもう一度やらなくてはいけなくなります。
バグは出ることが前提
プログラムを作成して、いざ各テストフェーズに入るときに、テスト設計や工程を立てている段階でテスト件数から何件バグがあるのかを事前に見積もりを立てておきます。
つまりテストをするときは「バグは出ることが前提」でスケジュールが立てられます。
これは何を意味すのかというと「バグは出て当然」ということを意味しています。
当然ながらどんなバグでも出していいわけではなく、テストのフェーズに合わせたエラーの出し方というのがあります。
メンタルが弱かったりすると「自分のバグのせいで」や「こんなに大量のバグが出ている」と落ち込んでしまう人もいます。
しかし、そういう人ほどプラスに考えてほしいです。ちゃんとテストをしたから本番稼働前に摘出出来たという考え方も出来ます。バグが確認できるのはそれだけテストが効率的に行われているということではないでしょうか。
バグを出さないエンジニアとは
エンジニアとして仕事をしていると、「あの人本番で全然バグ出さない」「いつも高品質の物を納品している」という人が必ずいます。そういう人は周りからも尊敬されますし、お客様からも高い信頼を得ることができます。
駆け出しのエンジニアからしたら雲の上の存在ではありますが、皆さんも以下のステップをしっかり理解し、実践するだけでそういうエンジニアになることができます。
バグを出さないエンジニアは存在しない
まずこれだけは理解をしておいてほしいのですが、そもそもバグを出さないエンジニアなどこの世に存在しません。
どれほど優秀なベテランであっても必ずバグは目にします。
それはプログラム行数には関係なく、四則演算のプログラムであってもです。
僅か数行のプログラムなのにバグが多発することだって日常茶飯事です。
「この1年間で単体を含めてバグが出ていません」と聞くと駆け出しのエンジニアはこの人優秀だと思いたくなる気持ちも理解できますが、我々エンジニアからしたら「バグが出ていません」ほど信頼できない言葉はありません。
まずその人のテストが杜撰だったのではないのかと疑いますし、「品質がいいですね」と言われることは100%有り得ません。
恐らく厳しいお叱りを受けることでしょう。
本当になかったら普通のエンジニアであれば物凄く不安になり、テスタや他のエンジニアに「どんな手を使ってでもバグを出せ」「何でもいいからバグを見つけろ」と指示します。
どうしても何も見つからないから、中にはLANケーブルをいきなり抜いてまでして物理的にバグを出そうとする人もいます。
最終的にバグを出さなければいい
では優秀なエンジニアはどのようにしてそこまで高品質なプログラムを書き上げることが出来るでしょうか。
その答えは、「最終的にバグを出さなければいい」という考え方を持っています。
最終的にというのは総合試験であったり、本番稼働を指します。
そして物凄い入念にテストを行っています。中にはプログラム一つを作ったらテストをするのではなく、1つの小さな処理を作ったらテスト、1つの機能を作ったらテスト、画面が表示できるようになったらテストなど何回も何回もテストをします。
そうすると最初のテストでは20個バグがあったとしても、次のテストではテスト範囲が広がったのに15個のバグだったとリアルタイムでバグを摘出しながら開発をするエンジニアもいます。
他にもバグが大量にあることを承知の上で一気にプログラムを作り上げて、最初のテストでは50個のバグがあったとしたら、それを直して次のテストでは30個、次は10個など徐々に減らしていくやり方をしているエンジニアもいます。
両方とも共通して言えるのは、いずれのケースであっても目標の品質に到達させるために何回もテストをしています。
その結果として総合試験や本番運用に耐えられる品質まで高めることができているのです。
出したバグは全て自分のノウハウにする
さらにステップアップする方法として出したバグは全て自分のノウハウにするという方法があります。
これは個人的な見解ですが、バグが出ることはラッキーなことだと考えています。
自分の実装力が弱い分野など、暫くエンジニアをやっていると自分のバグの傾向が分かってくるからです。
そのためには、
- なぜこのバグが出たのだろうか
- もしかしたら他にもこういうバグを出す人がいるかもしれない
- いざ出たらどのように対応するべきだろうか
と、自分のバグを客観的に分析する癖をつけてください。
「バグが出たから直す」は正直多少のプログラミングの知識があれば誰でも出来る作業です。
高いお金を出してエンジニアを何人も雇う必要なんてありません。
エンジニアはその豊富な経験と蓄積されたノウハウ、一つのバグに対してどれだけのアプローチ方法を知っているかといったナレッジの多さが問われます。
それが出来ずにただ機械的にバグを直しているだけのエンジニアは昇進することは不可能ですし、すぐに淘汰されていきます。
実際に自分が有責で出したバグであったとしてもそのバグを分析し、お客様に適切に報告を行い、修正とアフタケアをすることでお客様から逆に信頼を得ることが出来て更なる案件の拡大に繋がった事例も少なくありません。
まとめ
エンジニアとして仕事をする上でバグが出ない方が当然いいという考え方も理解できます。
バグが出ると仕事が増えて下手すると徹夜とかになるからバグなんて見たくないという気持ちも理解できます。
しかしバグというのはエンジニアを映し出す鏡みたいなものであり、出しているバグの傾向を見ればその人がどのようなところに重点を置いているかというのが物凄くよく分かり、どのようなところが苦手かもよく分かります。
自分で自分のことを分析するのは難しいですし、本番稼働でバグが出たことで自分のミスから目を背けたい気持ちも十分に理解できますが、「バグを出した」という事実ではなく、「なぜこのバグが出たのか」という部分を分析しないといつまでたっても進歩はしません。
どうしても気が引けてしまう場合は先輩や上司に相談してみてください。
「ここまでやったのに、バグが出てしまう。ちゃんと分析をしたい」と言えば一般的な感覚を持った人であれば必ず力になってくれますし、もしかしたら叱られることもあるかもしれませんが、的確に叱ってくれます。
そして繰り返しになりますが「バグが出るから適性がない」とは絶対に思わないでください。
少なくとも分析しようとしたり、悩んでいる時点でバグを反省しない人より適性があります。
その悩みを超えた先に更なる成長と大成は必ずあります。