このエントリーをはてなブックマークに追加LINEで送る

12.5. 欠陥とは何か?

ハッピィ・エンジニアリング表紙

 品質向上のために重要なのは、欠陥を作らないことである。ソフトウェアは論理的なものであるため、欠陥が目に見える形になるのは開発したプログラムを動作させてからである。しかし、それ以前のプロセスから生まれた欠陥が、後のプロセスにおいて徐々に顕在化していくことは事実であり、欠陥を作らないように意識して開発することが重要であるのはいうまでもない。

 

 欠陥を作らないためには、システム開発における欠陥とは何かをあらかじめ認識しておかなければならない。欠陥は、以下のようなパターンに分類される。

 

  • 欠落の誤り
  • 規定の誤り
  • あいまい性の誤り

 

 欠落の誤りとは、必要な機能が欠落していたということである。これは、要件定義や設計、テストにおいて発生する。要件定義や設計では、ユーザから明示的に要求されなかったものが欠落することが多い。テストにおいては「テストケースの漏れ」として発生する。
 規定の誤りとは、仕様としたものが誤っていたということである。もうひとつのパターンとしては、欠陥が発見され修正を行ったが、それが誤修正であったということである。

 

 あいまい性の誤りとは、記述に対する明確性の欠如による誤りである。これらは、作成者本人から第三者に情報が引き継がれた後で、第三者の解釈によって誤りとして発生する。

 

 これらの誤りを作り込まないために、どのように開発していくか、ということが品質向上のポイントである。

 

設計における欠陥

 設計における欠陥は、以下の4つに分類することができる。

 

  1. 実行機能の欠落
  2. 機能設定、起動、終了、管理
  3. データの欠陥
  4. アプリケーション構造と処理方式

 

 実行機能が欠落する原因の多くは、要件定義されていない場合に頻繁に発生している。つまり、要件定義プロセスの成果物品質が高まれば、その多くは解消されるはずである。前述したように、ユーザからの明示的な要求事項でないものは、機能として欠落してしまう場合が多い。実行機能の欠落を防止するには、「業務の常識」を知っていて、「行間が読める」人間がSIベンダや開発者にはいないという前提で、要件定義プロセスを見直すことが必要である。

 

 システムの機能設定・起動・終了や、それらの管理という面での欠陥も非常に多い。最近ではフィールドテストが省略されるプロジェクトが多く、初期のシステムトラブルにおけるシステムの再起動などで発覚する場合が多い。必然的に、トラブルからのシステム復旧に必要な時間が増えてしまう。

 

 本来は、いくら遅くとも、システムテストにおいて発見されるべきことである。個々の分割された機能を開発し、システムテストにおいては疑似的な環境で段階的にテストされるため気がつかず、基盤構築時においても、段階的なテストを行った状態でシステムをリリースしてしまう。

 

 これらを根本的に解決するには、システムの実行環境や運用設計を十分に行った上で、それらをアプリケーション開発に的確に反映させていくプロセスが重要である。

 

 データの欠陥については、厄介な問題が内在している。テストデータと本番データの想定の差異によって、システムの運用が開始されてからのトラブルと改修という結果を生んでいる。システム開発者は、常に本番データの想定が不十分である。

 

 例えば、データの記述という問題がある。電話番号の市外局番・局番・番号を分解するためのスペースやハイフンなどの区切り文字への想定、あるいは移行するデータに多くのゴミやメモが含まれている場合など、「ありがちな想定」を怠っている場合が多い。

 

 しかし、その半面で、システム開発者にデータの想定を期待するのが難しいものもある。実際の業務において、どのようなデータが入力され、利用されているかを想定することは難しい。ユーザ企業のシステム担当者も、自社のセキュリティポリシをふまえた上で、本番データを適切にマスクして提供し、データ設計とシステムテストの精度を向上させる工夫が必要だろう。

 

 データの関連性は非常に重要である。システムのトラブルは改修によりどうにかできるが、重要なデータは半永久的に利用され、さらに間違ったデータは業務の障害になる。邪魔なだけではなく、業務にミスを生みかねない。

 

 運用に入ってから問題になるのは、マスタとなるデータを変更した場合である。マスタとなるデータが変更された場合に、そのマスタを参照しているデータ自体を変更しなければならないのか、あるいは過去のデータのまま保存しておかなければならないのかを十分に考慮することが重要である。

 

 また、データの重複は、システムの性能に影響を与えるばかりでなく、データが変更された場合には、システムが正しいデータと間違ったデータの2つを持ってしまうことにもつながる。

 

 データベースもプログラムと同様に、「作れば動く」ものではあるが、データのライフサイクルは、プログラムのライフサイクルよりもはるかに長く、プログラムの改修のように簡単には直せないという前提で十分な考慮が必要である。

 

 アプリケーション構造は、プログラムの欠陥を生む原因となる。つまり、設計の正しさは、単に「システムが動作すればよい」という前提に立つものではないことを意味する。システムの設計が簡潔であればあるほど、プログラム構造や個々のプログラムが単純になり、欠陥が含まれる可能性が低くなる。システム設計者には、複雑な機能を持つシステムをどれだけ簡潔に設計するかという課題が与えられている。

 

 処理方式も、設計者に与えられた課題のひとつである。日本のシステムにおける例は、システムが持つバッチ処理の多さに代表される。バッチ処理で、個々の機能は単純化されるが、それぞれのバッチ処理をどのように制御するかが非常に複雑になる。保守の面でも、大規模なシステムのバッチ処理はかなり厄介である。さらに、少しずつ並行処理すれば、短時間で終了するものが、システムのユーザ運用が終了した時間から、大量のデータを一気に処理することになり、夜間のバッチ処理時間が問題になってくる。バッチ処理の
性能を簡単に改善するには、より高速に処理できるハードウェアの導入を余儀なくされる場合が多い。

 

 さらに、バッチ処理は他システムとの連携処理を実現するうえで実装される場合がほとんどである。古くからの温泉旅館が渡り廊下で巡らされ、迷路のような状態になるのと同様に、個々のシステムがどのように依存関係を持っているかが不明確になる。ひとつのシステム障害が与える影響が、多数のシステムに及んでいく。

 

 「4.6.速い、安い、うまい」の「 部品化、再利用」に記載したように、個々のシステムの依存性を低下させていくための取り組みと合わせ、個々のシステムの依存性や処理能力を考慮した処理方式を採用することが、設計における重要なポイントである。

 

プログラム開発における欠陥

 プログラム開発における欠陥は、「バグ」である。バグを生む要素の多くは、以下の3つに分類される。

 

  • 上流プロセスでの成果物の欠陥
  • プログラム設計の省略
  • 誤修正

 

 きちんとプログラム設計を行い、レビューすることで防げる問題は多い。特に、仕様にマッチしないプログラムを生み、それを修正するコストは大幅に減少させられる。これを防止するには、チームリーダが見た目だけの進捗を計上するために、「書類はいいから着手しろ」とか、仕様が決まっていない機能を「わかっている範囲でいいから作り始めろ」という指示をしないことである。さらには、開発者自身が「時間がないから」という理由でプログラム設計の省略を求めた場合に、それを容認しないことである。

 

 プログラム設計をきちんとしていれば、コーディング時に考える要素が大幅に減り、コーディング自体が「作業的なもの」に近づくのである。「作業的なもの」になっていれば、必然的に開発に必要な時間は省略される。プログラミングにおいて、作って、動かして、直して、を繰り返し、作られた機能が正しいものかを検証できないようなやり方は、リーダ・開発者ともに容認しないことだ。

 

 もうひとつの頭の痛い問題は、誤修正である。プログラムの改修において、5〜20%は誤修正となるといわれている。バグを修正しようとして、新しいバグを作り込んでしまう。これをすべて防止することは困難だが、プログラムの構造を単純にすることで、かなりの誤修正を防止できる。

 

 開発したプログラムのサイクロマティック複雑度を取得し、評価しながら開発を進めていくやり方は、プログラム構造を単純にするために有効である。なぜなら、サイクロマティック複雑度を計測するフリーソフトウェアは数多くあり、また評価が簡単だからである。

 

 サイクロマティック複雑度は、その数値が増えるほどプログラムの欠陥が増えていくという統計的な相関関係を持つ。一般的な指標として、複雑度が10以下のものは保守可能な許容範囲として認められている。しかし、複雑度があまりにも高いものは、欠陥が潜在している可能性が高い上に、保守が限りなく困難である。つまり、開発コストを増やすばかりでなく、保守におけるリスクを高める結果となるのである。

 

 複雑度の高いプログラムの保守においては、無理にプログラムを改修するよりも、プログラム構造を見直して最初から作り直したほうが、工数が少なくて済む場合が多い。ただし、複雑度の高いソースプログラムのリバースエンジニアリングが困難であることを考慮すれば、最初から作り直すことができるのも、正確に記載された設計書が残っている場合に限られる。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

12.5. 欠陥とは何か? ハッピィ・エンジニアリング関連ページ

12.1. 品質とは何か?
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.2. テストのプロセス区分
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.3. 現状のシステム品質
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.4. 品質低下の根本要因
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.6. 品質向上の手法
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
12.7. 品質は作り込まれる
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング