#055 プロマネのお仕事(本編5) - スケジュール・マネジメント(遅れの「兆候」を見つけよう)

こんにちは。中小企業診断士の多田と申します。

本編5回目は「スケジュール・マネジメント」。

今回から3回は、いわゆる「Q・C・D」の管理についての知識エリアになります。
D(Delivery - スケジュール)、C(Cost - コスト)、Q(Quality - 品質)、の順番で説明していこうと思います。

# 051: 資源マネジメント
# 052: コミュニケーション・マネジメント
# 053: ステークホルダー・マネジメント
# 054: リスク・マネジメント
# 055: スケジュール・マネジメント ← 今回
# 056: コスト・マネジメント
# 057: 品質マネジメント
# 058: 調達マネジメント
# 059: 統合マネジメント
# 060: スコープ・マネジメント

プロジェクトにおいて最もトラブルになりがちなのが「納期を守れない」事だと思います。
いかに早いタイミングで遅れの兆候を把握し、その兆候に対処できるかがプロマネの腕の見せ所です。

(ちなみに、今回でnoteを書き始めてから1年を超えました。毎週1回書かさず更新中。我ながらよく続いていると思います…)

「スケジュール・マネジメント」とは

PMBOKの10の知識エリアの中では上から3番目。

PMBOKでの定義は以下のとおりです。
「プロジェクトを所定の時期に完了するようにマネジメントする上で必要なプロセスからなる。」
(PMBOK 第6版 p.24)

シンプルですね。そりゃそうでしょ、という気分になります。

PMBOKに書かれているプロセス

この知識エリアに書かれているプロセス(やること)は全部で6つありますが、「段取り八分(※1)」という言葉にあるように、「計画プロセス群」に属するプロセスが6つのうち5つもあります。

1. 「スケジュール・マネジメントの計画」
→ 2以降のスケジュール・マネジメントをどのように行うのか計画し、文書化します。
→ アウトプット文書: スケジュール・マネジメント計画書

2. 「アクティビティの定義」
→ WBS(プロジェクト全体の業務を階層的に記述したもの)の最下層である「ワークパッケージ」を、「アクティビティ」と呼ばれる一つ一つの作業に分解します。
→ アウトプット文書: アクティビティ・リスト

3. 「アクティビティの順序設定」
→ 2で作成したアクティビティ・リストを元に、それぞれのアクティビティ(作業)をどういう順番で行うのが良いのかを決めていきます。
→ 例えば、Web制作において、blogの記事の内容が決まらないと、どういう写真が必要になるのかわからないので、そのblogで使う写真撮影には行けません。こうした、アクティビティ感の「依存関係」を明確にして、作業の順番を決めていきます。
→ アウトプット文書: プロジェクト・スケジュール・ネットワーク図

4. 「アクティビティ所要時間の見積り」
→ 各アクティビティ(作業)にどれくらいの時間がかかりそうかを見積もります。
→ アウトプット文書: 所要時間見積り、見積もりの根拠

5. 「スケジュールの作成」
→ 既に作成した「組織要員計画表」(#051 資源マネジメントも参照してください)を見ながら、できるだけ全員の作業負荷が同じになるようにスケジュールを作成していきます。
→ アウトプット文書: スケジュール・ベースライン

6. 「スケジュールのコントロール」
→ スケジュール・ベースラインと実績を比較して、差異があれば原因を追及し、改善を図っていきます。
→ 場合によっては実現可能なスケジュールに引き直し、ステークホルダーと会話して了解を得ます。

(※1) 段取り八分: 段取りをきっちりしておけば仕事の8割はおわったようなものである、という意味。

「スケジュールの作成」 → ベースラインをきちんとつくろう!

何はともあれ、スケジュールのベースラインを作りましょう。これが無いと始まりません。
にも関わらず、これができていないプロジェクトって意外と多いです。(体感8割)

作り方は上のプロセスに書かれている通りで、まず業務全体の WBS を作成した後に作業レベルまで分解し、個々の作業をカレンダーにあてはめてガントチャートを作っていきます。

…というと難しそうなのですが、数人規模のプロジェクトであれば、適切なツールを導入してそのツールのフォーマットに従ってデータを入力していけば、それなりに精度の高いベースラインが完成すると思います。
いろいろ検討する前に、まずはツールを導入してしまい、わからないなりに手を動かして使ってみるのが良いと思います。
(P/LとかB/Sとか余り詳しくなくても、財務ソフトに数値を入力していけばある程度の財務分析は自動的にやってくれるのと似ています。)

「スケジュールの作成」 → お勧めガントチャートツール5選

…ということで、
私がこれまでに使ったことのあるガントチャートツールをまとめておきたいと思います。
主に数人程度の小規模なプロジェクトで使用することを想定した際に、お勧めできる順番に並べてあります。

[1] Microsoft Project
Microsoft社製のアプリケーション。Webブラウザで動作するオンライン版もありますが、基本的には Windows にアプリをインストールして使用します。
プロジェクトマネジメントに必要なほとんどの機能が備わっており、これ1本あればスケジュール管理だけでなく、個人毎の業務量を把握してリソースを調整するなどの管理も可能です。
実質的に業界標準なので、迷ったらこれを導入すれば間違いないと思います。
一方、値段が若干お高めなので(1ライセンス3000円/月 or 買い切りライセンス10万円弱くらい)、以下で紹介するツールで問題ないようでしたら、まずはそちらからスタートするのも良いかもしれません。
製品紹介URL: https://products.office.com/ja-jp/project/project-management-software
価格など: https://products.office.com/ja-jp/project/compare-microsoft-project-management-software?tab=1

[2] Brabio!
Webブラウザで動作するスケジュール管理ツールです。日本の会社が運営していて、日本語対応も問題なし。
直感的でわかりやすいユーザーインタフェースになっており、特に小規模なプロジェクトや、プロジェクト管理が初めてという方にお勧めできます。
5人までならずっと無料で使えるところも良いです。
細かいところですが、有料プランの場合に請求書支払に対応しているところもありがたいです(海外のサービスだとカード払いしか対応していないところも多い)。
製品紹介URL: https://brabio.jp/
価格など: https://brabio.jp/upgrade.html

[3] Jooto
こちらも PR TIMES という日本の会社が運営しているサービス。Webブラウザから使用します。
4人まで無料、5人以上は1人500円/月、といった料金体系も Brabio! に似ています。
Brabio! と両方使ってみて、自分に合う方を選んでみるのも良いかと。
製品紹介URL: https://www.jooto.com/
価格など: https://www.jooto.com/pricing/

[4] asana
世界中の会社で使われているオンライン型のプロジェクト管理ツール。
無料プランもありますが、タイムライン(ガントチャート相当の機能)を使おうとすると、Premium プラン(ユーザー1人あたり1,200円/月)に加入しないといけないのが若干ハードル高いです。
UI が気に入るようでしたら候補に入れて良いと思います。
ちなみに、私は、無料プランのアカウントで、タスク管理の機能(ToDo リスト)だけを使っています。
製品紹介URL: https://asana.com/ja/
価格など: https://asana.com/ja/pricing

[5] Wrike
こちらも世界中で使われているツール。UI も洗練されていてかっこいいです。asana と両方使ってみて自分にあう方を選ぶのが良いと思います。
ガントチャート機能を使うためには Professional プラン($9.80/月)へのアップグレードが必要なのも asana と同じ。
製品紹介URL: https://www.wrike.com/ja/
価格など: https://www.wrike.com/ja/price/

以上、代表的な5つを紹介してみました。

プロジェクト管理ツールは日々新しいものがどんどん出てきているので、これらのツールの情報も日々アップデートしていく必要がありますが、私の場合、途中でいろいろなツールに浮気するものの、結局最終的には MS Project に戻ってくる、というのをここ10年くらい繰り返している感じです。

「スケジュールの作成」 → マイルストーンを決めて、その前にバッファを入れておこう!

さて、ツールを導入したら実際にスケジュールを入力して管理していくわけですが、重要なのは「守れる」スケジュールを立てることです。

お勧めしたいのは、あらかじめスケジュールにバッファ(予備日のことです)を入れておくことですが、このバッファの入れ方にコツがあります。

一般的には、一つ一つの各作業に対してバッファを入れておくことが多いと思います。
例えば、「会社紹介の社長インタビューページを作る」というアクティビティの場合、
・「社長にインタビューする」→1日で終わりそうだけど、念のため2日とっておこうか
・「インタビューを文字起こしする」→2日で終わりそうだけど、バッファとして1日足して3日でスケジューリングしよう
といった余裕の取り方です。

実は、こうしたやり方よりも良いやり方があります。

作業の一つ一つにはバッファを入れず、
・「社長のインタビューページを公開する」
といった大きな目標(マイルストーン、と言います)を設定し、その前にまとまったバッファを入れる、という方法です。
この例の場合、マイルストーンの直前に5日ほどのバッファをまとめて入れておくのが良さそうです。

人は、一つ一つの作業にバッファを儲けておくと、その場でそのバッファを使いきってしまうと言う特性があります。
個々の作業にはバッファをおかず、マイルストーンの前にバッファを置くようにするのがお勧めです。

この手法について詳しく知りたい方は、「クリティカルチェーン法」「TOC理論」といったキーワードで検索してみて頂けると良いと思います。

以下の本もおすすめです。

https://amzn.to/32tjJ10
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

「アクティビティ所要時間の見積り」→「五指投票」をやってみよう!

スケジュールを立てるにあたって、重要になってくるのがそれぞれの作業にどれくらいの時間がかかるかを見積もる作業なのですが、これがなかなか難しい。
過去の実績を参考にすることができれば良いのですが、それでもよくわからない場合は担当者や詳しい人に、「この作業どれくらい時間かかりそう?」と聞くことになります。
しかし、その場合、楽観的な人と慎重な人とでは自然と見積もりの期間が変わってきてしまいます。

「五指投票(Fist to Five: フィスト・トゥ・ファイブ )」は、こうした場合に役に立つテクニックです。
以下のような手順で作業時間の見積りを行います。

1. リーダーからお題を提示します。たとえば、「この作業は1週間で終わると思うか」というお題を出します。

2. リーダーの「せーの」のかけ声で、参加しているメンバー全員が、指0本(グー)から指5本(パー)のいずれかで、そのお題を支持するかどうかを表明します。
本数の意味は以下のとおり。(意味合いはチーム毎にカスタマイズしても良いでしょう。)
0本: 反対。
1本: 自分としては重大な不安があるが、皆が合意するなら進めても良い。
2本: 若干の懸念があるが、進めても良い。
3本: 支持する。
4本: 良いと思う。
5本: 素晴らしい。

3. 全員が3本以上の指を上げるまで話し合いをして最終的な意志決定を行います。

この方法の良いところは、発言機会の多い人や、最初に発言した人の意見に引っ張られることなく、全員の不安要素を出すことができる、という点です。
毎回やっていると大変かもしれませんが、メンバーの参加意識が低くなってきたときなどにやってみたりすると良いと思います。

「スケジュールのコントロール」 → 遅れの「兆候」を見つけよう!

スケジュールができて実際にプロジェクトを進めていくフェーズになったら、プロマネは、実際の作業の進捗を確認し、最初に作ったスケジュールとの差異をチェックしていかなければなりません。

その際、作業が遅れてしまった後で後追いで対応するのではなく、実際に遅れが発生する前に、潜在的な遅れの兆候に気がつけるかどうかが重要になってきます。

そのためには、あらかじめ、どういう原因で作業が遅れることが多いかのパターンを頭に入れておき、今後何が起きそうかを予測しながら現場をみていくことが重要です。
以下、経験的に、作業が遅れる主な原因を、重要な順に挙げてみます。

1) メンバーの能力が想定よりも不足していた
2) スタート時には抜けていた作業があった
3) 外注の仕事が遅れた
4) 仕様の追加・変更があった
5) 見積もり時間が間違っていた
6) 予期しない理由でメンバーが離脱した

特に、メンバーの能力不足に関しては、進捗確認の際に嘘をつかれてしまうと実際に作業が遅れるまで気がつけないことが多いです。客観的に、プロマネが自分の目で進捗を確認することが重要です。

「スケジュールのコントロール」 → スケジュールチキンにならないようにしよう!

最後に、実際に作業が遅れてしまった場合の対応についてです。

スケジュールチキンとは、何人かのチームでプロジェクトを行う場合、自分の作業が遅れていることをマネージャに伝えたくなくて、誰か他の人が遅れを報告するまで自分の遅れを隠してしまう状況のことを言います。
結果、みんなスケジュールが遅れているのに、ギリギリになるまでその事実に気がつくことができません。

プロジェクトを進めていく上で、作業が遅れてしまうことはよくあります。
その際に最も大事なのは、遅れをきちんと認識・共有し、代替案を探していくことです。
特にプロマネ自身がスケジュールチキンになってしまってステークホルダーへの報告を怠るようになってしまうと、プロジェクトはとても危険な状況に陥ります。

スケジュールが遅れたときの対処としては、
[1] 人員を追加投入する
[2] 作業の順番を組み替えてスケジュールの短縮を図る
[3] やること(スコープ)を小さくする
の3つがありますが、正直、[1]や[2]で計画通りにプロジェクトを終わらせることはなかなか難しいです。
場合によっては、人員を追加したことが逆効果になり、逆にもっとプロジェクトが遅延することもあります。
勇気を持って[3] を選択できるかどうかがプロジェクト成功の鍵だと思います。

スコープを小さくする、とは、具体的には
・製品やサービスのスペックを落とす
・発売する機種を減らす
・生産する台数を減らす
・段階的に市場投入する
などの調整をして、プロジェクトとして期日までにやることを減らしていくことです。

よくソフトウェア開発の現場でやりがちなのは「テストの工数を減らして間に合わせる」という対応ですが、経験的にこれは絶対にやってはいけません。
必要なテストの工数を省くと、不具合が市場に流出してしまい、あとで大きなしっぺ返しをくらうことになります。

私がよく使う言葉で、「開発メンバーは魔法使いではありません」というのがあります。
プロマネとして、できないことはできないときちんと伝えられる勇気が必要です。
また、普段からステークホルダーとの信頼関係が築けているかどうかもポイントになってくるだろうと思います。

まとめ。

(1) 「スケジュール・マネジメント」とは、プロジェクトが所定の時期に完成するようにマネジメントしていく活動のことです。遅れが発生してから後追いで対応を行うのではなく、あらかじめ遅れそうなポイントを予測して、遅れの兆候を発見するように心掛けることが大切です。

(2) スケジュールマネジメントにおいては、まずきちんとしたベースライン(計画表)を作成し、その計画との差異を日々確認していくことが重要です。計画の作成と進捗チェックには、MS Project のようなスケジュール管理ツールを導入するのが良いと思います。

(3) スケジュールに遅延が発生したら、それを隠したりせず、みんなで共有して対策を考えましょう。人員を追加して納期を守るという対応は、現実にはなかなか難しいものです。ステークホルダーと交渉し、スコープ(やること)を縮小して、段階的にサービスを開始するなどの対応も検討すべきだと思います。

----------
(ここに書かれている内容はいずれも筆者の経験に基づくものではありますが、特定の会社・組織・個人を指しているものではありません。)