第3回 タイムマネジメントは急がば回れ

第3回　タイムマネジメントは急がば回れ

杦岡充宏（スカイライトコンサルティング）
2004/6/16

　前回（「第2回　みんなを幸せにするスコープマネジメント」）は、プロジェクトの成否を分けるスコープの管理について解説した。プロジェクトの関係者全員が満足する結果が得られるようにスコープを設定し、状況に合わせて変更・管理していくことはなかなか難しい。しかし、プロジェクトのゴールを踏まえたうえでスコープを可視化し、優先順位付けの判断基準を明確にし、関係者全員の合意を得る努力をしていれば、おのずと納得のいく意思決定を下せるのではないだろうか。

　今回は、プロジェクトの推進に欠かせないタイムマネジメントの勘所を解説する。「第1回　プロジェクトメンバーを1つにまとめる」で触れたようにプロジェクトとは何らかの目的の達成を目指して、「一定期間」に行われる活動である。期限が定められているということがプロジェクトの特徴であり、期限を順守することはプロジェクトマネジメント（PM）において重要な要素であることはいうまでもないだろう。それではまず、PMBOK（Project Management Body Of Knowledge）におけるタイムマネジメントの定義を確認しておこう。

■タイムマネジメントとは

　タイムマネジメントとは、プロジェクト開始前の計画段階に必要な作業を洗い出しスケジュールを作成し、そのスケジュールの予定と実績を管理していくことである。前回のスコープマネジメントと同様、「Plan-Do-See-Action」のサイクルになっている。つまり、プロジェクト期間中、スケジュールは常に見直され、最新の状態に保たれていなければならない。PMBOKでは、タイムマネジメントは表1の5つのプロセスから構成されている。

タイムマネジメント
のプロセス 主要成果物 説明
作業定義 作業リスト、WBS更新版 スコープ定義で作成したWBSに基づき、実際の作業に分解する
作業順序設定 プロジェクトネットワーク図 作業間の順序関係を定義する
作業所要時間の見積もり 作業ごとの所要時間見積もり それぞれの作業を完成させるために必要な所要時間を見積もる
スケジュール作成 プロジェクトスケジュール 作業の開始日・終了日を決定する
スケジュール管理 プロジェクトスケジュール更新版 進ちょく度を測定し、スケジュール変更の管理を行う

表1　PMBOKにおけるタイムマネジメント

　タイムマネジメントはスケジュールマネジメントとも呼ばれるように、スケジュールを作成しないプロジェクトは存在しないといえよう。スケジュールはプロジェクトを進めていくうえでのよりどころである。しかし、多くのプロジェクトではスケジュールどおりには進まず悪戦苦闘している。どうすればよいのだろうか？

　プロジェクトの最初に立てたスケジュールどおりに最後まで終了すればプロジェクトマネージャとしてこんなうれしいことはない。しかし、その場合スケジュールを作成する時点でプロジェクトの成果物、必要な作業、そして各作業の所要工数がすべて確定していることが前提である。しかし、残念ながらこのようなケースは極めて少ない。スケジュールを作成する時点では情報が不足しており、思ったとおりに物事が進まないのが現実である。最初から完ぺきなスケジュールを作成できるとは思っていけないのである。

■作業定義は過不足なく、スケジュール管理は柔軟かつタイムリーに

　タイムマネジメントの目的は最初から完ぺきなスケジュールを作成することではなく、「納期どおりにプロジェクトを完了させるために必要な作業をスケジュールどおりに終了させること」である。

　完ぺきなスケジュールを組もうとするあまり、管理不能なほど詳細な作業定義を作成してしまったり、過去のプロジェクトで使ったスケジュールを無理に流用し、作業リストがプロジェクトの実態と乖離（かいり）してしまったりすることがある。このように、スケジュールの「体裁」に意識がいってしまうと、本来の目的を見失ってしまいがちである。

　重要なことは、

スケジュール作成時点では、納期やフェイズの終了時など重要なマイルストーンに大きな影響を与えないことに重点を置く
予定と差異が見られたときに迅速に適切な対応を取る
である。

　誤解のないように付け加えておくが、最初にち密なスケジュールを作成するなといっているわけではない。本来の目的を見失わず、凝り過ぎず、不確実性に対して柔軟に対処する心構えを持とうということだ。

　それでは、タイムマネジメントの実践的な勘所について、ケーススタディを通じて紹介していくことにしよう。

■進ちょく度を「判定」するだけではマネジメントとはいえない

　あなたの部署で進行中のプロジェクトのうち、納期遅れが心配されているものが2つある。営業担当からの要請を受け、あなたはそれぞれのプロジェクトを調査し、ばん回するためにはどうすればよいのかをエンジニアの立場から助言することになった。

そこで、それぞれのプロジェクトを担当している「矢見雲マネージャ」と「出来杉マネージャ」のもとを訪問し、状況を聞くことにした。

矢見雲マネージャの発言
　 「正直いって、当初予定していたスケジュールどおりには進んでいない」
「プロジェクトの開始時には、顧客が要求したマイルストーンをメンバーに周知したうえで、問題があれば報告するように伝えておいた」
「スケジュールが厳しいのは最初から承知のうえだ。だからメンバーには走りながら考えるように指示して、立ち上がりからアウトプットを出すように要求していた」
「ところが今回は私が得意としていたクライアント／サーバ系のシステムではなくWeb系のシステムだった。画面遷移が多いため、思っていた以上に設計書のボリュームが増えてしまった。負荷を軽減するために設計文書のフォーマットと作成単位を見直したが、途中まで作った設計文書もこれに合わせるため再度作り直す必要が出てきた」
「このままいくと、設計フェイズのマイルストーンは最低でも3週間遅れとなるが、開発フェイズでばん回できると信じている。顧客にはこれから説明するが、きっと理解を示してくれるだろう」
「メンバーも徹夜続きで大変疲れているが、どうか君を含め応援部隊の力を貸して欲しい。よろしく頼むよ」

出来杉マネージャの発言
　 「正直いって、当初予定していたスケジュールどおりには進んでいない」
「プロジェクト開始前には、顧客の要求したマイルストーンをクリアできるよう、作業定義を行ってスケジュールを調整しようとした」
「しかし、今回は私が得意としていたクライアント／サーバ系のシステムではなくWeb系のシステムだった。作業リストや作業順序については問題ないと思ったが、設計書のボリュームが読めなかったので従来の見積もりによる作業時間に10%のバッファを持たせることにした」
「この結果、顧客の要求したマイルストーンから2週間ほど遅れる計画となってしまった。」
「しかし、顧客はマイルストーンの変更を受け入れなかったので、何とかこのフェイズでばん回できるよう、スケジュールを短縮する方法を検討した。具体的には、10名のメンバーのうち2名だけ、業務範囲を絞ったうえで作業を先行させ、各作業の生産性データを収集するとともに、作業効率を改善するために何ができるかを検討してもらった」
「その結果、設計文書のフォーマットと作成単位を見直すことによって、作業時間が5％ほど改善することが分かった」
「これで遅れを1週間に縮めるメドがたった。作業を先行させたメンバーについては学習効果により生産性が上がっているので、チーム内における作業分担の見直しによって全体ではさらに期間短縮が可能だろう。メンバーには申し訳ないが、週末に何日か作業すれば十分にばん回できる見込みはあると思っている」

　スケジュールは、作業定義、順序、各作業の所要時間が見積もられていて初めて成立する。矢見雲マネージャのように「走りながら考える」というのはいささか乱暴な例ではあるとしても、作業ごとの所要時間まで事前に想定することはなかなか難しいのではないだろうか。PMBOKでは、見積もりの技法の1つとして類推見積もりを挙げている。これは、過去の作業や類似作業の実績値を用いて、作業の所要時間を推定するテクニックである。出来杉マネージャは、この技法を使って保守的な見積もりを行っている。経験を積んだシステム開発会社であれば、スケジュール作成時の方法論や見積もりの基礎となる実績データを全社で共有しているところもあるだろう。

　また、出来杉マネージャは先行チームを使って実測値を取り、さらに生産性改善の方策を探っている。大規模なプロジェクトであればあるほど、このような先行チームを持つことの意義は大きくなる。単に「信頼できる」実測値を取ることができるだけでなく、予測不能な問題を検知してプロジェクト全体での手戻りを最小限に食い止めることができるからだ。もちろん、プロジェクトマネージャは先行チームの成果を適切にプロジェクト全体にフィードバックし、共有できるよう配慮しなければならない。プロジェクトマネージャは単にスケジュールどおりに進んでいるかどうかを「判定」するだけでなく、作業を標準化し、負荷を平準化し、作業効率を高めることによって、スケジュールの実績値を「作り込む」努力をしなければならないのである。

■重要なタスクの抜け・漏れが生じる

　さて、2つのプロジェクトはその後開発フェイズに入り、単体テストを実施している。それぞれのマネージャの様子を見てみよう。

矢見雲マネージャの発言
　 「開発フェイズも単体テストに入り、一段落した感がある」
「これからは単体テストの実施に加えて、システムテストの準備をしていく必要がある」
「ところで、現行システムからのデータ移行についてはスケジュール上決まっていないことがほとんどだな」
「システムテストの準備で当面手いっぱいだから、データ移行についてはシステムテストの計画策定後ということにしよう」
「それでも少し不安だから、君を含め応援部隊の力を貸してほしい。よろしく頼むよ」

出来杉マネージャの発言
　 「開発フェイズも単体テストに入り、いよいよ開発の佳境に入ってきた」
「これからは単体テストの実施に加えて、システムテストの準備をしていく必要がある」
「現行システムからのデータ移行については、プロジェクト開始前の計画によると単体テスト開始後に準備着手ということになっていた。システムテストの後半では、実際に移行データの一部を使ったテストを行う必要があるからだ」
「従って、今後はチームを3つに分けて、単体テスト、システムテストの準備、データ移行の準備を実施していこうと考えている」
「正直いって楽ではないが、この時期に着手しておかないと後で取り返しのつかないことになる。万が一、データ移行の準備につまずいてシステムテストの実施に影響が出ると大変だからな」
「幸い、現行システムの調査については顧客から全面的な協力を得ている。まだまだ気は抜けないが、いまの要員で何とか大丈夫だろう」

　作業定義を行う際には、対象となるスコープのWBSすべてについて、漏れなく作業をリストアップする必要がある。その点、矢見雲マネージャは、プロジェクト開始前にデータ移行の作業を定義していなかったばかりでなく、いまの作業に気を取られて、着手すべき時期になっても着手できていない。いずれは、関連する作業（システムテスト）にも影響が出てしまうことは必至である。プロジェクトマネージャには、常に先を見越したうえで先手を打つ姿勢が求められるのである。

■スケジュールと実態が乖離し、有名無実化する

　2つのプロジェクトはそれぞれ終盤にさしかかってきた。開発フェイズにおけるメンバーの頑張りもあって、遅れはある程度ばん回できたもようだが、最終納期に向けて予断を許さない状況である。それぞれのマネージャの様子を見てみよう。

矢見雲マネージャの発言
　 「プロジェクトもいよいよ大詰めだ」
「途中、ある程度はばん回したものの、やはり2週間程度の遅れは致し方ない」
「プロジェクト内部の週次進ちょく会議ではまだ顧客には報告できていないが、状況は理解してくれているので説明すれば分かってくれるだろう」
「来週、プロジェクトオーナーである顧客の取締役を含めた報告会があるので、その場で正直に説明することにしよう」
「遅れの責任の大半はわが社にあるとはいえ、これだけの要求事項を満たしながら頑張ってきたのだから、期間超過分のコストについては請求せざるを得ないだろう」
「まあ、お金の話も含めて交渉だな」

出来杉マネージャの発言
　 「プロジェクトもいよいよ大詰めだ。」
「途中、ある程度はばん回したものの、やはり1週間程度の遅れは致し方ない」
「すでにプロジェクト内部の週次進ちょく会議では、毎週のように進ちょくを報告してきたのだから、状況は顧客もよく理解している」
「来週、プロジェクトオーナーである顧客の取締役を含めた報告会があるので、その場でどのように説明すべきかということについても、すでに顧客と調整したうえで資料を準備しているところだ」
「これもすでに顧客に報告していることではあるが、今回の遅れの要因は仕様変更要求が多かったことに尽きる。これについては仕様変更管理手続きで承認されたことであるから、期間超過分のコストについては請求しても問題ないだろう」
「ただし稼働日が遅れることによって期待していたコスト削減効果に若干の影響が出るな。これについては年度を通してみれば微々たるものだが、きちんと説明しておく必要があるだろう」

　矢見雲マネージャの場合は、プロジェクト内部の週次進ちょく会議を毎週実施しているにもかかわらず、遅れの実態を顧客と共有できていない。こうなってしまうと、スケジュールはあっても意味のないものになってしまう。本来スケジュールの進ちょく度を確認し、問題があれば対策を検討する場であるはずの週次進ちょく会議も、有名無実化してしまっているのである。これは、顧客に対してタイムリーな報告を怠っているというだけでなく、週次進ちょく会議の時間を無駄に費やしているという意味で、二重の問題がある。

　プロジェクトの遅れは確かに問題ではあるが、出来杉マネージャのようにすべてを把握し、関係者との調整を適切に行っていれば、必ずしもプロジェクトの成功が危ぶまれるというわけではない。要は適切に管理することが重要なのであって、プロジェクト開始当初の計画を盲目的に守りきることだけが重要なのではない。

　最後になるが、こうしたタイムマネジメントを実現するためには、プロジェクトメンバー全体に時間に対するコスト意識を浸透させるべきであることを付け加えておきたい。時間に対するコスト意識が緩んでくると、プロジェクトの全体パフォーマンスが落ちるのである。出社時間が遅くなる、会議に遅刻する、だらだらと必要以上に残業する、などの事象は時間に対するコスト意識が低下しているサインである。こうしたサインが表れると、生産性や品質が低下し、ひいてはスケジュールに影響が及ぶ。時間に対するコスト意識とチームとしてのパフォーマンスには、相関性がある。例えば、野球のメジャーリーグやF1などのプロスポーツの世界では、メンバーの遅刻に対して罰金を科しているチームがある。強豪チームであればあるほど、こうした形で規律が保たれている。罰金を科すことについて、その是非をここで議論することは控えるが、プロジェクトにおけるメンバーの時間に対する意識について、あらためて振り返ってみてはいかがだろうか。

■今回のまとめ

・タイムマネジメントとは、プロジェクト開始前の計画段階に必要な作業を洗い出してスケジュールを作成し、そのスケジュールの予定と実績を管理していくこと。
・タイムマネジメントの目的は最初から完ぺきなスケジュールを作成することではなく、「納期どおりにプロジェクトを完了させるために必要な作業をスケジュールどおりに終了させること」
・作業を標準化し、負荷を平準化し、作業効率を高めることによって、スケジュールの実績値を作り込む努力をすること。
・作業定義を行う際には、対象となるスコープのWBSすべてについて、漏れなく作業をリストアップする。常に先を見越して、早めにアクションを取る姿勢も忘れずに。
・実績が計画から乖離した際には、ステークホルダーにタイムリーに情報共有するとともに、是正措置を取る。
・メンバーに時間に対するコスト意識を持たせ、チームとしてのパフォーマンスを高める。