Framework とは

およそ５、６年前、駆け出しのプロマネだったわたしは以下のように考えていた、、

PMBOK では大きく以下の９つの分野に分けて説明がなされている。
１） 統合マネジメント
２） スコープマネジメント
３） タイムマネジメント
４） コストマネジメント
５） 品質マネジメント
６） 組織マネジメント
７） コミュニケーションマネジメント
８） リスクマネジメント
９） 調達マネジメント
これまでにプロジェクトマネジメントでは「タイム」「コスト」「品質」の３つが主力であったが、その点、PMBOK では、「組織」「コミュニケーション」「リスク」「調達」などのサポート的な管理の重要性を説いている。
難しい説明はここまでにして、私はこの世の中の流れに対し、あえて異論を唱えたい。私はまさにこのような「型にはめられる」ような管理が苦手である。それは、自分が技術者であることに関係するかもしれない。（技術者は元来押し付けられることにはなんでも抵抗する）このようにどこで策定されたか分からない、得体の知れない「管理」とやらには拒否反応が出てしまう。本当に困ったものである。だが、たぶんそれは、これまでの経験から知らずに肌に刷り込まれた「現場の汗から生まれたもので無ければ意味を成さない」とゆう教訓から来るもののように思われる。
Framework とは、辞書で調べると「骨組み」とあるように、ある統合的見地の元に策定されたプロジェクトマネジメント手法をさすものであり、プロジェクト管理のベースとなるものである。これは、ピザ生地のようなものなので、これだけでは美味しくないしピザとは言えない。美味しいピザには、チーズやソース、トッピングが必ず必要になる。

vol.8

技術的にも管理的にもFrameworkがはやっていた時期でもあり（今でもその兆候はなくなっいないですが）、Frameworkに対してアレルギーを感じていました。Frameworkとは、ただのユーザーの囲い込みではないか？流行がすぎるとすぐに忘れ去られ、それと同時にそのユーザーも捨てられる。また新たなFrameworkが勃興してはさびれていく。。

このころの大きな勘違いはPMBOKをFrameworkと定義していたことである。もしくはFrameworkの定義が狭かったのかも。PMBOKの目的は、世の中の「良い実務慣行と一般的に認められているものを特定する」ことであり、これらをベースに自らがチョイスしよりよいものに転化していくことを推奨するものです。あながち間違いではなかったようです。。