100点以外は0点
「上手の手から水が漏れる」という言葉があります。上手な人でも時には失敗することがある、ということですが、この言葉、システム開発では特に肝に銘じておかなければなりませんね。
システム開発の仕事は、その過程で誤りを作り込むという宿命を負っています。作り込まれているはずの誤りを発見して直していくのがテストですし、行った作業や、検証している内容が的外れでないことを押さえるためにもレビューは必要です。
ところが、特に急いでいる時などは、急いでいることを理由にして、テスト、レビューを省略することが行われます。
急がなければならない時、急いでいることが全てに優先する…という気持ちになりやすいのはよく理解できるのですが、急いでいる時の方が誤りの発生や、勘違いが起こりやすいのもまた事実です。何とかしなければいけないという気持ちが先走って、品質と期限をバーターにするのは悪魔のささやきです。
システム開発は「100点以外は0点」という宿命を負っています。皆さん、口では80%主義などといいますが、それが実現機能80%のことなら良いのですが、品質80%でしたらシステムは使い物になりません。また、作りこんだ誤りの大きさと、その誤りが起こす事件の大きさは無関係です。些細な誤りが…大事件となります。
頑張って、徹夜で、何とか間に合わせようと一所懸命働いて、しかし、その結果が大トラブルでは浮かばれません。「何とか間に合わせてくれ」と言った相手も、「トラブルを起こしてくれとは言わなかった」と冷たい態度になります。こういった頑張り方に価値は無いのです。
開発依頼者と期限優先の合意が出来ている場合、またトラブルに寛容なお客様、一定程度の誤りは本番をやりながらなおしていく…ということが許される業務なら話は別ですが、その場合でも、どんなトラブルが起こるかわからないのですから慎重にはなりますね、大きなトラブルになると、よいとは言ったがこんなトラブルは想定していないよ…、と言われる羽目になりそうです。
テスト、レビューは省略しない
結局、原則はどのような局面でも、テスト、レビューは省略しないことです。もちろん、要領よく行うよう頭を使う必要はあります。押さえなければいけないところをきちんと押さえ、最低限、そこは譲らないのがプロです。その押さえが正しいかについてレビューをしっかり行うのもプロです。万が一!万が一!省略せざるを得ない時も、リスクを評価し、省略の判断についての責任を明確化しておくことです。
誰がやっても、システム開発に伴う誤りの作り込みが発生するのは事実です。テストやレビューをしないことに伴うリスクを主張するのは恥ずかしいことではありません、責任あるプロの仕事です。そして、こうした原則、基本動作は、結局は開発依頼者、そしてお客様のためだということを忘れてはなりません。
トラブル発生時のプログラム緊急修正、緊急作業。もっとも期限が厳しい状態になります。テストが出来ない環境、条件の時もあります。どうしても人間系でのチェックだけで作業を進めなくてはならない場合が出てきます。
このような時は、是非、チェックに際して、作業をやったことのチェックだけにならないようにお願いします。チェックする人は、作業する人に、なぜ、この作業でよいのか、どこがどうなればよいのか、その根拠は、という点を説明させてその内容を吟味、判断してください。完全ではありませんが、担当者に根拠を説明させることで人間の犯しやすいミスを防止できます。経験的にはテストが出来ない時の、2重遭難を防ぐ数少ない有効策といえると思います。