はじめに
エンジニアにプロジェクトマネジメントが必要？
「なぜエンジニアがプロジェクトマネジメントを学ぶ必要があるのか？」、そう思った人が多いでしょう。
「自分は管理職になるつもりはない」「自分は一生エンジニアでいたい」と思っている人もいるでしょう。
しかし、エンジニア（私を含めて）もプロジェクトマネジメントの知識は必要なのです！！
なぜか、それは私たちは仕事でどこかの会社、チーム、集団に属している以上自分の上司、あるいは他の管理職やもっと偉い人のプロジェクトマネジメントにより動かされているからです。
どこかの組織に属し仕事をしている以上これは免れません。
最近はプログラマーの場合、フリーランスで個人で仕事をしている方もいると思いますが、受託開発のような誰かと関わりながら仕事をする人も例外ではありません。
自分が知っている人が作ったプロジェクトマネジメントに従うならまだしも、何十年も続いている組織の場合は、プロジェクトマネジメントのやり方がレガシー化してしまい、もはや誰も気にせず組織のマネジメントに従ってプロジェクトを進めているだけかもしれません。
プロジェクトマネジメントをしっかりできていない組織ではプロジェクトを進める中で、以下のようなことを言っている人がいるのではないでしょうか？
「なんで見積もりにこんなに時間がかかるの？」
「なんで時間は延びるばかりなの？」
「なんで余裕を持って見積もったのに遅れるの？」
自分が属している組織のプロジェクトで納期遅れがなく目的がしっかりと達成されているなら良いですが、そうでない場合、上記のような文句を言う人が多くいると思います。
本記事を読むことでプロジェクトの遅れがなぜ起きるのか、なぜ目的が達成できないのかを「バッファ（セーフティーゾーン）の取られ方・消費のされ方」と「リソース配分」の観点から知ることができ、対処法としてどのような方法があるのか知ることができます。
プロジェクトマネジメント
そもそもプロジェクトとは？
根本的なことですが、まず、「プロジェクトとは何ですか？」と聞かれてパッと答えられる人は少ないのではないでしょうか。
いろいろな説明があると思いますが、プロジェクトは以下のことだと覚えておけばよいです。
プロジェクトとは？
「目的」「資源」「納期」の3つのバランスと取りながら実行するもの
プロジェクトを何度か行ったことがある人はわかると思いますが、プロジェクト当初の目的、納期、資源を守って最後まで達成するのはものすごく難しいことです。
プロジェクトは基本的に納期に間に合わないものです。遅れるのが普通です。
しかし、納期は絶対守らないといけないというプロジェクトもあるでしょう。
その場合、資源は人の数やお金に関わるものなので増やすのは難しく、多くのプロジェクトでは目的（作るもの）を小さくします。
目的（作るもの）を小さくすることはよくあることなので、プロジェクトがあまりにうまく行っているひとはそのプロジェクトの目的がそもそも小さい、しょぼいのではないかと思ってしまうこともあると思います。
プロジェクトマネジメントがうまくできたら
ここから先読み進める前に、プロジェクトマネジメントがうまくできたらどんなメリットあるか考えてみます。
会社としてみると、プロジェクトの納期を半分にできれば、競合企業よりも圧倒的に優位に立てるようになるでしょう。
個人でみれば、仕事を早く終わらせて自分の趣味や家族との時間を増やすことができます。複数の企業で働いてより多くのお金を稼ぐのも良いでしょう。
他にもそれぞれの方に多くのメリットがあると思いますが、プロジェクトマネジメントをうまく行うことがいかに大事が考えてもらえればと思います。
クリティカルパス
PERTとは
PERTとはProgram Evaluation and Review Techniqueの略です。
複雑なプロジェクト内の各タスクの処理順序の関係をネットワークやフローチャートで表したものです。
クリティカルパスとは
クリティカルパスとはPERT図において最も時間のかかる経路のことです。クリティカルパスが遅れることはプロジェクト全体の遅れを意味します。
つまり、プロジェクトにおいてクリティカルパス状のタスクをいかに円滑に進めるかが大事と言えます。
バッファ（セーフティーゾーン）
なぜ、時間は延びるばかりなのか？
上記でも述べましたが、皆さんはプロジェクトを行うにあたって「なんで時間は延びるばかりなの？」という言葉やそれに近い言葉を聞いたことないでしょうか。
プロジェクトの見積もりはプロジェクトをしたことがある人なら誰しもしたことがあると思いますが、なぜ見積もりの時間はどんどん伸びるのでしょうか？
それは以下の3つの考え方によりバッファ（セーフティーゾーン）は発生するからです。
-
80%くらいの確率で達成できるようにタスクを見積もる
- 「よっぼどのことがなければ大丈夫」と思える時間を見積もる
-
タスクを管理するPMや上司による追加の見積もり
- 念の為、遅れてもいいように時間を追加する
- 各タスクの合流地点の整合、確認用に時間を追加する
-
役員などに「20%巻きでやって」といわれてもいいように余分に見積もる
- 見積もったあとに前倒しでやるように言われてもいいように各タスクで見積もりを増しておく
以下は1.の内容を図で表したものである。
タスクが終わる確率から考えると図のグラフの確率が一番大きいところを見積もればいいですが、ほどんどの人はだいたい80%くらいのところを見積もっていると思います。
理由は、短く見積もって遅れたら他の人に迷惑をかけるし、自分の評価にも関わるからです。
また、短く見積もってそれ通りに終わったら次からタスクを見積もる時にその感覚で見積もるように言われるからです。
なぜ、余計に見積もったのに遅れるの？
上記で3つの考え方によってバッファ（セーフティーゾーン）が発生するのかはわかりましたが、実際にプロジェクトを進めてみると、バッファをしっかりと入れたはずなのに見積もりよりも遅れてしまうことがあると思います。
なぜ、このようなことが起こるのか？
それは、バッファは以下の4つの要因により消えていくからです。
-
学生症候群
- 時間的余裕があるとギリギリまで人はそれをやらない、やる気がでない
-
掛け持ち作業
- 仕事を交互にすることによってリードタイムが延びている
-
浮いた時間は無駄に消費
- 早く終わっても正直に報告すると、次からその時間で見積もられるので終わっても報告しない
-
依存関係
- 作業が依存しているので、ひとつ遅れるといくつものタスクが遅れる
- ~ 4. の要因のどれもプロジェクトやったことがある人なら経験したことがあるのではないでしょうか。
ここでは2.掛け持ち作業がどれほど効率がよくないかを図を用いて説明します。
タスクを一つずつ片付けることを図で表すと以下のようになります。
タスク1~3のそれぞれのリードタイムはタスク一つ分の長さと同じ10日です。
一方でこれらのタスクを掛け持ちして行うことを考えると以下のようになります。
ここではタスク1~3を交互に5日ずつやることを考えています。
図を見てもらうとわかる通り、全体にかかる日数は計30日で、上のタスクを一つずつ片付ける場合と同じですが、一つ一つのタスクにかかっているリードタイムは20日になっているのがわかると思います。
一人でやっているプロジェクトならよいですが、複数人に関わるタスクや他のチームに関わるタスクをしている場合、掛け持ちでタスクを行うことが如何に効率が悪く、迷惑をかけているかもしれないことがこの図からわかるのではないでしょうか。
新しいバッファの取り方
新しいと書いていますがあくまでも上記で説明した3つのバッファの取り方を変えたもので、すでに当たり前のように次に示すバッファの取り方を行っている組織もあると思います。
ここで示す新しいバッファの取り方は以下です。
-
作業ごとの「期限」は設定しない
- 期間のみを掲示する
- 学生症候群をなくす
- 作業がきたらすぐ着手、終わったらすぐ報告
-
各タスクは50%の確率で終わる時間を見積もり
- 余分に見積もらない
-
バッファは最後にプロジェクトバッファとして用意
- プロジェクトの遅れはプロジェクトバッファの残りを見ることでわかる
-
クリティカルパス以外のところは合流バッファーを用意
- クリティカルパスを長くしない
上記のバッファの取り方を図で表すと以下のようになります。
各タスクで50%の確率で終わる時間を見積もっているためタスクが見積もりよりも長くなってしまう可能性はあるりますが、延びた時間はPERT図の最後のプロジェクトバッファで消費します。これにより、各タスクには期限を設けないため柔軟に対応することができる。
また、プロジェクト全体の遅れがプロジェクトバッファの残りを見ることでわかるのもこのバッファの取り方のメリットです。
クリティカルチェーン
それでもプロジェクトがうまくいかない
合流バッファ、プロジェクトバッファを用意したのにそれでもプロジェクトがうまくいかない。そんなことがあるかもしれません。
バッファは適切にとって十分時間もあるはずなのに、合流バッファ、プロジェクトバッファをつかい果たしプロジェクト全体の納期が遅れてしまうことがあるかもしれません。
なぜ、このようなことが起きるのか？
以下の図のタスクを表す四角形の図形にここでは誰がそのタスクを行っているのかを書いてみます。
その結果が以下の図で、図におけるXは同じ人によって行われるタスクです。
見てわかるように、Xのタスクの配分の仕方が明らかにおかしいです。
Xのキャパシティが無視されているため、Xに過剰にタスクが割り振られており、一つのタスクとしてはXが十分に期間内に終わらせれる内容のタスクとしても、複数のタスクを同時に行う必要がある場合はXがこのプロジェクトにおけるボトルネックとなり、プロジェクトの遅延に大きな影響を与えてしいます。
本来はXにできる仕事量に限度があることを考慮しないといけません。
つまり、私たちが考えなければならないのは共通リソースの関係を表すパスです！
この「共通リソースの関係を表すパス」を図に書くと以下のようになります。
図の中にある共通のリソースの従属関係を表すパス、これがクリティカルチェーンです。
クリティカルパスとの違いを説明すると、クリティカルパスは作業の流れに起因するもであり、クリティカルチェーンは共通リソースに起因するものです。
この記事で一番言いたいことはクリティカルパスだけを見ているマネージャーは多くいいますが、それだけを考えていたらプロジェクトは破綻する可能性があると言うことです。
共通リソースの取り合いが起こらないように、共通リソースの配分として、誰にどのタスクをどのタイミングで依頼するかなどしっかりと考えましょう。