Transcript プロジェクトを
ソフトウェア開発及びソフトウェア プロジェクトマネジメント（IX） 北航软件学院 马平 博士 副教授 [email protected] レビュー １．コスト・マネジメントには、（？ ）のプロセスがある。 各プロセスの主なアウトプットは？ ２．ソフトウェア開発の見積りを困難にしている要因は？ 見積り技法は何種類がある？ 各技法の特徴、使用上の注意は？ ３．EVMSでどのように進捗管理とコスト管理を行いますか? WBS？ PMS？ PV？ EV？ AC？ BAC？ CV( コスト差異)、 （EV – AC） SV (スケジュール差異) （EV - PV ） CPI（コスト効率指数 ） （EV÷AC） SPI（スケジュール効率指数 ）（EV÷PV） EAC (完成時総コスト見積り） AC + (BAC - EV)÷CPI ＥＶＭＳ （Earned Value Management System） ＥＡＣ ＰＶ ベースライン ＡＣ ＶＡＣ：完成時での差異 実コスト 完了予測コスト EV アーンドバリュー ＢＡＣ コ ス ト ＰＶ 完了予算コスト ベースライ ン ＡＣ ＥＶ ＣＶ：コスト差異 ＳＶ：スケジュール差異 コスト表示 予測のプロジェクトの 時間遅れ EV ＳＶ：スケジュール差異 期間表示 現時点 計画完了 時点 時間 PMBOKプロセス群と知識エリアのマップ プロセス群 立ち上げ 計画 実行 コントロール プロジェクト計画の策定 プロジェクト 計画の実行 統合変更管理 終結 知識エリア 統合マネジメント スコープ・マネジメント 立ち上げ スコープ計画 スコープ定義 スコープ検証 スコープ変更管理 タイム・マネジメント アクティビティ定義 アクティビティ順序設定 アクティビティ所要期間見積り スケジュール スケジュール・コン トロール コスト・マネジメント 資源計画 コスト見積り コストの予算化 コスト・コントロー ル 品質マネジメント 品質計画 品質保証 人的資源マネジメント 組織計画 要員調達 チーム育成 コミュニケーション・マ ネジメント コミュニケーション計画 情報配布 リスク・マネジメント リスク・マネジメント リスク識別 定性的リスク分析 定量的リスク分析 リスク対応計画 調達マネジメント 調達計画 引合計画 品質管理 実績報告 完了手続き リスクの監視・コン トロール 引合 発注先選定 契約管理 契約完了 見積り技法 概要 特徴 使用上の注意 概算法 （類推法） 過去に実績のあるプロジェクトをベースとして、 対象となるプロジェクト工数やコストを見積も る。主にプロジェクトの初期段階で行われるこ とが多いです。 見積りコストが安価 で済む。 類似プロジェクトが 過去にあれば信頼性 は高くなる。 過去のプロジェクト実 施者に見積りを依頼 のデータベースを活用 したりする。 積算法 （積上げ法 ） プロジェクト上で必要となる作業項目をWBSに よって洗い出し、その作業ごとの工数を個別に 見積もる。それから、個別の工数を積み上げて 計算する WBSを細かくすること で、見積り精度向上 させることができる。 WBSを細かくすればす る ほど、見積りコストが 上昇する。 標準タスク 法 開発工程を標準的な複数のタスクに定義し、そ れぞれ過去の実績から設定された作業工数を与 える（標準タスクテーブル）このテーブルをも とに対象となるプロジェクトの見積りを算出する 積算法を標準化した 標準値の設定に開発規 ものである。標準化 模などの付加的要件を しているため,見積り 反映させ、定期的に標 に統一性があり、 準値を見直す必要があ ユーザの理解も得やすい。 る。 CoCoMo プログラムのソースコードの行数で見積りを行う。 過去、主に、アセンブラやCOBOLなど、メインフ レーム中心のソフトウェア開発で利用された。 開発規模を見積もる技 法ではなく、ソース コード行数と工数との 変換技法と考えると理 解しやすい。 ウォーターフォール型 の開発を想定している。 数万から数十万ステッ プ規模の見積りに適し ている。 ファンク ションポイ ント法 （FP法） 画面入力や帳票出力、使用ファイル、外部インタ フェースなどの機能数（ファンクションポイン） によって見積りを進める。開発形態の多様化に対 応して、多くの企業で採用されだした。機能は５ つのタイプ（内部論理ファイル、外部インタェ ースファイル、外部入力、外部出力、外部照会） にわけてカウントされる。 開発環境に影響される ことなく、ソフトウェ アの開発規模を測定す ることができる。 FPは規模の大きさを示 すものなので、開発工 数を求めるには、別途 変換テーブルの作成が 必要となる。 COCOMOⅡ ソースコードの行数から工数に変換すること になっている。工数調整にソフトウェアの再 利用やプロジェクトメンバーの経験などの要 素が重み付けされる。 新規開発のみでなく、 再利用を含んだ開発に も対応することができ る。 開発のどの時期に見積 もるかによって、３つ のモデル（基本COCOMO、 中間COCOMO、詳細 COCOMO）に分かれる。 第9回 品質・マネジメント及び人的資源マネジメント 品質・マネジメント 9.1 品質計画 9.2 品質保証 9.3 9.4 9.5 9.6 品質管理 組織計画 要因調達 チーム育成 品質・マネジメントのプロセス 品質・マネジメントは次の図に示す ３つのプロセスがある。 品質・マネジメント 品質計画 計画のプロセス 品質保証 遂行のプロセス 品質管理 コントロールのプロセ ス 品質システム体系（例） 9.1 品質計画 品質計画 インプット １．品質方針 2. スコープ記述書 3．成果物記述書 ４．標準と規制 ５．他のプロセスからの アウトプット ツールと技法 1. 便益・費用分析 ２．ベンチマーキング ３．フローチャート化 ４．実験計画法 ５．品質コスト アウトプット １．品質マネジメント 計画書 ２．運用基準 ３．チェックリスト ４．他のプロセスへの インプット 9.2 品質保証 品質保証 インプット １．品質マネジメント計画書 2. 品質管理の測定結果 3．運用基準 ツールと技法 １．品質計画のツールと 技法 ２．品質監査 アウトプット １．品質改善 9.3 品質管理 品質管理 インプット １．品質マネジメント計画書 2. 作業結果 ３．運用基準 ４．チェックリスト ツールと技法 １．検査 ２．管理図 ３．パレート図 ４．統計的サンプリング ５．フローチャート化 ６．傾向分析 アウトプット １．品質改善 ２．受け入れの決定 ３．手直し ４．記入済みチェックリスト ５．プロセスの調整 9.3.1 品質管理技法としてQC７つ道具 １．特性要因図 ２．チェックシート ３．管理図 ４．ヒストグラム ５．散布図 ６．パレート図 ７．層別 QC七つ道具 ① 特性要因図（Cause-effect Diagram） 現状の問題点を要因別に整理し、関連付けた図。 結果とそれに影響を及ぼす要因を魚の骨のように整理して記述します。「魚の 骨図（Fishbone Diagram）」とも呼ばれます。 プロジェクトでは、例えば要件定義段階での問題分析、障害発生時の原因分析、 プロセス改善のための現状分析などに利用されます。 QC七つ道具 ② チェックシート，チェックリスト （Check Sheet，Checklist） チェックする項目を並べて、項目をチェックすることで簡 単に結果が分かる図。 プロジェクトでは、例えばデザイン・レビューやリスク分析などにお いて、チェックポイントを標準化して利用します。ただし、チェック シートに無い項目がレビューされない可能性があり、運用には注意が 必要ですし、内容の適宜な改訂が必須です。 QC七つ道具 ③ 管理図（Control Chart） 中心線及び管理限界線を引き、測定値をプロットして作成され る折れ線グラフ。 不良の出方（不良率や不良個数）の分析など、プロセスが「管理され た状態」にあるか、または調整の必要があるかを判断するために利用 されます。 QC七つ道具 ④ ヒストグラム（Histogram） データが存在する範囲をいくつかの区間に分け、各区間に入るデー タの分布を棒グラフで表した図。 リスクの定量的分析や、障害の発生分布（ばらつきの全体的な形や散らばり具合） を確認するなどプロジェクトではさまざまな局面で利用されます。 QC七つ道具 ⑤ 散布図（Scattered Diagram） 何らかの相関関係がある二つの要素を縦軸と横軸にとり、測定 値をプロットすることで作成される図。 要素の分布状況を見たり、回帰分析などによって二つの要素の相関関 係を分析したりする際に利用されます。グラフ全体が右上がりの場合 は正の相関、右下がりの場合は負の相関があると言います。 QC七つ道具 ⑥ パレート図（Pareto Diagram） データを項目別に集計して多い順に並べた棒グラフと、その累積を 示す折れ線グラフで構成される図。 項目毎の問題の大きさの順序や、その全体に占める割合などを分析するた めに利用されます。イタリアの経済学者Paretoにちなんで名づけられまし た。 20%の原因を取り除けば、80%の問題発生を抑えられる、という「パレー トの法則」が有名です。累積度数分布図、あるいはABC分析図とも呼ばれ ます。 パレート図 パレート図 40 欠 陥 事 例 件 数 100 35 30 75 25 50 20 15 10 25 5 0 0 A B C D E F G 欠 陥 事 例 比 率 QC七つ道具 ⑦ 層別（Stratification） データや結果をグループ別に分類し、層グラフで表した図。 性質の異なるものを分類して検討する必要がある場合に利用されます。 なお、上記の他、グラフ（棒グラフ、折れ線グラフ、円グラフ、レーダー チャートなど）をQCの道具に含める場合もあります。 9.3.2 新QC７つ道具 「QC７つ道具」が事象の定量的な分析に使われるのに対して、「新QC７つ道具」は主に定性的な分析 に使われます。これらはひとことで言えば分析対象の問題構造に明らかにするための技法です。 １．親和図法 ２．連関図法 ３．系統図法 ４．マトリックス図法 ５．マトリックス・データ解析法 ６．PDPC法 ７．アロー・ダイアグラム法 新QC七つ道具 ①. 親和図法（Affinity Diagram Method） 選定されたテーマに関わるさまざまな事象を整理して、問題点 を明らかにすることで、その解決策を導きだす手法。 さまざまな問題を事実や意見などの言語データとして捉え、そ れらを似たもの同士（親和性を有するもの同士）集めてグルー ピングし、図式化することで、問題の有無や性質を明らかにす る手法です。 親和図法は、川喜田二郎博士が考案したKJ法がその起源になり ます。 新QC七つ道具 ②. 連関図法（Association Diagram Method） 原因と結果、目的と手段といった関係を持つ問題について、それらの関係を矢 線で結ぶ形で論理的に整理して、問題解明に導く手法。 数人のメンバーで連関図を作成する過程を踏むことで、メンバー間のコンセン サスを得たり、発想の転換を図ったりして、問題の核心に迫ることが期待でき ます。 意見やアイデアの抽出にはブレーンストーミング（＊）などの技法が使 われます。 （＊）ブレーンストーミング： グループで意見やアイデアを出し合う方法。 メンバーが順番に次のルールを守りながら意見、アイデアを出していきます。 （1） 批判厳禁：他人の意見やアイデアを批判しない。 （2） 便乗発展：他人の意見やアイデアを参考にしてよい。 （3） 自由奔放：常識に捉われずに自由に発想する。 （4） 量を求む：たくさんの意見やアイデアを出す。 新QC七つ道具 ③. 系統図法 （Tree Diagram Method） ある目的を達成するために、「達成すべき目的」と「その目的 を達成させるための手段」、という関係に展開して、系統図と 呼ばれる階層的な図を作成して目的達成手段を見出す手法。 通常の階層化のステップは以下のようになります。 （１）目的を「◎を△するために」という表現で表し、達成目的を掲げる。 （２）目的達成に当っての制約条件を明確にする。 （３）目的達成の手段を策定して、それを「○を×する」という表現で表す。 （４）策定された手段の妥当性を評価する。 （５） （４）の結果、もし必要ならば、（３）に掲げた表現を次のステップの達成目的「○を ×するために」とする。 （６）上記ステップ（２）～（５）を繰り返して納得できる深さまでブレークダウンして系統 図を作成する。 新QC七つ道具 ④．マトリックス図法（Matrix Diagram Method） 系統図法によって展開された複数の方策について、それらの重み付け（重 要性、優先度）を明確にするときに用いられる手法。 系統図法で目的を展開していくと多くの方策が出されますが、それらをマト リックス図法によって重み付けし、優先順位を設定したりします。 新QC七つ道具 ⑤ マトリックス・データ解析法（Matrix Data Analysis Method, Principal Component Analysis） 別名「主成分分析法」と呼ばれる多変量解析の一手法。 新QC７つ道具の中では唯一の数値データを分析対象にした手法です。 主成分分析法は、相関関係にある多くの変量の値を、できるだけ情報 の損失なしに、1個または少数個の総合的指標（主成分）で代表させ る手法です。 新QC七つ道具 ⑥ PDPC法（Process Decision Program Chart） 問題の発生を事前に予測してそれを未然に防ぐとともに、もし問題が発生し た場合には適切な処置がとれ、結果が大事に至らないように導くための手 法。 目的達成のために、その計画の開始から最終結果に至るすべてのプロセ スを順に矢線で繋げた図を作成します。そして、この作業を通して、実行時 に起こりうる問題を予測してその対処方法（問題をバイパスするなど）を考 えておきます。 1968年、当時の東大工学部の近藤次郎教授が開発した手法です。 新QC七つ道具 アロー・ダイアグラム法（Arrow Diagram method） 作業の順序関係をネットワーク図で表す手法。 プロジェクトを構成する全ての作業をそれぞれ矢線で表し、矢線の間 にノードを配して作業間の順序関係を表します。 スケジューリング技法として知られるPERTとCPMで用いられていま す。 プロジェクトのクリティカル・パスや、作業日程を明確にしたり、作 業日程上の問題点を明らかにしたりすることができます。 信頼度成長曲線 ソフトウェア品質の定量化 ・ソフトウェアの出荷時の信頼性を定量的に評価 ・品質目標との差異を調べ、その品質を達成するために必要な期間と工数を予 測 9.3.3 品質管理のポイント 品質管理の活動 ドキュメント品質管理実施 プログラム品質管理実施 品質管理の活動 品質管理の活動 品質管理活動は、「ドキュメント品質管理」と「プログラム品質管理」の２ つにて実施する。 （１） ドキュメント品質管理 ① ドキュメントをレビューすることにより出来具合を確認する。 ② ドキュメントの設計品質を確認する。特に不良を早期に発見、修正する。 ③ プロジェクトの特徴を十分理解し、後続工程、作業計画を確認する。 （２） プログラム品質管理 ① テスト工程ごとの「試験手順書」に従ってテストを行い、プログラムの出来具合を確認する。 ② テスト結果の評価によりプログラムの品質を確認する。特に故障を早期に発見、修正し品質を向上 させる。 ③ 品質状況（テスト実施状況、バグ発生状況）の報告をする。さらに品質指標値との比較を行う。 ④ トラブル（故障）に対しては、「故障処理票」にて管理する。 ⑤ プロジェクトの特徴を十分理解し、後続工程、作業計画を確認する。 ドキュメント品質管理実施 （１）ドキュメント品質管理の流れ プロジェクトリーダーを中心にチーム内レビューを実施し、出来具合や進捗状況や品質などの確認を行う。これに より、問題点などを整理し、公式レビュー実施のための議題をまとめる。 品質責任者は発生した問題に対しては、プロジェクトリーダーに対して問題解決のための助言、改善提案を行う。 顧客の要求により共同でレビューを実施する場合は、社内でのレビューを終えて、レビュー対象物の品質を確認し た上で実施しなければならない。 工程終了時、プロジェクトリーダーは「レビュー成績書」を記入し、プロジェクトマネージャと承認者に報告する。承 認者は終了基準を確認（ドキュメントの内容が要求品質を満足していることを確認）し、承認する。 （２）レビュー参加者及び役割 公式レビューの参加者と役割について次の表に示す。 レビューはプロジェクトリーダーが議長役を行い、当該設計者がレビューイ、他の参加者はレビューアと なる。 （３）品質の判定について 品質の判定方法 ドキュメントの品質は、レビューで指摘された記述誤りの数によって判定する。 予め設定された品質管理指標値の上限値と下限値の指標値の間に、レビューで指摘された記述誤りの数が収（お さ）まっていた場合は、品質要求が満たされたものと判断する。 プログラム品質管理実施 （１）適用範囲 下記のテスト工程を対象とする。 単体テスト ソフトウェア結合テスト ソフトウェア適性確認テスト システム結合テスト システム適性確認テスト （２）管理手順 テスト工程では、次の品質活動によりテキストを行い出来具合を確認し、プログラムの品質を確保する。 試験手順書に基づきテスト実施 テスト結果の評価 品質状況のチェック トラブル（故障）に対する管理の実施 （３）テスト工程の品質評価 テスト工程の品質評価は、以下に示す３つの観点から評価する。 テスト密度 バグ検出密度 バグ収束率 上記尺度の実績値が予め設定された品質管理指標値の上限値と下限値の間に収まっていた場合、品質要求が満たさ れたものと判断する。 （４）品質の判定について 品質管理指標値は、社内標準またはこれまでのプロジェクトでの経験値を基に設定する。 （５）テスト実施結果の取りまとめ テストごとにプログラム品質管理帳票である「テスト実施報告書」をまとめる。 レビュー 1.品質の定義 品質のマネジメント定義 2.品質マネジメントには、(？)プロセスがある。 3.各プロセスの主なアウトプットは？ 4.品質管理技法としてQC7つの道具は？ Keywords *トータルクオリッティマネジメント(TQM) *品質計画 *フローチャート *特性要因図 *品質保証 *品質管理 *コントロールチャート(管理図) *上方管理限界と下方管理限界 *中心線、平均 復習--品質マネジメント 品質計画 計画フェーズ 品質保証 品質管理 実行フェーズ コントロールフェース 計画を立てる 立てる計画を実行する 実行いた結果を測る どんな品質管理基準を 品質基準どおりにいって 洗い出した結果から 設けるのか？どのような いるか洗い出してみる。 エラーを数える。スケジュ その基準に合わせるの そもそも基準は正しいか？ールどおりにいっている か(どこをチェックすれば か測ってみる。計画とズレ 『基準にあっている』とい が生じるようなら手を打つ えるのか) ジャストインタイム (JUST IN TIME) 今日の内容--人的資源マネジメント プルジェクト人的資源マネジメントは、単なるプロジェクトチーム メンバーを対象とするものではなく、プロジェクトに関するメンバ ー(プロジェクトのステークホルダー)全体を、プロジェクトの目的 達成のために効果的に活用するためのマネジメント。 PMBOKでは、プロジェクト人的資源マネジメントは、『組織計 画』、『要因調達』、『チーム育成』の三つのプロセスで構成する。 PMBOKプロセス群と知識エリアのマップ プロセス群 立ち上げ 計画 実行 コントロール プロジェクト計画の策定 プロジェクト 計画の実行 統合変更管理 終結 知識エリア 統合マネジメント スコープ・マネジメント 立ち上げ スコープ計画 スコープ定義 スコープ検証 スコープ変更管理 タイム・マネジメント アクティビティ定義 アクティビティ順序設定 アクティビティ所要期間見積り スケジュール スケジュール・コン トロール コスト・マネジメント 資源計画 コスト見積り コストの予算化 コスト・コントロー ル 品質マネジメント 品質計画 品質保証 人的資源マネジメント 組織計画 要員調達 チーム育成 コミュニケーション・マ ネジメント コミュニケーション計画 情報配布 リスク・マネジメント リスク・マネジメント リスク識別 定性的リスク分析 定量的リスク分析 リスク対応計画 調達マネジメント 調達計画 引合計画 品質管理 実績報告 完了手続き リスクの監視・コン トロール 引合 発注先選定 契約管理 契約完了 人的資源マネジメント 9.4 組織計画 9.5 要因調達 9.6 チーム育成 プロジェクトに影響するを及ぼすマネジメントスキル リーダーシップ 方針の設定、人々を方向付け、動機附ける。 交渉力 問題解決力 組織に対する影響力 人的資源マネジメントのプロセス 人的資源マネジメントとは？ プロジクトに関わる要員に、その持てる能力をプロジェクトの目 的に従って効果的に発揮してもらうための環境を提供する。 人的資源マネジメント 組織計画 計画のプロセス 要員調達 計画のプロセス チーム育成 実行のプロセス PMBOKにおける人的資源(組織)マネジメント プロセス 組織計画 要員調達 チーム育成 主要成果物 説明 *組織(体制)図 *役割(責任)分担表 *要員 マネジメント計画書ほか *プロッジェクトメンバーのアサイン *プロジェクトチーム名簿 プロッジェクトにおけるチームおよ び個人の役割、責任、報告関係を 明確にする。 必用な人的資源を実際にプロジェ クトにアサインし業務実行可能な *業務実行能力の向上 状態にする。 メンバー個人の育成とチームとし *業務評価への基礎情報 てのパフォーマンスの最大化を両 面からアプローチする。 PMBOKにおける人的資源(組織)マネジメント つまり、組織(人的資源)マネジメントとしてなすべきことは 》誰が何をして誰が何を決定するか、および、誰が誰に何を報告し誰から何の 報告を受けるかを明確にする。 》要員計画で必要とされた要員を調達、手配しプロジェクトにアサインする。 》個人として最大限のパフォーマンスが発揮できるようナビゲートするとともに、 チームまたはグルーップとしても最大限ののパフォーマンスが発揮できるようにする。 9.4.1 組織計画プロセス 組織計画 *プロジェクト組織内における役割、責任、報告関係(命令システム)を定め、 文書化し、割り当てることである。 インプット １．プロジェクトの インターフェース 2. 要員に対する要求事項 3．制約条件 ツールと技法 アウトプット １．役割と責任の 1. テンプレート ２．人事慣行 ３．組織論 ４．ステークホルダー分析 割り当て ２．要員マネジメント 計画書 ３．組織図 9.4.2 組織計画--手順 『組織計画』は、プロジェクト組織を立ちあげるために、そのプロジェクトが置 かれた内外環境や、ステークホルダーの技術的な役割などを整理、認識し、 必要な要員の要求事項や制約事項を考慮しながら組織構成を作り上げる プロセスである。 各人的資源の役割と責任を明確するために用いられる整理の仕方としては WBS毎に人員の責任を定義する『責任分担マトリスク』などの整理方法が ある。 プロジェクトは期間を限定した有期的な組織活動なので、必要な要員をプロ ジェクトのどの時期でどれだけ必要とするかを表現する『資源ヒストグラム』 などを用いて過不足の無い人の資源の期間配分を計画するのある。 これらの方法で計画されたアウトプットは『要員マネジメント計画書』にまと められた。 これに基づいて、母体組織や外部組織との交渉によって『要員調達』が行 われる。 9.4.3 組織計画--責任分担(1) 役割と責任分担 そのプロジェクトで誰が何をするかは、責任分担マトリクスで規定される。シ ニアマネッジヤ、プロジェクトマネージャー、スポンサー、チームメンバーなど、 PMIイズムとリアルではほぼ同じといえる。しかし、経験だけで答えていると足元をす ぐわかる。 プロジェクトスポンサーの役割 シニアマネージャの役割 ステークホルダーの役割 機能部門マネーッジャの役割 9.4.3 組織計画--責任分担(2) プロジェクトスポンサーの役割 プロジェクトに対し資金を供給する人。注意したいのは、『プロジェクトスポン サー≠顧客』という場合があるということ。 *顧客と共に、プロジェクトの成果物を正式に受領する。 *顧客と共に、マイルストーンやイベント、納品日などを設定する。 *プロジェクト憲章にはサインしない。それはマネージャの仕事。 *顧客と共にリスクの許容範囲を決める。 9.4.3 組織計画--責任分担(3) シニアマネージャの役割 シニアマネージャにとって組織上の上司にあたるのがシニアマ ネージャ。スポンサー、機能部門マネージャ、顧客、プロジェク トマネージャに対しマネジメントを行う。 》プロジェクト憲章を発行する/サインする。これにより、誰がプロ ジェクトマネージャなのか、何を目的としたプロジェクトなのか がハッキリする。 》プロジェクト計画書を承認する。 9.4.3 組織計画--責任分担(3) 》三つの制約条件(コスト、時間、品質)の優先順位を決める。 》プロジェクト間の優先度を決める。 》プロジェクトを『外部の影響』から守る。いわゆるノイズ。 9.4.3 組織計画--責任分担(4) チームメンバー役割 計画フェーズでは主にWBSを作成するのを手伝い、実行フェー ズではそれぞれのTASKを熟し、計画からのズレがないか目を 光(ひか)らせる役割がある。 》WBSを作る 》 TASK間の依存関係を特定する。 》コストと時間の見積もりをする。 》計画と実績のズレをみつける。 9.4.3 組織計画--責任分担(5) ステークホルダーの役割 『プロジェクトにかかわる人』を総称していう。 》プロジェクトの期間を通じ、情報が伝達される。 》プロジェクト計画書が変更されたことが知らせる。 》プロジェクト憲章やスコープ定義書を作成する上での具体的 な情報をもつ。 》プロジェクト計画書の作成に参加する。 》制約条件を特定させる。 》リスクマネジマントに参加する。 9.4.3 組織計画--責任分担(5) ステークホルダーの役割 》プロレクト情報を必要とする(その品質、スコープで商品、サー ビスとして成立するかの問題に答えるために) 》リスクを共用する 9.4.3 組織計画--責任分担(6) 機能部門マネージャの役割 》プロジェクトマネージャが必要とする特定の人才をプロジェク トへ提供する。 》Go, Not Go決定に関わる。 》プロジェクト計画書を承認する。 9.4.3 組織計画--責任分担(7) プロジェクトマネージャの役割 プロジェクトマネジメントに対し責任を負う(おう)人。 》できるだけ初期の段階で指名される。 》必要な権威と説明責任を与えられるべき。 》非実なスコープ/品質/納期に対抗できる方法を持つべき。 》プロアクティブで(先見の明が)ある。 9.4.3 組織計画--責任分担(7) プロジェクトマネージャの役割 》どうしてもその必要があるとき、『ノー』といえるべき。 》プロジェクトの失敗について責任を負う。 》プロジェクトについては責めを負うが、資源についてはその限 りではない。 》プロジェクト対象の技術のエキスパートである必要はない。 9.4.4 組織計画--責任分担マトリックス 責任分担マトリックスの例 WBS 番号 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 作業項目 自社 顧客 PM PL PT PS CPM CPS 開発準備 責任 支援 支援 プログラム設計 支援 責任 支援 マニュアル作成 承認 責任 支援 コーディング 支援 責任 支援 単体テスト 支援 責任 支援 結合テスト 支援 責任 支援 シスエムテスト 責任 支援 支援 シスエムテストレビュ- 責任 支援 支援 承認 承認 承認 9.4.5 組織計画--ツールと技法 ツールと技法 『組織論』は組織をどのように構築し得るか、また構築すべきか記録したも のである。 *マズローの『欲五段階説』 自己実現欲 自己欲 親和欲 安全欲 生理欲 9.4.6 組織計画--体制図 プロジェクト体制図 顧客 プロジェクト マネージャ プロジェクト リーダー プロジェクト メンバー 協力会社 プロジェクト マネージャ プロジェクト リーダー プロジェクト メンバー テクニカル サポート プロジェクト メンバー プロジェクト リーダー 9.5 要員調達 要員調達 プロジェクトに必要な人的資源(要員)を保証することである。 インプット 1 要員マネジメント計画書 2 要員プール記述書 3 雇用習慣 ツールと技法 1交渉 2先行任命 3調達 アウトプット 1任命されたプロジェクト 要員 2プロジェクトチーム名簿 9.5.1チーム育成--プロセス チーム育成 *プロジェクトのパフォマンスを向上させるのに必要な個人もしくはグループ のスキルを向上することである。 *『チーム育成』は、集められる要員が、プロジェクトの目標に向かってチー ム意識をもって活動できるようにするためのプロセスである。 インプット 1 プロジェクト要員 2 プロジェクト計画書 3 要員マネジメント計画書 4 実績報告書 5 外部からのフィードバック ツールと技法 1 チーム活動 2 一般的なマネジメントスキル 3 償制度 4 作業場所の集結 5 トレーニング アウトプット 1 業務実行能力の向上 2 業務評価へのインプット 9.5.2 チーム育成--プロマネに対する要求 プロジェクトマネージャには要求されていること *動機附け(参加意識をもたせる、良い人間関係を筑り上げる) *適正なアサイン(能力、経験、資質、意欲を考慮してアサイン) *人才育成に基づいたメンバー配置 *正当な業績評価 9.5.3 チーム育成のための理論 動機附け理論: 動機附け理論とは、人々がある活動を起こす理由や、その結 果期待された成果を挙げるための働きかけ方などを示すもの。 マズローの『欲求階層』 ハーツバーグの『衛星理論』 マネージメント姿態に関する理論: マクレガーの『X理論、Y理論』 9.5.3 チーム育成のための理論(その1) マズローの『欲求階層』 人間は自己の欲を満足サセルために努力する。 第1層: 第2層: 第3層: 第4層: 第5層: 基本的な生理的欲 安全と治安に対する欲 社会的欲 自己の充実に対する欲 自己実現に対する欲 9.5.3 チーム育成のための理論(その2) ハーツバーグの『衛星理論』 『動機附け衛星理論』とも言う。 動機附けには動機要因と動機附け要因の二つの要素がある。 *動機要因は、作業環境に関係し、不満足感を防止。 *動機附け要因は、作業の本質や機能を果たすことで得られ、 満足感につながる。 9.5.3 チーム育成のための理論(その3) マクレガーの『X理論、Y理論』 *X理論(理論信じマネジャー) 1)普通の人間は生まれつき仕事が嫌いである。 2)大体の人間は強制、命令、処罰などを伴う企業目標達成の ために十分な力を発揮することはない。 3)普通の人間は命令されることは好み、責任を回避したが り、野心をもたず、安全を求める。 9.5.3 チーム育成のための理論(その3) *Y理論(理論信じマネジャー) 1)仕事で心身を使うのはあたりまえのことである。 2)統制や威圧のみが従業員をして企業目標達成に努力させる 手段ではない。 3)努力の度合いは目標達成に伴う報酬次第である。 4)普通の人間は安全が脅かされぬ限り責任を引き受け、かつ 進んで責任をとろうとする。 5)企業内の問題を解決しょうとする能力は、大体の従業員に備 わっている。 6)現代の企業においては、従業員の知的能力は僅かしか生か されていない。 マクレガーは、X理論からY理論への転換によって、組織の雰 囲気が根本的に変わると指摘している。 9.5.4 対立解決マネジメント 対立解決マネジメントの技法としては次の5種類がしられていま す。 *強制 (Forcing) *円滑 (Smoothing) *撤回(Withdrawal) *妥協 (Compromising) *対決 (Confronting) 9.5.4 対立解決マネジメントの技法(その1) 強制 (Forcing) 権威をもった当事者による解決策の一方的な押しつけ。 これは場合によっては久的な解決方法にもなりえますが、最適 とは限りません。 通常 (一方が負利益をとる)の解決法と言われています。 9.5.4 対立解決マネジメントの技法(その2) 円滑 (Smoothing) 対立している当事者同士の了承の上で、表面上の争いを小さく 扱う、いわば仮の解決法。 問題は潜行して再燃する場合んもある。問題の再認識により再 び対立が生じることになり、久的な解決方法とはいえない。 Lose-Lose(当事両方が不利益をとる)の解決法といわれている。 9.5.4 対立解決マネジメントの技法(その3) 撤回(Withdrawal) 一方の当事者のあきらめ。 一方の当事者が問題解決のための話し合いなど拒否している。 両方にとって棚上げ状態にしかならず、最も悪い解決法といわ れている。 時間が経てば問題が解決あるいは縮小するような場合に用い られることがある。 これもLose-Loseの解決法です。 9.5.4 対立解決マネジメントの技法(その4) 妥協 (Compromising) 当事者の譲歩により両方の主張のレベルを落とした解決法。 当事者両方に良い関係の維持が必要な場合にこの方法がとら れることがあり、明確な合意の上で久的な解決方法にもなる。 当事者両方にとって100%の満足は得られませんが、の関係に なるので、やの関係附けはない。 9.5.4 対立解決マネジメントの技法(その4) 対決 (Confronting) 問題解決手法( )ともいい、最適な対立解決方法。 当事者両方が客観的な事実の調査結果に基づいて議論を尽く して解決策を見出す積極的な姿態を伴った解決法です。 久的な解決方法となり、これによって対立は解消され、Win-Win の関係になる。