#27：全部は、守れない
─ Redirectで問われる「何を守り、何を変えるか」
お世話になっております。YMGアドバイザリーの山口です。
前回Vol.26では、プロジェクトには大きく分けて三つの選択肢があると書きました。
Go ─ そのまま進める。
Stop ─ 一度立ち止まる。
Redirect ─ 方向を変えて進める。
そして、Goだけが自動的に続いている状態は、本当にGoを選んだ結果ではなく、StopもRedirectも選ばなかった結果かもしれない、とお伝えしました。
今回は、その先の話です。
Redirectを選んだとき、次に必ず問われることがあります。
「では、何を守り、何を変えるのか。」
プロジェクトには、三つの選択肢がある
プロジェクトを進めていると、当初の想定とは違う現実が必ず見えてきます。
要件の前提が違っていた。
現場業務とのギャップが想定以上に大きかった。
追加開発が膨らんできた。
データ移行が想定より難しい。
予定していた効果が期待できそうにない。
そんなとき、選択肢を大きく整理すれば三つあります。
Go ─ 現在の基本方針で、そのまま進める。
Stop ─ 一度立ち止まり、必要であればプロジェクト自体を中止する。
Redirect ─ ス コープ、方式、計画などを見直し、方向を修正して進める。
重要なのは、Goだけが「普通の選択」で、StopやRedirectが「特殊な選択」なのではないということです。
どれも、本来は同じように検討されるべき経営判断です。
ところが、実際のプロジェクトでは、三つの中でGoだけが自然に選ばれ続けることがあります。
Stopには「止めた責任」が伴う。
Redirectには「計画を変更した責任」が伴う。
一方、Goは既に承認された計画に沿って進むだけなので、少なくともその時点では、誰か個人の新たな判断として認識されにくい。
そのため、「続ける」という選択だけが、判断を必要としないかのように扱われるのです。
Redirectは、決めた瞬間からが本番
方向修正を決めた瞬間、プロジェクトには新しい問いが生まれます。
当初の前提と、現実が合わなくなってきた。
このままでは進めない。
だから、方向を変える。
ここまでは決められた。
でも、その次に、
「具体的に、何を変えるのか」
を決めなければ、Redirectは実行できません。
プロジェクトの主要な条件を、大きく四つに分けて考えてみます。
納期 ─ いつまでに届けるのか。
予算 ─ いくらまで投資するのか。
スコープ ─ 何を実現するのか。
品質 ─ どの状態なら安心して使い続けられるのか。
Redirectが必要になったにもかかわらず、この四つをすべて固定したままでは、方向を変える余地はほとんどありません。
ところが実際には、
納期は経営に約束している。
予算は稟議で承認済み。
スコープは要件定義で合意している。
品質は当然落とせない。
というように、すべてが「変えてはいけないもの」として扱われることがあります。
その結果、
「全部守りながら、方向だけ変えてください」
という、ほとんど実現不可能な要求が生まれます。
「全部守る」では、何も変わらない
Redirectとは、単に
「方針を見直しました」
と宣言することではありません。
現実が変わったのであれば、前提や条件も見直す必要があります。
何も変えないままRedirectしたつもりになっているのであれば、実質的にはGoとほとんど変わりません。
当初から抱えていた問題を残したまま、
「対応方針を修正した」
という形だけが整ってしまいます。
Vol.22でお伝えした「計画書の呪縛」は、ここでも働きます。
一度承認された納期、予算、スコープを変えることが、
「当初計画が間違っていたと認めること」
のように受け取られる。
だから、誰も動かしたくない。
でも、本当のRedirectには、
「何を変えてよいのか」を決める判断
が必要です。
何かを削ること自体が目的なのではありません。
最も大切なものを守るために、他の条件を調整する。
それがRedirectです。
納期を守るなら、何を動かすのか
まず、納期を最優先にするケースを考えてみます。
リリース日は、経営層への約束になっていることがあります。
市場投入のタイミングが重要な場合もあります。
法令対応などで、簡単には動かせない日付であることもあります。
そうであれば、納期を守るという判断には十分な合理性があります。
ただし、その場合は、
納期を守る代わりに、何を動かすのか
を決めなければなりません。
一部のスコープを後続フェーズに回すのか。
追加予算を使って体制を補強するのか。
実装方法そのものを見直すのか。
問題は、
「納期は絶対です。予算も増やせません。スコープも変えません。品質も落とさないでください」
となったときです。
こうなると、表向きには何も変えていなくても、実際には現場のどこかで何かが削られます。
テストの範囲が狭くなる。
教育期間が短くなる。
例外処理が「運用でカバー」に回される。
将来の保守性が後回しになる。
つまり、
正式にトレードオフを決めなければ、現場で非公式なトレードオフが起きます。
予算を守るなら、それは何のためか
次に、予算です。
承認済みの予算を超えるには、追加稟議や経営承認が必要になることがあります。
そのため、
「何とか今の予算内で収めてほしい」
という判断が出る。
これも、経営判断としては十分あり得ます。
ただし、一度確認したいことがあります。
予算上限そのものが重要なのか。 それとも、再承認の手続きを避けたいだけなのか。
この二つは、似ているようでまったく違います。
本当に投資上限が決まっているのであれば、その範囲内で何を実現するかを組み直す必要があります。
一方で、
「もう一度稟議を通すのが大変だから」
という理由で必要な投資を避けているのであれば、それは予算の問題ではなく、意思決定プロセスの問題です。
予算を守るなら、
スコープを縮めるのか。
納期を延ばすのか。
実装方法を変えるのか。
その影響まで含めて判断する必要があります。
スコープを守ることが、価値を守ることとは限らない
スコープも、変更しづらい条件の一つです。
要件定義で合意した。 RFPに書いてある。 契約上の成果物になっている。
だから、
「全部作ること」
が成功の条件のように見えます。
でも、当初のスコープをすべて維持することで、
納期が遅れる。
予算が増える。
品質確認の時間が足りなくなる。
ということもあります。
そのとき、問うべきなのは、
「この機能は、本当に今必要なのか」
です。
すべての機能を予定通り作ることと、事業上重要な機能をしっかり使える状態で届けることは、同じではありません。
Redirectの局面では、
「最初に決めたから守る」
ではなく、
「今の現実でも、それを守ることが本当に重要なのか」
を問い直す必要があります。
品質は、最も後回しにされやすい
四つの条件の中で、品質は最も声が小さくなりやすいものです。
納期遅延は、すぐに分かります。
予算超過も、数字ですぐに見えます。
スコープ変更も、機能一覧を見れば分かります。
でも、
保守しにくくなった。
構造的な負債が増えた。
将来の拡張が難しくなった。
といった問題は、その場では見えにくい。
Vol.21で取り上げた、
Closed-loopの断絶。
As-Mantained BOMとの不整合。
Bolted-onによる将来負債。
こうした構造品質の問題は、今日の進捗会議ではGreenに見えていても、後から大きな負担として表面化します。
リリース後の手戻り。
バージョンアップ時の追加改修。
現場で増え続ける例外運用。
次期システムへの移行負荷。
品質に関する設計や確認を後回しにするということは、そのコストを未来へ送るということです。
だからこそ品質は、
「時間に余裕があれば守るもの」
ではなく、
どこまでを絶対条件とするのか、最初から決めておくべきもの
です。
この判断を、PMだけに背負わせてはいけない
では、
納期、予算、スコープ、品質。
この優先順位を、誰が決めるのでしょうか。
これは、PMだけに背負わせるべき判断ではありません。
もちろんPMには、
トレードオフの選択肢を整理する。
それぞれの影響を可視化する。
リスクを説明する。
意思決定者に提言する。
という重要な役割があります。
しかし、
「納期を守るために、どの機能を後ろに回すのか」
「追加投資をしてでも品質を守るのか」
「市場投入時期と将来の保守性をどう比較するのか」
といった判断は、最終的にはビジネス上の優先順位を決める話です。
プロジェクトスポンサー。
事業責任者。
ステアリングコミッティ。
場合によっては経営層。
ビジネス上の結果に責任を持つ側が、判断に関与する必要があります。
Vol.24でお伝えしたPMへの過剰な期待を、ここでも繰り返してはいけません。
「絶対に守るもの」と「変えてよいもの」を分けておく
Vol.26では、意思決定を機能させるためには、
Authority ─ 誰が判断するのか。
Criteria ─ 何を基準に判断するのか。
Accountability ─ 判断結果を誰が引き受けるのか。
この三つが必要だと書きました。
今回のVol.27では、もう一つ加えたい視点があります。
それは、
「絶対に守る条件」と「状況に応じて変えてよい条件」を、あらかじめ分けておくことです。
例えば、
Go-Live日は法令上、動かせない。
安全に関わる要件は絶対に削れない。
一部の便利機能は後続フェーズへ回せる。
一定範囲の追加予算はスポンサー権限で承認できる。
こうした境界が決まっていれば、Redirectが必要になったときに、
「結局、何を守るのか」
というところから議論を始める必要がありません。
議論を、
「何を、どこまで変えるのか」
に進めることができます。
この違いは、意思決定のスピードにも、質にも大きく影響します。
決めた優先順位は、苦しい場面でこそ試される
ただし、最初に優先順位を決めておけば、それですべて解決するわけではありません。
プロジェクト開始時に、
「品質を最優先にする」
と決めていても、リリース日が近づけば納期へのプレッシャーは強くなります。
「現場が使える状態になるまでは出さない」
と決めていても、経営報告では予定日通りのGo-Liveを求められるかもしれません。
つまり、
原則を決めることと、その原則に従って判断することは別の話です。
だからこそ、
「どんな条件なら、その優先順位を変えてよいのか」
まで決めておく必要があります。
原則を変えること自体が悪いわけではありません。
問題は、誰も変更したと認識しないまま、
テストを削る。
教育を削る。
構造品質を削る。
という形で、現場の判断によって少しずつ優先順位が入れ替わっていくことです。
そして、その優先順位が最後に試されるのが、
Go-Liveを判断する瞬間です。
DX推進責任者・PMOの皆さんへ
Redirectが必要だと感じているのであれば、
「何を犠牲にしますか」
と聞く必要はありません。
それでは、相手は守りに入ってしまいます。
代わりに、こう聞いてみてください。
「私たちのプロジェクトで、今も絶対に守るべき条件は何でしょうか。一方で、現実に合わせて変えてよい条件は何でしょうか。」
これは、誰かの判断ミスを責めるための質問ではありません。
現実が変わった今、
「何を守ることが、事業にとって本当に重要なのか」
を一緒に確認するための問いです。
Redirectとは、全部を守りながら進路だけを変えることではありません。
最も大切なものを守るために、何を変えてよいかを決めることです。
YMG Advisoryでは、プロジェクトの進捗や体制だけでなく、納期、予算、スコープ、品質の優先順位が明確になっているか、そのトレードオフを誰が判断するのかについても、第三者の視点から整理しています。
「全部守るよう求められているが、現実には難しい」
「何かを変える必要があるが、どこまで変えてよいか分からない」
「表向きは順調だが、品質や将来の保守性にしわ寄せが出ている」
そのような状況にある方は、ymg-info@ymg-advisory.comまでお気軽にご相談ください。
次回Vol.28では、三つ目の意思決定──
「何を満たせばGo-Liveできるのか」
を考えます。
工程が終わったから稼働するのか。
予定日が来たから稼働するのか。
それとも、事前に決めた条件を満たしたから稼働するのか。
Go-Liveを単なるスケジュール上のイベントではなく、経営判断として捉え直します。