プロジェクトマネジメント（第5回）です。
今回はプロジェクトのスケジュール管理です。
新人の頃、「仕事は間に合わなければ０点だ」と教えられました。これは例えば、どんなに立派な資料を作ったとしてもそれが締め切りに間に合わなければ意味がない。だから30点でも50点の資料でもいいから締め切りだけは守れ、ということでした。
が、なかなか30点で提出すると、当然受け取ってもらえず、残業する羽目になり、締め切り直前までバタバタすることも多かったです。振り返ると、私の実力不足もありましたが、もともとのスケジュールに無理があったり、関係する業務との連携がうまくいっていなかったというのが原因だったような気がします。ちょっとした依頼においてすらスケジュール管理は大切ですが、プロジェクトが巨大になればなるほど、そのスケジューリングはプロジェクトの成否を握るものとなります。
（補足：「時間」はプロジェクトの3大制約「Scope」「Cost」「Time」の1つです。）
さて、WBS（作業の一覧表）
を作ったら、それをもとにプロジェクトのスケジュールを作ります。
今回のProject Schedule Managementについては、概要の紹介として、以下に、Project Schedule Managementの流れや、それに用いる手法を列挙しますが、あくまでキーワード程度で触れることとし、このブログでは主にスケジューリングにおいて留意すべきと私が感じた事項について記載したいと思います。
１．Project Schedule Managementの流れ
１）Plan Schedule Management：スケジュールを作成するにあたっての方針や手続きの決定。例：どういったツールを用いるか。どの程度の正確さでスケジュールを見積もるか等。
２）Define Activities：作業の洗い出し
３）Sequence Activities：それぞれの作業のつながりの確認 例）作業Bは作業Aが終わらないと着手できない。
４）Estimate Activity Durations：作業期間の見積もり
５）Develop Schedule：スケジュールの作成
６）Control Schedule：スケジュールのコントロール
２．手法
それぞれの作業のつながりを表すためには、「Arrow Diagramming Method」（いわゆるアローダイアグラム）などが用いられます。
また、作業期間を算出するために、ある作業についての3つの期間（作業を終えるのにもっともありえそうな日数、最も早く終わる場合の日数、最も時間がかかる場合の日数）の平均をとる「Three-Point Estimating」などが用いられます。
スケジュールを作成するにあたっては、プロジェクトの全工程を最短期間で完了するための作業行程であるクリティカルパスを算出する「Critical Path Method」などが用いられます。
スケジュールを組むうえでのバッファー（余裕期間）の与え方としては、各作業ごとにバッファーを与えたり、またTheory of Constraintsに基づく「Critical Chain Scheduling」などが用いられます。
スケジュールのコントロールに際しては、遅れを取り戻すための作業短縮の代表的な2つの方法として、「Fast tracking」（前の作業の終盤部分と次の作業を序盤部分を同時並行で行う方法）や「Crashing」（人員を増やすなどしてある作業工程を短くする）があります。
３．気づき（教科書の記述を踏まえた自分の意見）
Project Schedule Managementにおいてやはり大切なことは以下ではないかと思います。
１）現実的な工程を組む
これに尽きます。プロジェクト当初は、様々な関係者からの要求に基づき、ともすれば理想的な行程を描いてしまいがちです。これは後々禍根を残します。
例えば、土木プロジェクトにいくつかかかわった私の経験では、私が担当者となるずっと以前に書かかれた絵に描いた餅のような（正確には、理想的な）工程表を見たこともあります。もちろんその理想的な工程は不可能というわけではなかったのです。晴天が続いたり、十分な予算があったりすれば可能だったのですが、リスクも不確実性も考慮していないスケジュールには意味がありません。
長期のプロジェクトになればなるほど不確定要素も大きくなるため、その影響も考慮し、適切なバッファーが必要です。なお、多すぎるバッファーは、結局作業を遅らせることとなりがちです。（パーキンソンの法則：仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する）
また、ある作業を短縮すればコストがかさみますし、複数の作業を同時並行で行えばリスクが高まります。こういった当然のことをスケジュールの作成や修正に当たって、しっかり反映することが必要です。作業員が常に120％で動くことを前提とした工程は極めて危険です。
２）関係者間での情報共有
現実的に工程を組んだとしても、当然遅れが生じる場合がありますが、その場合はすぐに後工程の関係者に連絡すべきです。特にプロジェクトの後半の作業を担当する部署は、作業の遅れを批判されがちですが、前工程の遅れが原因であり、どれほど後半の作業部隊が頑張ったとしても挽回不可能な場合もあります。逆に行程に余裕が生まれたのであれば、ムダに急がせる必要のない作業については、その旨速やかに伝え、今後に備えて余力を蓄えておいてもらった方が良いです。
また、内部関係者であれば、残業などの無理がきくかもしれませんが、外部関係者についてはこちらがコントロールできないことが多いです。外部の影響を受ける作業の前後にはバッファーを設けたいです。
３）ソフトウェアの活用とデータの収集
現実的な工程を組むためにも、また情報共有のためにも、ソフトウェアを活用したいです。
ソフトウェアを活用することにより、クリティカルパスが一瞬で分かったり、ある作業の作業期間の変更を即座に全体行程に反映、つまり関係者全員に周知できます。そしてソフトウェアを通じてデータを蓄積することは今後のプロジェクトに活用することができます。もちろん、ソフトウェアの活用に当たっては、Project Schedule Managementの流れや各手法についての理解が必要です。
４．最後に
以下の文書を紹介します。（注：私自身は原本を見ていません。是非見てみたいです。）
『国立屋内総合競技場施工記録 1964年 関東地方建設局営繕部』より抜粋
「全工期を通じて雨天日数が意外に少なく、台風シーズンもさしたる事なく通過した事は誠に天祐と云わざるを得ない」
「本施設はすぐれた設計、施工者の技術力と犠牲的な努力により是又好天にも恵まれ8月末の完成を見、無事にオリンピックを迎えることが出来た」
「最後に此のような工事が同じ単価で同じ工期内で完成させることはおそらく不可能であるという事を附記したい」
「オリンピックの旗印のもとに最多の無理が通り道理がひっこんだのであって、このような事例を再現させてはならないと思う」
参照：
Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide) (Sixth ed.). Newtown Square, Pennsylvania: Project Management Institute, Inc.
Schwalbe, K. (2015). Information technology project management (Eighth ed.)
