現場で使える！スケジュール作成手順とそのコツ【PMの道具箱 #6】
みなさん、こんにちは！
今回はスケジュールの作成です。初めてプロジェクトマネージャーになった方や、大規模〜中規模のプロジェクトのリーダーが迷いなくスケジュールを作成できるようになることを目指しています。
はじめに
WBSとスケジュールの違い
現場では以下のスケジュール（ガントチャート）をWBSと呼ぶことがありますが、厳密にはこれらは異なるものです。
PMBOKでは、WBSはスコープマネジメントに分類され、スケジュールはタイムマネジメントに属します。WBSは作業と成果物を細分化したもので、これに時間軸を加えたものがスケジュールです。
スケジュールを作成する前には、WBSを用いて作業と成果物を明確に分解しておく必要があります。
本稿のスケジュール作成の前提となるWBSの作成方法について詳しく知りたい方は、「WBSの作成手順とそのコツ」の記事も参照してください。
以降では、システム開発プロジェクトを例に説明を進めます。
1.ゴールと制約の設定
1-1.ゴールの設定
スケジュール作成において最も重要なのは、プロジェクトの終了日を設定することです。通常、以下のような設定が一般的です。
・リリース日
・リリース後の安定稼働まで（だいたい1〜2ヶ月）
また、「効果が出るまで続ける」をゴールとして設定するプロジェクトもあります。特に、SoE関係のシステム開発で多く見られます（例：CRM、顧客関係管理）。ビジネスを考える上でこのようなゴール設定は誤りではありませんが、そのようなゴールを設定すると、プロジェクトの中断などの判断が困難になり、エンドレスな活動になる可能性があります。目標までのコストを明確にするためにも、プロジェクトの終了日を決めることが重要です。
Tips:プロダクトマネジメントとプロジェクトマネジメント
「効果が出るまで続ける」というはビジネスを考える上で妥当と書きましたが、これはプロダクトマネジメントの考え方です。両者はスケジュールを管理し、リソースを割り当て、課題やリスクを管理していくという点では同じですが、下表の違いがあります。
役員などの上位マネジメントは、ビジネスに責任を持つ立場であるため、プロダクトマネジメントの視点を持っていることが多い印象です。もし相手が望むものがプロダクトマネジメントであれば、プロダクト開発におけるMVP（＝最小機能を実装したリリース）をプロジェクトと切り出し、MVPリリース後のエンハンスメント開発をプロダクトマネジメントで管理することを提案してください。
1-2.制約の洗い出し
スケジュールを組む上での制約を洗い出します。
内部制約
休業日・繁忙期
組織の休業日や繁忙日を洗い出します。
システム開発に協力していただく業務部門の関係者のスケジュールには注意が必要です。たとえば、繁忙時期ではユーザ側は手が動かせない、ミーティングができない日などがあります。
手続きのリードタイム
稟議や品質監査などの必要期間を洗い出します。
外部制約
リソースの利用不可期間
特定のリソース（人員や設備）が利用できない期間があります。たとえば、専門家や外部ベンダーが他のプロジェクトにアサインされている場合や、外部システムとの接続テストなどです。
法的要件や規制
法的要件や規制によって、プロジェクトのスケジュールが制約される場合があります。たとえば、特定の許認可や認証を取得するための期間が必要な場合です。
2.スケジュール表への落とし込み
WBSの作成で整理した成果物とプロセス定義を、その作業量とともにスケジュール表に落とし込みます。ここでは熟練PMがよくやるテクニックを説明します。
2-1.作業の入れ替え、並列化
成果物の依存関係（特に前後の因果関係）をもとに作業順序を調整します。
事前にWBSで成果物の依存関係を可視化しておくと、前後の因果関係が可視化されるのでこの作業が楽になります。
作業の入れ替えを考える上で、PDM法の考えを用いると、より効率的な順序に整理できます。
Tips：PDM法（Precedence Diagram Method）
タスクの依存関係を整理する、スケジュール作成手法の一種です。
もっとも出現する関係はFS関係です。効率がよいスケジュールを作るにはタスクを並列化させることがポイントです。よって、タスクを直列で実行するFS関係から並列で実行するSS関係に出来ないかを探ります。
①FS関係（終了-開始）：先行作業が完了してから開始できる依存関係
例）システム設計と実装、システムの外部設計とシステム研修のマニュアル作成など
②SS関係（開始-開始）：先行作業と同時に開始できる依存関係
例）画面設計とデータベース設計など
③FF関係（終了-終了）：先行作業が終了しないと終了できない依存関係
例）品質管理とテスト、テストとリリース（次行程開始）
④SF関係（開始-終了）：先行作業が開始すると完了できる依存関係
例）新システムの運用と旧システムの運用など
FF関係はこの後に説明しているマイルストーンの設定で役に立ちます。たとえば、システムと本番データが揃っていなければリリースができないという関係が、FF関係に該当します。一方で、SF関係は現れることがまれであるため「そのような依存関係もある」程度の認識で十分です。
2-2.リソースを考慮してスケジュールを平準化する
タスクを並列化させた後は、作業の人員計画に山と谷ができていないか確認します。
ここでいう「山」と「谷」はその時点での稼働している人数の総量を時系列に示したものです。人員の稼働計画を積み上げグラフにすると、出っ張った部分やへこんだ部分が山や谷に見えることから、そう呼ばれます。
システム開発ではスポットで作業することが困難であり、今月は50人、来月は10人、再来月はまた50人というような人員計画は成り立ちません。
左側のグラフのように山と谷が出来た場合は、右側のグラフのように、なるべく山と谷が出ないように作業割り当てを平準化します。
Tips:作業を平準化するにあたってのコツ
作業者一人一人を個別に考慮すると、プロジェクト開始後のタスク調整が煩雑になります。そのため、作業を個人ではなくチームに対して割り当てる方法が有用です。ちなみに、1人の管理者が適切に管理できる人数は5～8人程度（スパンオブコントロール）とされています。この基準に基づき、体制図をもとにして管理者（リーダー）と作業者の割合が不均衡にならないように体制を分割します。
アメリカのAmazonでは「ピザ2枚チーム」というルールがあります。これは、2枚のピザで満足できる程度のチーム規模、つまり10名未満のチームが理想的であるとし、小規模であるほど効率的かつ生産的であるとされるルールです。
3.作業期間の妥当性チェック
ここまで来て効率の良いスケジュールができましたが、果たして本当に実現可能なスケジュールでしょうか？ここで一度立ち止まり、作業工数と期間の妥当性をチェックします。
チェック方法は2つ考えられます。
①自社の実績数値を使用する
②公的機関の提供する統計数値を使用する
特にソフトウェア開発の分野では、JUAS（一般社団法人 日本情報システムユーザー協会）から提供されている以下の式で検証することがよくあります。
平均工期＝2.7×（投入人月の立方根）
※2008年には2.4×投入人月の立方根でしたが、近年は徐々にその数値が上昇しています。最新のデータを参照することをおすすめします。
Tips:期間見積結果が基準と乖離していた時の見直し観点
筆者が支援したプロジェクトの一例を挙げます。
期間見積もりが長すぎるケース（工数過大評価）では、心配性の担当者がチーム全員で成果物をレビューするという非常に慎重な計画を立てていました。この方法は、プロジェクトの性質や他のプロジェクトと比較しても、過剰なほど慎重であると言えます。
対照的に、期間見積もりが短すぎるケース（工数過小評価）では、作業者が素早くかつ非常に高い精度で作業し、手戻りも一切発生しないという前提でした。
これらの見積もりの乖離は、個々人の「品質」や「リスク」の考え方の違いに起因しています。そのため、期間見積もり（工数）を見直す際には、「品質」と「リスク」を論点に標準と比較し、感覚のズレを確認することを推奨します。
4.マイルストーンの設定
最後に、プロジェクトの目標としてマイルストーンを設定します。
長期プロジェクトでは、キックオフからリリースまで1年以上かかることが多く、計画通りに進むことはまれです。そのため、ステークホルダーと一緒に、計画通りにプロジェクトを続けるかどうかの意志決定タイミングを設けます。これがマイルストーンの役割です。このタイミングで、プロジェクトの現状をステークホルダーと共有し、遅延や課題があっても今後挽回できるか、追加のリソースや計画の変更が必要かどうかを判断します。
マイルストーンの設定タイミングと検討することの例
工程切り替え前：工程が終わり、次の工程の準備を始めるタイミングで、プロジェクトを進めるかどうか、残課題や現在の進捗、品質状況を評価します。
数ヶ月以上同じ作業が続く場合：現場の遅延が徐々に拡大していても、リカバリーが可能だと過信しないように、第三者の評価を1〜2ヶ月毎に設定します。
ここまででスケジュールが完成しました。お疲れ様でした。
WBSとスケジュール作成で大事なこと
誰がWBSやスケジュールを作成すべきでしょうか？プロジェクトの各チームを任されているチームリーダー、またはサブPMでしょうか？しばしば、PMが情熱を込めてWBSやスケジュールを作成しますが、メンバーがその背景や意図を理解していないことがあります。プロジェクトはPMだけで進めることはできません。リーダーやメンバーを巻き込むことで、チーム全体の情熱がWBSとスケジュールに反映されます。そのためにもスケジュールの作成を分担することを推奨します。
スケジュール作成の分担案
推奨する分担は以下の通りです。
WBSの作成（成果物と構造）：PMとリーダー
マスタースケジュール（Lv1〜Lv4）：PM
中日程（Lv4〜Lv6）：リーダー
作業台帳（Lv6〜Lv7）：作業メンバー
マスタースケジュールと中日程の境界は、専門領域の有無によります。Lv4のサブ工程を責任分解のラインとして、専門領域を持つ単位でWBSを分け、「専門領域」以下のプロセスは、それぞれのリーダーやメンバーに作成を委ねます。ただし、計画の責任をリーダーやメンバーに押しつけることは避けるべきです。計画の承認やそれに伴うリスク対策はPMの責任です。
スケジュールを作成する上でのPMの責務
筆者はスケジュールやWBS作成におけるPMの責務を以下と考えます。
プロジェクトの規模を可視化すること
各専門領域（リーダー）までの作業分解
論理的な順序関係の設定
予算や所要期間等の制約の設定
リスクへの準備とコンティンジェンシーの検討
もし、リーダーに専門領域のスキルが足りない場合、PMは適切な専門家を配置するか、外部からのサポートを求めることが責務です。それが難しい場合は、教育を含む計画を立てることも考慮に入れましょう。
最後に
スケジュールはプロジェクトを進める上での地図です。「段取り八割、仕事二割」と言われるように、プロジェクトの成否はいかに実行可能なスケジュールを作成するかにかかっています。
また、プロジェクトは1人で進めることはできません。ステークホルダーの協力を得るためにも、合意形成が必要です。ただし、合意を得るためには納得感が不可欠であり、そのためにはスケジュールの根拠が重要になります。
今回示した作成手順は、主観をなるべく排除し、根拠を基にスケジュールを作成する手順です。これまで直感でスケジュールを作成し、関係者との合意がなかなか得られなかった方も、今回紹介した手順やポイントを参考にすることで、より合意形成しやすい根拠を作ることができると考えています。
この「現場で使える！PM道具箱」では、その名の通りすぐに現場で使える考え方やテンプレート等のコンテンツをご提供しています。あなたの欲しい道具が探せばあるかも？ぜひ他の記事もご覧下さい！
ウルシステムズでは「現場で使える！PM道具箱」でご紹介したコンテンツにまつわる知見・経験豊富なコンサルタントが多数在籍しております。ぜひお気軽にご相談ください。