─ Go-Liveを日程ではなく、経営判断にするために
お世話になっております。YMGアドバイザリーの山口です。
Vol.26では、プロジェクトを「進める・止める・方向を変える」という三つの選択肢について、誰が、何を基準に判断するのかを考えました。
Vol.27では、方向を変えると決めたとき、納期・予算・スコープ・品質のうち、何を守り、何を変えるのかを取り上げました。
今回は、この意思決定論の三つ目となるテーマです。
「何を満たせば、Go-Liveしてよいのか。」
プロジェクトの終盤で必ず訪れるこの判断を、少し違う角度から考えてみたいと思います。
工程が終わっても、稼働してよいとは限らない
- テストは予定通り終了した。
- データ移行のリハーサルも終え、ユーザー研修も実施した。
-プロジェクトの進捗報告では、主要な工程がすべて「完了」になっている。
- ここまで来れば、あとは予定通りGo-Liveするだけ。
そう考えたくなるのも自然なことです。
ただ、ここで一つ確認したいことがあります。
「工程が終わったこと」と「事業として稼働できる状態になったこと」は、同じでしょうか。
例えば、フィールドサービスのシステムであれば、顧客からの依頼が受付から作業手配、現場対応、完了報告、その後の請求や改善活動まで、滞りなくつながるでしょうか。
現場は日常業務を問題なく回せるでしょうか。
想定外のケースが起きたとき、対応方法は決まっているでしょうか。
重大な障害が発生しても、業務を継続したり、復旧したりできる体制は整っているでしょうか。
テストや研修の完了は、もちろん大切です。
しかし、それらは稼働を判断するための根拠であって、それだけで稼働を承認できるとは限りません。
工程が完了したかどうかと、事業として稼働を認めてよいかどうかは、分けて考える必要があります。
なぜGo-Liveは「判断」ではなく「日程」になるのか
Go-Liveの日付は、プロジェクトの早い段階で決められることが多いものです。
経営会議で報告され、関係部門に周知され、場合によっては取引先にも伝えられます。
ベンダーの契約や体制、旧システムの運用終了、予算計画なども、その日付を前提に組み立てられていきます。
こうなると、予定日を変更することは簡単ではありません。
しかも、それぞれの立場には、日付を守りたい合理的な理由があります。
- 経営層は、すでに承認した計画を予定通り進めたい。
- 推進責任者は、ここまで積み上げてきた成果を形にしたい。
- ベンダーは、契約上のマイルストーンを達成したい。
- 現場も、新しいシステムへの切り替えに向けて準備を進めている。
誰かが不誠実だからではありません。
それぞれが自分の役割を果たそうとするほど、日付を動かしにくくなるのです。
その結果、本来は、
「どの条件を満たせばGo-Liveできるのか」
と考えるべきところが、
「予定通りGo-Liveするために、残った課題をどう処理するか」
という議論に変わってしまうことがあります。
Vol.22で取り上げた「計画書の呪縛」は、プロジェクトの最後にも現れるのです。
「条件付きGo」は、何を条件にしているのか
Go-Liveが近づいても、未解決の課題が残ることはあります。
そこで出てくるのが、「条件付きGo」という判断です。
「この問題は稼働後に対応する」
「当面は運用でカバーする」
「追加の対策を講じながら稼働する」
こうした判断が、すべて間違っているわけではありません。
重要なのは、
稼働前に必ず解決しておくべき問題と、稼働後の対応でも事業への影響を許容できる問題を、きちんと区別すること
です。
例えば、請求金額が正しく計算されない問題と、管理画面の一部の表示が崩れる問題では、事業に与える影響が大きく異なります。
もちろん、表示上の問題であっても重要な判断を誤らせるのであれば、軽視できません。
つまり、単に不具合の件数や重要度のラベルを見るのではなく、その問題を抱えたまま事業を開始した場合、どのような影響が出るのかを確認する必要があります。
稼働後の対応が許容できる問題であれば、暫定的な対応方法、責任者、解消期限、確認方法を決めたうえで、Go-Liveを承認することもあるでしょう。
その場合でも、問題が想定以上に拡大したときに、誰が、どう対応するのかを明確にしておかなければなりません。
一方、稼働に不可欠な条件を満たしていないのであれば、単に「条件付き」と呼び替えても、リスクが小さくなるわけではありません。
大切なのは、課題が残っているかどうかではなく、その課題を抱えたまま事業を開始してよいと、何を根拠に判断できるかです。
Go-Live直前には、止める判断が難しくなる
Go-Liveが近づくほど、予定を変更するための組織的な負担は大きくなりがちです。
すでに利用部門へ案内している。
旧システムの運用終了も迫っている。
ベンダーの体制も切り替わる予定になっている。
そんな状況で、
「やはり稼働を延期した方がよいのではないか」
と提案するのは、簡単ではありません。
ここでも、個人の勇気や能力だけの問題ではないと思います。
最も判断が難しくなる時点で、初めて判断基準を決めようとしていること自体が問題なのです。
だからこそ、Go-Liveの条件は、直前になって初めて議論するのでは遅いのです。
Vol.26でお伝えしたように、判断が必要になってから権限や基準を考えるのではなく、プロジェクトの開始時から設計しておく必要があります。
経営が事前に決めておくべき三つのこと
ここでも、Vol.26で整理した三つの要素が役に立ちます。
Authority ─ 誰が判断するのか
まず、Go-Liveを誰が承認するのかを明確にしておく必要があります。
同時に、条件を満たさなかった場合、誰が延期を判断するのか、その手続きも決めておかなければなりません。
PMやベンダーが工程の完了を報告することと、事業として稼働を認めることは別の話です。
ベンダーの契約上の検収と、事業側の稼働承認も、必ずしも同じではありません。
最終的には、事業上の結果に責任を持つ側が、必要な情報を踏まえて判断できる状態にしておくことが重要です。
Criteria ─ 何を満たせば稼働できるのか
ここで必要なのは、工程の完了状況だけではありません。
主要な業務が一通り成立すること。必要なデータが正しく引き継がれ、業務の中で利用できること。現場が通常の業務だけでなく、重要な例外ケースにも対応できること。
さらに、重大な問題が起きた場合の対応方法や、稼働後のサポート体制が整っていることも必要でしょう。
こうした条件を、プロジェクトの目的や事業特性に応じて具体化しておくのです。
Vol.27で「最後まで守るべきもの」を決めたのであれば、その優先順位がGo-Liveの判断基準にも反映されていなければなりません。
例えば、品質を最優先すると決めていたのに、Go-Liveの判断では納期しか確認しないのであれば、その原則は実質的に機能していないことになります。
Accountability ─ 判断の結果を誰が引き受けるのか
そして、もう一つ重要なのが、残されたリスクを誰が引き受けるのかという問題です。
条件付きGoを承認するのであれば、何が未解決で、それが事業にどのような影響を及ぼす可能性があるのかを認識したうえで、判断する必要があります。
そのリスクを受け入れるのは、現場担当者でも、PM個人でもありません。
事業として誰が判断し、その結果に責任を持つのか。
ここが曖昧なままでは、関係者全員が承認したように見えても、実際には誰もリスクを引き受けていないという状態になりかねません。
意思決定とは、承認印を押すことではありません。残されたリスクを理解し、事業として引き受けるかどうかを決めることです。
切り替え手順や移行計画がどれほど整っていても、それだけでGo-Liveを承認できるわけではありません。
事業として何を満たす必要があるのか。
その判断基準を明確にすることが、経営側の重要な役割だと思います。
判断基準も、見直せるようにしておく
ただし、ここで一つ注意したいことがあります。
Go-Liveの条件を事前に決めたからといって、それを最後まで一切変更してはいけないわけではありません。
プロジェクトが進む中で、新しいリスクが見えてくることもあります。
事業環境が変わり、当初の前提が成り立たなくなることもあるでしょう。
その場合には、判断基準そのものを見直す必要が生じるかもしれません。
ただし、予定日を守るために条件を緩めることと、新たに分かった事実を踏まえて条件を見直すことは、同じではありません。
また、安全性や法令遵守など、安易に緩めてはいけない条件もあります。
大切なのは、
誰が、どのような根拠で条件の変更を認め、その結果生じるリスクをどう引き受けるのか。
そこまで含めて決めておくことです。
Vol.22では、「計画は更新されるべき仮説である」と書きました。
Go-Liveの判断基準も同じです。
条件を決めることは重要ですが、その条件を守ること自体が目的になってはいけません。
現実に照らして判断基準を見直せること。そして、その変更も正式な意思決定として扱うこと。
この二つがあって初めて、判断基準は機能するのだと思います。
延期は、必ずしも失敗ではない
Go-Liveの延期が必要になった背景には、計画や実行上の問題があるかもしれません。
それについては、当然、別途振り返りや検証が必要です。
しかし、必要な条件を満たしていないことが分かっているのに、予定日を守るためだけにGoを出すことが、正しい判断とは限りません。
経営が比較すべきなのは、
延期することで発生するコストと、条件を満たさないまま稼働した場合に生じるリスクやコスト
です。
稼働を延期すれば、追加費用が発生するかもしれません。関係者への説明も必要になります。
一方、無理に稼働した結果、業務停止や大量の手戻りが発生すれば、その影響はさらに大きくなる可能性があります。
ここでも、Vol.23で取り上げた「コストの非対称性」を示すことが役に立ちます。
延期した場合の影響と、そのまま稼働した場合に想定される影響を、できる限り具体的に比較する。
それによって、議論を「予定を守るべきか」という感情的な対立から、「事業としてどちらのリスクを引き受けるべきか」という判断へ移すことができます。
延期することが常に正しいわけではありません。
重要なのは、予定日を守ることも、延期することも、根拠を持って判断できる状態になっているかどうかです。
DX推進責任者・PMOの皆さんへ
もし、今進めているプロジェクトでGo-Liveの条件が曖昧だと感じているなら、稼働直前になって、
「このままでは危険なので、止めましょう」
と訴えるよりも、できるだけ早い段階で、次のように問いかけてみてください。
「私たちのプロジェクトでは、何を確認できればGo-Liveを認められるのでしょうか。また、その最終判断は誰が行うことになっていますか。」
これは誰かの判断ミスを責める質問ではありません。
プロジェクトを成功させるために、経営や関係者と一緒に、判断の仕組みを確認するための問いです。
判断基準がまだ決まっていないのであれば、今からでも整理を始める価値があります。
条件を明確にすることは、プロジェクトを止めるためではありません。
安心して進めるために、何を確認すべきかを明らかにすることです。
三つの意思決定に共通していたこと
Vol.26から、三つの意思決定について考えてきました。
Vol.26では、進めるか、止めるか、方向を変えるか。
Vol.27では、何を守り、何を変えるか。
そしてVol.28では、何を満たせば稼働してよいのか。
一見すると、それぞれ別の判断に見えます。
しかし、共通していることがあります。
それは、判断を先送りするほど、選べる選択肢が狭くなっていくということです。
- 問題が見えたときにRedirectを判断できなければ、計画の修正は難しくなる。
- 何を守るかを決めなければ、現場で非公式なトレードオフが起きる。
- Go-Liveの条件を決めていなければ、最後は予定日を守ることが優先されやすくなる。
いずれも、誰か一人の能力や勇気で解決できる問題ではありません。
プロジェクトの成否を左右するのは、問題が起きたときに、誰かが勇気を出して正しい判断をすることだけではないのです。
問題が起きる前から、誰が、何を基準に判断し、その結果を組織としてどう引き受けるかを考えておくこと。
判断が必要になったときに、判断できる状態をつくっておくこと。
それが、ここまで考えてきた「意思決定の設計」の本質だと思います。
Vol.25では、「正しい体制は、必要条件に過ぎない」と書きました。
体制を整え、問題を見つけられるようにすることは重要です。
しかし、見つけた問題に対して、組織として判断できなければ、プロジェクトは変わりません。
体制が「誰が何を見るか」を決めるものだとすれば、
意思決定の設計は「見えた現実をもとに、どう動くか」を決めるものです。
この二つが揃って初めて、DXプロジェクトは現実に合わせて進むことができるのではないでしょうか。
YMG Advisoryでは、プロジェクトの進捗や体制だけでなく、納期、予算、スコープ、品質の優先順位が明確になっているか、そのトレードオフを誰が判断するのかについても、第三者の視点から整理しています。
「Go-Liveの日付は決まっているが、稼働条件が曖昧になっている」
「課題が残っているものの、どこまで許容してよいか判断できない」
「経営層に延期や条件変更を相談したいが、どう説明すればよいか分からない」
そのような状況にある方は、ymg-info@ymg-advisory.comまでお気軽にご相談ください。