「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
データ収集 †
データ収集のコンテキストで使われる。
チェック・リスト †
- リスク
- ステークホルダー、チーム・メンバにチェック・リストを記入してもらう。
- チェック・リストの作成方法
- 経験に基づいてチェック・リストにリスクのリストをまとめる。
- RBSをチェック・リストとして使用することもできる。
- チェック・リストはメンテして追加する必要がある。
アンケートと調査 †
パフォーマンス †
観察と対話 †
通常、作業者が気が付かない要求事項を発見できる。
- 作業観測
- 通常行っている仕事を外部から観察する手法
- 観察者がプロダクトを使用した作業を観察する。
- 参加型オブザーバー
- 観察者 自身が作業者になる。
- 自らプロセスや手続きを実際に体験する。
ベンチマーキング †
基準値と測定値を比較してパフォーマンスを測定する。
- ベストプラクティスの精緻化
- 慣行の改善のためのアイディア創出
インタビュー †
概要 †
を記録
リスク特定(計画 - リスク) †
- ステークホルダー、チーム・メンバに対してインタビューを行う。
- 事前に、WBSや前提条件を提示し、過去の経験に基づいてリスクが回答される。
ブレーン・ストーミング †
概要 †
- リスク特定プロセスで最もよく使われる。
- シックス・ハット法と呼ばれるブレーン・ストーミング手法がある。
- 他にも、アイデア・マップ法、マインド・マップ法などがある。
リスク特定(計画 - リスク) †
- ステークホルダーを一堂に会し、リスク事象を特定する。
- 進行役がリスク区分を提示、参加者アイディアが連鎖する。
※ リスク特定のポイント
意思決定技法 †
投票 †
- 満場一致
- 過半数
- 相対多数(過半数に達しない場合)
独裁的意思決定 †
1人がグループを代表して意思決定
ノミナル・グループ技法 ★ †
ブレスト+投票
デルファイ法 ★ †
アンケート+フィードバック繰返で収斂(しゅうれん)
- 多数の専門家や個人にアンケート調査を行い、結果を回答者にフィードバック、
さらに予測を繰り返し、予測の正確度を上げながら、全体の答えや意見を絞る。
- ブレーン・ストーミングに似ているが参加者がお互い誰か解らない点が異なる。
- 社内外の専門家を集めてリスクに関するアンケートを配布する。
- 回答がPMに送られるので、PMは結果をサマリして返信する。
- 返信への参加者のコメントをまとめて最終リストを完成させる。
ブレーン・ライティング †
- リレー形式でアイデアを書くことにより、アイディアを発展させていく手法。
- ブレイン・ストーミングをベースに、635法をさらに改良した技法
- 635法とは、アイデアを紙に書き出していく手法である。
- 参加メンバ全員に同程度の貢献を期待できる。
- 地位や立場の違いの配慮、発言が苦手な人などを避け易い。
- 初対面の参加者間でもアイディアを交わすことが出来る。
- 紙だと他のアイディアへの批判が起きない。
- リーダや書記の負担軽減。リーダの経験に左右され難い。
多基準意思決定分析 †
概要 †
- ツールを用いて、基準を作成し、潜在的な資源の等級付け採点に用いる。
- 基準は、相対的な重要度に従って重み付けされ、その値はタイプに応じて変更される。
資源の獲得における †
- 資源タイプに応じて基準値は、
相対的な重み付けによって変更される。
- 「資源の獲得」における「選択基準の例」
# | 選択基準 | チーム資源固有の選択基準 |
1 | 経験 | チーム・メンバには成功に寄与できる妥当な経験があるか? |
2 | 知識 | チーム・メンバには類似プロジェクトの関連知識があるか? |
3 | スキル | チーム・メンバにはプロジェクトで使うツールを使用するスキルがあるか? |
4 | 態度 | チーム・メンバは他のメンバと連帯感をもってやっていけるか? |
5 | 国際的な要因 | チーム・メンバの所在地、タイムゾーン、コミュニケーション能力を考慮する。 |
データ収集 & 意思決定 †
フォーカス・グループ †
ファシリテーション †
概要 †
相互理解 -> 信頼関係の構築 -> 合意形成をサポートする。
- ファシリテーション型のフォーラムで、
- 様々な機能部門のステークホルダーが参加する。
- 複数の部署に影響を及ぼす要求事項に関する討議・定義。
- ファシリテーターは会議、ミーティング等の場で、
- 発言や参加を促したり、話の流れを整理したり、
- 参加者の認識の一致を確認したりする行為で介入する。
要求事項収集(計画 - 範囲) †
- JAD:IT業界(共同アプリケーション設計・開発)
- 概要
システムの利用者が開発の初期段階から参加し、要望を反映させる。
- 概要
品質保証や製品企画、顧客満足やマーケットインを実現するための方法論。
製造者と顧客の考えの関係をチェックして、ミスマッチを減らす。
特性値とそれを実現するための工程や、製造条件、等の関係を決める。
リスク特定(計画 - リスク) †
個別リスク・全体リスクを特定する技法の有効性を高める。
- 個別リスク・全体リスクに対する集中を保持し明確なリスク記述を促す。
- 偏見要因の特定と克服し、あらゆる不一致の解決する。
意思決定と †
時間 †
- 意思決定には時間が影響する。
- 長過ぎ / 短過ぎの場合、最良の意思決定にならない。
モチベーション †
メンバに意思決定権を与える事によって、
(若しくはメンバの意見を反映することによって)
モチベーションを高めることが出来る。