このエスケープルートの考え方も、プロジェクトと似ている部分があります。登山でいえば山頂までは行けないが、途中の景色の良いところまで行って戻る、あるいは縦走で途中の山頂を1つ飛ばして、別ルートで次の地点まで行くということがあります。プロジェクトでも途中の目標まではたどり着き、その後の対応を検討し直すことや、全ての目標は満たさないまでも全工程を完遂するといったことはあるでしょう。
アポロ13号に学ぶ
「諦めるとき」の最優先策
諦めて撤退する場合も同じです。有名なものではアポロ13号プロジェクトの例があり、私もよく引き合いに出して説明します。
アポロ13号は本来、月面着陸を目指していましたが、途中で事故が発生し、月面はもとより、そもそも地球に帰還できるかどうかすら分からない状態に陥ります。アポロ計画のミッションは「人間を月に着陸させ、安全に地球に帰還させる」というものでした。このときは、月面に着陸できませんでしたが、地球に帰還させることがより重要なミッションだとして、エスケープルートを実行することになりました。
実際にはアポロ13号のケースでは、あらかじめ考慮していたエスケープルートが使えない過酷な状況だったのですが、いずれにせよ、こういったプロジェクトにおいては常にプランB、駄目だったときに最優先させるべきものを実現するための方策を考えることが重要です。
持ち物の検討でも、登山とプロジェクトには共通点があります。登山においては必要なものをそろえるのは当然ですが、装備品の重量を抑えることも大切です。不要なものを持っていかないようにするのですが、この判断がとても難しい。
プロダクト開発や事業においても、「何か機能やサービスを足したら何かを引かなければならない」ということがよくあります。スマートフォンアプリを想像してもらうと分かりやすいかと思いますが、限られた画面の中で全体のUIに加えられるものには限度があり、ソフトウェアの容量もサイズを抑える必要があります。そのために、使わない機能や必要がなくなったものを削除して、代わりに何かを追加するのが望ましいのです。