.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

計画 - スコープ・プロセスの主要な役割

  • 要求事項収集技法を使用して、
    • 計画会議
    • ブレーンストーミング
    • フォーカス・グループ
  • ステークホルダーと共にプロダクトの詳細を評価し、
    • 要求事項
    • 制約条件
    • 前提条件
  • スコープに関する記述を行う。
  • プロジェクト・スコープに関する記述を行う。
    • プロジェクト・マネジメントに含まれるもの
    • プロジェクト・マネジメントに含まれないもの
  • これらは、WBS作成の土台になる。
  • プロダクトをマネジメントするために、スコープを分解して、WBS作成する。

※ 計画プロセス群の肝(≒ SIだと要件定義などと呼ばれるフェーズ)。

プロダクト・スコープ

プロジェクト・スコープ

インプット・アウトプット

#プロセスインプットツールと技法アウトプット知識エリア
2スコープ・マネジメント計画プロジェクト憲章
プロジェクト・マネジメント計画書
  (p) 品質マネジメント計画書
  (p) プロジェクト・ライフサイクルの記述
  (p) 開発アプローチ
----------
組織体の環境要因
組織のプロセス資産
専門家の判断
・データ分析
  (p) 代替案生成
会議
スコープ・マネジメント計画書
要求事項マネジメント計画書
プロジェクト・スコープ・マネジメント
3要求事項収集プロジェクト憲章
(p) プロジェクト・マネジメント計画書
  ★スコープ・マネジメント計画書
  ★要求事項マネジメント計画書
  ・ステークホルダー・エンゲージメント計画書
(p) プロジェクト文書
  (p) 前提条件ログ
  (p) 教訓登録簿
  ★ステークホルダー登録簿
(p) プロジェクト・マネジメント・ビジネス文書(6)
(p) 合意書
----------
(p) 組織体の環境要因
(p) 組織のプロセス資産
・人間関係とチームに関するスキル
  (p) ノミナル・グループ法
  ・観察と対話
  ・ファシリテーション型ワークショップ
・データ収集
  (p) ブレーン・ストーミング
  ・インタビュー
  ・フォーカス・グループ
  ・アンケートと調査
  ・ベンチマーキング
・データ分析
  ・文書分析
・データ表現
  (p) 親和図法
  (p) マインドマップ法
・意思決定
  ・グループ意思決定技法
プロトタイプ
コンテキスト・ダイアグラム
グループ発想技法
要求事項文書
要求事項トレーサビリティ・マトリックス
4スコープ定義プロジェクト憲章
(p) プロジェクト・マネジメント計画書
  ★スコープ・マネジメント計画書
(p) プロジェクト文書
  (p) 前提条件ログ
  ★要求事項文書
  (p) リスク登録簿
----------
(p) 組織体の環境要因
組織のプロセス資産
専門家の判断
・人間関係とチームに関するスキル
  ・ファシリテーション型ワークショップ
・データ分析
  (p) 代替案生成
・意思決定
  (p) 多基準意思決定分析
プロダクト分析
プロジェクト・スコープ記述書
プロジェクト文書更新版
  (p) 前提条件ログ
  ・ステークホルダー登録簿
  ・要求事項文書
  ・要求事項トレーサビリティ・マトリックス
5WBS作成(p) プロジェクト・マネジメント計画書
  ★スコープ・マネジメント計画書
(p) プロジェクト文書
  ★要求事項文書
  ★プロジェクト・スコープ記述書
----------
組織体の環境要因
組織のプロセス資産
専門家の判断
要素分解
スコープ・ベースライン
  ・WBS
  ・WBS辞書
プロジェクト文書更新版
  (p) 前提条件ログ
  ・要求事項文書
  ・プロジェクト・スコープ記述書
  ・プロジェクト・マネジメント計画書
  ・その他のプロジェクト文書

スコープ・マネジメント計画

インプット

  • プロジェクトの背後の環境・目的を理解する。

プロジェクト憲章

スコープに影響

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

組織体の環境要因

スコープの管理方法に影響

  • 市場の状況
  • 組織の
    • 文化、人事管理
      • 人的資源の上申のスキル、知識、能力
    • 経済な状況
    • インフラストラクチャー
      • 物理的
      • 技術的

組織のプロセス資産

  • スコープの管理方法に影響
  • 方針・ガイドライン、手順
    • 組織の
    • 業界の
  • 過去の情報
    規模とスコープが類似している過去のプロジェクト。

プロセス(ツールと技法)

専門家の判断

  • 上級管理職(立上の人物/組織)
  • プロジェクト・スポンサー
    (オーナー、イニシエータ、顧客であることもある)
  • 業界の専門家
  • 専門的な訓練を受けたチーム・メンバ
  • 類似プロジェクトの経験のあるPM

会議

スコープ・マネジメント計画書に含める内容を会議で決定する。

アウトプット

スコープ・マネジメント計画書

  • スコープ決定のプロセスを記述する。
    • スコープの定義方法
    • スコープの検証方法
    • スコープの制御方法
    • スコープの変更方法
  • プロセスの相互作用と依存関係から、
    変更の監視・制御の方法を記述する。

要求事項マネジメント計画書

  • プロジェクト全期間に渡って要求事項を
    分析/文書化/追跡/報告/マネジメントする方法を記述する。
  • このプロセスの鍵は要求事項のマネジメントにある。
  • 例:
    • 直列関係:フェーズの開始時に要求事項が完成している必要がある。
    • 並列関係:段階的に詳細化されるため、開始時に完全に定義されない。
  • プロセスの相互作用と依存関係から、
    変更の監視・制御の方法を記述する。
  • 構成要素
  • 要求事項の各アクティビティの実行方法
    • 計画アクティビティ
    • 追跡記録アクティビティ
    • 報告アクティビティ
  • 要求事項の
    • 優先度付
    • 追跡に使用される評価基準
    • 変更の要求/追跡記録/分析
      (他のコンフィグレーション・マネジメントのアクティビティとともに)
  • トレーサビリティ・マトリックス
    • 含める要素
    • 要素の属性

要求事項収集

  • ステークホルダーの関心・期待、ニーズ、要望(要求事項)
    を理解するため、要求事項を収集・定量化し、文書化する。
  • ここでは、まず、スコープに含まれるものを収集する。
  • 収集された要求事項をプロジェクトに含めるかどうかは次のプロセスで決定する。

インプット

  • ステークホルダーの関心・期待、ニーズ、要望(要求事項)
    を理解するため、要求事項を収集・定量化し、文書化する。
  • 要求事項
  • 測定 / 追跡 / テストが可能であるものであること。
  • 以下のカテゴリーがある。
    • ビジネス
    • ステークホルダー
    • ソリューション
    • 機能
    • 非機能
    • 移行
    • プロジェクト
    • 品質

プロセス(ツールと技法)

  • コミュニケーション・スキルが重要になるプロセス。
    • 心を読む力
    • 要求事項を引き出す的確な質問を投げかける。
  • (バリュー・チェーン中の)
    ビジネス・プロセスのオーナー
    • 中間管理職やライン・マネージャ
    • ライン(製造)以外のビジネス・エキスパート

インタビュー

  • 一対一の会話
    • 質問
    • 回答を記録
  • 対象を絞って短時間で多くの情報を入手できる。
    • 特性・機能に詳しい特定の分野の専門家
    • 経験豊富なチーム・メンバ

フォーカス・グループ

  • 訓練を受けたモデレータによって行われる。
  • 参加者の選定が重要になる。
    • 特定の分野の専門家
    • ステークホルダー

ファシリテーション型ワークショップ

  • 様々な機能部門のステークホルダーが参加する。
  • ファシリテーション型のフォーラムで
    複数の部署に影響を及ぼす要求事項に関する討議・定義。
  • IT業界:JAD(共同アプリケーション設計・開発)
  • 概要
    システムの利用者が開発の初期段階から参加し、要望を反映させる。
  • 参加者:機能部門のステークホルダー
  • 製造業界:QFD(品質機能展開)
  • 概要
    品質保証や製品企画、顧客満足やマーケットインを実現するための方法論。
    • 製造者と顧客の考えの関係をチェックして、ミスマッチを減らす。
    • 特性値とそれを実現するための工程や、製造条件、等の関係を決める。
  • 参加者
    • 顧客
    • ビジネス分野の専門家

グループ発想技法

  • 技法
  • ブレーン・ストーミング
    • アイデア・マップ法
    • マインド・マップ法

※ 各技法についてはリスク特定プロセスで説明

グループ意思決定技法

  • 投票
    • 満場一致
    • 過半数
    • 相対多数(過半数に達しない場合)
  • 独裁(1人がグループを代表して意思決定)

アンケートと調査

  • 大規模な母集団
  • 素早い情報収集
  • 結果の統計分析

観察と対話

  • 作業観測
    観察者がプロダクトを使用した作業を観察する。
  • 参加型オブザーバー
    観察者 自身が作業者になる。
  • 通常、作業者が気が付かない要求事項を発見できる。

プロトタイプ

ベンチマーキング

  • 基準値と測定値を比較してパフォーマンスを測定する。
    • ベストプラクティスの精緻化
    • 慣行の改善のためのアイディア創出
  • 測定対象
    • プロセス
    • 定常業務
    • マネジメント
  • 基準値
    • 他部署
    • 他組織
    • 他業界

コンテキスト・ダイアグラム

  • アクターとビジネス・プロセス(機器)の相互作用の視覚化する。
  • UMLダイアグラムで言う所の、コンテキスト図に該当する。

文書分析

  • 組織のビジネス計画
  • マーケティング計画
  • 契約、ビジネス規則
  • 戦略計画

アウトプット

要求事項を文書化する。

  • プロジェクトが長期化すると
    • ステークホルダーは要求事項を忘れる。
    • また、要求事項は段階的に詳細化される。
  • 従って、文書化してステークホルダーからの承認を得ることが重要。
  • これをベースにプロジェクト全期間に渡って要求事項を分析/文書化/追跡/報告/マネジメントする。

要求事項文書

  • 要求事項が要求事項文書に記録される。
  • また、ステークホルダーの署名が必要になる。
  • 構成要素
  • プロジェクト
    • のビジネス・ニーズ
    • の達成したいビジネス目標
    • が選定された理由
  • 各種要件
    • 機能要件
    • 非機能要件
    • 品質要件
  • 受入基準
    発注元の要件を満たすか。
  • 引渡要件
    発注元の定常業務・エンドユーザの要件を満たすか。
  • サポートとトレーニングに関する要件
  • その他
    • ビジネス規則
    • 制約条件
    • 前提条件
#要求事項内容
1ビジネス要求事項課題・好機など組織のハイレベルなニーズとPJ採用理由
2ステークホルダー要求事項ステークホルダー(グループ)のニーズ
3ソリューション要求事項プロダクト・スコープ
3-1機能要求事項機能要件
3-2非機能要求事項非機能要件
4プロジェクト要求事項プロジェクト・スコープ
5品質要求事項[[スコープ妥当性確認>]]に必要な条件や基準
6移管および準備状況への要求事項TO-BEを定常業務化するためのデータ移行、トレーニングなどの要求事項(移行計画的な)

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

  • ココで記録・文書化するモノ
    • 要求事項の発生源
    • 要求事項の追跡の基準
  • これにより、追跡を引渡 or 完了まで継続する。
  • 記述項目
    マトリックスと言うよりリスト?
  • ID
  • 要求事項の説明(要求事項名)
    短な、要求事項を特定可能な情報
  • テスト・シナリオ
    要求事項のテスト方法とフェーズ
  • 優先度
  • オーナー
    要求事項のオーナー、合否判定も行う。
  • 状態
  • IPAの例、こちらの例はVモデルに準拠。
    • 要求仕様
    • システム設計書
    • 基本設計書
    • 詳細設計書
    • ソースコード
    • 単体検査仕様書
    • 結合検査仕様書
    • システム検査仕様書
  • これにより、
    • 要求事項がプロジェクト目標、ビジネス目標にリンクされる。
    • プロジェクト完了時の事業価値の実現の可能性が高くなる。

スコープ定義

  • プロジェクトの成功に直結
    • プロセスの正確さと完全性に特に注意する必要がある。
    • 不完全な定義は、コスト増加、手直し、スケジュール遅れ、士気の低下を招く。
  • 収集された要求事項をプロジェクトに含めるかどうかはこのプロセスで決定する。

インプット

要求事項 → 成果物(プロダクト / サービス / 所産)の詳細な説明
予備的なスコープに含まれれている情報を収集する。

プロセス(ツールと技法)

専門家の判断

プロダクト分析

プロダクトの最終結果がプロダクトであるとき最も役に立つ。

  • インプット・アウトプット
  • 構成要素
    • 価値分析(VA:Value Analysis)、価値工学(VE:Value Engineering)
    • システム分析(SA:System Analysis)、システム工学(SE:System Engineering)
    • プロダクト・ブレークダウン、要求事項分析(RA:Requirement Analysis)

代替案生成

プロジェクト作業を実行するための異なる技法・方法を発見する技法

  • ブレーン・ストーミング
  • 水平思考( ---> 水平思考パズル)
  • ランダム発想法
    無作為に選び、興味分野と関連付けて発想を広げる。
  • 刺激的発想法
    誇張、またはその逆を行い、アイデアの源にする。
  • 挑戦的発想法
    既成事実を分析し、アイデアの源にする。
  • 概念拡散発想法
    ある概念を他の事物に広く応用する。
  • 反証的発想法
    説得力のある反証を試みる。
  • 一対比較
    判断の対象となる選択肢を2つ一組とし、どちらがよりよいか選択する。

ファシリテーション型ワークショップ

アウトプット

プロジェクト・スコープ記述書

詳細に、要求事項(重要成功要因)を再文書化する。

  • 目的
    すべてのステークホルダーにスコープを理解してもらう。
    • プロジェクト・チームと顧客との合意書。
    • 意思決定の基準として使用する。
    • プロジェクト作業の指揮の際に使用する。
    • 段階的に詳細化され、タスクやアクティビティに分解される。

大きなプロジェクトでは、個々の成果物(プロダクト / サービス / 所産)ごとに生成される。

プロジェクト・スコープ記述書の構成要素

  • 仕様の定義
  • 基準の定義
    • 品質標準
    • 使用適合性
    • パフォーマンス測定基準
  • 受入プロセスの定義
  • 除外事項
    ステークホルダー・エンゲージメント・マネジメントの継続のため。
  • 三大制約条件
    プロジェクト目標や要求事項を導き出すのにも必要になる。
    三大制約条件にどう対処するかで、範囲と品質が決定される。
    範囲と品質を守るために、時間・予算のバランスを図るケースが多い。
    (時間・予算どちらか一方は可能だが、両方は無理。
    その場合、範囲や品質などの変更が必要になる。)。
  • 範囲(スコープ)
  • 時間(≒ 締め切り、≠ スケジュール)
  • 予算(コスト)
  • 競合する要求
    上記に加え、以下のものがある。
  • 人的資源
    非人的資源の、入手可能性や品質。
    人的資源の、入手可能性やスキル・レベル。
  • リスク
    ・・・。
  • その他
  • スケジュール
    締め切りではなくてアクティビティの日程
  • 技術
    リリース時期、テスト完了時期
  • 指示
    経営陣からの方針、契約条項など。
  • 前提条件
    プロジェクト / ステークホルダーの本当だと信用できる情報(確定ではない)。
    前提条件が間違っていたり、文書化されていなかったりすると、
    それが、プロジェクトにとって命取りになることがある。
  • 前提条件の例
    • 主要なチーム・メンバが支障なく働ける。
    • プロジェクト計画の精度(契約締結日、プロジェクト開始日、フェーズ開始日)
    • 調達(ベンダーの納期、製品の入手可能性、コンストラクターの確保可能性)
  • プロジェクトの前提条件の例
    • 資材の入手可能性(コモディティは入手容易で値段も手頃)
    • 契約労働者の雇用(景気や地域の労働市場状況によ左右される)
  • ステークホルダーの前提条件の例
    • ・・・
  • 前提条件の確実化の例
    • ベンダーにコンティンジェンシー・プランの実行を義務付ける。

引掛けが多いが、制約条件は、

  • 時間 > コストとなることが多い。
  • また、資源の調達は予め既知の範囲で限定しない。

プロジェクト・スコープ記述書の承認と発行

  • プロジェクト憲章と同様に、合意後に承認を受けて発行 / 配布する。
  • 公式のアウトプットではなく、全てに合意 / 承認が必要と言う訳ではない。
  • これにより、ステークホルダーは能動的プロジェクト参加者で有り続ける。

プロジェクト文書更新版

対象のプロジェクト文書の更新後、プロジェクト・スコープ記述書の再発行を行う。

WBS作成

  • 要求事項(重要成功要因)を明確にした後、作業を構成要素に分解する(要素分解)。
    ※ ワーク・ブレークダウン・ストラクチャー(WBS : Work Breakdown Structure)
  • 定義するもの
    • プロジェクト作業スコープ
    • プロジェクト作業の内容

できる。

  • このため(重要な前提条件であるコストやスケジュールを狂わせるため)、正確さと完全性が要求される。
    • 正確さ:WBS検証専門家の判断で正確さを判定できる。
    • 完全性:集合的にプロジェクトのすべての作業を網羅する(100%ルール)。

インプット

プロセス(ツールと技法)

要素分解

  • 作業
    ブレークダウン・プロセス(要素分解プロセス)の5ステップ。
  • WBSの構造を決定し、プロジェクト作業を体系化する。
  • プロジェクト
    プロジェクト・レベルをWBSの第1レベルとする。
  • 主要な成果物(プロダクト / サービス / 所産)とサブ・プロジェクト
    要素分解の第1レベル(=WBSの第2レベル)として使用する。
    ※ 従って、例えば、各プロダクトを第1レベルに設定することもできる。
  • プロジェクト・フェーズ
    要素分解の第2レベル(=WBSの第3レベル)として使用する。
  • プロジェクト要素成果物
    要素分解の最下位レベルをワーク・パッケージ・レベルと言う。
  • WBSの構成要素を下位レベルの構成要素に分解する。
  • 主要な要素成果物を、小さく、管理しやすい作業に対応する要素成果物に分解する。
    ※ WBSの最下位レベル(ワーク・パッケージ・レベル)まで分割する。
  • この場合、測定・検証が可能な形式で、要素成果物を定義・記述する必要がある。
  • プロジェクト・チームの外部で実施される可能性のあるサブ・プロジェクトのWBS
  • 契約作業の一環として、納入者(コンストラクター、サプライヤー、別の部署)によってWBSが作成される。
  • このため、実施時期が近くならないとWBSが作成されないことがある。
    ローリング・ウェーブ計画法では現時点で解っている範囲で詳細化する。
  • このサブ・プロジェクトは元プロジェクトのワーク・パッケージ・レベルになる。
    サブ・プロジェクトは、要素分解の第1レベル(=WBSの第2レベル)で、
    元プロジェクトのワーク・パッケージ・レベルと同じ階層でなくてイイ。
  • WBSの構成要素にWBSコードを割り当てる。
  • 各レベルに割り当てられたIDをハイフンで繋げてWBSコードを作成
  • この識別コードはコントロール・アカウントと呼ばれ追跡に使用される。
  • コストの追跡の場合、会計システムの勘定科目に関連付けられる。
    作業時間・割当資源の追跡というひっかけがあったが、「コスト追跡」が目的。
  • WBSを検証する。
    構成要素が明確で完全なものであるか判断する。
    • 絶対不可欠なものか?
    • 作業を記述するに十分なものか?
  • 補足
    • ワーク・パッケージ・レベル
  • チーム・メンバにとって解り易く、適切な時間内に完了するようにする。
    過度の分解は非効率であり、細部までの定義はチーム・メンバの創造性を阻害する。
  • ワーク・パッケージ・レベルを、測定・検証の責任を持つ組織に割り当てる。
  • ワーク・パッケージ・レベルによって、コストと資源の見積、スケジュール作成を行う。

専門家の判断

  • 上級管理職(立上の人物/組織)
  • プロジェクト・スポンサー
    (オーナー、イニシエータ、顧客であることもある)
  • 業界の専門家
  • 専門的な訓練を受けたチーム・メンバ
  • 類似プロジェクトの経験のあるPM

アウトプット

スコープ・ベースライン

  • 利用
    • アクティビティ定義
    • コストと資源の見積
    • スケジュール作成
    • 監視・制御(進捗)

WBS辞書

  • 要素
    • WBS識別コード
    • 作業の記述
    • 前提条件
    • 制約条件
    • 担当組織
  • 重要な前提条件
    • コストの見積
    • 資源の見積
    • スケジュール
      スケジュール・マイルストーン
      関連するスケジュール・アクティビティ
    • 品質要求事項
  • 受入基準
  • 技術的参照資料
  • 合意情報

プロジェクト文書更新版

対象のプロジェクト文書の更新作業を行う。

  • 要求済み変更の見直し
  • 修正対象の修正
  • 変更管理プロセスを利用して変更を承認 / 却下
  • 修正対象に反映(プルリク・マージ的な)

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-11-06 (火) 20:49:45 (37d)