確実にプロジェクトを成功に導くためのプロジェクトマネジメント手法
企業によっては「PM(プロジェクトマネージャー)」というポジションを設け、あるプロジェクトを進めていく組織も多くあります。具体的にどのような仕事をするものなのか、行う上でどのようなスキルが必要になってくるのか。
この記事では、「正しいプロジェクトマネジメントの実施方法」について解説していきます。
◆この記事を読んで解決できること◆
1.提供企業と顧客、双方にとってメリット（便益）のあるのプロジェクト設計ができるようになる。
2.定められた期限と予算内でプロジェクトの目的を達成するために必要な管理をできるようになる。
1.そもそも「プロジェクトマネジメント」とは何か。
プロジェクトマネジメントはその名の通り、一般的には「管理すること」にフォーカスされますが、プロジェクト成功のためのプロセスを構築し、実行するプロジェクトマネージャーには、幅広い視点と知識が要求されます。
PMBOK (※①)において、5つのプロセスと共に必要とされる「10個の知識エリア」とは、下記のようにプロジェクトの管理と遂行に必要な要素になります。「PMBOK」のフレームワークを軸に「未経験者でも、明日からプロジェクト計画書」が構築できるように、下記にて解説していきます。
※① PMBOKとは・・・プロジェクトマネジメントを理解し、活用するための知識体系のこと。アメリカの非営利団体であるPMIが1987年に発表した『A Guide to the Project Management Body of Knowledge』というガイドブックが由来。
このガイドブックの発表から徐々に知られるようになり、今ではプロジェクトマネジメントの事実上の国際標準として浸透している。従来の「QCD」（品質・コスト・納期）に着目したマネジメント手法と区別して、「モダンプロジェクトマネジメント」と呼ばれることもある。
PMBOKは、プロジェクト管理を「立ち上げ」「計画」「実行」「監視・管理」「終結」の5個のプロセスと、「総合管理」「スコープ管理」「スケジュール管理」「コスト管理」「品質管理」「組織管理」「コミュニケーション管理」「リスク管理」「調達管理」「ステークホルダー管理」の10個の管理に分けて体系化している。
プロセスは、プロジェクトやその局面（フェーズ）において、相互に重なり合い、作用するため、最終目標であるQCDを実現するためには、それぞれのプロセスを明確に管理することが重要であるという考え方。
PMBOKは4年ごと、オリンピックの開催年に改訂されている。PMIでは、PMBOKに準拠した国際的な認定制度である「PMP」（Project Management Professional）を展開しており、日本でもPMP取得者が年々増加している。
1.1 プロジェクトマネージャーに求められる能力
上記では「プロジェクトマネジメント」について解説しましたが、実際にその職務を全うする「プロジェクトマネージャー」そのものについても解説していきます。
プロジェクトマネジメントを実施するにあたっては、正しい方向にプロジェクトを導いていく必要があります。プロジェクトマネージャーは、新しいサービスを立ち上げるなどのプロジェクトの進捗管理を任される人の事を言います。
「プロジェクトを始めるにはどれくらいの規模でやるのか」、「どれくらいの予算でやるのか」、「そもそも誰とやるのか」といったことを決めなければなりません。
1.1.1「抽象的なものを具現化する能力」
プロジェクトは「曖昧性」と「不確実性」の塊になります。そのため、「フワッとした曖昧すぎる要求や要件に対して、いかに具現化して開発メンバーに落とせるか」の能力が必要不可欠になります。
故にプロジェクトマネジメントにおいては、「抽象 ↔ 具現」の思考がどれだけ繰り返せるかになってきます。例を挙げると、「会員登録機能にSNS認証を加えたい」といった、ざっくりといったストーリーがあったとして、
1.プロトタイプの作成
2.シーケンス図作成(画面遷移他院に)
3.認証用のBack-ends API x 5
4.構成 : Go(echo) x AWS ECS
5.Front-ends : React(Next.js) x SPA x SSR x BFF
6.Front-ends: S3(静的ファイル) x AWS ECS(BFF)
7.SEO対策はいらない
8.ページ遷移は最大3ページ
,etc….
といったような具現化したものをどれだけ早く落とし込めるかが、とても重要になってきます。ここが全くわからないとただの「進捗管理者」になってしまって、PMプロキシー的な存在を配置しないといけません。
1.1.2 「開発プロセスを作る能力」
ここでいう開発プロセスとは「プロジェクトの流れ」になります。明確な道筋（プロセス）を構築してあげて、開発者達が開発しやすい、自走できるような環境とプロセスを構築しないといけません。当然ながら、PMが先頭を切って、プロジェクトの全てを仕切ることは不可能になります。
いかにメンバーを育てて、皆がプロジェクト管理を自分事にして語れるか。プロダクトバックログも開発者と一緒に構築していきます。
1.1.3 「報告する能力」
PMは、ビジネスサイドだったり、経営層へのプロジェクトの進捗を報告する必要があります。ここで抑えておきたいことは例えば、「経営層に細かいプロダクトバックログ単位でどこまで終わったのか」を報告する必要はありません。要は、報告の粒度を使い分けるということになります。
1.2 プロジェクトマネジメントの具体的な運用フロー
1.2.1 プロジェクト計画書の設計
プロジェクトマネジメントで使用される「プロジェクト計画書」を構築要素は下記のようになります。
○プロジェクト計画書の目次○
1.プロジェクトの目的
2.プロジェクトスコープ
3.前提条件、制約条件
4.スケジュール
5.プロジェクト体制
6.プロジェクト予算
7.品質基準
8.プロジェクトの目標
9.マネジメント計画
9.1 品質マネジメント計画
9.2 コストマネジメント計画（稼働・コスト管理）
9.3 スケジュールマネジメント計画
9.4 スコープマネジメント
9.5 コミュニケーションマネジメント計画
9.6 組織マネジメント計画
9.7 リスクマネジメント計画
1.2.2 プロジェクト計画書を構築する手順
プロジェクト計画書を構築する具体的な手順は下記のようになります。
○プロジェクト計画書を構築する手順
1.プロジェクトの目的の明確化
2.スコープの明確化
3.前提条件、制約条件の明確化
4.スケジュールの作成
5.工数の算出
6.プロジェクト体制の構築
7.コストの算出
8.品質基準の構築
9.目標の設定
10.マネジメント計画の作成
10.1 品質マネジメント計画
10.2 コストマネジメント計画
10.3 スケジュールマネジメント計画
10.4 スコープマネジメント計画
10.5 コミュニケーションマネジメント計画
10.6 組織マネジメント計画
10.7 リスクマネジメント計画
1.2.3 プロジェクトマネジメントの具体的な運用フロー
プロジェクトマネジメントの具体的な運用フローは、下記の4つのステップになります。
①.準備
・プロジェクトチーム発足
-必要な経験・能力
・対象プロジェクトの選定
・PMの納品物一覧の各ヒアリングシートに記載
②.実施
・オリエンテーション
・ヒアリングの実施
-5段階評価 : Ex : 導入効果を定量化・定性化できない
③.評価
・専門家チーム内の意見調整
・問題の把握
・ヒアリングシート内の対策案の確認
④.対策検討
・評価の説明
・意見交換
・対策案の検討
・実行計画の策定
1.2.4 プロジェクトアウトプット一覧
ここでは、プロジェクトのアウトプットを紹介していきます。
①.俯瞰図・・・周辺システム構成俯瞰図、システム構成俯瞰図、プロジェクト推進体制俯瞰図、ステークフォルダー俯瞰図、スケジュール俯瞰図、要因推移俯瞰図
②.プロジェクト計画・ルール・・・プロジェクト計画書、リスク管理表、責任分担表、体制図、WBS、システム規模見積もり、テスト計画書、レビュー計画書、構成管理計画書、移行計画書、保守・運用計画書、要因育成目標、レビュー、実施要領、変更管理ルール、チェックリスト 等
③.スケジュール・・・マスター・スケジュール、チーム別スケジュール、要員山積表
④.進捗管理・報告書・・・課題管理表、リスク管理表、変更管理表、変更管理表、進捗報告書、メンバーの勤務管理表、各種議事録
⑤.設計書・・・RFP、要件定義書、基本設計書、用語集
⑥.契約・・・各種契約書、協力会社との契約書、提案書、見積書
1.3 プロジェクトマネジメントにおけるインプットとアウトプットとは何か？
この項目では、この記事内でよく使用するプロジェクトマネジメントにおける「インプット」と「アウトプット」の概念を解説していきます。
1.3.1 プロジェクトマネジメントにおける「インプット」と「アウトプット」とは
プロジェクトマネジメントでは、「インプット」と「アウトプット」という用語が頻繁に使われます。「インプット」とはプロセスを進めるために必要な項目であり、「アウトプット」とはプロセスによって生成されるプロダクト、所産、またはサービスのことを指します。
1.3.2 「インプット」と「アウトプット」の定義
PMBOKによると、インプットとは「プロセスが勧められる前に必要となる様々な項目。プロジェクトの内外のものであるかを問わない。先行プロセスからのアウトプットの可能性もある」と定義されています。
他方、アウトプットとはというと、「プロセスによって生成されるプロダクト、所産、またはサービス。後続プロセスへのインプットとなる場合がある」と定義されています。
1.3.3 「インプット」と「アウトプット」の関係
「プロセスはインプットをアウトプットに変換する一連の活動である」
PMBOKでは、一連のプロジェクトマネジメント活動であるプロジェクトマネジメント・プロセス は「適切なプロジェクトマネジメント・ツールおよび技法を使用して、ひとつ以上のインプットからひとつ以上のアウトプットを生成する」と定義し、品質マネジメントシステムの標準であるISO9001でもプロセスを「インプットを使用して意図した結果を生み出す、相互に関連する又は相互に作用する一連の活動」と定義しています。
プロジェクトにおいては、複数の様々なプロセスを経て、最終的な成果物を形づくっていくことになります。つまり、プロジェクトとは「インプット」と「アウトプット」を繰り返しながら、最終的な成果物（プロダクト）を作っていく過程であるともいえます。
1.3.4 インプットはアウトプットのための材料
例えば、これから「プロジェクト憲章の作成」というプロセスをこなしていくとします。PMBOKでは、「プロジェクト憲章の作成」のプロセスのインプットとして「ビジネス文書、合意書、組織体の環境要因、組織のプロセス資産」を挙げています。
最終的に「プロジェクト憲章の作成」ではアウトプットととしてプロジェクト憲章が取得できるのですが、インプットはアウトプットという料理のための材料要素と捉えるのがベターでしょう。
2.プロジェクトの目的の明確化
この項目では、「プロジェクトの目的の明確化」について解説していきます。
2.1「何を実現するためのプロジェクトなのか」を明確化する
まず「プロジェクトをそもそもなぜするのか」という目的を明確にしていきます。
「何を得たいのか、得たことにより何が幸せなのか」
ここで相違認識のズレが起こると、「クライアントの便益」と「プロジェクト活動」が結び付かず、プロジェクトがほぼ確実に失敗してしまいます。
2.2 プロジェクトとプロダクトの違いとは
混同しがちな「プロジェクト」と「プロダクト」の違いを説明をすると「プロダクト」とは、製品や商品、製作物といった「成果物」のことを言い表します。この成果物には、機械や製品といったものだけでなくソフトウェアやアプリ 等も含まれます。
語感は「プロジェクト」と似ていますが、意味は全然異なるので明確に理解しましょう。
2.3 主な投資対効果の指標（事業投資マネジメント）
当然ながら、経営における「プロジェクト」は投資になりますので、プロジェクトの「成功・失敗」は下記の指標で定義することができます。
・ROI (総資本利益率）
・ROA（総資産利益率）
・ROE（株主資本利益率）
・ORS（売上高利益率）
これに基づいて「プロジェクト投資の成功・失敗」を定義することが出来ます。
2.3.1 投資管理設計
※この項目では、かなり踏み込んだ内容を解説しておりますので、PM初心者の方は読み飛ばしていただいてもかまいせん※
そもそもの経営における「投資対効果」を管理（企画～意思決定～評価）する仕組みが曖昧、またはほとんど存在しないという場合は、新しいプロジェクトを立案しても、意思決定が思うように実行されない場合もあるので、上層部を巻き込み投資管理のフレームワークを構築するの一つの手になります。
下記では、投資管理に関する具体的なフローを解説していきます。
投資管理は、「①.投資案の作成（ビジネスシナリオ立案）」「②.事前評価（意思決定）」「③.投資実行」「④.事後評価」「⑤.出口戦略」の、5つのステップに整理できます。
①.投資案の作成（ビジネスシナリオ立案）
• 中期経営計画での事業投資戦略の策定、予算編成時の投資優先順位の策定
• 個別案件の起案時におけるビジネスシナリオの策定課題
• 投資案の検討に関する指針がなく、案件ごとに視点が不揃いである
• 決裁を得るためだけの現実味のない投資回収計画しか作らない
②.事前評価（意思決定）
• 定量的・定性的な評価に基づく投資案の実行可否判断
• 不確実性の可視化によるリスク対応策と投資の可否判断検討・課題
• 投資評価方法・指標が経営方針や戦略と整合していない
• 決裁者の経験と勘と度胸に依存した意思決定をしている
③.投資実行
・投資実行計画の進捗状況の把握課題
• 投資実行中の環境変化に対応できない
• 不確実性に基づくシナリオ分析の欠如
④.事後評価
• 投資回収状況・リスク発現状況の事後評価
• 事業セグメントとキャッシュフロー生成単位の統合的な業績管理制度
• キャッシュフロー生成単位ごとの投資の事後評価課題
• 事後評価が実施されていない
• 投資の勝ち負けしか判定しておらず、打ち手に繋がらない
⑤.出口戦略
・投資効果（利益）の上積みを追求した計画修正・追加投資
• 撤退判断の遅れによる損失拡大防止、不採算案件からの撤退
課題
• 投資後の拡張・縮小・中止・撤退に関する基準がない
• 最初に作った投資回収計画が見直されない（投資リスクの発現を放置）
■ 一般的な検討ステップ
①.ルール / 業務フローのデザイン
• KPIの選定
• 定量・定性評価のルール整備
• 統合的業績管理の構築
• 投資実案件を使ったケーススタディの実施
②.規程 / フォーマットへの落とし込み
• 投資管理規程の作成
• 起案時の申請フォーマットのデザイン
• 定量評価フォーマットの作成
③.導入準備・導入
・新制度導入の意思決定用資料の作成
• 段階的導入に向けたステップの検討
• 社内展開に向けた研修の実施、手順書作成
④.運用定着・拡大
・運用に関する助言
• 運用開始後の課題分析と改善
• 運用範囲の拡大（別事業・子会社への展開など）
2.4 関係者のプロジェクト成功の定義
この項目では、プロジェクトの成功定義について解説していきます。プロジェクトにおける「成功」とは、大きく分けると下記の3つになります。
⑴.顧客の要求を満たす品質の製品を提供すること
⑵.期日を守ること
⑶.予算内でプロジェクトを終えること
プロジェクトにおける「企画、設計・開発、運用」の各段階における実施および効果の評価を行うことになります。下記に例を挙げていきます。
・ゴール
ゴールは「Q（品質）、C（コスト）、D（納期）」の目標になります。なるべく定量的な数値でゴールを設定しましょう。プロジェクト終了後は、一般的にプロジェクトの振返り評価を行います。この際の評価基準にこのゴールを使います。
・Q（品質）
ソフトウェアの場合、品質はあらかじめ「サービスレベル」で細かく定義します。内容としては、ソフトウェア自体の品質（バグやレスポンスタイム）と稼動後の運用品質（稼働率、障害時の復旧時間、運用体制、稼動直後の問合せ件数 等）の2つがメインです。定義するサービスレベルの中身はプロジェクトの内容によって異なります。
・C（コスト）
コスト目標は、原価率・利益の目標を設定する場合が多いです。コスト計画自体がコスト目標となります。
・D（納期）
納期目標は、重要なマイルストーンとローンチ日です。ここが守れないと結果的にコスト目標にも響きます。
3.プロジェクトのスコープ
ここでは、「プロジェクトのスコープ」について解説していきます。スコープを明確にする理由としては、「目的を達成させるために、プロジェクトの範囲に対して何をしなければならないのか」ということになります。
プロジェクトの目的に基づいて、発注者側からは「このようなことがしたい」という要求が出されます。しかしながら、期限やリソース、予算などの理由から、リストアップされた要求すべてを実現するのは容易ではありません。
そこで、様々な制約・前提の中で「出来ること」を絞り込む作業（要件化）が必要となります。スコープマネジメントが最終成果物と作業範囲を管理することはご理解いただけたと思いますが、プロジェクトにおいて、なぜ必要になるのでしょうか。
その答えは、顧客のニーズを満たし、顧客満足度を高めるためと言えます。プロジェクトは顧客の目的を満たすために発足し、必要な成果物を定められた期間内に予算を超えることなく、高品質で作る必要があります。
そこで、顧客の目的を達成するために必要な成果物を明らかにし、期間や予算、品質に応じた作業範囲を管理するためにスコープマネジメントが必要になります。プロジェクトのスコープは大きく分けると下記の2つになります。
・成果物スコープ…「何を作るか」
・プロジェクトスコープ（作業スコープ）…「何をやるか」
では実際のプロジェクト、例えば「勤怠システム構築」といったプロジェクトで同じように考えてみましょう。「要求分析」「業務フロー作成」といった項目があげられます。
システムでいうところの工程とタスク（作業内容）作業を毎回、一から洗い出すとどうしても漏れが出やすくなります。そこでWBSの標準を持つことが重要になります。
プロジェクトタイプ（開発スタイル、システム要件が同じようなプロジェクト）別に標準的なWBSを作っておき、そこから自身のプロジェクトに当てはめるようにします。
・作業スコープ（工程タスク成果物登録）
3.1 対象業務
「やりたいこと（要求）」から「やれること（要件）」を絞った成果物とタスクの実行範囲のことを「スコープ」と言い表します。前項で、プロジェクトの目的に従って、構築したい画面一覧・機能一覧と、一覧に記載された内容を実現する設計書やテストケースを含めた成果物一覧を作成します。
リストアップされた成果物の全体量を踏まえて、期限や予算、技術的難易度といった制約・前提条件を照らし合わせて、個々の成果物の質を決めていくと、作る優先度が低い成果物が削られたり、逆にプラスαで作るべき成果物が加わることがあります。
こうして出来上がった「成果物一覧」に基づいて必要なタスクの量を見積もれば、タスクの量も確定できることになり、成果物とタスクの実行範囲（スコープ）が明らかになります。
3.2 対象システム
機能・非機能要件は、プロジェクトのゴール設定と言っても過言ではなく、これが定まらないと「失敗を定義」をしているのと同等のレベルになります。下記にて「機能要件」「非機能要件」を解説していきます。
3.2.1 機能要件
「機能要件」とは、画面や帳票やバッチといった実装すべき機能のことを言い表します。プロジェクトで構築するシステムの目標となるため、プロジェクトのゴール設定と言えるでしょう。機能要件は、画面・帳票・バッチに大きく分類されます。
Ex :
・画面
販売製品や販売履歴が見れる画面が欲しい
・帳票
製品納品の納品書を自動作成して欲しい
・バッチ
月末の支払業務を自動化して欲しい
①.機能要件の書き方
機能要件は、システム開発の要件定義の初期段階で洗い出すことになります。顧客が完成形のイメージを持っていれば容易ですが、実際にはイメージを持っていないことがほとんどになり、その理由を挙げると顧客は業務のプロであって、システムのプロではないためになります。
故に顧客にヒアリングを重ねながら、要件を洗い出していくことが重要になります。下記にて具体的な手順を解説していきます。
⑴.背景や目的を明確にする
当然ながら顧客は「何らかの目的」があってシステムが欲しいと考えています。まずは「背景と目的」を明確に洗い出しましょう。背景と目的を明確に整理・理解できていないと、議論がまとまりにくくなり、要件を絞り込むときの判断材料も不足することになります。
⑵.必要な機能を洗い出す
最初は顧客が求める機能をヒアリングすることから始めます。その後、ヒアリングした内容を図や表にまとめたり、具体的な画面や帳票のサンプルを作ったりしながら、具体的にイメージができるようにします。業務改善のシステムならば、業務フローから必要な機能を洗い出すことが多いでしょう。
⑶.機能要件の選定
全ての機能を開発するだけの予算が顧客にあれば理想ですが、現実的には予算の都合で機能を絞り込む必要が出てきます。機能毎の概算工数（費用）を提示しつつ、機能削減した際の代替案を検討していきます。
代替案の例
・利用頻度の低い画面や帳票は、Excelやメールで作業する
・画面の一部の便利機能（例えばグラフ表示機能）を外す
・開発費用の少ない簡易機能を提供する
※備考※
費用を提示する場面では、「もっと安くできないか？」と、顧客と値引き交渉になる場合も多くあります。このような交渉に備えて、値引きを前提で費用を提示するという策も必要になってきます。
②.非機能要件
非機能要件とは、顧客が機能面以外にシステムに求める要件のことになります。稼働率やシステム性能、セキュリティ、保守サービスなどの要件になります。機能要件と並んで、システムの目標となるため、プロジェクトのゴール設定と言えます。
下記にて、具体的な手順を解説していきます。
⑴.機能要件の検討が完了していること
当然ながら、非機能要件を検討するのは、機能要件の検討が完了した後になります。機能が変わってしまえば、裏側の要件である非機能要件も大きく変更されて、無駄になってしまう可能性があるからになります。
⑵.自分達で非機能要件の仮設定
まず非機能要件の洗い出しを行いますが、前述したように顧客側は非機能要件を意識していない場合が多いため、
「非機能要件は何かありますか？」
と聞いたところで何も得ることはおそらくないでしょう。
そこでまず、委託先の専門業者から非機能要件の一覧表を仮作成します。作成する際は、可用性や性能・拡張性などに分類しつつ、構築するシステムの特性に応じて、要件を仮決めしていきましょう。
⑶.非機能要件を顧客と設定
委託を受けた企業側で、非機能要件一覧の仮作成ができた後は、顧客に適切な要件を確認します。
例を挙げると、
「システムの稼働時間は10時〜21時ではなく、6時〜22時として欲しい」
このような具体的な要件が出てきます。当然の事ですが、注意しなければならないのは、要件の理由を明確に聞き、メモをしておくことになります。
例）稼働時間を6時〜22時にする理由
・始発で出勤して作業をする人がいるため
・残業終了時間が22時のため
要件の理由をメモしておかないと、顧客が言った要件を採用するしかなく、代替案が提示できません。また、思いつきで回答する顧客もいるため、理由は明確に把握したほうがいいでしょう。
4.前提条件・制約条件
この項目では、プロジェクトマネジメントの「前提条件・制約条件」について解説していきます。
4.1 そもそもの「プロジェクトの前提条件・制約条件」とは
4.1.1 プロジェクト前提条件とは
PMBOKの用語集には、前提条件（※①）は次のように定義されています。
※①.前提条件・・・計画を立てるにあたって、証拠や実証なしに真実、現実、確実とみなした要因。
前提条件とは、実は不確実であることを確実とみなした場合を言い表します。故にプロジェクトにおける不確実なものといえばリスクになります。プロジェクト計画を立てる上では、不確実なものに一定の推定値や仮定を起きながら計画を組み立てていくことになります。
その推定値や仮定と実際が異なる可能性は、すなわち、プロジェクト計画に内在するリスクということになります。したがって、プロジェクト計画を立てる上で置いた前提条件を漏れなく洗い出して一覧化したものは、プロジェクトに内在するリスクの一覧とみなすことも出来ます。
逆にいえば、プロジェクトマネジメントとは、前提条件を設定できないことで発生する問題を解決するための手段だと言っても過言ではありません。
・全ての人は放っておいても自発的に報告をする
この前提条件は、経験を一定数を積んだベテラン勢だと当たり前ですが、経験の浅い若手だと「自発的に報告する」という行為は容易ではないでしょう。故に「前提条件」はプロジェクトメンバー全員と必ずすり合わせましょう。
4.1.1.1 前提条件が綻びるとどうなるか
もし、このような前提条件に綻びがあると、上で議論してきたように、最終的には予算と納期とスコープ（品質も含む）、つまり、プロジェクトの制約条件にかなり、重大な影響が出てきます。
極論すれば、前提条件が明確になっていない限り、プロジェクトの計画は作成する意味が無いといっても良いでしょう。責任の明確化と前提条件の明確化になります。
このような例は
・リソース確保が前提になっているスケジュール
・パフォーマンスの平準化が前提になっている予算計画
・作業者のプロジェクトのコミットを前提した品質管理計画
【資源の前提条件】
・必要に応じてプロジェクト要員の確保が可能
・必要に応じて主要な顧客の資源の確保が可能
・プロジェクト要員の殆どが開発環境の経験がある
・顧客側でシステムの機能要件を詳細に説明できる要員の確保が可能
・市場から特殊な分野の経験者やスキルの保有者の確保が可能
・専任の要員は少なくとも、一週間35時間の労働時間を確保できる
4.1.2 プロジェクト制約条件とは
これに対して、「制約条件」とはどのようなものでしょうか。「プロジェクトの制約条件」も「プロジェクト目標」も、どちらも「何が何でも守る」対象であることは同じように考えられます。
PMBOKの定義にて、「制約条件」を確認してみますか。（※１）
※① 制約条件・・・プロジェクトまたはプロセスの実行に影響を及ぼす制限要素。プロジェクト・スコープ記述書に深く関係する制約条件は、プロジェクトの実行に影響するプロジェクト・スコープと関連づけられた、特定の内部的または外部的な制約や制限を列挙し、記述する。
例としては、顧客または母体組織によって発行された既定の予算、指定日、あるいはスケジュール・マイルストーンなどがあります。合意に基づいてプロジェクトが実施される際の契約上の条項は、通常「制約条件」となります。
制約条件に関する情報は、プロジェクト・スコープ記述書、またはそれとは別のログに記載される場合があります。
この定義を読むと、何となく、プロジェクト実行において守る必要のある事項の全てを「制約条件」と呼び、その中に予算やリリース日などのプロジェクト目標も含まれるということのように読み取れます。
【資源の制約条件】
・主要な（人的）資源がパートタイムでしか確保できない
・主要な顧客の資源の確保に制限がある
・プロジェクト要員の多数が開発環境の経験が無い
・顧客側でシステムの機能要件を説明できる要員に制限がある
この2つをよく比べてみてください。例えば、
必要に応じてプロジェクト要員の確保が可能
という前提条件があります。この前提条件は本来プロジェクトマネジメントでは前提であるが、IT系のプロジェクトを中心になかなか、成り立たなくなってなっています。これが成り立たないとどうなるか、例えば
主要な（人的）資源がパートタイムでしか確保できない
といった制約条件が生じてしまいます。
「何が何でも守るべき」絶対的制約条件として受注側にインプットされ、デスマーチ化の根源になってしまうこともあり得ます。よく言われるように、「数字はひとり歩きする」ことになります。
したがって、特にベンダー側からコスト感やスケジュール感を安易に口にするのは、くれぐれも注意する必要があります。いくら前提条件をつけても、超概算だとか形容詞をつけたとしても、一度、口に出した数字は、装飾物が全て取り払われた状態でひとり歩きしてしまうかもしれないことを肝に銘じるべきです。
4.1.3 完了条件を曖昧にしてはいけない
プロジェクトの完了とは、計画通りにシステム（成果物）を完成させることはしません。本当の意味でのプロジェクトの完了は、「顧客に検収してもらう」ことになります。明確に検収してもらうには、あらかじめ終了条件を明確にして公式な文書で記録しておくことが重要になります。
・契約書
・プロジェクト・チャーター
・プロジェクト計画書
・客先との議事録
・関係書類
基本的には、プロジェクト計画書に重要な顧客との約束事項は反映されているはずなので、その記載内容とプロジェクト進行中での取り決め事項の確認になります。さらに、見落としを防ぐために、PMはプロジェクトに関係する上記の公式文書を全て確認しておく必要があります。
5.スケジュール管理
この項目ではプロジェクトの「スケジュール管理」について、解説していきます。
5.1 なぜ見積もりのズレが出やすいのか
そもそも、何故工数の見積もり作業は難しく、開発時に必要な工数との乖離が発生してしまうのでしょうか。見積もりが何故ずれるかという説明の1つに「不確実性コーン」というものがあります。
ざっくり説明するとプロジェクトの初期段階では不確定要素が多いので見積もりには「4倍」くらいの誤差があり、プロジェクトの進行とともに不確実な部分が少なくなってきて、誤差は収束に向かうという話です。
「プロジェクト開始時点では、見積もりには4倍のばらつきが含まれている」ということがこの図からわかるように
「1年かかると予想したプロジェクトが、実際には4年かかる」
ということがあっても、全く不思議ではないということを表しています。
当然ながら、実際には、様々な要因によって綺麗なコーン状にはならないでしょうが、プロジェクト最初期であるほど不確実な要素が多く、徐々に低くなっていくといった変化を見せるということを示しています。
「不確実性の減るタイミング」になります。グラフを見ると、時間の経過とともに不確実性が自然に減っていくように見えます。しかし、実はそうではなく、不確実性は各フェイズで意思決定が行なわれることに小さくなります。
製品コンセプトや仕様が明らかになるコミットメントを得ることで、不確実性は小さくなるのです。逆にいえば、意思決定をしなければ、大きな不確実性を抱えたまま、プロジェクトが進んでしまうということになります。
不確実性が高いフェーズは、
・初期の段階見積もりを正確に行うのは、現実的に不可能。後々、ブレが出る事を大前提として、受注 / 発注側が合意する
・それらを踏まえた上で工数 (お金 / 期限)を増減できるような取り決めにしておく
という考えが重要になってきます。プロジェクトマネジメントの観点から言えば、先ほどみた「不確実性コーン」のようなプロジェクトのはじめに不確実性が高いことが少なくなります。
例えば、プロダクトに必要な「20個の機能を1年で開発する工数を見積もる」のではなく、「1個の機能を1週間で開発する工数を見積る」ので必然的に見積もり精度が上がっていきます。
5.2 不確実性を乗りこなす三つのアプローチ
プロジェクトが成功するかどうかは、「やってみないと分からない」という不確実性をどう乗りこなすかにかかっています。乗りこなすためのアプローチは下記のようになります。
①.プロジェクト初期には、大きな不確実性が存在しますが、プロジェクトの開始時に目的と目標、全体プロセスを明らかにし、それらを基に計画を立てることで、不確実性そのものを小さくすることができます。これが1つめのアプローチです。
②.リスクの顕在化や想定外のトラブル、大幅な見積もり超過などに備えて、あらかじめ対策を打っておくというものになります。「予定と実績のズレ」や「リスク」が現実になっても、プロジェクトに与える影響を最小限に抑えられるようにします。
③.不確実性を徐々に減らしていくというものです。やってみないとわ分からないということは、やれば分かる部分が多いということの裏返しでもあります。
分かったことをうまく捕まえて、計画やスケジュールに反映するには、予定と実績を比較し、計画に反映していく仕組みが必要になります。一般的には「進捗管理」と言われる部分になります。
5.3 工数見積もり手法
工数見積もり手法は下記の3つの種類があります。
⑴.類推法（トップダウン見積法）
⑵.WBS積算法（ボトムアップ見積法）
⑶.パラメトリック法
各見積法を下記にて解説していきます。
⑴.類推法（トップダウン見積法）
類推法は、過去の似たような仕事内容や規模のプロジェクトの実績を基にして、工数を見積もる手法になります。トップダウン見積法とも呼ばれています。
例を挙げると、設計書作成やコーディング作業などは、過去の実績を参考にするだけで十分正確な見積もりを出せることがありますので、類推法が有効な手法となります。
ただし、類推法を使う際には、可能な限り、同じ条件の実績を参考にしなければなりません。ページ数やステップ数などの作業規模、担当者のスキルや経験値、作業の難易度などが似ているプロジェクトでなければ、全く参考にならないので注意が必要になります。
⑵.WBS積算法（ボトムアップ見積法）
WBS、つまり細かく細分化した作業工程の見積もりを個々に算出して積み上げていくことで、全体の見積もりを出す手法になります。ボトムアップ見積法とも呼ばれます。それぞれのWBSの見積もりが詳細であればあるほど、正確な見積もりを出すことができます。
⑶.パラメトリック法
全ての作業の工数を決める要素を変数として設定し、関数を利用して工数を計算する手法になります。工数を決める要素としては、作業規模や作業の難易度、担当者の人数、スキルなどがあります。
5.4 スケジュールで何を管理するのか
上記の項目で「成果物・タスクの洗い出し」を実施しましたが、それを決めた条件の中で、明確に終了させるために
「所要時間の予測」
「実行日次の設定」
「担当者の割り当て」
「進捗管理のルール」
を洗い出します。
5.5 スケジュールをどのように管理するのか
スケジュール管理手法は調べれば、多くありますが、初心者でもすぐに使いこなせる下記の2つを紹介していきます。（※執筆者も下記の2つを軸にPMを実施しております。）
⑴.CCPM
CCPM（Critical Chain Project Management：クリティカル・チェーン・プロジェクト・マネジメント）とは、プロジェクトの各タスクの予算やスケジュールを限界までに抑えて、その分、「プロジェクト・バッファ」という余裕を設けておく管理手法になります。
精度の高い「限界の計画」を立てるコツは「WBS」を明確に分解することになります。分解された個々のタスクを「順調に行ったとして」と仮定して計画を立てることにより、全体の予定が「限界」となります。
・バッファ捻出の工夫
バッファの捻出を、次の手順で実施するとしましょう。
① WBSを展開する
② 個々のタスクを見積り、合計を正規の計画とする。
③ 個々のタスクの余裕分を取り除き、合計をぎりぎりの計画とする。
④ 正規の計画―ぎりぎりの計画＝バッファとして準備する
当然ながら、このフローで最も難しいのは「③」の作業になります。どの程度を余裕とみなすかは人に依存しますので、PMを実施する人によってはバッファがほとんど出てこない場合があります。
故に、「一律 20%」をバッファとして回すというやり方も一つの手になります。
※あくまでも強制的にバッファに回すので、やり方は人それぞれになります※
⑵.ガントチャート
ガントチャートとは、プロジェクト管理や生産管理などあらゆる管理工程に使う表になります。「スケジュール表」「管理表」などと表記する組織もあります。
「ガントチャートに使う項目」の例は下記のようになります。
・タスク（管理項目名）
・開始日、完了（予定）日
・作業内容
・担当者
・作業間の関連
・マイルストーン
WBSの各タスクの右側に時間軸を作成し、開始日と終了日を棒グラフで表示します。長期に渡るプロジェクトだとメモリを日単位ではなく、週単位で表すこともあります。
大規模なシステム開発などはプロジェクト終了までに数年かかることもありますので、単位は「週」となることが多いです。2～3カ月のプロジェクトであれば、多くは「日」単位で表現されます。
5.5.1 スケジュールが遅延した場合の対処方法
5.5.1.1 工程が遅延する原因
遅延した場合の対処方法の前に、まずはそもそも「工程が遅延してしまう原因」を解説していきます。
・メンバーの作業遅延
メンバーの業務ミスや怠慢・キャパオーバーなどによって、工程遅延が起きる場合になります。工程どおりに人員を投入したにもかかわらず、遅延が起こった場合は人的ミスを疑うようにしましょう。
企業側の管理体制に不備があったり、従業員の業務量を把握できていない場合は注意しましょう。
・インフラの稼働遅延
インフラ設備の非効率的な運用によって、工程遅延が起きる場合になります。具体的には、開発機器や部品の不足、特定設備への過剰負荷などによって発生します。
・進捗状況の共有不足
各プロジェクト間の進捗状況が把握できなければ、全体の効率が低下し、工程遅延が発生します。進捗状況を共有できないのは、外注先やプロジェクト工程を一括管理していないためになります。
関係者間のコミュニケーション不足により、間違った情報が伝達されるのも要因の一つになります。承認プロセスやプラットフォームが不均一だと、プロジェクト間の作業データが把握しにくくなります。
・人員配置のミス
プロジェクトを進行する上で、適材適所の人材配置ができていなければ、いくらスケジュールが明確にしていても思うように業務が進まず、納期が間に合わないという事態を引き起こします。
人材を確保したら、人員配置を行う前に一人ひとりがどの程度の技術力を持っているか正確に把握することも納期遅延を防ぐために必要になります。
・曖昧な要件定義をされた案件と案件に対する理解力不足（指指し確認不足）
いざプロジェクトがスタートしたからといって、プロジェクト内容が曖昧であれば、要求されているものを明確に作り上げることはできません。「工数の見積もりが甘い」という言われてみると当たり前の事が、そもそもの原因になっている場合もあります。
プロジェクトの仕様書は、まずプロジェクトがスタートする前に関わるメンバー全員が理解できるような内容になっていなければ、納期が間に合わない原因になります。
また案件自体の内容は明確にしていても、誰か1人が理解していないだけで間違った方向に進んでしまい、それを修正するために納期遅延が起きてしまうのです。まずは案件内容を明確にし、全員がプロジェクト完成に向けた共通認識を持たなければいけません。
・プロジェクトが無謀な納期
特に発注者がその案件にどれだけの技術や業務量が必要なのか把握していない場合、絶対に無理な納期を強いてくることはあります。明らかに無理だとわかっているにもかかわらず、その納期を受け入れてしまうと確実に納期遅延が起きます。
・問題を隠蔽する空気
「問題が発生」しても、正しくPMに伝わる文化がないと問題そのものがもみ消されてしまいます。
5.5.2 遅延した場合の具体的な対処方法
・リソースを入れ替える
スケジュールに遅れが生じてきている場合、まず原因を突き止めるべきであるのは、当然の事ながら、遅延の原因は配置されているリソースの可能性が多々あります。
「特定のチームメンバーが適切なスキルを兼ね揃えていない」などの原因が挙げられるなら、担当者を変更したりしましょう。
・クラッシングをしてスケジュールを早める
プロジェクト進捗に遅れが見えはじめたら、管理者はクラッシングを採用することでスケジュールを早められます。クラッシングとは、プロジェクトに遅れが発生した時に用いられる手法になります。
プロジェクト達成のための工程に、人や物といった資源を追加投入してスケジュール全体を短縮します。
しかしながら、当然ながら「コスト増加」や「追加した人員がすぐに作業」が出来るとは限りません。いわゆる、アメリカの計算機科学者フレデリック・ブルックスの法則「ブルックスの法則」になります。
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる」
実際に新入りがチームに貢献できるようになるためには、ある程度、キャッチアップのための時間が必要になります。また、人員の追加はそれだけでチーム内のコミュニケーションコストを増加させます。人が増えれば増えるほど、それだけ協調して仕事をするのが難しくなります。
仮に、あなたのチームのリーダーが「人が足りない！」と嘆いたら、「どういう意図」で発言しているのかよく確かめたほうがよいでしょう。単純にスケジュールを挽回するつもりでそう言っているのだとしたら、それは非常に危険な発想だということがわかります。
他に手段が無く、追加人員の投入が行われる場合には、以下の3点を必ず抑えましょう。
①.日頃から可能な限りチーム内の業務を標準化しておくこと
社内やチーム内でのみ独自に使用されているツールや言語ではなく、広く一般的に普及しているツールや言語を日頃の業務から使うようにしておけば、助っ人のスキル次第で立ち上がりがスムーズになります。
一方で、業務が標準化されていないと、たとえ、どのような優秀な人を投入しても立ち上がりに必要以上にリソースがかかります。
②.チーム内の独自ルール・知識などは日頃からドキュメント化・マニュアル化を心がけること
ここを明確に整備していないと、新しい人が入る度に同じコミュニケーションロスが生じます。ドキュメントやマニュアルを作るのは手間がかかりますが、一回作成したら、何度も同じことを繰り返さなくて済むようになります。
③.追加投入人員は「パイパフォーマー」
存在しない情報は豊富な経験によって補完でき、チームに投入されたらすぐに自力で立ち上がれるような本当に優秀な人でなければ、追加人員としてはほとんど役に立ちません。
・ファスト・トラッキングで工程を入れ替える
この方法は、通常であれば順番に行うはずの作業工程を前後させて行う作業です。クラッシングと異なりコストが掛からず、抱えているメンバーのみで業務が完了します。
ただし、品質低下の恐れがあります。例を挙げると企画・構成・実作業という工程の場合、先に実作業を行ったために、本来の目的からずれた内容になる可能性があります。このような事態が発生すると修正が必要となり、余計な工程が増加してしまいます。
・プロセスを改善する
プロジェクトにおけるスケジュール遅延の原因に目を向けると、内部の作業プロセスに改善の余地の可能性もあります。チームメンバーにフィードバックを寄せてくれるよう依頼し、チーム内部でプロセスの効率を向上させる道を模索してみるべきです。
・進捗管理をより「厳密」にする
「プロジェクト」といっても、因数分解すると各メンバーのタスクからなるものなので、各メンバーの進捗管理をより「厳密」にしていきます。
例えば、「より細かい作業レベルで管理する」という行動になります。作業の進捗報告の単位を細かくしたり、報告頻度を短くしたりする場合になります。朝会に加えて、夕会を追加するケースなどもこれに当たります。メンバー間の進捗報告の仕方をより具体的にさせていきましょう。
進捗情報をパーセンテージで報告させるのではなく、具体的な数字などで報告してもらうようにしましょう。パーセンテージの感覚には個人差があるので認識のズレが起こり、後々、遅延につながる問題が起きてしまう可能性があります。
パーセンテージを使うのであれば、具体的に進捗率の数字を定義化させるルールを作りましょう。
Ex :
1.限られた時間で成果物を作成して、納品しなくてはならない
2.作業内容、作業順番、作業の所要時間を明確にする
・顧客目線でのタイムスケジュール
・開発目線でのタイムスケジュール
NG :
クライアントのが要望するスケジュールに合わせてスケジュールを構築し、品質・工数が足らずに炎上する
6.工数管理とは
この項目では「工数管理」について解説していきます。
6.1 工数の考え方
「工数」とは、プロジェクトの作業量のことであり、「人日」や「人月」という単位で示されます。1人でこなすと「1日かかる作業量」を1人日と呼び、 1人でこなすと1か月かかる作業量を1人月と呼びます。工数の計算では、「要員」と「期間」という言葉も出てきます。
「要員」 : プロジェクトの作業者の人数
「期間」 : プロジェクトを完了させるまでの日数や月数
6.2 そもそも「工数管理」をなぜするのか
工数管理を行う目的は、「利益の確保」になります。一般的な感覚だと、仕事をすれば報酬をもらえると思いがちです。しかしながら、企業の経営側としてはクライアントから回収できる金額がプロジェクトに必要なコストを上回った時点で赤字になります。
IT業界の場合、一番大きなコストは人件費になります。スキルなどによってバラつきはありますが、エンジニアを一人確保するのに「約100万円 / 月」は必要になります。
もし工数管理に失敗して、残業続きになった場合、人件費が一気に膨れ上がります。また見積もり失敗は信頼を失います。予算や納期、品質に関わる特記事項は全て見積書に記載されている内容を基にプロジェクトが進みます。
「もしも金額が間違っていたら」「もしも最初から達成不可能な納期であったら」「もしも品質上重大な欠点が記載されていなかったら」それは全て見積書を作成した側の責任になります。
見積もりの失敗はプロジェクトの失敗に直結します。予定していたスケジュールは混乱し、プロジェクトメンバーは先の見えない不安に陥ってしまいます。見積もりの正確に出来ない人はクライアント・メンバー双方から信頼を失うと念頭に置きましょう。
6.3 作業量と所要期間の把握が大事である
工数管理のポイントは「メンバーのスキル」と「実行できる作業量」を見極めることになります。システム開発における工数管理の場合、メンバーのスキルによって1日の生産性は大きく異なります。
スキルの低いメンバーに1日分の仕事を割り当てても、実際に作業完了するのに2日以上必要になるケースはよくあります。また、メンバーが1日に費やせる作業時間についても注意が必要です。よくある失敗が、1日8時間の作業時間で見積もるケースになります。
この場合、会議や進捗の共有などといった雑務に充てる時間が考慮されていません。実際は1日の作業に費やせる時間は8時間より少ないです。メンバーのスキルの見極めと1日に費やせる作業時間の見積もりを誤ると1か月で大きな誤差が生まれます。故に工数を作る時には十分に注意しましょう。
6.4 工数の計算方法
6.4.1 工数見積もりが失敗する原因
・工数を明確なエビデンスではなく、経験則・勘で考えてしまう。
プロジェクトは一つとして同じものはなく、常に未知の作業の工数見積もりを迫られることになります。作業を細分化して、経験したことがある作業まで落とし込むか、プロジェクト関係者に明確に意見を求めましょう。
・バッファを設けない
自信のスキルへの過信あるいは顧客の厳しい要求のためにスケジュールを短くしすぎてしまうのも、失敗の大きな原因になります。
6.4.2 より良い工数の見積もりを作るために
見積もりの精度を「100%」にすることは非常に困難ですが、期限内の完了確率を高める方法は下記にて解説していきます。
・その場で安易に回答しない
「xxはどれくらいかかる？」と口頭で聞かれることがありますが、その場の直感で回答することは避けましょう。5分程度でも構わないので、工程完了までに必要なタスクを書き出したり、他のエンジニアと相談したりするだけで見積もり精度は大きく向上できます。
・バッファを設ける
見積もりは必ず幅があるものなので、あらかじめバッファを持っておく必要があります。開発の状況に合わせてこのバッファを利用します。 この記事では「スケジュールバッファ」と「フィーチャーバッファ」の2つを挙げます。
⑴.スケジュールバッファ
スケジュールバッファとは、作業の見積もり期間とコミット期限に差をつけて、問題対応に備える考え方になります。例を挙げると、見積もりの値が3週間の時に完了のコミットメントを4週後にすれば、スケジュールバッファは、2週間になります。
想定外の問題が発生した際、この期間を利用して解決することができます。
⑵.フィーチャーバッファ
フィーチャーバッファは必須機能とそうでない機能を分け、スケジュールを調整する考え方になります。1ヶ月後のリリースが動かせない場合、例えば必須機能は「見積もり2週間分」までとし、それ以外の機能は間に合う分だけ実装するような方法になります。
これらのような「バッファ」が無ければ「残業をする」など手法で調整せざるを得なくなります。個人（チーム）の残業に頼ったプロジェクトはマネジメントの崩壊と同義といっても過言ではないでしょう。
・PERT法の使用
見積もりに有効な、プロジェクトマネジメント手法であるPERT（Program Evaluation and Review Technique）の見積もり計算式を解説していきます。対象となる作業にかかる時間を見積もる時、まずは以下の3つの値を設定します。
⑴. 最良時間
何も問題が起きず、全てがスムーズに進んだときに必要な時間
⑵.最有力時間
完了する確率が最も高いと思われる時間
⑶.最悪時間
問題が次々に見つかって、最も上手くいかないときに必要な時間
この3つの値を下の公式に当てはめると見積もり時間を求めることができます。
例えば、あるタスクに対して「最良時間 = 1日」、「最有力時間 = 3日」、「最悪時間 = 10日」だとすると、見積もり時間は以下の通りです。
（1日 + 3日 × 4 + 10日）÷ 6 = 3.83日
このように、PERT法では作業完了までの時間を直感的に判断せず、考えるプロセスを経るため精度向上に効果を発揮します。
・プロジェクト関係者にレビューを行う
プロジェクトの工数管理のベースとなるたたきが出来たら、必ず相違認識のズレが無いようにプロジェクト関係者にレビューを実施しましょう。レビューによって見積もり精度が高まるだけでなく、メンバーとの情報共有も可能になります。
当然ながら、PM担当が各プロジェクト関係者に特段確認せず、工数管理をトップダウンで行うのではなく、個人単位の見積もりを書くプロジェクト関係者が持ち寄り、チーム単位の見積もりを作っていきましょう。
・工数管理を定期的にアップデートする
プロジェクト進行中は定期的に見積もりをアップデートしましょう。更新作業に時間をかけすぎてもNGですが、必要なタイミングでアップデートすることは重要になります。
○マストNG : 工数算出を軽視しない
「プロジェクトメンバーが疲弊する」「予算オーバーする」「プロジェクトが中止する」といった炎上プロジェクトも少なからず、工数の算出は慎重に実施していきましょう。
7.プロジェクト体制の構築
この項目では、プロジェクトを進める上でのチーム体制構築について解説していきます。プロジェクトの体制が正確に明確化されてないと、必要な指示や報告が曖昧で伝わらなかったり、意思決定に時間がかかったりして作業ミスや効率低下の原因になってしまう恐れがあります。
7.1 プロジェクト体制の構築の目的
体制図を作る目的は、プロジェクトに参加するメンバーとそれぞれの役割、そして、メンバー間の指揮命令系統を定義することにあります。
7.2 プロジェクト体制図の書き方
上記の図のように、プロジェクトの体制図ではメンバーは「誰の指示に従えば良いのか」、「誰に報告すれば良いのか」というルートも定義することができます。
特にプロジェクトの体制図では「箱と箱が線で結ばれていない」、「複数の線が箱から同じ方向に出ている」など、指揮命令系統が曖昧になってしまうことがないように注意しましょう。
7.3 役割を明確化する
「誰が、どの作業を、いつからいつまで実施するのか」ということ管理することを上記の「スケジュール管理」の項目で解説していきました。
しかしながら、実際プロジェクトではスケジュール表に書いた作業以外にもやることがあります。それは、例えば「作業中に何か問題が起こった場合に対策を立てて実施する」などといった、あらかじめ計画できないような作業のことになります。
そのようなことを誰が責任を持って実施するのか、これらの資料ではまだ十分に明確化できておりません。そこで、体制図を作成した後に「役割分担表」という表を作り、チームやメンバーの役割をさらに明確に明文化することが有効になります。
7.4 責任と権限の明確化
プロジェクトマネジメントにおける「責任と権限明確化の重要性」は疑いのないところでしょう。今回はこれを実現するためのフレームワークを2点を紹介していきます。
7.4.1 作業責任マトリクス（TRM）
このフレームワークでの重要なポイントは、「責任者（主担当者）」と「通常の担当者」を明確に分離して示すことになります。ここでは、メンバー別に主担当、担当を明確化してみました。この取り決めは、各担当者のモチベーションとプロジェクトへの参画意識を高めるのに有効となります。
7.4.2 責任分担表（LRC）
開発業務の代表的ケースを一般化し、下記に例示してみました。組織横断的なプロジェクトの場合、誰が意思決定者で、誰が実行者なのかを明確化することで、プロジェクトの統制がスムーズになります。
簡単な取り決めですが、現実の業務では、これが非常に重要なものとなってきます。各責任者の役割が明確化されていますので、これで責任のなすりあいが可能な限り削減することが可能になります。
8.コストの算出（コストマネジメント）
この項目では、プロジェクトマネジメントのコストの算出（コストマネジメント）について解説していきます。
8.1 コストマネジメントとは
PMBOKにおけるコストマネジメントとは、プロジェクトを予算内で完了させるために必要なコストの見積もりや予算設定、コントロールの活動を表します。
8.1.1 コストマネジメントの目的
承認された予算内でプロジェクトを完了させるのがコストマネジメントの目的になります。当然ながら、予算は無限にあるわけではなく、限られた予算でビジネスニーズを満たす必要があります。
ビジネスニーズを解決するソリューションがいくら優れていてもコストに見合わなければ意味がありません。プロジェクトの現実的な予算を設定し、コストを超過させないためにもコストマネジメントが必須になります。
8.1.3 コストマネジメントの注意点
コストマネジメントにおいて、最も抑えておきたいのが根拠となる情報がないまま見積もりを行うことになります。知見を活用してわからないことをなくしていくことが重要になります。
故に、計画の段階で見積もりの精度を上げるために知見を積極的に活用しましょう。組織内で似たようなプロジェクトを経験している人の知見があれば、必要な作業や起こりうるトラブルを予想でき、見積もりの精度を上げることができます。
8.2 コスト・マネジメント計画
コスト・マネジメント計画プロセスでは、プロジェクトを通したコストの計画やマネジメント、支出、コントロールするための方針や手順、文書化を確立します。
プロジェクト憲章やプロジェクトマネジメント計画書から予算とコストに関する情報を確認し、専門家や関係者の会議を経てコスト・マネジメント計画書にまとめます。下記が「コストマネジメント計画」の参考事例になります。
コストマネジメントとは、考え方自体はそれほど難しいものではなく、「成果物とタスクから必要な人員や機器などの資源を洗い出し、そこから必要な金額を計画する」だけになります。
そして、その計画どおりにプロジェクトを完了させるよう働き掛けていくことであります。しかし、多くの方が経験しているのではないかと思うが、スケジュール同様、当初計画どおりの予算で終了させることは難しくなります。特にプロジェクトの規模が大きくなればなるほど困難になります。
8.2.1 コスト・マネジメント計画書作成時の検討事項
コストマネジメント計画書を構築する際の検討事項は、下記の6つになります。
①.有効桁数・・・アクティビティのコスト見積もりは、アクティビティのスコープやプロジェクトの規模に応じて、アクティビティ見積りの精度に丸めます。丸めるとは、プロジェクトの大きさによって、10万円とか100万円という単位で丸めるという意味です。
②.測定単位・・・測定のために使用する単位を定義します。例えば、労働時間数や労働日数など。
③.組織の手続きとのリンク・・・WBSはコスト・マネジメントの枠組みを提供して、コスト見積りや予算化、コントロールに一貫性を持たせるものです。
プロジェクトのコスト管理に使用するWBS要素は「コントロール・アカウント（CA）」と呼ばれます。個々のCAには、母体組織の会計システムで使用している勘定科目のコードと紐付けられます。
④.管理限界値・・・コスト・パフォーマンスを監視するための差異の限界値を定義します。例えば、コスト・パフォーマンス・ベースラインからの差異の許容範囲を±15%にするなど。
⑤.パフォーマンス測定の規則・・・パフォーマンス測定の「アーンド・バリュー・マネジメント（EVM）」を設定します。コストマネジメント計画書には以下の内容を含めます。
⑴.WBS、コントロール・アカウントとして測定する箇所の定義
⑵.採用するアーンド・バリュー測定技法の規定
⑶.予定する完成時総コスト見積り（EAC）の予備を決定するためのアーンド・バリュー・マネジメント計算式、およびその他の追跡方法の決定
⑥.報告形式・・・コストに関する報告の書式や報告頻度を定義します。
8.3 コスト見積もり
コストマネジメントの方針や手順が定まったら、実際にコストを見積もっていきます。コスト見積もりでは、アクティビティに必要な資源に対しての妥当なコストを定量的に見積もる必要があります。
プロジェクトにとって、最適なコストになるようインハウス化するのか外部に委託するのかといった代替案も検討します。
＜人的資源マネジメント計画書＞
プロジェクト要員の単価や表彰、報酬を確認。
＜スコープ・ベースライン＞
成果物に関する情報と合わせて、セキュリティやライセンス、許認可といった契約や法律関連の要求事項も確認。
＜プロジェクト・スケジュール＞
アクティビティに割り当てた資源や量、期間を確認。
＜リスク登録簿＞
リスク対策費要求を確認。インプットを元に見積もり手法を用いて最終的にプロジェクト完了のために正当であると思われるコストを定量的に評価したアクティビティ・コスト見積もりを作成します。
＜見積もり手法＞
コスト見積もりの手法としては、主に以下が挙げられます。状況に応じて使い分けましょう。
類推見積法 : 過去の類似したプロジェクトで発生したコストに基づき、相対的に見積もる手法
パラメトリック見積もり法 : 過去の情報と他の変数との統計的関係を使用し、見積る手法
ボトムアップ見積法 : ワークパッケージやアクティビティから工数を見積もり、それらを積み上げて全体の工数を見積もる手法
8.4 予算設定
ワークパッケージやアクティビティのコスト見積もりが終わったら、それらを積算してプロジェクト全体の予算を算出していきましょう。アクティビティ・コスト見積もりを元にプロジェクト・スケジュールを把握しながら時系列に予算配分を行い、コスト・ベースラインを構築していきます。
また、予算は一度に与えられるのではなく、期間ごとに必要な予算が分割されます。予期しないリスクが発生した場合の余裕も合わせて、プロジェクト資金要求事項として予算を要求していきます。
8.4.1 プロジェクトの収益予測
プロジェクトの成果物に見込む収益などのパフォーマンスを予測するには、投資収益率や割引キャッシュフロー、投資回収分析などの、多くの一般的なマネジメント技法を使います。
・数学的モデルと利益測定法
プロジェクトの収益予測で使用される、プロジェクト選定手法には以下の2つに分類できます。
数学的モデル制約条件付き最適化法とも呼ばれ、大規模で複雑なプロジェクトの選定で使われる手法になります。「線形計画法」「非線形計画法」「動的計画法」「整数計画法」「多重目標計画法」を使用します。
利益測定法プロジェクトの選定の際に、一般的に使われる手法です。費用便益分析や重み付け得点モデル、回収期間法、DCF、NPV、IRR、EPVなどがあります。これらの利益測定法については、試験に出題される可能性がありますので、それぞれ解説しておきます。
・費用便益分析法
費用便益分析法とは、プロジェクトがもたらす金銭的価値とプロジェクトの導入費用を比較する手法になります。「BCR（Benefit Cost Ratio）」や「BCA（Benefit Cost Analysis）」で表記されます。
計算式は以下の通りです。
BCR(%) = Benefit（収入） × 100 / Cost（費用）
BCRが1.0以上であれば、初期投資額を回収できると判断されます。
・重み付け得点モデル
「重み付け得点モデル」とは、プロジェクト選定の際に用いられる評価項目に重み付けをして評価する手法になります。重み付けした得点の高いプロジェクトが優先されます。
・回収期間法
回収期間法とは、プロジェクトで作られた製品がライフサイクル期間で見込める収入に着目して、プロジェクト投資費用を回収するために必要な期間を算出する手法になります。通常は、回収期間が短いプロジェクトが優先されます。
例えば、プロジェクトの投資費用が20億円で、毎年5000万円の収入が見込まれる場合の回収期間は、
回収期間 = 20億円 / 5000万円 = 4年
回収期間法の問題点としては、貨幣の時間的価値を考慮していないため正確性に欠ける点があります。
・DCF（割引キャッシュフロー分析）
DCFは、将来受け取るお金は、現在より貨幣価値が低いという考えに基づいて、将来に受け取る金額を現在の貨幣価値に換算して評価する手法になります。計算式は以下の通りです。
通常は、回収金額を現在価値に換算した金額が、初期投資額を上回っていれば、初期投資額を回収できると判断されます。
PV = FV / （1 + r）n乗
PV：現在価値
FV：将来価値
r：割引率
n：期間
例えば、プロジェクトの投資費用が20億円で、プロジェクトで作られた製品は10年間で40億円の売上が見込まれていて、割引率は年間5%とした場合、
PV = 40億円 / （1 + 0.05）10乗 = 25億円
DCF = PV – 投資額 = 25億円 – 20億円 = 5億円
となり、現在価値が投資額を上回っていると判断できます。
・NPV（正味現在価値分析法）
NPVは、将来得られる金額について、期間ごとに現在価値に換算していく手法になります。DCFに似ていますが、DCFよりも将来価値を厳密に算出できる点がポイントです。通常は、NPVがゼロ以上であれば、プロジェクトは承認されます。
DCFで記載した例をNPVで算出してみます。毎年4億円の売上があるとして算出します。
1年目：4億円 / （1 + 0.05）10乗 = 2.5
2年目：4億円 / （1 + 0.05）9乗 = 2.6
3年目：4億円 / （1 + 0.05）8乗 = 2.7
4年目：4億円 / （1 + 0.05）7乗 = 2.8
5年目：4億円 / （1 + 0.05）6乗 = 3.0
6年目：4億円 / （1 + 0.05）5乗 = 3.1
7年目：4億円 / （1 + 0.05）4乗 = 3.3
8年目：4億円 / （1 + 0.05）3乗 = 3.5
9年目：4億円 / （1 + 0.05）2乗 = 3.6
10年目：4億円 / （1 + 0.05）1乗 = 3.8
= 合計：30.9
NPV = PV – 投資額 = 30.9 – 20 = 10.9億円
となります。
・IRR（内部収益率法）
IRRは、将来得られる金額の現在価値と初期投資額が等しくなる利率のことです。NPVがゼロになる割引率のことをいい、IRRが高い方が望ましいといえます。
・EMV（期待金額価格）
EMVは、リスク（不確実性）を考慮したプロジェクト選定手法になります。通常は「デシジョン・ツリー分析」と組み合わせて利用されます。EMVは以下の式で算出することができます。
EMV = (影響を金額で表した価) x 発生確率
例えば、以下の2つのプロジェクトがあり、どちらのプロジェクトを選定するかを考えてみます。
■ プロジェクトA
投資額：100億円
発生確率60% → 売上200億円
EMV = 60億円
発生確率40% → 売上60億円
EMV = -16億円
EMV = 60 – 16 = 44億円
■ プロジェクトB
投資額：80億円
発生確率80% → 売上120億円
EMV = 32億円
発生確率20% → 売上100億円
EMV = 4億円
EMV = 32 + 4 = 36億円
以上から、EMVが大きいプロジェクトAが選定されます。
・EPV（期待現在価値）
EPVは、EMVと同様に「リスク（不確実性）」を考慮したプロジェクト選定手法になります。EMVとの違いは、EPVはNPV（正味現在価値）にリスクを考慮した選定手法である点で、EMVに貨幣の時間的価値を考慮したものになります。
EMVで例示したものに、それぞれ以下のように売上時期と割引率を考慮に入れた場合を考えてみます。
■ プロジェクトA
投資額：100億円
売上時期：5年後
割引率：5%
発生確率60% → 売上200億円
NPV = 200 / (1 + 0.05)5乗 = 157億円
EPV = (181 – 100) × 0.6 = 34億円
発生確率40% → 売上60億円
NPV = 60 / (1 + 0.05)5乗 = 47億円
EPV = (54 – 100) × 0.4 = -21億円
EPV = 32 – 21 = 11億円
■ プロジェクトB
投資額：80億円
売上時期：2年後
割引率：5%
発生確率80% → 売上120億円
NPV = 120 / (1 + 0.05)2乗 = 109億円
EPV = (109 – 80) × 0.8 = 23億円
発生確率20% → 売上100億円
NPV = 100 / (1 + 0.05)2乗 = 91億円
EPV = (91 – 80) × 0.2 = 2億円
以上より、EPV = 23 + 2 = 25億円
以上から、EPVが大きいプロジェクトBが選定されます。以上がプロジェクト選定手法になります。「数学的モデル」と「利益測定法」には、それぞれどのような選定手法があるのかは、明確に押さえておきましょう。
8.5 コスト・コントロール
コスト・コントロールは、プロジェクトを監視し、コスト・ベースラインへの変更を管理していきます。プロジェクトマネジメント計画書のコスト・ベースラインとプロジェクト資金要求事項で要求した資金を確認し、実績である作業パフォーマンス・データと照らし合わせます。
分析には、「アーンド・バリュー・マネジメント法（EVM）」が用いられ、コストやスケジュール、スコープを統合的に測定します。
分析した結果である作業パフォーマンス情報とEVMで得られた完成時総コスト見積もりは文書化します。結果からコスト・ベースラインの変更が必要な場合は変更要求を行います。
8.5.1 アーンド・バリュー・マネジメント（EVM）
プロジェクトの計画と実績を評価する手法になります。出来高、実コスト、計画を比較して、パフォーマンスを測定します。
コストマネジメントは予算内にプロジェクトを完了させるために不可欠な手法です。顧客の予算は限られており、コストに見合ったソリューションを提供しなければならないからになります。コストを超過すれば、顧客の信頼を失うだけでなく、プロジェクト自体が立ち行かなくなります。
9.品質マネジメント
この項目では、プロジェクトマネジメントの品質に関する「品質マネジメント」について解説していきます。
9.1 品質マネジメントとは
品質マネジメントとは、プロジェクトのプロセスや成果物の品質を管理する活動を言い表します。顧客の要求に一致した成果物を作成するために品質を管理する方針や計画を立て、パフォーマンスを検証することで改善活動を実施します。
品質管理の目的は、「限られたコストと期限の中で成果物の品質を最大限保証すること」
成果物だけでなく、プロセスの品質にも及ぶことに注意してください。プロセスで問題が生じた際に、その原因と対策を共有することで品質は上がります。
そのため、目に見えにくいプロセスについても留意する必要があります。プロジェクトではコストや納期に意識が向きがちですが、品質が低ければ顧客は満足してくれません。
顧客のニーズを的確に捉え、明確に形にすることが品質マネジメントの目的になります。プロジェクト品質マネジメントでは、プロジェクトのマネジメントと成果物の両方を取り扱います。
プロジェクト品質マネジメントは、成果物の性質にかかわらず、すべてのプロジェクトに適用されるのに対して、成果物の品質の指標や技法は、プロジェクトで生み出される成果物の個々のタイプに固有なものになります。
それはプロジェクト活動自体の品質と、プロジェクト活動の結果出来上がる成果物の品質の両方を対象とします。PMBOKでは、プロジェクト品質マネジメントを「品質計画」「品質保証」「品質管理」の3つのプロセスで行うとしているが、
「品質計画」では「品質方針」の他スコープや成果物の記述書 等のインプットから、QC活動等で知られた特性要因図 等の「フローチャート」や「ベンチマーキング」などの技法、ツールを用いて「品質マネジメント計画書」、「運用基準」、「チェックリスト」などを作成します。
「品質保証」は、プロジェクトが適切な品質規格を満たしながら進められているかどうかの第3者的な視点からの監査（レビュー）を通して具現化され、その結果は品質改善の指摘というアウトプットを生成し、プロジェクトの変更要求や是正処置を促すことになります。
「品質管理」のプロセスは、プロジェクト活動全体を通して行われる品質維持のための活動になります。品質管理のためには適切な検査を行い、その結果で承認（受け入れ決定）、手直し、予防、是正処置は適時行われます。
プロジェクト品質マネジメントでも、一般的な品質管理でも重視されるのは、結果を検査して改善することより、品質割れや、低下を未然に防ぐ、予防の概念であります。また品質は成果の生成過程に作り込まれるべきものでもあります。
9.1.1 品質の概念
・「正確さ」
測定された値が真の値に非常に近い状態
・「精度」
繰り返し測定された値が集中しており、バラツキがほとんどない状態
・「等級」
同一の用途を有するが、技術的特性が異なるプロダクトやサービスに定めたグレードが高い状態
・「品質」
本来備わっている特性がまとまって、要求事項を満たす度合いが高い状態
〇インプット
・「プロジェクトマネジメント計画書」
プロジェクトマネジメント計画書には、品質管理に使用される品質マネジメント計画書が含まれます。品質マネジメント計画書には、プロジェクトにおいてどのように品質管理プロセスを実行するかが記述されています。
・「品質尺度」
品質尺度は、プロダクトやプロダクト属性が何であるか、品質管理プロセスでどのように測定するかについての運用基準が記述されています。
・「品質チェックリスト」
品質チェックリストは、一連のステップが実行されたことを確認するために用いられる構造化されたツールになります。
・「作業パフォーマンス測定結果」
作業パフォーマンス測定結果は、アクティビティの評価指標を生成するために使用され、その評価指標により進捗の計画と実績が比較されます。評価指標には以下のようなものがあります。
・技術パフォーマンスの計画対実績の比較
・スケジュール・パフォーマンスの計画対実績の比較
・コスト・パフォーマンスの計画対実績の比較
・「承認済み変更要求」
統合変更管理プロセスの一部である「変更要求状況更新版」を見ると、どの変更が承認されたかがわかります。承認された変更要求には、欠陥修正、作業方法の変更、スケジュールの変更などの修正が含まれていることがあります。
承認された変更はタイムリーに実施されたことを検証する必要があります。
・「要素成果物」
実行プロセス群で作成されたプロジェクトの成果物です。
・「組織のプロセス資産」
品質管理プロセスに影響を与える組織のプロセス資産には以下のようなものがあります。
・品質標準および品質方針
・標準作業ガイドライン
・課題および欠陥の報告手順とコミュニケーション方針
9.1.2 品質の基準
「品質」＝設計済みの品質特性 / 設計すべき品質特性（品質特性の充足度）
一般的に品質は、「機能性・信頼性・使用性・効率性・保守性・移植性」の各品質特性に分類されます。このうち機能性を除くと非機能要件がシステムを実現する上で品質の要素となります。
9.1.3 品質測定の品質と共通的な尺度の関係
ここでは「品質測定の品質」と「共通的な尺度の関係」について解説していきます。
〇設計充足度
・設計項目ごとの特徴
・設計内容
〇設計プロセス
①.設計の品質
・レビュー
・レビューの実施回数
・レビュー時期
・レビュー時間
・参加者の数-有職者の数
・指摘事項数
・指摘事項への対応
・指摘事項修正数
・指摘事項修正の工数
・指摘事項修正の期間
②.レビューの実施状況
・指摘能力
・修正能力
・修正速度
・修正効率
9.2 品質マネジメント計画
品質マネジメント計画では、品質の定義を行い、その品質を確保するための方針や計画を作成します。まずは要求事項文書から顧客の要求を確認します。顧客の要求が品質に直結するため、要求事項を正確に掴む必要があります。
合わせてリスク登録簿から品質に関するリスク情報も確認しましょう。そして、これらの情報を元に品質を担保するためのコストを評価します。高品質を保つことで、手直しの減少や生産性の向上が見込まれるため、コストと比較することで投資対効果を分析します。
分析結果から、品質方針や手順を品質マネジメント計画書にまとめます。
＜品質コスト＞
品質コストは「適合コスト」と「不適合コスト」に分かれます。「適合コスト」は欠陥が生じないように対処するコストのことで、「不適合コスト」は発生したコストに対処するためのコストになります。
〇品質コスト
①.予防コスト・・・製品の不良を予防するための費用。
②.評価コスト・・・製品の品質を保証するために品質検査、評価にかかる費用。
〇不適合コスト
①.内部不良コスト・・・顧客に製品を納品する前の自社で発生した不良に対する対処費用。
②.外部不良コスト・・・顧客に製品を納品した後に発生した不良に対する対処費用。
9.3 品質保証
品質保証では、品質標準と運用基準を満たすために、全てのプロセスの品質改善活動を支援するプロセスです。つまり、無駄なくプロセスを実行できるようにパフォーマンスの測定結果を監査し、問題点を改善していく作業です。
改善点を洗い出すためには、まず品質コントロール測定結果を分析します。
分析の際には、QC7つ道具や品質監査を用い、問題点を抽出します。監査の結果、プロセスの改善点をまとめ、変更要求を行います。
＜QC7つ道具＞
品質改善のためにデータの分析に利用する7つの手法です。
9.4 品質コントロール
品質コントロールでは、パフォーマンスを測定し、品質マネジメントにおける実施作業を監視し、記録します。品質検査対象として指定された成果物や作業パフォーマンス・データを基に、QC7つ道具の利用や検査を行い、品質コントロール測定結果としてまとめます。
プロジェクト・チームはこの品質管理のプロセスで、一般的なツールを使用します。例を挙げると「管理図」「特性要因図（フィッシュボーンダイアグラム）」「パレート図」などのQC7つ道具をはじめ「検査」や「レビュー」などのツール、技法を使用します。
〇品質管理(品質コントロール)・インプット
・プロジェクトマネジメント計画書
・品質尺度
・品質チェックリスト
・作業パフォーマンス・データ
・承認済み変更要求
・成果物
・プロジェクト文書
・組織のプロセス資産
9.5 品質マネジメント活動全体を監視する
「品質保証」プロセスは品質マネジメント活動全般を監視し、無駄を無くしていくための活動です。トヨタ自動車の「カイゼン」活動に代表されるように、プロジェクトの活動が適切なプロセスを踏んで行われているかを監視し、継続的に無駄を排除するためにプロセスの見直しを行います。
その代表的な技法が「品質監査」です。品質監査は品質マネジメントの活動が、プロジェクトの方針や手順などに従って行われているかを第三者がレビューし、プロセスを改善するための提案を行います（アウトプットに提案済み是正処置が含まれます）。
また、ツールと技法に、「品質計画のツールと技法」「品質管理のツールと技法」と定義されているように、このプロセスは品質マネジメント全般にわたる活動であることが分かります。
〇監査の目的
・良い実務慣行やベストプラクティスの特定
・ギャップや欠点の特定
・組織や業界内で類似したプロジェクトで導入または実施されている実務慣行の共有
・チームの生産性の向上
・組織の教訓リポジトリへ、監査効果の登録
〇監査効果
・品質効果の削減
・顧客やスポンサーによる成果物の受入率の向上
〇実施者および実施スケジュール
・組織内または組織外の監査員（第三者）の指導のもとに実施
・適宜もしくは予定
10. スコープマネジメント
この項目では、プロジェクトマネジメントの「スコープマネジメント」について解説していきます。
10.1 スコープマネジメントとは
PMBOKにおけるスコープマネジメントとは、プロジェクトの最終成果物を明確にし、必要な作業範囲を管理することです。プロセスの側面から見てみると、「計画プロセス群」と「監視・コントロールプロセス群」に分けられます。
計画プロセス群はプロジェクトの計画時に実施する作業、監視・コントロールプロセス群はプロジェクトの実行を通して実績を監視し、計画とのギャップをコントロールする作業です。
10.2 スコープマネジメントの目的
スコープマネジメントが最終成果物と作業範囲を管理することはお分りいただけたと思いますが、プロジェクトにおいてなぜ必要になるのでしょうか。
その答えは、顧客のニーズを満たし、顧客満足度（customer satisfaction、CS）を高めるためと言えます。
プロジェクトは顧客の目的を満たすために発足し、必要な成果物を定められた期間内に予算を超えることなく、高品質で作る必要があります。
そこで、顧客の目的を達成するために必要な成果物を明らかにし、期間や予算、品質に応じた作業範囲を管理するためにスコープマネジメントが必要になります。
顧客の目的を満たすために顧客から寄せられる要望は多岐に渡ります。しかし、定められた期間や予算がある以上、全ての要望を実現することはできません。顧客の要求事項を整理し、本当に必要な要素だけを最終成果物や実施作業として落とし込むことがスコープマネジメントの目的となります。
10.3 スコープマネジメントの抑えておきたい注意点
顧客の要望から必要な機能を落とし込むのがスコープマネジメントの目的ですが、顧客の要望を全てそのまま鵜呑みにしてはいけません。顧客の要望が目的に合致していない可能性があるからになります。
10.4 PMBOKスコープマネジメントの実施作業
スコープマネジメントの基礎知識については理解していただけたと思いますが、基礎知識だけでは、スコープマネジメントを現場で活用することはできません。
実施作業と成果物を実際に作成することで、現場で活用できる力を身につけることができます。それでは、スコープマネジメントのプロセスごとに実施作業と成果物を見ていきましょう。
10.5 スコープ・マネジメント計画
スコープ・マネジメント計画とは、スコープの定義や文書化、検証、マネジメントの方針を作成するプロセスになります。
スコープ・マネジメント計画以降のプロセスでは実際に顧客の要求を収集し、スコープを定義、検証、マネジメントしていきますが、本プロセスではそれをどのように行っていくかを示したガイダンスの役割を果たします。
プロジェクトの基本事項が記載されたプロジェクト憲章やプロジェクト・マネジメント計画書を基に、会議や専門家の判断を通じて、最終的にスコープ・マネジメント計画書と要求事項マネジメント計画書を作成します。
10.5.1 スコープ・マネジメント計画書
スコープ・マネジメント計画書はスコープの定義や文書化、検証、マネジメントをどのように行っていくかを記載します。具体的にはWBSの作成方針やスコープの妥当性を確認する際の基準を明記します。
10.5.2 要求事項マネジメント計画書
要求事項マネジメント計画書は顧客の要求をいかにして収集し、整理していくか、その方法を文書化したものになります。顧客の要求事項を収集する方法やスケジュールを明記します。
10.5.2.1 要求事項収集
要求事項収集は、顧客やスポンサーといったステークホルダーのニーズを定義し文書化するプロセスです。
統合マネジメント領域で作成されたプロジェクト憲章とコミュニケーションマネジメント領域で作成されたステークホルダー登録簿をインプットとして使用します。プロジェクト憲章には、プロジェクトの基本事項であるプロジェクトの目的や主要成果物が記載されています。
この段階では、ステークホルダーのニーズが抽象化されたままなので、ステークホルダー登録簿に記載のステークホルダーをインタビューし、ニーズを具体化した要求事項文書を作成します。要求事項はステークホルダーからニーズを聞き出していくにつれ、段階的に詳細化されます。
また、要求事項が適切に処理され、スコープや最終成果物に落とし込まれているかを確認しなければ要求事項を作る意味がありません。要求事項トレーサビリティ・マトリックスを作成し、プロジェクトのライフサイクルを通して要求事項を追跡します。
・「要求事項トレーサビリティ・マトリックス」
プロジェクトのライフサイクルを通じて、要求事項の追跡のために使う表のことです。主に要求事項の発生源や優先順位、承認・変更などの状況が記載されます。
10.5.3 スコープ定義
スコープ定義は、要求事項を踏まえプロジェクトのスコープをより詳細に定義するプロセスになります。プロジェクト憲章と要求事項収集で作成した要求事項文書を元にプロジェクト・スコープ記述書を作成します。
インプットからプロジェクトの要素成果物と作業を詳細に記述する必要があるため、顧客の関係部門、及び開発担当者といった専門家を含めて、具体化していきます。従来の要求では実現が難しい場合も代替案を練り、要求事項実現のためアプローチしていきます。
10.5.4 プロジェクト・スコープ記述書
プロジェクト・スコープ記述書はプロジェクトのスコープを詳細に定義した文書です。定義すべきスコープは、プロジェクトが創出するプロダクトやサービス、所産に特有の特性や機能を表す成果物スコープと成果物を生みだすために必要な作業を表すプロジェクト・スコープがあります。
組織によっては一部の人しか要求事項の作成に関わっておらず、権力のある人の声が大きくて不必要な要望が紛れていることがあります。
顧客の真のニーズを満たすためには顧客と信頼関係を築き、その要望に関係が深い部門との関わりが必要です。目の前の担当者だけでなく、要望に関係が深い人もプロジェクトに巻き込み、真のニーズを引き出すことが求められます。
10.5.5 WBS（Work Breakdown Structure）作成
要求事項文書、及びプロジェクト・スコープ記述書からプロジェクトの要素成果物と作業をWBSに落とし込むプロセスです。WBSを作成することで必要な作業を明確にし、スケジュール作成や工数見積もりを行うことができます。
WBSの作成には、要素分解といった技法が用いられ、階層構造に分解することでスケジュールやコスト見積もりの対象となるワークパッケージまで落とし込みます。
10.5.6 スコープ妥当性確認
完成した要素成果物を顧客やスポンサーがレビューし、公式に受け入れるプロセスです。成果物が要求事項と受入れ基準を満たしているか検査を実施します。
品質マネジメントの品質管理プロセスで品質が確認された確認済み要素成果物が顧客に正式に受け入れられることで、受入れ済み要素成果物となります。
10.5.7 スコープ・コントロール
「プロジェクト・スコープ」と「成果物スコープ」を監視し、スコープ・ベースラインに対する変更を管理するプロセスになります。要素成果物の作成状況とスコープ・ベースラインの差異分析を行って差異を確認し、スコープ・ベースラインに沿うように是正処置案を作成します。
是正処置は統合マネジメントの統合変更管理プロセスに対して、変更要求を行うことで処理します。
スコープマネジメントは顧客の満足度を高めるために必要不可欠になります。品質や費用、納期は当然の事、顧客の目的を理解してニーズを引き出し、目的達成のために必要なものは何かを明確にする必要があるからになります。
目の前の担当者だけでは、真のニーズを引き出すことはできません。要望に関係が深い人に必ずアプローチして、本当に必要なものを追求していくことで適切なスコープを設定することができます。
10.6 コミュニケーションマネジメント計画
この項目では、プロジェクトマネジメントの「コミュニケーションマネジメント」について解説していきます。
10.6.1 コミュニケーションマネジメントとは
コミュニケーションマネジメントとは、ステークホルダーが必要とする情報を把握し、正確な情報伝達を担う活動になります。チームメンバーだけでなく、顧客やスポンサーといったステークホルダーを含むことに注意してください。
コミュニケーションを取るのは当たり前だと思われるかもしれませんが、情報をただ伝えればいいわけではありません。伝えた情報を相手が理解しなければ意味がありません。重要な情報であればあるほど、相手が理解したか確認する必要があります。
コミュニケーション計画は、プロジェクトのステークホルダーが求める情報を定め、コミュニケーションヘの取り組み方を定義するプロセスになります。
10.6.2 コミュニケーションの要求事項の特定に必要な情報
コミュニケーションの要求事項の特定に必要な情報として以下のようなものがあります。
・組織図
・プロジェクト組織とステークホルダーとの責任関係
・プロジェクトに関係する専門分野、部門、特殊技能
・プロジェクトヘの参加者数、所在地といったロジスティックスに関する事項
・内部の情報ニーズ（組織内のコミュニケーションなど）
・外部の情報ニーズ（契約者とのコミュニケーションなど）
・ステークホルダー登録簿およびステークホルダー・マネジメント戦略からのステークホルダー情報
・コミュニケーション技術
プロジェクト・ステークホルダー間で情報をやり取りする手段は、極めて多岐にわたります。
例えば、プロジェクトマネジメント・チームは、簡単な打合せから大規模な会議に至るまで、または簡単な手書きメモ書きからオンランインでアクセス可能な資料 (例:スケジュールやデータベース)までの技法をコミュニケーション手段として用いることができます。
プロジェクトに影響を及ぼす要素として、以下のようなものがあります。
〇情報ニーズの緊急度
プロジェクトの成功は、更新頻度の高い情報を直ちに入手できることに依存するのか、あるいは定期的な書面による報告で十分なのか。
〇技術の可用性
既存システムは適切か、あるいはプロジェクトのユーズに対応した変更が必要か。例を挙げると、想定したステークホルダーは選択したコミュニケーション技術を使えるか。
〇予定されたプロジェクト要員の配属
予定しているコミュニケーション・システムは、プロジエクト参加者の経験や専門知識に合致しているか、あるいは教育や訓練が必要か。
〇プロジェクト期間
現在利用できる技術は、プロジェクトが終了するまでに変わりそうか。
〇プロジェクト環境
チームは対面で作業するのか、バーチャルな環境で作業するのか。
10.6.3 PMBOKコミュニケーションマネジメントの実施作業
コミュニケーションマネジメントの実施作業は計画、実行、監視・コントロールプロセスに分かれています。各プロセスにおける実施作業を見ていきましょう。
10.6.3.1 コミュニケーション・マネジメント計画
コミュニケーション・マネジメント計画では、ステークホルダーの情報ニーズを把握し、コミュニケーションの取り組み方を決めていきます。
ステークホルダーの情報ニーズはステークホルダー登録簿から引き出し、情報伝達の手段やタイミングを定め、最終的にコミュニケーション・マネジメント計画書にまとめます。
10.6.3.2 コミュニケーション・モデル
情報を相手に伝えるためには、自身の思考内容を言語化（コード化）し、相手がその内容を理解（解読）しなければなりません。メッセージの伝達の際には、理解を妨げる物理的、心理的ノイズを認識した上で適切な伝達方法を設計しましょう。
・「ノイズ」
メッセージの伝達や理解を妨げる要素（距離や不慣れな技術など）
・「解読」
メッセージを、意味のある思考やアイデアに戻すこと
・「コード化」
思考やアイデアを他者が理解できる言語に翻訳すること
コミュニケーション・モデルは、送信者と受信者の間で、情報がどのように受け渡されるかを示しています。
10.6.3.3 コミュニケーション手段
以下の3種類のコミュニケーション手段があります。
①.相互型コミュニケーション
「2人以上」の当事者間で、複数方向に情報が交わされるコミュニケーション手段です。特定の議題に関し参加者全員が共通の理解をするのに最も効率的な方法で、会議、電話、テレビ会議などがこれに含まれます。
②.プッシュ型コミュニケーション
その情報を知る必要がある特定の受信者に送信するコミュニケーション手段です。情報は確実に配布されますが、それが実際に意図した相手に届いたか、また理解されたかは保証されません。
プッシュ型コミュニケーションには、手紙、メモ、報告書、電子メール、ファックス、留守番電話、プレス・リリースなどが含まれます。
③.プル型コミュニケーション
情報量が大量であったり、受け手の人数が非常に多かったりする際に使用されて、受信者が自分の意思で情報にアクセスする 必要があるコミュニケーション手段です。この方法には「イントラネット」「eラーニング」「ナレッジ・リポジトリ」などが含まれます。
10.6.3.4 コミュニケーション技術
プロジェクト・ステークホルダー間で情報をやり取りする手段は、極めて多岐にわたります。
例を挙げると、プロジェクトマネジメント・チームは、簡単な打合せから大規模な会議に至るまで、または簡単な手書きメモ書きからオンランインでアクセス可能な資料 (例:スケジュールやデータベース)までの技法をコミュニケーション手段として用いることができます。
プロジェクトに影響を及ぼす要素として、以下のようなものがあります。
①.情報ニーズの緊急度
プロジェクトの成功は、更新頻度の高い情報を直ちに入手できることに依存するのか、あるいは定期的な書面による報告で十分なのか。
②.技術の可用性
既存システムは適切か、あるいはプロジェクトのユーズに対応した変更が必要かどうか。例を挙げると、想定したステークホルダーは選択したコミュニケーション技術を使えるかどうか。
③.予定されたプロジェクト要員の配属
予定しているコミュニケーション・システムは、プロジエクト参加者の経験や専門知識に合致しているか、あるいは教育や訓練が必要か。
④.プロジェクト期間
現在利用できる技術は、プロジェクトが終了するまでに変わりそうか。
⑤.プロジェクト環境
チームは対面で作業するのか、バーチャルな環境で作業するのか。
10.6.3.5 コミュニケーション・マネジメント
実行プロセスであるコミュニケーション・マネジメントでは、計画に基づいてプロジェクト情報の収集や配布、管理などを行います。プロジェクト情報の配布には紙媒体ではなく、プロジェクト管理ツールやグループウェアといったシステムを活用するのが、一般的になります。
伝達情報であるプロジェクト伝達事項にはパフォーマンス報告書や成果物、スケジュール、コストの状況などが挙げられます。
・「パフォーマンス報告」
プロジェクトのパフォーマンス情報を収集し、配布されます。情報としては、プロジェクトの進捗や予測などが含まれます。パフォーマンスを理解するために、ベースラインと実績データの比較、分析を行う必要があります。
10.6.3.6 コミュニケーション・コントロール
コミュニケーション・コントロールでは、計画に基づいたコミュニケーションが適切に実行されているかを評価、コントロールします。プロジェクトマネジメント計画書やプロジェクト伝達事項から計画に基づいた情報が配布されているか確認し、計画に変更があれば変更要求を行います。
コミュニケーション・コントロールはプロセスの改善サイクルを回すトリガーになる点を押さえておきましょう。
10.6.3.7 コミュニケーションマネジメントの計画
コミュニケーション計画は，形成した組織に対してコミュニケーション要素を実現するためのポリシーを確立することを目的としています。
・情報と利用者の定義 （指示，報告，検査，承認／メンバ，上位管理者など）
・コミュニケーション手段 （メール，ワークフロー，進捗ツールなど）
・共有する情報 （要員計画，スケジュール，WBS，リスク，重点
管理項目など）
・文書化 （議事録，プロジェクト状況報告書，技術文書など）
・プロジェクト組織のメンバの中には，目的達成型の雇用のメンバと時間拘束的な雇用のメンバーがいると
文書化の内、プロジェクト状況報告書はプロジェクトをステークホルダーとの位相合わせの上では特に重要であり、プロジェクトの概況と状況認識と課題と対策の報告及びスケジュールの進捗、要求の変更管理、リスク管理、財務管理の予実管理の計画になります。
10.6.3.8 コミュニケーションマネジメントの実施
プロジェクトマネジメントの一環として、コミュニケーションの実施を以下の様に行います。コミュニケーション・アクティビティには、以下のような多様な側面があります。
・内部（プロジェクト内）と外部（顧客、他プロジェクト、メディア、一般大衆）
・公式（報告書、メモ、概要説明）と非公式（電子メール、その場限りの話し合い）
・縦方向（組織の上下に対するもの）と横方向（同僚に対するもの）
・後任（ニュースレター、年次報告書）と非公認（オフレコのコミュニケーション）
・書面と口頭
・言語と非言語（声の抑揚、ボディ・ランゲージ）
コミュニケーション・スキルは、一般のマネジメントとプロジェクトマネジメントで共通していて、以下のようなものがあります。
・積極的かつ効果的に傾聴すること
・確実に理解するためにアイデアや状況を質問し、正しく理解すること
・チームがさらに効果的に活動できるように、チームの知識を増やすための教育を行うこと
・情報を特定し、または確認するために実態を調査すること
・期待を設定し、マネジメントすること
・行動を起こすように、個人または組織を説得すること
・当事者が相互に受け入れできる合意に達するように交渉すること
・深刻な影響が生じないように、コンフリクトを解決すること
・要点をまとめ、整理し、次の手順を特定すること
⑴.ステークホルダーとの位相合わせ
コミュニケーション計画で策定した文書に従い、プロジェクト状況を共有化します。プロジェクト状況報告では、全体を総合的に判断した格付けや各種のメトリックス（指標）を用いた客観的な評価も行います。
ちなみに、「アーンドバリュー分析」は進捗測定の上で最も浸透している手段であり、主に以下のような指標を使用します。
－主な指標－
・期間予算（Budgeted Cost of Work Scheduled）
・実際発生コスト（Actual Cost of Work）
・出来高（Budgeted Cost of Work Performed）
・完成予想コスト（EAC）
・コスト差異（Cost Variance）
・スケジュール差異（Schedule Variance）
⑵. コンフリクトマネジメントの実施
計画通りの進行するプロジェクトは稀であり、通常はプロジェクトの見直しが必要となります。すなわち、ステークホルダとの調整が発生するということであり、PMのコミュニケーション技術が必要になる部分であります。
－主なコンフリクトの例－
・スケジュールの見直しによる段取りの変更
・作業プライオリティの変更
・人的リソースの再配分
・技術的課題の解決策
・仕様変更に関わるコストの負担部署
・プロジェクトメンバ間の軋轢
10.7 組織マネジメント計画
組織のPMO、すなわち事業部などの部門PMOは、組織目標を達成するために、組織内のプロジェクトのプロジェクトマネジメントに関してとりまとめを行います。組織のPMOは、次の3つの重要な役割があります。
・部門全体のプロジェクトマネジメント力の向上
・経営層の「組織のプロジェクト統制」に関する支援
・個別プロジェクトの支援
この3つの役割はいずれも重要ですが、組織のPMOとして特長的な役割は、「1」「2」の役割になります。これに対して、特定のプロジェクト内のプロジェクトオフィス（PO）の役割は、「3」に限定されます。
これは、組織のPMOは、組織目標を達成するために、プロジェクトマネジメントをまとめる役割を持ちますが、特定プロジェクト内のPMOは、特定プロジェクトが成功するための役割を持ちます。
このように、PMOの形態によって、PMOの目的が異なることに注目する必要があります。組織のPMOの上記の3つの役割で、PMOが実施する機能には、以下のようなものがあります。
⑴.部門全体のプロジェクトマネジメント力の向上
組織には多くのプロジェクトが存在します。組織目標を達成するためには、組織全体のプロジェクトマネジメント能力の向上が必要になります。PMOは具体的には、次のような業務を遂行します。
・組織のプロジェクトマネジメント方針の決定
・組織のプロジェクトマネジメントに関する標準化
・プロジェクトマネジメント標準の定着化
・ツールや標準書式の整備と普及
・技法の整備と普及
・プロジェクト・マネジャーの人材育成
・プロジェクト・マネジャーのコンピテンシー
・プロジェクト・マネジャーのトレーニング
・ＰＭコミュニティー
・情報管理
・教訓管理
・プロジェクト情報管理
⑵．経営層の「組織のプロジェクトの統制」に関する支援
多くのプロジェクトのスポンサーになっている経営層に対して、PMOは正確な情報を提供したり、意思決定を支援することが求められます。PMOは具体的には、次のような業務を遂行します。
・重要プロジェクトの情報把握と可視化報告
・リソース管理支援
・経営層の意思決定支援
・プロジェクト審査制度
⑶.個別プロジェクトの支援
組織のPMOの基本的な役割として、個別プロジェクトが成功するように支援をする役割があります。具体的には次のような業務を遂行します。
・プロジェクトマネジメント計画書の作成支援
・プロジェクトマネジメント方法の定着支援
・プロジェクトモニタリング
・プロジェクト・マネジャーの意思決定支援
・メンタリングとコーチング
・問題発生プロジェクトのリカバリー
人的資源計画書作成プロセスは、プロジェクトにおける役割、責任、必要なスキル、上下関係等を特定して、文書化し、さらに要因マネジメント計画書の作成を行うプロセスになります。
■インプット
・アクティビティ資源に対する要求事項
アクティビティ資源見積りのアウトプットで、要因に関するニーズを確定します。
・組織体の環境要因
参考にする情報は、以下のようなものがあります。
・組織の文化や構造
・既存の人的資源
・人事管理方針
・市場の状況
・組織のプロセス資産
参考にする情報は、以下のようなものがあります。
・組織の標準プロセスと方針、標準化された職務分担規定
・組織図と順位記述書のテンプレート
・過去のプロジェクトに用いられた組織構造に関する情報
・ツールと技法
・組織図と順位記述書
チームメンバーの役割と責任を文書化する書式には、様々なものがあります。
・階層型のチャート
トップダウン形式で職位とその関係を示すのに使用します。
・マトリックス型のチャート
責任分担マトリックス（RAM）を使い、ワーク・パッケージやアクティビティとプロジェクトチームメンバーとの間の関係を図示するために使用します。また、RAMの一種として、RACIチャートがよく使われます。
R:Responsible = 「実行責任」
A:Accountable =「説明責任」
C:Consult = 「相談対応」
I:Inform = 「情報提供」
RACIチャートで重要な点は、役割と期待を明確に区分にすることになります。
・テキスト型のチャート
詳細な記述のためには、アウトライン形式がよく使われ、責任、権限、コンピテンシー、資格などを記入します。
10.8 プロジェクトマネジメント計画書のその他の該当部分
プロジェクトマネジメント計画書のその他の該当部分にも、以下の中にもプロジェクトをマネジメントする責任についての記載と説明があります。
・リスク登録簿
・リスク・オーナー
・コミュニケーション計画書
・コミュニケーション活動を担当するチーム・メンバー
・品質計画書
・品質保証や品質管理の実行責任者
・ネットワーキング
ネットワーキングとは、組織、業界、専門分野の人達と、公式あるいは非公式な交流を行うことになります。マネジメントとして取りうる様々な選択肢の効果に影響を及ぼす、政治的や人間関係的な要因を理解する上で有効です。
10.9 組織論
組織論は、要員、チーム、部門などの行動様式に関する情報を提供します。
その情報を効果的に用いると、人的資源計画策定のアウトプットの生成に必要な時間、費用、労力などを削減して、計画が効果的なものになる可能性を高めるものになります。
ただし、組織構造が異なると、個人の反応、パフォーマンス、人間関係などが変わってくることに留意することが必要になります。
■アウトプット
・人的資源計画書
・役割と責任
・役割と責任として、以下のようなものを記述します。
・「役割」
個人が説明責任をもつ領域を表す肩書き
・「権限」
資源の投入、意思決定、承認などの権利
・「責任」
個人が遂行することを期待されている業務
・「コンピテンシー」
アクティビティを完了するために必要なスキルと能力
・「プロジェクトの組織図」
プロジェクトの組織図は、プロジェクト・チーム・メンバーとその上下関係を図示したものになります。
・「要因マネジメント計画書」
要因マネジメント計画書はプロジェクトマネジメント計画書に含まれる人的資源計画書の一部になります。
要因マネジメント計画書は、他のマネジメント計画書とは異なり、プロジェクトマネジメント計画書の補助計画書ではないので注意してください。要因マネジメント計画書は以下の内容を記述します。
・「要因調達」
調達先、作業場所、コスト、機能部門からの支援などを記述
・「資源カレンダー」
作業のための期間や調達アクテイビティの時期などを記述。人的資源を図表化するツールとして、資源ヒストグラムがよく使われます。資源ヒストグラムは、月日など期間を横軸として、作業時間や要員数などを縦軸にしたヒストグラムです。
・「要因離任計画」
責任を終えたチーム・メンバーが離任する場合の方法と時期を記述します。
・「トレーニングのニーズ」
必要なコンピテンシーについてのトレーニングや資格取得についての支援や計画を記述します。
・「表彰と報奨」
表彰や報奨についての明確な基準と運用のための計画を記述します。
・「法令順守」
政府規則や労働協約などを順守する運用に関して記述します。
・「安全」
安全上の問題から保護する方針について記述します。要因マネジメント計画書とともに、リスク登録簿にも記載します。
プロジェクト・チーム編成は、人的資源の可用性を確認し、プロジェクトの任務を完了するために必要なチームを設定するプロセスになります。プロジェクト・チーム編成プロセスの考慮点としては以下があります。
プロジェクト・マネジャーやプロジェクトマネジメントチームは、プロジェクトに必要な人的資源を提供する立場にある、人々と効果的に交渉し、影響を及ぼす必要があります。
コンピテンシーが十分な要員が確保できない場合、コンピテンシーが不十分な代替要員を任命することがありますが、法令違反とならない範囲で行って、プロジェクトのスケジュール、予算、顧客満足、品質、リスクなどに反映させます。順守すべき法令の代表的な例として労働者派遣法があります。
※プロジェクト・チーム編成
■インプット
〇「プロジェクトマネジメント計画書」
プロジェクトマネジメント計画書には、以下の内容が含まれています。これらの情報は、プロジェクト要員を特定して、配置し、マネジメントし、コントロールし、その後の離任する等の方法を示す指針として使われます。
・プロジェクトに必要な職位、スキル、コンピテンシーを規定した役割と責任
・プロジェクトに必要な要員数を示すプロジェクトの組織図
・各プロジェクト・チーム・メンバーが必要とされる期間、およびプロジェクトチームの編成に関して重要なその他の情報を明確に記述した要員マネジメント計画書
・「組織体の環境要因」
組織体の環境要因では、以下の内容を参照します。
・人的資源に関する既存の情報
・人事管理の方針
・組織構造
・所在地など
・「組織のプロセス資産」
組織のプロセス資産では、以下の内容を参照します。
・組織の標準方針
・プロセス
・手順
・ツールと技法
・先行任命
プロジェクト・チーム・メンバーが事前に選定されている場合には、先行任命されたものとみなされます。この状況が起こりうるのは以下のような場合です。
・競争入札の一部として特定の要員の任命を約束している場合
・プロジェクトが特定の個人の専門知識に依存している場合
・一部の要員の任命がプロジェクト憲章で定められている場合
・「交渉」
多くのプロジェクトで、要員任命に関する交渉が行われます。例として以下のような人との交渉を必要としています。
・「調達」
プロジェクトの完了に必要な要員を確保出来ない場合、外部から調達や別組織への作業依頼などを行います。
・「バーチャルチーム」
バーチャルチームとは、共通の目標を持った要員の集まりで、相互に顔を合わせることがほとんどまたは、全く無いまま役割を果たすものになります。バーチャルチームは、電子メールや電話会議、Web会議などの電子コミュニケーションが利用可能になったことで実現しました。
バーチャルチームを採用することで、以下のようなことが可能になります。
・地理的に離れた地域に住む同じ会社の要員でチーム編成が可能
・専門家が同じ地域にいなくても、プロジェクト・チームに加えることが可能
・自宅をオフィスとして組み込むことが可能
・シフトや労務時間帯が異なる要員でチーム編成が可能
・異動が不自由な人を含めることが可能
・出張費用がかかるためこれまで無視してきたようなプロジェクトに取り組むことが可能
バーチャルチームの場合に気をつけないといけない点として、プロジェクトメンバーが顔を合わせることがほとんどなくなるため、コミュニケーションがより重要になる点になります。
■アウトプット
・「プロジェクト要員任命」
プロジェクト要員任命には、以下のような内容を記述します。
・チーム名簿
・メンバーの覚書
・プロジェクト組織図への名前記入
・プロジェクトマネジメント計画書への名前記入
・資源カレンダー
資源カレンダーは、プロジェクト・チームの各メンバーがプロジェクトのために作業できる期間を文書化したものになります。
・「プロジェクトマネジメント計画書更新版」
以下の内容が更新されます。
・「人的資源計画書」
人的資源計画書に規定した内容と任命した個人のコンピテンシーと異なる場合に反省させます。
プロジェクト・チーム育成は、プロジェクトのパフォーマンスを高めるために、コンピテンシーを強化し、チーム内の交流を促進し、チーム環境を改善させるプロセスです。プロジェクト・マネジャーに必要なスキルや活動には以下のようなものがあります。
・プロジェクト・チームを特定し、形成し、維持し、動機付けし、リードし、奮起させる
・チームワークを促進する環境を作る
・オープンで効果的なコミュニケーションの推進
・コンフリクトのマネジメント
・協力的な問題解決と意思決定
チーム・メンバーは多様な業種の経験があり、複数の言語を話す環境で仕事を進めることもあります。
プロジェクトマネジメント・チームは、文化的な違いを活かして、プロジェクト・ライフサイクルを通してプロジェクト・チームの育成と維持を行うことに集中して、相互に信頼できる環境の中でお互いに協力しあえる環境を作る必要があります。
プロジェクト・チームを育成する目標として以下のようなものがあります。
・コストを抑えて、スケジュールを短縮し、品質を向上させながら、プロジェクト要素成果物を完成させる能力を高めるために、チーム・メンバーの知識とスキルを向上させる
・士気を高め、コンフリクトを抑え、チームワークを向上させるために、チーム・メンバー間の信頼と合意の意識を改善する
・個人とチーム両方の生産性、チームの団結心、協力関係等を改善し、一般知識や専門知識の共有を目的としてチーム・メンバー間における相互のトレーニングやメンタリングを行えるようにするために、ダイナミックかつ結束したチーム文化を作り出す
・「プロジェクト・チーム編成」
〇プロジェクト要員任命
・「人間関係のスキル」
人間関係のスキルは、「ソフト・スキル」と呼ばれ、チーム育成に特に重要なスキルになります。プロジェクト・チームをマネジメントする上で必要な活動として以下のようなものがあります。
・感情の理解
・行動の予測
・関心事の認識
・課題の追跡
プロジェクト・チームをマネジメントする上で必要なスキルとして以下のようなものがあります。
・共感
・影響力
・創造性
・グループの円滑な意思疎通
・「トレーニング」
トレーニングは、プロジェクト・チーム・メンバーにコンピテンシーを高めることを意図したあらゆるアクティビティからなります。
トレーニングには、公式と非公式なものがあって、メンバーが必要なマネジメント・スキルや技術的スキルを欠いている場合は、プロジェクト作業の一部としてスキルを習得していきます。
チーム・メンバーのコンピテンシーを高める活動としては、以下のようなものがあります。
・予定したトレーニングは、人定資源計画書に従って実施する
・計画外のトレーニングは、観察や会話、パフォーマンス評価の結果を受けて実施する
・チーム形成活動
チーム形成活動の目的は、個々のチームメンバーが効果的に協力して作業できるようにすることです。チーム・メンバーが顔を合わせること無く離れた場所で作業している場合は、特に重要になります。
チーム環境を作る上で最も重要なスキルは、プロジェクト・チームの問題をチームの課題として扱い、話し合うことになります。こうした課題を解決するために必要な行動には、以下のようなものがあります。
・トップマネジメントの支持を取り付ける
・チーム・メンバーの積極的な参加の約束を取り付ける
・適切な表彰と報奨の導入
・チームのアイデンティティを作り上げる
・コンフリクトを効果的にマネジメントする
・メンバー間の信頼とオープンなコミュニケーションを促進する
・優れたリーダーシップの発揮
・タックマンモデル
PMBOKでは、チームの5つの発展段階を表す、「タックマンモデル」が紹介されています。
・「成立期」
チームの顔合わせの段階で、この段階では個々に独立していて心を開いていない状態
・「動乱期」
活動を開始する段階で、この段階では協力的でなく心を開かない場合があります。
■「状態」
・「安定期」
一緒に活動する段階で、この段階では自らの習慣や行動を調整して信頼し始める状態
・「遂行期」
よく組織されたチームとして機能する段階で、この段階では相互に依存している状態
・「解散期」
作業を完了して、プロジェクトから離任する状態。各段階の所要期間は、チームのダイナミックスや規模、リーダーシップによって異なります。チーム・メンバーが全ての段階を経過していくため、新しいメンバーが加わると、チームは成立期からやり直しになります。
プロジェクトの理想は、プロジェクトが終了するときの最も望ましい姿は、プロジェクトチームを解散することです。
・「行動規範」
行動規範とは、プロジェクトチーム・メンバーとして容認できる行動についての明確な期待を設定するものになります。いったん規範を設定した後は、プロジェクト・チーム・メンバー全員が規範を順守する必要があります。
・「コロケーション」
コロケーションとは、最も活動的なメンバーとほとんどが物理的に同じ場所に集まって活動することです。コロケーションは、プロジェクトの重要な時期のみ一時的に行う場合も、プロジェクト全体を通して行う場合もあります。
当然、同じ場所に集まれない場合は、バーチャル・チームを活用します。PMBOKでは、プロジェクトを遂行する形態として、コロケーションを推奨しています。PMBOKでは、プロジェクトを遂行する形態として、コロケーションを推奨しています。
・「表彰と報奨」
チーム育成プロセスの一部に、望ましい行動に対する表彰と報奨があります。要員を表彰する法案の原案は、人的資源計画書作成プロセスにおいて作成します。
個人に与えられる特定の報奨は、その人が重要だと考えているニーズに合ったものである場合にのみ効果があることを認識しておくことが重要です。また、文化的な違いについても考慮が必要になります。
報奨の対象は、望ましい行動にのみ限定すべきです。例えば、強気のスケジュール目標を達成するために積極的に残業することは、報奨対象にすべきですが、チーム・メンバーによる不十分な計画の結果として残業が必要になった場合には、報奨の対象とするべきではありません。
・「モチベーション理論」
モチベーション理論については、以下の専門家の名前と理論を覚えておきましょう。
・「マズローの欲求5段階説」
人の欲求は5段階あって、順に満たされていくものであるという考え方。
・生理的欲求
・安全・安定欲求
・社会的欲求
・尊厳欲求
・自己実現欲求
・「ハーツバーグの動機付け要因と衛生理論」
・動機付け要因
・達成、認知、責任、成長、内容、昇進
・衛生理論
※「給与」「処遇」「作業条件」「会社の方針」などは、仕事をするための「外部要因」であり、不満を予防するものであります。
・「マグレガーのX理論・Y理論」
・X理論
人は元来仕事が嫌いであるという考えに基づいて仕事をさせる。
・Y理論
人は適切な動機付け要因の元で仕事をするものである、という考えに基づいて仕事をさせる。
・期待理論（2段階期待）
人は成功するために努力し、成功の暁には報奨を期待する
■アウトプット
・「チームのパフォーマンス評価」
チーム機能の実効性についての評価指標には以下のようなものがあります。
・各人のスキルの改善
・コンピテンシーの改善
・要員の離職率低減
・チームの結束力の強化
プロジェクトマネジメント・チームは、チームの全体的なパフォーマンスの評価を行う結果、トレーニング、コーチング、メンタリング、助力、パフォーマンス改善に必要な変更及び、そのために必要な資源の特定などを実施します。
・「組織体の環境要因更新版」
更新される内容には以下のような物があります。
・教育研修記録
・スキル評価などの人事管理
プロジェクト・チームのマネジメントは、プロジェクト・パフォーマンスを最適化するために、チーム・メンバーのパフォーマンスを追跡し、フィードバックを行い、課題を解決し、変更をマネジメントするプロセスになります。
・「プロジェクト・チームのマネジメント」
チームマネジメントの活動には以下のようなものがあります。
・チームの行動の観察
・コンフリクト・マネジメント
・課題の解決
・チーム・メンバーのパフォーマンス評価
マネジメント活動の結果としての活動としては、以下のようなものがあります。
・変更要求の提出
・課題の解決
・パフォーマンス評価に対する情報提供
・教訓の解決
さらにマネジメントに必要なスキルとしては、以下のようなものがあります。
・コミュニケーション
・コンフリクト・マネジメント
・交渉
・リーダーシップ
やりがいのある任務を与え、高いパフォーマンスに対して表彰する
■インプット
・「チームのパフォーマンス評価」
プロジェクト・チームのパフォーマンスの公式または、非公式な評価を継続的に行います。結果として以下の項目に対して、改善を実施します。
・課題の解決
・コミュニケーションの修正
・コンフリクトへの対応
・チームの相互作用の改善
・「実績報告書」
実績報告書は、進行中のプロジェクトの状況をその予測と比較した文書です。実績報告書は以下の項目に対して利用します。
・人的資源に対する要求事項
・表彰と報奨
・要員マネジメント計画書
・組織のプロセス資産
以下のような内容を参考にします。
・感謝状
・ニュースレター
・Webサイト
・特別賞与制度
・企業ユニフォーム
・ツールと技法
・観察と会話
観察と会話は、プロジェクト・チーム・メンバーの作業と態度を継続して把握しておくために行います。監視する指標としては、以下のようなものがあります。
・要素成果物の進捗状況
・達成した業績
・人間関係の課題
・プロジェクトのパフォーマンス評価
プロジェクト期間中にパフォーマンス評価を行う目的には以下のようなものがあります。
・役割と責任の明確化
・チーム・メンバーへの建設的フィードバック
・未知または未解決の課題の発見
・個人のトレーニング計画書の作成
・今後の具体的な目標設定
・コンフリクト・マネジメント
プロジェクトの環境では、コンフリクトは避けられないものになります。コンフリクトに対処する際は、以下のような特徴を認識しておく必要があります。コンフリクトは当然のことであり、従来とは異なる手段を探す力となります。コンフリクトはチームとしての課題になります。
オープンであることが、コンフリクトの解決に繋がります。コンフリクトの解決には、個人の人間性にではなく、課題に焦点を当てます。コンフリクトの解決には、過去ではなく、現在の焦点を当てます。コンフリクトの解決方法に影響を与える要員は、以下のようなものがあります。
・相対的な重要度と深刻度
・解決への時間的制約
・当事者の立場
・長期的あるいは短期的に解決しようとする動機
・「コンフリクトの解決方法」
コンフリクトの解決方法には、一般に以下の6つの方法があります。
・「強制」
他者を犠牲にして自分の観点を押し付ける。これは勝ち負け式（Win-Loose）の解決策しか提示しない。
・「撤退や回避」
現在ある、あるいは潜在的なコンフリクトから身を引く
・「鎮静や適応」
意見の異なる部分ではなく、同意できる部分を強調する
・「妥協」
当事者全員が、ある程度満足できる解決策を模索する
・「協力」
異なる観点から複数の視点や見識を取り込む。合意と確約につながる。
・「対峙や問題解決」
いろいろな手段を検討して解決すべき課題とする。ギブアンドテイクの態度とオープンな対話が必要。
この中で、「強制」と「撤退や回避」は、一時的には解決されたように見えるが、あらたなコンフリクトを有無場合があります。あくまでも最善な方法は、「対峙や問題解決」です。
・「課題ログ」
各課題を解決する責任者と目標期日を一覧表に記載して監視に役立てます。
⑴.人間関係のスキル
プロジェクト・マネジャーは、状況を分析するために、技術的、人間的、概念的なスキルを複合的に使って、チーム・メンバーと適切に対話します。
人間関係のスキルには、以下のようなものがあります。
⑵.リーダーシップ
リーダーシップは、プロジェクト・ライフサイクルのすべてのフェーズを通して重要です。特にビジョンを伝えて、高いパフォーマンスを達成するようにチームを鼓舞することが特に重要です。
⑶.影響力
マトリックス型組織の環境では、プロジェクト・マネジャーはチーム・メンバーに対して直接的な権限がほとんどないか、全くない場合が多いです。そのため、ステークホルダーに、タイムリーな影響を与えることのできる能力を持つことが成功には不可欠です。
影響力に関する重要なスキルには、以下のようなものがあります。
・説得力を持って、要点や立場を明確に述べられる能力
・積極的傾聴能力
・状況に応じ、いろいろな観点から考えられる能力
・信頼を維持しながら合意に達するために重要な情報の収集能力
・効果的な意思決定
組織やプロジェクトマネジメント・チームと交渉して影響を与える能力に関するもので、以下のようなものがあります。
・達成すべき目標に焦点を当てる
・意思決定プロセス順守
・環境要因の調査
・チーム・メンバーの人間関係の資質の育成
・チームの創造性の活性化
・リスクのマネジメント
〇アウトプット
・組織体の環境要因更新版
更新が必要になる項目には、以下のようなものがあります。
〇組織のパフォーマンス評価へのインプット
・要員スキル更新版
・組織のプロセス資産更新版
更新が必要になる項目には、以下のようなものがあります。
・過去の情報と教訓についての文書
・テンプレート
・組織の標準プロセス
・変更要求
プロジェクトマネジメント計画の実行に支障がある場合には、統合変更管理を通して変更要求を処理する必要があります。
変更要求として、以下のようなものがあります。
・配置転換
・作業の一部外注
・離任メンバーの補充
・予防処置
・担当社不在時のためのクロス・トレーニング
・役割のさらなる明確化
プロジェクト人的資源マネジメントは、プロジェクト・チームを組織し、マネジメントし、リードするためのプロセスです。
・計画プロセス群
・人的資源計画書作成
・実行プロセス群
・プロジェクト・チーム編成
・プロジェクト・チーム育成
・プロジェクト・チームのマネジメント
プロジェクト・チームをマネジメントし、リードする活動には以下のようなものがあります。
・プロジェクト・チームへの影響力の行使
・プロジェクトに影響する人的資源に関わる要因に注意を払い、可能ならプロジェクト・チームヘ影響力を行使する
・プロフェッショナルであることおよび倫理的な行動
・チーム・メンバー全員が、倫理的な行動をするように、リーダーシップを発揮し、それを確実に守るようにする
PMBOKでは、プロジェクトに関わる人達を以下のように分類しています。
・プロジェクト・チーム
・役割と責任を割り当てられた人々で構成されたチーム
・プロジェクトマネジメント・チーム
・プロジェクトの立ち上げから終結までのプロジェクトマネジメント活動やリーダーシップ活動を担当するチーム
・スポンサー
・プロジェクトマネジメント・チームに協力して、プロジェクトの資金調達、スコープの明確化、進捗監視などの支援を行う人々
11.リスクマネジメント計画
11.1 リスク・マネジメントの勘所
大問題が発生することが分かっていれば、手を打たないことは通常あり得ません。分からないか、発生しないだろうという認識から手を打たなかったのであります。
その背景として、「計画が明確に明確になっているか」、「体制が整っているか」、「費用ITプロジェクトの「見える化」上流工程編は妥当か」、「開発期間は十分か」、「発注側との関係は良いか」など、概念的で、かつタイミング的に疑問のあるリスク認識のみがリストアップされていることが多くなります。
また、数多くのリスク認識項目がリストアップされると、数の論理に気を
取られ、あたかもリスク・マネジメントを十分に行っているかのような錯覚に陥りやすくなります。
しかし、本質的にリスク・マネジメントを行うということは、「次の工程が
うまくいくために直前の工程がどういう状況にあるべきか。何が明確になっ
ていなければならないか」を考えることだと言っても良いでしょう。
11.2 リスク分析
（1）.リスク影響度の考え方
システム開発は、出来合いのものを同じ環境や条件で適用するよりも、カ
スタマイズするか、個別にシステムを構築するケースが多いです。
システム開発の上流工程におけるリスクは、「①.目的、要件の明確性」「②.計画、体制、組織の具体性」「③技術、進捗の確実性」「④プロジェクト・マネジメントの客観性」という4つの要素に分類できます。
一方、もう1つのリスク回避を阻害する要因の分類方法として、外部要因
と内部要因があります。これらの分類に、「①～④」を組み合わせると次のようになります。
外部要因は「目的」「要件」「計画」「費用」「体制」に密接に関連します。プロジェクトにとって根幹を成す要因であり、影響範囲は大きくなります。内部要因は、「計画」「組織」「技術」「進捗」「管理」に密接に関連します。
外部要因に比べ、影響範囲は小さいものの、具体性という点で結果への関連は大きくなります。したがって、リスクを分析する場合には、外部要因に力点を置くべきであるべきになります。
（2）.リスクの大小の判断方法
リスクの大小判断は、プロジェクトの特質により異なりますが、いくつかの視点があるのでここで紹介していきます。まず、連携動作する個所が多い場合、リスクが大きいと判断します。
例えば、関連するサブシステムが多い場合に、サブシステム間のインターフェースの仕様変更を想定してみましょう。例え、プログラムの変更量が小さくても、設計の見直し、運用の変更、テストのやり直しなど影響が大きいため、リスクも大きくなります。
11.3 曖昧性と不確実性のマネジメント
また、後工程になるほど、リスクが大きいと判断します。システム開発の途
中での変更、追加はやむを得ない事象としても、早い時期での変更、追加と、サービス・イン直前の変更、追加ではリスクの大小が異なります。
例えば、テスト段階で設計に関わる変更、追加は、工数、進捗に関係す
るだけでなく、作業の完成度にも影響します。当然、リスクは大きくなります。一方で、設計作業途中での変更、追加は、関係者が設計に注力しているため、一般的にリスクは小さくなります。
他のシステムや工程に対する影響度合いが大きい場合、リスクが大きいと判断する。過去の事例から考えると、
①.品質（正確性）
②.性能
③.機能（広義）
④.納期
⑤.費用の順
で、リスクの大小を判断するのが妥当と考えます。ただし、代替案があり、かつ代替案による対応が容易な場合にはリスクが小さいと判断します。
⑴.リスクの重み
①.リスク要因領域（A）
この領域のリスク要因は、基本的事項（特にQCDおよび法律、信用にかか
わる重要な項目）が合理性を持って確定しているか否かであります。上流工程だからといって「要件」「仕様」「方式」「体制」「費用」「計画」などの基本的事項が、この段階で決定していない、または確定していない状態を決して「やむを得ない」と容認してはなりません。
このような基本的事項の合理性に立脚し、このリスク要因領域におけるリスク認識を行いません。現実には、基本設計段階になっても要件が決定しない、または決定したとしても仮決定の意味が含まれていることが多くあります。
しかし、ある時期に物事が確定していることを前提において「規模」「生産性」「工数」「期間」など綿密に計画を立てているにもかかわらず、実際のプロジェクト運営が未決定、未確定、変更やむなしと捉えることは誤っています。
発注側、受注側もそれが当然と考え、また、それら不確定要素に柔軟に対処
することが受注側の実力と解釈する風潮があるとするならば、それはリスク・マネジメント上、非常に危険であります。最初から失敗を受け入れているようなものであります。
仮に、未決定、未確定事項がある場合、どのような些細な未決定、未確定事項でも問題視すべきだ。発注側、受注側の社内で問題提起（エスカレーション）し、公にすることが重要であります。
その後、計画を見直して、発注側、受注側の責任者の承認を得るなどの施策を実施します。これは、プロジェクトという立場を超えた発注側と受注側という企業間の問題だからであります。
無理をして決定、確定しないことも重要であります。計画通りに進捗しない場合、決定、確定に向けた行動をとることは当然になります。しかし、この段階で未決定、未確定があるということは、その背景に根深い問題が潜んでいることにほかなりません。
それを無理に決定、確定しても、必ず後工程で変更、追加が発生し、混乱します。プログラム製造、テストの消化などは、ある程度、増員、設備強化など物理的対応により進捗が促進される可能性があります。
だが上流工程においては、最低限必要な期間、巻き込むべき組織、採るべきプロセスがあり、これを無視できません。一方、問題を複雑にする理由として、納期まで時間的余裕があるため、「後工程で何とかなるだろう」という希望的観測、精神論的になります。
特にこのリスク要因領域は、現工程で予定通り進捗しないにもかかわらず、後工程で計画通り進捗する、あるいは後れを取り戻すなどプロジェクトの進捗が向上することは稀であることを認識すべきです。
②.リスク要因領域（B）
この領域のリスク要因は、以降の工程で、ジワジワと痛手を被るものがな
いか否かになります。この領域には、内容、質という若干抽象的な要素が問われるものと、抽象的要素を具現化するための組織的バックアップ体制が整っているかという要素があります。
それらを次の視点で認識する必要があります。
・「計画に曖昧さがある曖昧性と不確実性のマネジメントか」
・「計画実行に曖昧さがあるか」
・「コミュニケーション不良、モチベーション低下など人間的な問題が内在しているか」
・「上記の課題をひたすら頑張ろうなどという精神論で解決しようとする姿勢があるか」
・「第三者的立場による検証など客観的評価ができる組織か」
・「エスカレーションのルールが明確か、エスカレーションの効果は十分か」
などであります。
例えば、性能はシステムにとって重要になります。そのため、「リスク要因領域（A）」での必要性能を確定、試算、検証する手立て、つまり性能確保については誰でも認識が可能になります。
仮に、毎秒100件のトランザクションを処理する要件の場合「設備」「ツー
ル」「評価体制」などを整え、毎秒100件の性能要件を満たそうとします。問題は、実システム、あるいは実運用前のテストで、毎秒100件以上の負荷がかかった場合、この性能値の扱いについて発注側、受注側で大きく意見の分かれるところになります。
発注側は、毎秒100件以上の負荷がかかった場合、若干の処理遅れがあっても、システム障害に至るとは考えません。一方、受注側は、毎秒100件の負荷まで検証するとしても、それ以上の負荷がかかった場合にシステム全体にどういう影響が出るかは、設備、工数、ツール、期間などの制約、困難が発生するため、特別な場合を除いて検証しません。
その結果、一般的に性能改善には大きなリスクが伴う（危険性大）と理解しているにもかかわらず、リスク発生確率が低いため、見落としやすくなります。これを防ぐためには、第三者検証による先を見越したリスク・マネジメントが重要であります。
③.リスク要因領域（C）
この領域は、プロセスが目的に沿って正常に進展しているか否かが視点と
なりません。ただし、この領域は、発生確率が高いためリスク認識として欠落することは少なくなります。
何がリスクか、この領域でのリスク・マネジメントを怠ったらどうなるかは、参考文献が多く、マネジメント手法も確立されています。プロジェクト・マネージャ自身も体験的に知っています。
特に、プロジェクトで定めたルールの順守をプロジェクト・メンバーに任せきりにせずに、プロジェクト・マネージャ自身がマネジメントしなければならないことに注意する必要があります。
例えば、基本設計工程なら「要件」「規模」「機能」などに基づいて「設計書の目次」「書き方」「レビューの仕方」「是正処置」の手順を決めたルールを作るか、標準のルールを利用します。
④.リスク要因領域（D）
この領域は「マニュアルの体裁」「分かりやすさ」「画面のレイアウト・配色」「報告書の様式」「プロジェクト・ルームの環境」「プロジェクト・メンバーの質」など、重要ですが「経験」「説明」「教育」により課題を解決できる内容でもあります。
一般的にリスクが小さいため、リスク・マネジメントとしては、重要視されていません。しかし、この領域は、当事者の「趣味」「嗜好」「企業文化」というような価値観により、リスク認識が全く異なるため、扱いが非常に難しくなります。
リスクを認識する上で、要件の分かりやすさ、見やすさ、判断の容易さなど、概念的なものがある時に、本当に「要因領域（D）」のリスクであるかを検証することに注意しなければなりません。
半面、この領域のリスク・マネジメントは、計画に反映させ、地道に改善
しておかないと、中流・下流工程で「費用」「工数」「体制」「納期」「納品」に大きく影響することを意識する必要がありません。同時に見切りも必要になります。
⑴.問題のカテゴリーとパターン
プロジェクトマネジメントにおける問題の発生個所は、下記の5つになります。
「①.マネジメント」「②.要件定義と開発範囲」「③.設計・構築技術」「④.ステークホルダー」「⑤.モチベーション重要」
になります。計画通りに進捗しない場合「決定」「確定」に向けた行動をとること、決定、確定に向けた行動をとることは当然になってきます。
しかし、この段階では当然になってきます。しかし、この段階で未決定、未確定があるということは、未決定、未確定があるということは、その背景に根深い問題が潜んでいるこその背景に根深い問題が潜んでいることにほかなりません。
それを無理に決定にほかなりません。それを無理に「決定」「確定」しても、必ず後工程で変更、追加確定しても、必ず後工程で変更、追加が発生し、混乱します。
「プログラム製造」「テストの消化」などは、ある程度、増員、設備強化など物理的対応により進捗が促進される可能性があります。だが上流工程においては、可能性がありません。
一方、問題を複雑にする理由として、納期まで時間的余裕があるため、「後工納期まで時間的余裕があるため、「後工程で何とかなるだろう」という希望的程で何とかなるだろう」という希望的観測、精神論的になることでありません。
特観測、精神論的になることになります。特にこのリスク要因領域は、現工程でこのリスク要因領域は、後工程で計画通り進捗する、あるいは遅工程で計画通り進捗するなど、プロジェクトの進捗が向上することは稀であります。
⑵.曖昧性と不確実性のマネジメント
・「計画実行に曖昧さがあるか」
・「計画実行に曖昧さがあるか」
・「コミュニケーション不良、モチベーションミュニケーション不良、モチベーション低下など人間的な問題が内在している低下など人間的な問題が内在しているか」
・「上記の課題をひたすら頑張ろうか」
・「上記の課題をひたすら頑張ろうなどという精神論で解決しようとするなどという精神論で解決しようとする姿勢があるか」
・「第三者的立場による姿勢があるか」
・「第三者的立場による検証など客観的評価ができる組織か、検証など客観的評価ができる組織か」
・「エスカレーションのルールが明確か、エスカレーションの効果は十分か」なエスカレーションの効果は十分か」
などでなります。例えば、性能はシステムにとって重要になり、そのため、「リスク要因領域（A）」での必要性能を「確定」「試算」「検証（A）」での必要性能を確定、試算、検証する手立て、つまり性能確保についてする手立て、つまり性能確保については誰でも認識になります。
仮に、毎秒100件のトランザクションを処理する要件の場合、設備、ツーンを処理する要件の場合「設備」「ツール」「評価体制」などを整え、毎秒100件、評価体制などを整え、毎秒100件の性能要件を満たそうとしております。
問題は、実システム、あるいは実運用前のテストシステム、あるいは実運用前のテストで、毎秒100件以上の負荷がかかった場合、この性能値の扱いについて発た場合、この性能値の扱いについて発注側、受注側で大きく意見の分かれる注側、受注側で大きく意見の分かれるところになります。
発注側は、毎秒100件以上の負荷が発注側は、毎秒100件以上の負荷がかかった場合、若干の処理遅れがあっても、システム障害に至るとは考えなても、システム障害に至るとは考えません。
一方、受注側は、毎秒100件の負荷まで検証するとしても、それ以上の荷まで検証するとしても、それ以上の負荷がかかった場合にシステム全体に負荷がかかった場合にシステム全体にどういう影響が出るかは「設備」「工数」どういう影響が出るかは「設備」「工数」「ツール」「期間」などの「制約」「困難」が発生ツール、期間などの制約、困難が発生するため、特別な場合を除いて検証しするため、特別な場合を除いて検証しません。
その結果、一般的に性能改善には大きなリスクが伴う（危険性大）とはリスクが発覚しているにもかかわらず、リスク発生確率が低いため、見落としやすくなります。
生確率が低いため、見落としやすくなります。これを防ぐためには、第三者検証によこれを防ぐためには、第三者検証による先を見越したリスク・マネジメントる先を見越したリスク・マネジメントが重要になります。
「リスク要因領域（C）」この領域は、プロセスが目的に沿っこの領域は、プロセスが目的に沿って正常に進展しているか否かが視点とて正常に進展しているか否かが視点となります。
ただし、この領域は発生確率が高いためリスク認識として欠落することは少ないです。
何がリスクか、この領域でのリスク・マネジメントを怠ったらどうのリスク・マネジメントを怠ったらどうなるかは、参考文献が多く、マネジメなるかは、参考文献が多く、マネジメント手法も確立されています。
〇リスク要因領域（D）
この領域は「マニュアルの体裁」「分かりやすさ」「画面のレイアウト・配色の分かりやすさ」「画面のレイアウト・配色」「報告書の様式」「プロジェクト・ルーム報告書の様式」「プロジェクト・ルームの環境」「プロジェクト・メンバーの環境」「プロジェクト・メンバーの資質」などが重要ではあるが経験、説明、質など、重要ではあるが経験、説明、教育により課題を解決できる内容であ教育により課題を解決できる内容であります。
一般的にリスクが小さいため、リスク・マネジメントとしては、重要視されていません。しかし、この領域は、当事者の趣味、嗜好、または企業文化とい者の趣味、嗜好、または企業文化というような価値観により、リスク認識がうような価値観により、リスク認識が全く異なるため、扱いが非常に難しい。全く異なるため、扱いが非常に難しくなります。
リスクを認識する上で、要件の分かりやすさ、見やすさ、判断の容易さかりやすさ、見やすさ、判断の容易さなど、概念的なものがあるときに、本当に「要因領域（D）」のリスクであるか検証することに注意しなければならない。
半面、この領域のリスク・マネジメントは、計画に反映させ、地道に改善ントは、計画に反映させ、地道に改善しておかないと、費しておかないと、中流・下流工程で費用、工数、体制、納期、納品に大きく影響することを意識する必要があります。
10.4 プロジェクトの問題
・「プロジェクトの失敗」・・・プロジェクトの成功・失敗
・「システム品質」の低下
・「コスト超過」・・・納期の遅延
①.プロジェクト・マネジメントの問題
〇問題のパターン
プロジェクト・マネージャのスキル不足や経験不足に起因する問題になります。例えば、開発者の進捗管理ができていなかったり、規模の見積もりが甘かったりすることによるマネジメント不足など。
■プロジェクトマネジメント
・開発体制の不足
・開発メンバーのスキル不足
・発注側と受注側のコミュニケーションの問題
②.要件定義など開発範囲にかかわる問題
〇問題のパターン
要件定義がなかなか確定しないことによって、開発工程が遅れるケースや、要件定義が曖昧だったり矛盾があったりすることで、システム仕様に問題が埋め込まれて後工程で破綻をきたすこと。
■ 要件定義・開発範囲
・発注側と受注側双方の業務知識の不足
・要件定義の遅れやブレ
・開発範囲が不明確
・役割分担が不明確
③.システム設計・構築技術にかかわる問題
〇問題のパターン
アーキテクチャ設計やパッケージの利用、移行方式の検討不足などに起因する問題になります。現行機能や現行業務の調査不足が引き金になることも多い。開発側のスキル不足も品質低下などに繋がります。
④.ステークホルダーにかかわる問題
〇問題のパターン
顧客側のプロジェクトに対するオーナーシップの不足、重点ステークホルダー（例を挙げると役員や現場の利用者）への対応不足による問題
■ステークフォルダー
・発注側のオーナーシップの問題
・受注側のプロジェクトマネージャーのマネジメント力不足
⑤.モチベーションにかかわる問題
〇問題のパターン
プロジェクト・メンバーのモチベーションの低下に起因して作業
品質や生産性が低下したり、セキュリティ問題などの他の問題
に発展したりすることがあります。
■モチベーション
・開発の標準化を軽視
・開発者の参画意識の低下
・生産性の低下
・現行機能・現行業務の調査不足
11.マネジメント計画の作成
11.1 プロジェクト計画書作成
上流工程における重要な成果物としてプロジェクト計画書があります。プロジェクト計画書を作成する時点では、次のことを見える化する必要があります。
⑴.プロジェクトのドミナント・アイテムを把握する
プロジェクト計画書を作成する前に、俯瞰図を用いて、プロジェクトのドミ
ナント・アイテムを把握しております。
⑵.プロジェクトの目的、成果物、成功基準を明確にする
「プロジェクトの目的」「成果物」「成功基準」という重要な要素は「プロジェクトの目的」「成果物の品質・納期・コスト」への影響が大きいです。成果物が不明確なプロジェクトは稀であるが、成果物の作成にとらわれて目的が見失われているプロジェクトを明確にしましょう。
11.2 プロジェクト計画を考える手順
①.プロジェクト計画の必要性
プロジェクト計画の必要性を理解していないPMも多いものです。
・プロジェクト進捗を正確に把握するため
・メンバーやステークホルダーがプロジェクト内容を共通認識するため
・急な変更が発生したときに速やかに変更対応するため
PMであれば、これらを明確に意識し、メンバー・ステークホルダーをゴールまで牽引する責務があります。
②.プロジェクト計画を考える手順
プロジェクト計画を考えるには、
・WHY（なぜプロジェクトを行うのか）
・WHAT（どのような作業を行なって、どんな成果物を作るのか）
・HOW（成功に導くための手段や方法）
これらの順番で考えていきましょう。
11.3 プロジェクト計画書を作る10の手順
①.WHYを考える
Process 1：【目的の明確化】
多くのプロジェクト計画が目的が曖昧であるため、プロジェクト終了後の成否が判断付きません。また、プロジェクト実行中も目的が曖昧ではマネジメントがブレます。そのためには目的を明確にしていきます。
②.WHATを考える
Process 2：スコープの明確化
プロジェクトの目的が明確になっても、「何をしなければならないのか?」
これが、分からなければ目的の達成が出来ません。『プロジェクトの範囲を決める』、これをスコープと言います。スコープは計画段階でも抜け漏れのないようにしましょう。
Process 3：前提条件、制約条件の明確化
プロジェクトは全ての条件が完璧に揃うことは難しくなります。出来ないことを、出来るかのように振る舞う計画は理不尽になります。そのため、プロジェクトの目的を達成させるための条件を明確にすることが必要になります。
Process 4：スケジュールの作成
スケジュールを作成するには、
・マイルストーンを明確にする
・所用期間を見積もる
・スケジュールを整える
他のことに気を取られずに、これらを行うことだけに集中してください。
Process 5：工数の算出
残念ながら、スキルの設定、工数算出の方法を間違えているPMも多いのが事実です。工数を算出するには、
・スキル一覧を作成する
・工数を見積もる
これらを行っています。工数算出には様々な技法がありますが、まずはスキルを洗い出してください。
Process6：プロジェクト体制の構築
プロジェクトを計画通りに実行していくには、洗練された体制が必要です。
・役割分担
・要員計画
・体制図
特に役割分担においては、スキル一覧で定義されなかった問題解決作業 等 雑を含んだスキルも忘れずに役割を決めてください。
Process7：コストの算出
プロジェクトの予算は、プロジェクトの成功を左右するものです。予算超過、予算不足で痛い目に遭うPMも少なくありません。プロジェクトを成功させるために必要であり、現実的な予算を算出してください。
Process 8：品質基準の作成
多くのプロジェクトでは品質基準が曖昧なため、「何を持って合格なのか?」の判断に戸惑っています。これは、必要とする基準を理解していないのが原因になります。
・品質基準の対象範囲はどこまでか?
・何を基準にすれば良いのか?
これらを見極めて品質基準を作りましょう。
Process 9：目標の設定
多くのプロジェクト計画が目的と目標を混合しています。目的を達成するには数値化された目標を設定しなければなりません。目標の対象を見極めて目標を数値で設定してください。
③.HOWを考える
Process 10：マネジメント計画
プロジェクトを円滑に運営し、成功に導くための手段や方法を考えなくてはなりません。そのために、マネジメント計画では、
・プロジェクト活動を実行する方法と定義
・計画と実績の乖離に対する分析方法
・変更手続きの方法
これらを考えなければならず、これが『HOW』に当たります。HOWを考える範囲は以下通りとなります。
a)品質マネジメント計画
b)コストマネジメント計画
c)スケジュールマネジメント計画
d)スコープマネジメント計画
e)コミュニケーションマネジメント計画
f)組織マネジメント計画
g)リスクマネジメント計画
また、a)〜g)の順番で考えることで、論理矛盾を防ぐことにもなります。
11.4 PMとして絶対必要な16のスキル
プロジェクト計画書を作る手順はご理解いただけたでしょうか。実は、各手順はオートマチックでできるわけではありません。やはり、それなりの知識が必要です。ここでは、各手順に必要とされる『PMとして絶対必要な16のスキル』を紹介します。
必要スキルを使って「何をするのか」を理解してください。そして、知識習得のために全力で勉強していきましょう。
Skill1：システム化範囲の調査方法（『手順2：スコープの明確化』で使うスキル）
プロジェクトスコープを明確にするには、システム化範囲を把握しなければなりません。一般的には、顧客が準備した情報からシステム化範囲が明確になりますが、情報が曖昧・情報不足のケースも多いものです。そのため、 お客様へ欲しい情報を聞き出すことを忘れないでください。
Skill 2：要件の将来性を確認する方法（『手順2：スコープの明確化』で使うスキル）
プロジェクトスコープを明確にするには、顧客の要件の将来性を確認しなければなりません。プロジェクトの実行中に、計画段階で考えられていた要件が陳腐化して、ビジネスの優位性を脅かすこともあります。このことを意識して、要件の将来性を確認してください。
Skill 3：優先度を設定する方法 （『手順2：スコープの明確化』で使うスキル、『手順10 ①：品質マネジメント計画』で使うスキル））
プロジェクトスコープを明確にするには、スコープを明確にしなければなりません。顧客の要件の優先度の付け方を間違えると顧客は、ビジネスの恩恵を得られなくなります。そのため、事前に優先度を付けるようにしましょう。
Skill 4：WBS、マイルストーンする方法（『手順2：スコープの明確化』で使うスキル、『手順4：スケジュールの作成』で使うスキル）
プロジェクトスコープが明確になったら「WBS」を作成します。「WBS」はプロジェクトの成果物を作るために、どのような作業を行うのか、このようなことを明確に考えてください。
Skill 5：プロジェクトで重視する要素を決める（『手順3：前提条件、制約条件の明確化』で使うスキル、PMは、お客さまにプロジェクトの成功を約束しなくてはなりません。）
しかし、プロジェクトは顧客の都合・法律変更などによって、全ての目標に到達できないこともあります。その時、何かを犠牲にしてでも、プロジェクトの目的をクライアントの許容範囲で達成しなければなりません。プロジェクトで重視する要素を顧客をリードして決めてください。
Skill 6：概算期間、概算工数を求める算出式（『手順4：スケジュールの作成』で使うスキル、『手順5：工数の算出』で使うスキル）
スコープが明確になった時点で、開発期間・開発工数を決めなければなりません。しかし、計画段階ではお客さまの要件が具体的になっていないため、「概算」を求めてください。但し、確定期間と工数の決定フェーズをお客さまと協議してください。
Skill 7：必要なスキルを考える方法（『Process 5：工数の算出』で使うスキル）
プロジェクト計画では、工数の算出を行う際にプロジェクトで必要とされるスキルを洗い出します。必要なスキルの洗い出しは慎重に行わないと品質・コスト・スケジュールに悪影響が出ますので要注意です。
Skill 8：リスクを考慮したバッファ工数の算出方法（『手順5：工数の算出』で使うスキル）
工数を算出する際に、多くのPMが抜け漏れするのがリスクを考慮したバッファー工数になります。バッファー工数とはリスク予防のための作業・算出した見積もり工数への安全確保を考慮した工数になります。
Skill 9：割り当てる人数を決める方法（『手順5：工数の算出』で使うスキル）になります
工数の算出を行った後に、必要な人数を割り当てなければなりません。割り当てる人数とは、プロジェクトで作業を行う延べ人数です。割り当てる人数を慎重に考えないと品質、コスト、スケジュールに悪影響が出ます。
Skill 10：メンバーのアサインタイミング（『手順6：プロジェクト体制の構築』で使うスキル）
多くのPMはプロジェクトスキルを持ったメンバーであれば、計画通りにアサインすることで即座に戦力になると考えがちです。しかし、現実的は稀なことです。
アサインされたメンバーがプロジェクト成果物の内容や関連するシステムを理解するには、「キャッチアップ期間」が必要です。キャッチアップ期間を知らずに、メンバーをアサインすると品質・コスト・スケジュールに悪影響が出ます。
そのため、正確にキャッチアップ期間を設定して要員計画を作ってください。
Skill 11：クライアント視点での品質基準の考え方（『手順8：品質基準の作成』で使うスキル）
プロジェクト計画で、開発するシステムの品質を担保するために、品質基準を決めます。しかし、忘れがちなのがお客様視点による品質基準になります。プロジェクトは、システムを開発することから、ITベンダの品質基準に偏りすぎる傾向にあります。
そのため、お客様視点による品質基準が疎かになるものになります。顧客の視点が含まれた品質基準であることを確認してください。
Skill 12：テスト工程における品質基準の考え方（『手順8：品質基準の作成』で使うスキル）
プロジェクト計画では、開発するシステムの品質を担保するためにテスト工程の品質基準を決めてください。
Skill 13：設計工程における品質基準の考え方（『手順8：品質基準の作成』で使うスキル）
プロジェクト計画では、開発するシステムの品質を担保するために、設計工程の品質基準を決めてください。
Skill 14：EVMを使った管理方法（『Process 10 ②：コストマネジメント計画』で使うスキル、『Process 10 ③：スケジュールマネジメント計画』で使うスキル）
PMは、計画と実績からプロジェクト完了までの以下を予測しなければなりません。
・コストの消費進捗から見た必要コスト
・スケジュール進捗から見た必要日数
アーンドバリューマネージメントを使って、計画と実績からコスト超過や作業遅延、今後の予測値を視覚的に管理する方法を取り入れてください。
Skill 15：進捗報告書の作り方（『手順8：品質基準の作成』で使うスキル）
プロジェクトの状況を正確に捉えるには、進捗報告書が必要になります。これは、プロジェクトの作業状況を数値化することで、関係者との共有・スケジュールやコストの分析・プロジェクトリスクの洗い出しに取り入れてください。
Skill 16：リスク管理表の作り方（『Process 10 ⑦：リスクマネジメント計画』）
リスク管理表は、プロジェクトのリスク事象を取りまとめて、
・関係者との共有
・リスクの経過観察
・リスクの再査定や監査
これらを整理していきます。
12.まとめ
いかがでしたでしょうか。プロジェクトマネジメントの計画・実行を遂行する際に少しでもお役に立てれば幸いです。
この記事が気に入ったらサポートをしてみませんか？