はじめに

「気づいたら、不確実性の海のど真ん中にいた」

プロジェクトを進めていると、こういう瞬間ありませんか？

リリースに向けた計画はスカスカなのに、リリース日だけは決まっている
見えていないことが多く、いつの間にか計画が“積み上げ式”になって破綻する

私は、まさにこの状態に遭遇しました。

私の場合は「これだといけそう」という1パターンの楽観的な仮説の上に計画を積み上げ続けてしまい、気づいたときには「予定していたリリース日が現実的ではない」状態になっていました。

今思い返すと、
最初から完全にほぼ犬掻き状態でPJTを進めていたのに、そこに気付けないまま進めてしまっていました。

この記事は、そのときの反省を踏まえて、

不確実性が高いPJTで、計画が破綻して溺死するのをどうやって回避するか
を、振り返ります。

溺死しないためにやる4つのこと

不確実性の海で溺れないために、私がやるべきだったことを4つにまとめます。

1) まず「成功条件（ゴール）」を先に決める

成功条件が決まってないと、計画も判断も全部ブレる。

「ある程度決まったらリリース日と詳細計画を決めます」というスタンスで進めていました。

その結果、

マイルストンはあるのに、順調かどうかが判断できない
「見えていないから決めない…」を繰り返す
気づいたら計画が積み上げ式になり、破綻する

状態に陥っていました。

ここで私が先に決めるべきだったのは、

PJTで得たいアウトカムに対して、「いつまでに」「どこまで到達できれば成功と言えるのか？」です。

ここが曖昧なままだと、プロジェクトは簡単に漂流します。

2) 仮でもいいから「根拠ある計画」を置く

完璧より“根拠ある仮説”。粗くてもいいから仮説を元に計画を置いて更新する。

私は当時、リリース目標が曖昧なまま要件定義前になり、いよいよリリースが現実的になってきたタイミングで、

「目標に置いたら、なんか達成できる方法あるっしょ！」
「年内リリースだ！！」

という“気合いブースト”で計画を立てました。

結果、年内リリースの計画は

リソース増やす？ → 無理じゃん
スコープ削る？ → 無理じゃん
品質落とす？ → 無理じゃん
どうやっても無理じゃん

と、お手上げ状態になってしまいました。

最初から完璧な計画を作ることは無理なので、仮置きでもいいので、**今ある情報を元に「根拠ある計画」**を作るのが大事です。

ポイント

100点を目指さない
- 100点の計画が作れるほど不確実性が低いなら、そもそも困ってない
「今わかっていること」と「未確定なこと」を分ける
未確定なことは確定するまで、“決めない”ではなく いつ決めるか？決めるための計画を立てる

3) 視界を揃え続ける（ゴール・計画を定期更新する）

ズレを放置し続けると大きな歪みとなって返ってくる。

ここまでくると、PJTメンバーの自分達も曖昧なゴールのまま進めてきたことで、

関係者間で計画やリリース時期の認識がズレる
合意が取れていないため、ゴールの再調整が入る
結果的に計画のズレが増幅する

といったことが起こりやすくなります。

ポイント

「ゴール」「計画」「不確実性（前提・リスク）」をセットで更新して定期的に共有・擦り合わせる

私は、直近3ヶ月のゴールとマイルストンだけをすり合わせてしまい、プロジェクト全体のマイルストンまで揃えられていませんでした。

その結果、関係者ごとに「今どこに向かっているのか」の認識がズレていきました。

4) 不確定要素は「決め方」まで含めて計画に埋める

不確実性があることが問題なんじゃない。“放置”が問題。

不確定要素は放置すると、後から影響が肥大化し、どうしようもなくなることがあります。

これを防ぐには、

この不確定要素はいつまでに、何をもって確定するか
確定できない場合、どの仮説で進めるか

を、計画の中に入れておくことが大事です。

これを決めておくと、不確実性が“管理できるもの”になります。

不確実性があることが問題なのではなく、
解消されない・されようとしないまま放置されることが問題です。

教訓：不確実でも仮の計画を置いて、更新し続けよう

成功条件を決める
粗い計画でもいいから仮置きする
不確実性を管理する（決定期限・リスク・意思決定）
定期的に更新して、視界を揃え続ける

不確実性はなくならないけど、放置しなければ小さくできる。
そしてそれが、溺れないためのプロジェクトマネジメントだと思っています。

来年は、溺れずに楽しくプロジェクトを進めたいものです。