ソフトウェア開発及びソフトウェア プロジェクトマネジメント（V）

Presentation on theme: "ソフトウェア開発及びソフトウェア プロジェクトマネジメント（V）"— Presentation transcript:

1 ソフトウェア開発及びソフトウェア プロジェクトマネジメント（V）
北京航空航天大学软件学院 马 平 博士 副教授

2 第5回 プロジェクトマネジメント概論 及び統合マネジメント
第5回 プロジェクトマネジメント概論 及び統合マネジメント 5.1　プロジェクト、プロジェクト・マネジメントとは 5.2　ITプロジェクトの特徴と必要スキル(skill) 5.3　日本のプロジェクト・マネジメント 5.4　PMBOK(Project Management Body of Knowledge) の紹介 5.5 プロジェクトマネジメントの作業

3 第5回 プロジェクトマネジメント概論 及び統合マネジメント
第5回 プロジェクトマネジメント概論 及び統合マネジメント 5.6 統合マネジメントのプロセス 5.7 プロジェクト計画の策定と実行 5.8 統合変更管理

4 5.1 プロジェクト、プロジェクト・ マネジメントとは
5.1　　プロジェクト、プロジェクト・ マネジメントとは 一般的なプロジェクトの概念 国際的な基準によるプロジェクト プロジェクトの特徴 プロジェクトの各フェーズ(phase) プロジェクトの成功定義 プロジェクト失敗の原因

5 5.1 プロジェクトとは（Ⅰ） １．一般的なプロジェクトの概念
5.1　プロジェクトとは（Ⅰ） １．一般的なプロジェクトの概念 「特定の業務を計画・執行するために、その仕事が完成するまでの活動を行うために編成されるもので、完成するとプロジェクトは解散することになる」という動的なチーム活動のことを指している。 1.1　一般的なプロジェクトの概念は次の通りです。 「特定の業務を計画・執行するために、その仕事が完成するまでの活動を行うために編成されるもので、完成するとプロジェクトはプロジェクトは解散することになる」という動的なチーム活動のことを指しています。プロジェクトの「目的」や「開始」、「終了」が明確であり、長期的な性質の「機能（ライン組織）」型と異なり仕事のメンバーのモラールを高めるという効果もあります。

6 5.1 プロジェクトとは（Ⅱ） ２．国際的な基準によるプロジェクト （1）PMI-PMBOKプロジェクトの定義
5.1　プロジェクトとは（Ⅱ） ２．国際的な基準によるプロジェクト （1）PMI-PMBOKプロジェクトの定義 プロジェクトとは、独自の成果物または、サービスを創出するための有期的活動である。独自性とは創出する成果物やサービスがある部分で他と類似性（るいじせい）はあっても基本的な点で唯一無二（ゆいいつむに）であること、有期性とは明確な開始点と終了点があること。 　PMI-PMBOKプロジェクトの定義 プロジェクトとは、独自の成果物または、サービスを創出するための有期的活動である。独自性とは創出する成果物やサービスがある部分で他と類似性（るいじせい）はあっても基本的な点で唯一無二（ゆいいつむに）であること、有期性とは明確な開始点と終了点があること。 分かりやすい表現を用いれば「プロジェクトは、過去に似たプロジェクトが存在したとしても、基本的には2つと同じプロジェクトがない。そして、活動には必ず明確な開始が存在し、成果物やサービスを生み出す活動である。そして活動は必ず明確な終了が存在する。」と定義しています。 SEI_CMM!によるプロジェクトの定義 CMMIのモデルにおいて、「プロジェクトとは」、相互に関連し合う管理された一連の資源であって、一つ以上の成果物を顧客または最終利用者に納入するものである。この一連の資源には、明確な開始と終了があり、典型的には計画に従って運用される。そのような計画は、頻繁に文書化され、そして納入または実装される成果もの、使用される資源と資金、実施される作業及び作業を実施するスケジュールが明記される。一つのプロジェクトが、複数のプロジェクトから構成される場合もある。

7 5.1 プロジェクトとは（Ⅲ） ２．国際的な基準によるプロジェクト
5.1　プロジェクトとは（Ⅲ） ２．国際的な基準によるプロジェクト （２）SEI_CMMI （ Software　Engineering　Institute 　Capability　Mature　Model　Integration）によるプロジェクトの定義 CMMIのモデルにおいて、「プロジェクトとは」、相互に関連し合う管理された一連の資源であって、一つ以上の成果物を顧客または最終利用者に納入するものである。この一連の資源には、明確な開始と終了があり、典型的には計画に従って運用される。そのような計画は、頻繁に文書化され、そして納入または実装される成果もの、使用される資源と資金、実施される作業及び作業を実施するスケジュールが明記される。一つのプロジェクトが、複数のプロジェクトから構成される場合もある。 SEI（Software　Engineering　Institute）は米国の連邦基金研究開発センターの１つです。ソフトウェア改善技術における世界の中心的存在となっています。 SEI－CMMI（ Software　Engineering　Institute 　Capability　Mature　Model　Integration）：米国カーネギー・メロン大学のソフトウェア工学研究所が開発した、組織のソフトウェア開発プロセスやマネジメント・プロセスのための成熟度モデルです。 PMI（Project　Management　Institute）のPMBOK（Project　Management　Body　Of　Knowledge）はプロジェクト・マネージャが習得しておくべきプロジェクト・マネジメントのための基礎知識体系です。 本質的には同じことを定義していると言ってもよいでしょう。

8 5.1 プロジェクトとは（Ⅳ） ３．プロジェクトの特徴 プロジェクトには目的がある プロジェクトには始まりと終わりがある
5.1　プロジェクトとは（Ⅳ） ３．プロジェクトの特徴 プロジェクトには目的がある プロジェクトには始まりと終わりがある プロジェクトには不確実さがある プロジェクトには計画がある プロジェクトには制約がある プロジェクトにはプロジェクトマネジメントが必要である 　国家、企業が異なれば生活文化、ビジネス習慣及び法律が異なるのはもちろん企業や組織のマネジメント方法も異なります 　そのため、企業間、プロジェクトに参画するメンバー間で、プロジェクトを誤りなく確実に進めていくには何らかの基準が必要です。この基準がPMIのPMBOK、ISO10006などです。 　またIT分野の品質、生産性向上、効果的なプロジェクト・マネジメント、エンジニアリングのそれぞれのプロセスの組織成熟度に焦点をあてた業界標準となりつつあるSEI_CMMIがあります。 プロジェクトというスタイルで仕事をする際には、これらのことを常に念頭におく必要がある。 まず、目的があり、始まりと終わりがあることは業務上の意思決定の仕方に大きな影響を持つ。人事で言えば、先送りができないのである。意思決定の必要が生じたら、その場で目的に照らし合わせて決める必要がある。 次に計画と不確実さがあることにより、厳密な計画をつくり、計画とおり行ったり、計画をうまく変更していくことにより、いかに目的を達成できるという点により重点が置かれることになる。 次に制約があることにより、制約の中にいかに変動を収めるかが、仕事を進めていく上でのポイントになる。

9 5.1 プロジェクトとは（Ⅳ） ４．ソフトウェア開発プロジェクトのフェーズ ① 受注提案フェーズ ② 企画フェーズ ③ システム設計フェーズ
5.1　プロジェクトとは（Ⅳ） ４．ソフトウェア開発プロジェクトのフェーズ ①　受注提案フェーズ ②　企画フェーズ ③　システム設計フェーズ ④　ソフトウェア開発フェーズ ⑤　システムテスト・導入フェーズ 　プロジェクトの規模が大きくなればなるほどフェーズの構成は複雑になる。宇宙開発とか、経営革新プロジェクトといった大規模なプロジェクトでは、以下のようなフェーズ構成をとることが多いです。 ①　受注提案フェーズ 　　供給プロセスの作業項目（アクティビィ）群をフェーズとした。 ②　企画フェーズ 　　企画フェーズの目的はプロジェクトのコンセプトを決めることであり、またそのコンセプトに基づいて企画をつくりあげること 　　企画プロセスの作業項目群をフェーズとした。 ③　実施フェーズ 　　企画フェーズでつくりあげたコンセプトを具体的な形にします。このフェーズで重要なことは、「全体」との関係を明確にしながら進めることです。 　　システム設計フェーズ 　　開発プロセスのうち、システムの設計に関する作業項目群をフェーズとした。 　 ソフトウェア開発フェーズ 　　開発プロセスのうち、ソフトウェア開発に関する作業項目群をフェーズとした。 ④　導入・運用フェーズ 　　プロジェクトの成果物を定着させるフェーズです。 　　開発プロセスのうち、システムテスト関連と運用プロセスの一部の作業項目群をフェーズとした。

10 5.1 プロジェクトとは（Ⅴ） ５．プロジェクトの成功定義 主なプロジェクトの成功の判断基準と定義
5.1　プロジェクトとは（Ⅴ） ５．プロジェクトの成功定義 主なプロジェクトの成功の判断基準と定義 プロジェクトを見積りのスケジュール内で終了する 顧客から要求されている機能や品質を完全に満たしている 企業（プロジェクト）が利益をあげること 単に品質が優れているだけでなくプロジェクトが生み出すサービス、製品で顧客満足が達成される プロジェクト・メンバー、顧客などステーク・ホルダー（プロジェクトの利害関係者）に満足感がある 　モダン・プロジェクト・マネジメントでは、従来行われてきたQCD／TQMによる品質管理や伝統的なプロジェクト管理より広範囲な意味を持つため、プロジェクトの成功の条件も増えています。 　これまでの品質・生産性に対して主に焦点が当てられていたのに加え「ビジネスの利益やゴール」及び「顧客満足度向上」を達成するための活動が加えられています。

11 5.1 プロジェクトとは（Ⅵ） ６．プロジェクト失敗の原因 ① 顧客ニーズの把握が十分でない ② 仕様が不明確のまま提案・見積りを実施
5.1　プロジェクトとは（Ⅵ） ６．プロジェクト失敗の原因 ①　顧客ニーズの把握が十分でない ②　仕様が不明確のまま提案・見積りを実施 ③　営業・開発の役割分担が不明確 ④　プロジェクト実施計画がないため、 プロジェクト遂行方針ないし枠組みが不明確 ⑤　コミュニケーション不足（特に、営業と開発、メンバー間） ⑥　プロジェクト実行管理の不備（管理能力・経験不足） ⑦　開発に必要な体制となっていない 3.营业和开发的区别 营业技术

12 5.1 プロジェクトマネジメントとは プロジェクトマネジメントとは プロジェクトとプロジェクトマネジメントとの関係
5.1　プロジェクトマネジメントとは 　プロジェクトマネジメントとは 　プロジェクトとプロジェクトマネジメントとの関係 　プロジェクトマネジメントの作業内容

13 5.1 プロジェクトマネジメントとは（Ⅰ） PMBOKの定義
5.1　プロジェクトマネジメントとは（Ⅰ） PMBOKの定義 　 プロジェクトマネジメントとは「プロジェクトの事業主体や他のステークホルダー（当事者としてプロジェクトに関わっているか、またはその利害がプロジェクトによって影響される、個人や組織）の当該プロジェクトに対する要求事項を満足させるために、知識、スキル、ツールおよび技法をプロジェクト活動に適用すること」である。 　プロジェクトの目的は、遂行に関わる経営諸資源（人、物、金、技術、情報）を最も効果的に使用し、「費用」「時間」「品質」の統合化を図りつつ、プロジェクトの目標を達成することである。

14 5.1 プロジェクトマネジメントとは（Ⅱ） プロジェクトマネジメントの真髄 次のような相克する要求事項間の最適バランスを取ることにある。
5.1　プロジェクトマネジメントとは（Ⅱ） プロジェクトマネジメントの真髄 　次のような相克する要求事項間の最適バランスを取ることにある。 ①　スコープ（開発範囲）、タイム、コスト、並びに品質 ②　異なるニーズと期待を持つステークホルダー ③　特定された要求事項 　　プロジェクトマネジメントの成功には、ステークホルダー、管理対象（スコープ、品質、タイム、コスト、リスク等）を常に考慮し、判断事項の優先順位付けを時に応じて正しく行い、バランスよいマネジメントができることが必要である。 　一方、プロジェクトマネジメントは２つの側面から成り立っている。一つは技術的側面（プロジェクト計画、プロジェクト実行管理、管理支援システム、科学管理技術）であり、もうひとつは人的側面（組織運営、人間関係管理）である。 　最近、プロジェクト成功の要因として人的要素（ヒューマン・ソフトスキル）が重要となっている。

15 5.1 プロジェクトマネジメントとは（Ⅲ） モダン(modern)・プロジェクト・マネジメント基本用語 用語名称 役 割
5.1　プロジェクトマネジメントとは（Ⅲ） モダン(modern)・プロジェクト・マネジメント基本用語 用語名称 役　　　　　　　割　 プロジェクト・マネージャ（PM） プロジェクトをマネジメントし、プロジェクトの最終責任を持った人。一般的には、プロジェクトの予算￥開発計画、プロジェクト・メンバーの調達など、承認の権限を持つ。大きな仕様変更や組織外の調整などの責任を持つ。 プロジェクト・リーダー（PL） プロジェクトを実際に推進する。プロジェクト計画の作成、進捗管理などを実施する ステーク・ホルダー プロジェクトに関わる利害関係者。（顧客、PM、開発者） エンジニアリング・プロセス 目的の成果物（製品）を作るための手順を規定するものであり、成果物を作成するために必要なプロセスを技術的に見地より作成したプロセス。 タスク プロジェクトの一部として遂行される単位作業。 プロダクト プロジェクトが開発する製品や導入するシステム アクティビティ 　ステークホルダー： 　プロジェクトの利害関係者は、プロジェクトにより大きく異なるためプロジェクトの初期に明確にする必要がある。 　辞書によれば、「ステーク」とは「何かの結果によって失う危険のある大事なもの」である。代表的には賭け金や投資などであるが、「賭け」の対象という意味で、名声やキャリア、生活環境、安全等々、有形無形の多様なものも含む。つまり、「ステークホルダー」は企業や行政等の意思決定によって、自らの大切なものに大きな影響を受ける人々ということになる。 　例えば企業で考えると、直接的には「投資家」「株主」があげられる。他に金銭的な利害が生じる対象として「ビジネスパートナー」「取引先」「従業員・労働組合」、そして商品・サービスの購買によって利害を受ける「利用者・消費者」などがある。 　従来、企業のステークホルダーとしてはこのような範囲で考えられていたが、社会の持続可能性と企業活動との強い関連に社会的関心が高まる中、企業が責任を負うべきステークホルダーの範囲は拡大している。 　商品・サービス・事業活動が雇用の安定、社会の秩序、倫理等に与える影響を考えれば「地域住民」「産業界」「地方自治体・関連省庁」なども含まれ、また、生活環境、自然環境に与えるリスクを考えると「原料採取、製造、流通、販売、廃棄を行う全ての地域に関わる人々」が含まれることになる。特に、共有する地球環境に対して事業活動が影響を与えているという視点に立てば、影響を受ける範囲は「全人類」「次世代」などにまで及ぶことになる。 　さて、このように拡大するステークホルダー（所謂「マルチ・ステークホルダー」）に対して、企業はどのように対応すべきだろうか。まず、それぞれのステークホルダーに及ぼす影響の内容や大きさ、そしてリスクの緩和方策について明快に説明することが、大事なものを託す相手としての信用を得ることにつながる。そのためにも、様々なステークホルダーの特徴や利害関係、ニーズなどを正確に把握し、それぞれに適切なコミュニケーションを図っていくことが重要な課題である。 エンジニアリング 　タスク： 　作業には通常「時間」「予算」「資源」が割り当てられる。アクテイビティ（作業）との区別は説によって異なり、タスクと同義に用いることもある。また、アクティビティをさらに詳細にした作業を呼ぶ場合もある。

16 プロジェクトとプロジェクトマネジメントとの関係
　プロジェクトとプロジェクトマネジメントとの関係 プロジェクト・マネジメントは、最小限の経営資源でプロジェクトを行うためのマネジメントなのである。 　①　プロジェクトマネジメントがなければ、プロジェクトは成り立たないか？　ノー 　　　プロジェクトマネジメントがなくてもプロジェクトは成り立つ。 　　　しかし、プロジェクトマネジメントがなければ、制約の中にうまく入りきらないかもしれない。 　　　これでは成り立たないのと同じであるし、そのプロジェクトが企業にとって不可欠なものであれば、制約をゆるくせざるを得ない。言い換えると、経営資源を無駄に使うことになる。

17 プロジェクトマネジメントの作業 プロジェクト・マネジメントのステップ 新しいプロジェクトの立案 プロジェクトの開発範囲とリスクの評価
　プロジェクトマネジメントの作業 プロジェクト・マネジメントのステップ 新しいプロジェクトの立案 プロジェクトの終了 プロジェクト計画の作成 プロジェクトの実行、監視及び管理 プロジェクトの開発範囲とリスクの評価

18 プロジェクトにおける２つのプロセス （１） 製品に関するプロセス（開発マネジメントプロセス） （２） プロジェクトマネジメントのプロセス
　プロジェクトにおける２つのプロセス （１）　製品に関するプロセス（開発マネジメントプロセス） 　　プロジェクトの成果物を特定し、生成することに主眼を置く。通常は開発ライフサイクルと成果物によって定義される。ITプロジェクトとして強調すべきプロセスと言える。 （２）　プロジェクトマネジメントのプロセス 　　プロジェクトの業務を説明し、体系化することを主眼に置く。＜人・物・金・技術・情報・・・＞ 　　　PMBOKの９つの知識エリアがこれに相当する。 　この２つのプロセスはプロジェクト遂行期間を通じて重なり合い、相互に影響を及ぼす。 　プロジェクトは２つのプロセスから構成されている。プロセスとは、「プロジェクトの構成要素で、入力を出力に変換する相互に関連した活動のまとまり」であり、結果をもたらす一連の作業意味する。

19 5.2 ITプロジェクトの特徴と必要スキル （１） 従来SI(システム開発)プロジェクト （２） e ビジネス
（３）　ERP(Enterprise Resource Planning)導入 プロジェクト ITプロジェクトの種類・特徴により、プロジェクトマネージャに要求されるスキルは大きく変わる。また、その困難さ、成功／失敗の判断基準も違ってくる。 ここでは3種類のITプロジェクト（SI、eビジネス、ERP導入）を取り上げ、その特徴とプロジェクトマネージャに求められるスキルを述べる。３種のプロジェクトは、いずれも上級プロジェクトマネージャのスキルを必要とする。

20 5.2 ITプロジェクトの特徴と必要スキル（Ⅰ）
（１）　従来SIプロジェクト 　　　特徴は次のとおりである。 ①　初期における正確な見積りが困難（曖昧さ） ②　複雑なシステム開発（計り知れない論理量、柔軟性、目に見えない） ③　規模の巨大化に伴い、日程／費用管理が困難 　　　これに対応するためプロジェクトマネージャとして、以下のことが必要となる。 ①　円滑な顧客・ベンダー間協業の推進能力 ②　開発規模の見極め能力 ③　スケジューリング能力 ④　品質・納期・対価の優先コントロールと利害関係者の調整能力 　ITプロジェクトの種類・特徴により、プロジェクトマネージャに要求されるスキルは大きく変わります。また、その困難さ、成功／失敗の判断基準も違ってくる。 　ここでは3種類のITプロジェクト（SI、eビジネス、ERP導入）を取り上げ、その特徴とプロジェクトマネージャに求められるスキルを述べます。3種のプロジェクトは、いずれも上級プロジェクトマネージャのスキルを必要とします。

21 5.2 ITプロジェクトの特徴と必要スキル（Ⅱ）
（２） e ビジネス 　　　　特徴は次のとおりである。 ①　システム開発が短期間 （4ヶ月から5ヶ月） ②　提案と仕様まとめに顧客とのコミュニケーションが必須 ③　変更多発 　　　これに対応するためプロジェクトマネージャとして、以下のことが必要となる。 ①　納期をベースにすべてを管理してゆくとといった固有の管理ノウハウ。 ②　ユーザ中心によるサービス要件の定義，ビジネスプロセス決定，開発業務の洗い出しと見積りへの対応 リーダーシップトライアングル 　私のリーダーシップに対する理解は、以下の三角形で表現することができます。三角形なので、名付けてリーダーシップトライアングルといいます。 　リーダーシップトライアングルは、特にSI（システム開発）プロジェクトにおけるリーダーシップについて、一定汎用的に考え方をまとめたフレームワーク（枠組み）とご理解ください。 　フレームワークの構成要素を個別に説明しましょう。 　リーダーシップの基礎はCommunicationなので、下のレイヤに置きました。 　リーダーシップの各種教科書にも、リーダーシップとコミュニケーションは表裏一体、切っても切れない関係にあると書かれています。私もこの点は同意します。プロジェクトが大人数になればなるほど、メンバーとの対話が増えるでしょうし、適切にコミュニケーションすることも重要となります。「黙っておれについてこい」というスタイルでは、メンバーはリーダーが何を考えているのか分かりません。 　プロジェクトでは、さまざまなバックグラウンド（経歴や能力のことです）を持った人が集まって、一定期間に与えられたミッションを完遂することが求められます。電子メール、口頭、書面など方式を問わず、対話を通じて共通認識を持つことが重要となることは論を待たないでしょう。問題は、いかに効果的・効率的にコミュニケーションをしていくかということになります。 　さらにいうと、効果的・効率的なコミュニケーションは重要ですが、コミュニケーションの手続きの改善にばかりこだわってしまうと、本質的なことが見えなくなります。次回以降、SIプロジェクトにおけるコミュニケーションの本質についても解説します。 ■リーダーシップの3要素 　Communicationの上に3要素が載ります。3要素は左からVision、Love、Managementです。それぞれを簡単に説明しましょう。 ・Vision 　リーダーたるもの、Vision、つまり先の見通しを提示して部下を率いなくてはいけないということは、概要としてはご理解いただけると思います。先の見通しを何ら示さずに、ただ単に「頑張れ！」「働け！」では、リーダーではないですよね。 　同時に、リーダーがキャリアのビジョンを示すことも、特にSIプロジェクトにおいては重要だと考えます。SIプロジェクトにおいて作業に従事しているのはITエンジニアが多いでしょう。彼らにキャリアのビジョンを提示することは重要です。 　なぜかというと、ITエンジニアはキャリアのビジョンを示され、自分のキャリアにプラスになると理解すれば、作業に専念できるものだからです。いまの仕事が将来のキャリアアップにつながるという説明を怠るリーダーは、なぜ作業者が真剣にならないのかと不満をいうようになってしまいます。 ・Management 　特にSIプロジェクトにおいては、進ちょく管理、品質管理が重要な要素を占めます。SIプロジェクトでは通常、ソフトウェアを設計・開発・テストします（当然ですが）。ソフトウェアの特性として、目で見て確認できないという点が挙げられます。 　人間の視覚は、いわゆる五感のうち、最も発達している感覚だと思います。ソフトウェアは、視覚を使って確認できず、状態が把握しがたいという特性を持ちます。ですから、ソフトウェア開発においては、可視化して管理することが重要となります。管理、すなわちManagementが重要となるのです。 ・Love 　ここまで説明すると多くの人は、CommunicationをベースにVisionとManagementがあれば、Leadershipをその上に載せられると考えがちです。しかし、私の理解は違います。確かにリーダーシップの教科書には、VisionとManagementが重要だと書かれています。しかし、VisionがあってManagementができても、自分自身と部下・上司の「ココロ」（心）の管理ができない人はリーダーたり得ないと私は考えています。 　このココロの考え方を、リーダーシップトライアングルの中心に据えました。言葉としてはLoveですが、男女の愛とか、好き好きという恋愛感情とは異なります。Loveとは儒教でいう仁愛です。他者への思いやりの心、自分の感情をコントロールして正しく生きる精神とでもいいましょうか。詳しくは次回以降で説明します。 　これらの3要素、Vision、Management、そしてLoveがそろって初めて、その上にLeadershipが成り立ちます。この考え方がリーダーシップトライアングルです。 　次回以降、リーダーシップトライアングルの個別構成要素を解説します。次回はCommunicationを解説する予定です。ご期待ください。 　なお、私が主催するブログサイトはリーダーシップトライアングルの構成要素、Communication／Vision／Management／Loveによってトピックが分類されています。興味のある方は参照してくださるとご理解が深まるかと思います。サイトトップページの右上に分類が表示されています。

22 5.2 ITプロジェクトの特徴と必要スキル（Ⅲ）
（３）　ERP(Enterprise Resource Planning)導入 プロジェクト 　　　　特徴は次のとおりである。 ①　業務プロセス設計，ERP適用計画のウエイト(weight)が高い（コンサル(consult/経営)機能） ②　複数の構成・関係メンバーによる推進体制 ③　従来型システムとは設計思想が逆転（システム開発手順が大きく異なる） 　　　これに対応するためプロジェクトマネージャとして、以下のことが必要となる。 ①　上流工程での業務分析と計画策定の能力 ②　複数メンバーのマネジメントのためのコミュニケーション能力 ③　プロトタイプ(Prototype: 試作モデル)のシステム組立及び検証能力 【ITコンサルティングの本質】 それは、情報システムを提案したり設計・開発すること自体ではありません。 ビジネス上でITを活用して革新を起こすためには、様々な課題を解決していかなくてはなりません。 現代の経営課題が複合的な構造をしている以上、ITは万能薬ではなく、あくまでひとつのツールや切り口にすぎないわけです。 複合的な問題を分解して一つひとつの課題を片付けながら、様々なコンサルティングテクニックや知識（論理的思考や方法論、ビジネス知識や戦略への洞察等々）などあらゆるものを活用して「あるべき姿」を描くだけでなく、実現のための仕組み作りを通してクライアントの意識やビジネスを革新し、ビジネスベネフィットを最大限に追求していくということこそが「ITコンサルティング」だと言えるでしょう。

23 5.3 日本のプロジェクト・マネジメント 日本の企業文化や商習慣に影響される KKD（経験、勘(かん） 、度胸(どきょう） ）
国際的な動向に影響される 　勘: 直観, 本能, 天性, 知覚力 度胸: 勇気 日本の場合、従来からの組織の上司がそのままプロジェクト・マネージャになるケースがほとんどですが、これは日本の企業文化の歴史や組織構造が大きく影響しています。日本の企業文化は「「和」もって良しとする」あるいは、「あうんの呼吸(perfect timing)」など日本古来の文化が強く影響を与えています。そのためか、明確な判断基準が存在しなかったり、組織のメンバーと口論になるほど意見をマジ交わしたりすることは不得意としています。また、実際の業務の見積りや計画も「K経験K勘D度胸（どきょう）」と呼ばれるマネジメントが行われているのが現状です。 　しかし、近年の国際的なビジネスの広がりで、これまでの日本型の「あうんの呼吸」や「KKD」によるマネジメントでは通用しない状況にあります。また国際的な動向として、日本に多く見られる階層型・ピラミッド型の深い組織の階層ではなく、プロジェクト型を中心とする組織が多くなっています。このため、日本の企業でも以前のような組織型ではなく、プロジェクト・チームがたの仕事の進め方が取り入れられています。しかし、欧米諸国のような「プロジェクト型」の作業スタイルを行うにはまだまだ大きなギャップと課題があるようです。

24 5.4 PMBOK知識体系の紹介 PMBOKの９つの知識エリア PMBOKの５つのプロセス群

25 5.4 PMBOK知識体系の紹介 PMBOK(Project Management Body of Knowledge)は、プロジェクトマネジメントの遂行に必要な基本的な知識を汎用的な形で体系立てて整理したものである。 PMBOKでは、プロジェクトを遂行する際に、スコープ(プロジェクトの目的と範囲)、時間、コスト、品質、人的資源、コミュニケーション、 ...

26 5.4.1 PMBOK知識エリアの概要（Ⅰ） （１） プロジェクト統合マネジメント （２） プロジェクト・スコープ・マネジメント
（１）　プロジェクト統合マネジメント 　　　　　プロジェクトの多種多様な要素を整合が取れた形で実行するのに必要なプロセス群 （２）　プロジェクト・スコープ・マネジメント 　　　　　プロジェクトが成功に完了するのに必要とする。すべての作業・物理的要素を過不足なく包含するように管理していくのに必要なプロセス群 （３）　プロジェクト・タイム・マネジメント 　　プロジェクトが所定の期日までに完成するように計画・管理するプロセス郡 （４）　プロジェクト・コスト・マネジメント 　　プロジェクトが所定の予算内に完成するように計画・管理するプロセス郡 （５）　プロジェクト・品質・マネジメント 　　　　　プロジェクトが生成された基本的ニーズを確実に充足（じゅうそく）するためのプロセス群。

27 5.4.1 PMBOK知識エリアの概要（Ⅱ） （６） プロジェクト・人的資源・マネジメント
（６）　プロジェクト・人的資源・マネジメント 　　　　　　プロジェクトに参加する人材（ヒューマンリソース）が最も有効に活用さ れるような組織を作り、これを維持するプロセス群。 （７）　プロジェクト・コミュニケーション・マネジメント 　　　　　　プロジェクトの諸情報をタイムリーな生成（せいせい）、収集、配布、保 管そして廃棄に必要なプロセス群。 （８）　プロジェクト・リスク・マネジメント 　　　　　　プロジェクトに内在するリスクを特定し、定量化し、その対応策を策定 するプロセス群。 （９）　プロジェクト・調達・マネジメント 　　　　　　プロジェクトの遂行主体の外部から製品または役務（えきむ）を調達す るためのプロセス群。

28 5.4.2 PMBOKの5つのプロセス群（Ⅰ） （１） 立ち上げのプロセス群 （２） 計画のプロセス群 （３） 実行ののプロセス群
（１）　立ち上げのプロセス群 　　プロジェクト開始に当たっては、プロジェクトあるいはフェーズ着手の必要性を認識して、プロジェクトをコミットする。 （２）　計画のプロセス群 　　ビジネス上の要求を完遂するために、作業可能な計画を立案（プロジェクト計画書）し、それを維持する。 （３）　実行ののプロセス群 　　　計画で定義した作業を、プロジェクト組織内に割り当て実行する （４）　コントロールののプロセス群 　　プロジェクトの目的（定量化された目標値）の達成を保証するために、プロジェクト進捗を監視・測定し、必要に応じて改善策を実施する。 （５）　終結ののプロセス群 　　プロジェクトやフェーズの検収を完了し、プロジェクトを終結にたどり着かせる。 コミット　【commit】 委任［託］; 約束, 責任

29 5.4.2 PMBOKの5つのプロセス群（Ⅱ） ５つのプロセス群の連鎖は下図のようにプロジェクトの各フェーズに現れる。
これら５つのプロセス群の連鎖は図３のようにプロジェクトの各フェーズに現れます。 各プロセスは、そのプロセスに必要なインプット（入力）とプロセスの処理結果として出力されるアウトプット（成果物）、及びインプットからアウトプットを生み出すために利用されるツールと技法から構成されています。 　フェーズ内のプロセスグループは、いろいろなフェーズで重要度を変えながら出現する、重なり合った活動である。各フェーズで立ち上げと終結を繰り返すのは、プロジェクトの要求事項の再確認、プロジェクトの中断の判断などに有効である。なお、フェーズ間でプロセスはオーバーラップが多く出現する（後続きのフェーズの準備など）例えば、システム設計の「終結」で成果物のレビューをし、後続きのフェーズであるソフトウエア開発の「立ち上げ」で前フェーズの成果の確認を行う、などである。さらに、各フェーズは、進行しながら、プロジェクト計画を詳細していく。

30 5.4.3 PMBOK知識エリアとプロジェクトマネジメント・プロセス
図に示すように、PMBOKの９つの知識エリアにはそれぞれ幾つかのプロセスがあり、全体として３９個（PMBOK2000年版）のプロセスが定義されています。

31 5.4.4 PMBOKプロセス群と知識エリアのマップ
　　　　　　プロセス群 知識エリア 立ち上げ 計画 実行 コントロール 終結 統合マネジメント プロジェクト計画の策定 プロジェクト計画の実行 統合変更管理 スコープ・マネジメント スコープ計画 スコープ定義 スコープ検証 スコープ変更管理 タイム・マネジメント アクティビティ定義 アクティビティ順序設定 アクティビティ所要期間見積り スケジュール スケジュール・コントロール コスト・マネジメント 資源計画 コスト見積り コストの予算化 コスト・コントロール 品質マネジメント 品質計画 品質保証 品質管理 人的資源マネジメント 組織計画 要員調達 チーム育成 コミュニケーション・マネジメント コミュニケーション計画 情報配布 実績報告 完了手続き リスク・マネジメント リスク識別 定性的リスク分析 定量的リスク分析 リスク対応計画 リスクの監視・コントロール 調達マネジメント 調達計画 引合計画 引合 発注先選定 契約管理 契約完了 　さて、本図により、５つのプロセス群と対応する9つの知識エリアの関係が一目瞭然となる。また、「計画のプロセス」群に属するプロセスの数が突出して多いのが分かる。（全３９プロセス中２１プロセスが計画のプロセス群に属している） 　このことから、プロジェクトではいかに計画を重視しなければならないか、または計画すべきことがいかに多いかがわかる。そしてプロジェクトの進行段階でのプロジェクトマネジメントとは、計画とのギャップをマネジメントすることと言える。 　　5つのプロセス群は、PMBOKの9つの知識エリアそれぞれでている個々のプロセスを、その活動内容の側面から同じグループに入るものを集めて、5つのグループにマッピングし直したものです。したがって、PMBOKの各プロセスは9つの知識エリアの2つに属すると同時に、5つのプロセス群の1つにも属することになる。 　　プロジェクトマネージャは、これらの管理プロセスを実践することにより、一貫性のある管理、十分なコミュニケーション、生産性の向上などが得られ、プロジェクトの品質を高めることができる。

32 5.5 プロジェクトマネジメントの作業 プロジェクト・マネジメントのステップ 新しいプロジェクトの立案 プロジェクトの開発範囲とリスクの評価
　5.5 プロジェクトマネジメントの作業 プロジェクト・マネジメントのステップ 新しいプロジェクトの立案 プロジェクトの終了 プロジェクト計画の作成 プロジェクトの実行、監視及び管理 プロジェクトの開発範囲とリスクの評価

33 5.5.1 新しいプロジェクトの立案 システム開発構想及び企画の立案 プロジェクトのゴール、評価方法の明確化 リスクの洗い出し
5.5.1　新しいプロジェクトの立案 システム開発構想及び企画の立案 プロジェクトのゴール、評価方法の明確化 リスクの洗い出し 企業戦略と整合性 プロジェクト企画のレビュー

34 プロジェクトの企画書 （初期）リスク管理表 承認されたプロジェクト企画書
5.5.1　プロジェクト立案の主な作業 プロジェクト立案の主な作業 新しいプロジェクトの立案 　　　　　　　　　　　　　　　　　　　 プロジェクトの企画書　　（初期）リスク管理表　　承認されたプロジェクト企画書　 システム開発構想 及び 企画の立案 プロジェクトの ゴール、評価の 明確化 企業戦略の整合 リスクの洗い出し プロジェクト企画 のレビュー

35 5.5.2 プロジェクト計画の策定 プロジェクト計画の策定 プロジェクト組織の決定 要員配置の決定 システム開発範囲の明確化
5.5.2　プロジェクト計画の策定 プロジェクト計画の策定 プロジェクト組織の決定 要員配置の決定 システム開発範囲の明確化 成果物の計画とボリュームの見積り 外注先の検討と決定 開発環境などのツールの検討 プロジェクト計画書の作成 プロジェクト計画書のレビュー

36 プロジェクトの 品質保証 外注管理 構成管理 更新された スケジュール 計画 計画書 計画書 リスク管理表
プロジェクト計画策定の主な作業 プロジェクト計画の策定 　　　　　　　　　　　　プロジェクト構成表　　　　　　　　　　　　プロジェクト計画書　　　　　　　　　　　　　　承認されたプロジェクト計画書 プロジェクト 組織の決定 要員配置 の決定 計画書 のレビュー システム開発 範囲の明確化 スケジュール 計画 開発環境 などのツール の検討 計画書の作成 成果物の計画 とボリューム の見積り 外注先の 検討と決定 予算の計画 リスク管理表の 更新と優先度の 付与対策の検討 プロジェクトの　　　　品質保証　　　　外注管理　　　　構成管理　　　　　　　更新された　 　　　　　　　スケジュール　　　　　　計画　　　　　　計画書　　　　　　計画書　　　　　　　　リスク管理表　　　　　　

37 5.5.3 プロジェクトの監視及び管理 プロジェクトのステータス(status)の監視
プロジェクトの監視及び管理 プロジェクトのステータス(status)の監視 作業進捗に応じた作業のスケジューリングと作業者の割り当て 外注先の作業進捗監視と制御 プロジェクト計画書の更新

38 5.5.3 プロジェクトの実施、監視及び管理の主な作業
プロジェクトの実施、監視及び管理の主な作業 プロジェクトの 監視及び管理 　　　　　　　　　　　　　　更新されたプロジェクト構成表　　　　　　　　　　　更新されたプロジェクト計画書　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 プロジェクト のステータス の監視 作業進捗に応じ た作業の再スケ ジューリングと 担当者の割り当て 計画書の更新 外注先の 作業進捗 監視と制御 リスク管理表の 更新と優先度の 付与対策の検討 プロジェクトの　　　　品質保証　　　　外注管理　　　　構成管理　　　　　　　更新された　 　　　　　　　スケジュール　　　　　　計画　　　　　　計画書　　　　　　計画書　　　　　　　　リスク管理表　　　　　　

39 プロジェクトの終了 プロジェクト検収レビュー プロジェクトの完了の評価

40 5.5.4 プロジェクト終了の主な作業 プロジェクトの終了 プロジェクト 検収レビュー 成果物の納入 完了の評価
プロジェクト終了の主な作業 プロジェクトの終了 　　　　　最終成果物　　　　　　　　　　　　　　プロジェクト完了報告書　 プロジェクト 検収レビュー 成果物の納入 完了の評価

41 5.6 統合マネジメントのプロセス 計画のプロセス 実行のプロセス コントロールのプロセス
5.6 統合マネジメントのプロセス 統合マネジメントは次の図に示す３つのプロセスがある。 　　　　　　　　　　　　　　　　 計画のプロセス 　　　　　　　　　　　　　　　　 実行のプロセス 　　　　　　　　　　　　　　　　 コントロールのプロセス 統合マネジメント プロジェクト計画の策定 統合変更管理 プロジェクト計画の実行

42 5.7 プロジェクト計画の策定(Ⅰ) プロジェクト計画の策定は、次のことを指す ① 他の知識エリアの計画からのアウトプット
　プロジェクト計画の策定は、次のことを指す ①　他の知識エリアの計画からのアウトプット ②　プロジェクト遂行とプロジェクト・コントロールの指針 ③　首尾一貫したプロジェクト計画書の作成

43 5.7 プロジェクト計画の策定(Ⅱ) プロジェクト計画の策定 インプット ツールと技法 アウトプット 1. 他の計画からの アウトプット
5.7 プロジェクト計画の策定(Ⅱ) プロジェクト計画の策定 インプット 1.　他の計画からの 　　アウトプット 2.　過去の情報 3．組織の方針 ４．制約条件 ５．前提条件 ツールと技法 1.　プロジェクト計画法 2.　ステークホルダーの 　　スキルと知識 3．プロジェクト・マネジメント 　　情報システム（PMIS） ４．アーンド・バリュー・ 　　マネジメント（EVM） アウトプット １．プロジェクト計画書 2.　詳細資料

44 5.7 プロジェクト計画の実施 インプット ツールと技法 アウトプット プロジェクト計画の実施は、プロジェクト計画を実施すること。
1.　プロジェクト計画書 2.　詳細資料 3．組織の方針 ４．予防処置 ５．是正（ぜせい）処置 ツールと技法 1.一般的なマネジメント・スキル ２．成果物に対する 　　スキルと知識 3．作業認可システム　　 ４．状況レビュー会議 ５．プロジェクト・マネジメント 　　情報システム（PMIS） ６．組織の手続き アウトプット １．作業結果 2.　変更要求

45 5.7.1 プロジェクト実施計画書作成プロセス プロジェクト実施計画書作成プロセス （１） プロジェクト計画 作成作業の準備 （２）
プロジェクト実施計画書作成プロセス プロジェクト実施計画書作成プロセス （１） プロジェクト計画 作成作業の準備 （２） プロジェクト の定義 （３） プロジェクト管理 プロセスの定義 （４） 役割と責任の 定義 （５） WBSと見積り 作成 （６） スケジュールと リソース計画 （７） 収支計画 （８） リスク識別と 不測時対応計画 （９） の完成 （１０） 計画のレビュー と承認

46 5.7.2 プロ実施計画書の記述内容 （１）プロジェクト概要 （２）プロジェクト定義 （３）プロジェクト体制 （４）作業項目及び見積り
プロ実施計画書の記述内容 通常、プロジェクト実施計画書には以下の内容を記述する。 （１）プロジェクト概要 （２）プロジェクト定義 （３）プロジェクト体制 （４）作業項目及び見積り （５）資源 （６）工程スケジュール （７）レビュー及び承認 （８）リスクと対応策

47 5.8 統合変更管理 インプット ツールと技法 アウトプット
変更要求に対する効率的かつ効果的な統制を行うことである。アウトプットは、「プロジェクト計画書更新版」｢是正処置｣｢教訓｣である。 インプット 1.　プロジェクト計画書 2.　詳細資料 3．組織の方針 ４．予防処置 ５．是正（ぜせい）処置 ツールと技法 1.一般的なマネジメント・スキル ２．成果物に対する 　　スキルと知識 3．作業認可システム　　 ４．状況レビュー会議 ５．プロジェクト・マネジメント 　　情報システム（PMIS） ６．組織の手続き アウトプット １．作業結果 2.　変更要求 　一般的に、変更管理には次のことが要求される。 　（１）実績ベースラインの統合的な改訂作業 　　承認された変更項目はすべてのプロジェクト計画書に盛り込む。一方、進捗度ベースラインの改訂はスコープの変更時のみ実施。 　（２）プロダクト・スコープの変更 　　必ずプロジェクト・スコープの定義に反映させる。 　（３）他の知識エリアとの調整 　　例えば、スケジュールに関わる変更は、多くの場合コスト、リスク、品質、要員配置に影響を及ぼす。

48 レビュー ITプロジェクト・マネジメント概論 プロジェクトの特徴 プロジェクトの成功定義 プロジェクト・マネジメントとは
プロジェクトにおける2つのプロセス 日本のプロジェクト・マネジメント PMBOKのプロセス群と知識エリア プロジェクトマネジメントの作業 統合管理（PMBOKにより） １.　プロジェクトの特徴は？ ２．プロジェクトとプロジェクトマネジメントの関係？ ３．プロジェクトは、二つのプロセスからなり（マネジメントプロセス、プロダクトプロセス）、 　　その関係は（独立し、相互に影響を与え合うものである） ４．PMBOKのプロジェクトマネジメントのプロセス群、知識エリア ５．

49 PMBOKプロセス群と知識エリアのマップ
　　　　　　プロセス群 知識エリア 立ち上げ 計画 実行 コントロール 終結 統合マネジメント プロジェクト計画の策定 プロジェクト計画の実行 統合変更管理 スコープ・マネジメント スコープ計画 スコープ定義 スコープ検証 スコープ変更管理 タイム・マネジメント アクティビティ定義 アクティビティ順序設定 アクティビティ所要期間見積り スケジュール スケジュール・コントロール コスト・マネジメント 資源計画 コスト見積り コストの予算化 コスト・コントロール 品質マネジメント 品質計画 品質保証 品質管理 人的資源マネジメント 組織計画 要員調達 チーム育成 コミュニケーション・マネジメント コミュニケーション計画 情報配布 実績報告 完了手続き リスク・マネジメント リスク識別 定性的リスク分析 定量的リスク分析 リスク対応計画 リスクの監視・コントロール 調達マネジメント 調達計画 引合計画 引合 発注先選定 契約管理 契約完了

50 計画のプロセスの相互関係