【009】プロジェクト管理は普遍的な技術である

中津山　恒

プロジェクト管理に必要なのは線表とWBSだけではない

プロジェクト管理という言葉は、かなりポピュラーだと思います。読者の中にも、プロジェクト管理を行っている、あるいは行ったことがある方が多数おられるでしょう。
プロジェクト管理を行う方は、プロジェクトの計画を示す線表（ガント・チャート）や、実施項目を示すWBS（ワーク・ブレークダウン・ストラクチャ）を書いていると思います。線表は、実施項目のスケジュールを帯で示したものです。WBSは実施項目を段階的に詳細化（ブレークダウン）したもので、最終的には、担当者が実施可能なレベルまで掘り下げます。

しかし、線表やWBSがあればプロジェクト管理を行っていると言えるのでしょうか？　もちろん、答えはNOです。やるべきことは他に多々ありますが、筆者の考えでは、もっとも重要なことのひとつは役割と責任を明確にすることです。
このためのツールとしては、役割分担を示すRACI（レイシーと発音します）チャートがありますが、本稿の趣旨としては詳細に入りすぎるので、今回は割愛します。

プロジェクト管理は「技術」

プロジェクト管理は外在化（記号化）できない勘所や感覚のような「技能」ではなく「技術」です。つまり、プロジェクト管理の手法は、体系的にまとめられており、それを理解した第三者が実施可能です。このような体系でもっとも有名なのは、PMBOK（Project Management Body of Knowledge）です。
筆者がこれまで身を置いてきたソフトウエア開発は、もっともプロジェクト管理の精度が低い分野で、建設や建築とは比較にならないほど失敗の可能性が高いと考えています。筆者自身の経験でも、当初の目論見通りに着地できたプロジェクトはほとんどないと言ってもよいくらいです。　しかしそれだけに、ソフトウエア開発プロジェクトでは、できる限りの対策を講じようという姿勢が一般的であり、他の分野に比べるとプロジェクト管理の概念と用語が浸透していると感じます。

ちなみに、プロジェクト管理の失敗とは、計画と実績に一定以上の乖離が生じたことを言います。期限通りに終わらない、期待した成果が得られない、投入する資源が予定から大きく外れる、という場合が当たります。期間や投入資源の実績が計画より少なかった場合も失敗と考えるのは、その時間と資源を他のプロジェクトに投入できたはずだからです。マーケティングをご存知の方には、意思決定の誤りによって利益の機会を逸する「機会損失」を思い起こしていただければ理解しやすいと思います。

プロジェクトとは何か

話は少し変わりますが、プロジェクト管理の対象であるプロジェクトについて、「そもそもプロジェクトとは何か？」と問われたとき、明確に答えられる人は多くないと思います。一般的には、①期限がある、②成果が定義されている、③投入できる資源に限度がある、といった定義がなされています。この意味では、期限や成果が明確に定義されていない場合には、プロジェクトとは呼べません。

多くの仕事はプロジェクト

プロジェクトの定義を見ると、世の中の多くの仕事がプロジェクトであることにお気づきだと思います。逆にプロジェクトでない仕事は、期限がない、成果が定義されていない、資源に限度が設けられていない、という条件のひとつ以上に当てはまるものです。たとえば、相談窓口での顧客対応であるとか、情報システムの運用のように、常に行っている仕事はプロジェクトではありません。基礎研究も、期間、成果、投入資源を予め明確に定義することが困難なので、一般にはプロジェクトとは言えません。

プロジェクト管理の実践でプロジェクトを成功に導こう

多くの仕事がプロジェクトである以上、プロジェクト管理が普遍的な技術であることは明々白々です。
筆者が関わってきた多くのプロジェクトは大半がソフトウエア開発でしたが、このところソフトウエア開発以外のプロジェクトに関わることが増えてきました。その中で感じることは、プロジェクト管理を知らずに不必要にリスクを冒している事例が多いことと、プロジェクト管理がわかっているつもりになっているため、実際にはリスク管理できていない事例が多いことです。前者は助言すれば対応してもらえることが多いので、まだ傷が浅くて済むのですが、後者は助言が聞き入れられないことが多いので、深刻なダメージを負う危険性が大です。

国際協力を例にとって説明します。この分野では、プロジェクトマネジメントにPCM（Project Cycle Management）というフレームワークを用います。関係者はPCMを理解していて、このフレームワークがいわば標準語になっています。PCM自体は線表やWBSを含みませんが、広く用いられます。ただし、使い方はプロジェクトによってまちまちで、大まかな場合が多いようです。
最も残念なのは、役割と責任が明確になっているとは言えないことです。もちろん、関与者の基本的な役割は定義されるのですが、WBSとは粒度も違い、役割とWBSが連動していません。RACIチャートを用いれば、役割とWBSの関連が明確になり、プロジェクト運営が飛躍的に円滑になると考えます。

話をプロジェクト管理全般に戻すと、PMBOKなどの主だった考えを学び、プロジェクト管理手法を業務の中に取り入れていけば、プロジェクトが成功する可能性は飛躍的に向上すると思います。

2015年2月3日

＊コラムの内容は専門家個人の意見であり、IBLCとしての見解ではありません