Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

第14回 【拾四】プログラムの修正が無い場合でもデータの流れるシステムはテスト・確認を実施する。

  2007/10/26 12:00

 トラブルの原因のひとつに「手当て漏れ」があります。人間なので、担当者判断ミスはどうしても起こってしまいますが、そこをテストなどでどう防いでいくことが可能かをお話します。

「手当て漏れ」はなぜ起こるのか?

 システム開発に係るトラブルを分析していると、少なくない数、「手当て漏れ」「調査漏れ」という理由にぶつかります。システム開発にあたって、修正を必要とする既存システムを修正しなかった、とか、統計の計算方法を変えたのに、旧システムからの繰越データについて、該当項目の連続性を保つための(新計算方法に合わせた)データ移行が漏れた、とか、極端なケースでは、データを作成する上流の処理システムで改定が行われていることを知らなかったので手当てをしなかった、などというものまであります。

 こういったトラブルについて、より本質的な理由を追求していきますと、その多くが、担当者が「手当て不要」「調査不要」と判断したこと、またその結果、他担当者が「聞いていなかった、知らなかった」などということがおこった、という理由に行き着きます。

 「手当て漏れ」というからには、手当てが必要な所がどこか、具体的にドキュメント類にあたって調べている、しかし運悪く見逃した、と思うのが普通です。しかし、実際のところ、処理の塊ごとに担当者の知識だけで要不要を判断して確認をしなかった、結局その時の不要との判断に誤りがあった、ということがトラブルの原因になっていることが多く、

 また、「調査漏れ」というからには、きちんと調査対象を洗い出し、調査も隈無く行ったが、運悪く漏れたということなのではないか、と思うのですが、よくよく聞いてみると、実は調査していない、判断するための調査なのに、調査対象について要不要を判断している、そこに落とし穴があるようです。

 「聞いていなかった」についても同じようなことで、典型的には、自分のところしか見ていない。一応、考えたけれども、後続のシステムでは該当項目に対する処理が無いはずなので不要と判断し、後続システムの担当者に連絡もしなかった。などという、みなし、決め付け、思い込みが本質的な原因であることが、これまた多いのです。

 システム開発においては、作った部分については、徹底的にテストをしてその品質を高める努力が行われます。決めたことが正しかったか、決めたとおりに出来ているか、思惑通りに使えるものになっているか…など、様々な角度から検証されます。それが仕事として定義され実行されます。

 しかし、どうでしょう、いったん対象外、不要などという判断が加えられた部分、対象については、テストという工程は用意されません。対象外、不要とされたところについては、通常のシステム開発の作業において、その判断が正しかったかどうか検証、テストされることは稀なのです。

 テストというのは、作った装置としてのシステムが正しく出来ているかをテストするだけが目的ではなく、システム開発において、考えたこと、調べたこと、判断したことが正しいかどうか確認する作業でもなくてはなりません。従って、対象外、手当て不要といった判断についても、その判断に誤りがあるかもしれないので、テストで確認するのを基本としなくてはならないのです。

 最低限、一連の流れ、業務的にデータで結びついているシステムは、最小限、手を入れなくとも「手を入れないということが正しかったこと」をテストで検証しましょう。手間のかかることですが、例えば、新旧のデータを流して、結果が変わらないことを確認すればよいだけなのですから、基本動作としたいものです。



著者プロフィール

  • 菊島 靖弘(キクシマ ヤスヒロ)

    独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター(SEC) リサーチフェロー。 1975年東京海上火災保険に入社。以来30年間、損害保険、生命保険、確定拠出年金といった業務システムの開発に携わった他、東京海上日動システムズ取締役品質管理部長として、トラブル削減や、開発品質管...

バックナンバー

連載:開発担当者必携!トラブル削減のための原則拾七ヶ条

もっと読む

All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5