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

目次

概要

データ収集

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

チェック・リスト

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

アンケートと調査

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

パフォーマンス

観察と対話

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

  • 作業観測
    • 通常行っている仕事を外部から観察する手法
    • 観察者がプロダクトを使用した作業を観察する。
  • 参加型オブザーバー
    • 観察者 自身が作業者になる。
    • 自らプロセスや手続きを実際に体験する。

ベンチマーキング

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

  • ベストプラクティスの精緻化
  • 慣行の改善のためのアイディア創出
  • 測定対象
    • プロセス
    • 定常業務
    • マネジメント
  • 基準値
    • 他部署
    • 他組織
    • 他業界

インタビュー

概要

  • 一対一の会話(質疑応答形式のセッション)を行う。
  • 質問
  • 回答

を記録

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

リスク特定(計画 - リスク)

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

ブレーン・ストーミング

概要

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

リスク特定(計画 - リスク)

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

意思決定技法

投票

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

独裁的意思決定

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

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

ブレスト+投票

デルファイ法 ★

  • アンケート+フィードバック繰返で収斂
  • 偏見や過度な影響を減らして、意見を収束させる。
  • 多数の専門家や個人にアンケート調査を行い、結果を回答者にフィードバック、
    さらに予測を繰り返し、予測の正確度を上げながら、全体の答えや意見を絞る。
  • ブレーン・ストーミングに似ているが参加者がお互い誰か解らない点が異なる。
    • 社内外の専門家を集めてリスクに関するアンケートを配布する。
    • 回答がPMに送られるので、PMは結果をサマリして返信する。
    • 返信への参加者のコメントをまとめて最終リストを完成させる。

ブレーン・ライティング

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

多基準意思決定分析

概要

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

資源の獲得における

  • 「資源の獲得」における「多基準意思決定分析」
  • 以下には、通常、選択基準が用いられる。
    • 物的プロジェクト資源
    • プロジェクト・チーム選択
  • 資源タイプに応じて基準値は、
    相対的な重み付けによって変更される。
  • 「資源の獲得」における「選択基準の例」
    #選択基準チーム資源固有の選択基準
    1経験チーム・メンバには成功に寄与できる妥当な経験があるか?
    2知識チーム・メンバには類似プロジェクトの関連知識があるか?
    3スキルチーム・メンバにはプロジェクトで使うツールを使用するスキルがあるか?
    4態度チーム・メンバは他のメンバと連帯感をもってやっていけるか?
    5国際的な要因チーム・メンバの所在地、タイムゾーン、コミュニケーション能力を考慮する。

データ収集 & 意思決定

フォーカス・グループ

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

ファシリテーション

概要

  • ファシリテーション型のフォーラムで、
    • 様々な機能部門のステークホルダーが参加する。
    • 複数の部署に影響を及ぼす要求事項に関する討議・定義。
  • ファシリテーターは会議、ミーティング等の場で、
    • 発言や参加を促したり、話の流れを整理したり、
    • 参加者の認識の一致を確認したりする行為で介入し、

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

要求事項収集(計画 - 範囲)

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

リスク特定(計画 - リスク)

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

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

意思決定と

時間

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

モチベーション

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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-02-16 (土) 18:11:05 (6d)