DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

ここのところ「マンションの傾き問題」が世間をにぎわせていますが、システム開発の現場でも同じような品質問題が潜んでおり、決して対岸の火事といえるものではありません。品質データの改ざん、下請け構造による品質責任の所在不明確、コスト削減・納期厳守の現場プレッシャー・・・どれも聞いたことのあるキーワードばかりですね。

このような業界の構造的ともいえる品質問題は、現場任せにしていては決して解決することはありません。システム開発を行う組織の中で、そのような品質問題に客観的な立場で取り組む役割を担うのが品質保証部門です。。。

【　品質保証部門とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
品質保証部門は、Quality Assurance（品質保証）の頭文字をとってＱＡ部門と呼ばれたり、システムをリリースする前の出荷検査を行うことから検査部門と呼ばれたり、それぞれの組織によって、呼び方や役割はさまざまです。ISO9000の品質マネジメントシステム（QMS：Quality Management System）の維持を主目的としている場合もあります。いずれにせよ、実際にシステム構築を担う開発部門とは独立した第三者機関として、品質を確保することを目的とした組織です。（※１）

私がシステム開発の仕事に携わるようになって、最初に品質保証部門と接したのは、プロジェクトの終盤ともいえる、システムテストの頃です。われわれ開発部門のメンバーが、毎日夜遅くまでバグ対策とテストケース消化に追われているかたわらで、突然普段見かけない人たちが現れ、われわれの作った設計書を眺めたり、まだテスト中のシステムを勝手に操作したりしていました。

まだ一担当者にすぎなかった私としては、お客様でもない、その見知らぬ人たちが何ものなのかわからず、少し気にはなりましたが、テストケース消化とバグ対策を優先して、やりすごしていました。しかし、設計書の記載内容やシステムの動きについて、たまに質問されるようになったり、だんだん煙たく感じるようになってきたのです。

そして、われわれのテストも終盤を迎えるころ、「検査結果報告書」なるものが提出されました。品質保証部門から提出されたその文書の表紙には、以下のような衝撃的な内容が記載されていたのです！

＜　××システム　製品検査結果報告書　＞

１．検査結果：「不合格」

２．ＱＡ指摘件数：５０件

３．品質向上によるバグ摘出要求件数：５００件（QA指摘件数の１０倍）

（　件数などの数字はサンプルです　）

それは、まるで半沢直樹の名ゼリフ「やられたらやりかえす。倍返しだ！」のごとく、品質保証部門が摘出したバグ件数の１０倍ものバグ摘出、つまり、「１０倍返し」を要求しているというものでした！（※２）（※３）

システムテストも終盤で、われわれとしては、そろそろテストはやりきったかなと思い始めた時期にそんな要求をされ、その要求が満たされない場合には、お客様に納品できない、つまり、お客様の受け入れテストに進めないという厳しい内容です。

われわれ開発部門としても、黙ってそれを受け入れるわけにはいきません。まずは、少しでもバグ摘出要求件数を減らすために、品質保証部門により摘出されたバグの内容を精査します。たとえば、設計書とは違う動作をするが設計書の方が誤っているのでバグでは無いとか、システムテストで開発部門も検知していたバグであるためＱＡ指摘件数から除外するとか、確かにバグではあるが業務への影響度は低い（ランクが低い）とか、開発部門側の見解として、様々な理由をつけてバグの件数を減らしにかかります。

それでも、要求件数がゼロにならなければ、その要求件数を目標にして、開発部門側は品質向上を実施することになります。基本的には、品質保証部門が摘出したバグの類似見直し（横展開）により、同種の残存バグが無いかを確認します。その結果、要求件数には満たなくても、開発部門としてはこれだけ見直したというエビデンスを品質保証部門に提示すると、品質保証部門は再検査を実施します。

概ねこのサイクルを３回ぐらい繰り返すことで、ようやく品質保証部門としてもＯＫ、つまり「合格」を出すことで、次のステップであるお客様による受け入れテストに進むことができるのです。

【　品質保証部門の役割　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
以前は、品質保証部門の仕事はシステムリリース前の製品検査を行うことで、品質保証を行うということが中心でしたが、上流工程の重要性が唱えられるようになるとともに、製品検査だけでなく、「ドキュメント検査」にも重点が置かれるようになってきました。そして、ISO9000やCMMIなどのシステム開発のプロセスに着目されるようになってくると、「プロセスＱＡ」というものも行われるようになってきました。（※４）

このように、システム開発を行うそれぞれの組織において、開発部門とは独立した第三者チェックの役割も多様化していくことになります。品質保証部門が具体的にどんなアプローチを行うとしても、システムの提供側である開発ベンダーとしては、以下のような構図を描いて品質保証を行うことを目的としています。

図１の上段で示すように、開発部門と発注側だけの場合、発注側の要求（たとえば、コスト削減やスケジュール優先）に引っ張られて、品質管理活動が不十分になり、冒頭で触れたようなマンションの傾き問題などを引き起こすリスクが高まることになります。図1の下段に示すように、品質保証部門が第三者的な立場として、コスト制約やスケジュール制約に引きずられがちな品質をしっかりとフォローすることで、安定した品質管理の構図が出来上がるというわけです。

システム開発の現場では、発注側の要求との調整だけでさえ多大な労力が必要な場合もあり、開発部門にとって品質保証部門は煙たい存在とみなされることも多いと思われますが、品質問題を回避するためには、重要な存在であると考える必要があります。しかし、現実問題として、発注側と受注側という構図の中に品質保証部門がうずもれてしまう可能性もあります。開発部門として直接契約関係にある発注側からの要求事項を振りかざすことで、品質保証部門の要求をなし崩しにしてしまうようなことが往々に起きてしまうことがあります。（※５）

そのようなことがまかり通るようでは、せっかくの第三者的なけん制役として品質保証部門に参画してもらう意味が薄れてしまいます。そうならないように品質保証部門として確固とした対応を心がける必要があり、日ごろから開発部門との信頼関係を築くとともに、実際のシステム開発の中で、開発部門の後方に位置するのではなく、発注側にも信頼されるように前面に出て活動することも必要だと思います。

【　品質チェック視点の多重化について　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
開発ベンダーから見た場合に、開発部門、発注側の視点に加えて、品質保証部門という第三の視点を追加することで、安定した品質管理活動を行うことを目指します。品質の多面性を考えたときに、さらに品質チェックの視点を増やすことで、より確実に品質を確保することができると考えられます。

たとえば、発注側の中でもＩＴ部門とユーザー部門の視点を分けて品質チェックを行うとか、開発ベンダー内のインフラ担当者にアプリケーションの品質チェックを行ってもらうなどの品質向上施策を行うことも実際によく行われることです。

しかし、コスト制約やスケジュール制約もある中で、無制限に品質にコストや時間をかけるわけにはいかないため、バランスのとれた統合マネジメントが必要になります。品質チェックの視点の数を増やす場合には、それぞれの視点の役割分担やカバー範囲を明確にしておかないと、同じチェックを何重にも実施することになったり、視点間のコンフリクト（矛盾した指摘）の発生など、無駄や混乱を招くリスクもあるので気を付けましょう。

「品質チェック視点の多重化は有効だが、コスト、納期とのバランスも良く考えよう！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　ISO9000、品質マネジメントシステムについては、以下参照。
・「ISO 9000」『フリー百科事典　ウィキペディア日本語版』
2015年9月27日 (日) 07:12 utc https://ja.wikipedia.org/wiki/ISO_9000
・「品質マネジメントシステム」『フリー百科事典　ウィキペディア日本語版』
2015年4月21日 (火) 05:29 utc https://ja.wikipedia.org/wiki/品質マネジメントシステム

※２　「半沢直樹」『フリー百科事典　ウィキペディア日本語版』
2015年10月23日 (金) 02:43 utc https://ja.wikipedia.org/wiki/半沢直樹

※３　品質保証部門が製品検査を行う場合、開発部門と同じ粒度でシステムのテストができるわけではないので、一部分の機能をサンプルで検査することになります。品質保証部門が摘出したバクの数やサンプリング率などをもとにして、残存バグの量を算出します。実際には統計的手法を用いるのですが、わかりやすく説明するためにごく単純化すると、たとえば、全ての機能の１０％をサンプリングで検査して１０件のバグを摘出したとすると、全体としてはその９倍＝９０件のバグが残存しているとみなし、開発部門のテストが不十分だったというペナルティの意味もこめて、１００件のバグ摘出「１０倍返し」を要求するといった具合です。摘出したバグの重要度（ランク）も、開発部門への要求件数算出に加味されることもあります。

※４　ＣＭＭＩについては、以下参照。
・「能力成熟度モデル統合」『フリー百科事典　ウィキペディア日本語版』
2015年5月6日 (水) 14:18 utc https://ja.wikipedia.org/wiki/能力成熟度モデル統合
・【第９回】マルクス社会発展段階とＣＭＭＩ成熟度レベル
・【第１０回】落合「オレ流野球」はＣＭＭＩレベル５か？

※５　開発部門と品質保証部門の好ましくない関係性の一例として、以下参照。
・【第５５回】プロジェクト八景～品質評価の多面性　の【４．受注側品質保証部門のＯ氏】