開発の現場で、いちばんショックだった出来事の話です。
総合テスト（システムテスト）のフェーズに入ってから、自分が担当したプログラムのバグを見つけました。
しかもそれは、単体テストの時点からずっと残っていたものでした。
つまり、自分のテストをすり抜けたまま、結合テストも通過していたことになります。
この一件で、仕事の見方がけっこう変わりました。
開発でミスをして落ち込んでいる人
テストの観点がうまく作れないと感じている人
未経験から開発の現場に入った人
自分の単体テストをすり抜けていた
当時、案件は総合テストのフェーズに入っていました。
そこで出たインシデントの対応をしていたときのことです。
調べている途中で、報告されていたものとは別の不具合を見つけました。
どこから出ているのかをたどっていくと、答えははっきりしていました。
単体テストが終わった時点から、ずっと残っていたものです。
単体テストも結合テストも通っていたのに、総合テストまで誰も気づいていませんでした。
誰にも怒られていないのがきつい
しかも単体テストは、自分でやったものです。
何か月も気づかれないまま、そのまま動いていたことになります。
誰かに指摘されたわけではありません。
自分で見つけたぶん、余計にきつかったです。
「ちゃんとテストしたつもりだったのにな」というやつですね。
ちなみに私は、社会人10年目で開発の経験が1年ほどしかない状態から今の現場に入っています。
なので、テストの観点を自分で組み立てた経験もほとんどありませんでした。
なぜ見逃したのか
落ち込んでいても仕方ないので、原因を考えました。
技術的に難しかったから、ではありません。
自分の担当範囲だけを見ていた
私が見ていたのは、仕様書に書かれた「この機能」だけでした。
入力を入れて、出力が想定どおりか確認する。
そこで終わりにしていたんですよね。
前の処理も、後ろの処理も見ていませんでした。
当時の私の感覚だと、それは他の人の担当なんですよね。
実際、担当は分かれています。
ただ、データはつながって流れていきます。
自分の出力が誰かの入力になる以上、そこで切ると見えないものが出てきます。
書いてあることだけを見ていた
実は、似たようなことを別の対応でもやっています。
インシデント一覧に、修正内容が1機能ぶんだけ書かれていました。
なので私は、それが対象範囲だと思い込んで着手しています。
調べてみたら、実際には2つの機能に影響していました。
書いてある情報が足りなかったのは事実です。
私はそのプログラムを作った本人でもなかったので、全体像も分かっていませんでした。
そのとき、PLに怒り口調で言ってしまった
ここは反省点です。
私はPLに「これ、一覧からは読み取れないですよね」と言ってしまいました。
言い方に、明らかに苛立ちが混ざっていたと思います。
でも、あとから考えるとどうでしょうか。
範囲を狭く見たのは、私のミスでもあるんですよね。
着手する前に一言確認すれば済んだ話です。
資料が足りないなら、足りないと分かった時点で聞けばいい。
それをせずに進めておいて、あとから資料のせいにするのは違いますよね。
この一件は、今でもわりと覚えています。
そこから、見方を変えた
やったことは単純です。
部分的に見るのをやめました。
自分の担当かどうかではなく、仕様全体としておかしくないかを見るようにしました。
実際にやっていること
バグを見つけた回では、こんな確認をしています。
- 開発した処理で、実際にデータを取り込む
- そのあとに動くバッチ処理まで流す
- 別の画面を開いて、結果がどう見えるか確認する
自分の担当範囲を出て、データが最後にどうなるかまで追いかけます。
正直、時間はかかる
テストの時間は、体感で倍近くになります。
環境の準備もいるので、単純に面倒です。
ただ、あとから直すコストのほうが確実に高いんですよね。
しかも終盤に見つかるほど、周りの時間まで奪います。
テスト工程で出た不具合は、原因の調査から始まります。
作った本人以外が調べると、そこだけで何時間もかかるんですよね。
自分の担当外の問題まで見えるようになった
見る範囲を広げたら、思わぬ副作用がありました。
自分が担当していないところの問題まで、目に入るようになったんです。
実際に見つけたもの
- 前日のデータを溜める処理に削除がなく、月末になると重くなる作りだった
- 土日は不要なデータまで毎日送っていて、処理時間を押し上げていた
- 基本設計の段階で、リリース前にデータを整えておく必要があることに気づいた
どれも、自分の担当だけ見ていたら気づけないものです。
リーダーに言われた感謝の一言
このうちのいくつかを確認しに行ったとき、こう言ってもらえました。
「そこまで見てくれていると思わなかった」
別の場面では、こうも言われています。
「設計は完璧ではないので、気になったことを確認してもらえると安心です」
この言葉は、けっこう効きました。
確認するのは、疑っているからではないんですよね。
むしろ、聞かれない設計のほうが不安なんだと思います。
自分が設計する側になったときも、これは覚えておきたいです。
同じことを、あとから入った人に説明した
しばらくして、チームに新しいメンバーが入ってきました。
異業種から転職してきて、開発の現場は初めてという方です。
システムテストのテストデータ作りで、完全に詰まっていました。
見ていると、私が最初にやっていたミスと同じことをしていました。
単体テストと同じデータでは足りない
単体テストは、その機能が仕様どおり動くかを見ます。
一方、システムテストは実際の業務の流れでデータを作る必要があります。
申請して、承認されて、締めて、連携する。
この流れに沿っていないと、そもそも後続が動きません。
「なぜ単体と同じデータではダメなのか」を説明したら、反応がかなり良かったです。
説明しながら、自分の理解も固まった
このときは、持ち歩いている小型のホワイトボードを使いました。
仕様とデータの流れを書いて、どこで何が起きるかを一緒に追いかけます。
2時間ほどかかりましたが、やってよかったです。
人に説明できないところは、自分も分かっていないんですよね。
教えるほうが勉強になる、というのは本当でした。
ミスの原因は、技術ではなかった
1年ほど同じ現場にいて、不具合の出方を見ていて思ったことがあります。
技術的に難しくて解けなかったものって、あまりなかった気がします。
難解すぎて読み解くのに時間がかかるものはありましたが。。。
多かったのはこの3つです。
- 業務や既存システムの知識が足りない
- 関係者どうしの認識がずれている
- 単純に伝わっていない
しかも、こういうミスは終盤になるほど効いてきます。
リリースが近いほど、一つの手戻りが全体を止めます。
だから、着手前に聞く回数を増やした
今は、着手する前に一度だけ確認するようにしています。
「これ、どこまでが対象ですか」
「この前提で合っていますか」
たったこれだけで、手戻りがかなり減りました。
聞くのは一瞬ですが、直すのは半日かかります。
まとめ：見逃したことより、見方を変えられたか
あのバグを見つけた日は、本当に落ち込みました。
ただ、今振り返るとあそこで見方を変えられたことのほうが大きかったです。
未経験に近い状態で開発に入ると、最初は担当範囲を守るだけで精一杯です。
それは仕方ないと思います。
ただ、少し余裕が出てきたら、範囲の外を見てみてほしいです。
そこから見つかるものは、たぶん自分の評価にもつながります。
実際、客先からの評価にも「上流の工程も任せていきたい」と書いてもらえました。
やったことは、範囲を少し広げて確認しただけです。
ちなみにこの話は、転職の面接でも使いました。
失敗の話は、そのあと何を変えたかとセットにすると通ります。
