CaseStudy 4: プロジェクトに潜む品質リスク(前編)

システム開発プロジェクトにおける品質管理は今も昔も変わらぬテーマの1つである。お客様を満足させる品質をどのように担保すれば良いのだろうか? このテーマについて以後2回の連載で解説をしていきたいと思う。

具体的には、前編でプロジェクトに潜む品質リスクにはどのようなものがあるかを定義し、後編で品質リスクを回避するためのノウハウを紹介する予定である。

品質リスクの考慮に欠けたプロジェクト事例

まずは、品質リスクが存在していたが、適切な対応をせず、プロジェクト推進に支障を来たした事例を紹介しよう。

ある企業の大規模基幹システム構築プロジェクトでの話である。要件定義工程をコンサルティング会社が担当し、設計工程以降を複数のSIベンダーが担当した。

システム開発も進みシステム間結合テストが始まったが、サブシステムAとサブシステムBを結合した一連のテストを実施した際、問題は起きた。サブシステムAからサブシステムBへあるデータが受け渡されず、サブシステムBの後続処理がストップしてしまったのである。

調査してみると、サブシステムAの要件定義を行ったときは、そのデータを作成する機能は構築予定であったが、担当ベンダーが変わったことで設計以降が漏れていたことがわかった。

なぜ、このようなことが起きたのか。それは、このプロジェクトでは、要件定義工程および設計工程といった上流工程の品質リスクを考慮した進め方が十分ではなかったのである。具体的には、"要件が漏れないよう管理する"、"各工程で要件を成果物に正確に記述する"、"成果物に対する効果的なレビューを行う"などの欠陥を未然に防ぐ活動が十分でなかった。

品質管理＝「品質の良いシステム」を作りこむための活動

品質リスクについての話を深めていく前に、品質管理に関する用語や考え方を整理しておく。

まず対象となる「品質の良いシステム」について整理しておこう。システム開発に関係する各種規約類において「品質」は以下のように定義されている。

ISO9000	本来備わっている特性の集まりが、要求事項を満たす程度
ISO25000	指定された特定の条件で利用する場合の明示的または暗示的なニーズを満たすソフトウェア製品の能力
PMBOK	一連の固有の特性が要求事項を満足している度合い

表現は異なるが「品質」とは"お客様の要求事項への適合"と解釈できる。この「品質」の定義に従うと「品質の良いシステム」とは"お客様の要件がシステム本稼働時に満されているシステム"ということになるが、もう少し整理すると【A:要件が正確に組み込まれている】システムで、かつ【B:欠陥が残っていない】システムといえるだろう。

では次に「品質の良いシステム」を作りこむための活動について整理しよう。具体的には「品質計画」、「品質保証」、「品質管理」の3つの活動を進める必要がある。

各活動の概要と実行する際の考慮すべき点は以下の通りである。

活動	活動の概要と実行時の考慮点
品質計画	プロジェクトにおける品質管理方針、品質基準、品質管理の進め方などを計画する。具体的には品質方針、品質目標、品質管理手順などを品質管理計画書としてまとめる。 品質管理計画書を作成する際に難しいのは、品質目標の定義である。一般的に、RFPでは、品質目標は明確に記述されてないことが多い。どの項目をどのレベルまで落とし込めばよいかが悩ましく、納品時に解釈の違いにより揉めそうな項目については詳細まで落とし込むべきである。
品質保証	品質保証には、各種レビューなどを行う「検証」、工程の終了が可能かどうかの最終判断を行う「審査」がある。「品質保証」で最も重要なイベントは、工程完了判定会議である。工程完了判定会議では、品質基準をクリアしているか、残課題は解決の見通しが立っているかなどを確認し、次工程へ進んでよいかの判断を行うとよい。
品質管理	品質状態をレビュー回数、レビュー時の欠陥除去数、テストカバレッジ、障害発生解決数、欠陥摘出密度などの品質指標を用いて多面的に分析・評価する。欠陥除去の観点では検出工程と除去工程を管理するとよい。検出工程と除去工程を管理することで、同一工程で欠陥が除去されたかが分かり、欠陥が後続工程に持ち越されるのを防げる。

品質リスクはどこにある?

品質リスクとは、欠陥を残存させてしまう可能性がある要因であり、要件定義～本稼働の各工程に潜んでいる。例えば、要件漏れ、要件誤解釈、設計漏れやミス、テスト漏れ、製品障害、欠陥除去漏れ、仕様変更ミス、要員のスキル不足などである。

本項では、「品質の良いシステム」作りを阻害する広い視点での品質リスク、すなわち、【A:要件が正確に組み込まれている】、【B:欠陥が残っていない】システム作りを阻害する品質リスクにについて説明していこう。

まず、『【A:要件が正確に組み込まれている】システム作りを阻害する』品質リスクであるが、システム開発において、連続性が途絶えてしまう状況を検討することで品質リスクを特定できる。工程が変わる、担当が変わる、成果物が変わるところが該当する。

工程・担当が変わるところでは、開発担当者間の誤解釈、認識不足が発生することが多い。また、成果物の種類が変わるところでは、成果物間の不整合が発生することが多い。そのため、「要件が正確に組み込まれない」状況が起こる。「・・・が変わる」ところには、品質リスクが存在することが分かる(図3参照)。

次に、『【B:欠陥が残っていない】システム作りを阻害する』品質リスクであるが、システム開発は人手による作業であり、いずれのシステム開発工程でも欠陥は混入してしまう。欠陥の混入による品質リスクの高い工程は、"システム開発工程の、どの工程で欠陥が残った場合に、欠陥除去コストが高くつくか"を検討することで特定できる。

一般的なシステム開発における欠陥の混入イメージ、欠陥の除去イメージ及び欠陥の除去に掛かるコストイメージを図で表現した (図4、5、6参照)。

欠陥は上流工程で混入する割合が多いが、上流工程で除去されるのは少なく、下流工程で除去されている。上流工程で混入した欠陥を下流工程で除去した場合のコストは、上流工程で除去した場合のコストの数十倍も掛かるのが常である。欠陥除去コストの観点から、上流工程は下流工程に比べ品質リスクが高いことが分かる。

今回は品質リスクをテーマに話を進めてきた訳だが、いかがだったろうか? 今回紹介したプロジェクト事例において、どのように品質リスクを回避すれば良かったのか。そのノウハウを次回紹介したいと思う。お楽しみに。

執筆者紹介

祖慶勉(SOKEI Tsutomu) - 日立コンサルティング シニアマネージャー

国内大手SIベンダー、国内大手航空会社の情報システム会社、外資・国内系コンサルティングファームを経て、2008年より現職。製造業、流通業、官庁のシステムを対象に、プロジェクトマネジャー、アウトソーシングコンサルティング、ITコンサルティングを数多く経験。

監修者紹介

篠昌孝(SHINO Masataka) - 日立コンサルティング ディレクター

国内最大手のファイナンシャルグループで、BPRプロジェクトや、数多くのEコマース構築プロジェクトにて、PMを歴任。2001年に外資系大手コンサルティングファームに入社、主にERP導入や、SOA技術を駆使した大規模SIプロジェクトを成功に導いた。同社のパートナー職を経て、2007年より現職。