リリース判定の直接的な使い方

リリース判定(本稼働判定)の直接的な目的は、以下の通りです。

「新システムを本番稼働させてよいか判定すること」

利用シーンとしては「リリース判定会議」となります。

ここで関係者の最終的な承認をとり、会社として正式に本番稼働が決定します。

ちなみに、現場によっては、「クライテリア判定」「カットオーバークライテリア」「サービスインクライテリア」などと、カッコいい呼び方をするところもあるので、ドヤ顔で使い分けてください(笑)

 
 

あまり知られていない本当の使い方

リリース判定は、リリース直前の「一発判定」のイメージが強いかもしれません。

しかし、弊社の使い方はそれとは少し異なります。

本番リリースを予定通りに進捗させるためには、関係者に対して事前に以下を周知しておく必要があります。

「この項目をクリアしたらリリースできますよ!」

そのため、弊社ではリリースの2〜3ヶ月前から、このリリース判定表を用いて、判定状況を「リアルタイム」に共有するようにしています。

「社内進捗会議」「ベンダー進捗会議」「ステアリングコミッティ」など、様々な定例会で共有します。

定例会なので、時間が経つにつれ、判定結果「OK」の項目が増えていく様子を見せられます。

そこで、関係者のリリースに向けた意識を高めることができるのです。

「OK」となっていない項目について、担当者は危機感をもって対応することになります。遅れが目立つと、管理者や経営層もテコ入れで動き出します。

ベンダーに対しては、内部情報を見せるのは抵抗があるかもしれません。しかし、もはや一蓮托生です。状況を共有し、お互いに協力し合って、残りの課題を潰していく方が圧倒的に状況が好転していきます。

リリース判定項目を2〜3ヶ月かけて、関係者全員で残課題を潰していく流れを作ることが重要です。

リリース判定は「最後の進捗資料」として活用することがポイントとなります。

 

リリース判定(詳細版)

リリース判定の基本的な項目は、共通しています。

ただし、プロジェクト毎に詳細項目は変わってくるため、アレンジは必要です。


(※ 画像をクリックすると、大きな画像が表示されます)

 

リリース判定(サマリ版)

こちらはサマリ版です。ステアリングコミッティなど、経営層向けに簡潔な状況報告をする場合に用います。

詳細版と連動しており、詳細版の結果を積み上げたものが、このサマリ版となります。

そのため、エクセルで数字の部分は詳細版とリンクさせておくと、自動更新されるのでメンテが楽になります。


(※ 画像をクリックすると、大きな画像が表示されます)

 

仕切るのは情シス

最後に、このリリース判定を仕切るのは「情シス」の重要な役目です。

なぜなら、情シスが「経営」と「事業」と「IT」の橋渡しをできる唯一の部署だからです。

ぜひ、このサンプルをアレンジして、経営層、事業部門、そしてベンダーを巻き込み、リリースまでの道筋を立てていきましょう!!

 
 

(↓関連記事↓)
基幹システムは稼働してからが情シスの腕の見せどころ
要件定義終了判定の作り方(サンプル画像付き)
ベンダー提案評価資料の作り方(サンプル画像付き)
 
 

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