概要・リリース判定はリリースの種類/判定責任者/判定方法/ワークシートの４つの仕組みで実施する

2017年12月20日2022年5月10日リリース判定

ページの概要

ソフトのリリース判定では４つの仕組みに注意してリリース判定作業を実施する

ソフトのリリース判定にはリリース判定の基準とその基準を運用するリリース判定の仕組みが必要です。リリース判定のやり方は組織によって様々ですが、グータラ親父はこの20年近く下記の４つのリリース判定の仕組みに注意してリリース判定の作業を実施してきました。

リリース判定の方法や仕組みは組織によって様々ですので、このような考え方もあるのだと一つ具体例として読んでもらえば良いと思います。なお、ソフトウエアをリリースしても良いかどうかのリリース判定の基準については、別の記事に書いてありますので、そちらをご覧ください。

1. リリースの種類

まずはリリースの種類ですが、皆さんの会社ではどんなリリースの種類があるでょうか？　必ずあるのは正式版ですね。正式版以外に、ソフトウエアには、評価版とか、機能確認版とか、α版とか、β版とか、いろいろな呼び名のリリースが有ります。

リリースの目的によって、また市場によって、いろいろな呼び名が使われていいますが、各々の呼び名のリリースに対してリリース判定の手続きやリリース判定基準は、明確になっていて社内の関連する人やお客様とは、意識が合っているでしょうか。

リリースの種別に対する意識にズレがあると、結構大きな問題が起きる場合があります。例えば、βリリースのソフトウエアはどこまでのテストが済んでいるか？　という品質レベルを例に考えてみましょう。　お客様は安定性のテストも完了していると考えているのに対して、開発者は正常系のテストが完了したまでで異常系を含む安定性のテストは未完了、だと考えていると、いろいろと問題が起きてくる事は確かですね。

リリースの種類毎に、どの様な事を明確にして関係者と意識を合わしておくのが良いのか、リリースの種類については、別の記事で考えてみます。

2. リリース判定責任者

２つめのリリース判定責任者ですが、誰がリリースの可否を最終的に判定するのが良いのでしょうか。　ソフトウエアのリリースは製品出荷に相当するので、品質保証部門があれば、出荷の可否判断はリリース品質保証部門の責任者である品質保証部長が良さそうです。　ソフトウエアの開発・販売を主要なビジネスにいているソフトウエアハウスなどの場合は、この考えが実態と合っうので違和感もありません。

ところが、品質保証部門がソフトウエアのリリース判定をするのに違和感が生じる場合も、結構あります。例えば、家電などの製品に組み込まれる組み込み系のソフトウエアは、家電製品のメーカで開発されます。家電製品のメーカなら当然品質保証部門があるので、この品質保証部門がリリース判定をすれば良さそうに見えます。

しかし、家電製品の様な量産品の品質保証部門の仕事は、実は工場で常に同じ品質で大量の物を製造するための、量産品質を保証する事に主体が置かれている事が多いです。　そのために、品質保証部門は、量産品の品質を保証するための色々な品質管理の手法や、量産品を出荷しても良いかどうかを判定する出荷判定については、技術・ノウハウを持っています。

しかし、ソフトウエアはここにも書いてあるように、一品物です。　そして、一品物のソフトウエアの品質の善し悪しを判定するには、設計品質と製造品質とテスト品質と残存バグの状況を判断する必要があります。　一品物のソフトウエアの品質を判定するノウハウを品質保証部門が持っていない時には、そのようなノウハウを持っていそうな開発部門でリリース判定をしたほうが良い場合もでてきます。

どの様な組織や役割の人がリリース判定をするのか？については、リリース判定責任者についての記事で、もう少し考えてみます。

3. リリースの判定方法

ところで、ソフトウエアのリリース判定は、どんな方法で実施するのでしょうか？　関係する部門が集まって判定会議をするのでしょうか、あるいはリリース申請書のような書類が回覧されて、承認印がズラッと並ぶと、判定合格になるのでしょうか。

通常の製品であれば、出荷をしても良いかどうかという出荷に関する最終判定の権限を品質保証部門が持っている事が多いです。　この場合には、品質保証部門が出荷を承認する事になりますので、品質保証部門が書類や現物を調べるて品質に問題が無いと判断し、出荷承認の書類に品質保証部門の捺印がされると出荷承認となります。

ソフトウエアのリリースの場合は、リリース判定の責任者と同様にリリース判定の方法も、会社によっていろいろです、どれが正しいというのは無いのですが、では自社にとってどんな方法でリリース判定を行うのが良いのか、と考えると迷いが出ますね。　

グータラ親父は会議や書類審査などのリリース判定方法を、ソフトウエアの品質状況や開発状況に合わせて使い分けてきました。リリース判定方法の記事では、グータラ親父が行ってきたリリース判定を紹介します。こんな判断の方法もあるのだな、と参考にご覧ください。

最後が、リリース判定の作業を実際に行う時に、一つ一つの判定の方法やその結果を記録するリリース判定ワークシートです。実は、ここまで説明してきたリリースの種類やリリースの判定責任者やリリース判定方法は概念的なものなので、極端な言い方をすれば、別に決まっていなくても何とかなります。　でも、実際の判定作業を行うためのリリース判定ワークシートは、これが無いと実際のリリース判定を行ったりその結果としてのリリース可否を記録して社内に伝えたりする事ができないので、リリース判定ワークシートは必須のツールです。

リリース判定のためのリリース判定ワークシートは、普通はソフトウエアのリリースに関わる人、つまりリリースを申請する人とリリースを判定する人とリリース判定結果に従ってリリース作業をする人、以外の人は見る機会はあまりありません。　ですので、自分の会社のリリース判定のためのリリース判定ワークシートは見た事が無い人のほうが多いと思います。ソフトウエアの設計や実装やテストを担当している人達は、ぜひ一度自分の会社のリリース判定ワークシートを手に入れて、ご覧になる事をお勧めします。そこには、皆さんの会社がソフトウエアの品質にどんな物をどんなレベルで求めているのかが、凝縮されて書かれています。

では、リリース判定ワークシートでは、ソフトウエアのどんな点を確認して品質の状況を判断し、どんな方法で最終的なリリース判定の可否を判断し、その結果を記録するのが良いのでしょうか？　世の中に標準的なリリース判定のワークシートが有るわけでも無いので、これもまた会社によってばらばらです。会社によってばらばらなのは仕方ないのですが、どれが正しいか判らないので、これからリリース判定のワークシートを作ろうとか見直そうとすると、正解が無いのでちょっとやっかいです。

リリース判定ワークシートはどんな事に注意して作れば良いのでしょうか？　グータラ親父は、以下の点に注意してリリース判定ワークシートを作っていました。