スケジュールを立てよう
私たちは日々の仕事に対してスケジュールを立てて対応していると思います。プロジェクトにおいてもスケジュールを立てることは重要です。ですが、あまりの要素の多さも相まってなかなか正確なスケジュールを立てることは困難です。私がよくやる手順を紹介しますので、参考にしていただければ幸いです。
サンプルプロジェクトに対して、PMBOKの5つのプロセスに沿った形で解説していきます。今回は（４）計画｜スケジュールです。
スコープ定義
スコープ定義とはこのプロジェクトがどこからどこまでが対象かを定義します。個人的に意識してるポイントとしてはやらない事を定義してドキュメントに明示的に記載しておくことです。
テキストで列挙してもいいですし、下記のように図を使って表現してもいいです。大切なことはどこからどこまでがこのプロジェクトが関連するか、どこが関連しないかを明記することだと思います。
また、スコープ定義ではシステム関連の情報も必要となってくる場合が多いので、プロジェクトにアサインされているシステムのリーダーと相談しながら明らかにしていくといいと思います。
要件定義
スコープ定義まで完了したら、システム要件と業務要件を設計可能な状態にするために、要件定義書を作成します。要件定義書は会社によってはフォーマットが決まっていたりする場合もあるため、自社の有識者に確認するといいと思います。
ここではサンプルプロジェクトを使って、要件定義書を作成してみました。要件定義書を作成する際の参考にしていただければ幸いです。
WBS作成
スコープが定義できたら次は具体的な作業項目を明らかにしていきます。ここで使うのがWBS（Work Breakdown Structure）、日本語で表現すると作業分解構成図と言ったものになります。具体的にはこんな感じです。
今回は大項目に成果物、中項目に成果物を作るためのプロセスを記載してあります。
ここに書かれている内容はかなりざっくりした感じで記載されているので、もう少し詳細に記載してもいいかもしれません。このような形で成果物、成果物を作るために必要な項目といった形で表現していきます。
一つの成果物を作るためにはざっくり言うと「計画→計画のレビュー→修正→計画の承認→開発→開発物のレビュー→修正→承認」といったプロセスを辿ります。重要なのは可能な限り明確に項目を洗い出すことが重要です。後の工程で洗い出した項目に対してどの程度時間がかかりそうかを見積もって記載していくためです。
コスト・マネジメントの計画
コスト・マネジメント計画は定義したスコープやWBSの変更があった際にどのように対応するのかを計画しておくものです。要求事項の確定後に要求事項の増減が発生したり、プロジェクト中盤で技術的な問題や外部サービスの影響などにより要求事項が変更されたりすることがあります。またWBSの見直しがあった場合、対応すべき中項目が増減することもあります。
そのような場合、誰がどこにエスカレーションすればいいのか、誰が増減分をプロジェクトに含める意思決定をするのかといった事項を前もって計画しておきます。
個人的な経験としては、こういった変更はプロジェクトメンバーの多くが参加する定例会議の場で課題提起と承認まで行うケースが多かったです。そうすることにより、特定の誰かの課題ではなくプロジェクト全体の課題としてメンバー全員で向き合うというカルチャーの醸成にも一役かってくれます。
コストの見積り
WBSで洗い出したタスクに対して、誰が担当するのかを決め、どのくらい時間が必要かを見積ります。実際の担当者に見積りをしてもらう方が良いと思います。
ですが、見積もった時間と実際にかかる時間には必ずズレがあります。なのでこの段階では見積り精度がどのレベルの見積りなのかをプロジェクトの共通認識としておくことが大切です。見積り精度は以下のようなものになります。
超概算見積り
「ざっくり肌感でいうとこれくらいです」といった精度の見積りで、出した見積りから -50% 〜 +100%のブレが想定される見積りです。会議などの中でエンジニアの方にどれくらいかかると思う？と質問すると出てくる見積りがおおよそ超概算見積りレベルのものだと思っておけば大丈夫です。
概算見積り
計画プロセスが完了した際に算出できる見積りで、-25% 〜 +50%のブレが想定される見積りです。
（確定）見積り
内製でシステム開発している場合はあまり使うことはありませんが、委託先側はここまで行います。この見積りは発注書などに記載する額となるため、システム設計や間接費などを勘案して算出することがほとんどです。見積り精度としては-5% 〜 +10%のブレが想定される見積りです。
予算の設定
WBSの作成、コストの見積り、スケジュールの作成を通して予算に必要な情報の半分が確定したと思います。これらにその他必要な備品などを足して予算の設定を行います。算出方法は会社によって様々ですが、よくある手法としては1人あたりの1ヶ月の稼働が20日換算で100万円といった感じの人月とう概念で計算したりするケースが多いです。
実は予算見積りは熟練のプロジェクトマネージャーでも頭を悩ませることが多いです。受託開発を行う会社の場合、ある程度フレームワーク的なものが定められているケースが多いですが、そうでない場合はいろいろな考え方があるので、これと言った決め手がないのが実情です。
といって丼勘定でやってしまうとプロジェクトオーナーが上位のステークホルダー（例えば社長など）に「見積りの根拠は？」と聞かれ回答に困るといったケースもよくある話です。なんらかの根拠を持った予算見積りを心がけましょう。
さて、ここまででプロジェクトに必要な社内のコストはある程度明らかになったと思います。ただ委託先のコストについてはまだ言及していません。委託先のコストについては次回解説していきたいと思います。
スケジュールの作成
作成したWBSと見積もった工数、前後関係や作業者のアサイン状況を記載しつつ、ガントチャートを書いていきます。これによりどのタイミングで誰が何を行うのかが明らかになります。そしてこのプロジェクトの概算のスケジュールを見定めることができるようになります。
ポイントとしては対応する項目の前後関係や並行関係について把握しておくという点です。スケジュールを組む上で「Aが終わらないとBが始められない」という重要なポイントを把握したり、プロジェクトオーナーから「もう一人開発メンバーを追加した場合どの程度早くリリースできるか？」といった提案に対して回答できるように計画しておくとプロジェクトをスムーズに進行させることができる可能性が高まります。
この辺りは専門的な知識や過去の経験がものを言いやすいですが、事前に検討しておくことによってある程度はカバーできるのではないかと思います。
最後に
いかがだったでしょうか。前回に続き今回も内容が盛りだくさんでしたが、いよいよスケジュールが固まり、具体的に手を動かすことができるようになりました。ここまで来ればプロジェクトマネージャーが手を動かすケースはぐっと少なくなります。
次回は委託先について、どのようなプロセスで委託先を選び、契約し、契約を履行し、納品してもらうかについての話を進めていこうと思います。
宣伝
株式会社WAPでは「日本企業が世界と戦うための伴走型リーダー育成」をミッションに掲げています。この困難なミッションに共に立ち向かってくれるプロジェクトマネージャーを募集しています。ちょっと気になったので話を聞いてみたい！という方も大歓迎です。Meetyにてお気軽にお申し込みください。
