>ここのところ「マンションの傾き問題」が世間をにぎわせていますが、システム開発の現場でも同じような品質問題が潜んでおり、決して対岸の火事といえるものではありません。品質データの改ざん、下請け構造による品質責任の所在不明確、コスト削減・納期厳守の現場プレッシャー・・・どれも聞いたことのあるキーワードばかりですね。このような業界の構造的ともいえる品質問題は、現場任せにしていては決して解決することはありません。システム開発を行う組織の中で、そのような品質問題に客観的な立場で取り組む役割を担うのが品質保証部門です。Assurance(品質保証)の頭文字をとってQA部門と呼ばれたり、システムをリリースする前の出荷検査を行うことから検査部門と呼ばれたり、それぞれの組織によって、呼び方や役割はさまざまです。System)の維持を主目的としている場合もあります。いずれにせよ、実際にシステム構築を担う開発部門とは独立した第三者機関として、品質を確保することを目的とした組織です。(※1)私がシステム開発の仕事に携わるようになって、最初に品質保証部門と接したのは、プロジェクトの終盤ともいえる、システムテストの頃です。われわれ開発部門のメンバーが、毎日夜遅くまでバグ対策とテストケース消化に追われているかたわらで、突然普段見かけない人たちが現れ、われわれの作った設計書を眺めたり、まだテスト中のシステムを勝手に操作したりしていました。一担当者にすぎなかった私としては、お客様でもない、その見知らぬ人たちが何ものなのかわからず、少し気にはなりましたが、テストケース消化とバグ対策を優先して、やりすごしていました。設計書の記載内容やシステムの動きについて、たまに質問されるようになったり、だんだん煙たく感じるようになってきたのです。ものが提出されました。)それは、まるで半沢直樹の名ゼリフ「やられたらやりかえす。倍返しだ!」のごとく、品質保証部門が摘出したバグ件数の10倍ものバグ摘出、つまり、「10倍返し」を要求しているというものでした!(※2)(※3)システムテストも終盤で、われわれとしては、そろそろテストはやりきったかなと思い始めた時期にそんな要求をされ、その要求が満たされない場合には、お客様に納品できない、つまり、お客様の受け入れテストに進めないという厳しい内容です。われわれ開発部門としても、黙ってそれを受け入れるわけにはいきません。バグ摘出要求件数を減らすために、品質保証部門により摘出されたバグの内容を精査します。設計書とは違う動作をするが設計書の方が誤っているのでバグでは無いとか、システムテストで開発部門も検知していたバグであるためQA指摘件数から除外するとか、確かにバグではあるが業務への影響度は低い(ランクが低い)とか、開発部門側の見解として、様々な理由をつけてバグの件数を減らしにかかります。それでも、要求件数がゼロにならなければ、その要求件数を目標にして、開発部門側は品質向上を実施することになります。基本的には、品質保証部門が摘出したバグの類似見直し(横展開)により、同種の残存バグが無いかを確認します。その結果、要求件数には満たなくても、開発部門としてはこれだけ見直したというエビデンスを品質保証部門に提示すると、品質保証部門は再検査を実施します。概ねこのサイクルを3回ぐらい繰り返すことで、ようやく品質保証部門としてもOK、つまり「合格」を出すことで、次のステップであるお客様による受け入れテストに進むことができるのです。】~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~以前は、品質保証部門の仕事はシステムリリース前の製品検査を行うことで、品質保証を行うということが中心でしたが、上流工程の重要性が唱えられるようになるとともに、製品検査だけでなく、「ドキュメント検査」にも重点が置かれるようになってきました。ISO9000やCMMIなどのシステム開発のプロセスに着目されるようになってくると、「プロセスQA」というものも行われるようになってきました。(※4)このように、システム開発を行うそれぞれの組織において、開発部門とは独立した第三者チェックの役割も多様化していくことになります。品質保証部門が具体的にどんなアプローチを行うとしても、システムの提供側である開発ベンダーとしては、以下のような構図を描いて品質保証を行うことを目的としています。図1の上段で示すように、開発部門と発注側だけの場合、発注側の要求(たとえば、コスト削減やスケジュール優先)に引っ張られて、品質管理活動が不十分になり、冒頭で触れたようなマンションの傾き問題などを引き起こすリスクが高まることになります。図1の下段に示すように、品質保証部門が第三者的な立場として、コスト制約やスケジュール制約に引きずられがちな品質をしっかりとフォローすることで、安定した品質管理の構図が出来上がるというわけです。システム開発の現場では、発注側の要求との調整だけでさえ多大な労力が必要な場合もあり、開発部門にとって品質保証部門は煙たい存在とみなされることも多いと思われますが、品質問題を回避するためには、重要な存在であると考える必要があります。現実問題として、発注側と受注側という構図の中に品質保証部門がうずもれてしまう可能性もあります。開発部門として直接契約関係にある発注側からの要求事項を振りかざすことで、品質保証部門の要求をなし崩しにしてしまうようなことが往々に起きてしまうことがあります。(※5)そのようなことがまかり通るようでは、せっかくの第三者的なけん制役として品質保証部門に参画してもらう意味が薄れてしまいます。ならないように品質保証部門として確固とした対応を心がける必要があり、日ごろから開発部門との信頼関係を築くとともに、実際のシステム開発の中で、開発部門の後方に位置するのではなく、発注側にも信頼されるように前面に出て活動することも必要だと思います。視点に加えて、品質保証部門という第三の視点を追加することで、安定した品質管理活動を行うことを目指します。品質の多面性を考えたときに、さらに品質チェックの視点を増やすことで、より確実に品質を確保することができると考えられます。発注側の中でもIT部門とユーザー部門の視点を分けて品質チェックを行うとか、開発ベンダー内のインフラ担当者にアプリケーションの品質チェックを行ってもらうなどの品質向上施策を行うことも実際によく行われることです。コスト制約やスケジュール制約もある中で、無制限に品質にコストや時間をかけるわけにはいかないため、バランスのとれた統合マネジメントが必要になります。品質チェックの視点の数を増やす場合には、それぞれの視点の役割分担やカバー範囲を明確にしておかないと、同じチェックを何重にも実施することになったり、視点間のコンフリクト(矛盾した指摘)の発生など、無駄や混乱を招くリスクもあるので気を付けましょう。ISO9000、品質マネジメントシステムについては、以下参照。品質保証部門が製品検査を行う場合、開発部門と同じ粒度でシステムのテストができるわけではないので、一部分の機能をサンプルで検査することになります。品質保証部門が摘出したバクの数やサンプリング率などをもとにして、残存バグの量を算出します。実際には統計的手法を用いるのですが、わかりやすく説明するためにごく単純化すると、たとえば、全ての機能の10%をサンプリングで検査して10件のバグを摘出したとすると、全体としてはその9倍=90件のバグが残存しているとみなし、開発部門のテストが不十分だったというペナルティの意味もこめて、100件のバグ摘出「10倍返し」を要求するといった具合です。摘出したバグの重要度(ランク)も、開発部門への要求件数算出に加味されることもあります。■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。(プロジェクトマネージャ、システム監査技術者他)など。社員の声アクセス採用情報ブログ株式会社アイ・ティ・イノベーションは、米国PMI®から公認教育プロバイダー(R.E.P)として認定されております。Inc.)の登録商標です。Provider)です。Knowledge®は、IIBA®の登録商標であり、IIBA®の許可を得た上で使用しています。アイ・ティ・イノベーションまたは各社の商標もしくは登録商標です。