ソフトウェア開発及びソフトウェア

プロジェクトマネジメント（ IX ）

北航软件学院马平 博士 副教授maping@buaa.edu.cn

レビュー１．コスト・マネジメントには、（？ ）のプロセスがある。　　各プロセスの主なアウトプットは？

２．ソフトウェア開発の見積りを困難にしている要因は？　　見積り技法は何種類がある？　　各技法の特徴、使用上の注意は？

３． 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 分析図とも呼ばれます。

パレート図パレート図

5

10

15

20

25

30

35

40

A B C D E F G

欠陥事例件数 欠陥事例比率

0

75

25

100

50

0

パレート図

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 作業項目 自社 顧客 番号 PM PL PT PS CPM CPS 4.1 開発準備 責任 支援 支援 4.2 プログラム設計 支援 責任 支援

4.3 マニュアル作成 承認 責任 支援 4.4 コーディング 支援 責任 支援 4.5 単体テスト 支援 責任 支援 4.6 結合テスト 支援 責任 支援 4.7 シスエムテスト 責任 支援 支援 4.8 シスエムテストレビュ - 責任 支援 支援 承認 承認 承認

9.4.5 組織計画 -- ツールと技法 ツールと技法 『組織論』は組織をどのように構築し得るか、また構築すべきか記録したものである。 *マズローの『欲五段階説』 自己実現欲 自己欲 親和欲 安全欲 生理欲

9.4.6 組織計画 -- 体制図 プロジェクト体制図

顧客 協力会社プロジェクトマネージャ プロジェクトマネージャ プロジェクトリーダープロジェクトリーダー プロジェクトリーダー テクニカルサポート

プロジェクトメンバー プロジェクトメンバー プロジェクトメンバー

9.5 要員調達 要員調達 プロジェクトに必要な人的資源 ( 要員 ) を保証することである。

インプット ツールと技法 アウトプット 1 要員マネジメント計画書 1 交渉 1 任命されたプロジェクト

2 要員プール記述書 2先行任命 要員 3 雇用習慣 3 調達 2 プロジェクトチーム名簿

9.5.1 チーム育成 -- プロセス チーム育成 *プロジェクトのパフォマンスを向上させるのに必要な個人もしくはグループ のスキルを向上することである。 * 『チーム育成』は、集められる要員が、プロジェクトの目標に向かってチー ム意識をもって活動できるようにするためのプロセスである。

インプット ツールと技法 アウトプット 1 プロジェクト要員 1 チーム活動 1 業務実行能力の向上 2 プロジェクト計画書 2 一般的なマネジメントスキル 2 業務評価へのインプット

3 要員マネジメント計画書 3 償制度 4 実績報告書 4 作業場所の集結 5 外部からのフィードバック 5 トレーニング

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 の関係になる。