プリンス2

PRINCE2（PRojects IN Controlled Environments）は、構造化されたプロジェクト管理手法^[1]および実践者認定プログラムです。PRINCE2は、プロジェクトを管理可能かつ制御可能な段階に分割することに重点を置いています。

英国、西ヨーロッパ諸国、オーストラリアなど世界中の多くの国で採用されています。^[2] PRINCE2のトレーニングは多くの言語で提供されています。^[3]

PRINCE2は、英国政府の情報システムプロジェクト標準として開発されました。2013年7月、PRINCE2の権利は、内閣府から内閣府とCapitaの合弁会社であるAXELOS Ltdに譲渡され、それぞれ49%と51%の株式を保有しました。^[4]

2021年、PeopleCertによるAXELOSの買収に伴い、PRINCE2はPeopleCertに移管されました。^[5]

PRINCE は、PROMPT II (プロジェクト リソース組織管理計画技法) と呼ばれる以前の手法から派生したものです。1989 年に、英国中央コンピュータ通信庁(CCTA) は、PROMPT II のバージョンを情報システム (IT) プロジェクト管理の英国政府標準として採用しました。このバージョンは「PRINCE」と名付けられましたが、これはもともと「PR OMPT II IN the C CTA E nvironment」の略語でした。PRINCE は、公務員コンテストで「 PR ojects IN C ontrolled E nvironments」の頭字語として改名されました。PRINCE2 は、1989 年に英国政府支援機関である英国中央コンピュータ通信庁(CCTA) によって最初に発表され開発された以前の PRINCE 手法の第 2 版です。 ^{[6] PRINCE2 は、一般的な}プロジェクト管理手法として 1996 年にリリースされました。^[7]

それ以来、PRINCE2はますます人気を博し^[8]、現在では多くの英国政府省庁や国連システム全体でプロジェクト管理の事実上の標準となっています。

PRINCE2は1996年の発売以来、2009年の「PRINCE2:2009 Refresh」と2017年の「PRINCE2 2017 Update」の3回にわたる大きな改訂が行われています。2017年の更新は、実際のプロジェクト環境におけるPRINCE2実践者からのフィードバックと実践的なビジネスプラクティスの進化に基づいて行われました。^[9]最近では、2023年にAXELOSがPRINCE2 7（第7版）を発売しました。これについては以下で説明します。

これらの側面は、許容範囲またはパフォーマンス目標とも呼ばれます。許容範囲は、上位レベルの管理職が下位レベルに設定する権限の委任レベルを定義します。責任のある管理職は、許容範囲を超えることが予測されない限り、提供された許容範囲内で管理する必要があります。そうでない場合は、委任元の管理職にエスカレーションする必要がある例外と見なされます。この管理方法は「例外による管理」として知られており、PRINCE2 の原則の 1 つです。この方法で管理することで、上級管理職の時間を節約できます。組織によっては、許容範囲を主要業績評価指標(KPI) にすることができます。次の表に、プロジェクト レベルの許容範囲をまとめます。^[10]

PRINCE2 は 7 つの原則に基づいており、これらをカスタマイズすることはできません。PRINCE2 の原則は、プロジェクトを PRINCE2 方法論に沿わせる考え方と言えます。プロジェクトがこれらの原則に従わない場合、そのプロジェクトは PRINCE2 を使用して管理されていません。

1. 継続的なビジネス上の正当性を確保する: ビジネス ケースは最も重要なドキュメントであり、プロジェクトが引き続き実行可能であることを確認するためにプロジェクトの各段階で更新されます。これが当てはまらなくなった場合は、早期終了が発生する可能性があります。
2. 経験から学ぶ: 各プロジェクトは教訓ログを保持し、車輪の再発明を避けるために、プロジェクトは自身の、および以前のプロジェクトと同時進行のプロジェクトの教訓ログを継続的に参照する必要があります。教訓が変化を促さない限り、それは単に特定された教訓であり、学習されたものではありません。
3. 役割、責任、関係を定義する: 役割は個人から分離され、個人は複数の役割を担ったり、役割を共有したりできます。PRINCE2 の役割は 4 つのレベル (企業またはプログラム管理、プロジェクト ボード、プロジェクト マネージャー レベル、チーム レベル) に構造化されています。プロジェクト管理チームには最後の 3 つのレベルが含まれ、すべての主要な利害関係者 (ビジネス、ユーザー、サプライヤー) が参加する必要があります。
4. 段階別に管理: プロジェクトは段階ごとに計画および管理されます。段階間の移動には、新しい証拠に照らしてビジネス ケース、リスク、全体計画、および詳細な次の段階の計画を更新することが含まれます。
5. 例外による管理: PRINCE2 プロジェクトでは、委任された権限の制限を確立するために、各プロジェクト目標に対して許容範囲 (上記の 6 つの側面) が定義されています。管理レベルでこれらの許容範囲を超えると予測された場合 (たとえば、管理段階の時間が現在の管理段階の推定時間よりも長くなる場合)、次の管理レベルにエスカレーションされ、どのように進めるかが決定されます。
6. 製品に重点を置く: PRINCE2 プロジェクトは、製品の定義と提供、特に品質要件に重点を置いています。
7. プロジェクトに合わせて調整: PRINCE2 は、プロジェクトの環境、規模、複雑さ、重要性、時間的余裕、およびリスクに合わせて調整されます。調整は、プロジェクトを開始するプロセスの最初のアクティビティであり、各段階でレビューされます。

PRINCE2 のすべての側面がすべてのプロジェクトに適用できるわけではないため、すべてのプロセスにはスケーラビリティに関する注記があります。これにより、プロジェクト マネージャー (およびプロジェクトに関与するその他の関係者) は、プロセスをどの程度適用するかについて指針を得ることができます。これの利点は、PRINCE2 を特定のプロジェクトのニーズに合わせて調整できることです。欠点は、PRINCE2 の重要な要素の多くが省略され、PINO プロジェクト (名前だけの PRINCE) になってしまう場合があることです。

1. プロジェクトを開始し、幹部とプロジェクト マネージャーを含むプロジェクト チームが任命され、プロジェクト概要が作成されます。
2. プロジェクトを開始し、ビジネス ケースを洗練し、プロジェクト開始ドキュメントをまとめます。
3. プロジェクトを指揮し、プロジェクト委員会がプロジェクト マネージャーを指揮してプロジェクトを監督します。
4. プロジェクト マネージャーがチーム マネージャーに作業パッケージを承認し、問題とリスクを管理し、プロジェクト ボードに進捗状況を報告する段階を制御します。
5. 製品の納品管理は、プロジェクト作業の受諾、実行、納品に関する正式な要件を課すことで、プロジェクトマネージャーとチームマネージャー間のインターフェースを提供します。^[11]
6. ステージ境界の管理。プロジェクト マネージャーは、プロジェクト委員会が次のステージを承認するか、プロジェクトを終了するかを決定するための情報を準備します。
7. プロジェクトの終了。プロジェクトが正式に終了し、後続のアクションが文書化されて割り当てられ、教訓が学ばれ、利点が評価されます。

PRINCE2 の第 7 版では、この方法に新しい重要な側面、つまり人の役割が導入されました。プロジェクトの目的は、通常業務 (BAU) 活動を実行する人々に影響を与える変更を実現することです。プロジェクトがどれだけうまく変更を実現できるかは、プロジェクト チームの能力、チーム間の関係の強さ、および変更の影響を受ける人々によって決まります。これらの理由から、PRINCE2 では、組織に変更をうまく実装できるように、プロジェクトに変更管理を組み込むことを推奨しています。

PRINCE2 で説明されている管理製品は、プロジェクトの「高レベル」管理にのみ使用されます。タスク内では、タスク マネージャーは独自のプロジェクト管理フレームワークを決定する必要があります。PRINCE2 マニュアルで提案されているいくつかの方法には、製品ベースの計画、変更管理、品質レビュー手法、カンバン ボード、ガント チャート、PERT チャート、クリティカル パス分析などがあります。

PRINCE2はアジャイルソフトウェア開発手法を使用するプロジェクトの管理にも使用できます。^[12]

品質レビュー手法は、プロジェクトの製品が要求された標準 (つまり、定義された品質基準を満たす) を満たしていることを確認します。これは、製品のエラーを特定する品質レビュー ミーティングで行われます。品質レビュー ミーティングでは、特定された問題の解決は試みられません。ミーティングには、プロジェクトの成果物 (または製品) に関心のある人々と、特定された問題に対処できるプロジェクト チームのメンバーが集まります。

以下はPRINCE2の全エディションのリストです。2020年1月1日現在、「PRINCE2 2017」は「PRINCE2 6th Edition」に改名されました。また、以前のエディション「PRINCE2 2009」は「PRINCE2 5th Edition」に改名されました。ブランド名以外の変更はありません。名前変更の理由は、「名前の形式がプロジェクト管理業界の他のフレームワークで使用されている形式と一致するようにするため」でした。^[13] PRINCE2の全バージョンのリストは、PRINCE2マニュアルの表紙に印刷されています。

(*n 番目の名前は、文脈上、他のエディション用に追加されたものですが、元々これらの名前で参照されていたわけではありません。ただし、PRINCE2 マニュアルの表紙では、そのように参照されています。)

PRINCE2 は、明確に定義されたフレームワーク内でプロジェクトを管理する方法を提供しますが、プロジェクト管理は複雑な分野であり、このようなフレームワークを使用してもプロジェクトが成功するとは限りません。

PRINCE2 の宣伝されている利点には、完成品の品質の向上、リソースの効率的な管理、「英雄的」(規制不足) または「機械的」(規制過剰) な作業の回避、プロジェクト チーム間の信頼の向上などがあります。

PRINCE2 は、ドキュメント、ログ、リストの作成と維持に必要な作業のため、小規模なプロジェクトや要件の変更が予想されるプロジェクトには不適切であると考えられる場合があります。また、成果物の構造により、より有用な作業を行うのではなく、成果物自体の作成、つまり「チェックボックスにチェックを入れる」ことに集中する可能性もあります。^{[引用が必要]}

PRINCE2の著者らは、批判に対して、この方法論は拡張可能であり、プロジェクトや環境の特定の要件や制約に合わせて調整できると一般的に指摘している。^[14]この調整への強い重点により、一部のユーザーは、PRINCE2は反証不可能であると不満を漏らしている。つまり、プロジェクトで発生した問題がPRINCE2自体ではなく不適切なPRINCE2の適用に起因する場合、PRINCE2が「機能する」か「ベストプラクティス」を構成するかを判断することは不可能である。

1997年から2007年までの英国のブレア政権（およびその後の英国政府）の経験は、その期間に納税者に負担を強いられた一連の注目度の高い失敗したITプロジェクト^{[15] [16] [17]と、ブレア政権とPRINCE2の共同所有者である}Capitaとの財政関係をめぐる論争を考えると、PRINCE2が「ベストプラクティス」であるという主張を弱めると言えるでしょう。^{[18] [19]} PRINCE2のトレーニング資料では、これらの失敗を取り上げ、プロジェクト環境へのPRINCE2の不適切な調整が原因であるとし、政府プロジェクトマネージャに対するPRINCE2トレーニングの強化を提唱しています。^[要出典]

Project Management InstituteのProject Management Professional (PMP) は、PRINCE2 の競合相手とみなされることがあります。一般的に、英国、オーストラリアでは PRINCE2 が好まれ、米国およびアメリカ諸国では PMP が好まれます。アジア、アフリカ、中東地域では、PMP または PRINCE2 に対する強い好みはありません。重要なことは、PMP (PMBOK) は PRINCE2 と併用できることです。

PRINCE2とPMPは、広告資料で互いの存在を認め、互いに併用できる補完的な製品（PRINCE2を「方法論」、PMPを「標準」^[20]）として位置づけようとしています。実際には、企業や実務者は、プロジェクト環境、地理的な場所、関連するコストに応じて、1つのシステムまたは両方のシステムを選択します。

• アジャイルソフトウェア開発
• プロジェクト管理ソフトウェアの比較
• ガントチャート
• プロジェクト管理トピックのリスト
• 作業分解構造

ウィキメディア・コモンズには、 PRINCE2に関連するメディアがあります。

• 公式サイト
• 英国ビジネス・企業・規制改革省（BERR）のプロジェクト管理ガイドライン（PRINCE2に完全準拠）
• PRINCE2.wiki