第2回 作業範囲～スケジュール立案
(1) 作業範囲を明確にする
PMの最初の仕事は目標と成果物を正確に理解し、成果物を造るために必要な既存の製品や作業の範囲（プロジェクトスコープ）を明確にすることです。そして、そのためにはどんなプロジェクトチーム体制が必要なのか、要求されるスキルは何かなどを検討しなければなりません。また、自社のプロジェクトチームだけではまかなえず、他社の供給する製品を調達したり、他社に一部の成果物の開発を依頼したりすることもあります。
(2) プロジェクトの関係構造を把握し、体制を作る
PMは、プロジェクトにおける様々な「構造」を正確に理解する必要があります。まず抑えるべきはプロジェクト全体の構造で、これは会社間の、あるいは会社内のプロジェクトチームの体制、プロジェクトチームを取り巻くスポンサー、ユーザ、運用担当者、及び調達先の他社などを含む関係構造です。
図１の例は、プロジェクト監事会社の最終成果物を造るために、他の３つの会社（プロジェクト請負会社、2次請負会社、製品提供会社）が関係するプロジェクトで、監事会社からへプロジェクト請負会社、２次請負会社、製品提供会社へ向かって発注がなされ、逆の方向に成果物、あるいは製品が納入されます。図１では、３つの会社のPMがそれぞれの成果物開発の責任を負うことになりますが、それぞれのPMがプロジェクト全体の構造を理解するとともに、全体の中での自分の位置付け、役割を理解することが必要です。
さらにPMは、図２のように自分が責任を持つプロジェクトチーム内の体制を整え、体制図を明確にする必要があります。図２のプロジェクト請負会社（インテグレータ）のPMは、自社のプロジェクトチームの体制を整えると同時に、２次請負会社のプロジェクトチームの構造や、製品提供会社の体制（営業、営業SE、製品サポートなど）についても把握しておく必要があります。
－図２の解説－
担当アプリケーションでA,B,Cの３つのサブチームに分けています。
運用チームは、システムの運用設計を行い、必要な運用機能を開発する役割を果たします。
基盤チームは、ネットワーク、ハードウェア、基本ソフトウェア関連の設計、設定を担当します。
管理チームは、マスタスケジュールの管理、詳細進捗情報、懸案事項、変更情報、障害情報、品質管理、開発標準など、プロジェクト全体に関わる課題を管理しPMをサポートします（大きなプロジェクトでは、管理チームを設けることは必須で、非常に重要な役割を果たします）。
もし、体制図が無いとすると、会社間でもプロジェクトチーム内でも、誰が何をやっているのか分からなくなってしまいます。そうなると、ある事を誰に伝えるべきなのか、誰に聞けばいいのかが分からず、いろんな事がすべてPMを経由することになり、それこそPMがネックとなってしまいます。私も実際に、50名以上のプロジェクトメンバーがいながら、体制表が無いというプロジェクトに出会ったことがあります。すぐにPMに体制表を作成させましたが、既に全体がスムーズに回らなくなっていました。結局、このプロジェクトは３ヶ月ほど期限に遅れてしまいました。
また、PMは公式な構造だけではなく、非公式な人間関係の構造にも目を向ける必要があります。つまりプロジェクトチームメンバー同士の仲の良さ悪さ、気が合う、合わない、上下関係の問題などに目を向ける必要があります。ただし、チームメンバーの個人的なことにあまり立ち入ってしまうのも不適切で、あくまでプロジェクトをうまく進める観点からチェックし、障害の発生を予防し、障害を取り除くことが重要です。
(3) スケジュールを立てる
プロジェクトの早い段階、できれば最初の業務要件分析フェーズで、全体のスケジュールを作る必要があります。業務要件分析フェーズでは業務の要件をヒアリングしてまとめるわけですが、同時に実現方法のフィジビリティスタディ、AP・基盤全体のアーキテクチャ設計を、頭の片隅ででも並行してやっておく必要があります。通常、業務要件分析のタスクに参加する人数は限られますので、PM自身もこの段階では積極的に業務要件分析タスクに参加し、後工程でのスケジュール、体制、人材、資材、リスク、顧客企業や２次請負会社への要求事項などを検討しておく必要があります。
業務要件分析フェーズで実現性を検討しておかないと「実現性の裏付けの無い業務要件記述書」だけが「全部実現すること」として一人歩きしてしまう可能性があります。その後の工程を担当する人は、業務要件記述書を実現性の面から吟味し、実現できることできないことの取捨選択を、顧客企業とすり合わせることになります。結局、業務要件分析のタスクをもう一度やりなおすことになります。すなわち、業務分析、要件分析を行う人は、その後の工程の進め方やリスク、注意点を、本当に予想でき、次の工程に繋ぐことのできるプロジェクトのベテランでなければなりません。
スケジュールを立てる際には、以下のような標準的に実施するタスクを考え、そのプロジェクトの特性に合わせて細分化していきます。さらに細分化した各タスクの前後関係を検討して順番に並べてスケジュールを作成します。このとき体制を考慮しながら、可能なタスク同士を極力並行してやるようにします。
アプリケーション関連のタスク
- 業務要件分析
- AP基本設計
- AP詳細設計
- DB設計
- APプログラム作成・単体テスト
- 総合テスト
- 検収テスト
- 本番移行
管理･運用･基盤のタスク・・アプリケーション関連タスクと並行して走らせる必要があります。
- フィジビリティ調査
- APアーキテクチャ設計
- 基盤アーキテクチャ設計
- ネットワーク設計
- AP開発ガイドライン作成
- 運用設計
- 開発環境構築
- 本番環境構築
- 運用テスト
スケジュールは建前上遅れることは許されませんが、必ず遅れるものです。だから、必ず、実現する機能のうち絶対に遅れてはいけない部分と、遅らせても構わない部分の、目星をつけておく必要があります。顧客、ユーザ、スポンサーの意向を非公式にでも聞いておき、優先度の高い部分と低い部分を明確に把握して、遅延に対していつでも有効な手を打てるようにしておく必要があります。