SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

Data Tech 2024

2024年11月21日(木)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

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

EnterpriseZine編集部が最旬ITトピックの深層に迫る。ここでしか読めない、エンタープライズITの最新トピックをお届けします。

『EnterpriseZine Press』

2024年秋号(EnterpriseZine Press 2024 Autumn)特集「生成AI時代に考える“真のDX人材育成”──『スキル策定』『実践』2つの観点で紐解く」

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

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

第14回

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

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

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

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

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

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

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

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

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

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

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

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
開発担当者必携!トラブル削減のための原則拾七ヶ条連載記事一覧

もっと読む

この記事の著者

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

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

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/196 2007/10/26 12:00

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング