こんにちは。わさお(@wasataka)です。
今回はシステム/業務リリース時のリリース判定基準を明確にするための「リリース判定表」の作成方法について解説します。
ちなみに、「リリース判定基準」のことを、「カットオーバークライテリア」だったり、「稼働判定基準」と言うこともありますが、ここでは「リリース判定基準」に統一いたします。
目次
1.リリースの種類
まず、リリースの種類について、説明します。
リリースと言っても、いくつか種類があり、きちんと定義することが大事です。ここでは、「システムリリース」と「業務リリース」について紹介します。
システムリリース
システムリリースとは、開発したシステムモジュールを検証環境から本番(商用)環境へ移行することです。
本番環境へ移行する際は、既存のシステムに影響を与えるため、細心の注意を払う必要があります。
そのため、システムリリース時は、既存システムを停止して、移行作業が行われることが多いです。
業務リリース
実際の業務・運用を開始することです。
業務リリースでは、システムの準備が整っていることに加えて、業務面での準備や体制が整っているか、なども判定基準になります。
2.リリース判定の目的
リリース判定は新システムを現場で稼働させて良いかを判定するもので、現在の準備状況を総合的に判断します。
そして、リリース判定にはプロジェクトリーダーやプロジェクトマネージャーはもちろん、現場関係者も集めて判定するのが望ましいです。
システムリリース後に現場でトラブルが起きた場合は、社内だけでなく、社外関係者にも影響を及ぼす可能性があるため、リリース判定は慎重に行うべきです。
また、ベンダー主導で行うのではなく、必ず自社主導で行うべきです。システム面だけでなく、業務面の状況も踏まえて判断できるのは、自社のみだからです。
3.移行方針のパターン
リリース判定は、移行方針によって2パターンに分かれます。
①一斉切替パターン
②並行切替パターン
①の一斉切替パターンとは、旧システムと新システムの切替をある時点で一斉に行うパターンのことです。この場合は一斉切替前にリリース判定を行います。
②の並行切替パターンとは、旧システムと新システムを一定期間並行稼働させる場合です。この場合、「並行稼働判定」と「本番稼働判定」の2段階で判定を行います。
「並行稼働判定」は、多少の問題があっても修正していくことが可能なため、局所的な問題であれば、OKという判定を出すことも出来ます。
4.リリース判定の評価項目
4-1.システム観点
まずは、システム観点の評価項目について説明します。
受入試験・FTのシナリオ完了率
リリース判定には、受入試験やFTの結果を使うことが多いと思います。シナリオ完了率は受入試験やFTが完了しているかの最も基本的な指標と言えるでしょう。
【入門編】受入テスト仕様書作成の4ステップ(シナリオ・テスト観点のサンプル有り)
障害対応完了率
受入試験やFTの際に発生した障害の対応が完了しているかもチェックポイントの一つです。システムでの修正が難しい障害の場合は、ワークアラウンド(応急措置)の方法が決まっているかどうかが重要です。
システムパフォーマンス
システムが実運用に耐えうる仕様になっているかもチェックするべきと言えます。例えば、「同時アクセス可能数」「レスポンスタイム」などの項目は、実業務をスムーズに回すために重要です。
非機能要件定義で押さえるべき6つの観点について(サンプルあり)
4-2.業務観点
マニュアルの作成・配布
実際に業務に使う人たち向けのマニュアルが作成されているか、また配布されているかも重要な観点です。リリースしても現場の人が使い方が分からない状態では意味がありません。
研修・説明会の実施状況
現場で利用するユーザー向けの研修や説明会を実施するのも良いでしょう。実施する場合は、それらが完了しているかなどを判定基準に利用します。
体制の構築状況
業務開始後の「障害対応」「問い合わせ対応」「トラブル時の連絡体制」など、何かが発生したときにスムーズに対応できるよう体制構築をしておく必要があります。
どの部署(もしくは個人)がどういう役割で体制に入るのかを明確にしておきましょう。
4-3.環境観点
システム環境
システムが商用環境でちゃんと動くかどうかの観点になります。移行を伴う場合は、移行完了が基準になります。
ユーザー環境
ユーザーの利用環境も確認しておくのがベターです。例えば、「問い合わせ先」「利用フォルダ」「オンラインマニュアル」など、実際に利用するユーザー目線で考えるのがポイントです。
5.リリース判定チェックリストのサンプル
リリース判定チェックリストのサンプルです。下のダウンロードボタンを押してもらえれば、保存できます。
6.リリース判定チェックリストの作成方法
稼働判定評価表を作成するには、以下の点を意識しましょう。
①客観性を確保する
②網羅性を確保する
①の客観性を確保するためには、定量的な評価を行う必要があります。そのためにも、これまでの工程で利用したエビデンス(受入テスト管理表やユーザー研修アンケートなど)を残すことが重要です。
②の網羅性を確保するためには、どのような項目で評価するかが重要です。システム開発の評価を行うのは当然ですが、業務観点や運用観点の評価も忘れないように評価基準に加える必要があります。
6-1.項目
分類
稼働判定に必要な要素を洗い出し、分類します。
この記事のサンプルでは例として以下のような分類を挙げております。
・受入テスト
・ユーザー研修
・残課題
・データ移行
・インフラ整備
評価項目
分類の中で評価すべき項目を洗い出して記載します。
エビデンス
評価項目のエビデンスを記載します。そのために、エビデンスは必ず残しておきましょう。
定量評価
評価項目に対しての評価を定量的に示します。
定性評価
評価項目に対しての評価を定性的に示します。
判定
上記の評価に基づき、〇か×で判定を記載します。
基本的には、×が一つでもあるとシステムリリース不可という評価になります。
7.リリース判定の注意点
稼働判定時には、基本的にOKをもらえるよう事前に根回しをしておくべきです。業務リリースが遅れることで、会社全体にも影響を与えるためです。
もし、オーナーから承認をもらえないとしたら、それはプロジェクトマネージャーの責任です。稼働判定前に、システムサイド・業務サイド・オーナーとのコミュニケーションを積極的にとり、それぞれの意向を確認しておきましょう。
8.参考書籍
こちらの本は、システム開発の一連の流れを発注者目線で書いた本です。システム開発の一連の流れが実例とともに具体的に書かれているので、経験値を増やすのにも役立ちます。
稼働判定基準についても書かれていますので、ぜひ参考にしてみてください。
9.【まとめ】リリース判定は念入りに準備して臨もう
いかがでしたでしょうか。
今回はシステムリリース時の稼働判定評価表の作成方法について解説しました。
万全な準備をもって、システムリリースに臨みたいものですね。
↓↓このブログが少しでもお役に立ったならば、応援クリック頂けると嬉しいです！↓↓
