PMP：グループ意思決定技法

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

• 戻る
  • 計画 - 範囲
  • 計画 - リスク
  • 試験

目次 †

概要 †

データ収集 †

データ収集のコンテキストで使われる。

チェック・リスト †

• チェック・リストを記入してもらう。

• リスク
  • ステークホルダー、チーム・メンバにチェック・リストを記入してもらう。
  • チェック・リストの作成方法
    • 経験に基づいてチェック・リストにリスクのリストをまとめる。
    • RBSをチェック・リストとして使用することもできる。
    • チェック・リストはメンテして追加する必要がある。

アンケートと調査 †

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

パフォーマンス †

観察と対話 †

通常、作業者が気が付かない要求事項を発見できる。

• 作業観測
  • 通常行っている仕事を外部から観察する手法
  • 観察者がプロダクトを使用した作業を観察する。

• 参加型オブザーバー
  • 観察者 自身が作業者になる。
  • 自らプロセスや手続きを実際に体験する。

ベンチマーキング †

基準値と測定値を比較してパフォーマンスを測定する。

• ベストプラクティスの精緻化
• 慣行の改善のためのアイディア創出

• 測定対象
  • プロセス
  • 定常業務
  • マネジメント

• 基準値
  • 他部署
  • 他組織
  • 他業界

インタビュー †

概要 †

• 一対一の会話（質疑応答形式のセッション）を行う。

• 質問
• 回答

を記録

• 対象を絞って短時間で多くの情報を入手できる。
  • 特定の分野の専門家
  • 経験豊富なチーム・メンバ

リスク特定（計画 - リスク） †

• ステークホルダー、チーム・メンバに対してインタビューを行う。
• 事前に、WBSや前提条件を提示し、過去の経験に基づいてリスクが回答される。

ブレーン・ストーミング †

概要 †

• リスク特定プロセスで最もよく使われる。
• ６つの帽子と呼ばれるブレーン・ストーミング手法がある。
• アイデア・マップ法、マインド・マップ法などがある。

リスク特定（計画 - リスク） †

• ステークホルダーを一堂に会し、リスク事象を特定する。
• 進行役がリスク区分を提示、参加者アイディアが連鎖する。

意思決定技法 †

投票 †

• 満場一致
• 過半数
• 相対多数（過半数に達しない場合）

独裁的意思決定 †

１人がグループを代表して意思決定

ノミナル・グループ技法 ★ †

ブレスト＋投票

• ブレーン・ストーミングの一技法、集団インタビュー技法。
• ブレーン・ストーミングに投票プロセスを加え、結論を出す方法。
• 付箋紙にリスクを書き出し、ボードに貼り付けレビューしランク付けする。

デルファイ法 ★ †

• アンケート＋フィードバック繰返で収斂

• 偏見や過度な影響を減らして、意見を収束させる。

• 多数の専門家や個人にアンケート調査を行い、結果を回答者にフィードバック、
  さらに予測を繰り返し、予測の正確度を上げながら、全体の答えや意見を絞る。

• ブレーン・ストーミングに似ているが参加者がお互い誰か解らない点が異なる。
  • 社内外の専門家を集めてリスクに関するアンケートを配布する。
  • 回答がPMに送られるので、PMは結果をサマリして返信する。
  • 返信への参加者のコメントをまとめて最終リストを完成させる。

ブレーン・ライティング †

• リレー形式でアイデアを書くことにより、アイディアを発展させていく手法。
• ブレイン・ストーミングをベースに、635法をさらに改良した技法

• 635法とは、アイデアを紙に書き出していく手法である。
  • 参加メンバ全員に同程度の貢献を期待できる。
  • 地位や立場の違いの配慮、発言が苦手な人などを避け易い。
    • 初対面の参加者間でもアイディアを交わすことが出来る。
    • 紙だと他のアイディアへの批判が起きない。
    • リーダや書記の負担軽減。リーダの経験に左右され難い。

多基準意思決定分析 †

概要 †

• ツールを用いて、基準を作成し、潜在的な資源の等級付け採点に用いる。
• 基準は、相対的な重要度に従って重み付けされ、その値はタイプに応じて変更される。

資源の獲得における †

• 「資源の獲得」における「多基準意思決定分析」

• 以下には、通常、選択基準が用いられる。
  • 物的プロジェクト資源
  • プロジェクト・チーム選択

• 資源タイプに応じて基準値は、
  相対的な重み付けによって変更される。

• 「資源の獲得」における「選択基準の例」

  #	選択基準	チーム資源固有の選択基準
  1	経験	チーム・メンバには成功に寄与できる妥当な経験があるか？
  2	知識	チーム・メンバには類似プロジェクトの関連知識があるか？
  3	スキル	チーム・メンバにはプロジェクトで使うツールを使用するスキルがあるか？
  4	態度	チーム・メンバは他のメンバと連帯感をもってやっていけるか？
  5	国際的な要因	チーム・メンバの所在地、タイムゾーン、コミュニケーション能力を考慮する。

データ収集 & 意思決定 †

フォーカス・グループ †

• 訓練を受けたモデレータによって行われる。

• 参加者の選定が重要になる。
  • 特定の分野の専門家
  • ステークホルダー

ファシリテーション †

概要 †

• ファシリテーション型のフォーラムで、
  • 様々な機能部門のステークホルダーが参加する。
  • 複数の部署に影響を及ぼす要求事項に関する討議・定義。

• ファシリテーターは会議、ミーティング等の場で、
  • 発言や参加を促したり、話の流れを整理したり、
  • 参加者の認識の一致を確認したりする行為で介入し、

合意形成や相互理解をサポートする。

• フォーカス・グループと違い、部門を跨る要求事項を定義できる。
  • 素早い相違の把握
  • 相違の解消と合意

要求事項収集（計画 - 範囲） †

• IT業界：JAD（共同アプリケーション設計・開発）

• 概要
  システムの利用者が開発の初期段階から参加し、要望を反映させる。

• 参加者：機能部門のステークホルダー

• 製造業界：QFD（品質機能展開）

• 概要
  品質保証や製品企画、顧客満足やマーケットインを実現するための方法論。
  製造者と顧客の考えの関係をチェックして、ミスマッチを減らす。
  特性値とそれを実現するための工程や、製造条件、等の関係を決める。

• 参加者
  顧客、ビジネス分野の専門家

リスク特定（計画 - リスク） †

個別リスク・全体リスクを特定する技法の有効性を高める。

• 個別リスク・全体リスクに対する集中を保持し明確なリスク記述を促す。
• 偏見要因の特定と克服し、あらゆる不一致の解決する。

意思決定と †

時間 †

• 意思決定には時間が影響する。
• 長過ぎ / 短過ぎの場合、最良の意思決定にならない。

モチベーション †

メンバに意思決定権を与える事によって、
（若しくはメンバの意見を反映することによって）
モチベーションを高めることが出来る。