「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-戻る
--[[計画 - 範囲>PMP：計画 - 範囲]]
--[[計画 - リスク>PMP：計画 - リスク]]
--[[試験>PMP：試験]]
*目次 [#bee9f90e]
#contents
*概要 [#ae5d48cf]
*データ収集 [#n4905ba1]
データ収集のコンテキストで使われる。
**チェック・リスト [#v54642fe]
-チェック・リストを記入してもらう。
-リスク
--ステークホルダー、チーム・メンバにチェック・リストを記入してもらう。
--チェック・リストの作成方法
---経験に基づいてチェック・リストにリスクのリストをまとめる。
---RBSをチェック・リストとして使用することもできる。
---チェック・リストはメンテして追加する必要がある。
**アンケートと調査 [#lb5e1c37]
-大規模な母集団
-素早い情報収集
-結果の統計分析
**パフォーマンス [#h249ec93]
***観察と対話 [#z0cd2e1d]
通常、作業者が気が付かない要求事項を発見できる。
-作業観測
--通常行っている仕事を外部から観察する手法
--観察者がプロダクトを使用した作業を観察する。
-参加型オブザーバー
--観察者 自身が作業者になる。
--自らプロセスや手続きを実際に体験する。
***ベンチマーキング [#u9f2c2d6]
基準値と測定値を比較してパフォーマンスを測定する。
-ベストプラクティスの精緻化
-慣行の改善のためのアイディア創出
-測定対象
--プロセス
--定常業務
--マネジメント
-基準値
--他部署
--他組織
--他業界
**インタビュー [#j13f224c]
***概要 [#u438add9]
-一対一の会話（質疑応答形式のセッション）を行う。
--質問
--回答
>を記録
-対象を絞って短時間で多くの情報を入手できる。
--特定の分野の専門家
--経験豊富なチーム・メンバ
***リスク特定（計画 - リスク） [#s2836618]
-ステークホルダー、チーム・メンバに対してインタビューを行う。
-事前に、WBSや前提条件を提示し、過去の経験に基づいてリスクが回答される。
**ブレーン・ストーミング [#b36da89b]
***概要 [#q6f2ec0a]
-&color(red){リスク特定プロセス};で最もよく使われる。
-&color(red){シックス・ハット法};と呼ばれるブレーン・ストーミング手法がある。
-他にも、&color(red){アイデア・マップ法、マインド・マップ法};などがある。
***リスク特定（計画 - リスク） [#j6da4c94]
-ステークホルダーを一堂に会し、リスク事象を特定する。
-進行役がリスク区分を提示、参加者アイディアが連鎖する。
※ [[リスク特定のポイント>PMP：試験 - 計画#n9085a79]]
*意思決定技法 [#mff4527a]
**投票 [#xacd8da7]
-満場一致
-過半数
-相対多数（過半数に達しない場合）
**独裁的意思決定 [#n257a920]
１人がグループを代表して意思決定
**ノミナル・グループ技法 ★ [#y1f97e88]
ブレスト＋投票
-[[ブレーン・ストーミング>#b36da89b]]の一技法、集団インタビュー技法。
-[[ブレーン・ストーミング>#b36da89b]]に投票プロセスを加え、結論を出す方法。
-付箋紙にリスクを書き出し、ボードに貼り付けレビューしランク付けする。
**デルファイ法 ★ [#ebcbd30b]
アンケート＋フィードバック繰返で収斂（しゅうれん）
-偏見や過度な影響を減らして、意見を収束させる。
-多数の専門家や個人にアンケート調査を行い、結果を回答者にフィードバック、~
さらに予測を繰り返し、予測の正確度を上げながら、全体の答えや意見を絞る。
-[[ブレーン・ストーミング>#b36da89b]]に似ているが参加者がお互い誰か解らない点が異なる。
--社内外の専門家を集めてリスクに関するアンケートを配布する。
--回答がPMに送られるので、PMは結果をサマリして返信する。
--返信への参加者のコメントをまとめて最終リストを完成させる。
**ブレーン・ライティング [#v3466b2d]
-リレー形式でアイデアを書くことにより、アイディアを発展させていく手法。
-ブレイン・ストーミングをベースに、635法をさらに改良した技法
-635法とは、アイデアを紙に書き出していく手法である。
--参加メンバ全員に同程度の貢献を期待できる。
--地位や立場の違いの配慮、発言が苦手な人などを避け易い。
---初対面の参加者間でもアイディアを交わすことが出来る。
---紙だと他のアイディアへの批判が起きない。
---リーダや書記の負担軽減。リーダの経験に左右され難い。
**多基準意思決定分析 [#u3f9c815]
***概要 [#n28a37a2]
-ツールを用いて、基準を作成し、潜在的な資源の等級付け採点に用いる。
-基準は、相対的な重要度に従って重み付けされ、その値はタイプに応じて変更される。
***資源の獲得における [#xaaf9783]
-「資源の獲得」における「多基準意思決定分析」
--以下には、通常、選択基準が用いられる。
---物的プロジェクト資源
---プロジェクト・チーム選択
--資源タイプに応じて基準値は、~
相対的な重み付けによって変更される。
-「資源の獲得」における「選択基準の例」
|#|選択基準|チーム資源固有の選択基準|h
|1|経験|チーム・メンバには成功に寄与できる妥当な経験があるか？|
|2|知識|チーム・メンバには類似プロジェクトの関連知識があるか？|
|3|スキル|チーム・メンバにはプロジェクトで使うツールを使用するスキルがあるか？|
|4|態度|チーム・メンバは他のメンバと連帯感をもってやっていけるか？|
|5|国際的な要因|チーム・メンバの所在地、タイムゾーン、コミュニケーション能力を考慮する。|
*データ収集 & 意思決定 [#g9db31f8]
**フォーカス・グループ [#s73b3e08]
-訓練を受けたモデレータによって行われる。
-参加者の選定が重要になる。
--特定の分野の専門家
--ステークホルダー
**ファシリテーション [#w28dfb85]
***概要 [#b8b8a81f]
&color(red){相互理解 -> 信頼関係の構築 -> 合意形成をサポートする。};
-ファシリテーション型のフォーラムで、
--様々な機能部門のステークホルダーが参加する。
--複数の部署に影響を及ぼす要求事項に関する討議・定義。
-ファシリテーターは会議、ミーティング等の場で、
--発言や参加を促したり、話の流れを整理したり、
--参加者の認識の一致を確認したりする行為で介入する。
-[[フォーカス・グループ>#s73b3e08]]と違い、部門を跨る要求事項を定義できる。
--素早い相違の把握
--相違の解消と合意
***要求事項収集（計画 - 範囲） [#o4598f67]
-JAD：IT業界（共同アプリケーション設計・開発）
--概要~
システムの利用者が開発の初期段階から参加し、要望を反映させる。
--参加者~
機能部門のステークホルダー
-QFD：製造業界（品質機能展開）
--概要~
品質保証や製品企画、顧客満足やマーケットインを実現するための方法論。~
製造者と顧客の考えの関係をチェックして、ミスマッチを減らす。~
特性値とそれを実現するための工程や、製造条件、等の関係を決める。
--参加者~
顧客、ビジネス分野の専門家
***リスク特定（計画 - リスク） [#ae603e9e]
個別リスク・全体リスクを特定する技法の有効性を高める。
-個別リスク・全体リスクに対する集中を保持し明確なリスク記述を促す。
-偏見要因の特定と克服し、あらゆる不一致の解決する。
*意思決定と [#n5b33e4d]
**時間 [#y8f27286]
-意思決定には時間が影響する。
-長過ぎ / 短過ぎの場合、最良の意思決定にならない。
**モチベーション [#l42cc8af]
メンバに意思決定権を与える事によって、~
（若しくはメンバの意見を反映することによって）~
モチベーションを高めることが出来る。
*[[参考>プロジェクト選定委員会運営#x7e9e057]] [#q5fac5c2]
*参考 [#q5fac5c2]
**[[Qiita>プロジェクト選定委員会運営#x7e9e057]] [#de2dd82f]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
