仕事の基本ルール
計画っていうのは、作った瞬間からどういうわけか遅れ始めます。
不思議ですね。
でもまぁ、その理由を考えているより、どうやって遅れを挽回するかがプロジェクトリーダにとっては大事なことです。
本日はそれのやり方のパターンをまとめておきます。
長期のプロジェクトや始まって間もないプロジェクトであれば取れる方法はたくさんありますが、プロジェクトが終盤になってくるとやれないことが多くなります。そんな時でもパニックにならないように、どのような選択肢があり、それを今回のプロジェクトに適用すると、どんなことをやればいいのか、そのメリット・デメリットを考えるベースにしてください。
まず、大枠に分けると
１．期限を延ばす
２．投下する工数を増やす
３．必要工数を減らす
４．効率を上げる
の4パターンに分かれます。
■大事なのは複合技
この中で、効果が高いのは、この番号順です。つまり、上から順に検討していかないといけないですが(意外と、逆から考える人が多い)、1つの方策でだけで、対策が完了することはありません。
つまりは、納期は延ばしてもらうけど、100%ではなく、残業もするし、効率化も検討するというようなやり方をしないといけません。
私の場合、以下に上げる細かいパターンも含めて、まずマインドマップに書きだして、さらにそれぞれの項目について、具体案と費用対効果を考えます。
その結果、もっとも費用対効果の高い組み合わせ(お互いにAをやればBは出来ないなどの制約があるので)を担当者に指示することになります。
■１．期限を延ばす
とりあえず手っ取り早いのがこの方法。
これは更にいくつかのパターンが存在します。
●すべての納期を延ばす
まぁ要は、「すみませんが出来ないので、××まで待ってください」ということ。
このためには、「じゃぁいつだったらできるのか」の回答に対する答えが必要です。
●分納にする
プロジェクトの結果を納品する相手に迷惑がかからないように、一部だけは計画通りに提供して、その時点では必要ないような機能や部品の個数などをあとで納品するようにすること。
特にソフトウエアプロジェクトだと、通常の機能は問題ないが、異常処理(イレギュラーな処理)は未実装、みたいな状態で納品することがあります。また部品であれば1万個治める予定を、1,000個だけにしてもらい、残りは１週間後とかに分けてしまいます。
いずれにしても、リリース物を作る作業が2度手間になることはさけられないので、余計な業務は発生しますが。
当然、プロジェクトにはその結果を受けて活動する人がいるので、最終意思決定者と後工程の人に対して、ケア/合意が必要になります。
■２．投下する工数を増やす
こちらが一般によく取られる手ですがこちらも2通り。
●残業する
ま、よくやるやつですね。(^^;
●人員を増やす
あまりやれないですが、本当はこちらの方がいいです。特にプロジェクトの最初のほうなら、ぜひこれを検討するべきでしょう。
ただし、増やしてもらう人員は、現在の担当者に対して同等かそれ以上が望ましいです。
ただでさえあとからプロジェクトに参加すると、そのプロジェクト内部での合意事項や事前教育のために時間が取られます。つまり、余計な初期工数が発生するので、それをあとでカバーできるだけの力量を持った人でないと、崩壊する危険があるためです。
もしプロジェクトが終盤にかかってくると、この作戦はとれません。後20人日というところで、新しいメンバーをいれたら、その教育に10人日、教育のために現在メンバーの工数が10人日と合わせて40人日必要になって、助かるどころか、足を引っ張られかねません。
如何に早期の段階で遅延回復措置が取れるかは、プロジェクトマネージャーの腕の見せ所ですね。
■３．必要工数を減らす
これは要するに、「目標を下げる」ということです。
例えば、ソフト開発プロジェクトで、
・「詳細部分のドキュメントはつくらない」と決めて、ドキュメント化とそのレビューに関わる工数を減らす
・バグ曲線の収束率を99.8%から99%に下げる
・効果の低そうな機能を取りやめる(例えば、派手なスプラッシュはやめるとか)
など。
これも成果物に影響するので、最終意思決定者と後工程の人に対して、合意が必要になります。
■４．効率を上げる
ようするに、10人日かかる予定のものを、5人日で仕上げる方法を考えるなど、WBSにおけるひとつづつのタスクごとにそれを短縮して全体の時間短縮を図る方法です。
●能力の高い人に任せる
極端な話、ド新人にまかせていた業務を、ベテランに振り替えるだけでプロジェクトは大きく進むようになります。
もちろん、その時のド新人のモチベーション低下や、ベテランの負荷増大にはなりますが、背に腹は代えられない。
●手待ちち時間を減らす
プロジェクトのWBSを作っているのであればわかると思いますが、ガントチャートに書かれた依存関係は実は今では関係なくなているかもしれません。こういったものを洗い出します。
たとえば、タスクA,B,C,Dがあって、この順番にやらないと思ってたけど、実はA,BとC,Dの依存関係はあまり高くなとすれば、
A,BとC,Dは実は並行して作業できるかもしれません。
あるいは、建前としては「要件定義」が完了するまでは「機能設計」に入れませんが、すでに確定している部分については機能設計に入ってもいいはずです。もちろん、あとで影響する要件が変更になるかもしれず、ある程度のリスクは織り込まないといけなくなりますが。要は見切り発車できそうなところを探すこと。
すべてを見直す必要はありません。着目しなければいけないのは、クリティカルパス上にあるタスクか、プロジェクトの律速になっているタスクパスを見なおせばいいです。
ま、世の中で言われている「コンカレント・エンジニアリング」というかっこいい言葉で締めておきましょう(^^;
●作業プロセスを改善する
プロジェクトの内部活動としてやっているような事柄を省略するという方法です。
たとえば、全員集まってのレビューはやめて、メールでレビューをしてもらうというようなやり方で効率化できます。
あるいは、全員参加の進捗ミーティングを、グループのリーダだけにしてみるとか。
作業を取り決めているルールをちょっと変えてしまうわけです。これは社内基準があったりしますので、あくまでも暫定措置としての位置づけでないと、それ以降なし崩しになる危険があります。もちろん、成果物品質に影響しないようなら、その後は標準として使ってもいいとは思います。
■最後の手段
これは本当に最後の手段で、1週間以上かかるようなものには使えないですが、以前の記事
プロジェクトを最短で終わらせる方法
があります。なるべくならそうなる前に、手を打ちましょう。
