リリース判定という闇

 

 

　 Tweet 　

シェア

　

みなさんは、リリース判定というものをご存じでしょうか？

開発をしたことある人は耳にしたことがある程度かもしれません。

PM, PLをしたことがある人はいい思い出がないものかもしれません。

 

そんなリリース判定についてのご紹介と存在意義について話していこうと思います。

※  私の経験則から記載しますので、ウォーターフォール、かつ、定量型の判定が主になっております。

 

リリース判定とは

リリース判定とは、リリースしてよいかを判定するモノです。

（そのままですね）

 

これは、大抵、企画した人（提案者）が企画を受けた人（お客や上長）に対して行うもので、開発について、こういうことをしたのでリリースしてよいですか？

と伺いを立てるモノとなります。

では、どのように伺いを立てるのかというと、リリース判定をする場合、合格ラインが規定されています。

その合格ラインに沿って、開発もするので、本来であれば、「合格ラインまで、ちゃんとやってるよね」 というチェックのみになります。

 

開発計画という合格ライン

リリース判定をする際の合格ラインとして開発計画を行います。

 

どのようなことをするかというと、開発するにあたり、以下を決めます。

• どの程度のバグが出るか
• ライン数や機能数（画面や機能）に対し、何個バグが出るかを決める
  
• どの程度のテストをするか
• ライン数や機能数（画面や機能）に対し、何個テストするか決める
  
• 性能はどの程度か
• 単体、負荷、ロングランテストのレスポンス時間などを決める
  
• セキュリティはどの程度か
• どの程度のセキュリティを担保するかを決める
  
• どのような機能を作るか
• リリースで入れる機能を決める
  
• どのような運用をするか 
• リリースする機能についてどのように運用するかを決める
  

 

上記に向かって、開発をするだけですので、基本的にリリース判定でごちゃつくことはありません。

もし、ハレーションが発生するのであれば、それは開発時であって、リリース判定直前ということはないはずです。

 

 

リリース判定で準備するもの

リリース判定で実際、準備するモノは以下になります。

• リリースする機能一覧
  
• インフラ構成図（概要）
• 各工程のテスト数とバグの数
• 各工程のバグ分析
• セキュリティ診断結果
  
• 性能結果
  
• 運用方法
• 成果物一覧
  
• 問題ないことの総括
• デモ
  

 お偉いさんへの報告なので、資料はパワポでまとめます。

 

リリースする機能一覧

これは、機能の名前と概要を書くだけです。

詳細は設計書を見るものなので、成果物一覧参照でよいでしょう。

 

インフラ構成図（概要）

AWS アーキテクチャアイコン などを使い、インフラ構成図を書きます。

こちらも詳細はインフラ設計書をみればよいのですが、書かされることが多いです。

インフラ設計書みればいいのですが、お偉いさんはリリース判定書「だけ」で完結できるようにしたいためです。

 

書く際は、リリースする機能がどこに当たるのかを記載する必要があります。

 

各工程のテスト数とバグの数

結合テスト、シナリオテストなどのテスト実施数と、バグの数を記載します。

なので、テスト仕様書はテスト数がわかるように、バグが出たときはチケット管理などで数がわかるようにしておく必要があります。 

 

指標通りにテストしていて、バグが出ているかを確認します。

テストやバグが少なすぎたり、多すぎたり、する場合は、ちゃんとした理由が必要です。

定量型で指標を出しているのであれば、「条件分岐が少ないリリースだった」など

 

各工程のバグ分析

上記、バグの中に「どのような傾向があったか」「なぜそのバグは発生したのか」などを分析します。

どのような傾向があったかを分析する際は

• 要件漏れ
• 仕様書バグ
• 仕様理解不足
• 実装ミス
• デグレード
• 環境依存
• 再現性低
  

というようなものを出し、発見されたバグが何であったかをまとめます。

これにより、バグについてどこが原因であったかを分析します。

 

次に、なぜそのバグは発生したのか、バグに関して、直接的な原因や根本的な原因は何か分析します。

よく言われる「なぜなぜ分析」です

 

セキュリティ診断結果

内部セキュリティチェックや、外部セキュリティ会社へ依頼したチェックの結果と対処内容を記載します。

セキュリティ診断では、優先度を設け、優先度低のものは別途対応となることが多いです。

 

性能結果

単体性能、負荷性能、ロングランテストの結果を提示します。

 

単体性能：1リクエスト1レスポンスの性能

負荷性能：需要予測（繁盛期など）をもとに算出されたアクセス数に対する性能

ロングランテスト：需要予測（平常時）をもとに算出されたアクセス数での長時間テスト

運用方法

リリースした機能に対する運用方法を記載します。

基本的には運用設計書に書くので、そちら参照程度でもいいものです。

 

成果物一覧

リリースした際に作成した成果物一覧を記載します。

 

問題ないことの総括

最後の総括として、全て合格したのでOKくださいと書きます。

 

デモ

最後に、資料ではないのですが、作成した機能についてデモンストレーションを行います。

 

これは基本的にシナリオを作成し、デモではそのシナリオに沿って実施します。

※ 決して、適当に触ってもらうものではありません。

 

このデモでバグが発見された場合はリリース不可になります。

 

闇部分

合否について

さて、リリース判定について、つらつらと書いてきましたが、めちゃくちゃ合格が大変そうに見えませんでしたか？

 

しかし、私は、リリース判定で不合格になったことはありません。

 

私が超優秀なのかと言われたら、答えはNOです。

理由としては、リリース判定は単純に不合格にならないものだからです。

 

なぜなら、リリース判定はリリースの一週間前、短いものだと2日前とかに行うもので、それが不合格の場合、リリースを延期する必要があるからです。

 

あまりにもひどいものであれば、もしかしたらリリース延期になるのかもしれませんが、合格ラインに届いていなくても大抵OKになります。

 

なんとなくやらないといけないもの

リリース判定はリリースを行う前に「やらなければいけないもの」になっています。

 

しかし、上や客から「やれ」と言われているだけで、実際何をやればいいのかわからないプロジェクトが多いです。

前述した内容をやればよいのですが、それがわかっていません。

 

例えば 

計画がなく、合格ラインがないままリリース判定するモノ

　⇒ とりあえずやったことを報告するだけ

本当に何をするのかわからず、開発物一覧とデモだけをするモノ

　⇒ デモで不具合が出なければOK

 

というリリース判定も少なくありません。

 

そりゃ、絶対合格になりますよね。。。

 

使えない上層のリリース判定

リリース判定の資料を作成するにはメンバの協力が必要不可欠ですが、使えない上層がリリース判定をする場合、情報がなく、資料が作れない状態になります。

そのうえ、バグ分析では、「開発者がバグを出した！」「開発者が全部悪い！！」みたいな分析をするわけです。

 

それにより何が起こるかというと、もっと上の人からの聞き取り調査です。

開発リーダやメンバを呼び出し、なぜなぜ分析をその場で行わされることになります。

 

しかも、もっと上の人が使えない人の場合、責められるような感じになったりもします。

これが、開発者に対するモチベーションをめちゃくちゃ下げるものになります。

次はもうやりたくないと離れていった人を見たこともあります。

 

本来、リリース判定では、基本的にプロセスに対する改善をするもので、人に対する改善をするものではありません。しかし、使えない上層がリリース判定すると、「お前らは何をしていたんだ」になったりするわけです。。

やったことないなら

なんでもそうですが、最初は何もわからないはずです。それは人でもそうですが、プロジェクト、会社としてもそうです。

 

リリース判定はナレッジがたまっていないと難しいものです。

なので、開発が初めての人、プロジェクト、会社であれば、初めてでない人を頼る必要があります。

この業界は派遣が得意分野です。初めてであれば、やったことがある、それを得意とする人を派遣するべきです（これが派遣の本質です）

 

会社が雇った場合、メンバに対して「派遣がなんか言ってるよ。。。」とか思わせないようにちゃんと「このメンバに従ってプロジェクトを回せ」など伝える必要があります。

プロジェクトを急に変えるのは難しいと思いますが、もし、しっかりとリリース判定をしたいのであれば、リリースを遅らせてでもプロジェクトを正常化させる必要があります。

リリース判定が適当であればあるほど、プロジェクトの速度だけは出ますからね。。

 

 

まとめ

いかがだったでしょうか

今回は、リリース判定のことについて記載させていただきました。

 

開発者であれば、あまり意識をしたことがないものかもしれませんが、とても重要な工程になりますので、ちょっとでも興味を持っていただければと思います。

 

もし、上層の人であれば、頭の痛い工程ですよねｗ

私も、判定会議はいつもつらい思いをしていたりします。。。

 

 

 

　 Tweet 　

シェア