プロジェクトマネジメントで最も大切な「スケジュール」について改めてきちんと考えてみた

みなさん、こんにちは。
D2C IDでディレクター、プロジェクトマネージャーをしている三谷と申します。

突然ですが、「スケジュール」って難しいですよね。
ディレクターと呼ばれる仕事を始めて10数年になりますが、いまだに悩むし、とても「スケジュール得意です！」なんて言える立場にありません・・・

ただ、プロジェクトマネジメントというのは、スケジュールが全てと言っても過言ではないとも思っています。

そこで今回は、自分がこれまで仕事をしていく中で感じていた、スケジュールについての考えを改めて整理してみたいと思います。

少し長くなりますが、スケジュールについて悩む人たちにとって、少しでも助けになれば幸いです。

WBSとは

WBSへのよくある勘違い

はじめに、よくある「WBS＝スケジュール」という勘違いについて少しお話しさせてください。

よく、下記のようなスケジュール表をWBSと呼ぶ人がいますが、厳密にはこれは誤りです。

これはガントチャートと呼ばれるもので、アメリカのヘンリー・ガントさんが1910年頃に考案したとされています。

ガントチャートは縦軸をタスクや行、横軸を時間にしてグラフ形式にしたもので、いつ・どの作業が・どれくらい続くかを把握するためによく使われます。

ヘンリー・ガント
ヘンリー・ローレンス・ガント（英: Henry Laurence Gantt、1861年5月20日 - 1919年11月23日）は、アメリカ合衆国の機械工学者で経営コンサルタント。1910年代にガントチャートを考案したことで知られている。ガントチャートはフーバーダムや州間高速道路といった大型公共事業で使われ、現在でもプロジェクトマネジメントの重要なツールの1つとなっている。

(Wikipediaより引用)

ガントチャートもWBSと無関係では無いのですが、ガントチャートやスケジュールのことを「WBS」と呼ぶと関係者間で何を指しているかがバラバラになってしまうこともあるので注意しましょう。

WBS = Work Breakdown Structure

では、WBSとはなんなのでしょうか。

WBSとは、Work Breakdown Structureの頭文字を取った略称です。
読んで字の如く、Work(ワーク＝仕事/タスク)を、Breakdown(ブレイクダウン＝細分化)した上で、Structure(ストラクチャー＝構造化)したものを指します。

ガントチャートはWBSそのものではなく、WBSを時間軸に合わせて配置したものと言えるでしょう。

WBS自体はどんな形式でも構いません。
下記のようなツリー状の図でまとめても良いですし、markdownなどのテキスト形式でまとめる形でも良いと思います。

私の場合は、最近はWorkFlowyのようなアウトライナーと呼ばれるツールを使うことが多くなっています。

※アウトライナーについては、『ライティングの哲学　書けない悩みのための執筆論』(千葉雅也・山内朋樹・読書猿・瀬下翔太 / 星海社新書)で知りました。WBSをつくるとき以外でも、自分の頭の中をライトに整理することができるので色々と重宝しています。このブログの記事もまずはアウトライナーで構成を考えてから書き始めています。

WBSをつくる意味

複雑なプロジェクトになればなるほど、いきなりガントチャートをつくるのではなく、まずはWBSを作成することが重要になってきます。

では、ガントチャートの前にWBSをつくる意味とはなんでしょうか？

1. タスクの抜け漏れをなくす

WBSをつくる際には、なるべく細かくタスクを洗い出すことを意識しましょう。

ついつい意識の外に追いやってしまいがちなタスクや、細かいけれど重要なタスクがないか。後々のトラブルの原因となりうるタスクを見落としていないかを自問自答しながら、落ち着いてしっかり考えていきます。

いきなりガントチャートをつくろうとすると、どうしてもスケジュールとして表現しづらいタスクや、まだ見えていないタスクが抜け落ちてしまいます。

プロジェクトも後半になって「あれ、そういえばこのこと決めていなかった！」となって慌てないためにも、まずはWBSとして洗い出すことが重要です。

2. タスクの依存関係を整理する

プロジェクトにおいては「タスクAが完了しないと着手できないタスクB」もあれば、「タスクAが完了かどうかに関わらず開始できるタスクC」もあり、複数のタスクが複雑に絡み合っていきます。
(これをタスクの依存関係と呼びます。)

ここの共通認識が出来ていないと、タスクAが遅れた際に「まだ終わってないけど、タスクBは進められるよね？」「いや、タスクAが終わらないとタスクBに着手できないんですが・・・」のような行き違いが発生し、プロジェクト全体の遅延につながってしまいます。

もちろん、ガントチャートでもある程度は依存関係を可視化することはできますが、どうしても限界があります。
WBSとして整理する方が、2層3層にわたる依存関係なども比較的にすっきり表現できます。

※なお、タスクの依存関係をWBSで表現するのが難しい場合は、下記のようなクリティカルパスと呼ばれる図をつくって明示化します。

WBSの解像度の高さ = プロジェクトが見通せているかどうか

解像度の高いWBSを描けるかどうかというのは、つまりプロジェクトマネージャーがどれだけそのプロジェクトを見通せているかどうかと言うことです。

逆に言うと、粗いWBSしか描けないのであれば、それはまだまだプロジェクトへの理解が足りていない状況です。

もちろん、すべてのプロジェクトにおいて開始時点からすべてを見通せるわけではないですし、必ずしも最初から完璧なWBSを描ける必要はないのですが、「自分がどのくらい見通せていないか」を知ることは重要です。

ドライブに例えると、自分が霧の中にいるとわかっていれば対向車や急カーブに注意しながら慎重に運転できますが、霧の中でも普段通りの運転をしているといつか必ず事故を起こしますよね？
同じ霧の中にいる状態でも、自分たちの状況を把握した上で、適切な行動を取れるかどうかで、その先の未来がだいぶ変わってしまいます。

解像度の低いWBSしか描けないのであれば、まずはそのことをしっかりと理解した上で、解像度を高くしていくにはどのようなアクションを取るべきかを意識していきましょう。

WBSとして必要なタスクを充分に洗い出すことができたら、それを元にスケジュールをつくっていきましょう。

スケジュールをつくる意味とは

そもそも、なぜスケジュールが必要なのでしょうか？
スケジュールをつくる意味について改めて考えてみたいと思います。

スケジュールをつくる = プロジェクトを計画する

プロジェクトマネジメント協会(Project Management Institute)が発行する、プロジェクトについての知識体系『Project Management Body of Knowledge』、通称PMBOKでは「プロジェクト」を以下のように定義しています。

独自のプロダクト、サービス、所産を創造するために実施される有期的な業務である

つまり、そもそも終わりがあるものをプロジェクトと呼ぶわけです。

プロジェクトとは始まった瞬間から、みんなの中にそれぞれイメージするスケジュールが存在しています。
ただし、イメージしているものは全員バラバラかもしれません。

誰かがそれを具現化することで、ようやく認識のすり合わせができるようになります。

つまり、「スケジュールをつくる」ということは、「プロジェクトの計画を立て、関係者間での認識をすり合わせる行為」と言えるでしょう。

納期がないと進捗しない

パーキンソンの法則をご存知でしょうか？

パーキンソンの法則
パーキンソンの法則（パーキンソンのほうそく、英語: Parkinson’s law）とは、ある資源に対する需要は、その資源が入手可能な量まで膨張するという法則である。(中略) 時間やお金といった「あらゆる資源」を人間はあればあるだけ使ってしまうこと。

(Wikipediaより)

人はどれだけ時間があっても締め切りいっぱい時間をつかってしまうし、締め切りがない仕事は後回しにしてしまいます。
(このブログも締め切り間際にせっせと書いています・・・)

つまり、そもそもスケジュールがないプロジェクトは進まないということです。

締め切りがなくても関係者が自発的にタスクをこなし、自律的に完遂されるというのがプロジェクトの理想的な形ですが、なかなかそうはいきません。

忙しさにかまけてまったく進捗しないというのを避けるためにもスケジュールは必要なのです。

リスクヘッジになる

プロジェクトにトラブルはつきもので、場合によっては残念ながら公開や納品が遅延してしまうケースも発生してしまいます。

そんなとき、どんなに自分たちに非がなくても、3日前に突然「間に合いません」と告げられても、他の関係者からすればとても受け入れらるものではありません。

こういう重大な状況に至るまでには、だいぶ前からその予兆があったはずです。

スケジュールがあることで、プロジェクトの状態が適正かどうかを細かく判断していくことができ、リスクを早めに発見できることができますし、万が一、公開や納期の遅延が発生した場合でもそれが自分の責によるものだけかどうかの証拠にもなります。

ただしこれは、スケジュールを最初につくったきり放置していては効力を発揮しません。

この後でも述べますが、スケジュールは適正に運用していくことが重要です。

スケジュールをつくる意味が薄い場合

これまでスケジュールをつくる意味について述べてきましたが、逆に、スケジュールをつくる意味があまりないのはどういうケースでしょうか？

それは、端的に言うとスケジュールをつくるコスト(手間)が、つくるメリットよりも上回るケースです。

• 前提条件がコロコロ変わって毎週大幅なスケジュール変更が必要になる
• そもそも実現可能かどうか判断できてない
• ゴールがどこにあるかが確定していない

などの場合は、スケジュールをつくるよりも他に優先して確認・決定すべきことがあると言えるでしょう。

もちろん、「仮定として」「暫定的に」スケジュールをもとめられる場合もあると思いますが、仮のはずのスケジュールがいつの間にかコミットラインになってしまっていることも多いので注意しましょう。

スケジュールをつくるときの注意点

では、実際にスケジュールをつくる段階になったとき、どこに注意したら良いでしょうか？
いろいろな観点があると思いますが、私は以下の点を意識しています。

必要な粒度はどのくらいか

先ほどWBSをつくることの重要性について述べましたが、かと言ってWBSすべてをスケジュール化する必要があるわけではありません。

しっかりすべてのタスクをスケジュール化する必要がある場合もあれば、まずは全体像の把握のために各工程のマイルストーンを知りたいだけのこともあります。

人間の認知能力には限界があるので、いきなり何百行もあるガントチャートを見せられても全体像を捉えるのは困難です。
マイルストーンがほしいときに、何時間もかけて緻密なガントチャートを作成し、それで結局伝わらなかったら意味ないですよね？

スケジュールをつくるときは、そのスケジュールの目的からどのくらいの粒度が必要かを逆算して、適切なコスト(手間)をかけることを意識しましょう。

メンテナンスすること前提でつくる

スケジュールは一度つくっては終わりではありません。

スケジュールを提示したところ認識が違って修正が必要になる場合もあれば、プロジェクトを進めるにあたって当初の計画から変更が必要になる場合もあります。

最初に緻密で完璧なスケジュールをつくったとしても、プロジェクトは進めるにあたりどんどん状況が変わってきます。
そのときに、緻密すぎて誰も修正ができず、結果として放置されてしまう・・・となってしまうと本末転倒です。

スケジュールはつくっておわりではなく状況に応じてメンテナンスをすることで、正しくプロジェクトの現状を把握することができるようになります。

スケジュールは必ずどこかで修正が入るものという前提で、メンテナンスしやすさも意識しながらつくっていきましょう。

バッファを持つことの重要性

スケジュールをつくると、関係者からこんな言葉を聞くことがあります。

「なんでこんなに時間がかかるんですか？」

皆さん、スケジュールをつくるときには多少のバッファを持たせていると思いますが、ここで改めてバッファの重要性について考えていきましょう。

不確実性に対処するため

プロジェクトというものは不確実性を孕んでいます。

仮にそのプロジェクト自体に問題がなくても、担当者が急な体調不良になったり、別件のトラブルに手を取られて本来やるべきだった作業ができなかったりといったこともありえます。

プロジェクト推進メンバー以外の決裁が必要な局面で、どうしてもその日に決裁者がつかまらないといったこともあると思います。

そうした予期せぬ事態が発生したときに、バッファがあればそこで吸収し、プロジェクト全体への影響を最小限でおさえることが可能です。

タイトなスケジュールは大幅遅延のリスクが増す

例えば、1日で終わるタスクの作業期間を1日しか取っていなかった場合について考えてみましょう。

スケジュール上でバッファがある場合

一般的には、以下の図のように、実際の作業工数に対してある程度のバッファを持たせてスケジュールを組みます。

このような場合に、何らかの事情でプロジェクトCの作業を5/19(月)に取り掛かることができなかったとしても、他のプロジェクトも含めてバッファがあるために、5/20(火)か5/21(水)に対応することが可能です。

バッファ期間中に対応ができるので、プロジェクトは計画通りに進行できます。

スケジュール上でバッファがまったくない場合

一方、バッファがまったくない場合を考えてみましょう。

何らかの事情で5/19(月)にプロジェクトCの作業に取りかかれなかった場合、翌日以降はプロジェクトA、プロジェクトBの作業が詰まっています。
こちらもバッファなしのため、その間プロジェクトCの作業に取り掛かることはできず、それらが終わるまでプロジェクトCの作業に再度取り掛かることはできません。

バッファがなかったばかりに、1日の遅れがプロジェクトとしては1週間以上の遅れにつながってしまうわけです。

少し極端な例ではありますが、タイトなスケジュールは何かあったときに取り返せないほど大幅な遅延が発生するリスクがあるということは理解しておきましょう。

「デッドライン」の難しさ

一方で、スケジュールにバッファをもたせていると、こんなことを聞かれる場合もあります。

「デッドラインはどこですか？」

こちらも非常に難しい質問です。
最後に、この問題について考えてみましょう。

実際には「デッドライン」は存在しない

例えば「10日(月)までに素材をご手配ください」と言っていたと仮定しましょう。

その素材が「1日遅れて11日(火)に手配となります！」となったときに、その時点で「じゃあ、公開に間に合いませんね。延期しましょう。」となるケースはきわめて稀です。

「デッドラインを教えて」と言われる場合を思い返してみると、たいていその時点ですでにスケジュールから遅延が発生していることがほとんどです。
要するに、デッドラインを聞かれている時点で遅れが発生しているので、デッドラインという名で締め切りを再設定してもそこに間に合わない可能性が充分ありうる状況です。

しかし、「14日(金)がデッドラインです」と伝えて、それでも間に合わなかったとしても、その場で即公開延期が決定できるほどドライな状況というのもなかなかありません。

結局は関係者がなんとか頑張って公開に間に合わせるというケースが多いと思います。

では、その場合、「公開が間に合って良かったね。めでたしめでたし」なのでしょうか？
そうではありません。納期には間に合ったとしても、その分だけ犠牲になったものが存在します。

犠牲になるのは「品質」

先ほど述べた通り、「明確なデッドライン」を判断するのは難しい問題です。

ですが「デッドラインを決める」という状況になってくると「良いものをつくろう」から「なんとか間に合わせよう」にスタンスが変わっていってしまいます。

納期にいきなり影響するものではなくても、その分だけ品質を犠牲にせざるをえない状況になっているということです。

「デッドラインを決める」という行為は、「納期遅延」という本当のデッドの前に、すでに「その分だけ品質を落とし続けること」という状況がすでに発生してしまっているというのを関係者全員で理解する必要があります。

※もちろん、そこからさらに度を越して遅れが発生すると納期遅延も発生しえますが、そこはケースバイケースのため、この記事では割愛します。

おわりに

最後までお読みいただき、ありがとうございます。

偉そうにここまでつらつらと書いてきましたが、私自身まだまだだなと思わされることも多く、

D2C IDへのお仕事をお待ちしております！

D2C IDではWebやデジタルの領域だけに留まらず、CX(顧客体験)の最大化をテーマにさまざまな分野で業種・業態を問わずに皆さまのビジネスへの支援を行っております。

D2C IDのこれまでのお仕事はこちらをご覧ください

何かお困りごとなどありましたら、ぜひお気軽に下記よりご連絡ください！

一緒に働く仲間も募集中です！

また、一緒に困難なプロジェクトを推進する仲間も大募集中です！

この記事を読んで、「一緒にD2C IDで働いてみたい」と思ってくれたディレクター、プロジェクトマネージャーの方はぜひ下記からご連絡ください！