EXCELで進捗を管理するのは良くないなーと思う
Windows PCならMicrosoft Officeはほぼ入っているし、レンタルPCでもOffice付を選んでもたかが知れているのでプロジェクトで使用するPCにははいっているよね、って感じになったのは、Office97が出たくらいのころにLotusやjust systemと勝負がついたから、でしょうか。もうすっかり昔のことで記憶が曖昧ですね。
ねぇ、ねぇ、進捗管理はEXCELでしかやる方法を知らないんでしょ？
どうしてプロジェクトの進捗管理でEXCELを使うんでしょうね。どういう思考の流れて、進捗管理にexcelを使おうと考えに至るのかなーって思ったけど、こんな感じで選んでいるんじゃないかな？
“目の前の手を付けないといけない作業があるし”
“WBSの一覧を作らないと”
“みんなのPCにEXCELが入っているし”
“以前経験したプロジェクトではEXCELを“使っていたから”EXCELでやろうかな”
EXCELが良い悪いじゃなくて。本当にこんな風にEXCELを選んでいるなら、進捗管理をしたい人が進捗管理で何を管理しようとしているのか自分と向き合って考えていないですよね？なんて思われても仕方がないかな、と思うんですが。
一方、「いや、EXCEL以外と言えばMicrosoft Projectだけど高いから全員に導入できないでしょ？」という面もある。これはこれで事実。MS Projectは機能が豊富すぎて使いきれなくてせっかく入れたデータを他の人が不用意に更新してぐちゃぐちゃになってしまった、と言う経験もあるし。
費用でツールを選ぶのは合理的な判断基準だけど、でもほんとにEXCELでいいのかな。何も考えずに全面的にEXCELでいいのかな。ワタシは、あなたがプロジェクトマネージャなら積極的に選んではいけない、と思うんだ。
EXCELでWBSを作ると進捗管理が出来ているつもりになっているでしょ？
そうなんですよね。EXCELにしろ、wordにしろ、powerpointにしろ、Officeツールでドキュメントを作ると清書しているようなものですから見た目が綺麗に仕上がりますよね。だから、進捗管理ではある観点で管理したい、注視したい、と思っても抜け漏れがあっても気づかないでスルーしちゃうことが多いんですよ。それに、それ自体は効率化の観点で良いことなのですが、過去プロジェクトの様式を流用するときなんでその様式になっているか何も考えずに使っちゃうことがある。これからやるプロジェクトの特性を考える必要があるのかないのか、そうしたことを経ないで使っちゃう。実際、ある程度は無意識に使えちゃうから何も疑問も持たない。
良くある考えていない進捗管理のEXCEL
例として↓を作ったんだけれどさすがにないかな、このレベルは。と思うでしょ？作ってもこのレベルしか進捗管理一覧を作れない人多いんですよ。
| NO | 大項目 | 中項目 | 小項目 | 開始日 | 終了日 | カレンダ 1日目 | カレンダ 2日目 | カレンダ N日目 |
| 1 | システム要件定義 | 機能要件 | 機能その1 | yyyymmdd | yyyymmdd | ■ | − | … |
| 1.1 | システム要件定義 | 機能要件 | 機能その2 | yyyymmdd | yyyymmdd | − | □ | … |
これの何がいけないか。
- 担当者がわからない。
- 終了条件がわからない。
- 開始日、終了日が予定どおり終わらないと実績で上書きされてしまい予実の差異がわからない。
- 作業が日単位でしかわからない。
じゃあ、と言うことで、そのわからないことを足してみますか。
| NO | 大項目 | 中項目 | 小項目 | 担当 | 予定開始日 | 予定終了日 | 予定実績開始日 | 実績終了日 | カレンダ 1日目 | カレンダ 2日目 | カレンダ N日目 |
| 1 | システム要件定義 | 機能要件 | 機能その1 | Aさん | yyyymmdd | yyyymmdd | yyyymmdd | yyyymmdd | ■ | − | … |
| 1.1 | システム要件定義 | 機能要件 | 機能その2 | Bさん | yyyymmdd | yyyymmdd | yyyymmdd | yyyymmdd | − | □ | … |
あぁ、完了条件が抜けちゃった。
| NO | 大項目 | 中項目 | 小項目 | 担当 | 完了条件 | 開始日 | 予定予定終了日 | 予定実績開始日 | 実績終了日 | カレンダ 1日目 | カレンダ 2日目 | カレンダ N日目 |
| 1 | システム要件定義 | 機能要件 | 機能その1 | Aさん | 顧客レビュー | yyyymmdd | yyyymmdd | yyyymmdd | yyyymmdd | ■ | − | … |
| 1.1 | システム要件定義 | 機能要件 | 機能その2 | Bさん | 顧客レビュー | yyyymmdd | yyyymmdd | yyyymmdd | yyyymmdd | − | □ | … |
実績開始日、実績終了日までは表現できましたけど、作業が日単位でしか表現できないですよね。工夫しても記号の■や□を増やして表現するくらいでしょう。でも、その記号を増やせば増やすほど覚えられないので凡例か何かで記号を目視してから脳内変換して理解しないといけない。そんなことやってられませんよね。
あと、WBS単位での進捗管理なら、↑の一覧の“カレンダ 1日目”以降はいらないんですよね。ついつい無意識に日単位のカレンダを足したくなるもんです。なんでかな。日付だけでは感覚的につかめなくて日単位に線を引いて表現するガントチャートを入れたくなってしまうんですよね。でも、そのガントチャートも日単位であるがゆえに、締め切り時間がある場合には表現は限界があるんですよね。
プロジェクトマネージャが進捗管理で知りたいこと
なんでプロジェクトマネージャは進捗管理の一覧を必要とするでしょうか。そもそも的な話ですが。
- 計画を立てたいから？
- 予定通りに進めて欲しいから？
- 予定どおりに実績があることを知りたいから？
- 顧客に報告したいから？
全部違いますよね？プロジェクトマネージャの観点は。
ここまでは単なるWBSの作成と日程を割り付けてスケジュール化しただけの話です。なぜ、そうすることが必要なのか。それは、どのWBSの連続が一番プロジェクトにとって注視しないといけないのか、それを知るためです。どの作業のつながりが遅れるとプロジェクト全体に影響してしまうのか。どのWBS群がどのタイミングでマージされるのか。そうしたWBS上の体幹となる脈を見つけるためです。そしてそれの実績が滞らないように活動するためです。
もう一つ。WBSは最終的には契約書で定義したアウトプットに収斂していきます。だって、そのアウトプットを作るために作業しているんですから。そのアウトプットを作るために、WBSが一旦分離したり、いくつかのWBSがまとまるときがある。そのまとまるところではリソースがひっ迫する場合があるんですね。そうすると、枝分かれしているWBSの作業時期を調整してリソースの平準化ができるかどうかを考えたくなるんですよね。そうしたこともプロジェクトマネージャがWBS上で知りたいことの一つなんです。
それをEXCEL上で実現しようとするとプロジェクトマネージャやプロジェクトのPMOがお絵かき職人になってしまう。それもリソースの使い方を間違っていると思うんです。とはいえ、Microsoft Projectは使いにくいし、必要な人に配るにはコストが見合わなかったりするんです。
じゃあどうすればいい？
今のところ、スケジュールの一番大きなレベルでのマスタープランはEXCELだろうがpower pointだろうが何でもいいかな、と。それは顧客とのプロジェクトを時間軸で共有するために必要なドキュメントだから。できれば、進捗のツールで出力したものが使えればいいんだけど、共有したいレベル感や追加しておきたい情報が違うんだよなぁ。
ただ、WBSに展開して進捗を日々見るのはチケットがいいかと。詰まる所、これと言う解決策はないけれど、適材適所でツールを選ぶしかない、と。マスタープランや直近の工程は顧客と時期感を共有したり、メンバとマイルストーンを共有したりするために必要なのでそこはお絵かきするしかないかな。
