【PMBOK】意味ないのか？スケジュールマネジメント 実務への活用方法

このシリーズは、私がこれまで経験してプロジェクトマネジメントのノウハウを、PMBOKの知識体系に沿って、駆け出しPMの方々や新入社員向けの研修資料的な位置づけでノウハウや考え方をまとめています。ぜひご覧ください。

スケジュールマネジメントにおける各プロセスは以下の通り。

スケジュールはプロジェクトマネージャー（PM）がコントロールすべきQCDSのうちの１つであるD（Delivery）を指しています。スケジュールコントロールがうまいPMはメンバからも信用され、メンバが活性化していきます。ワークライフバランスが叫ばれる昨今において重要な側面を持ちます。

また、スケジュール管理は工程ごとに管理の方法やポイントが変わってきます。そのため、計画段階と実行段階で、工程ごとの切り口とともに解説していきたいと思います。

スケジュールの作成

まずは、計画を立てるところからすべては始まります。

所要時間の見積

見積方法

スコープマネジメントにて定義したWBSをもとに各要素に対する作業時間の見積を行います。

代表的な算出方法は以下の通りです。これらの方法は組み合わせることが最も効果的です。

・過去経験則による見積

過去に同等の作業を実施していた場合、その時の実績値をもとに算出する方法です。しかし、実績値が綺麗に残っているとは限らないため、見積担当者の感覚に依る部分が大きくなってしまうことが難点です。しかし、最も早く見積が可能なため、多く採用されています。

・サンプリングによる見積

見積をするにあたって、一部の作業を先行してとある作業者に実施してもらう方法です。実績値を収集したのちは、その値に習熟度係数をかけ合わせることで調整を図ります。

しかし、とある作業者が先行して作業する分の工数（期間）が読めないため、最初のとっかかりは経験則に基づく見積にならざるを得ません。そこで、信頼できる作業者に計測を任せたうえで（いない場合は計測結果を慎重に精査する）、その計測値よりも余裕をもった見積値を算出することになります。

また、そもそも最初にサンプリングする際の稼働工数の確保や期間の確保をする必要があるため、どのような計画でサンプリングするかも重要な計画となります。（つまり、計画を作成するための作業見積を取得するための計画のようなものが必要になります。計画のための計画のような形です。）

・生産性（人日/FP）×FP数による見積

最も定量的な導出です。会社やプロジェクトによって使用するFPの考え方は異なる部分もありますが、一定のルールによって導出されたFP数をもとに算定します。

FPで算出しているので大丈夫という考えをしがちであるので注意が必要です。

FP数の算出はある程度の知識があれば、機械的に算出が可能であるものの、生産性を見誤ることが多いです。この生産性は過去プロジェクトを基にしたり、サンプリングしたりする方法もありますが、どうしても参考値がない場合は業界・社内標準の値を使用することになります。

しかし、業界・社内標準を使用する場合は、どこかのタイミングで見直しをすることを強くお勧めします。

上述した、３つの見積方法、いずれの場合であっても、導出された見積値に対して安全係数で除算、もしくは乗算することが推奨されます。

生産性×FP数による算出でタスクAの作業工数が10日となった場合であっても、作業タスクの見積としては÷0.8や×1.2を行います。

これにより、出来たバッファ（10人日×1.2 – 10人日 = 2人日）を活用しながらスケジュール全体を作成します。

見積時の注意点

後述しますが、見積もる作業工数がどこまでを考慮したものかが後々とても重要になります。

そこで、作業見積する際に漏れがちであったり、後々必要になりがちな工数について、後半で詳細に触れる内容もありますがここでも紹介したいと思います。

クリティカルパスと向き合う

スケジュールを作成する前に必ず確認しておくべきこととして、クリティカルパスの存在です。

クリティカルパスとなるタスクがその作業（プロジェクト）のタスク群の納期になります。

例えば、以下のような約２か月の設計工程におけるWBSを作成する際、各機能に対して各担当者をうまく当て込み、効率的にタスクを割り振ったとします。

しかし、このような作業見積となっている場合、どんなに各担当者が各機能を効率的に順繰りに対応したとしても、バッチEを担当する三宮さんのタスクが８週間かかる見込みであれば、この設計工程が完遂するのには８週間かかるという計算になってしまいます。

当たり前のような話ではあるが、こういったWBSの作成は避けなければなりません。

この場合、バッチEをさらに要素分解して複数担当者で分担ができないかどうかを考える必要があります。またそもそもとして、このような特筆して大きなタスクが１つだけ発生してしまうような機能定義（要件定義）の結論も避けるべきです。しかし、避けられないことも多いです。

前工程からも意識したうえで、WBS作成時により細かく要素分解を試みても実施できないような場合は、バッチEの完了＝設計工程の完了と定義するしかなくなります。

その判断自体は決して誤りではありませんが、そのような判断をした場合、他の機能に当たった担当者が設計工程完了までに手すきにならないように作業調整をする必要があります。

この時、次工程（実装の前の仮実装や、内部結合テスト（画面遷移））に先行着手したり、モンキーテストを挟んだりすることで進捗面、品質面で貯金を作ることが重要です。決して、メンバが手持ち無沙汰になってはいけません。

スケジュール作成

見積工数の内訳を見誤らない

見積工数をもとにスケジュールを作成することになりますが、ここで注意したいことがあります。

それは、今から扱う見積工数は、どこからどの作業範囲までを含んでいるかということです。

外部設計工数：10人日（0.5人月）と見積をした時、工程定義の仕方によってこの10人日に含まれる具体的な作業の範囲が異なることがあります。そのため、外部設計及び10人日の解像度を上げる必要があります。

以下のように見積担当者やPM、プロジェクトの工程定義によって変わってくるため、スケジュール作成者と見積担当者が異なる場合は特に注意が必要です。

バッファを制する

前述した通り、作業見積をする際は、安全係数を反映してバッファ工数を積ませることが大事です。しかし、せっかくできたバッファ工数の配置に失敗することがあります。

バッファ工数の使い方のコツは、バッファは最後に取っておくことです。

有名なパーキンソンの法則というものがあります。これは簡単に言えば、人間はバッファをどんどん消化してしまうというものです。

したがって、以下のように、バッファは最後にまとめておくようなスケジュール作成が望ましいです。

例１はそもそもバッファをバッファと見ず、期間いっぱいに計画を立てているので論外です。

例２はタスクごとにバッファを設けていますが、これではバッファを食いつぶすことになり、画面Aもしくは画面Bで遅延が発生した時のリカバリの手段を失うことになります。

例３が最も正しいバッファの配置の仕方です。２つのタスクをバッファなしの工数で計画したうえで、それぞれのタスクから出るバッファを最後にまとめておく方法です。

これにより遅延が発生した場合に、バッファ工数を切り崩してリカバリを防ぐことができようになります。

よくある落とし穴

作業見積やスケジュール作成、どちらのシーンでも起こりえますが、”レビュー工数”を見誤ったり、見落としたりしてはいけません。

レビューというと顧客レビューを想像しやすいですが、通常は作業者の成果物を顧客に見せる前に社内レビューを通します。下手な成果物を見せたり、担当者によってバラつきが出たりすることを防ぐためには必須となるプロセスです。

さらに、レビューを受けるということはレビューに対する指摘対応があります。

さらに言えば、指摘対応が正しく取り込まれたかどうか、レビューアの再チェックもあります。

このように細分化すると、”レビュー工数”といっても様々な側面があります。

そして、レビューを対面で実施する場合、そのレビュー工数は２倍、３倍となります。（顧客側の工数はベンダーが考慮する必要は厳密にはないかもしれません。）

仮に、１時間の社内レビュー、１時間の顧客レビューにレビューイ、レビューアの２名が参加したとするとそれだけで社内レビュー２人時（１時間×２名）＋顧客レビュー２人時（１時間×２名）の計４人時の工数を消化することになります。

さらに、打合せが発生するということはその打合せに向けて多少なりとも付随する細かい準備（資料の準備、スケジュール調整、会議室の移動、アジェンダの作成など）が発生し、実態としては計４人時以上となることが多いです。

つまり、レビュー工数は勿論、レビューの回数、レビュー指摘に対する対応、レビューに参加する人数、またそれに付随してかかる工数についても見落とさないようにしなければなりません。

レビューは品質を上げるうえで欠かせないタスクであり、レビューがうまくいけばベンダーと顧客双方にとってハッピーな結末となりますが、その分工数を投下することに繋がっているため、バランスを取ることが重要です。

スケジュールの監視・コントロール

計画を立てることが出来たら、次はその計画が遅延しないように監視、コントロールしていきます。

遅延予防策

要件定義工程

〇ユーザ部門に参画を促す

要件定義はユーザ部門が主体です。そのため、ユーザ部門の参加度合いが薄いと、いくらベンダーが優秀であっても要件は煮詰まらないです。

そのため、ステークホルダーマネジメントの段階で、顧客側の事務局、情報システム部門と協力してユーザ部門のキーマンとなる担当者を必ず参加させることが最重要です。

そして、必要な決定権を委ねることです。（ベンダーは委ねることを顧客側に促します。）

また、可能であれば、顧客側でプロジェクト専任部隊を結成していただき、通常業務から一旦離れて、プロジェクトに割くことができる工数を確保する動きも取るとより良いです。

〇優先度を付けた要件定義

要件定義は議論しなければいけないことが多いです。

場合によっては要件を切り捨てや、最悪の場合設計工程以降に持ち越したりしてもリカバリは可能です。

そのため、必ず決定しなければいけない要件の確定や重要要件の整理から実施するといったように優先度をつけて議論することで遅延を招くことを防ぎます。

〇トップダウンで方向性を示す

要件定義工程でよくある遅延として、顧客ユーザ部門の意見がまとまらず、収束しないことが挙げられます。ユーザ部門間でも利害関係があり、各部門にとって都合の良いことを言うのは当然です。

このような場合、ベンダー側で意見を収束させることは難しいです。（コンサルの立場でも参画している場合は、収束しやすいです。）

その時、鍵となるのがプロジェクトの方針がどうであるかです。

そして、そのプロジェクトの方針を決めるのは、プロジェクトオーナーです。

プロジェクトオーナーにしっかりと方向性を示してもらい、意見を収束させることも重要であり、ＰＭはプロジェクトオーナーを巻き込み、味方につけた運営をすることが求められます。

例えば、パッケージシステム導入の際に、システムを業務に合わせるようにアドオンするか、業務をシステムに合わせるように標準機能を適合するかの際、トップダウンとして業務をシステムに合わせるという旗印に掲げていれば、結論を導きやすくなります。

〇進捗確認の仕組化

この対策は要件定義工程に限らず、すべての工程に通じていえます。

ＰＭが進捗状況を常に早く、正確にキャッチできる状態・ルールを確立しておくことです。

具体的には、各チームリーダとの定期的（週１～２回）な進捗会議の開催や、メンバ全員からの週報・日報の提出のルール化などが挙げられます。プロジェクト規模が小さければ、ＰＭが朝会で毎日メンバ全員の進捗を確認しても良いです。

ＰＭが進捗確認する際のポイントを挙げたいと思います。

ＰＭはチームリーダやメンバの報告をすべて鵜呑みにしてはいけません。「問題ないです」「順調です」の発言の裏には何かきな臭さを疑う嗅覚を持たなければいけません。

問題がありそうな場合にＰＭは対策を考えますが、メンバが余程頼りにならない限りは報告者自身に問題に対する解決策を出させることも忘れてはいけません。報告者本人に考えさせることで当事者意識を生ませ、責任感を持たせることで、プロジェクトを前進させることに繋がります。

一方で、決してＰＭはすべての報告を否定してはいけません。根拠は聞くが、どんなに悪い報告であってもまず報告してくれたことを感謝しなくてはなりません。

報告に対して感謝する、これだけは忘れてはいけません。

設計・開発工程

〇レビュー計画の決定

要件定義工程でも同じですが、ベンダー側が主体となる設計工程はベンダーが主導して顧客を巻き込む必要があります。そういう意味で、レビュー計画を先に立てることで、そのターゲットに向けて成果物を作成するようにプロジェクト全体を意識付けすることができます。

一方、レビュースケジュールありきの無茶な作業計画にならないようにだけは気を付けなければなりません。

〇勉強会や作業説明の実施

設計工程や開発工程が遅延する大きな原因の１つに、作業者（メンバ）の理解不足が挙げられます。要件定義や設計といった上位工程で決まった内容を十分に理解せずに、メンバが進めることで手詰まりになったり、せっかく出来上がった成果物の品質も悪く手戻りになったりすることが多いです。

そこで、事前に有識者からの勉強会の開催や、設計や開発する前に、要件定義実施者や設計者から次工程の担当者に説明をするための時間を確保しておきます。

ただし、当然、勉強会や作業説明のための工数も作業工数の見積時に含めておかなければなりません。

逆にいえば、作業工数見積時点で、有識者からメンバへ仕様を伝える工数が必要になるかどうか（具体的には設計者と実装者が異なるような計画になるかどうか）を検討しておく必要があります。

テスト工程

〇テスト工数は思ってるよりも多く確保する

テスト工程でよくある遅延の理由が、テストデータの作成に時間がかかるというものがあります。

これは、テスト担当者の仕様に対する理解不足が挙げられますが、この原因を対処するためには、理解するための工数が必要です。

しかし、往々にして、テストデータの作成工数はしばしば欠落します。そのため注意が必要です。

〇テスト工程の削減は期待しない

作業工数見積時の話にもなりますが、テスト工程の削減は大抵の場合期待できません。過度な期待しない方が良いです。

よくある作業計画の失敗として、画面Ａと画面Ｂは類似機能であるため、画面Ａが作成できれば画面Ｂの工数は画面Ａの７割で済むと考えることがあります。確かに、画面ＡのＰＧをもとに画面Ｂを作成することで製造工数は削減できますが、テストは画面Ａと同様に実施しなければいけないので、テスト工数は削減できないということになります。

共通機能として独立させておくか、画面Ａと画面Ｂが全く同じであればテストは不要にはなりますが、そもそもその場合はどちらか１つの画面に済ませるべきです。

スケジュール監視・コントロール

遅延が発生しないような予防策を打ち、実際にプロジェクトが進行したら、スケジュールを監視・コントロールしていきます。この際の確認ポイントについて解説します。

〇課題件数の増減傾向

課題件数が増加傾向にあり、オープン件数が増加傾向にある場合、収束に向かうかどうかを注視します。

逆に、要件定義工程の前半をはじめとして各工程の前半など、課題が出て然るべきタイミングでは、課題が順調に出ているかという視点で監視することがポイントです。

〇レビュー指摘密度・指摘件数の増減傾向

レビュー件数は多すぎも少なすぎも良くないです。そのため、一般的にはレビュー指摘密度という指標を設けて評価します（品質観点）。

小規模プロジェクトによっては、基準となる指摘密度を設けづらいプロジェクトも実際は存在します。

その場合、レビューを繰り返し行っても指摘が出続けたり、同じような指摘が繰り返されるような場合は品質に問題があると疑ってかかります。

ひいては、品質悪化が進捗遅延を招くことに繋がるため、注視していきます。

〇バッファ工数の減少傾向

後述しますが、遅延が発生した場合、第一の対処としてはバッファ工数の切り崩しが挙げられます。

しかし、バッファ工数がいくらあっても、バッファ工数を切り崩し続けている場合は危険です。

結局、想定した工数内で収まらず、ズルズルとスケジュールを後ろ倒しにすることに繋がるからです。バッファ工数の切り崩しは実施しても問題ありませんが、その後の状態について注意が必要です。

〇メンバの稼働状況

スケジュールがオンスケ（SV＞０）であっても注意が必要です。

実際は、メンバが毎日21時、22時まで残業してやっとオンスケになっている場合は、黄色信号です。当然タイミングによっては残業が多くなることもありますが、これが慢性的になっている場合は、いずれガタが来ます。所謂、コスト効率が良くない（CV＜０）状態です。

実際には想定工数が足りずい、残業でカバーしている状況のため、計画の見直しを強いられる局面が来ると考えておくべきです。

遅延後リカバリ策

続いて、遅延発生後のリカバリ策について解説します。

どの工程にも共通して言えることとして、まず第一にバッファ工数の切り崩しを考えます。

バッファ工数内の遅延幅であれば、まだＰＭの手の内です。そのため、まずは是が非でもバッファ内で完了できることを目指します。

しかし、それでも遅延が解消できない場合は、品質（Ｑ）（スコープ（Ｓ）を狭めることも品質低下とする）、コスト（Ｃ）のいずれか落とすことになります。とはいえ、品質を落とすことはできないため、要員増加や稼働増をもってしてリカバリに当たることになります。

要件定義工程

〇顧客のタスクを巻き取る

要件定義工程の遅延理由の１つに顧客（情シス、事務局、ユーザ部門）が多忙であるため、顧客側のタスク遅延によりプロジェクト全体が遅延することがあります。

無論、ユーザ部門の普段の業務を代わりに実施することはできませんが、顧客が作成する予定であったドキュメント作成、例えば、システム操作マニュアルなどについて、ベンダー側から支援要員を投入することでプロジェクト全体を前に進めることを考えます。

〇責任者のアサイン

要件定義工程は、意見が収束しないことがやはり一番の遅延要因です。

意見を収束させるために、各部門の責任者や、その責任者から権限を委譲された担当者をアサインしてもらうことで、意見を収集を実施してもらうことが効果的です。

設計・開発工程

〇機能の優先度を付けて見送る

本来、要件定義工程にて機能一覧を定義し、その一覧にある機能を設計、開発していくことになります。しかし、どうしても遅延が解消できない場合は、一部の機能を次期開発に回したり、カットオーバーを見送ったりします。

そのために、優先度を付けることでプロジェクトオーナーや顧客に対して判断を仰ぐことになります。

〇追加要員の投下

テスト工程でもいえることですが、要員増加でリカバリすることはよくある方法です。

しかし、要員追加は一時的なプロジェクトの生産性を下げ、受入側の負荷増大を招くうえに、プロジェクト内のコミュニケーションパスが増え、混乱を招くことにもつながります。当然、プロジェクトの採算（コスト）を悪化させます。

そのため、要員追加する場合は最大限に慎重になるべきであることは肝に銘じておきます。

そして、なるべく簡単な作業を切り出して担当させるようにタスク調整をすることがポイントです。

テスト工程

〇テスト可能なケースや項目からテスト

製造工程の遅れが尾を引いてテスト工程が遅延している場合や、テスト不具合の解消に時間がかかっている場合、テスト消化が可能なテストケースから実施します。

根本的な解決にはなりませんが、効率的に進捗できる部分から対応していくことは定石の１つです。

〇部分稼働の実施

一部のサブシステムや機能（例えば、バッチ処理による週次・月次処理）については本稼働日を遅らせます。

しかし、当然これは当初の契約を違反することになります。

そのため、プロジェクト関係者や顧客、プロジェクトオーナへの説明は必須です。

注意点

プロジェクトにおいて予期せぬ事態が起こり、遅延を招くということは当たり前ですが、その遅延をどう対処していくかがポイントです。

しかし、注意すべき点として計画を修正した場合は、新たなリスクを抱えることになります。

例えば、バッファをすべて切り崩した場合、もうバッファという手持ちの武器はなくなります。そうなると、次に再び遅延が出た場合、バッファを使うという対処ができなくなります。

このリスクをどう捌くか、どうケアするかを合わせて検討しておき、対策を打つことができるＰＭこそが真のＰＭだと言えます。

まとめ

以上、進捗管理は非常に重要なテーマです。

スケジュールマネジメントは、他の知識領域（資源マネジメント、リスクマネジメント、品質マネジメントなど）と非常に深く関わりがあります。

他の知識領域についても整理しているため、合わせて御覧いただければ幸いです。

参考文献

・情報処理教科書 プロジェクトマネージャ　（三好康之著）

私は2019年度版を参考にしています。

・プロジェクトマネジメント実践講座 伊藤大輔（著）