リリース判定基準・ゲートプロセスの実施状況
開発プロセスでは最後にゲートプロセスの実施状況を確認する
この記事では、リリース判定でのプロセス品質の判定のためにグータラ親父が確認していた７つの項目のうち、ゲートプロセスの実施状況 について紹介しています。他の6項目（開発計画の立案、ソフトウエアの設計、実装テスト計画の立案、懸案やリスクの管理、ベースライン管理、保守の体制と保守契約）については、前の記事や後の記事で紹介していますのでそちらをご覧ください。
７．ゲートプロセスの実施状況
ゲートプロセスとは、ソフトの開発から出荷後の保守までに実施するいろいろなプロセスのうちで、社内のルールで実施と完了の承認が必須と決められているプロセスの事です。言い換えると、そのプロセスが完了した事が承認されないと、次の開発プロセスに進んではいけないという制限が設定されているプロセスの事です。
判り易い例で言えば、リリース判定はゲートプロセスです。 完成したソフトを市場にリリースしても良いかどうかの最終的な承認は、組織のルールに従って、ソフトの品質に責任のある人を最終判定者として実施され事が必須なので、ゲートプロセスです。
ソフトは目に見えないのでゲートプロセスがより重要
当たり前の事のように聞こえますが、なにせソフトは目に見えず、ネットを介して簡単に配布できるという特徴があります。リリース判定という開発プロセスが、充分に定着していない組織では、開発部門でテストしていたソフトが、誰の承認を得たのかよく判らないままいつのまにか市場リリースされるという事も、起こり得ます。
これがハードウエアですと、正式に出荷してエンドユーザの手元に届けるには、梱包して宛先の住所や受取者を明確にして輸送業差に物を渡して運んで貰う必要があり、色々な部署に依頼する作業が発生するので、その時点で何らかのチェックが働きます。
ところがソフトは、特に既に市場に存在する製品に対するバージョンアップ版のソフトの場合などは、開発担当者が手元のソフトをインターネットにUpしてしまえばそれだけで、エンドユーザの手元に届いてしまいます。
ハードウエアよりも格段に簡単で社内の他部署への作業依頼も不要なため、チェックも働き難いです。これは極端な例ですが、目に見えないソフトについては、ゲートプロセスを明確に定めて、そのプロセスが着実に実施されている事を１つ１つ確認しながらリリースする、いう仕組みを作っておく必要があります。
どのプロセスをゲートプロセスにするかは、どんな開発プロセスを採用しているかに大きく依存するので一概には言えませんが、例えばウォータフォール型の開発プロセスを採用している場合だと、以下の様なプロセスがゲートプロセスの候補になります。
① 要求仕様の確定：要求仕様書に対する公式レビュー等で関係部署と供に仕様を確認する
② 開発計画の立案：開発チームの作成した計画に漏れや抜けが無く実現性が高いかを確認する
③ 製品のアーキテクチャ設計：ハードとソフトの役割分担や将来のお拡張性を確認する
④ ソフトの基本設計：基盤ソフトやその上に組み上げるソフト構造などを確認する
⑤ テスト設計：市場が製品に求める品質を保証できるテストが計画されているか確認する
⑥ テストの実施：テストの結果が製品に求められる品質を満たせているかを確認する
⑦ リリース判定：ソフトが市場に提供しても問題なり品質を持っているかを確認する
⑧ 保守開始：ソフトのリリースと同時に保守サービスの提供が開始される事を確認する
プロセス品質に問題があればプロダクト品質を注意し見る
だいぶ説明が長くなってしまいましたが、これまでに説明してきた以下の7つの重要な管理プロセスについて、ちゃんと実施されているかどうかを、リリース判定の時に確認していました。
ところで、プロセスを確認して問題が無ければ良いのですが、問題があった時はどうしていたのでしょうか？ 結論を言いますと、プロセス品質に問題があった時には、特に注意してプロダクト品質の確認をして、プロダクト品質に問題がなければリリースを承認していました。
ソフトの品質として大事なのは、プロダクト品質そのものです。プロセス品質は良いプロダクト品質を達成するための手段なのです。ですので、例えプロセス品質に何等かの問題があってもプロダクト品質に問題がなければリリースしても問題は無い、との判断していました。
プロセス品質は良い常に良いプロダクト品質を達成するために
では、なぜプロセス品質を確認していたのでしょうか？？？ プロセス品質が良いと、常に管理された状況でつまりは納期遅れや品質低下が少ない状況でソフトの開発が進みます。その結果として、プロダクト品質の良いソフトウエアができてくる可能性が高いです。
一方で、プロセス品質が悪いと、開発管理が不十分なので、納期の遅延が起きたり、品質の低下が起きたりするリスクが高まります。 要するに、納期や品質のブレが大きくなってしまいます。なので、ある時はプダクト品質の良いソフトウエアができあがるのですが、別の時にはプロダクト品質の悪いソフトウエアが出来てきます。
これでは、あまり宜しく無いので、プロセス品質も監視して、できるだけプロセス品質も改善するように指導はしていました。 でも先ほども述べましたが、ソフトのリリースで重要なのはプロダクト品質なので、プロダクト品質に問題がなければリリースを承認していたとう事です。
次はプロダクト品質です
ここまでの記事でリリース判定のための４つの基準について書いてきました。次はリリース判定のための４つの仕組みについて紹介します。ご興味のある方は以下からプロダクト品質についての記事をご覧ください。