スケジュールのリカバリー策〜ファストラッキング編〜【PM困り事シリーズ】

※この記事は「スケジュールのリカバリー策〜クラッシング編〜【PM困り事シリーズ】」の続きになります。

では、続いてファストラッキング（タスクの並行実施）を取り上げていきたいと思います。

2.ファストラッキングについて
ファストラッキングとは、「本来重なっていなかった複数のタスクを同時並行で行うことで、スケジュールのリカバリーを図る」打ち手です。

単純な例でいくと、「要件定義を終えた機能について、設計Phaseを待たずに基本設計を開始する」とかが挙げられます。

一見、「リソースの増強も必要ないしクラッシングよりハードル低そう」に思える打ち手ですが、僕は「ディレクター・PjM層の負荷が増大する」点に、特に気を配るべきだと考えてます。

例えば、自分の経験談で、「ベンダが作成する試験項目書を、事業側が1機能ずつベルトコンベア式にレビューしていく」というファストラッキングを敢行したことがあります。試験項目数は合計約7000項目に渡り、1機能ずつ1日でレビューしていきました。割と地獄でした苦笑

そこで何がおきたかというと、ディレクターの負担が激増しました。考えてみれば「そりゃそうだよね」という話なのですが、事業側や社内メンバーとコミュニケーションするコストが、細かく同時並行で作業すればするほど、大きくなっていくんです。

先程の例だと、ベンダ側のディレクターは、1機能ずつ設計書と試験項目書を付け合わせて確認し、赤を入れ、完成させた試験項目書を顧客側に展開していくわけですが、特にこの展開するコミュニケーションが重くなりました。「試験項目書を所定のフォルダに格納し、JIRAやバックログを更新し、事業側から修正箇所の指摘があれば、JIRAやバックログから内容を確認して社内にFBする…。」その回数が細かく並行作業するほど増えていくので、ディレクタの負荷が増し、ミスも増えがちです。

↑は少し極端な例だったかもしれませんが、要件定義と設計工程が被っても、設計を開発工程が被っても、同じような事象が起きがちです。かつ、ディレクターやPjMのリソースは（なぜか）可視化されづらいため、意外とボトルネックになりやすい…。事業側のPjMとしては、彼らに異変が起きていないか（ドキュメントのミスが増えていたり、コミュニケーションが遅くなっていないか）などに気を配りながら、ファストラッキングを敢行するようにしましょう。

その他、ファストラッキングの留意事項としては、
・並行作業するタスクにおいて、リソースの被りはないか（例えば、設計と開発が被っている場合、同じ人が設計と開発を同時にやるような計画になっていないか）
・ダブルタスクにより効率が落ち込んでいないか
・資材管理がきちんとできているか
などが挙げられるかと思います。ベンダ側で起こりがちな問題ですが、事業側のPjMもそのことをリスクと捉えたうえでベンダに寄り添うことが重要だと思います。事業側のタスクを可能な限り前倒してベンダ側の負荷を下げるとか、ファストラッキングがうまくいかなかった場合に備え、開発リソースやテスターのリソース増強を検討したり、一部スコープをリリース後対応とするとか、2の矢3の矢を仕込んでおくようにしましょう。次の矢を放つタイミング（マイルストーン）を設定しておくのも重要です。

プロジェクトではベンダも事業側も「運命共同体」です。「それはベンダ側でなんとかしてよ」的なアプローチをとるより、「ベンダ側の負荷を少しでも下げられないか」と考えたほうが、現実的で建設的で、プロジェクトの完遂に一歩近づきます。事業側のPjMにとって非常に重要なマインドだと思います。

以上、ファストラッキングに関する記事でした。これでリカバリー策編は終了です。…が、そもそも「遅延の原因が何だったのか」という分析と根本的な対策がなければ、せっかくのリカバリー策も効果を発揮しきれません。

というわけで、次章では「遅延や品質低下の原因分析」について、話していきたいと思います。