ファシリテートGの「のり」です。
今回は、PMBOK第7版のプロジェクト・パフォーマンス領域のうち、開発アプローチとライフサイクル・パフォーマンス領域の概要についてお話します。
まず用語の説明ですが、開発アプローチとはどのように成果物の開発を進めるかを意味します。そしてライフサイクルとは、プロジェクトが経由する成果物開発の開始から終結までの一連の工程を意味します。
この領域では、プロジェクト成果物の実現に最適な開発アプローチを選択しますが、開発アプローチごとにライフサイクルが異なるのがポイントです。
プロジェクトの開発アプローチには以下の3つの手法があります。
●予測型
ウォーターフォール型とも呼ばれ、何をいつまでにどのくらいお金をかけてという
計画部分をプロジェクトの初期に決めてしまい、あとはその計画に沿って開発を進
めていくという手法です。
予測型の特徴は以下です。
・「要件定義 ⇒ 外部設計 ⇒ 内部設計 ⇒ 開発 ⇒ 単体テスト ⇒
結合テスト ⇒ 総合テスト ⇒ 受入テスト」と工程を踏んで、
一番最後に完成したプロジェクト成果物をリリースします。
・基本的に直列で工程を進めるため、ある工程が完了したらそこへ後戻りすることは
ありませんので、もし出来上がったプロジェクト成果物が想定外だった場合の
修正コストが甚大となります。
・大規模なプロジェクト・定期的な更新プロジェクト・高品質を要求される
プロジェクトに向いています。
●適応型
いわゆるアジャイルと呼ばれる反復型(※1)と漸進型(※2)を組み合わせた手法です。
最初に、ユーザーの視点から機能を記述したもの(ユーザーストーリー)を集めて
バックログと呼ばれる要件や未対応作業の一覧を作成します。
バックログから優先度の高いバックログアイテムを取り出して固定長の期間で
「設計 ⇒ 開発 ⇒ テスト」を進めるスプリントを繰り返してプロジェクト成果物
をリリースします。
※1：「設計 ⇒ 開発 ⇒ テスト」を小さく繰り返して内容を洗練させていく手法
です。リリースは最後に1回だけ実施します。
※2：プロジェクト成果物を機能や部品ごとに分割して、分割したものを対象に
「設計 ⇒ 開発 ⇒ テスト」を繰り返して段階的に作成していく手法です。
分割したものごとにリリースを実施します。
適応型の特徴は以下です。
・一般的に2-3週間から2-3か月ほどの短期間でリリースを繰り返します。
・顧客価値を最大限に高めるため、プロジェクト成果物が完成間近であっても変更を
歓迎します。
・変更を歓迎するということで、要件が明確化されていないプロジェクト・顧客の
ビジネス状況により変更が発生するプロジェクトに向いています。
●ハイブリッド型
予測型と適応型を組み合わせて、両方のメリットを活かしながらデメリットを補って
いいとこ取りしてしまおうという手法です。
予測型と適応型のどちらに重きを置いているかで2つの考え方があります。
・予測型主導
設計とテストを予測型で行い、開発を適応型で実施します。
計画の実現にほとんどブレは無いものの想定外事象にしっかり対応したい場合、
継続的な機能追加や変更が見込まれる場合に適しています。
・適応型主導
プロジェクト初期に適応型で開発を進め、完成イメージが確定された時点で仕様を
再検討して予測型に切り替えます。
適応型を徐々に導入したい場合、予測型における仕様変更のリスクを軽減したい
場合に適しています。
★所感
筆者は予測型主導のハイブリッド型アプローチを採用したプロジェクトに携わった
ことがあるのですが、適応型のいいところを活かすことなく、いつの間にか完全な
予測型に変わっていました。
そのためアジャイルプロジェクトを成功に導くのは難しいというイメージを持って
います。
ちなみに私はその予測型主導のハイブリッド型アプローチを推進する立場ではなく、
同プロジェクト内別チームの傍観者でした。
座学の限りでは、アジャイルのエキスパートが1人以上必要、今回話題にして
いないCI/CD(継続的インテグレーション/継続的デリバリー)の仕組みが重要に思えます。
また、開発側と顧客側の双方でアジャイルの考え方についての理解が必要です。
前述の失敗したアジャイルプロジェクトでは、アジャイルのエキスパートは不在、
かつ出来上がった画面のスクリーンショットをファイルで渡してレビューする
というようにCI/CDの考慮も無かったため、少しでもそういう部分に目が向いていれば
結果が変わっていたかもれません。
開発アプローチとライフサイクル・パフォーマンス領域についてのお話は以上となります。
ファシリテートGでは本年も皆さまのご期待に応えるべく尽力いたしますので、
今後とも変わらぬご愛顧を賜りますようお願い申し上げます。
Comments