リリース判定の仕組み・リリース判定の結果はチェックリストで記録を残す
リリース判定は項目毎の判定結果をチェックリストで残します
これまでの記事で、リリース判定のための４つの判定基準とリリース判定のための４つの仕組みのうち３つについて、紹介してきました。 これでソフトのリリース判定に必要な情報と判定の方法、その判定を実施する仕組みはほぼ揃いました。ところで、リリース判定した結果はどうやって残しましょうか？ グータラ親父は、リリース判定結果の表紙と、判定項目ごとの判定結果を記録したチェックリストを使って判定結果を残してきましたので、その内容についてこの記事で紹介しましょう。
どんな方法でリリース判定を行ったうのか、とどんな判定基準でリリースの可否を判断するのかは、各々の組織によって変わってきます。しかしリリース判定の結果を記録として残さなければいけない、とう事はどの組織でも必要な共通の作業です。
どんな様式でリリース判定の結果を残しても構わないのですが、せっかく結果を残すのならば、後になってどんな情報を元に、どんな考え方でリリースの可否を判定したのか、判り易い資料で残しておくのが良いですね。リリース判定の結果を記録しておく資料の名称としては「リリース判定結果」というような名前が一般的ですので、この記事では「リリース判定結果」と呼ぶことにします。
リリース判定結果の表紙には判定対象が何で判定結果が何かを書いておく
「リリース判定結果」は、これまた組織によっていろいろな書式がありますが、一般的にはまず以下のような項目が書かれた表紙（先頭ページ）があります。
- リリース判定の ID 番号 （このリリース判定結果のIDです、書類番号の場合が多いですね）
- リリース判定の対象ソフトウエア（名称とバージョンはソフトにとって必須です）
- リリース判定の結果（合格とか不合格とか条件付きで合格とかを判りや易く記録します）
- リリース判定責任者の承認（捺印や直筆サインや電子署名で誰が判定の責任者なのか明確にします）
- リリース判定合議者の承認（合議の場合は誰が参加したのかの記録も必要です）
- リリース判定の日時（これはどんな書類でも必須の項目ですね）
- リリース判定の理由 （合格の理由か不合格の理由を、簡潔に書いておきます）
ISO9001的にはこれだけでも良いのですがこれだけでは判定の理由が良く判りません
この表紙だけでも、「リリース判定結果」としては成立します。「リリース判定結果」は、どのソフトに対して、何月何日に誰の責任においてリリースが承認されかのか、を記録する事が目的ですので、その目的はこの表紙だけで成立しています。ISO9001 でも CMMI でも、上記の項目が記載された「リリース判定結果」で問題ありません。
でも、これだけだとちょっと寂しいですね。特にリリースが不可と判定された時には、何が悪かったのか明確に判らないと再挑戦の時までに何を改善すれば良いのかが判りません。また、後日この判定結果を見ても、どんな情報を元にどんんあ考えで合否の判定をしたのか、よく判りません。この表紙だけではちょっと不親切な状態です。
様々な判定のための確認項目の１つ１つについての判定結果の一覧表を残しましょう
リリースの判定は、リリース判定の４つの基準の記事で紹介しているように、様々な観点からソフトの品質を確認して、総合的に問題が無い場合にリリースを承認する事になります。各々の観点に関する判定の結果か記録として残っていれば、リリースの合否だけではなく、次回からどんな点について改善すれば良いかも判り易いです。また、多くのリリース判定の結果を分析すれば組織としての改善点も見えてきます。
ですので、グータラ親父は下記のようなリリース判定項目毎のチェックリストを作成して、これを「リリース判定結果」の2ページ目以降に添付していました。このチェックリストの記録を見れば、そのソフトの品質はどんな箇所が十分でどんな箇所に不足があるのか、その内容を知る事ができます。グータラ親父が使っていたチェックリストを乗せておきますので、参考にご覧ください。
チェックリストではプロセス品質とプロダクト品質を項目毎に確認して記録します
チェックリストの本体は、プロセスセス品質とプロダクト品質とに分けて、必要な確認項目を箇条書きにしてあります。各々の項目の確認方法や判定の仕方については、リリース判定のための４つの判定基準の記事に紹介していますので、そちらもご覧ください。様々な判定項目がありますので、必要な項目のみを選択してこのような一覧表にしておくと使い易いです。
プロセス品質は主に、計画されたプロセスが計画通りに実施されているかという開発プロセス実施状況と、工程や品質を監視するプロセスの状況言い換えると管理プロセスの状況について、確認した結果を記載する欄が並んでいます。
プロダクト品質は、設計と実装とテストの各々のフェーズでの成果物である、設計書やソースコードや実行プログラムの品質を測る、設計レビューやコードレビューの指摘や検出バグの状況を確認して、品質の要否を判定するための欄が並んでいます。
特別確認項目というのは気になる点の確認です
プロセス品質とプロダクト品質とは別に、特別確認項目 という欄もあります。 プロセス品質とプロダクト品質は、毎回のリリース審査で必ず確認する項目が並んでいます。しかし、ソフトのリリースを継続して行っていると、ある時期に特定の領域について重点的に確認したくなる事があります。
例えば、世間でサイバー攻撃の兆候が高まってきた時には、セキュリティ機能に関するテス状況などは特に念をいれて確認したくなります。その様な時には、この特別確認項目の欄に１項目「セキュリティ」という項目を付けたして、毎回注意して確認するようにします。
グータラ親父がリリース判定を行っていた組み込み系の製品では、RAS機能とセキュリティについては注意が必要だったので、この２項目が入っています。もう１項目の「時限爆弾バグ」というのは、、、グータラ親父の造語です。
メモリ等のカーネル資源の枯渇問題や、カウンタのロールアップ問題は、ソフトウエアが稼働してから長時間が経過してから発生する事が多いので、時限爆弾バグと呼んでいました。 この時限爆弾バグが潜在してると、発生する時期に若干の前後はあっても、市場で稼働している全ての製品で不具合が引き起こされる場合が多いです。 そして、嫌な事に出荷前のテストで見つけ難いです。ですので、特に注意する項目として入れてあります。
確認結果は 良 / 可 / 不可 の３段階
各々のチェック項目に従って判定した結果は、良 / 可 / 不可 の３段階で判定結果を記録するようにしてあります。その項目について、問題が無ければ 可 、良く出来ていて安心監があるなら 良 ですが、品質上問題があるなら 不可 の判定となります。
ソフトウエアのリリース判定方法としては、不可 の判定が１つも無ければリリースを許可する、というのが単純明快で良いと思います。
もちろん、全てのソフトウエアが不可が１つも無い状況になってくれるのが一番良いのですが、世の中はそんなに上手くは行きません。１つや２つや３つは、不可項目が発生する事もあります。そんな時には、不可の項目をＸＸＸＸまでに改善する事を条件として、条件付でリリースを許可するとか、特別採用の申請に切り替えて、問題点の市場への影響範囲を再検討の上でリリースの可否を再判定する、という運用も必要になってきます。
確認に使った資料も判定結果と一緒に残しましょう
このチェックリストには、各々の確認項目に「確認結果と確証」という記載欄もあります。 ここには、実際の確認に使った資料類の資料番号やサーバーの記録場所を記載し、どんな情報を元にどんな判断をしたのかを記録します。
そして、リリース判定に使った資料類は、何年か経ってからでも間違いないく参照できるように、資料のID番号を記録するか、資料そのもののコピーを残しておくのが良いと思います。
グータラ親父は、最初の頃は資料番号だけを記録していたのですが、有る時過去のリリース判定の記録を遡ろうとした時に、ちょっと困った事が起きました。 とある設計書の書類番号が記録に残っていて、サーバ上の保管場所も記録してあったので、その保管場所を見に行ったのですが、そこには同じ書類名で同じ書類番号の、複数のバージョンの資料が記録されていました。
そうです、設計書は開発が続いていると、どんどんと改訂されていくので古いバージョンから新しいバージョンアまで、複数バージョンの設計書が記録されていたのです。 開発部隊はソースコード管理システムに使っている設計書も登録しているので混乱はしないのですが、品保部門がソースコード管理システムのタグ番号を元に、該当する設計書を取り出すのは、なかなか手間が掛かります。
という経験があったので、それ以降グータラ親父はリリース判定の時に確認した資料類は全て、そのコピーをリリース判定の確証として別のフォルダに記録する事にしました。 幸い、電子化された資料はコピーも簡単ですし音声や動画で無い限り、少々ドキュメントの分量が多くても、最近の HDD の広大な記憶容量から見れば、記憶場所の不足を気にする必要もありません。 なので、少々乱暴ですが、リリース判定で確認した資料は全て、コピーを記録するという方法を採りました。
チェックリストの最上段はダブってますが、まあ気にせずに
チェックリストの最上段は「リリース判定結果」の 先頭ページと内容がダブっていますが、リリース対象のソフトや判定日時を記載する欄を設けてあります。
実際のリリース判定の時には、まずこのチェックリストに沿って具体的な確認を行い、その結果を元に総合的に合否を判定し、その結果を先頭ページに記載する、という順番で作業をしていました。チェックリストの確認に数日を要する場合もあり、同時に複数の作業をしている時に判定対象が何なのかという最低限の情報が無いと、混乱するからという単純な理由からです。
リリース判定のための４つの仕組みについて、紹介してきましたがいかがでしたでしょうか。 ソフトのリリースにあたっては確認が必要な項目が多くあります。できるなら、複数の担当者で分担して、相互にレビューをしながら作業を進められると良いですね。