情報処理技術者試験

PMP学習ノート

Contents
  1. プロジェクトマネジメント・プロセス一覧
  2. プロジェクト統合マネジメント
  3. プロジェクト・スコープ・マネジメント
  4. プロジェクト・スケジュール・マネジメント
  5. プロジェクト・コスト・マネジメント
  6. プロジェクト品質マネジメント
  7. プロジェクト資源マネジメント
  8. プロジェクト・コミュニケーション・マネジメント
  9. プロジェクト・リスク・マネジメント
  10. プロジェクト調達マネジメント
  11. プロジェクト・ステークホルダー・マネジメント
  12. プロジェクト、プログラム、ポートフォリオ
  13. プロジェクトライフサイクル
  14. アジャイル
  15. 用語

プロジェクトマネジメント・プロセス一覧

10の知識エリア立ち上げ計画実行監視コントロール終結
①プロジェクト統合マネジメント・プロジェクト憲章の作成・プロジェクトマネジメント計画書の作成・プロジェクト作業の指揮、マネジメント
・プロジェクト知識のマネジメント
・プロジェクト作業の監視、コントロール
・統合変更管理
・プロジェクトやフェーズの終結
②プロジェクト・スコープ・マネジメント・スコープマネジメントの計画
・要求事項の収集
・スコープの定義
・WBSの作成
・スコープの妥当性確認
・スコープのコントロール
③プロジェクト・スケジュール・マネジメント・スケジュールマネジメントの計画
・アクティビティの定義
・アクティビティの順序設定
・アクティビティ所要期間の見積もり
・スケジュールの作成
・スケジュールのコントロール
④プロジェクト・コスト・マネジメント・コストマネジメントの計画
・コストの見積もり
・予算の設定
・コストのコントロール
⑤プロジェクト品質マネジメント・品質マネジメントの計画・品質のマネジメント・品質のコントロール
⑥プロジェクト資源マネジメント・資源マネジメントの計画
・アクティビティ資源の見積もり
・資源の獲得
・チームの育成
・チームのマネジメント
・資源のコントロール
⑦プロジェクト・コミュニケーション・マネジメント・コミュニケーションマネジメントの計画・コミュニケーションのマネジメント・コミュニケーションの監視
⑧プロジェクト・リスク・マネジメント・リスクマネジメントの計画
・リスクの特定
・リスクの定性的分析
・リスクの定量的分析
・リスク対応の計画
・リスク対応策の実行・リスクの監視
⑨プロジェクト調達マネジメント・調達マネジメントの計画・調達の実行・調達のコントロール
⑩プロジェクト・ステークホルダー・マネジメント・ステークホルダーの特定・ステークホルダー・エンゲージメントの計画・ステークホルダー・エンゲージメントのマネジメント・ステークホルダー・エンゲージメントの監視
前田和哉著 PMBOKの知識と手法がしっかりわかる教科書 P54 21.プロジェクトマネジメント・プロセス

プロジェクト統合マネジメント

プロジェクト憲章

プロジェクトの発足を正式に認可する文章

以下のようなものが記載される。

  • プロジェクトの目的や成功基準
  • 要求事項の概要
  • 主要な成果物
  • スケジュールや予算の概要
  • プロジェクト終了基準
  • プロジェクト・マネージャーの責任権限レベル
  • プロジェクト憲章を認可するものの名前

プロジェクトのイニシエーターまたはスポンサーが発行すべきであるが、その作成にプロジェクト・マネージャーが関与するのが望ましい。

プロジェクト憲章が発行認可されることで、プロジェクト・マネージャーはプロジェクトを計画し、実行し、コントロールする権限を持つことができる。

プロジェクトマネジメント計画書

プロジェクトマネジメントに関するすべての計画をまとめた計画書

プロジェクトの実行を管理するために使用される。

プロジェクトマネジメント計画書を作成する目的は、計画段階で意思決定した内容を文書化し、プロジェクトの実績測定基準となるベースラインを設定し、プロジェクトを遂行する上での指針を与えることにある。

プロジェクトベースライン

正式に承認されたプロジェクトの計画

プロジェクトの途中での実績評価はベースラインと対比して行われる。

重要なベースラインは以下3つ。

  1. スコープ・ベースライン(スコープ記述書、WBS、WBS辞書)
  2. スケジュールベースライン(マスター・スケジュール)
  3. コスト・ベースライン(予算化の結果として作成される)
    時間軸に対応させて認可済予算を積算したもん。プロジェクトのコスト実績の測定や監視に用いる。通常S字カーブを描く。

ベースラインの変更は正式な変更管理プロセスを通してのみ、行うことができる。

プロジェクト・スコープ・マネジメント

要求事項の収集

プロジェクトのスコープを定めるために必要な要求事項を収集し、文書化する。

要求事項をベースライン化するためには、明瞭性(測定とテストが可能なこと)、追跡可能性、完全性、一貫性を満たすように要求を定義してステークホルダーに受け入れてもらう必要がある。

要求事項は下記のように分類される。

  • ビジネス要求事項:プロジェクトを立ち上げるに至ったビジネス上の課題や好機など。
  • ステークホルダー要求事項:ステークホルダーのニーズ
  • ソリューション要求事項:プロダクト、サービス、所産の機能および特性
    機能要求事項:プロダクトの振る舞い
    非機能要求事項:プロダクトに求められる環境条件や品質
  • 移管及び準備状況への要求事項:成果物を移管するために必要なこと
  • プロジェクト要求事項:プロジェクトが満たすべきその他の条件
  • 品質要求事項:成果物が受け入れられるために必要な条件や基準

要求事項トレーサビリティ・マトリックス

プロジェクトを通して要求事項の追跡(トレース)を行う際に利用する。

プロジェクトを通して要求事項を追跡するための表で、要求事項ごとにその属性や理由、完了時期などを記録していく。

記載する項目は下記のようなものになる。

  • 要求事項
  • ビジネス・ニーズ
  • 目標
  • 設計
  • 開発
  • テスト

要求事項を追跡することの利点

  • 各要求事項をビジネス目標/プロジェクト目標に結びつけ、各要求事項が事業価値を確実に実現できるようにする。
  • プロジェクト完了時点で、承認された要求事項が達成されていることを確認できる。
  • プロダクト・スコープの変更をマネジメントする仕組みを提供する。

WBSの作成

プロジェクトの成果物及び作業を、マネジメントしやすい構成要素へとより詳細に分解してWBS(Worak Breakdown Structure)を作成する。

WBSの効果

  • 詳細なWBSを作成することで、コストやスケジュールの見積もりの単位が明確になり、精度の良い見積もりが可能になる。
  • 作業の責任分担が明確になる。
  • 実績を測定しコントロールするベースラインを決めるのに役立つ。
  • ステークホルダーが成果物を一覧する助けになり、コミュニケーションの円滑化に寄与する。

プロジェクト・スケジュール・マネジメント

アジャイル型プロジェクトのスケジューリング

オンデマンド・スケジューリング

「オンデマンド」とはユーザーに要求された時にサービスを提供すること。

オンデマンド・スケジュールは要求された時に提供を行うスケジュール技法のこと。

事前に作成したスケジュールに依存するのではなく、資源が利用可能になると、バックログの待ち行列から実施すべき作業を取り出す。(プル・システム)

カンバン方式が有名

CAP(コントロール・アカウント・プラン)

WBSではプロジェクトを管理する単位として「ワーク・パッケージ」を利用するがプロジェクトの規模によってはもう少し粒度の粗い単位で管理した方が良いこともある。

この場合に設定される管理単位をコントロールアカウント(CA)と呼び、コントロールアカウント単位に立てる計画をコントロールアカウントプランと呼ぶ

プレシデンス・ダイアグラム法(PDM:Precedence Diagramming Method)

Precedenceは「先行の」Diagrammingは「図式」という意味がある。

アクティビティ間の順序関係をネットワーク的な図式で表現したものをプロジェクト・スケジュール・ネットワーク図という。

PDMでは下記4つの順序関係が表現できる。(Fは「Finish」、Sは「Start」)

  • FS(終了ー開始)関係:先行の作業が終了しないと後続の作業が開始できない。
  • FF(終了ー終了)関係:先行の作業が終了しないと後続の作業が終了できない。
  • SS(開始ー開始)関係:先行の作業が開始しないと後続作業が開始できない。
  • SF(開始ー終了)関係:先行の作業が開始しないと後続の作業が終了できない。

PDMのアクティビティは下記のように表現する。

最早終了(開始)日:商用時間から見積もると、最も早く該当アクティビティを開始(終了)できる期日

最遅開始(終了)日:プロジェクトの終了期日からさかのぼると、遅くともこの日までに該当アクティビティを開始(終了)しなければならないという期日

フロート

フロート(Float)

プロジェクトの終了日を遅らせることなく、あるアクティビティの開始を遅らせることのできる期間。

Floatは「浮く、余裕時間」の意味がある。

トータル・フロート、スラックとも呼ぶ。

フリー・フロート(Free Float)

後続アクティビティの開始を遅らせることなく、あるアクティビティの開始を遅らせることができる期間

リードとラグ

リード(Lead)

後続アクティビティの開始を早め、先行アクティビティと期間的に重なり合わせる。

ラグ(Lag)

先行アクティビティの終了から、後続アクティビティが開始するまで一定期間を置く。

PERT(Program Evaluation Review and Technique)

所要時間の見積もりに、統計的推定を取り入れた三点見積もりを採用した手法

三点見積もりとは、金額や工数を「楽観値」「最可能値(最もありそうな値)」「悲観値」の三点で見積もること。

PERT加重平均値(所要時間の期待値)A=(O+4M+P)/6

  • A:平均値
  • O:楽観値
  • M:最可能値
  • P:悲観値

パーキンソンの法則

ノースコート・パーキンソンが提唱した法則

  • 仕事の量は、完成までに与えられた時間を全て使い切るまで膨張する。
  • 支出の額は、収入の額に達するまで膨張する。

プロジェクトのスケジューリングにおいて、作業者は作業バッファを与えると時間を使い切ってしまう傾向があることを頭に入れておく必要がある。

学生症候群

期限ギリギリまで作業を先延ばしにする傾向のこと。

資源最適化

資源平準化(Resource Leveling)

最早開始日をもとにスケジュールを作成すると、一定期間内に投入可能な量以上の資源が必要となることがある。

このとき、現実的なスケジュールを作成するために資源の投入を平準化する。

少ない資源を、まずクリティカルパス上のアクティビティに割り当てることで資源の制約条件を反映したスケジュールを作成することができる。

資源平準化を行うと、当初のスケジュールよりプロジェクト期間が長くなることが多い。

資源円滑化(Resource Smoothing)

あるスケジュールで資源の制約上限を越える時期が発生しているような場合に、クリティカル・パスを変更しないままフロートの範囲内でアクティビティの着手時期を調整する方法。

フロートが許す限りでの調整になるので、資源すべてを最適化できないこともあり得る。

クリティカル・チェーン法

特定の資源に依存している作業のつながり(クリティカル・チェーン)に着目した管理手法

特定の資源(ある特定の人でなければできない作業など)に依存する作業がある場合進捗遅れが生じやすい。

特定資源のスケジュール・バッファーが十分にあれば余裕があり、バッファーが少なれば進捗が遅れる可能性が高い。

ALAP(As Late As Possible)

「可能な限り遅く」という概念で、クリティカル・チェーン法を用いる時に適用する。

最終終了日から逆算したスケジューリングを行うことで、資源のバッファーを確保する。

コンティンジェンシー許容値

「contingency」は「万一」「偶発」といった意味がある。

コンティンジェンシーに関する不確実性はプロジェクトの進行とともに減少する。

プロジェクトの集結に向けてコンティンジェンシー許容値も残作業の割合を反映し、減少させる。

What-If シナリオ分析

「仮説を立てたシナリオが発生した場合にどうなるのか」を考えていく分析手法

シナリオがどの程度の確率で発生するか、発生した場合の影響度がどのくらいかを分析する。

プロジェクト・コスト・マネジメント

機会コスト(オポチュニティーコスト)

ある意思決定をした時、その他のやり方をとっていたら得られたであろう利益のこと。

矛の利益を取り損なったと考え、逸失利益と呼ぶこともある。

A案であれば100万円の利益、B案であれば80万円の利益、両方はできないためA案を選択した時、B案で得られるはずだった80万円が機会コストとなる。

選択肢なかったB案の機会コストを考慮することで、選択されたA案の意義や求められる利益が明確になる。

パラメトリック見積もり

数学的モデルを利用してプロジェクトのコストを見積もる。

COCOMOモデル、Putnamモデル、ファンクションポイント法による見積もりなどがこれに当たる。

COCOMOモデル

数式を使って開発工数を見積もる。数式は複数存在する。

E(開発工数)=a(定数)*KLOC(ソースコードの行数)のb乗(定数b)

Putnamモデル

ソフトウェア開発のコンサルティング会社を経営していたプットナムによって提案されたソフトウェア開発の見積もり方法の一つ。

大規模、超大規模プロジェクトに向けた見積もり手法

数式で、ステップ数や走行数の算出が可能

ファンクションポイント法

ソフトウェアの機能ごとに、その複雑さからファンクションポイントという点数をつけていきポイント合計から規模や工数を算出する。

ボトムアップ見積もり

WBSに詳細に展開した個々のアクティビティ、あるいはワーク・パッケージ単位でコストを見積もり、それらを集計してプロジェクト全体のコストを算出する。

予備について

コンティンジェンシー予備

基地のリスクに対して備えておく予備で「既知の未知」とも呼ばれる。

プロジェクトのコスト・ベースラインに組み込まれている。

リスク登録簿で特定されたリスクが計画外の現象として発生した時に、そこで必要となる諸変更を実施するための費用の引当金

マネジメント予備

計画時に予見できないような未知のリスクに備えておく予備費で「未知の未知」とも呼ばれる。

コスト・ベースラインには含まれておらず、マネジメント予備を使用する際には承認手続きを経てコスト・ベースラインを変更する必要がある。

アーンド・バリュー・マネジメント(EVM)

基本データ

データ名意味
PV(Planned Value:計画価値)ある時期までにプロジェクトに割り当てられた計画予算、経過口に経営者承認済の変更を加えたベースライン。
AC(Actual Cost:実コスト)ある時期までにプロジェクトのために支出された費用の累計値で、直接費、間接費を含む。
EV(Earned Value:達成価値)ある時期までに着手した作業に割り当てられていた承認済み予算の合算値。単純な場合は、総予算に作業進捗率を掛けた値となる。

EV分析による指標値

指標名計算式意味
CPI(Cost Performance Index)コストパフォーマンス指数CPI=EV/ACある時期までに着手した作業に割り当てられていた予算値と実際に支出されたコストの比率。この値が1より大きいとコストは予算内である。
SPI(Schedule Performance Index)スケジュール効率指数SPI=EV/PVある時期までに着手した作業に割り当てられた予算値と当初計画値とのコスト比率。この値が1より大きいとスケジュールは守られている。
CV(Cost Variance)コスト差異CV=EV-ACある時期までに実際に着手した作業に割り当てられていた予算値と、その時期までの費用支出学との差。この値がプラスだとコストは予算内である。
SV(Schedule Variance)スケジュール差異SV=EV-PVある時期までに実際に着手した作業に割り当てられていた予算値と、当初計画されていたその時期までの予定費用との差。この値がプラスだとスケジュールは守られている。

予測指標値

指標名計算式意味
BAC(Budget At Completion)完成時総予算-プロジェクト完成までに使用することを予定した総予算(プロジェクト完成時点におけるPV)
Budgetは「予算」の意味
EAC(Estimate At Completion)完成自総見積もりEAC=AC+(BAC-EV)/CPIプロジェクトの途中で見積もった、プロジェクト完成時点で支出されると予想されるコストの見積額
Estimateは「見積もり」の意味
VAC(Variance At Completion)完成時差異VAC=BAC-EACプロジェクトの途中で見積もった、プロジェクト完成時点での予算と見積もりとの差異
ETC(Estimate To Completion)残作業見積もりETC=EAC-AC現時点からプロジェクト完成時までに必要なコストの見積額

残作業効率指数:TCPI(To-Complete Performance Index)

残りの作業で達成すべきコスト効率を示す指標

BACに基づくTCPI:TCPI=(BAC-EV)/(BAC-AC)
EACに基づくTCPI:TCPI=(BAC-EV)/(EAC-AC)

EACが求められている場合は、EACに基づくTCPIが優先される。

プロジェクト品質マネジメント

品質の定義

「本来備わっている特性の集まりが、要求事項を満たす程度」

「どのくらい要求事項をみたしているの?」というのが品質

顧客満足

顧客満足には以下2つが必要となる。

要求事項適合性

要求された仕様通りに作られていること

使用適合性

プロダクトやサービスは真のニーズを満足させる必要がある。

エンドユーザーにValue(本当の価値)を提供できていること。

品質と等級

等級とは「同一の用途であっても技術的特性が異なる成果物に定めた区分」のこと。

等級が低いものは受け入れられるが、品質の低いものは受け入れられない。

(例)高級車も一般車も「人を乗せて走る」という点では品質を満たしているが、加速や乗り心地に差がある(技術的特性が異なる)。これが等級である。

品質方針

プロジェクトが適応すべき品質に関するガイドラインであり、組織のプロセス資産に含まれる項目である。

品質方針はトップマネジメントによって公式に表明されるべきであり、品質計画プロセスのインプット情報となる。

一般的にプロジェクトにおいては母体組織の品質方針をそのまま採用する場合が多い。

母体組織が品質方針を持たない場合には、プロジェクトマネジメントチームが品質方針を設定する必要がある。

ベンチマーキング

品質マネジメントの計画を行う際の、データ収集方法の一つ

現在のプロジェクトのやり方を、過去の類似したプロジェクトにおけるやり方と比較して、改善策を考えたり、パフォーマンスを測定したりすること。

元々は、靴修理の職人が修理の際、顧客の足を測定することをベンチマーキングと呼んでいた。(顧客の足を「ベンチ」にのせ、マーキングしていた。)

統計的サンプリング

検査対象用の母集団から一部だけ抽出(サンプリング)してその一部の情報から全体を推定する方法

±2σ(母集団の95.44%いないであれば適合)と判断したり、±3σ(母集団の99.73%いないであれば適合)と判断したりする。

計数サンプリング

サンプリングによる適合の判定で、検査の対象となる各ユニットの特性が存在するかしないかに注目する品質測定方法

Yes、Noで答えられるもの。

例えば、身長が100cm以上かどうかという特性にはYes、Noで答えられる。

計量サンプリング

サンプリングによる適合の判定で、適合の度合いについて連続的尺度を用いて測定した結果の等級付けをする方法

例えば、身長が「100未満」「100〜150」「150〜200」「200以上」のように等級が付けられる。

品質コスト

品質コストとは、製品やサービスの品質を達成するために費やされるコストのこと。

一般に、誤りを予防するコストは、検査または不具合を修正するコストに比較するとはるかに少ない。

予防コスト(prevention cost)

品質問題の発生を事前に防止するコスト

品質計画、レビュー、品質システム監査、訓練など

評価コスト(appraisal cost)

製品の適合度を評価するのに必要なコスト

テストなど

内部不具合コスト(internal failure cost)

手直しや廃棄などにかかるコスト

外部不具合コスト(external failure cost)

検査や返品などにかかるコスト

デザイン・フォー・エックス

設計時に製品のライフサイクルの各段階を考慮しながら、設計を進める手法

エックスはライフサイクルの各段階のことで、複数のエックスを考慮に入れて設計する。

設計段階で後のこともしっかり考えるのでコスト削減などの効果が期待できる。

具体的には、組立容易性、環境負荷性、製造容易性、保守容易性、リサイクル性などがある。

品質報告書

開発中や提供中のシステムが、どの程度品質を保証品質を保証できているかを報告する資料

品質マネジメントのアウトプットとして作成される。

システム全体の品質ではなく、システム開発の工程なども品質に含まれる。

プロジェクト品質の期待を満たすために是正処置をとることができる。

品質のマネジメント、品質のコントロール

「品質のマネジメント」プロセスは、組織の品質マネジメント計画を品質活動の実行に移すプロセスである。

「品質のコントロール」プロセスとは、作業結果が基準に適合っしているかを確認するために、作業結果をモニターするプロセスである。

両方ともプロジェクトのライフサイクル全体を通して実行すべきもの。

管理図

ITストラテジスト学習メモ参照

標準偏差

データが平均値の周辺でどの程度バラついているのかを表す指標

±σ:全体の68.26% のデータが含まれる。

±2σ:全体の95.44%のデータが含まれる。

±3σ:全体の99.73%のデータが含まれる。

プロジェクト資源マネジメント

ハーズバーグの衛生理論

ハーズバーグは動機付け理論として、人のやる気の源泉を「衛生要因」と「動機要因」の2つに分けて説明する。

衛生要因は不満足要因とも言われ、作業環境や給与など一定以上でないと不満が起こるという要素であり、一定限度以上を確保する必要があるが、必要以上にしても意欲の大きな向上にはつながらない。

同期要因は満足要因ともいわれ、達成感や自己成長など、満たされるほどやる気が出てくる要因で、その満足感には際限がない。

この理論では達成感のある職務設定こそ重要だということになる。

感情的知性(EI)

感情的知性とは、感情を冷静的に分析する能力で、自他の個人的な感情だけでなく、集団の共感度も特定、評価、マネジメントする能力である。

これを身につけることによって、効果的なチーム運営が可能になり、従業員の離職率の低下につながるとも言われている。

RACIチャート

ITサービスマネージャ学習ノート参照

コンフリクトマネジメント

撤退や回避

解決を諦め、対立の解決について議論することを放棄する。

解決にならないのでLose-Loseの関係になる。

鎮静や適応

意見の異なるところより意見の同じところを強調することで調和を図る。

一時的な対応で対立の先送りなので、結局はLose-Loseの関係になりやすい。

妥協や和解

双方が完全な解決を諦め、ある程度の満足で我慢する方法

双方とも不満が残るが一応の解決となる。

強制や指示

解決策を他方に押し付ける対立解消方法なので、一方的に押し付ける側がWin、押し付けられた側がLoseになる。

短期の解決策としては有効だが後に問題を生じる可能性があり、好ましくない。

マネージャーとしては最後に選択すべき手段

協力や問題解決

互いの一方的な主張だけではなく、異なった視点からのいろいろな見解も盛り込んで両者が納得できるような合意を得るように努める方法である。

うまくいけばWin-Winの関係につながる。

意思決定は早すぎたり遅すぎたりすると裁量の判断にならない。

プロジェクト・コミュニケーション・マネジメント

プロジェクト・リスク・マネジメント

プロジェクト調達マネジメント

プロジェクト・ステークホルダー・マネジメント

スコープ・クリープ

プロジェクト・スコープがコントロールされずに拡大すること。

プロジェクト、プログラム、ポートフォリオ

事業戦略があり、それを達成するためのポートフォリオがあり、ポートフォリオを達成するためのプログラムがあり、プログラムは複数のプロジェクトで構成されている。

プロジェクト

独自のプロダクト、サービス、所産(result)を創造するために実施する有機性のある業務

プログラム

関連プロジェクト、サブプログラムのかたまりのこと。

プロジェクト個別のマネジメントでは得られないベネフィット(便益)を得られる。

「ダイエットプログラム」などと同じ意味

ポートフォリオ

プロジェクト、プログラム、サブポートフォリオ、定常業務のかたまり

ポートフォリオマネジメントは組織の戦略的な目標を達成するためにポートフォリオ(何をやるのか)をマネジメントすること

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

プロジェクトの始まりから終わりまでにはいろいろな活動が連なっている。

この全体をプロジェクトライフサイクルという。

予測型(Predictive)ライフサイクル

ウォーターフォール型ライフサイクルとも呼ばれ、プロジェクトのスコープ、タイム、コストを初期フェーズで決定し、計画通りにプロジェクトを進めることを重視する。

反復型(Iterative)ライフサイクルと漸進型(Incremental)ライフサイクル

プロジェクト、フェーズにおいてアクティビティが何回か繰り返されるもの。

反復型では、一連の繰り返しの中で成果物が作られれ、漸進型では繰返しごとに継続的に機能が追加されていく。

適応型(Adaptive)ライフサイクル:アジャイル型

ステークホルダーを巻き込んで変化に追随しつつ、プロジェクトを進めるもの。

反復型、漸進型に比べて反復期間が短い。

スコープの定義が容易でないプロジェクトで、ステークホルダーに分割的な価値が提供できる場合に適している。

ハイブリッド型ライフサイクル

予測型ラフサイクルと適応型ライフサイクルの組み合わせ。

例えば全体的に予測型で進めつつ、不確定要素が多い部分だけ適応型とするなど。

アジャイル

イテレーション

設計、開発、テスト、改善などの一連の工程を短期間で繰り返す、開発サイクルのこと。

1つのイテレーションは1週間から4週間になる。

レトロスペクティブ

各イテレーションの終了時に行う振り返りのための場である。

そこでは、チームがもっと効率を高めることができるよう、自分たちのやり方を最適に調整する。

インセプションデッキ

プロジェクトの全体像(目的、背景、優位性、方向性)を端的に伝えるために伝えるためのドキュメント

プロジェクトの「Why」と「How」を明確にする。

自分たちはどうしてこのプロジェクトに取り組むのか、開発しようとしているプロダクトのコアとなる価値は何か、顧客に届けたい価値は何かといった質問に答えていくことで作成する。

プロジェクトの屋台骨を明確にし、共通認識を持つことによって迷った時の指針になる。

インセプションは「初め」「発端」、デッキは「床」なので、「初めの床」のようなイメージ

バックログ

まだ対応されていない要求事項の集まりのこと。

イテレーションを開始する前に、プロダクト・バックログから要求事項を取り出し作業対象とする。

要求事項がまだ妥当なものであるかを確認するために、(イテレーションの切れ目などで)バックログを定期的に見直すことが必要になる。

ユーザー・ストーリー

ユーザー・ストーリーは「誰(ステークホルダー)」が「なんのために」「何をする」ということを表現すること。

アジャイル型プロジェクトでは、成果物への要求事項をユーザー・ストーリーの形式で記述することが多い。

テンプレートとして「◯◯として、XXをしたいそれは、△△だからだ」がある。

(例)営業担当者として、顧客情報を出力したい、それは顧客情報の棚卸しをする必要があるからだ。

以下の6つの原則に従うと書きやすいとされている。

  1. Independent(独立している)
  2. Negotiable(交渉可能である)
  3. Valuable(価値がある)
  4. Estimable(見積もりができる)
  5. Small(小さい)
  6. Testable(テストできる)

エピック

ユーザー・ストーリーに落とし込む前の一歩手前のまとまった作業のこと。

用語

OPM(Organizational Project Management)

組織が適切なプロジェクトに取り組み、重要な資源を適切に割り当てられるようにすること。

ポートフォリオ、プログラム、プロジェクトを体型的にマネジメントすることができ、組織の戦略的なビジネス目標が達成できる。

「Organizational」は「組織の」という意味の英語

ビジネス・ケース(Business Case)

プロジェクトを開始する理論的な理由のこと。

以降のプロジェクトマネジメント活動を認可するかどうかを判断する根拠となる。

下記のような情報が文書化される。

  • ビジネス・ニーズ
  • 状況分析(組織の戦略や目標、重要成功要因、既知のリスクなど)
  • 評価(どのようにしてベネフィットが得られるようになるか)

ベネフィット・マネジメント計画書

プロジェクトのベネフィットがいつどのように実現するかを説明し、ベネフィットの測定を実現するためのメカニズムを説明する文書

下記のような情報が記載される。

  • 目標ベネフィット(得られる有形、無形の価値)
  • 目標ベネフィット実現の時間枠
  • ベネフィット・オーナー(監視・記録・報告を行う責任者)
  • 評価尺度
  • 前提条件
  • ベネフィット実現のリスク

プロジェクトの成功を評価するためにプロジェクトが完了した後も参照され続ける。

ローリング・ウェーブ計画法

プロジェクトマネージャ学習ノート参照

モンテカルロ・シミュレーション

システム的に乱数を発生させてシミュレーションを行うこと

名前の由来はカジノで有名なモナコの都市「モンテ・カルロ」

ノミナル・グループ技法

ブレーンストーミングに投票プロセスを付け加え、得点によって優先順位をつけたり合意を形成する。

要求事項の収集プロセスの技法の一つ。

ノミナル(nominal)は「名ばかりの」「有名無実の」といった意味になる。

点数によって名ばかりでも優先順位を決めようという技法でもある。

プロジェクト・スケジュール・ネットワーク図

各アクティビティの依存関係を表示したもの。

アクティビティを全て書き出して、開始から終了まで、アクティビティの前後か関係を図にする。(Aが終わったらBの作業に着手できるなど)

ABOUT ME
hazukei
「はずけい」と申します。 この度一児の父となりました。まだ実感はわかないのですが、猛烈に忙しくなりそうです。楽しみつつ頑張りたいと思います!