プロジェクト計画書の作り方｜スケジュール表を作成する
以前作成した“作業リスト”。
正式にはWBS（Work Breakdown Structure：作業分解構成図）と言いますが、このリストで洗いだしたそれぞれの作業を、
「誰が、いつからいつまで実施するのか」
を計画し、紙に書いたものがスケジュール表です。
もちろん"絵に描いた餅"では意味がありません。
計画を立てたプロジェクトマネージャーは、
・要員の割当て
・作業の開始時期
・作業の工数
それぞれに妥当である根拠がなければなりません。それを「いや、これくらいでやらないと間に合わないから」と現実を見ないで押し付けるようなスケジューリングにした時、そのプロジェクトは不幸な事態に見舞われます。
理想論ばかりで現実が見えていない人…とは、こういう人を言いますよね。
メンバーはこうしてできあがったスケジュールに沿ってプロジェクトの作業を進めていくことになりますが、
スケジュールが崩れるとドミノ倒しのように他の作業へと影響が波及します。
スケジュールが崩れると必ずその影響を受けて迷惑をこうむる人が出てきます。
ここがしっかりしていないと後で問題が噴出することになってしまいます。慎重に慎重を重ねてスケジュールを組むこと、それはプロジェクトの計画における非常に重要なポイントと言えます。
計画の肝と言ってもいいでしょう。
楽観的では困ります。
普段、皆さんはEXCEL等を使って自身のスケジュールを管理されている人も多いのではないでしょうか。企業やプロジェクトが許せば有償のサービスなどを利用している人も多いことでしょう。
プロジェクトにおけるスケジュール表もこれと基本は同じですが、複数のメンバーの予定を1枚の紙に書くことになりますから、少々特別な書き方を用います。
とはいうものの、実際のスケジュール表を見れば一目瞭然。
このような表し方で作成されたスケジュール表を正式には“ガントチャート”と呼び、プロジェクトにおけるスケジュール表の最もオーソドックスな書き方です（企業や現場での呼び名は様々で、“バーチャート”や“線表（せんぴょう）”などと呼ばれることもあります）。
元々、ガントチャートは建築現場や工事現場で使われていました。
当初はホワイトボードに枠を作って、作業ごとや担当者ごとに、
「何日(AM/PM)に、どこで、何の作業を担当するのか」
といったことを一覧管理するために使われていました。ＩＴ業界はこれを模倣して一般ビジネスにも普及し、ガントチャートが広まったとも言われています。
一般的にスケジュール表の左側には"作業リスト(WBS)"が並んでおり、「その作業を誰が実施するのか」という情報と「いつからいつまで実施するのか」という予定が棒線で書かれています。
なお、担当者と棒線は作業リストの最下層のものの右側にだけ書かれていますが、作業リストの上位の階層にあたるもの（例では「1.設計と製作準備」「2.屋台の制作」「2-1.本体」など）は作業の“分類(グループ名)”であり実際の作業があるわけではありませんので、これらの行には担当者と棒線は基本的に不要です。
マイルストーンとは
すでにお気付きかと思いますが、最初の行に作業リストとは関係ない“マイルストーン”という行を入れてあります。
マイルストーンとは、もともと1マイル毎に道路に設置された標石のこと（日本で言えば“一里塚”のようなもの）で、そこから転じて「何かの節目」という意味を表す英単語です。
プロジェクトにおけるマイルストーンとはスケジュール上で重要な節目となる日を表しており、「このマイルストーンがずれることになると大きな影響が起こる」というポイントに設定しておきます。
作業が始まった後にはスケジュール表を使ってプロジェクトの進行状況を確認するのですが、このマイルストーンを設定しておくことによって、
「このままこの作業が遅れるとマイルストーンに影響が出るぞ、
すぐに手を打たなければ！」
などのように、深刻な問題につながるスケジュールの遅延を早期に認識することができます。基本的に一度立てたマイルストーンを崩すことはしません。崩すときは根本的なスケジュールの見直し（納期の変更等）がある時だけです。
これは、夏休みの宿題にも似ています。
「最初の3日で漢字ドリル」
「次の4日で読書感想文」
のようにあらかじめ計画を立てていても、ついつい「夏休みは長い、まだ何とかなるさ！」とズルズル遅れを放置したまま最後に大慌てとなってしまいます。
「１週間後に国語の宿題完了」というマイルストーンを設定し、「漢字ドリルに５日かかってしまった、マイルストーンがあるから遊ばずこの２日で読書感想文を終わらせよう！」と、必ずそのポイントを守るよう遅れを取り戻していけば大事に至らなくて済むというわけです。
プロジェクトにたとえるならば、
・工程完了のタイミング（お客さまの承認）
・仕様凍結のタイミング
・お客様レビューのタイミング
・お客様受入テスト開始のタイミング
などは絶対に崩してはならないポイントとして、マイルストーン化することが多いと思います。逆にマイルストーンを正しく設定しようとする動きがないプロジェクトマネジメントは少々心配です。
プロジェクトマネージャーが、自身のマネジメント能力やお客さまを含むステークホルダーの適切な状況把握頻度や調整能力を正しく理解していない可能性があるからです。
「計画と現実との間のギャップがどの程度までなら調整可能か」
マイルストーンはその力量によって間隔を設定するべきだからです。自身やお客さまの力量を正確に把握しようとしなければなかなか定められないことでしょう。
スケジュールをどのように考えるか
では、スケジュール表を実際にどのように作っていくのでしょう。
(1) 縦にマイルストーン用の行と作業リスト、横に時間軸を入れた表を作る。
(2) マイルストーンの行にすでに確定しているマイルストーンを配置する。
すでに確定しているマイルストーンとは、お客さまと前もって約束した納期など、
スケジュールを作成するための前提となる期日のこと。
(3) 土日や祝日、夏季休業日など、カレンダーを確認しながらメンバーが作業を
行わない日を明確にする。
(4) 個々の作業の担当者を決め、必要な時間を見積もって棒線を引く。
この時、確定済マイルストーンに作業が収まりきらないような場合は、
新たにメンバー追加／作業分担し、複数作業を並行して進めることを検討。
また、見積りが困難な作業は、詳しい人や作業をお願いする担当者と相談する、
過去の似たようなプロジェクトの事例を参考にするなどして確認する。
(5) プロジェクトの重要なポイントとなる節目を決めて、マイルストーンを追加する。
(6) できあがったスケジュールに過不足がないか、しっかりと共有確認する。
以上がスケジュール表作成の流れになるのですが、最後の(6)で必ず確認しておきたいことが3点あります。
①作業間の“依存関係”が正しいか
依存関係とは、たとえば「ある作業が終わっていないと、別のある作業が開始できない」といった関係のことです。
先の例では、
「屋台の設計が終わらないと必要な材料が分からないから、材料の購入ができない」
「材料がないと木材の加工ができない」
などといった依存関係があるため、その順序に従って作業期間が配置されていなければなりません。
プロジェクトでいえば、
「仕様が決まってもいないのに設計ができるわけない」
「データを作成していないのに、テストが始められるわけがない」
と言ったものが該当します。
こうした作業間の依存関係／影響関係は数多く存在します。こうした関係性を正確に把握していなければ、実現可能なスケジュールを立案することは不可能です。
ですが当たり前のことなのに、無理やり進めようとするプロジェクトというのは珍しくありません。おそらくはプロジェクトマネージャーやそこに関与する多くのステークホルダーの間で「スケジュールの何たるか」を理解できていないことが原因なのでしょう。
分かりづらい場合は、このように作業間の依存関係を棒線と棒線の間に矢印で書き込むと考えやすくなります。これを"先行線"といいます。先行線は、常に右へ右へと伸びなければなりません（日単位で管理している場合、同日中に片付けられる作業であれば、垂直になることはあります）。
しかし、もし矢印が左側に向かって伸びている場合は依存関係が正しくないことになり、現実的に実行することが不可能となります。
②同一担当者が同一期間に複数の作業を行っていないか
原則として１人の人間が同時に２つの作業を行うことはできません。
ですから、このように担当者毎に「この人はまずこの作業をやって、その後はこの作業で・・・」とスケジュールを追いかけ、作業が重なっている部分がないかを確認していきます（日単位で管理している場合、同日中に片付けられる作業であれば重複することはあります）。
もちろんパフォーマンスの高い人や、作業内容が小さなものであれば、１日で複数のタスクを消化することは可能でしょう。しかし、可能であればあまりタスクを重複させるべきではありません。させるとしても、１日に１人日以上の作業となることがないよう配慮しなければなりません。
それ以上の作業を強要するようなスケジュールは必ずどこかで破綻します。
③スケジュールに“余裕度”があるか
プロジェクトでは何が起こるかわかりません。
それに、スケジュール表を作成する時に見積もった時間はあくまで予測であり、実際にはそれ以上に手間がかかる場合もあります。そのような場合に、余裕のない“ギッチギチ”のスケジュール表だと即座に破綻してしまうことになります。
そうした余裕度を"バッファ（余裕、緩衝）"と言います。
バッファには「〇〇と言う問題が起こった場合…」と具体的に対策工数を想定できるリスクバッファと、「何かあるかも知れないから」と抽象的な不安を払しょくするための余剰バッファがあります。
本来、お客さまの資金をお預かりして開発する私たちにとって、前者はお客さまのために用いるものとして妥当性を証明することが可能ですが、後者はあくまでもマネジメントの杜撰さを隠すため、あるいは必要以上に請求して儲けるためのもので、いざと言う時にお客さまに
「なんかちょっと高いんだけど、理由を説明してもらえる？」
と言われて言葉に詰まることになります。
もしも、コンペを実施されている場合、適切な説明が出来なければ失注…と言うことになるでしょう。
おたくの会社は請求金額が『高い』
にもかかわらず『適切な説明ができない』
というイメージがお客さまに刷り込まれると、次からは引き合いの話すら来なくなることもあります。スケジューリングの正確性、精密性はとても大事な交渉力の１つなのです。
私は、見積りを行う場合、お客さまが何をどう言ってきても関係なく一度思い込みをリセットし、
お客さまが全くの素人で、
どの部分について、何をどう聞いてきても、
その根拠が説明できるスケジュールにしよう
というコンセプトから始めます。
高くても、安くても、お客さまは適切な説明に基づいて"納得"ができれば、必ず正しいビジネスに応じてくれます。「安いのに、無茶な要求を押し付けてくる」ことも「急にスケジュールに変更を加えてくる」ことも原則無くなります。なぜなら、そのスケジュールが納得できるほど正しく、そうしないと成功できないと理解できているからです。
それを開発側が自分たちの都合で捻じ曲げれば、スケジュール通りに終わらなくなる責任を持たなくてはならなくなるのは当然です。
正しいビジネスに応じてくれるようになれば、仮にどうしても変更をお願いしたいような場合でも、こちらの適切ない要求（たとえば、納期の延長や、コストの追加）などにも気持ちよく応じてくれることでしょう。
そして、最後に
「うん！このスケジュール表なら多少の事が起こっても大丈夫そうだね！」
という十分な安心感を持つことができたら、スケジュール表作りを一旦完了としましょう。
いいなと思ったら応援しよう！
