リリース判定の仕組み・リリース判定は公式レビューで行うのが最良
リリース判定は公式レビューか２部署会議か個別判定を使い分ける
ソフトのリリース判定を行なう仕組みを４つに分けて考えると判り易いですと、リリース判定のための４つのの仕組みの記事で紹介しました。この記事では３つ目のリリース判定の方法についてもう少し詳しく紹介します。リリース判定の方法としては、公式レビューと２部署会議と個別判定の３つの方法があります。
ソフトのリリースは、企画・営業・設計・製造・保守の全ての部門に関係する重要なイベントなので、リリース判定の方法として一番良いのは関連する部署が参加した公式レビューです。しかし、バグ修正版などの様に緊急性は高いけど今市場にあるソフトからの変更点はとても少ないようなリリースまで、全てを公式レビューで判定していてはなかなか大変です。
リリース判定の方法としてどんな物がある？
リリース判定はどんな方法で実施するのでしょうか？ 会社によって様々な方法があって、これが正しいという物はありません。グータラ親父は、リリースするソフトの内容（規模や用途）や、状況（初版かバグ修正か）によって、以下の３つの方法を使い分けていました。この記事では、グータラ親父が使っていた３つの方法について、紹介しましょう。
- 公式レビュー：ソフトに関連する部門の責任者が集まって会議形式で実施する
- ２部署会議 ：品質保障部門と開発部門の責任者が出席する会議で実施する
- 個別判定 ：品質保証部の担当者が一人で実施しその内容を品質保証部長が承認する
重要性の高いリリースは関連部門が集まって公式レビューで判定する
公式レビュー会議がリリース判定として一番良い方式です。前の記事でも書きましたが、リリース可否の判定責任者は、品質保障部門の責任者である事が多いです。その判定責任者がリリース可否の判定を行うにあたって、様々な情報を元に客観的に判定ができるように、ソフトのリリースに関連する部門の責任者を集めて会議をおこない、公式レビュー (Public Review) の形式でリリース判定を行おう、という方式です。
リリース判定会議に参加する部門としては、営業部門、企画部門、開発部門、テスト部門、製造部門、保守部門 等です。実際に参加する部門は会社によって異なってきますが、だいだいはこの様な部門の責任者が集めってリリース判定会議を行い、各部門からの情報を元にして判定責任者が最終的なリリース判定を行います。
初めてそのソフトを市場にリリースする初版のリリースや、大きな機能追加を行った重要なメジャーバージョンアップなど、製品にとって重要性の高いリリースの場合は、この公式レビューによるリリース判定が適しています。各部門がどんな情報を提供するのか、順番に見て行きましょう。
営業部門は市場状況を提出する
営業部門からは、リリースするソフトの市場での期待度や既存ソフトの利用状況に関する情報を提供して貰います。ソフトのリリースは、初版リリースの他にも機能改善や不具合修正のためのバージョンアップリリースがあります。バージョンアップリリースの時には、市場で既に稼働している現行バージョンのソフトがどの程度の本数なのか、最近の利用でのユーザからの問題点の指摘状況等の情報を提供してもらいます。また、初版のリリースであれば市場に存在する類似のソフトや自社ソフトの競合ソフトの売れ行き等につついての情報を提供して貰います。
これらの情報から、今回リリースするソフトの稼働の規模や市場の期待度が見えてきます。リリース初日から数十万ユーザが使い始めるのか、数千ユーザが使い始めるのかは、残存問題がある時には特に重要な情報となります。
企画部門は今後のリリース予定を提供する
企画部門からは、今回リリースが無事終了した場合の次のリリース計画についての情報を提供して貰います。次のリリースではどんな機能改善や不具合修正を織り込んで、いつ頃のリリースを目指す予定なのか、という情報からは今回リリースの判定を行うバージョンのソフトの市場での寿命（何か月間とか何年間使われるのかとか）が推定できます。これは、長期安定性の要求レベルに影響するので、長期安定性に懸念がある場合には、リリース判定に大きな影響を与える情報となります。
開発部門はソフトの開発状況を提供す
開発部門からは、今回のリリースで達成できた要求事項（機能改善や不具合修正）と、先送りになった要求事項についての情報を提供して貰います。これらの情報は、リリース判定という視点からは、それらのソフトの状況がユーザに正しく伝えられているか、という確認を行う時の基礎情報となります。言い方を変えると、当初の要求事項にあったのに、先送りになったような機能改善やバグ修正は、リリースノートや公開情報等で確実にユーザに伝わるかどうか、という事を確認するための情報です。
同時に、今回の開発の概要についての情報も提供されます。 どの程度の開発規模だったのか、どんな機能追加があって影響する機能は何なのかとか、どれくらいのバグ修正が織り込まれたのかというような情報です。これ等の情報は、次のテスト状況の確認をする時の補助情報として必要になります。
テスト部門はテスト計画とその結果を提供する
テスト部門からは、今回のリリース判定を行うソフトに関するテストの状況についての情報を提供して貰います。どんなカテゴリのテストをどの程度のテスト量で実施したのか。その結果発見されたバグの状況はどうなっていて、修正されたバグと残ったバグはどんな状況かというプロダクト品質を表す情報です。この情報と、先の開発部門からの開発概要に関する情報とを突き合わせて、必要にして充分なテストが実施されているのか、テストの結果は問題無く、リリースしても良いレベルの品質に達しているか、を判定する事になります。
製造部門はソフトを搭載する製品の製造計画を提供する
製造部門からは、今回のソフトがリリース判定に合格した場合にそのソフトウを搭載する製品の工場での製造計画に関する情報を提供して貰います。この情報は、ソフトのリリース判定には直接的には影響しませんので、通常は製造部門がリリース判定会議に参加する必要性はあまり高くはありません。
しかし、リソフトのリース時期と工場での製造開始時期が非常に近い場合、もしリリース判定でNGとなった時に、改修版が出来上がる時期を元に、早急に工場の生産計画を立て直さないといけないので、情報収集のために製造部門がリリース判定会議に出てくる場合もあります。場合によっては、製造ラインを一旦止めて、倉庫内在庫を保管する場所を大急ぎで確保しないといけないかも知れません。
保守部門はソフトの保守計画を提供する
最後に保守部門ですが、リリース判定会議でリリースが承認された場合、そのバージョンのソフトの保守についての保守計画（何時から、どんな保守サービスを開始するのか、そのための開発部門からの保守引き継ぎは何時行うのか、等）についての情報を提供して貰います。これらの情報は、プロダクト品質や開発プロセスの品質には直接は影響しません。しかし、保守プロセスの品質を推定する情報ですので、リリース審査において保守品質も含めて判定する場合には、必要な情報となります。
集まった情報を元に協議してリリース判定責任者が判定する
以上のような情報を、関連する各部門から提供してもらい、内容をレビューした上で、最終的にはリリース判定責任者である品保部門の責任者が、リリースの可否を判定するというのが、更改レビュー方式によるリリース判定です。
関連する部門が一同に集まる事で、必要な情報を漏れなく・効率良く集めて、多くの観点から問題の有無を確認した上で、リリース可否の判定を行う事ができるので、信頼性が高いリリース判定になります。
全てのリリースを公式レビューで判定できる訳でもない
公式レビューによるリリース判定を実施するには、忙しい各部門の責任者に集まって貰う必要もあり、また各部門で会議に必要な情報を準備する作業も必要なので、なかなかコストがかかります。そこで、重要度がやや低いソフトについては、もう少し簡単な方法でリリース判定を行えるようにしておくのが良いでしょう。 次の記事では２部署会議と個別判定について紹介します。