プロジェクト概要書とWBSを詳細化し、あるべき姿を示したものが、
プロジェクト計画書と言われている。

具体的には管理の対象である、
品質管理、進捗管理、費用管理、組織要員管理、契約管理、生産性管理、変更管理。
この7つの管理を計画する。

ただ、この7つはPMが管理し易いよう便宜上分けただけであって、
相互に密接に関連している。
計画立案のために、スコープ定義という概念が存在する。
プロジェクトにおいて作成する成果物と、
この成果物を生み出すために必要な範囲である。

簡単に言えば、
「ここからここまでは作成しますが、ここから先はしない」
というようなもの。

これを纏めたものが、WBS。
直訳すれば作業分割構造図であり、
プロジェクトで必要な作業項目を階層構造として示した図だ。


開発プロジェクト―――プロジェクト計画
             +―外部設計
             +―内部設計
             +―プログラミング単体テスト
             +―結合テスト、システムテスト


例ですが、こんな感じ。
プロジェクトの立ち上げに際して、
プロジェクト概要書が作成される。

ちなみに、この概要書はスポンサーが作る場合もあれば、
PMが作成し、スポンサーが承認する場合が多い。

じゃあ社内開発の場合はどうなの? となれば、
PM=社員、スポンサー=CEO、CTOだと思う。


つまり社内開発だからと言って、
ここをすっ飛ばして良いという理由にはならない。
プロジェクトとは有期であり、言わば繰り返しが無いことが前提らしい。
ある意味で、一発勝負の性質を孕んでいる。

そこで、その一発勝負の成功率を上げる為にも、
管理が必要になってくる。

すなわち、失敗を避けるための管理であり、
成功するための管理では無い点が注意するべき点だ。
(正解は無い、ということ)


管理のためのサイクルとは、

計画⇒実行⇒評価⇒改善

この繰り返しである。
別名、デミングサイクル。

あらゆる事象を、このサイクルで回し、
改善を積み重ねることで軌道から外れ易いプロジェクトを、
失敗から遠のけるのだ。

だから、プロジェクトを「管理」するのである。
プロジェクトマネージメント。
プロジェクトをマネージメントする。言葉の通りです。

では、プロジェクトって何でしょうか。
どんな定義をもってして、プロジェクトと言うのでしょう。

どうやら、
『独自の成果を創造するために実施される有期的活動』
こそプロジェクトと言われるそうです。

つまり、PMのお仕事とは、限られた期限の中で行なわれる活動を、
裁量して適切に取り計らうことこそが真実のようです。


もっとも、僕の場合はグループウェアの開発(所謂、SaaS!?)なので、
連続した有期活動(有期を納期、或いは定期的なメンテナンスと定義して)
をマネージメントすることこそPMのお仕事と言えるのかもしれません。