プロセス13:プロジェクトマネジメントノベル
レッスン2:プロジェクト計画(スケジュール作成)のポイントレビュー

アクティビティ7〜9は、プロジェクトスケジュールと要員計画の作成プロセスを扱った。今回は、振り返りながらポイントを解説する。


◆ポイント1:計画対象のスコープとスコープマネジメントルールの明確化

 立ち上げの段階で、ビジネス的なスコープの区分を明確にするというポイントを上げたが、計画段階で再度、作業ベースのスコープを明確にする必要がある。立ち上げフェーズのスコープはプロジェクト成果の評価を明確にするための区分であるが、計画では担当区分であり、成果を得るためにプロジェクトとして行うことと、行わないことを明確にする必要がある。

 もちろん、立ち上げフェーズで定義したスコープについては、誰かがカバーする必要があるわけで、その意味で担当区分だと考える。

 スコープ区分にもまして重要なことは、「スコープ変更計画」の策定である。プロジェクトマネジメントでは普通SQCDという形でQCDとスコープを同等に考える。のような考え方もあるが、スコープはQCDよりは上位の概念として考えておくべきである。スコープが変わるというのはプロジェクトの成果物が変わるということであり、関連するステークホルダが極めて広範であり、下手に対処するとステークホルダ間の利害調整に失敗し、プロジェクトを崩壊させかねない。

 事実、そのようなプロジェクトを見かけることも多い。無計画なスコープ変更により、外注先が手を引く、母体組織からのリソース提供が絶たれるなど、ステークホルダの協力が得られなくなり、プロジェクトが停滞し、そのまま、実質的な中止に追い込まれた例は知っているだけでも片手では数えられない。

 そこで、スコープについてはスコープ変更の計画を作っておく必要がある。その目的はスコープの変更に対して、すべてのステークホルダがオートマチックに連動できるためである。そのようなルールがあって初めて、スコープ変更がスムーズに進む。

 もちろん、この後で出てくるが、すべての計画について計画変更計画(ルール)の策定は必要であるが、手続きも違うのだ。


◆ポイント2:マネジメントに影響を与える技術的側面があることを知る

 プロジェクトマネージャー養成マガジンや養成マガジンセミナーでもずいぶん議論してきた話題であるが、プロジェクトマネジメントが技術的な問題にどのように影響を受けるかという問題がある。

 今回のストーリーの中では、アーキテクチャーは明らかにマネジメントに影響を与えている。アーキテクチャーが決まらないとマネジメントの方針が決まらないというケースは往々にしてあるし、アーキテクチャーによってリスクマネジメントをはじめとするマネジメント作業の内容がガラリと変わることも珍しくない。ソフトウエアの場合だと、システムアーキテクチャーにソフトウエアプロセスが依存する部分が大きいからだ。まず、このことをよく認識しておく必要がある。

 その上で、プロジェクトマネージャーに技術的なスキルが必要かどうかというとこれは別の問題であることも付記しておく。理想的にはそうありたいものだが、技術的スキルのなさをカバーするマネジメントの進め方はいくらでも考えられるからだ。

 むしろ、プロジェクトマネージャーに求められるのは、そのようなスキルを持つメンバーとの間、また、メンバー同士のコラボレーションを促進し、技術的制約をうまく反映したマネジメント計画を作っていくことだと考えるべきだろう。


◆ポイント3:スケジュール決定に当たっては柔軟性に配慮をする

 ストーリーの中で、木村が提案したようにスケジュールの策定に当たってはスケジュールの柔軟性を考えることが重要である。柔軟なスケジュールというのはどのようなものだろうか?

 たとえば、1ヶ月でできると想定される作業を2ヶ月にすると、確かに柔軟性は高くなり、変動にも強くなるし、また、納期遅れのリスクも減少するだろう。特に最近リスクに対する関心が高まり、納期要求が厳しくなっているにもかかわらず、このようなスケジュールを立てるプロジェクトが目につく。

 結果として、改まってマネジメントをしなくてもできるようなスケジュールになる。言うまでもなく、これは本末転倒で、プロジェクトマネジメントやリスクマネジメントは、マネジメントされていない状態と比較して、納期を短縮することが目的である。

 柔軟性のあるスケジュールはクリティカルパスを守るために、スケジュール変更、要員計画変更の自由度の大きな計画である。たとえば、リスクの大きなアクティビティに対して、余裕アクティビティのリソースを振り替えることでリスクを解消できるような計画である。完全にできるケースはほとんどないだろうが、アクティビティの切り出し方、あるいは、タスク順序関係を工夫することによってかなりの自由度を確保することが可能なケースが多い。

 スケジュール作成に当たっては、納期までに何とか入れるだけではなく、この点をよく考えておく。それにより、逆に、リスクを取れるようになり、スケジュールの短縮につながっていくケースが多い。


◆ポイント4:マイルストーンのとり方

 マイルストーンにはいくつかの目的がある。

(1)プロジェクト作業の同期のために必要になるマイルストーン
(2)コミュニケーション計画のポイントになるマイルストーン
(3)組織(マネジメント)によりレビューするタイミングになるマイルストーン
(4)他のプロジェクトと何らかの同期を取るために必要なマイルストーン
(5)是正のポイントになるマイルストーン
(6)プロジェクトスケジュール感を共有するためのマイルストーン

などがある。重要なマイルストーンは、これらの目的が重複しているマイルストーンだ。

 マイルストーンの設定にあたっては、どのような目的で設定するのかを明確にして設定し、なおかつ、その目的をプロジェクトチーム全体で共有することが肝心である。

 また、逆の考え方として、(1)の目的のマイルストーンに合わせて、コミュニケーション計画やプロジェクト監査計画を立案するという考え方もある。


◆ポイント5:要員計画ではその実現性を配慮する

 要員計画を頭数あわせとして考えるケースをよく見かける。これではプロジェクトはうまくいかないだろう。たしかに、適材適所など理想論に過ぎず、現実的には与えられた業務で学習をしながら取り組んでいくという考え方も一つの方法ではある。

 しかし、考えなくてはならないことは、効率を追求するのであれば、その方法が人によって異なるということである。したがって、作業スケジュールの前提になる要員像を明確にし、その像に近い要員の確保を行っていく必要がある。

 その際には、

 ・母体組織からの調達が現実問題として可能かどうか
 ・外部調達が可能な人材像か

という点を十分に検討したうえで、要員を計画する必要がある。

 調達が難しい場合、

 ・プロジェクトの中でどのようにして育成していくか

という点を考え、育成の方法があるかどうかを検討する。

 さらにそれも難しい場合には

 ・確保可能な要員で、もっとも効率的な作業計画はどのようなものか

ということを考えることも必要になる。

 これらの一連の要員計画の際に、意外な落とし穴になるのは、必要なスキルレベルが高い場合に、1人ではできないが、2人だとできるだろうということを根拠なく考えることである。これは、錯覚であることが多い。1人と2人体制を比較する場合には、1人あたりのパフォーマンス80%(2人で1.5人程度)、スキルレベルは同じという程度に考えておくのがよいだろう。

(2004.8.12号より抜粋)
購入はこちらまぐプレバナー