LIGのメルマガ、はじめました!
LIGのメルマガ、はじめました!

PM・ディレクターが絶対に押さえておきたいタイムマネジメントのたった2つのコツ

しもん

こんにちは! BiTT事業部でブリッジディレクターをしている、しもんです。

「BiTT事業部って何をしているの?」と、疑問に思う方は下記の記事を見ていただけると幸いです。

ここ最近、各ディレクターが集まり、業務の知見を高めるために、グループに分かれて業務で欠かせないテーマに沿って資料を作成したり、議論をしています。

私のグループでは「プロジェクト管理」がテーマなのでPMBOKを利用して抜粋し、業務に落とし込む作業をしています。そこで今回は自分の学びへの落とし込みの意図も込めて、記事にしてみようと思います。

PMBOKとは
簡潔にまとめると国際的に標準とされているプロジェクトマネジメントの知識体系です。PMBOKについて詳しく知りたい方はこちら。

今回はプロジェクト管理項目の1つである、タイムマネジメントについて紹介します。

タイムマネジメントとは

スケジュール作成・管理のエリアとなります。例えば、以下のような項目が挙げられます!

  • リスケジュールが必要な際の調整
  • スケジュール通り進行しているかの確認
  • 生産性の向上を目的とした工程全体のスケジュールの管理

ここから、タイムマネジメントの考え方をベースに、プロジェクトにおける効果的なスケジュールの作成法を書いていこうと思います!

タイムマネジメントその1:精度の高いスケジュールを作成する

当たり前のことですが、精度の高いスケジュールはプロジェクト全体の質を高めます。Webプロジェクトにおけるより効果的なスケジュールのテクニックを紹介します!

アクティビティの依存関係

スケジュール作成のときに最初に考えないといけないことが、それぞれの作業内容(アクティビティ)です。どのアクティビティにどのくらいの時間が必要となるのかを考えることで、全体のスケジュールが決まってきます。

例えば、家を建てようと思ったときに骨組みがないと壁を作ることができません。このように、あるアクティビティが完了したら次のアクティビティに着手可能となります。

この関係が見出しの通り、「アクティビティの依存関係」です。

この「アクティビティの依存関係」には以下の3つの種類があります。

依存関係 関係
強制依存(ハード・ロジック) 順序を絶対に入れ替えられない依存関係。
任意依存(ソフト・ロジック) 過去のプロジェクトから得た経験や知識を基にしてプロジェクトチームが任意に設定する依存関係。
外部依存 プロジェクト内のアクティビティではない要因との依存関係。

このような依存関係を見落としたままスケジュールを立ててしまうと、後々大きな問題になる可能性があります。

マイルストーンの設定

「マイルストーン」は聞いたことがあるのではないでしょうか? マイルストーンとはそのプロジェクトにおいて、重要な意味があるイベントや時点のことです。

プロジェクトは毎日進行しています。そのなかで進行状況をプロジェクトメンバー全員が常に把握することはとても難しいです。そこでマイルストーンという、スケジュールの節目を設定してあげることで、メンバー全員が把握しやすくなるわけです。

マイルストーンの設定には以下のようなメリットがあります。

  • メリット①:プロジェクト途中段階での検収

プロジェクトの最後に検収をし、万が一最初からやり直しが発生するケースに比べて、リスクを分散させることができます。

  • メリット②:クライアントとの遅延の意識の共有

クライアント側が行う作業のスケジュールは管理しにくいですが、マイルストーンを共有しておくと、スケジュールの遅延として明らかになり、自発的な協力を導き出すことができます。

  • メリット③:大まかなスケジュールの把握

全体の流れを把握するために、マイルストーンだけの簡易なスケジュールを作成する方法もあります。

クリティカルパスを押さえる

スケジュール作成をするうえで重要なことが、「クリティカルパス」を認識しておくことです。「クリティカルパス」とは、納期に直結する一連の作業のつながりのことです。

下の図では、アクティビティA, C, E, Fがそれぞれ先のアクティビティが完了したら、次のアクティビティへ着手できる関係にあります。CとDが強制依存、BとDも強制依存の関係で、◆はマイルストーンとします。

この場合、クリティカルパスは太線のようなルートで示されます。A, C, E, Fのいずれかで作業に遅延が起きると、プロジェクト全体のスケジュールに影響が出ます。

このように、時間的に余裕がない最長の作業の連なりがクリティカルパスで、この連なりの作業を遅らせなければ、全体スケジュールの遅延は発生しないということです。

タイムマネジメントその2:スケジュール短縮を図る

スケジュールの遅延は契約に関わる重大な問題点です。しかし、現実的にはスケジュールの遅延はよく起きてしまうものです。

ここからは遅延を防ぐポイントと遅延が発生した場合の対応の仕方を紹介します!

スケジュール管理の3つのポイント

スケジュールにはさまざまな要素が組み込まれています。例えばスコープやコスト、品質です。これらにすこしでも変更があればスケジュールに影響が出てしまいます。

そのため、PMやディレクターは常にスケジュールの進捗に気を配り、遅れを吸収・手直しするため下記のような手立てを行っていくことが必要になります。

  1. 進捗を把握する
  2. スケジュールの遅れに対処する
  3. 遅延の理由を明らかにしておく

それぞれ順番に説明していきます。

進捗を把握するポイント

スケジュールの進捗を把握する際に重視すべきなのが、「クリティカルパス」と「マイルストーン」です。

クリティカルパス上にあるタスクの遅延は、そのまま納品の遅れにつながるため致命的な遅延を防ぐためにも、ほかのタスク以上に細かく進捗を把握する必要があります。それに対して、クリティカルパス上にないタスクの場合は、バッファが存在しているため多少の遅れであれば、気にしすぎる必要はないかと思います。

しかし、小さな遅れが積み重なると、もともとクリティカルパス上になかったタスクがクリティカルパスに乗ってしまう場合があるので要注意です。

また先ほども記載していますが、マイルストーン単位でプロジェクトに節目をつけ、プロジェクトメンバー全員とクライアントの双方でスケジュールを把握することも効果的です。スケジュールの遅延は、クライアントにはなかなか言いにくいと思いますが、遅れが発生したことは報告しなければいけません。

手の打ちようがなくなってから報告するのではなくその都度しっかり共有して前向きな対応策を考え、提案すればクライアントとの関係も良好に保つことができると思います。

スケジュールの遅れの対応

スケジュール遅延したときの手段として、「クラッシング」「ファスト・トラッキング」「資源平準化」の3つを紹介します!

  • クラッシング

クリティカルパス上のタスクに必要となるリソースを追加し、作業の期間短縮を図る方法です。ウェブ・プロジェクトでは、それまで1人で対応していたタスクに対して2人に増やす、2人だったデザイナーを3人に増やすといった措置がこの手法に当たります。※仮に人数を2倍にしても、パフォーマンスが機械的に2倍になるわけではありません。

クラッシングは、クリティカルパス上にあるタスクに対して行使されなければ、プロジェクト全体のスケジュール短縮には結びつきません。また、この方法はコストの増加につながるため、ミニマムにとどめながらスケジュール短縮を最大化することを考えることが必要だと思います。

  • ファスト・トラッキング

元々順列に並んでいた2つのタスクを同時並行で進めて期間短縮を図る方法です。例えば、デザイン開発とコーディングは通常順列の関係にありますが、この2つの作業を同時並行で進めてしまうのがファスト・トラッキングです。

この場合、あとからデザイン修正が発生するとコーディングをやり直さなければならないといったリスクが高まりますが、そのリスクを把握している上でスケジュール短縮を優先させます。ただしファスト・トラッキングは、作業のやり直しやクライアントとの関係悪化などのリスクにも繋がり兼ねないので安易に行うのはやめたほうが良さそうです。

  • 資源平準化


メンバーのスキルや経験、作業に当てられる時間などを考慮して、タスクの割り当てを最適化する方法です。簡単に言うと作業の遅れをメンバーのスキルで調整するということです。

例えば、メイン機能と軽微な機能の両方を経験の浅いエンジニアが一手に担当しているケースで、経験の豊富なエンジニアに加わってもらい、メイン機能を任せる、 といった方法が資源平準化になります。

遅延の理由を明らかにしておく

遅延にともなうスケジュール更新の際は、遅延の理由と更新履歴をあわせて明記するようにします。重要なのはスケジュールが遅延しているという事実とその理由をプロジェクトのメンバー全員が共有し、プロジェクトの目的達成への影響をミニマムにとどめることです。

まとめ

スケジュールの遅延が起きないとは100パーセント言い切れないのが事実です。その一方でPMやディレクター陣がクライアントとうまくコミュニケーションを取りつつ、抜かりない進行管理をすることが、当たり前ではあるものの、遅延が起こさないためにとても大切なことだと改めて考えました。

上記で記載したテクニックや用語は知らないこともありましたが、プロジェクトを進行していくうえでは知っておいて損はないなと思いました。

M o n g o