プロジェクトを管理するって要はどういうこと？
プロジェクト管理という仕事はとても大事です。
その名の通り、プロジェクトの成否はここにかかっています。
しかし、このプロジェクト管理はとても難易度が高く、
たくさんのプロジェクトリーダー（以下、PL）がこの難問に取り組み、
そして、良い答えが出せず、
と頭を抱える日々を過ごしています。
その苦しみの果てが、世に溢れている炎上プロジェクト達です。
そもそもプロジェクト管理という言葉自体は
様々なタスクを包含している言葉ですので、
いざ、「このプロジェクトのPLは君だ。よろしく」といわれたときに
初心者PLは何をどうすればいいのか困ってしまうと思います。
実際、PLがやらなくてはいけない仕事は多く、多岐にわたる上、先輩PLにアドバイスを求めても、経験則な回答や場当たり的な助言しかもらえず
なんとなくはこなすものの、プロジェクトが無事にゴールできたとしても
本当に自分がうまくやれたのかどうか、いまいち実感がわかない。
失敗しても何が間違っていたのかよくわからないまま・・・
そんな状態になってしまいがちですが、
PLの仕事の本質を突き詰めると、その役割は２つのタスクに集約されると思います。
それは
・タスクを洗い出すこと
・妥当なWBSを引くこと
この２つです。
簡単に言うとスケジュールです。洗い出したタスクをだれがどのタイミングで、どういう順番でこなしていくかという予定表になります。
これを聞くと
「ふーん。それのどこら辺が大変なんだろう？」
「それだけ？」
「それができれば苦労しない」
と、感じ方は現状置かれた立場によって様々だと思います。
ただ、いずれにせよ、私が見てきた数々の炎上プロジェクトの大半は
・タスクの洗い出し方が雑すぎる
・スケジュール（WBS）を引いた時点で既に無理筋
というプロジェクトが占めています。
実際、システムエンジニアをやっていると
「こんな無茶なスケジュールで、できるわけがない！」
とか
「このフェーズで今更そんなこと言うの？そんなのわかってたことじゃないの？
そんなのねじ込んだら後続の作業全部破綻するよ？」
とか、誰もが一度は経験したことがあるのではないかと思います。
WBSとは洗い出されたタスクをもとにスケジュールを引くので
そもそもタスクの洗い出し作業が荒かった場合、
作業が進むにつれ
「あ、この作業をやらないといけなかった。」
「あ、このテスト工程忘れてた。」
といった、割り込みのタスクが都度発生して、
スケジュールの見直しが頻繁に行われてしまいます。
そうなると、元々別の作業をする予定で参入していた作業員が
予定していた作業に着手できず、
別の作業をする羽目になったり、「待ち」状態になって予算を食いつぶしてしまうというような状況が発生します。
それだけではなく、スケジュールが見直される度に、新しいスケジュールを周知しなくてはいけない為、末端のメンバーは「あれ？明日からこの作業じゃなかったっけ？もう準備してたんだけど。」などのように周知がうまくいかず、段取り間違いなどの混乱を招き、チームリーダー達の管理工数も増大させます。
そして、何より恐ろしいのは、
タスクが漏れていたから割り込ませたとしても、プロジェクトの納期はズレない
という事です。
つまり、割り込ませたタスクの後続のタスクはすべて当初の予定よりも短納期になります。
これが積み重なると、最終的にWBSが到底実現できないものに変わり果ててしまい、
「絶対終わらない」とみんなが思いながら、前に進むしかない
いわゆる「デスマーチ」が始まるわけです。
もちろん、プロジェクト開始前から、すべてのタスクをきれいに洗い出すというのは
容易ではないため、どんなプロジェクトでもWBSの微調整は発生します。
しかし、腕のいいPLほど、肝となるタスクは見逃さないし、何か発生したとしても、吸収できるポイントだったり、タイミングを心得ているので、微調整程度で終わらせることができます。
全チームに周知しなくてはいけないほどの、リスケジュールが発生するような場合はプロジェクト管理の精度を疑うべき事態といっていいと思います。
そして、無事にタスクを洗い出せたとして、次の問題はWBSです。
このWBSを引くという作業もまた難解な作業です。
一番最初にWBSを引くときはまずは、ざっくり引く必要がありますので
「このぐらいのボリュームのプロジェクトだったら開発期間はこのぐらい見積もっていれば大丈夫だろう。」
「順調にいったとしても、このあたりで手直しを入れるシーンが出てくるから、このぐらいバッファをとっておこう」
など、経験に基づいたさじ加減でそれぞれのタスクに割り当てる時間を検討しなくてはいけません。
これはプロジェクト参加メンバーの力量であったり、規模感であったり、納期までの時間であったりと色々踏まえたうえで検討しなくてはいけません。
そして、粒度を細かくする際には、実作業をするメンバーやリーダーに詳細なヒアリングをして具体的な日付を入れますが、これも相手が
かなりバッファ（余裕）をもって提示してきているのか
1次請けの圧力に負けて、かなり無理な提示をしてきているのか
信頼性のある提示をしてきているのか
を見分けなくては妥当な線は引けません。
実施者のいわれるがまま線を引いていては、ほぼ間違いなくうまく行かないので、かならずPLは適切なフィルタをかけて判断しなくてはいけません。
状況によっては、敢えてタスクを削り取るという調整が入ることもあります。
これらの事を適切にできないと、どう考えても無理なスケジュールを引いてしまいます。
例えば、何かのテスト工程の線を引く際に
２か月の期間を取ったとします。
しかし、その準備期間に１週間しかとっていませんでした。
そのテストを実施する際には、別の環境を用意しないといけない上に
別環境からデータも移行しないといけない為、準備作業は一週間では全然収まらず
テスト開始が遅れてしまいました。なんとかかんとか、テストを少しの遅れ程度でリカバリーすることができましたが、よく見るとテスト結果の報告も一週間しか時間をとっておらず、テスト報告書をまとめ上げても、報告者自身を捕まえることができず、
次の工程に移ることができず、プロジェクトメンバーが何もできなくなる時間が発生してしまった。
などという事が起きてしまいます。
このように
タスクを洗い出す
WBSを適切に引く
というただ２点がプロジェクト全体に及ぼす影響はとてつもなく大きく
これを精緻にやれないことにはプロジェクトはどうやっても無事にゴールできません。
そして、プロジェクトにおいてこういった全体の青写真を描くことができる立場の人間はPLしかいない為、PLには必須の能力になります。
自身がPLになりたての人
もしくはプロジェクト管理がうまくいかない人は
まずはこの２点に立ち返り、作業を見直すと道筋が見えてくると思います。
ただ、ここまで書いたように、
この２つのタスクがPLの仕事の本丸である為
難易度はなかなかの高さです。
しかし、目指すゴールや道標がない中、「とりあえず頑張る」よりも
困難であっても、それが見えている方が努力のしようはあると思います。
コメント
コメントを投稿