見出し画像

【プロマネ】プロジェクトマネジメントの歴史(体系化のはじまりから現代まで)

プロジェクトマネジメント体系化の始まり - クリティカルパス法とPERT

プロジェクトマネジメントが広く認識されるようになったのは、1950年代になってからでした。1950年代以前のプロジェクトは、主にガントチャートと体系化されていない手法やツールにより限定的に管理されていました。そうした中で、二つの数学的に構造化されたプロジェクトスケジュールモデルが同時期に開発されました。

画像1

(クリティカルパススケジュールの例)

一つが「クリティカルパス法」(Critical Pass Method: CPM)で、これはプラント保全プロジェクトを管理するために、デュポン社とレミントングランド社が合弁事業として開発しました。クリティカルパス法は、タスク間の依存関係を評価し、タスクの実行にかかる時間を測定するスケジューリング手法です。

画像2

(PERT GUIDE for ANAGEMENT USE - 1963)

もう一つは「PERT」(Program Evaluation and Review Technique)で、これはポラリスミサイル潜水艦プログラムの一環として、ロッキード社とブーズ・アレン・ハミルトン(コンサルファーム)が共同で開発したものです。PERTはタスクを評価し、プロジェクト完了するために必要な最短時間を特定するアプローチで、時間測定の考え方には前述のクリティカルパス法と類似点があります。特徴としては、悲観・楽観・現実的と3つのシナリオを作成することなどがあります。

AACE、PMIの設立

こうしてプロジェクトのスケジュールモデルが開発されるのに伴い、コスト見積り、コスト管理などプロジェクトのエコノミックスに対する技術も進化していきました。この潮流から1956年にAACE(American Association of Cost Engineering, 後に国際組織としてAssociation for the Advancement of Cost Engineeringに改称)が、プロジェクトマネジメントに携わる実務家(当時はまだプロジェクトマネージャやPMOという言葉は使われていません)や、計画・スケジュール・コスト管理を行う専門家により設立されました。

プロジェクト管理の重要性、有用性は、プロジェクトに携わる人たちの間で共通認識になり、1962年には米国防総省において将来のプロジェクトではWBS(Work Breakdown Structure)を使用することが要求されるに至りました。そうした流れから、1969年には恐らく、多くの皆さんもよくご存じのPMI(Project Management Institute)が設立されました。

画像3

PMIは1980年代に、プロジェクト管理の手順とアプローチを標準化するための取り組みに力を入れていました。そして1996年に、最初のPMBOK(Project Management Body of Knowledge)が、プロジェクトマネジメントの知識体系としてまとめられて、発行されました。PMBOKは改訂が続き、2012年に4th editionでISOがプロジェクト管理プロセスを採用し、最新版ではアジャイルなどの考え方も取り入れながら、2021年には7th editionがリリースされることになっています。PMBOKに準拠し、PMIが認定するProject Management Professional(PMP)は、国際資格としてプロジェクトマネージャに世界で最も人気がある資格になっています。

アジャイルの潮流

現代にいたるプロジェクトマネジメント体系化の大きな流れは、はじめエンジニアリングから出発し、プロジェクトにおけるタスク、手順の明確化、効率化という観点で発達してきました。その本流に対して、ソフトウェアやプロダクト開発でのプロジェクトマネジメントという側面から、新しい潮流がアジャイルという枠組みで、合流してきているのが今日のプロジェクトマネジメント体系の状態といえるでしょう。

1990年代に従来のウォーターフォール型といわれる手順、手続きを重視し、硬直的になりがちであったプロジェクト手法に対してのカウンターとして、今日アジャイル手法として括られる多くの手法が開発されました。代表的なものとしてRapid Application Development(RAD)、エクストリームプログラミングなどがあります。2001年には17人のソフトウェア開発者が米国ユタ州にあつまり、アジャイル開発のマニフェストを発表しました。以下が4つの宣言です。

• プロセスやツールよりも個人と対話を、
• 包括的なドキュメントよりも動くソフトウェアを、
• 契約交渉よりも顧客との協調を、
• 計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

スクラムの登場

画像4

スクラムはソフトウェア導入プロジェクトにおいては、現時点ではメインストリームになってきています。一般的にスクラムは、アジャイル手法の一つとして理解されていますが、あまり知られていないのはスクラムが、アジャイルという呼称が世間一般で膾炙される前から存在したこと、そしてこれが日本発の理論であるということです。

画像5

(野中氏と竹内氏)

遡ると1986年に、当時一橋大学の竹内弘高氏(1946 - )と野中郁次郎氏(1935 - )がハーバードビジネスレビューに「The New New Product Development Game」という論文を寄稿し、そこで製品開発の文脈でスクラムという用語を紹介しました。竹内氏、野中氏は自動車、コピー機、プリンター業界のケースステディを通じて、スピードと柔軟性を向上させるアプローチについて説明しました。スクラムの言葉の由来は、プロセス全体を複数の重複するフェーズに渡って、一つの部門横断的なチームによって実行し、チームは「ボールを味方の間で受け渡しながら、徐々に前進して距離を稼いでいく」ことに重ね合わせているところから名づけられたようです。

その後1990年初頭にソフトウェア開発の現場でスクラムが使用され始め、テスト・改善が重ねられて、Ken Schwaber (1945 - )とJeff Sutherland(1941 - )を中心に1995年に共同でスクラムフレームワークを説明する論文を発表しました。

私はGE Healthcare/GE Digital在籍時に、スクラムでの大規模グローバルCRM導入プロジェクトを、日本から統括する立場で指揮をとりました。スクラムは非常に完成度が高く、有用性も大きいため、私は理論としてのスクラムには心酔しています。ただし、オフショア開発を前提とする、大規模なグローバルプロジェクト適用には難点が多く、完全な形でスクラムを導入することは不可能でした。スクラムは美しい方法論ですが全てのケースに万能ではなく(また、そのような理論は存在しない)、そのため一部スプリントなどを取り入れた不完全なスクラムがアジャイルと呼ばれて進められていたりもします。これは私も取ったアプローチですので、否定はしません。ただし、スクラムが本来目指していた本質を理解しないまま、その方向に走るのは危険です。PMBOKのような読みにくい資料ではないので、プロジェクトに携わる方はScrum Guideは是非、一読して頂きたいと思います。

今後のプロジェクトマネジメント

今後のプロジェクトは、リモート環境でのプロジェクトがスタンダードになっていきます。グローバルプロジェクトの割合も、さらに増えていくことでしょう。そうした場合に、共通言語としてのフレームワーク・方法論と、柔軟性やスピード感を重視するアジャイル型のプロジェクト遂行の重要性は今以上に増していきます。

一方で、日本のプロジェクトの現場では、プロジェクト管理の方法論はかなり軽視されているように感じます。これは、ドキュメンテーションを偏重する文化と、相反しているようにも思います。

元々、非定型作業を管理することがプロジェクトマネジメントで、その性質から、プロジェクトに携わる者は、変化への対応、柔軟性が必要になります。そして「結局プロジェクトによって状況が違うから・・」ということがプロジェクトマネジメントの方法論軽視につながっているように感じます。わたしはPMPを持っていますが、同じくPMPを持たれているような方でも、同様の発言があることに驚くことがあります。これは知識としてのプロジェクトマネジメントと、実践としてのプロジェクトマネジメントが別物だということを表しているように思います。

他方、グローバルプロジェクトや大規模プロジェクトを多く経験しているベテランのプロジェクトマネージャであれば、方法論やフレームワークを理解することの重要性と、それをどう現場の状況に応じて適用させていくかがプロジェクトマネージャの力量であるということをよく知っている方が多いです。それがなければ大規模で複雑性を有したプロジェクトを全体指揮することなど到底不可能だからです。

今後、製品やソフトウェアなどもトレンドの変化があったり、社会の情勢の変化も大きくあることでしょう。そうであるからプロジェクトマネジメントの方法論も、それに合わせてアップデートが続いていきます。ゆえにアジャイルへの大きな流れも止まることはありません。アジャイルを取り入れたプロジェクト方法論を、現場で適用するプロジェクトマネージャも、マクロとミクロ両方で起きる変化に対してのアプローチを、常にアップデートしていかなければなりません。

私はプロジェクトマネジメントという仕事を、特に短期的にはAIに代替されない仕事の一つとしてとらえています。ここまで、その所感を得るうえでの前提としての歴史を振り返りました。

この記事が気に入ったらサポートをしてみませんか?