第97回 瑕疵担保とゲネラルプローベ

学校帰りの森陰で、僕のブログにトラバした、セーラー服のおませな子、辛いコメント忘らりょか、ソラ。こんにちは、大島雅己です。

「ものづくり」や「目標達成」の大まかな流れというのはだいたい共通していると思います。
ゴールを決めて、その具体的な内容を固めて、スケジュールを作って計画を立て、いざ取りかかる。完成近くなってきたら、出来具合を確認してみて、問題があれば手直しする、なければそのまま最後の仕上げを行う。
具体的なやりかたは千差万別でしょうが、基本的にはそんな感じになると思います。料理、プラモデル作り、資格取得、マラソン出場、家庭菜園、原稿執筆、コンクール出場、レコーディング、住宅建築、映画製作、そしてシステム開発も。

このフローの中で「出来具合を確認」する際、不具合が見つかるケースはどれぐらいあるでしょうか。
最初の計画がよくできていて、実行者がベテランであれば、不具合が出る確率はかなり小さくなりそうに思えます。
しかし、ことシステム開発について言えば、不具合は必ずあると考えた方がよいですね。どんなに入念に計画され、体制もベテラン揃い、進み具合が順調であろうとも、不具合が一つも出ないまま完成を迎えるなどというケースは考えられません(よほど単純なシステムであれば別ですが)。
ある程度の規模のシステムであれば、テストで不具合が出るのが当たり前、むしろ何も出ない方が恐ろしくて私など気が気でなくなってしまいます。不具合をどれだけ見つけられるかがテストの使命と言ってもいいぐらいです。

ブログやメールを書く時、まず一度書いて見直しますが、必ずどこかおかしな部分があります。いざ送信ボタンを押す直前にもう一度ざっと見返しますが、たいていどこかに直したい箇所が見つかります。そして送信後にあらためて自分でも再確認しますが、ここでも不備が発覚するケースは少なくありません。メールだと手遅れですがブログなら修正します。
これぐらいやっても、あとでまたさらに別のミスが出てきたりするのです。全く自分ほど信用できないものはありません。

<今日の本歌>
ザ・ドリフターズ「ドリフのズンドコ節」

Follow me!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA