プロジェクトマネジメントのフレームワーク
A. プロジェクトマネジメントフレームワークとは
プロジェクトマネジメントのフレームワークとは、プロジェクトの開始から完了までプロジェクトを企画し、計画し、実行するためのツール、タスク、プロセスをまとめたものです。言い換えれば、フレームワークはプロジェクトを首尾よく計画し、管理し、コントロールするために必要なすべてを要約したものと言えます。I
標準的なプロジェクトマネジメントのフレームワークは、主に3つのバケットに分けることができます:
- プロジェクトライフサイクルの要約 ウォーターフォールとアジャイル手法の主な違いは、フレームワークに異なるライフサイクルが含まれていることです。例えば、ウォーターフォールのフレームワークは、次の5つの標準フェーズが含まれています:初期
- 計画
- 実行
- コントロールとモニタリング
- クロージャ
- その一方、アジャイルフレームワークは修正されたライフサイクルを使って、アジャイルの柔軟でインタラクティブな本質を表しています。
- テンプレート、チェックリスト、およびその他のツール。 プロジェクトのフレームワークには、プロジェクトを効果的に配置するために必要な情報が含まれています。これにはタスクやアクティビティへの提案や、プロジェクト文書の草案を作成するリソースが含まれます。
- プロセスとアクティビティ 各フレームワークはフォローすべきプロジェクトのプロセスをやや異なった方法で描いているため、各プロジェクトにはそれに合ったフレームワークを選ぶ必要があります。例えばアジャイルフレームワークの多くで説明されている標準アクティビティとは日々のミーティングを意味します。
プロジェクトマネジメントのフレームワークの目的は、明確で一貫したプロジェクトの概要を提供することです。これによってチーム全体また会社全体で、信頼のおける反復可能なプロジェクトの実行が保証されます。フレームワークによっては、関係者全員に役立つよう、ベストプラクティスを文書に残して共有します。また1つの企業が立ち上げた建設プロジェクトが別の企業のプロジェクトの同様のものになるよう、組織や業界の共通基準を構築します。
PMBOKガイドでは、プロジェクトマネジメントのフレームワークはプロジェクトマネジメントを理解するための基本構造であると説明しています。複数のフレームワークが利用できることにより、プロジェクトマネージャーは自身のプロジェクトに最も適したフレームワークを選ぶことができます。自身のプロジェクトに適したフレームワークの選び方は、以下のF項で説明しています。
手法とフレームワークの違いとは何でしょうか?
手法ではプロジェクトマネジメントの原理、バリュー、フォローすべきベストプラクティスを説明していますが、フレームワークはその実行方法を予測しています。言い換えれば、手法では何を達成したいかを説明し、フレームワークではその達成方法を説明しているのです。
例えば「リーンとアジャイルの原理」では、変化に対処することが重要であると書かれているかもしれませんが、変化への対処方法は説明されていません。対処方法はフレームワークで説明されています。
B. アジャイルフレームワークが持っている共通点とは
アジャイルプロジェクト手法は、プロジェクトの編成に4つの主なピラーと12の原則を使用するアプローチです。すべてのアジャイル手法に共通するものは、これらのピラーと原則を達成するようデザインされていることです。
アジャイルプロセスのフローが他のプロジェクトマネジメントアプローチの中で際立っている理由は、インタラクティブ開発、柔軟性、継続的なフィードバックに重点を置き、さらにプロセスよりも人を重視している点です。そのため、アジャイル手法はこれらの主なバリューの上に構築されなければなりません。
各フレームワークはそれぞれ独自の面を持っていますが、すべてのフレームワークはプロジェクトマネジメントの基本に従っており、プロジェクトが成功を収めるように構築されています。アジャイルフレームワークは一般に文書やルールを最低限に抑えるようにデザインされており、従来のフレームワークに比べて内容が軽くなっていますが、すべてのアジャイルプロジェクトフレームワークには、初期段階や計画段階をはじめとするプロジェクトの重要なプロセスとフェーズが含まれていなければなりません。
C. スクラムフレームワーク
最も一般的なアジャイル手法はなんであるかと聞かれれば、ほとんどの人はスクラムフレームワークであると答えるでしょう。
スクラム手法は1990年代に開発され、「The New New Product Development Game」というハーバードビジネスレビューの記事をベースにしています。
他のアジャイルフレームワークと同様に、スクラムはプロジェクトマネジメントに対して反復アプローチを取っています。スクラム手法ではプロジェクトを4つのsprintに分けており、各sprintの期間は通常1週間から4週間です。各sprintの目的はプロジェクトの最終成果物の作業可能なバージョンまたはドラフトの完了です。
担当チームが短い反復を使用するスクラムプロジェクトマネジメントアプローチでは、チームは最終プロダクトの作業バージョンを頻繁に提供できます。
スクラムは開発当初、一連の役割や責任分担、およびミーティングに従ったソフトウェアモデルを使用して設計されましたが、その柔軟性からあらゆる業界の複雑なプロジェクトでも使用することができるようになりました。しかしながらサービスよりも具体的なプロダクトを取り扱うプロジェクトの方が、その威力を発揮します。
スクラムは内容が軽く柔軟性があると言われていますが、習得は困難です。そのフレームワークは、3つのピラーをベースにしています:
- 透明性。共通の言語と定義を使用しなければなりません。
- 検査。スクラム「アーティファクト」とプロダクトは定期的にしっかりとチェックし、その品質を確認します。
- 適合。チェックの際に品質が基準を満たしていなことが確認されれば、チームはできるだけ早く修正および訂正できます。
アジャイル手法のスクラムには以下を含む役割と責任が必要です:
- プロダクトオーナー プロジェクトのプロダクトオーナーは顧客の最善の利益を代表し、最終プロダクトに何が含まれるかを決定する権限を持っています。プロダクトの要件や機能、優先事項が理解され、達成されているかを確認するのはプロダクトオーナーの責任です。
- スクラムマスター。スクラムマスターは日々のミーティングを設定し、チームの意思疎通を改善し、生産性を最大化する責任を持つファシリテーターです。プロダクトマネージャーとスクラムマスターの違いは、定義上、スクラムマスターは
サーバントリーダーであることに重点が置かれています。アジャイルのプロジェクトマネージャーの役割にはスクラムマスターとしての業務が含まれていることが多いですが、チーム内にスクラムエキスパートや優秀なファシリテーターがいる場合はスクラムマスターに指名することもできます。 - 開発チーム。開発チームとは貴社のスクラムプロジェクトチームを指し、本質的には自己管理ができる部門間を超えたチームです。本チームには、最終プロダクトを設計し、作成し、テストし、リリースするために必要なメンバー全員が含まれています。
- スクラムチーム。スクラムチームには開発チーム、スクラムマスター、プロダクトオーナーが含まれています。
スクラムでも独自の用語を使用します。以下はスクラムフレームワークで一般に使用する重要な用語です。
- プロダクトのバックログ バックログとは最終プロダクトに含まれるタスクと要件のリストです。バックログの作成と管理はプロダクトオーナーの責任です。
- sprint。sprintはバックログに記載されている一連のタスクを完了する期間指定です。すべてのsprintの期間は同じで、通常2週間ですが、チームとプロジェクトのニーズによっては1週間から4週間になることもあります。
- バックログプラニング。バックログプラニングは、バックログに記されているタスクがどのスプリントに含まれるかを決定するプロセスです。このプロセスはアジャイルsprintプラニングとも呼ばれます。
- sprintのバックログ。現在のsprintに割り当てられたバックログの一部
- 日々のスクラム。スクラムプロジェクトチームは日々ミーティングを行い、過去24時間の進捗状況と今後24時間の予測、新しく出た問題について話し合います。本ミーティングは通常デイリースクラムまたはデイリースタンドアップと呼ばれ、15分程度で終了します。
- レトロスペクティブ。各スプリントの終わりにはレトロスペクティブと呼ばれるレビューミーティングを行い、チームはこれまでの進捗状況を見直し、次のsprintをどのように改善できるかについて話し合います。
- スクラムボード。チームはスクラムボードを使ってsprintバックログを確認し、管理します。ホワイトボードのような物理的なボード、またはプロジェクト管理ツール内のバーチャルボードでもかまいません。 ボードには通常「すること」「処理中」「完了」の3つの欄があります。バックログのアイテムが完了すると、ボード上で次の欄へ移動し、チームは現在のスプリントで何をしなければならないか、また作業がどのように進行しているかを確認することができます。
- アーティファクト。プロダクトのバックログ、sprintのバックログ、プロダクトのインクリメントが、プロジェクトにおける3つのスクラムアーティファクトです。プロダクトのバックログとスプリントのバックログは未処理の作業を示し、プロダクトのインクリメントは現在のスプリントで終了した作業を示しています。
D. 他に人気のあるアジャイルプロジェクトマネジメント方法
スクラムは最も人気のあるアジャイルプロジェクト管理手法ですが、これ以外にもオプションはあります。「アジャイル計画作成とはどういうもので、どれを選べばいいのだろうか」と思っていらっしゃるかもしれません。以下に5つのアジャイルプロジェクト管理手法をご紹介します:
1. かんばん
かんばんはプロジェクトを管理するためのシンプルでビジュアルな手法で、可視性に重点を置いています。アジャイルかんばんはもともとスケジューリング用の手法として設計され、プロジェクト内の作業と次の作業を確認し、「ジャストインタイム」な作業を可能にします。
かんばんは作業を細かく分類し、ワークフローに可視性を与えることに重点を置いています。かんばんのフレームワークは多くの点でスクラムに似ています。例えば、かんばんもまた作業の進捗状況の確認と追跡にボードを使用しています。このボードを使ってプロジェクトのタスクを「すること」「処理中」「完了」の3つのコラムに分類します。しかし、スクラムと異なる点は、かんばんボードはプロダクトのすべての作業を追跡しますが、作業を各スプリントに分割しません。
かんばんの利点はプロジェクトのボトルネックや無駄を認識し、待ち時間を削減できることです。
2. エクストリーム・プログラミング(XP)
アジャイルXPはもともと、アジャイルのソフトウェア開発プロジェクト用に設計されたアジャイルフレームワークです。スクラムと同様、このフレームワークは継続的開発と顧客への納品に重点を置いています。またスクラム手法と同様にインターバルやスプリントを使用します。
しかしながらアジャイルXPのフレームワークは工学原理に重点を置いており、以下に記載されたソフトウェア開発に固有の12のサポートプロセスを含んでいます:
- プラニングゲーム
- 小規模のリリース
- 顧客承認テスト
- シンプルなデザイン
- ペアプログラミング
- テスト駆動型開発
- リファクタリング
- 継続的統合
- 共同コード所有権
- コーディング基準
- メタファー
- 持続可能なペース
3. ユーザー機能駆動型開発(FDD)
ユーザー機能駆動型開発もまたソフトウェア開発におけるアジャイルフレームワークで、2週間おきにソフトウェアのモデルを作成するというアイディアに基づいています。各ソフトウェアモデルの機能にそれぞれ開発プランや設計プランが必要となり、他のアジャイルフレームワークに比べて文書の数が増えてしまうため、FDDはすぐれた設計やプラニング能力を備えたチームにより適していると言えるでしょう。
FDDフレームワークは、プロジェクトをベーシックで反復可能な5つのアクティビティに分割します:
- 全体的なモデルの開発
- 機能リストの作成
- 機能ごとのプラン
- 機能ごとのデザイン
- 機能ごとの構築
4. 動的システム開発方法論(DSDM)
動的システム開発方法論(DSDM)は、ソフトウェアを迅速に納品する業界共通のフレームワークへの需要から生まれました。DSDMの一部はリワークが必要となるため、開発変更は後にリバースが可能でなければなりません。XP、FDD、およびDSDMのフレームワークは、スクラムと同様にプロジェクトを小型のスプリントに分割します。
本フレームワークは、8つの主な原則がベースとなっています:
- ビジネスニーズに重点を置く
- 期限通りの納品
- コラボレート
- 品質の妥協無し
- 確固たる基盤から徐々に構築
- 反復的な開発
- 明確で継続的なコミュニケーション
- コントロールを実証
5. クリスタル
クリスタルは実際はアジャイル手法のファミリーで、クリスタルクリアー、クリスタルイエロー、クリスタルオレンジ、クリスタルレッドなどが含まれており、それぞれのクリスタル手法は独自のフレームワークを持っています。どの手法を選ぶかは、チームの規模やプロジェクトの優先事項、およびプロジェクトの重要度などによって決まります。プロジェクトでアジャイルの採用方法を決定する際は、各プロジェクトはプロジェクト独自の特性によってポリシーや実務、プロセスが多少異なることを認識することが重要です。
リーンプロジェクトとは何でしょうか?
リーンはしばしばアジャイルフレームワークのリストに含まれていますが、リーン開発は全く異なる手法です。リーンとアジャイルがしばしば同じグループに入っているのは、同じバリューを共有しているからです。例えば、リーンとアジャイルは共に変更に容易に対応する機能を強調しています。
リーン手法の主な原則には以下が含まれています:
- 無駄の排除
- 品質の向上
- 知識の構築
- コミットメントの先送り
- 迅速な納品
- 人を尊敬する
- 全体を最適化
E. アジャイルエピックの定義
アジャイルエピックの基本的な定義は、「大型のユーザーストーリーです」。これはかなり曖昧な表現で誤解を招くこともありますが、この定義は、プロジェクトとプロジェクトマネージャーに柔軟性を提供するためにあえて曖昧な表現を使用しています。
エピックが何かを理解するために、まず最初にそのユーザーストーリーを定義してみましょう。ユーザーストーリーとはユーザーが求めるものです。言い換えれば、お客様が求める成果と言えるでしょう。ユーザーストーリーは1つのプロジェクトsprint内に収まることが理想です。例えば、本の制作をする場合、各チャプターがsprint内に収まれば、それぞれのチャプターがユーザーストーリーとなります。
しかし1つのチャプターに8週間必要であればどうでしょうか?この場合は1つのsprint内で完成するにはユーザーストーリーが大きすぎるため、大型のユーザーストーリー、またはエピックと見なされます。
エピックには正確な規模を示すガイドラインはなく、その規模はチームのsprintの長さとプロジェクトのニーズによって異なります。
ここではテーマを定義することも重要です。テーマとはお互いに関連するユーザーストーリー、または1つにまとめられるユーザーストーリーを収集したものです。例えば、家を建てる場合、電気要件を1つのテーマでまとめ、構造要件を別のテーマでまとめます。
ストーリー、エピック、テーマとは、アジャイルチームがプロダクトバックログについてのディスカッションや計画の効率化に使用する用語です。例えば、プロダクトバックログの中に、1つのsprintに割り当てるには大きすぎるものがあるとします。これをエピックと呼ぶことで、sprintバックログの一部になる前に作業を分割しなければならないことを全員が理解できます。
同様に、複数の要件を1つのテーマ名でまとめれば、sprintバックログを容易に計画できます。最終的には、1つにまとめた要件を同じsprintに割り当てることでメリットが得られるのです。
要は、エピックプロジェクト管理とは実行可能な方法でバックログを管理するということなのです。要件が簡潔であり、1週間から4週間で達成できることを保証します。
エピックが持つ2つのメリットとは: are:
- エピックはバックログに含まれている、おおまかに定義された大きなアイディアをフォローします。まずエピックとして要件を記録し、プロジェクトが進行するにつれてその要件の精度を上げることができます。
- エピックはバックログアイテムの階層を構築します。エピックは本来のアイディアまたは要件としてバックログ内に記録され、それに関連するユーザーストーリーが要件を満たす製品の特徴を監視します。
エピックが抱える大きな問題の1つは、チームがエピックとストーリーを識別することに捕らわれすぎることです。もう1つの問題は、チームがストーリーから離れてエピックに気を捕らわれすぎたり、ストーリーに分割するためにエピックの評価や精度を上げる作業量が増えすぎることです。
結論としてはエピックはバックログのグループ化に役立つ手法であるということです。エピックの使用によってチームに問題が発生するようであれば、その使用を再評価する必要があります。
アジャイルエピックの定義とバリューについてさらに詳しくご覧いただけるKnowledge Hutによるビデオを、こちらからご覧ください。
F. プロジェクトマネジャーの正しいフレームワークを選ぶ一番いい練習方法
人気の高い6タイプのアジャイルプロジェクトフレームワークの中から、ご自身のプロジェクトに最適なフレームワークをどのように選べばいいでしょうか?
まず、すべてのプロジェクトに使用できるフレームワークというものはありません。フレームワークの使用には、個々のプロジェクトやチームのニーズを把握することが重要です。
ではここで、プロジェクトマネジメント協会のOrganizational Project Management Maturity Model(組織的プロジェクトマネジメント成熟度モデル)(OPM3)とImplementing Organizational Project Management Guide(組織的プロジェクトマネジメント導入ガイド)に基づいた、プロジェクトマネージャーによる7つのベストプラクティスをご紹介します。
- プロジェクトの規模とスコープの評価。長期に渡る大型のプロジェクトの場合は2週間のsprintに分割するのが困難なこともありますが、その一方、スコープの定義が難しく、時間と共に進化する可能性がある場合は、従来のフレームワークよりアジャイルの方が適していると言えるでしょう。
- プロジェクトの原動力の見極め。プロジェクトを開始する前に、ビジネスケースと組織にとってのバリューを理解することが重要です。このプロジェクトは組織にどのようなメリットをもたらすでしょうか?
- プロジェクトに対するクライアントの主要目標、期待される成果、優先度の理解
- 様々な手法の影響を受けるプロジェクトの原動力、目標、成果、優先度の見極め。プロジェクトの目標がなるべく経費を抑えることであれば、リーン手法が最も効果的であると言えるでしょう。顧客が詳細な記録文書を求める場合はFDDが最適かもしれません。
- プロジェクトに適していると思われる手法のリストを作成し、前ステップで説明された条件に従ってその適性を評価してください。シンプルな表を作り、各アジャイルフレームワークを上段に記載し、左側にすべての主な原動力や目標などを並べ、それぞれのフレームワークがその原動力をサポートするかどうかを判断してください。
- 原動力や目標、成果、優先度を最もサポートするフレームワークをお選びください。必ず達成すべき成果がある場合は、それを見逃さないように判断してください。最も低いリスクで最高の成果を挙げることのできるフレームワークを選択することが重要です。
- フレームワークを選択したら、それがどのように作動しているかを監視してください。アジャイルの重要なコンセプトは柔軟性と適応性です。選択した手法が求める成果につながっていない場合は手法を修正するか、または別の手法への変更も必要となります。
G. 無料のプロジェクトマネジメントツール
アジャイルプロジェクトの管理に使用するツールはすべてアジャイルプロジェクト管理ツールと呼ばれ、最もベーシックなフォームではホワイトボードや付箋紙を使用します。
しかしさらにすぐれた様々なデジタルツールの利用も可能です。アジャイルツールとその他のプロジェクト管理ツールの大きな違いは、スクラムやかんばんなどのアジャイルフレームワークに対応する能力です。
次に5つのタイプの無料アジャイルプロジェクト管理ツールをご紹介します:
- かんばんツール かんばんツールはオンラインのかんばんボードです。かんばんカードやスイムレーン、カラーなどを備え、プロジェクトに可視性を提供します。本ツールの基本バージョンは、ユーザー2名でボード2つまで無料でご利用いただけます。
- PipefyPipefyはかんばんスタイルのワークフローを構築して使用するためのツールです。事前設計されたテンプレートはありませんが、ご自身のワークフローを設計してカスタマイズする機能を備えています。本ツールは5名までのチームで無料でご利用いただけます。
- Wrike Wrikeはアジャイルおよび従来のプロジェクト管理フレームワークをサポートする、クラウドベースのプロジェクト管理ツールです。Wrikeの基本バージョンはチームメンバー5名まで無料でご利用いただけます。
- YodizYodizは完全にカスタマイズできる一体型のアジャイルプラットフォームです。フィールドレイアウトやボードレイアウト、ボードカラーなどをカスタマイズでき、ユーザー3名まで無料でご利用いただけます。
- Zoho SprintsZoho Sprintsはアジャイルチーム向けのクラウドベースのツールです。スクラムボードをはじめとするアジャイルプロジェクト管理機能を提供し、5つのプロジェクトでユーザー5名まで無料でご利用いただけます。