ソフトウェア開発プロジェクトでは、どんな開発方式をとっていたとしてもスケジュール等に遅れが発生することはある(それが人の御業である限り)。そんな時にはプロジェクトを立て直す(リカバリーする)ためのプランを立てて実行することになるが、これをリカバリープランと呼んでいる。リカバリープランを自分で立てることもあるし、人のリカバリープランを見ることもあるけれども、おさえておくべきポイントがあると思う。
科学的に取り組む。精神論で立ち向かわない。
単純にブラックであること以上に、精神論で状況に立ち向かうことは関係者に多大な迷惑をもたらす。サイコリバカリーはよくない。
- 利害関係者と状況を共有することができない。
- 「今やってます」という回答を繰り返す、いわゆる蕎麦屋の出前状況になってしまう。
- 何らかのタスクの終了を待っている人が見通しを立てられない。
- 利害関係者からの協力がやりにくい。
- もし少しでも状況改善に協力したい人がいたとしても、応援する以外のサポートができない。
- どこからどこまでがリカバリーの範囲か不明確になりがちで、プロジェクトメンバーのモチベーションが維持しにくい。
- 遅延→一時的復旧→遅延 というスパイラルに陥って、最終的には信用を無くす。
スケジュールやスコープの見直しなどは、何度もやるべきものでもない。よって、リカバリープランは科学的に、あるいは客観的に達成可能だと考えられるものを立てるべきだと思う。
リカバリー状況を計測可能にする。
リカバリープランは、何らかの指標を示してリカバリー状況を計測可能にして、それがある状態にになるまで、という定義をしたほうが良い。バーンダウンチャート風に測定できるのがベストだと思う。指標はプロジェクトの状況によって合理的なものを決めればいい。
- 残タスク、ストーリー、課題、バグ数
- 残テストケース数 (事前に見積もれるか、数えられるのであれば)
これらの指標でリカバリープランを立てれば、実行前から勝ち目があるか(現実的か)どうかを検証することができるし、実行中も計画との差異から順調にプランが進んでいるのか、そうでないかがすぐにわかる。
なお指標はできる限り集計が容易なものを、複雑なロジック無く使えるもののほうがいい。複雑な指標を採用してしまうと管理がボトルネックとなって貴重な作業時間をさらに失ってしまう事になりかねない。
また、出来れば増減が一方向になるような指標にしたほうがいい(例えば残タスク数を指標にするのであれば、あるタスクの実行中に新しいタスクが発見されたり、分割されたりして増えてしまうこともある。しかしこの場合「作業期間内に増加した分のタスク」は別の指標としてカウントしたほうが良いと思う)。
作業量（に繋がる何か）を減らす
リカバリーが必要な状況に陥った事態を考えれば、まず当初狙っていたすべての作業やタスクを完遂するのは難しいと言ってよい。受発注の関係で受注者側に非があっても、である。そこでまず何らかの方法をもって作業量を減らすことを考える必要がある。
- 作業時期を後ろに倒す
- マニュアルやドキュメント類の作成をあとまわしにする
- 一部機能のリリースを別にする
- 一部のデバイスのサポート時期を後ろにする
- 影響度の低いバグや課題の対応時期を後ろにする
- 作業をプロジェクトの外に出して、無くす
- ドキュメント類の作成を発注者側に担当いただく（やってもらう）
- テストの一部を発注者側や別の組織でやる（自社の空き要員とか）
- 作業内容を見直してタスクを小さくする
- レビュー類の簡易化
- テストプロセスの簡易化
- 作業を無くす
- 一部の設計プロセス
- 一部のテストプロセス
もちろんここで削るものは「本来はやるべきもの」であるので、単に削ってしまうとプロジェクトに悪影響を及ぼすこともある。よって、単に作業を減らすだけでは駄目で、代替策をあわせて検討することも必要だ（例えば簡易マニュアルを作って当座をしのぐなど）。
関係者の役割と期待事項を明確にする
リカバリープランにおいては、特に普段より細かく役割を定義しておいたほうが良い。
- 責任者/決定権者は誰か
- 窓口担当者は誰か
- 副担当は誰か
- 主担当が（体や心の）風邪を引いたら状況が不明になるようなことにならないように
- 発注者にお願いしたい事は何か（もしあれば）
- 日々の状況確認方法
- メールなのか、会議なのか（場所やサイクル）
- トラブル発生時のエスカレーション方法
プランについて関係者の合意を得てから実施する
リカバリープランは必ず利害関係者の了承を取り付けてから始めるべきだ。
そもそもリカバリープランの実行自体、何度もやるべきものではないし、ここでリカバリーのスコープやプロセスを合意しておかないと、後で不幸な手戻りや追加作業の発生につながりかねない。
- 機能や作業の優先度が間違っていて、そもそものプランが無駄になったり
- 援助するつもりの顧客の気持ちを無にして、関係が悪化したり
そもそもリカバリーは「関係者の協力」のもとに実施すべきものであって、協力を取り付けるためにもきちんとした了承を得ることが必要だ。
思うに、プロジェクトを船に例えるとリカバリープランはリスクのあるショートカット航路に舵を切ることなのである（その航路には暗礁や嵐の恐れがあるものの、確かに距離・時間は短縮される）。これまで計画していなかった安全（なはずだった）航路ではなく、新たな未知の航路に進路を取るので、同じ船に乗っている人の同意と協力が不可欠だろう。
ひょっとすると合意までに意外に時間を要することがあるかもしれないが、それでも合意には大きな意味がある。
巨大で危険な物体を操縦するときには、操縦桿をしっかりと握っているだけでは不十分です。あなたが操縦しようとしているものが巨大であり、多くの人が関与しているのであれば、より大きな慣性が働くのです。プロジェクトマネジメントにおいても同様ですが、巨大な機械（自動車、飛行機、航空母艦等）を操縦する場合、初心者は進路変更操作をしてから、実際に変更し始めるまでの時間を過小評価しがちです。
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
もちろん、リカバリープランの事など考えなくて良いように、普段からきちんとマネジメントすることが一番重要なのだけれども。
