プロジェクトのスケジュール作成で重要なこと

   

プロジェクトのスケジュール作成で重要なこと

どうも。オタカタカオです。

 

システム開発のプロジェクトではスタートする前から納期が決まってることがあります。

 

そんなプロジェクトでは非現実的なスケジュールになってたりします。

 

本当は3ヵ月の期間が必要なのに1ヵ月で納品しなければいけなかったりとか・・・。

 

ムリにも程があるんですけど実際にあるんです。

当たりまえのように納期遅延になりますけどね。

 

今日はスケジュールを立てるときにゼッタイに考えなければいけない重要なことについて書きたいと思います。

 

スポンサーリンク

 

納期ありきのスケジュールを作っても無意味

プロジェクトがスタートする前から納期が決められてることが大きな間違いなんですが、

実際にはそういうプロジェクトは少なくありません。

 

そういうプロジェクトのスケジュールはこんな感じになってたりします。

(納期が3日の場合)

project-schedule_1

 

納期に合わせて線を引いただけのスケジュールですね。

 

突っ込みどころ満載になってます。

・各作業の担当者は誰?

・作業2以降の開始時期がスケジュールの途中なのは何故?

・線が重なってるのは何故?

 

など、挙げればキリがありません。

 

そもそも、納期が決まってる理由

これはいろんな理由がありますが、例えばこんなのがあります。

 

日程(納期)が発表されている

例えば、「〇月〇日リリース!」とかプレスリリースで日程(納期)を発表したり、

社内の偉い方々(役員とか)に報告したりとかですね。

 

納期交渉の難易度:高

 

なんで発表しちゃうんだよ!先走るなよ!って感じです。

予算を消化したい

予算を消化しないと次年度の予算が削られちゃうとか言う理由ですね。

 

納期交渉の難易度:中

 

知らんし。

予算削られる事業ならヤメてしまえ!

 

早くリリースしたいから

これはもうただのワガママです。

 

納期交渉の難易度:低(っていうか交渉すら不要)

 

・・・・・・。(言葉を失うわ!)

 

納期交渉の難易度が高いものから挙げてみましたけど、交渉するときに言われるのが、

 

納期に間に合わせる方法を考えてくれ

 

っていうムチャぶりです。

 

そんな方法があるなら最初から交渉なんかしないわっ!

 

スケジュールを立てるときに重要なこと

納期交渉をするときにはスケジュールを用意しておくことが必須なんですが、

冒頭のような大雑把なスケジュールでは説得はできません。

 

間違いなく顧客や上司に返り討ちにされますね。

 

スケジュールを立てるときに最も重要なのはクリティカルパスを明確にすることです。

 

クリティカルパスとは・・・

プロジェクトで必要な作業を前後関係で繋いで所要時間が最も長い経路のこと。

 

こんな感じですね。

project-schedule_2

 

作業が関係してるものを矢印で繋いでますが、これが経路(パス)です。

 

「作業1」が終わらないと「作業2」が始められません。

「作業3」が終わらないと「作業4」も「作業5」も始められないってことですね。

 

そして、各作業枠に日数を書いてますが、これはその作業にかかる期間(所要時間)です。

「作業1」の場合、作業終了までに3日かかるということです。

 

この図では3つの作業経路がありますが、赤矢印がクリティカルパスということですね。

 

1つ目の作業経路:作業1(2日)+作業2(1日)+作業6(1日)=4日

2つ目の作業経路:作業3(1日)+作業4(2日)+作業6(1日)=4日

3つ目の作業経路:作業3(1日)+作業5(3日)+作業6(1日)=5日

 

つまり、作業6までを全て完了するためには最短でも5日は必要ということです。

 

これを「3日で終わらせてくれ」とか言われても無理なんです。

日程が発表されてようが、予算を消化したかろうが、早くリリースしたかろうが、関係ありません。

 

スタンド「ザ・ワールド」で時間を止めない限り無理なんです。

 

納期の交渉ができない場合の対処

とは言っても、クリティカルパスを明確にしても納期の交渉ができないこともあります。

 

どんな時か・・・

 

本当は5日かかる作業なのに「3日もあれば終わると思いますよ」と言ってしまった場合です。

 

「~思います」という確証の無さそうな言い方をしてるとか関係ないんです。

 

顧客や上司には「3日で終わる」とインプットされてるので、

納期交渉したとしても「3日で終わるって言ったじゃん!」と言われるのがオチです。

 

これに対して「3日で終わるなんて言ってません。終わると思いますって言ったんです」なんてこと

言おうものなら、「同じことだろ!」と怒られるだけですね。

 

さらに「同じじゃありません」とか抵抗したところで、

「だったら3日で終わると思いますなんて適当なこと言うな!」と激怒されて終了ですね。

 

・・・無駄な抵抗ですので、期間短縮の道を探してみましょう。

 

そして、軽はずみな発言は控えましょう。

 

作業単位を細かくする

先ほどのイメージ図で「作業1」「作業2」・・・としてましたが、

この作業がもっと細かくできないかを考えてみます。

 

例えば、「作業5」は3日かかる予定ですが、1つの作業で3日・・・

つまり24時間(3日×8時間で計算)の作業をぶっ続けで行うとは考えにくいですね。

 

仮に3日というのが、ぶっ続けで行う作業だとしたら、3日×24時間=72時間の作業ということなので、

これを3日でやろうとするスケジュールならば既に計画が破たんしてます。

(コンピュータの自動処理にかかる時間なら話は別ですけど)

 

基本的に作業単位は1日以内・・・2時間~半日程度で完了する粒度まで細かくした方が組み換えられる可能性があるかもしれません。

 

理想で言えば、30分~1時間程度で完了できる粒度まで細かくできれば、

作業自体が単純化されるので、作業を割り振られた担当者の負荷も低くなりますね。

 

要員を追加でアサインする

誰かを任命したり、指名することをアサインと言います。

 

追加アサインができれば並行作業ができるので作業期間の短縮を図ることができますね。

 

ただ、追加でアサインされた人は当然ながら情報が不足しているため、

作業単位を細かくしてからアサインすることが前提です。

 

追加アサインした人に対しては情報共有して認識を統一するための期間が必要になりますが、

認識を統一したとしても、作業を細かくして単純化していないと、

作業に取り掛かれなかったり、作業の途中でわからなくて止まってしまったりというケースが多々あります。

 

そうすると、追加アサインすることが無意味になってしまうんですね。

 

素直に謝る

作業を細かくしても、優秀な人をアサインしても納期が守れない場合は謝りましょう。

 

どんなに有能な人でも間違えることはあります。

間違えたら謝る・・・基本です。

 

まとめ

今回はスケジュールを立てるときに重要なこととして、クリティカルパスについて書いてみました。

 

システム開発のプロジェクトに関わってるとスケジュールに関する問題は多々発生します。

 

でも、「納期に間に合わない」と慌てる前に間に合わせるための方法を考えてみましょう。

考えることで名案が浮かぶ・・・かもしれません。

 

「まだあわてるような時間じゃない」

by仙道彰 (スラムダンク)

では。

 

スポンサーリンク

 

 - プロジェクトマネジメント