品質問題では、その原因がどこでなぜ埋め込まれたかを確認することが大事
itpjstudy
プロジェクトでは、さまざまな品質問題にぶつかります。特に、システムテスト（総合テスト、統合テスト）では、多種多様な問題が同時に発生します。ただ、プロジェクトによっては、雑多な問題の物量に押されて、適切な対応が取ることに苦労しているように思います。
この回では、雑多な問題がどこで埋め込まれたのか。それはなぜか、どうすれば適切に対処できるかについて、お話していきたいと思います。
システムテストで検知される不具合
システムテストは、UAT（User Acceptance Test / ユーザ受入テスト）前の、IT側メンバによるシステム品質の最終総確認です。
ビジネスシナリオベースのテストですが、多種多様な不具合が検知されます。以下は、代表的な不具合の例です。シナリオ実施への影響を見て、緊急なものから順に対応していくことが多いと思います。しかし、不具合が多すぎて、対応が間に合わなくなるときがあります。そういうときは、一歩引いて、どこで仕込まれたものなのかを確認することが、有効です。
上の表に、どこで仕込まれたか（その内容がいつ検討されたのか）を追記してみました。要件定義フェーズ、設計フェーズ、開発フェーズと、システムテストに至るまでの各フェーズで、問題が仕込まれる可能性があることが分かります。
では、なぜ、そんなに色々なフェーズで問題が埋め込まれ、システムテストになるまで、解消せずに残っているのでしょうか。
システムテストにまで、問題が残っている理由
まず、フェーズごとに、そのフェーズで作成した成果物が妥当か、必ずレビューを行います。ただ、人間がレビューしますので、誤解や見逃しがありえます。
そのため、そのあと、プログラムが完成した後に、単体テスト、結合テストといった形で、実物に対するテストを行って、品質を高めるようにします。
しかし、それでも、なお問題をつぶし込み切れずに、相当量が、システムテストまで持ち越されることが多いのが現実です。
そのため、システムテストにおいて、多種多様な問題が発生するのです。
もう少し具体的に掘り下げてみましょう。
要件定義での確認をすり抜けてきた不具合
メンバ
ITパートナが取り上げた検討内容は、非常に粗くて、必要な業務要件の全量は検討できていないと感じた。でも、そのときは、ITパートナが持っているテンプレートで勝手にカバーされるものと信じていた。
いま、システムテストで、実際に作られたシステムを見てみると、必要なものがカバーされていない。
設計フェーズでの確認をすり抜けてきた不具合
メンバ
設計フェーズでは、システムの動作が文章でしか記載されていなかったので、あまりイメージができなかった。
いま、システムテストで、システム動作を見てみると、思っていたものとかなり違う。
人間ですから、思い込みもありますし、想像力の限界もあります。そのため、一定量の問題が発生し、つぶし込み切れずに、システムテストまで持ち越されることは避けようがありません。
ただ、少量なら良いのですが、量が多くなってくると、適切に対処しなければ、捌き切れません。そういったときに、「いつ仕込まれた問題なのか」ということが、整理の仕方のひとつとして、役に立ちます。
仕込まれた時期によって異なる、対処の方法
では、どのように対処が異なるのかを見て行きましょう。
要件定義フェーズ・設計フェーズで埋め込まれた問題
検討会が必要になる
要件定義や設計に不備・漏れがある場合は、要件定義書や設計書の内容変更や追加が必要になります。
要件定義書や設計書は、たいてい、ユーザ企業側から、業務ユーザやIT部門メンバが複数参加して、喧々諤々して最終化しています。その内容の追加変更ですから、一緒に検討したメンバに、それで良いかを確認して決定する必要があります。
要件定義書や設計書は、様々な要素を整合が取れるように整理して、ひとつの成果物にしています。そのため、ひとりの独断で変更してしまうと、考慮漏れが発生して、二次被害に会う可能性があるからです。
仕様変更として、マネジメント判断が必要となることがある
また、内容によっては、大きな工数・期間を必要とする可能性があります。その場合、きちんと仕様変更の手続きを通して、マネジメントの判断を求める必要があります。
課題一覧に起票して、モニタすることが必要になる
さらに、重要なこととして、簡単に解決しなさそうな問題については、課題一覧に起票する必要があります。システムテストの不具合一覧は、システム目線で記載・管理されるため、業務ユーザやマネジメントには理解しづらいところがあります。
そのため、業務メンバ目線で分かりやすい課題一覧に起票して、広く認知されるようにする必要があります。それにより、仕様変更になりそうなもの、業務側の判断が遅れているものなどが検知しやすくなります。
開発で埋め込まれた問題
手順を継続改善する
こちらは、ITメンバに閉じた活動になることが多いです。そのため、業務メンバを巻き込んだ検討会は基本的に必要ありません。
その代わり、設計書通りにきちんとプログラム開発するということが出来ていないということなので、品質担保のための手順を改善していくということが重要になります。
もちろん、ITパートナには、長年のノウハウが詰まったガイドラインやチェックリストがあります。しかし、プロジェクトごとに、必要となるプログラムは異なりますし、開発者の力量や得意分野も違います。そのため、プロジェクトで起きた問題事象をベースに手順を改善していくことが大切なのです。
横串ローラー
また、開発フェーズで発生する問題の特徴として、同じ問題が同時多発するということがあります。
複数人が集まって検討会形式で進める要件定義や設計と異なり、開発は、ひとりで進めることが多いです。そのため、特定の開発者が作成したプログラムでは、同じ間違いが繰り返し発生している可能性があります。また、ガイドラインが不足しており、開発者全員が同じ間違いをしている場合もあります。
そういったときは、問題事象からアクションプランを作成して、同種の問題は発生していそうなプログラム全てについて、横串で確認していく必要があります。
このように、問題が仕込まれたフェーズによって、アクションが異なります。この違いを明確に意識して、対応するのとしないのとでは、対処の的確さやスピードが大きく違ってくるのです。
システムテストで発生する多種多様な問題に対しては、それぞれの特性を理解して、その特性に合った対応を取ることが重要です。そのひとつの切り口として、その問題がいつ仕込まれたものなのかを確認することが大切だというお話をしました。
このカテゴライズするという考え方は、非常に重要です。的確な打ち手につながるというだけでなく、状況を俯瞰的に理解するためにも役に立ちます。この回では、課題一覧を利用するというお話をさせて頂きました。このカテゴライズする考え方については、また別の回に取り上げたいと思います。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
