1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

開発アプローチとライフサイクル・パフォーマンス領域

Last updated at Posted at 2023-03-22

初めに

記事をご覧いただきありがとうございます!
PMBOK第7版を元にプロジェクト・マネジメントについて勉強しております。
章立てでまとめておりますので、ご自身のあったものをご覧ください。

ステークホルダー

チーム

開発アプローチとライフサイクル

計画

プロジェクト作業

デリバリー

不確かさ

〜作成中〜

3 開発アプローチとライフサイクル・パフォーマンス領域における成果

  • プロジェクト成果物と一致する開発アプローチ
  • プロジェクトの開発時から終了時まで、事業価値とステークホルダーへの価値を実現する複数のフェーズで構成されるプロジェクト・ライフサイクル
  • プロジェクト成果物の作成に必要な、デリバリーのケイデンスと開発アプローチを促進するフェーズで構成されるプロジェクト・ライフサイクル

成果物

プロセス、フェーズ、またはプロジェクトを完了するために生成することが求められる固有で検証可能なプロダクト、所産、またはサービス遂行能力。

開発アプローチ

プロジェクト・ライフサイクルの期間中において、プロダクト、サービス、または所産を創り発展させるために用いる方法。予測方法、反復方法、漸進方法、アジャイル方法、ハイブリッド方法などがある。

ケイデンス

プロジェクト全体を通じて実施されるアクティビティのリズム。

プロジェクト・フェーズ

論理的に関連のあるプロジェクト・アクティビティの集合。一つ以上の成果物の完了によって終了する。

プロジェクト・ライフサイクル

プロジェクトがたどる開始から終了に至る一連のフェーズ。

3.1 開発、ケイデンス、ライフサイクルの関係

  • プロジェクト成果物のタイプ→開発方法が決定
  • 成果物の種類と開発アプローチ→プロジェクトのデリバリー回数とケイデンスに影響
  • アプローチとデリバリー・ケイデンス→プロジェクトのライフサイクルとフェーズが決定

3.2 デリバリー・ケイデンス

  • デリバリー・ケイデンスとは

プロジェクト成果物のタイミングと頻度

  • プロジェクトのよって、デリバリーのタイミングは異なる。
デリバリー 説明
1回だけのデリバリー
  • プロジェクト終了時にデリバリーを行う。
複数回のデリバリー
  • プロジェクト期間中に複数の構成要素が含まれるプロジェクトでは、デリバリーを複数回行う。
  • デリバリーは、構成要素に従って順次行われる場合と個別に開発した順に行われる場合とがある。
  • すべてのデリバリーが完了していなければ、プロジェクトは完了したと見なされない。
定期的なデリバリー
  • 毎月や2ヶ月毎などデリバリーのスケジュールが固定されている。

3.3 開発アプローチ

  • 開発アプローチは、プロジェクトのライフサイクル中にプロダクト、サービス、または所産を創出して発展させるために使用される手段である。
  • 使用されるアプローチには、予測型、ハイブリッド、適応型の3つがある。

予測型アプローチ(ウォーターフォール・アプローチ)

  • プロジェクト開始時にプロジェクトとプロダクトの要求事項を定義、収集、分析できるときに有効。
  • 多額の投資が行われる。
  • リスクが高いので、頻繁なレビュー、変更管理の仕組み、開発フェーズ間の再計画が必要なときに使われる。
  • スコープ、スケジュール、コスト、資源のニーズ、リスクは、プロジェクト・ライフサイクルの初期段階で適切に定義でき、比較的安定している。
  • プロジェクト・チームはプロジェクトの初期段階で不確かさの度合いを下げ、事前に計画の大部分を立案できる。
  • 概念実証の開発を使って選択肢を検討するが、プロジェクト作業の大部分は、プロジェクトの開始当初に作成された計画に従う。

ハイブリッド・アプローチ

  • 予測型アプローチと適応型アプローチを組み合わせたもの。
  • 要求事項にまつわる不確かさやリスクがあるときに役立つ。
  • 成果物をモジュール化できるとき、あるいは異なるプロジェクト・チームによって開発できる成果物がある時にも役立つ。
  • 適応性は、予測型よりも高いが、適応型よりも低い。
  • ハイブリッド・アプローチでは、反復型または漸進型開発アプローチを使うことが多い。

反復型アプローチ

  • 要求事項を明確にし、さまざまな選択肢を調査するのに役立つ。
  • 最終イテレーションより前に受け入れ可能と見なされる十分な能力が得られることがある。

漸進型アプローチ

  • 一連のイテレーションを通じて成果物を生成するために使われる。
  • 各イテレーションでは、事前に定義された時間枠内で機能が追加される。
  • 成果物には、最終イテレーション後にならないと完了と見なされない機能が含まれる。

適応型アプローチ(アジャイル・アプローチ)

  • 要求事項の不確かさと変動性が高く、プロジェクト期間を通じて要求事項が変わる可能性が高いときに役立つ。
  • プロジェクトの開始時に明確なビジョンが確立される。
  • 初期の既知の要求事項は、ユーザーのフィードバック、環境、または想定外のイベントに応じて精緻化されたり、詳細化されたり、変更されたり、置き換えられたりする。
  • 適応型アプローチでは、反復型と漸進型アプローチを使う。
  • 適応型手法の色がより濃くなると、イテレーションがより短くなり、ステークホルダーのフィードバックに基づいてプロダクトが進化する可能性が高くなる。

3.4 開発アプローチの選択に関する考慮事項

  • 開発アプローチの選択に影響を与える要因は以下のカテゴリーに分類できる。
    • プロダクト、サービス、または所産
    • プロジェクト
    • 組織

3.4.1 プロダクト、サービス、または所産

  • 開発アプローチに影響を与えるプロダクト、サービス、または所産の性質に関連する変数は以下のとおりである。
予測型 適応型
イノベーションの度合い
  • スコープと要求事項が十分に理解されている成果物
  • プロジェクト・チームが以前に取り組んだ成果物
  • 事前の計画が可能な成果物
  • 高度な技術革新を伴う成果物
  • プロジェクト・チームに経験がない成果物
要求事項の確実性
  • 要求事項が十分に把握されており、定義が容易
  • 要求事項が不確実、不安定、または複雑で、プロジェクト期間を通じて進化すると予想される。
スコープの安定性
  • 成果物のスコープが安定していて、変更される可能性が低い。
  • スコープに多くの変更があると予想される。
変更の容易さ
  • 要求事項の確実性とスコープの安定性に関連して、成果物の性質上、変更の管理と組み込みが難しい。
  • 変更に容易に適応できる。
デリバリー・オプション
  • 大規模なプロジェクト
※そのうち一部は、部分的および漸進的に開発して提供することができる。
  • 部分的に開発したり提供したりできるプロダクト、サービス、または所産
安全要求事項
  • 厳格な安全要求事項のあるプロダクト
※すべての安全要求事項を特定し、計画し、作成し、統合し、テストするために、事前に綿密な計画を立てる必要があるためである。
規制
  • 厳しい規制監督を伴う環境
※要求されているプロセス、文書、デモのニーズがあるため、予測型アプローチの使用が必要になることがある。
  • リスク
リスクが高い その他
  • 開発アプローチを選ぶ前に分析する必要がある。
  • 脅威を低減するために、事前に綿密な計画と厳格なプロセスが必要になることがある。
  • モジュール化して構築すること、および学習に基づいて設計と開発を適応させることでリスクを低減し、新たな工期を利用したり脅威にさらされる可能性を減らしたりすることができる。

3.4.2 プロジェクト

  • 開発アプローチに影響を与えるプロジェクト変数は以下のとおりである。
予測型 適応型
ステークホルダー
  • プロセス全体を通じてステークホルダーの顕著な関与が必要。
  • プロダクト・オーナーなどの特定のステークホルダーは、作業の確立と優先順位付けにおいて重要な役割を果たす。
スケジュールの制約条件
  • 完成品でなくても、早い段階で何らかのものを提供する必要がある場合に有効
資金調達の可能性
  • 資金調達に不安のある環境で実施されるプロジェクト

3.4.3 組織

  • 開発アプローチに影響を与える組織変数は以下のとおりである。
予測型 適応型
組織構造
  • 多くの階層、厳格な報告体系、および硬直的な官僚主義を伴う組織構造
  • フラットな構造を持ち、自己組織化されたプロジェクト・チーム
文化
  • 管理と指示の文化を持つ組織
  • プロジェクト・チームの自己管理を重視する組織
組織能力
  • 経営層を始めとして組織全体でのマインドセットが必要
  • 適応型アプローチを成功させるには、組織の方針、働き方、報告体系、根本的姿勢のすべてが整合している必要がある。
プロジェクト・チームのサイズと場所
  • プロジェクト・チームが大きい。
  • ほぼバーチャルである
  • 7±2のプロジェクト・チームでより効果的に機能することが多い。
  • 一箇所に配置されたプロジェクト・チーム

3.5 ライフサイクルとフェーズの定義

  • プロジェクト・フェーズの種類と数は、デリバリー・ケイデンスと開発アプローチによって異なる。
  • ライフサイクルのフェーズの例は以下のものがある。
1 実現可能性 ビジネス・ケースが有効かどうか、および組織が意図した成果を実現する能力を持っているかどうかを判断する。
2 設計 計画と分析は、開発されるプロジェクト成果物の設計につながる。
3 構築 統合品質保証活動を伴った成果物の構築を行う。
4 テスト 成果物の最終的な品質のレビューと検査は、顧客による移管、稼働開始、または受け入れの前に実施される。
5 展開 プロジェクト成果物の使用を開始し、維持、ベネフィットの実現、組織のチェンジマネジメントに必要な移管活動を完了する。
6 終結 プロジェクトが終了し、プロジェクトの知識と作成物がアーカイブされ、プロジェクト・チームのメンバーが離任し、契約が終了する。
  • プロジェクト・フェーズでは、多くの場合、フェーズ・ゲート・レビューを行い、フェーズの望ましい成果または完了基準が達成されていることを確認してから次のフェーズに進む。

3.6 デリバリー・ケイデンス、開発アプローチ、およびライフサイクルの整合性

デリバリー・ケイデンス 開発アプローチ
1回だけ提供 予測型
複数回提供 反復型、漸進型
定期的提供 適応型
  • 上記に基づくライフサイクルの案
ライフサイクル 開始基準 成果 完了基準
スタートアップ ビジネスケースが承認され、プロジェクト憲章が承認されていること
  • 概要レベルのロードマップの作成
  • 初期の資金調達要求事項の設定
  • プロジェクト・チームと資源要求事項を定義
  • マイルストーン・スケジュールの作成
  • 調達戦略の経計画を定義
開始時点のフェーズ・ゲート・レビューでレビューされる。
計画
  • 設計文書
  • ギャップ分析
  • 初期のワイヤーフレーム
計画フェーズ・ゲート・レビューでレビューされる。
開発 テスト・フェーズに入る前に、各成果物を個別にレビューすることがある。
テスト
  • 検査
  • ベータ版の提供
  • 小規模な試行
  • テスト環境での運用
展開フェーズに移行する前に該当するテストを受ける。
展開
終結
  • 各成果物についてのレトロスペクティブ(振り返り)や教訓の整理
  • さまざまなフェーズ・ゲート・レビューの情報と、ベースラインと比較したプロジェクト・パフォーマンスの全体的な評価
  • プロジェクト憲章とビジネス・ケースのレビューが行われ、成果物が目的のベネフィットと価値を達成したかどうか

3.7 他のパフォーマンス領域と相互作用

  • 開発アプローチとライフサイクル・パフォーマンス領域
    • 予測型ライフサイクルでは、事前の計画の大部分を行い、ローリング・ウェーブ計画法と段階的詳細化を使って計画を練り直し続ける。
  • 開発アプローチとデリバリー・ケイデンス
    • 規制要求事項を満たすことに伴うリスクが多い成果物では、予測型アプローチを選択して、追加のテスト、文書化、およびしっかりしたプロセスと手順を組み込むことができる。
    • ステークホルダーの受け入れに伴うリスクが多い成果物では、反復型アプローチを選び、最小実行可能プロダクトを市場に導入して、フィードバックを得てから追加のフィーチャーや機能を開発することができる。
  • 開発アプローチとライフサイクル・パフォーマンス領域
    • デリバリー・ケイデンスは、ビジネス・ケースとベネフィット実現計画書に沿って価値を実現する主な要因の一つ
    • プロダクト要求事項を引き出し、デリバリー・パフォーマンス領域に記載されている品質要求事項を満たすことは、開発アプローチに大きな影響を与える。
  • チーム・パフォーマンス領域と開発アプローチとライフサイクル・パフォーマンス領域
    • プロジェクト・チームの能力とプロジェクト・チームのリーダーシップ・スキルに作用し合う。
    • 予測型アプローチでは、通常、事前の計画、測定、コントロールに重点が置かれる。
    • 適応型アプローチでは、サーバント・リーダーシップ・スタイルがより必要であり、自己管理型のプロジェクト・チームになることがある。

3.8 結果のチェック

成果 チェック
プロジェクト成果物と一致する開発アプローチ 成果物の開発アプローチは、プロダクトの変数を反映しており、プロジェクトや組織の変数を考慮すると適切なものとなる。
プロジェクトの最初から最後まで、事業価値とステークホルダーへの価値を実現する複数フェーズで構成されるプロジェクト・ライフサイクル
  • 立ち上げから終結までのプロジェクト作業は、プロジェクト・フェーズで表される。
  • フェーズには、適切な完了基準が含まれる。
プロジェクト成果物の作成に必要な、デリバリー・ケイデンスと開発アプローチを促進するプロジェクト・ライフサイクルのフェーズ
  • 開発、テスト、および展開のケイデンスは、ライフサイクル・フェーズで表される。
  • 成果物が複数あり、異なるデリバリー・ケイデンスと開発方法があるプロジェクトでは、必要に応じてフェーズの重複やフェーズの繰り返しで表される。

引用

関連記事

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?