DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は工程完了判定基準がプロジェクトにおける問題を発見するための「過去に着目した物差し」であるということを考察しました。今回はシステム開発プロジェクトの最後の関門である（学校でいえば卒業試験のようなもの？）、カットオーバー・クライテリアについて考えてみます。

【　カットオーバー・クライテリアとは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
カットオーバー・クライテリア（cut-over criteria）という言葉はあまり聞きなれないかもしれませんが、移行判定基準とか、本番稼働判定基準とか、日本語にしてみればどんなものかなんとなく想像がつくと思います。システムの要件定義・基本設計から、開発・テスト工程を経て、最終的に開発したシステムの本番稼働に進んでよいかどうかを判断するための物差しのことです。前回テーマにした工程完了判定基準のうち一番最後のタイミングで実施されるものととらえるとなんとなくイメージできるかもしれません。

一般的にカットオーバー・クライテリアは、以下のような判断基準について、各プロジェクトの特性に応じて具体的に示したものとなります。

＜　カットオーバー・クライテリアに含める判断基準（例）　＞

1.  新システムの稼働に必要なシステム開発・機器の設置が完了していること
2.  新システムの稼働に必要なシステムや機器のテストが実施され、品質基準を満たしていること
3.  新システムに移行するための準備やリハーサルが全て完了していること
4.  新システムを運用するために必要な業務手順書等の準備が完了し、必要な教育がされていること
5.  新システムを運用・保守をするための体制が準備されていること
6.  新システムへの移行・本番稼働に際し、不測の事態が発生した場合の対応計画（コンティジェンシープラン）が明確であること

先ほどカットオーバー・クライテリアは工程完了判定基準のうち一番最後のタイミングで実施されるものと書きましたが、実際はプロジェクトの途中段階での工程完了判定基準とは少し意味合いが異なるものとなります。工程完了判定基準は、その工程で行うべきことの「全てがきちんと」行われたかどうかを判定するのに対し、カットオーバー・クライテリアは「このまま本番稼働しても良いか」を判断することが目的であるため、少しニュアンスが異なります。

たとえばこんな場面を想像してみてください。なんらかの原因（たとえば仕様変更の多発など）によりプロジェクトの進捗状況は大幅に遅延していたとします。しかし、さまざまな事情によりシステムの本番稼働時期をずらすことは出来ない（本番稼働時期をずらすと組織として大きなマイナスとなる場合など）こともあります。そんなとき、もちろん進捗を回復すべく努力はすると思いますが、限られた時間内にできることは自ずと限られているため、本番稼働に優先的に間に合わせる必要があるものと、本番稼働後にキャッチアップすればよいものを切り分け、優先順位の低いものが少し残っていても本番稼働に進むことを判断するケースもあり得るはずです。

つまり、工程完了判定基準は「全てがきちんと」という100点満点を目指すのに対し、カットオーバー・クライテリアは「本番稼働に必要な」という赤点では無いことを目指すぐらいのニュアンスの違いがあります。そのニュアンスの違いがもう少しわかりやすくなるよう、カットオーバー・クライテリアと対比する形で、一般的な工程完了判定基準に含める判断基準の例を以下に示します。

＜　工程完了判定基準に含める判断基準（例）　＞

1.  その工程で実施すべきタスクが全て完了していること
2.  その工程で作成された成果物のレビュー（テスト）が全て実施され、摘出された不具合の対策が全て完了し、品質基準を満たしていること
3.  その工程で作成された成果物について、必要とされる承認が全て得られていること
4.  未完のタスクや品質基準未達の成果物があった場合、次工程以降への影響が限定的で、次工程の開始に影響が無いこと、およびリカバリプランが明確となっていること
5.  次工程の計画が詳細化されており、実現可能性が検証されていること
6.  次工程以降を進めるにあたり、プロジェクト目標に影響を及ぼすかもしれないリスクが再評価されており、必要な予防策が計画に組み込まれていること

もちろん、稼働判定会議においても100点満点を目指すのが理想ではありますが、カットオーバーするかしないかは組織にとって重要な判断であることが多く、カットオーバー時期をずらすことになったらいろいろな調整が必要となるため、できる限りカットオーバーをずらさず不時着させることがプロジェクト・マネージャーの責務だと私は考えています。ただし、組織の戦略やプロジェクトの特性に応じて、納期より品質重視という場合もあり、何を最優先のプロジェクト目標とするかをプロジェクト計画書に明確に定義し、関係するステークフォルダーと合意した上で、その合意事項をカットオーバー・クライテリアの中に明確に示す必要があります。

【　本番稼働準備状況の確認という視点　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
前章では、カットオーバー・クライテリアというものを、プロジェクトを実行することで構築した新システムが赤点ではない、すなわち本番稼働に必要な品質が確保されているかどうかを判断するものという視点で見ましたが、もうひとつ重要な視点として、本番稼働の準備が十分できているかという判断基準も含まれていることを忘れてはいけません。

システム開発のプロジェクトでは、どうしても新システムの開発・構築がきちんとできているかということに目が行ってしまいがちですが、その新システムを使って現場の業務を運用することで、システム化の目的を達成することがプロジェクトの最終目的になります。新システムを構築したものの、運用の準備が整わずに、現場の利用者が旧システム利用や手作業を続けてしまったら、元も子もありません。

せっかく苦労して構築した新システムを十分に活用してもらうためには、さまざまな準備作業が必要となり、新システムの運用準備タスクとしてプロジェクト計画に盛り込まれ、それらのタスクの実施状況に関する確認ポイントをカットオーバー・クライテリアに含めて、稼働判定会議にて確認することになります。たとえて言えば、カットオーバー・クライテリアには、卒業試験（赤点ではない）と就職試験（社会貢献の準備完了）の両方の要素が含まれていることになります。

「カットオーバー・クライテリアとは、
システム開発の卒業試験　兼　就職試験だ！」

仮に稼働判定会議の場で本番稼働を迎えるための準備の不足に気付いた場合、そのリカバリーを図るための十分な時間と追加のリソースが必要になってくる場合があります。新規に開発するシステムでは、新システムを利用した業務の運用は未知のことであり、さまざまなイレギュラーケースも十分想定して準備を行う必要があります。したがって、何か準備の漏れが発覚するリスクも高い場合があるため、このようなリスクが顕在化した場合の備え（リスク予防策）が必要になります。

上記のリスク予防策のひとつとして、稼働判定会議の開催をカットオーバー予定日を起点にし、十分なリカバリー対策が実施可能な期間を逆算して設定することがあります。リカバリー対策が実施可能な期間は、プロジェクトの特性や規模に応じてまちまちではありますが、概ね1年以上の大規模システム開発プロジェクトの場合、本番稼働予定日の3ヶ月前には大きな取りこぼしが無いことを確認する必要があると思います。その後も、本番稼働1ヶ月前、１週間前、3日前などの何段階かのポイントで稼働判定会議を行うことにより、本番稼働準備の抜け漏れ防止を図ると安心です。

図１に示すように、稼働判定会議の実施タイミングはシステム開発の工程には関係なく本番稼働予定日を起点に期間を区切って設定するため、工程完了の区切りで実施する工程完了判定の時期と近接する可能性もあります。（図１の例では、本番稼働３ヶ月前の稼働判定会議とシステムテスト／ユーザーテスト工程の工程完了判定会議の実施時期が近接しています。）

そのような場合は、稼働判定会議と工程完了判定会議の目的は異なりますが、どちらもプロジェクトの意志決定を行うための会議体であり、参加メンバーも重複することが多く、近接する稼働判定会議と工程完了判定会議を合わせて実施するなど、効率的な会議運営を行うと良いでしょう。

それでは、次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～