【やらかすとマジでツライ】エンジニアの失敗談語ります【再防あり】
エンジニアを目指している方、エンジニアの方：
エンジニアとして仕事をするにあたり、仕事で失敗したくないな。
なのでエンジニアの失敗談を知りたいなぁ。
今回はこのような悩みに対して解説致します。
これまで複数回の流出不具合を経験。また、テスト工程で見つけられた不具合も多々あり。
これら苦い経験を糧に、日々開発業務を行っている。
【やらかすとマジでツライ】エンジニアの失敗談語ります【再防あり】
自分のいくつかあるうちの代表的！？なやらかし事例を赤裸々に語っていきます。
- ろくに設計せず、修正⇔再検証を繰り返してしまった
- 新規機能実装を後回しにして、納期ギリギリとなってしまった
- よりよってテストケース漏れした箇所がバグってた
ろくに設計せず、修正⇔再検証を繰り返してしまった
最初から計画が破綻していたプロジェクトにて、とにかく機能実装をすべく、コードを書きまくっていました。
そして、自分が書いたコードを、テスターがテストして、意図通りに動作するかを検証してくれたのですが、これがことごとくNG。
なぜなら、設計をあまりせず、コード作ってしまっていたから。
- テスターも途中から飽きれてしまい、
- どうせ動かしてもNGなんでしょ
- もうちょっとしっかりしたソフトを作ってくれよ
そんな心の声が聞こえてきたのは、なんとかコードが一通り作り終わった後のことでした。
このように、作成者が適当な仕事をすると、テスターに迷惑がかかってしまうことを身をもって経験しました。
一部の天才エンジニアなら、アタマの中で設計しながらコードを書けるかもしれませんが、自分のような普通のエンジニアだとそれが難しく、おそらくそのような方ってたくさんいるので、まずは設計をきちんとしましょう。
もちろん、開発日程が押していて、時間がないことはわかってます。
なので、完璧な設計書を揃える必要はありません。
例えば、
- 概要レベルのフローチャート
- 状態遷移図
これだけでも書くことで、これから実装しようとしている機能の情報整理ができ、いきなりコードを書くよりも遥かに質の高いコーディングをすることが
できるのではないでしょうか。
なぜなら、今回のように、そもそも動かないコードをテスターに渡してしまうと、テスター自身の作業計画も狂うと共に、テスターも精神的にツライからです。
なので、心構えとしては、
- コード作成者が最低限の動作まで検証
- テスターは、改めて正常動作を確認後、代替、異常ケースを中心にみていく
こんな感じでいいのかなと。
また、もしこれらをやる余裕がない場合は、
時間がなくて自身で最低限の動作を見る暇がないのなら、これをすればよいかと。
新規機能実装を後回しにして、納期ギリギリとなってしまった
いくつかの機能を実装する必要があったが、
- 最後に新規機能の実装を開始
- 想定より大きい内容であることに気づく
- 慌てて作業、まわりも巻き込む
- なんとか機能実装
ということがありました。これだとだめですよね。
なぜなら、簡単だったり、変更量が少ない機能から実装を開始してしまっているからです。
なので、作業開始前に、
- 今回実装する機能の洗い出し
- 各機能について、どのような手順を踏めばそれが実現されるのか
- その手順を踏むには、どのようなコードを組めばよいか
これらを概要レベルでもよいので行うことで、ある程度の作業ボリュームを見積もっておくとよいのかなと。
よりよってテストケース漏れした箇所がバグってた
関数単位で行う単体テストのテスト仕様について、
- テストパターン作成者がテスト仕様作成
- 自分がそれをチェック
と、いう分担で作業したのだが、あまりにミスや間違いが多くて、何回も修正依頼していました。
何回かの修正を繰り返した後、「もうこのくらいでいいかな」ってとこでOKを出し、単体テスト終了したのだが、その後その関数に不具合があることが発覚。
内容としては、当該部分のテストパターンが漏れていました。
なので、その際、単体テスト仕様の妥当性を問われてしまいました。
なぜなら、その不具合は、単体テストをやっていれば一発で気づけるレベルの内容だったためです。
なので、チェックした結果があまりにひどい場合は、途中でチェックをやめ、全部やり直しを依頼したほうがよいと感じました。
今回は、丁寧に修正してほしい箇所を特定、修正依頼を繰り返したため、それでも間違いが多くて、結果としてパターン漏れをしてしまったので。
当たり前のことを当たり前にやることで、不具合を防ごう
これまで、自分がエンジニアとして経験した苦い経験をベースに、その内容と対策を解説してきましたが、これらを教訓にすると共に、当たり前のことを当たり前にやることで、不具合を防ぎましょう。
なぜなら、不具合やバグというのは、「ゼロ」にするのは不可能だからです。
考える場面で、すべてのパターンを網羅したテストを行うのは不可能なので。
なので、当たり前のことを当たり前にやることで、不具合の発生を抑える必要があります。
当たり前のことがなんであるかを再認識する
不具合の当事者を端から見ていると、「なんでこうしているんだろう」とか、「なんでこんなことやってんの」って
思うことってありますよね。
それは、自分がその不具合に関わっていないからこそ思うことです。テンパってないので。
これが自分のことだとどうなるでしょう。
- そもそも不具合が出て焦る
- やることも多くなる
と、いう感じで、目の前の作業しか見えなくなるし、正常は判断もできなくなる恐れがあります。
そのため、
- 計画を立てる
- 困りごとを相談する
- 社内のプロセスや約束事に沿って作業する
などの、当たり前のことができなくなってしまいます。
なので、「当たり前のことを当たり前に」やる必要があるのです。
本来のセオリーや社内の約束事、一度再確認して、作業をするようにしましょう。
ということで開発作業をしましょう
と、いうことで、自身の苦い経験をベースに、その内容と対策を赤裸々に語ってみました。みんなこうなりたくないですよね？
なので、ここで解説したことを自分事にとらえ、自分のような失敗をしないようにしていきましょう。
今回は以上です。