リリース判定のステコミ発表バージョン

リリース判定（本稼働判定）のベースはエクセルで作成しますが、ステアリングコミッティ（以下、ステコミ）で発表する場合は見栄えのよいパワーポイントに整えていきます。

リリース判定エクセルは、以下を参考にしてください。
リリース判定／本稼働判定の作り方（サンプル画像付き）

リリース判定の考え方や進め方については、以下コラムを参照してください。
リリース判定こそが品質を高める最後の切り札

 

リリース判定のステコミ発表バージョンサンプル

 
 

リリース時に100点満点はありえない

リリース判定の3回目を「80点」としている理由を補足しておきます。

経験則として、リリース時に100点満点はありえないと考えているからです。

80点までは比較的早く到達できますが、そこから残り20点をとるのに時間がかかりすぎます。

難易度の高い修正や時間のかかる修正ばかりが残っています。これらを全て対応するのは現実的ではありません。

さらに、残りの課題は、相対的に重要度も下がっていきます。

一部の業務のみ影響する課題やイレギュラー機能についても、ユーザーは対応してほしいと要求するでしょう。

しかし、そもそもユーザーの声をすべて拾い上げるのが、本当に正しいのでしょうか。

残り20点をとるための追加費用と失われる時間は、見合うものでしょうか。

それよりは「経営判断」として、残り20点のリスクは許容し、あとは「走りながら修正する」という判断が現実的だと考えます。

リリース後の半年は障害トラブル対応でとても大変だと思います。ユーザーもベンダーも最優先で本番障害に対処していかないといけません。私も何度も経験していますが、突発的な残業や休日出勤などで生活リズムも乱れ、生きた心地がしません。

しかし、それがもっとも早く品質が安定し、収束する方法なのです。

逆に本番障害になっていないものは優先度が高くないので、後回しになっていきます。ユーザーの過剰な要求はここで淘汰されていきます。慣れの問題で解決する課題も増えていきます。

早くリリースすることで、他の対応に労力を回せますし、それにより機会ロスを防ぐことにも繋がります。

リリース判断は、ユーザーの意見も聞くべきですが、最後は機会損失とリスクを天秤にかけた総合的な「経営判断」なのです。

80点で「リスクテイク」していきましょう！

 
 

（↓関連記事↓）
リリース判定／本稼働判定の作り方（サンプル画像付き）
リリース判定こそが品質を高める最後の切り札

 
 

＊＊＊＊＊
 
 
※ 弊社で公開しているサンプルについては、基本的に画像のみの提供とさせていただいております。ファイルデータのダウンロードを可能とすると、内容の吟味をせずにそのまま流用し、トラブルに発展する可能性があるためです。画像データから文字起こしを行う過程で、それぞれのプロジェクトの状況に合わせてアレンジしていただければ幸いです。