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

12.6. 品質向上の手法

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

 欠陥を作らないためには、そもそも「モノ作りをしない」ことが重要である。つまり、すでに完成した高品質な製品を導入するのが一番の早道である。しかし、現実問題として、それは難しい。パッケージの導入ですら、日本においては過剰なまでのカスタマイズをするのが一般的だ。

 

 完成品に続く方法は「再利用」である。要件定義・基本設計・詳細設計・基盤方式など、過去に開発した成果の再利用を検討することは非常に重要である。さらに、どのような手法よりも、動作することが保証されたコンポーネントの再利用は有効である。

 

 ところが、システム開発における再利用は非常に難しい。再利用を前提としてものごとを進めていったとしても、実際に適用する場面において問題が発生し、結果やり直しになることが多いのである。再利用の可否を決定する観点については、次節で述べることにする。

 

 続いて効果的なのは、欠陥予防である。プロセスやルールなどを決めることで、作成している成果物の欠陥を防ぐ方法で、これらは、プロジェクト計画上、非常に重要である。

 

 最後に行うのが欠陥の除去である。欠陥の除去は、各プロセスの中で完全に終わらせることを目的として行うようにしたい。各プロセスの最終的な成果物の品質が低いと、続プロセスでの大幅な手戻りとなり、コストの超過やスケジュールの維持ができなくなる。欠陥の除去に有効なのは、開発対象に対する認識が深いメンバによる非公式なレビューである。

 

 テストの重要性はいうまでもないが、テストプロセスに入ってからの欠陥除去はコストが高くつく。さらに仕様のすべてを網羅するテストケースを作成することは、現実的に不可能である。つまり、テストプロセスの前で、どれだけの欠陥をつぶし込んでおけるかが、品質向上の鍵となる。

 

パッケージの利用

 もっとも品質が高いシステムを導入するには、すでに品質が保証されている完成品を「そのままの形で」導入することである。また、パッケージを「半製品」とみなして、不足する機能を開発した場合も、欠陥が入り込む範囲を狭めることが可能となり、必然的に信頼性は高まる。

 

 ただし、パッケージを選択する際には、デモを見たり、パッケージベンダへ問い合わせたりして、業務への適用度合いを十分に調査する必要がある。パッケージは、あくまでも「そのままの形で」利用することが前提になっているため、一般的に変更容易性が低い。カスタマイズ範囲が著しく広がってしまう場合には、通常のプログラム開発以上の工数が必要になったり、期待する性能を満たせなかったりすることがある。

 

 さらに、パッケージは動作するプラットフォーム、利用するミドルウェア、パッケージ自体のバージョンなどに強く依存するため、移植性は低い。

 

再利用

 プログラムは再利用性が低いものだという前提を改めて認識する必要がある。対象となるシステム内で共通に利用可能なプログラムを開発するケースはあるが、ほかのシステムにわたるまで共通で利用できるようなものは少ない。さまざまなシステムで共通に利用できる機能は、データベースアクセスをラッピングするようなものや、業務日付を計算するような、ごくごく単機能かつ汎用的なものに限られる。

 

 再利用性が高いプログラムは価値があるが、業務システムを開発するうえで、再利用可能なコンポーネントを開発することが重要視されているわけではない。高機能なコンポーネント開発は、本質的に非常に難しいのである。それを、業務システム開発の中で行うことには、無理がある。

 

 高機能なコンポーネント開発が難しいのには、いくつかの理由がある。まず、ビジネスの変化のスピードが速いことが挙げられる。業務システムの保守や二次開発により、改修対象となるものが、ビジネスモデルに関わる機能である。ビジネスレベルでのコンポーネント化は再利用性が低いのである。

 

 業務システム開発の中でコンポーネント化を行うこと自体にも無理がある。決められた機能を開発するのと、再利用可能なコンポーネントを開発するのは、異なる観点を必要とするからである。

 

 業務システムでは、なんらかのビジネス上のテーマを解決するためにプログラムを開発する。しかし、再利用性を考慮してコンポーネント開発を行うには、「ビジネス上のテーマを解決」すると同時に、「なんらかの類似したテーマを解決するための拡張」を行わなければならないのである。汎用的な要件を決めて仕様化していくことや、汎用的に利用できるかどうかをテストすることが非常に難しい。結局、業務システム開発を行う中で高機能なコンポーネントまでを開発するのは、現実的ではない。

 

 仮に、高機能なコンポーネントがすでに存在したとしても、業務システム開発で再利用を決定するためには、さらなる考慮点がある。

 

 それは、再利用の可否判断を行ううえで必要なドキュメントが十分に残されているかどうかである。可否判断を行うために、ソースコードを調査し、テストを行うのは現実的ではない。適用可否を判断できるだけのドキュメントが必要である。しかし、現状において、システムの保守に十分なドキュメントが残されている場合はほとんどないことを前提にすれば、判断材料はないに等しいのが現実である。

 

 さらに、汎用的に作られたプログラムを再利用する場合には、「そのままの形で」使うことが前提となる。汎用的な機能を持つプログラムは複雑なものが多く、改修するためのコストがかかり、バグの混入を生みやすい。そのままの形で再利用が不可能であれば、最初から対象システムの要件や仕様にマッチしたものを開発するほうが、高い生産性で高品質のものの開発が可能である。

 

 しかし、プログラムのみならず、類似の要件、類似の実現方式、類似の設計など、再利用性の高いノウハウは過去のプロジェクトの中に存在していることが多い。特にシステム設計やアーキテクチャに関する要素は再利用性が高く、ノウハウの集約が可能であり、それらは過去にきちんと動作した実績を持つものである。プログラム開発に近い要素では、デザインパターンがある。デザインパターンは、実装から研究されてまとめられた再利用性が高く、有効性が証明されたノウハウである。

 

 このように、再利用が現実的な要素を取り入れることで、システム開発におけるリスクのひとつである「新規性」の排除が可能になり、品質を高く保った状態でのシステム開発が可能になる。

 

欠陥予防

 品質の向上に一番効果が大きいものは、欠陥の予防である。「品質は作り込まれるものである」という言葉のとおり、最初から欠陥が入り込まないための対策を講じる必要がある。

 

 プロジェクト全体を見渡した場合には、

 

  • 作業標準化(第6章)
  • WBS、WBS辞書の整備(第10章)
  • 変更管理や意思決定プロセスのルール化(第13章)
  • 定期的なリスク分析(第11章)

 

などが、欠陥予防策として有効である。

 

 基本設計プロセスであれば、要件仕様書の各項目が基本設計書に反映されているかをチェックすることが欠陥の予防につながる。プログラミングプロセスであれば、共通モジュールの利用や、コーディングのガイドライン、ソースコードの複雑度調査などが有効に働く。このように、各プロセスの作業内容が異なるため、それぞれのプロセスで効果のある対策を事前に計画しておく必要がある。

 

欠陥除去

 欠陥の予防に続いて効果が期待されるものは、欠陥を除去することである。いかにして欠陥除去率を高めるかが、大きなポイントであることは言うまでもない。

 

 欠陥除去の手法には、レビューとテストがある。テストの必要性と効果については、もはや言うまでもないだろう。適切なレビューを行うことで、テストで検出される欠陥を減らし、テストプロセスをスムーズに進めることが重要なポイントになる。

 

 レビューは、公式なものと、一般的にインスペクションと呼ばれる非公式なものに分類されるが、ここでは両者を区別せず、単に「レビュー」と包括して呼ぶことにする。公式なレビューでは品質を高めることは難しい。しかし、非公式なレビューと公式なレビューの目的を明確にしたうえで、効果的なレビューのやり方をすることで、品質を向上させることは可能である。

 

 重箱の隅をつつくようなレビュー経験しかない技術者にとっては、成果物に対する指摘をされるのが嫌だったり、自分の担当したところは誰かに言われるまでもなく責任を持って取り組んでいるという自負があったりする。第一に取り組むべきことは、レビューの意義と役割を明確にし、技術者が的確なレビューを受ける恩恵を感じることができる文化の創造である。

 

 レビューは、手戻りを最小限に抑える効果が高い。各プロセスで的確なレビューを行うことにより、

 

  • 欠陥をそのプロセスで確実に検出できる
  • 後のプロセスで同様の欠陥を回避できる
  • 欠陥が発生した原因を把握することで、プロセスの改善点を明確化できる

 

などの効果を持つ。すなわち、欠陥を後のプロセスまで潜在させず、プロセスが後になればなるほど、莫大になる手戻りによる修正のコストを減せるのである。

 

 レビューは、第三者による成果物の評価である。成果物を第三者が評価することで、レビュー参加者全員が、「第三者が理解するためには、どのように成果物を作成すればよいか」や、「レビュー対象となった成果物をどのようなポイントで作成すべきなのか」について、共通の認識を持つことができる。*1

 

 テストでは、テスト仕様に対するプログラムの結果が正しいことしか確認できない。結合テストやシステムテストプロセスでは、最初の画面が動作しないと次の画面のテストができないなどの順序性を必要とする。そして、プログラムの挙動により欠陥が発見される。その挙動から欠陥箇所の調査と特定を行い、修正していくものである。テストの一番の欠点は、100%の網羅性を持つことが不可能な点である。一般的には、カバレッジアナライザを使用しない限り、単体テストのパスカバレッジは60%を超えないといわれている。複雑度の高いプログラムのカバレッジ率はさらに下回る。

 

 レビューでは、設計書・テスト計画書・テスト仕様など、プロジェクトの成果物となるドキュメントの正確性を確認することができる。そして、レビューには順序性は必ずしも必要ではない。最初の画面機能の設計書が完成していなくても、その次に動作する画面の設計書をレビューすることができる。そして、レビューは、そもそもの欠陥を直接発見することができる。さらに、レビューはプログラムですら、網羅的なチェックが可能である。さらに、レビュー対象のドキュメントのみをレビューするのではなく、前プロセスの成果物と比較するレビューを行うことで、正確性や一貫性が保たれているかについても確認を行うことができる。

 

 レビューで一番チェックができるのは画面と帳票の外部設計である。なぜなら、これらの設計書は、システム開発については素人だが業務に関してはプロであるエンドユーザの方々にとっては、「見ればなんとなくわかるモノ」だからである。もちろん、システムよりの細かい点、例えばデータ型などについては尋ねても無駄である。

 

 このように、レビューはシステム全体に対して、網羅的に欠陥を除去することが可能であり、欠陥除去の効率が非常に高い。ただし、前述した通り、正式なレビューに効果が期待できない現状では、チームリーダを中心とした非公式なレビューによる欠陥除去が望まれる。レビュータイミングをプロセス終了時に限定せず、短いサイクルによる短時間のレビューを繰り返すことにより、欠陥を作り込まないようにプロジェクトを進めていくことが重要である。

 

 公式なレビューでは品質を高めることは困難である。しかし、非公式なレビューと公式なレビューの目的を明確にしたうえで、効果的なレビューのやり方をすることで、品質を向上させることは可能である。

 

 テストは個々のテスト担当者が並行して行うが、レビューは関係者が一堂に会して行うため、どこでどのような欠陥が発生したかについて、関係者全員の共通認識とすることができる。ただし、テストの各プロセスの最初と最後には必ず、それぞれ「○○テスト設計書」と「○○テスト報告書」の「レビュー」を実施するので、テストに対する目的意識の共通化を図ることができる。

 


*1 担当者同士のレビューでは、成果物作成のポイントや品質を均一化する上では有効だが、担当者以外の第三者が理解するためのポイントは整理できない。詳細は「12.7 品質は作り込まれる」に後述するが、現在では担当者以外の第三者を交えたレビューの効果は、さほど期待できるものではない。
シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

12.6. 品質向上の手法 ハッピィ・エンジニアリング関連ページ

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

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