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