プロジェクト計画（スケジュール作成）のポイントレビュー

	プロセス１３：プロジェクトマネジメントノベルレッスン２：プロジェクト計画（スケジュール作成）のポイントレビュー
アクティビティ７～９は、プロジェクトスケジュールと要員計画の作成プロセスを扱った。今回は、振り返りながらポイントを解説する。 ◆ポイント１：計画対象のスコープとスコープマネジメントルールの明確化　立ち上げの段階で、ビジネス的なスコープの区分を明確にするというポイントを上げたが、計画段階で再度、作業ベースのスコープを明確にする必要がある。立ち上げフェーズのスコープはプロジェクト成果の評価を明確にするための区分であるが、計画では担当区分であり、成果を得るためにプロジェクトとして行うことと、行わないことを明確にする必要がある。　もちろん、立ち上げフェーズで定義したスコープについては、誰かがカバーする必要があるわけで、その意味で担当区分だと考える。　スコープ区分にもまして重要なことは、「スコープ変更計画」の策定である。プロジェクトマネジメントでは普通ＳＱＣＤという形でＱＣＤとスコープを同等に考える。のような考え方もあるが、スコープはＱＣＤよりは上位の概念として考えておくべきである。スコープが変わるというのはプロジェクトの成果物が変わるということであり、関連するステークホルダが極めて広範であり、下手に対処するとステークホルダ間の利害調整に失敗し、プロジェクトを崩壊させかねない。　事実、そのようなプロジェクトを見かけることも多い。無計画なスコープ変更により、外注先が手を引く、母体組織からのリソース提供が絶たれるなど、ステークホルダの協力が得られなくなり、プロジェクトが停滞し、そのまま、実質的な中止に追い込まれた例は知っているだけでも片手では数えられない。　そこで、スコープについてはスコープ変更の計画を作っておく必要がある。その目的はスコープの変更に対して、すべてのステークホルダがオートマチックに連動できるためである。そのようなルールがあって初めて、スコープ変更がスムーズに進む。　もちろん、この後で出てくるが、すべての計画について計画変更計画（ルール）の策定は必要であるが、手続きも違うのだ。 ◆ポイント２：マネジメントに影響を与える技術的側面があることを知る　プロジェクトマネージャー養成マガジンや養成マガジンセミナーでもずいぶん議論してきた話題であるが、プロジェクトマネジメントが技術的な問題にどのように影響を受けるかという問題がある。　今回のストーリーの中では、アーキテクチャーは明らかにマネジメントに影響を与えている。アーキテクチャーが決まらないとマネジメントの方針が決まらないというケースは往々にしてあるし、アーキテクチャーによってリスクマネジメントをはじめとするマネジメント作業の内容がガラリと変わることも珍しくない。ソフトウエアの場合だと、システムアーキテクチャーにソフトウエアプロセスが依存する部分が大きいからだ。まず、このことをよく認識しておく必要がある。　その上で、プロジェクトマネージャーに技術的なスキルが必要かどうかというとこれは別の問題であることも付記しておく。理想的にはそうありたいものだが、技術的スキルのなさをカバーするマネジメントの進め方はいくらでも考えられるからだ。　むしろ、プロジェクトマネージャーに求められるのは、そのようなスキルを持つメンバーとの間、また、メンバー同士のコラボレーションを促進し、技術的制約をうまく反映したマネジメント計画を作っていくことだと考えるべきだろう。 ◆ポイント３：スケジュール決定に当たっては柔軟性に配慮をする　ストーリーの中で、木村が提案したようにスケジュールの策定に当たってはスケジュールの柔軟性を考えることが重要である。柔軟なスケジュールというのはどのようなものだろうか？　たとえば、１ヶ月でできると想定される作業を２ヶ月にすると、確かに柔軟性は高くなり、変動にも強くなるし、また、納期遅れのリスクも減少するだろう。特に最近リスクに対する関心が高まり、納期要求が厳しくなっているにもかかわらず、このようなスケジュールを立てるプロジェクトが目につく。　結果として、改まってマネジメントをしなくてもできるようなスケジュールになる。言うまでもなく、これは本末転倒で、プロジェクトマネジメントやリスクマネジメントは、マネジメントされていない状態と比較して、納期を短縮することが目的である。　柔軟性のあるスケジュールはクリティカルパスを守るために、スケジュール変更、要員計画変更の自由度の大きな計画である。たとえば、リスクの大きなアクティビティに対して、余裕アクティビティのリソースを振り替えることでリスクを解消できるような計画である。完全にできるケースはほとんどないだろうが、アクティビティの切り出し方、あるいは、タスク順序関係を工夫することによってかなりの自由度を確保することが可能なケースが多い。　スケジュール作成に当たっては、納期までに何とか入れるだけではなく、この点をよく考えておく。それにより、逆に、リスクを取れるようになり、スケジュールの短縮につながっていくケースが多い。 ◆ポイント４：マイルストーンのとり方　マイルストーンにはいくつかの目的がある。（１）プロジェクト作業の同期のために必要になるマイルストーン（２）コミュニケーション計画のポイントになるマイルストーン（３）組織（マネジメント）によりレビューするタイミングになるマイルストーン（４）他のプロジェクトと何らかの同期を取るために必要なマイルストーン（５）是正のポイントになるマイルストーン（６）プロジェクトスケジュール感を共有するためのマイルストーンなどがある。重要なマイルストーンは、これらの目的が重複しているマイルストーンだ。　マイルストーンの設定にあたっては、どのような目的で設定するのかを明確にして設定し、なおかつ、その目的をプロジェクトチーム全体で共有することが肝心である。　また、逆の考え方として、（１）の目的のマイルストーンに合わせて、コミュニケーション計画やプロジェクト監査計画を立案するという考え方もある。 ◆ポイント５：要員計画ではその実現性を配慮する　要員計画を頭数あわせとして考えるケースをよく見かける。これではプロジェクトはうまくいかないだろう。たしかに、適材適所など理想論に過ぎず、現実的には与えられた業務で学習をしながら取り組んでいくという考え方も一つの方法ではある。　しかし、考えなくてはならないことは、効率を追求するのであれば、その方法が人によって異なるということである。したがって、作業スケジュールの前提になる要員像を明確にし、その像に近い要員の確保を行っていく必要がある。　その際には、　・母体組織からの調達が現実問題として可能かどうか　・外部調達が可能な人材像かという点を十分に検討したうえで、要員を計画する必要がある。　調達が難しい場合、　・プロジェクトの中でどのようにして育成していくかという点を考え、育成の方法があるかどうかを検討する。　さらにそれも難しい場合には　・確保可能な要員で、もっとも効率的な作業計画はどのようなものかということを考えることも必要になる。　これらの一連の要員計画の際に、意外な落とし穴になるのは、必要なスキルレベルが高い場合に、１人ではできないが、２人だとできるだろうということを根拠なく考えることである。これは、錯覚であることが多い。１人と２人体制を比較する場合には、１人あたりのパフォーマンス８０％（２人で１．５人程度）、スキルレベルは同じという程度に考えておくのがよいだろう。（２００４．８．１２号より抜粋）
購入はこちら