プロジェクトマネジメント
プロジェクトマネジメント
プロジェクトマネジメントの目的
情報システムやサービスを開発するとき、「ステークホルダ」が同じ目的意識を持ち、一丸となって計画を遂行することが重要
プロジェクト組織を編成して、組織的に進めることで効率的に計画を遂行できる
ステークホルダ
プロジェクトの発足によってさまざまな影響や利害を受ける人のこと
プロジェクト
●目的や目的の達成に向けた一連の活動である ●「始まり」と「終わり」のある期限付きの活動である ●明確な目的や目標が存在する ●プロジェクトのための組織を編成する ●さまざまな分野から専門知識や豊富な経験を持つ人が集まる ●繰り返しのない非日常的な業務を行う ●決められた経営資源を使って活動する ●目的の達成後は解散する |
プロジェクトマネジメント
チームに与えられた目標を達成するために、人材・資金・設備・物資・スケジュールなどをバランスよく調整し、全体の進捗状況を管理する手法
管理を行うための基本的な考えである「PDCA」サイクルによって管理する

PMBOK
PMBOKとはプロジェクトマネジメントに関する知識体系
目的
●プロジェクトマネジメントに関する知識をまとめることによってプロジェクト
  マネジメントを効率的に実施する
●言葉の定義を統一し、分野や国の違いによるコミュニケーションミスを防ぐ
プロジェクトマネジメントの5つのプロセス群
名称 | 説明 |
---|---|
立ち上げプロセス群 | プロジェクトの目的、予算、成果物などを定義して、そのプロジェクトを許可する |
計画プロセス群 | 目的や目標を達成するための計画を作成する |
実行プロセス群 | 決められて計画に基づき作業を実行する |
監視コントロール・プロセス群 | 計画と実行の差異について継続的に監視を行い、差異があれば是正措置を講じる |
終結プロセス群 | 成果物の受入を確認し、プロジェクトの終結を承認する |

プロジェクトマネジメントの9つの知識エリア
管理対象によって複数の領域に分けられ、この管理対象を「知識エリア」という
名称 | 説明 |
---|---|
プロジェクト統合マネジメント | ほかの8つの知識エリアを統合的に管理する |
プロジェクト・スコープ・マネジメント | プロジェクトの成果物や作業範囲、必要な作業を洗出し管理 |
タイム・マネジメント | スケジュール管理 |
コスト・マネジメント | 資金面の管理 |
品質・マネジメント | 品質管理 |
人的・マネジメント | プロジェクトメンバの要員の管理 |
プロジェクト・コミュニケーション・マネジメント | プロジェクト組織内の意思疎通や情報の共有などコミュニケーションの管理 |
プロジェクト・リスト・マネジメント | プロジェクトに関するリスクの回避・対処法の決定等の管理 |
プロジェクト・調達・マネジメント | 必要な経営資源の選択、発注・契約の管理 |

プロジェクトの体制と自己管理
プロジェクトの体制
機能型組織
営業部、設計部、製造部、品質管理部のように機能や専門性の異なる部門から集められたプロジェクト
特徴: | 従来の業務も行いながら、プロジェクトに参加可能なのでプロジェクト |
を作りやすい プロジェクトにおける経験や知識を蓄積しやすい 指揮命令系統が所属部署のマネージャーになり、プロジェクトマネージャは調整役になる |
プロジェクト型組織
特定のプロジェクト専門のチームを作り、各々のプロジェクトで独立して事業が動かされる
特徴: | プロジェクトマネージャが責任を持って行う |
プロジェクト終了後に解散するため、プロジェクトにおける経験や 知識を蓄積しにくい |
マトリックス型組織
機能型組織とプロジェクト型組織の仕組みを両方活かした組織形態で、組織のメンバーは部門長とプロジェクトマネージャの2人の上司をもつことになる
特徴: | 兼務が可能であり、プロジェクトマネージャの権限を強化したプロジェ |
クトになる 専任のプロジェクトマネージャに権限と責任が集中し、機能部門の責任 家を活用しやすい プロジェクト部門と機能部門との間で、衝突・混乱が起こりやすい |
自己管理
プロジェクトメンバは、与えられた役割を果たすために、自ら「作業計画立案」「進捗管理」「工数管理」「費用管理」などを行います
トレンドチャートを用いて、進捗管理と費用管理を同時に行う
トレンドチャート
計画と実績の時間的推移を実現するのに適し、進み具合並びにその傾向がよく分かり、プロジェクト全体の費用と進捗の管理に利用される

マイルストーン
主要なステップの終了などで、スケジュールの中の特別なチェックポイントを示すタスク
プロジェクトマネジメントの知識
プロジェクト統合マネジメント
プロジェクトマネージャの対象となるスコープ、タイム、コスト、品質、人的資源、コミュニケーション、リスク、調達の8つの知識エリアを統合的に管理すること
プロジェクト憲章の作成 | 許可を得るために、プロジェクトの実施内容を文書化したもの |
---|---|
スコープ記述書暫定版の作成 | プロジェクトの最終的な成果物と作業範囲を記載したもの |
マネジメント計画書の作成 | 実行、監視コントロール、終結の方法について記載したもの |
実行の指揮・マネジメント | 計画書に基づいいて、プロジェクトの実行を指揮し、スコープ記述書に従って作業の達成を支援 |
作業の監視コントロール | 立ち上げから終結までの各プロセスを監視し、必要に応じて是正処置、予防装置をとる |
統合変更管理 | 変更管理委員会を設置、発生する変更を変更管理表として管理する |
プロジェクト終結 | 成果物の受入れ、各種契約の終了手続き、関連文書の整理を通じて、プロジェクトを正式に終結させる |
プロジェクト・スコープ・マネジメント
プロジェクトの目標を達成するために必要な成果物とタスクを、プロジェクト期間を通じて定義していき、その内容をやり遂げることを保証すること
プロジェクトの成功/失敗に大きく影響を及ぼす
プロセス | 主要成果物 | 説明 |
---|---|---|
プロジェクトの立ち上げ | プロジェクト憲章 (チャーター) | プロジェクトの基本事項(目的・目標・主要成果物、概略予算・見積りなど)を定義 |
スコープ計画 | スコープ記述書 | 必要な成果物を定義 |
スコープ定義 | WBS | 成果物を遂行するためのタスクを定義 |
スコープ検収 | 検証(検収)後成果物 | 成果物の検証・検収 |
スコープ変更管理 | 変更後スコープ | 成果物とタスクの見直し・変更 |
WBS(Work Breakdown Structure)
WBSとは、プロジェクトに必要な作業を、具体的な作業スケジュールと進捗が把握可能な単位まで詳細化し、階層構造で表したもの
スコープマネジメントでは、そのプロジェクトにおいて「何をどこまでやるか」という範囲(これをスコープ(scope)と呼ぶ)を決める
スコープ定義では、最終成果を得るための中間成果物を明確にし、それを作るための作業へ展開する。これを階層構造図(または表)にまとめたものがWBSとなる
WBSの最下位レベルの作業項目は、ワークパッケージと呼び、このレベルで様々なマネジメント活動が行われる
WBS作成のメリット
●重複作業の排除と作業漏れの防止
●作業内容と作業担当の明確化
●プロジェクト全体作業の把握
●コミュニケーションの円滑化と情報共有
●プロジェクト作業の意義、位置づけの明確化

ワークパッケージ
WBSの最下層をワークパッケージという
ワークパッケージごとに工数や日程、担当、予算などを割り当てることで、スケジュール、コスト、人員配置、リスクなどの管理がやりやすくなる
プロジェクト・タイム・マネジメント
プロジェクト開始前の計画段階に必要な作業を洗出しスケジュールを作成、そのスケジュールの予定と実績を管理していくこと
重要な点は、スケジュール作成時点では、納期やフェイズの終了時など重要なマイルストーンに大きな影響を与えないことに重点を置き、予定と差異が見られたときに迅速に適切な対応を取る
プロセス | 主要成果物 | 説明 |
---|---|---|
作業定義 | 作業リスト、WBS更新版 | スコープ定義で作成したWBSに基づき、実際の作業に分割する |
作業順序設定 | プロジェクトネットワーク図 | 作業間の順序関係を定義する |
作業所要時間の見積り | 作業ごとの所要時間見積 | それぞれの作業を完成させるために必要な所要時間を見積もる |
スケジュール作成 | プロジェクトスケジュール | 作業の開始日・終了日を決定する |
スケジュール管理 | プロジェクトスケジュール更新版 | 進捗度を測定し、スケジュール変更の管理を行う |
所要時間の見積もり表(PERT図)
PERTとは、製品開発の日程計画を立てる時の技法で、複雑な仕事の処理順序の関係をアローダイアグラムによって表現し、プロジェクトの開始から終了に至るまでの仕事の処理時間に余裕のない経路(クリティカルパス)を明確にして、予定工期までにプロジェクトを完成できるかどうかの計画の実行可能性を検討し、管理の重点を明らかにする手法
例)![]() クリティカルパスは、@→A→B→C→D→Eとなり、合計20日かかる 作業Eの最遅開始日を求めるには、作業Gの最遅開始日は20−3=17日 よって、17−4=13日という日にちが、作業Eをぎりぎりその日に開始すれば作業全体の遅れが生じない日となる |
プロジェクト・コスト・マネジメント
承認された予算内でプロジェクトを完了させることを目的とし、他のマネジメント領域と同様、「Plan-Do-See-Action」のサイクルになっている。つまり、プロジェクト期間中、コスト見積もりは常に見直され、最新の状態に保たれていなければならない
プロセス | 主要成果物 | 説明 |
---|---|---|
資源計画 | 必要資源量 | 機器など物理的にどのくらいの資源が必要かを決定する |
コスト見積もり | コスト見積もりなど | プロジェクトの完成に必要な資源の予想コストの合計 |
予算設定 | コストベースライン | コスト実績を管理するために時系列に予算を配分したもの |
コスト管理 | 改定コスト見積もり | 進捗度を測定し、コスト見積もりの変更管理を行う |
名称 | 説明 |
---|---|
ファンクションポイント法 | ソフトウェアの持つ機能の数をもとに、そのソフトウェアの規模を測定する手法で、ソフトウェアの開発費用や工数などを算定する際に使われる |
三点見積法 | 楽観値、期待値、悲観値のシナリオに基づいて、予想される結果を評価する方法 |
類推見積法 | 過去の類似の開発事例から開発規模を類推する方法 |
ボトムアップ見積法 | コスト見積の中で一番重要なやり方、なるべく一番下のレベル、例えばアクティビティレベルでコストを見積り、それを足し合わせるという手法 |
LOC法 | プログラムステップ数に生産性を掛け合わせて行う見積り。要求仕様から開発するプログラムのコード数を推定し、そのコード数と1コードあたりの生産性から全体の工数を見積もる |
COCOMO法 | 開発するソフトウェアの行数を把握し、その行数に補正係数を掛け合わせて開発工数に換算する手法 |
プロジェクト・品質・マネジメント
プロジェクトのニーズを確実に満足させるためのプロセスであり、品質方針、目標および責任を定め、それらを達成するために、品質計画、品質保証、品質管理および品質改善を実施していくこと
プロセス | 主要成果物 | 説明 |
---|---|---|
品質計画 | 品質マネジメント計画書など | 品質を保証し改善していくための組織構造、責任、手順、プロセスおよび経営資源を定義したもの |
品質保証 | 品質改善 | プロジェクトの成果物とプロセスが適切な品質かどうかを保証するために行う行動。例)品質監査など |
品質管理 | 品質改善受入れの決定プロセスの調整など | プロジェクトのあらゆる活動結果が適正かどうかを歓談するために、結果をモニタし、必要に応じて対応していくこと |
名称 | 説明 |
---|---|
ベンチマークテスト | システムの処理能力を比較するためのテスト。標準作業を設定し、それぞれの製品で実行に要する処理時間などを測定することで性能を比較する |
ウォークスルー | エラーの早期発見を目的として、少人数で短時間に行うレビュー方法 |
レビュー | 上位者が下位者の作成した成果物を確認し、修正指示や承認を与える作業 |
テスト | ソフトウェアのバグを発見し、想定どうり正しく動作するかを確認して、品質を評価する作業 |
管理図 | 品質特性の変動を時間軸でプロットし、不良品やエラーの発生といった異常値を検出するために利用される図 |
プロジェクト・人的資源・マネジメント
組織(人的資源)マネジメントは、プロジェクトに関与する人々を最も効果的に活用するために必要なプロセスからなる
プロジェクトメンバの人選時に考慮すべき点
●プロジェクトに参加可能な期間 ●能力や専門知識の有無 ●過去のプロジェクト経験 ●プロジェクトへの関心度 ●プロジェクトメンバの調達コスト |
プロセス | 主要成果物 | 説明 |
---|---|---|
組織計画 | ・組織(体制)図 ・役割(責任)分担表 ・要員マネジメント計画書 など | プロジェクトにおけるチームおよび個人の役割、責任、報告関係を明確にする |
要員調達 | ・プロジェクトメンバのアサイン ・プロジェクトチーム名簿 | 必要な人的資源を実際にプロジェクトにアサインし業務遂行可能な状態にする |
チーム育成 | ・業務遂行能力の向上 ・業務評価への基礎情報 | メンバ個人の育成とチームとしてのパフォーマンスの最大化を両面からアプローチする |
プロジェクト・コミュニケーション・マネジメント
コミュニケーションマネジメントは、プロジェクト情報の生成、収集、配布、保管、廃棄をタイムリーかつ確実に行うために必要なプロセス
プロセス | 主要成果物 | 説明 |
---|---|---|
コミュニケーション計画 | ・コミュニケーション マネジメント計画書 | 情報の提供手段を決定する。例えば、会議や個人スケジュール、プロジェクトの連絡事項の通知方法、議事録の作成者と配布・回復方法の定義など |
情報配布 | ・プロジェクト記録 ・プロジェクト報告書 ・プレゼンテーション | 必要とされる情報を適切な手段で適切なタイミングで関係者に実際に提供するプロセス プロジェクト記録:連絡文書、議事録等プロジェクト文書 |
実績報告 | ・実績報告書 ・変更要求 | プロジェクトの目標達成に向けて、どのように資源が使われており、どの程度達成されているかを関係者に知らせるための情報を収集し配布すること |
完了手続き | ・プロジェクトの公式記録 ・プロジェクトの終了 | プロジェクト、またはフェイズの目標達成、あるいは中断や中止による終了時に行う作業を指す |
●文書、口頭、電子メールなどの伝達手段の長所、短所を知る ●状況に応じて複数の伝達手段を使い分ける ●相手の経験や知識レベルに合わせて用語を使い分ける ●相手の表情から理解度を読み取る ●一方的に伝えるだけでなく、相手の意見や感想を引き出す |
プロジェクト・リスク・マネジメント
プロジェクトのリスクを識別し、分析し、リスクに対応するための系統的なプロセスで、プロジェクトの目標に対してプラスに働く事象にはそれが起こる確率とその発生結果が最大となるように、マイナスに働く事象については逆に最小となるようにすること
プロセス | 主要成果物 | 説明 |
---|---|---|
リスクマネジメント計画 | リスクマネジメント 計画書 | リスクマネジメント計画時点で、プロジェクトで発生するリスクをどのようにマネジメントしていくかを決めること |
リスク識別 | 認識されたリスク、トリガーなど | 関係者からの話や、成果物のレビューなどを基にプロジェクトのリスク事象を把握する |
定性的リスク 分析 | リスク優先順位リストなど | 認識されたリスクを「影響度」と「発生確率」から優先順位で評価する |
定量的リスク 分析 | 定量化したリスクの優先順位リストなど | 優先順位付されたリスクを数量的に分析し、影響を考慮し、どのリスクにどの程度注力するかを決める |
リスク対応計画 | リスク対応計画書など | 個別のリスクへの対応策で、発生しないような対処、発生時の影響を最小限にする施策を取りまとめる |
リスクの監視コントロール | 迂回策の計画など | いったん識別されたリスクは、必要がなくなるまでプロジェクト期間を通じてモニタし続ける必要がある |
プロジェクト・調達・マネジメント
プロジェクト調達マネジメントとは、プロジェクト・スコープを達成する目的で、母体組織の外部から物品やサービスを取得するために必要な一連のプロセスで構成される
プロセス | 主要成果物 | 説明 |
---|---|---|
調達計画 | 調達マネジメント計画書 作業範囲記述書(SOW) | :調達プロセスをどのようにマネジメントしていくかを決めること :納入者(受注者)が実施する作業、納品する成果物などの契約範囲を記述するもの |
引き合い計画 | 調達文書、評価基準ほか | 「調達文書」はさまざまな呼び名があるが、一般的にいう「RFP(Request for Proposal:提案依頼書)」のこと。「評価基準」はどいういう基準で協力会社を選定するかを定義したもの |
引き合い | 提案書(の受領) | 協力会社から提案書(見積書)を受領する |
発注先選定 | 契約 | 提案書を比較検討し、候補企業と内容の確認や条件交渉を行い合意に達したら、お互いの責任と義務を明文化し契約を取り交わす |
契約管理 | コレスポンデンス | :協力会社との対応履歴のこと |
契約完了 | 契約ファイルほか | :一連の成果物、書類をひとまとめにしたもの。納品・検収が終了し、承認印も終えた状態のプロジェクト契約書類、成果物一式のこと |
契約タイプ | 説明 |
---|---|
定期契約 (一括契約) | システム開発に関するすべての業務を契約時に見積もった期間と費用で行う方式。締結時点で「価格」が決まっている契約のことで、納入者は見積しかしていないし、発注者は欲しいものの条件しかいていない。だからのコストリスクは最大となる契約 |
実費償還契約 | 開発にかかった実際のコストに納入側の利益相当分を加えた金額を、発注者が支払う契約。実コストに納入者の利益分を加えた金額が「価格」となる契約のことで「かかった分だけいただきます。プラスαももらいます」という契約。発注者が最大のコストリスクを負う |
タイム・アンド・マテリアル契約(T&M契約) | 設定した単価に、依頼業務にかかった時間を掛け合わせた額を支払く契約。いわゆる単価契約だと考えればよい。単価は明確に決めてあるが、トータルでどれくらいの量になるかわは不明であることに注意 |
開発期間10ヶ月、開発工数200人月のプロジェクトを計画する。次の配分表を前提とすると、ピーク時の要員は何人か。各工程の開発から終了までの人数は変わらないものとする。
※人月とは「人数×月」を意味し、プロジェクトに投入する人員と、月で表した1人当たりのプロジェクト従事期間の積を表す 1人で1ヶ月かかる仕事の量が1人月である。10人で6ヶ月かかれば60人月、 100人で半月かかれば50人月となる 開発期間10ヶ月なので、期間配分の10%が1ヶ月になる。また、開発工数200 人月なので、工数配分の0.5%が1人月になる。これから、各工程の必要人数を 求める 要件定義 工数配分:16%=32人月、期間配分:20%=2ヶ月、必要人数:32÷2=16人 設計 工数配分:33%=66人月、期間配分:30%=3ヶ月、必要人数:66÷3=22人 開発・テスト 工数配分:42%=84人月、期間配分:40%=4ヶ月、必要人数:84÷4=21人 システムテスト 工数配分:9%=18人月、期間配分:10%=1ヶ月、必要人数:18÷1=18人 よって、ピーク時の要員は設計工程の22人である |
 

