リリース判定の仕組み・リリース判定は２部署会議や個別判断でも可能
初版でなければ２部署会議か個別判定でリリース判定もあり
前の記事ではリリース判定の方法のうち公式レビューとを紹介しました。グータラ親父は、小さな機能改善やバグ修正など重要性がやや低いソフトのリリースについては、公式レビューよりも簡易的な２部署会議と個別判定の方法も使ってきましたので、この記事ではこの２つについて紹介します。
２部署会議は品質保障部門と開発部門で実施するレビュー
関係部門が集まっての公開レビュー方式でのリリース判定は、信頼度が高い良い方法なのですが、多くの人が集まる会議体なので、工数が掛かります。 6人が 2時間の会議を行うと、それだけで 6人 X 2時間 = 12人時の工数です。さらに会議用の資料の準備に各参加者が2時間の作業を行うと、合計で24人時の工数が発生し、高コストとなります。
大規模な開発を行ったソフトの初版のリリース判定の場合には、品質リスクも高くリリース可否の判定も難しい場合が多いので、少々人件費を掛けても公開レビュー方式で実施するのが良いです。
一方で、毎回公開レビュー方式のリリース判定をするのは、ちょっとコスト高になり過ぎるので、開発規模が小さい場合や、機能追加開発の場合などでは、品質保障部門と開発部門の２つの部門の責任者と関係する担当者のみが集まる会議形式でのレビューでのリリース判定を実施して、これを２部署会議方式と呼んでいました。実は、このパターンでのリリース判定が割と多いです。
他の部門の持つ情報は会議の前にヒアリングして集めておく
営業部門の市場状況、企画部門の今後のリリース計画、テスト部門のテスト結果、等の情報についてはヒアリング等で事前に情報を把握しておき、その情報を元にリリース判定を行います。
残存バグについては、それらが市場でのサービス提供に影響が無い事を確認するために、残存バグに起因する不具合としてどのような不具合が市場で起きるのか、その不具合が発生する条件は何か、不具合が発生した時の回復方法はどのような物があるのか、不具合が発生する頻度はどの程度なのか、というような少し詳しい情報を開発部門から説明してもらいます。
それらの情報を元に、残存バグがあっても市場でのサービス提供に実質的に影響が無いかどうかを判定して、リリース可否の判定を行います。開発部部門については、開発の概要などは業務計画書などの資料を見て把握すれば良いのですが、残存バグについての情報を効率的に収集するために、必要に応じて開発の実務担当はに会議に出てもらう場合もあります。
開発部門と品質部門との会議は、残存バグの件数にもよりますが、予め残存バグの情報が整理されていれは、１時間から２時間程度で終了します。それ以外の項目については、各種の資料を品保部門が読み取りますので、資料の出来具体にもよりますが、数時間から長くて１日程度で終わります。
個別判定は品質保障部門の担当者が一人で確認する
リリース判定の方式としては、前で説明した開発部門と品質部門とで実施するレビュー方式が一番多かったのですが、バグ修正２件のみというような完全なバグ FIX 版のソフトウエアのリリースの場合には、開発部門とのレビュー会議さえ必要が無い場合があります。
１つ前のバージョンからの変更点がバグ修正２件のみなら、その他のバグはやはり残存しています。 それらの残存バグの本番サービスへの影響度合いについては、前のバージョンのリリース判定時に確認済みでので、 今回のリリースにあたって改めて残バグがサービス提供に与える影響を再検討する必要もあまり無く、開発部門に聞く事もそれほど発生しません。
このような場合には、品質部門の担当者が一人で、各部門から提出された資料類を元にソフトの品質状況を確認し、リリース可否の判定を行う事も良くあります。もちろん、リリース判定の責任者は品保部門長なので、担当者の確認の後に品質保証部門長の承認の手続きは入りますが、具体的なリリース判定は、担当者が１人で行う形式です。
リリースの判定方法はどう使い分けましょう？
リリース判定の方法として３種類の方法を紹介しましたが、さて、どう使い分けるのが良いのでしょうか？ どれが正解というのは有りませんが、時間と費用が許す限りは、関係部門が集まって実施する公開レビュー方式が一番良いです。
ですが、世の中常に最適の常態で仕事ができるかというとそんな事は滅多に無くて、、、いつも少ない費用と短い納期に追い立てられて仕事が進むのが、ソフトウエア業界の悲しい性です。
と、現実に任せてしまうと、余り良い結果にはならない事が経験上多いですので、、、関係部門が集まって実施する公開レビュー方式を採用する条件を幾つか決めておき、その条件が成立した時には、どんなに忙しくても納期が迫っていても、しっかりと公開レビュー方式のリリース判定を行う、というルールにしておくのが良いです。
グータラ親父は、以下のようなルールのどれかが成立する時には、公開レビュー方式のリリース判定を実施するルールとしていました。
- 初版ソフトウエアのリリース時 （Ver1.0 のリリース時）
- 開発規模が大きい機能の追加開発を行ったリリース時（メジャーVerUp時）
- ソフトウエア自体は既存だけど、新しい市場に対して初めてリリースする時
要するに、リリースにあたって品質上のリスクが大きい時には、充分に情報を集めて、色々な視点で確認した上で、リリース可否を判定するほうが良いので、公開レビュー方式を採用していた、という感じです。
リリース判定にもツールがほしい
さて、リリースの判定責任者が整理できたので、最後にリリース判定にはどんなツールを使うのか？ という点について紹介します。