プロジェクトマネジメントの要点とまちがえやすい点（ITパスポート試験 論点テキスト）

このページの論点

マネジメント系｜プロジェクトマネジメント｜13論点・要点71本・まちがえやすい点44本・式3本

• プロジェクトマネジメント
  • プロジェクト憲章・計画書とPMBOKの枠組み
  • ステークホルダ・体制・コミュニケーション
  • スコープとWBS・ワークパッケージ
  • アローダイアグラムとクリティカルパスの用語
  • アローダイアグラムの日数計算と余裕日数
  • ガントチャートの読み取り
  • 見積りとスケジュール短縮の技法
  • ライフサイクル・進捗管理・遅延時の対応
  • ベースライン・予備費・変更の統制
  • リスクの分析と四つの対応戦略
  • 品質マネジメントと品質保証
  • 調達文書・契約形態と外部委託
  • 課題管理・教訓・コンフリクトの管理

プロジェクトマネジメント

プロジェクト憲章・計画書とPMBOKの枠組み

プロジェクトの立ち上げで作る文書と、PMBOKが示す知識エリア・プロセス群、三重制約の基本を扱う。

要点

• プロジェクト憲章は、プロジェクトの目的やプロジェクトマネージャの権限を定め、プロジェクトの存在を組織として正式に認可する文書である。
• プロジェクトマネジメント計画書は憲章の承認後に作成され、各知識エリアの計画を統合して、実行・監視・終結の方法を定める文書である。
• PMBOKガイド第6版の知識エリアは、統合・スコープ・スケジュール・コスト・品質・資源・コミュニケーション・リスク・調達・ステークホルダーの10領域である。
• PMBOKガイド第6版のプロセス群は、立ち上げ、計画、実行、監視・コントロール、終結の五つである。
• スコープ・スケジュール・コストの3要素はトレードオフの関係にあり、一つを変更すると他の要素や品質にも影響が及ぶ。
• プロジェクトは、始まりと終わりがある有期性と独自性を持つ活動であり、終わりのない定常業務とは区別される。

まちがえやすい点

• プロジェクト憲章は認可を目的とする文書であり、憲章の承認後に具体的な実行・監視の方法を定めるプロジェクトマネジメント計画書とは、作成される段階が異なる。
• PMBOKのプロセス群は、ソフトウェア開発工程や調達手続の流れを表したものとは異なる分類である。
• ステークホルダは関係者全体を指す語であり、資金や権限を提供する立場に限られるスポンサとは範囲が異なる。

ステークホルダ・体制・コミュニケーション

関係者の種類と役割、RACIチャート、組織形態、情報伝達の計画、コミュニケーション経路数の計算を扱う。

要点

• ステークホルダマネジメントは、利害関係を持つ人や組織を特定し、関心事や影響力を分析して、適切な関与とコミュニケーションを図る活動である。
• プロジェクトスポンサーは資金や資源を提供してプロジェクトを承認・支援し、プロジェクトマネージャの権限を超える重要事項の意思決定に関与する。
• RACIチャートのAは作業結果に対する最終的な説明責任を負い承認を行う役割で、1つの作業につき原則1名に限定することが望ましい。
• RACIチャートで、作業を実際に実行するのはR、助言を行うのはC、報告を受けるだけの立場はIである。
• マトリックス組織は、要員が機能別部門に所属したままプロジェクトマネージャの指揮のもとでも従事する形態で、二重の指揮命令系統を持つ。
• コミュニケーションマネジメント計画は、情報の発信者・内容・頻度・伝達手段などをあらかじめ定め、必要な情報を必要なステークホルダに届ける。
• プロジェクトチームの編成は、計画で定めた必要な人数やスキルを満たす要員を社内外から確保し、チームへ割り当てる活動である。
• プロジェクトコミュニケーションマネジメントは、関係者が必要とする情報を、適切な時期と方法で作成・配布・共有し、情報伝達が滞らないようにする活動。

まちがえやすい点

• ステークホルダはプロジェクトの結果に利害関係を持つ人・組織全般を指す広い概念であり、スポンサーはその一部にすぎない。
• 全員が直接連絡する経路数の組合せはn(n−1)/2であり、n×(n−1)で求める順列ではない。
• 機能別組織は部門長の指揮のもとで業務を遂行する形態であり、二重の指揮命令系統を持つマトリックス組織とは別である。
• RACIチャートのAは最終的な説明責任を負う役割であり、作業を実際に実行するR、助言を行うCとは異なる。

式

• コミュニケーション経路数n(n−1)÷2n人の全員が互いに直接連絡する場合の組合せの総数。6人なら6×5÷2＝15本

スコープとWBS・ワークパッケージ

作業範囲の定義と、WBSによる階層分解、最下位要素であるワークパッケージ、スコープの種類を扱う。

要点

• WBSは、プロジェクト全体の作業を階層的に分解し、管理可能な単位まで細分化したものである。
• WBSは成果物や作業を階層的に分解して、やるべきことの抜けや重複をなくすために作る。
• ワークパッケージはWBSの最下位の要素で、担当者と工数を割り当てられる大きさまで分解した、見積り・割当て・進捗管理の最小単位である。
• スコープマネジメントは作業範囲と成果物範囲を明確にし、承認されていない変更の無秩序な追加であるスコープクリープを防ぐ活動である。
• プロダクトスコープは完成する製品やサービスが備える特性・機能を指し、プロジェクトスコープは成果物を生むための作業範囲を指す。
• WBSは作業の階層構成を示す図であり、作業の順序・所要日数・担当者は表れない。
• プロジェクトスコープマネジメントは、プロジェクトで作る成果物と必要な作業の範囲を定め、範囲外の作業が紛れ込まないよう管理する活動。

まちがえやすい点

• WBSは作業の階層分解であり、スケジュールを横棒で表すガントチャートや、作業の順序と依存関係をネットワークで表すPERT図とは別である。
• ワークパッケージは作業分解の最小要素であり、節目の時点であるマイルストーンや、計画の基準線であるベースラインとは異なる。
• スコープクリープは無秩序な範囲拡大であり、承認された範囲の基準であるスコープベースラインではない。
• WBSの目的は作業の洗い出しと分解であり、日程の管理を担うガントチャートや、クリティカルパスを算出するアローダイアグラムとは別である。

アローダイアグラムとクリティカルパスの用語

アローダイアグラムの表す内容、クリティカルパス、余裕日数、マイルストーンなど日程管理の用語を扱う。

要点

• PERT図（アローダイアグラム）は、作業の順序・依存関係を矢印と結合点のネットワークで表し、プロジェクト全体の所要期間の把握に用いる。
• クリティカルパスは開始から終了までの経路のうち所要日数が最長となる経路で、この経路上の作業の遅延は全体の遅延に直結する。
• 余裕日数（フロート）はクリティカルパス以外の作業が持つゆとりで、クリティカルパス上の作業の余裕日数は0になる。
• マイルストーンは、工程の区切りや重要な意思決定のタイミングを示す節目の時点で、進捗管理の基準として用いられる。
• アローダイアグラムは作業の前後関係と所要日数を矢印で表す図で、クリティカルパスを求められる。
• フリーフロートは他の作業に影響を与えずに遅らせられる余裕時間であり、最早開始日は作業を開始できる最も早い日である。

まちがえやすい点

• クリティカルパスは所要日数の合計が最も長く余裕がゼロの経路であり、最も日数の余裕が大きい経路ではない。
• 特性要因図は結果に影響する要因を整理する品質管理の図であり、日程管理に用いるガントチャートやアローダイアグラムとは異なる。
• ガントチャートは期間と進捗を横棒で示すが作業どうしの前後関係は表しにくく、前後関係を矢印で表すアローダイアグラムではない。
• マイルストーンは節目の時点であり、所要日数が最長の経路であるクリティカルパスや、余裕として確保する時間のバッファとは別である。

アローダイアグラムの日数計算と余裕日数

合流する作業の到達日、全体の最短日数、クリティカルパス上の作業、作業の余裕日数の求め方を扱う。

要点

• アローダイアグラムで複数の作業が合流する結合点では、遅いほうの経路が到達時刻を決める。
• 後続の作業は先行する作業がすべて終わってから始められるため、全体の所要日数は合流点の到達日に後続作業の日数を足して求める。
• クリティカルパスは各経路の所要日数を比べて最長の経路を選ぶことで特定でき、この経路の作業が1日遅れれば全体も1日遅れる。
• 合流点に到達する経路のうち短いほうの経路には、長いほうとの日数の差だけ余裕があり、その範囲内なら作業が遅れても全体に影響しない。
• クリティカルパス上の作業の所要日数が延びると、その分だけ全体の所要日数が延びる。
• クリティカルパスに含まれる作業は余裕がなく、含まれない作業には余裕日数がある。

まちがえやすい点

• 全ての作業日数を単純に足した値は並行して進む作業を重ねて数えた誤りであり、最短の所要日数ではない。
• 一方の経路だけで計算した日数はクリティカルパスの日数とは異なり、合流点では両方の経路を比べて長いほうを採る。
• 余裕日数の範囲内の遅れは全体に影響しないが、余裕を超えて遅れると経路が長くなり、全体の所要日数も延びる点で異なる。

式

• 作業の余裕日数長いほうの経路の日数−短いほうの経路の日数合流する結合点で経路どうしを比べる
• 全体の最短所要日数合流点の到達日＋後続作業の日数合流点の到達日は遅いほうの経路で決まる

ガントチャートの読み取り

ガントチャートの横棒から、開始日・終了日、並行作業、完了済みの作業を読み取る方法と、表せない情報を扱う。

要点

• ガントチャートは、各作業の開始日・終了日を横棒で表し、スケジュールと進捗を視覚的に把握できるようにした図である。
• ガントチャートでは、横棒が重なる期間の作業が並行して進んでおり、横棒の重なりで並行作業を読み取る。
• ガントチャートでは、最も右に伸びた横棒の終わりが全体の完了日になる。
• 特定の日の時点で完了している作業は、その日の縦線と横棒の右端を比べ、右端が線より左にある作業である。

まちがえやすい点

• ガントチャートは作業間の前後関係やその理由、担当人数、費用を表現せず、依存関係を明示するアローダイアグラムとは表せる内容が異なる。
• 全ての作業の日数を単純に足した値は並行して進む期間を重ねて数えており、読み取る全体の完了日とは別である。
• 終了の翌日に始まる作業どうしは期間が重ならず、並行して進む作業ではない。

見積りとスケジュール短縮の技法

三点見積り法、クリティカルチェーン法、ファストトラッキング、クラッシング、資源平準化の特徴を扱う。

要点

• 三点見積り法（PERT見積り）は、楽観値・最頻値・悲観値の3つの数値から加重平均で見積値を算出し、単一の値による見積りより不確実性を考慮できる。
• クリティカルチェーン法は、各作業に個別の安全余裕を持たせず、資源制約を考慮した最長経路の末尾などにバッファをまとめて配置する手法である。
• クリティカルチェーン法では、プロジェクト全体の進捗を、バッファの消費状況で管理する。
• ファストトラッキングは、本来は順次実施する作業の一部を並行して進めることで、追加コストをかけずにスケジュールを短縮する技法である。
• クラッシングは、クリティカルパス上の作業に追加の要員や資源を投入し、コスト増加と引き換えに作業期間そのものを短縮する技法である。
• 資源平準化は、特定の期間に資源需要が集中して過負荷にならないよう、作業の実施時期を調整して使用量を均す技法である。

まちがえやすい点

• ファストトラッキングは作業の並行化で追加コストをかけない代わりに手戻りリスクが高まり、資源を追加投入するクラッシングとは異なる。
• 類推見積法は過去の類似実績、パラメトリック見積法は統計的な関係式を用いる点で、三点見積り法とは異なる。
• 資源平準化は資源需要の均しが目的であり、作業の並行化によるファストトラッキングや、資源投入による期間短縮のクラッシングではない。

ライフサイクル・進捗管理・遅延時の対応

適応型ライフサイクル、バーンダウンチャートの読み方、ステージゲート法、遅れが出たときの報告と調整を扱う。

要点

• バーンダウンチャートは、残作業量を縦軸、時間を横軸にとり、残りが減っていく様子を折れ線で示して進捗を可視化する図である。
• バーンダウンチャートの縦軸は残作業量であり、期間の終わりに向けて0へ近づくのが計画どおりの姿である。
• バーンダウンチャートで実績線が計画線より上にあるのは、残作業が計画より多いことを示し、予定より作業が遅れていることを意味する。
• 要求が不確実で変化が多い場合は、短い反復ごとに成果を確認して要求の変化を取り込める適応型（アジャイル型）のライフサイクルが適する。
• ステージゲート法は、プロジェクトを複数の段階に区切り、各段階の終了時に定めた基準に基づいて次段階への移行可否を判断する管理手法である。
• 遅れが出たときは、原因と影響範囲を確認してステークホルダに現状と選択肢を報告し、スコープ・納期・コストの優先を関係者と合意して調整する。

まちがえやすい点

• 遅れを報告せず残業で吸収しようとすると選べる手が減り、最後に大きな遅れとして表面化する点で、早期に共有して調整する対応とは異なる。
• 完了した作業量を積み上げる図はバーンアップチャートと呼ばれ、残作業量の推移を表すバーンダウンチャートではない。
• ガントチャートは作業別の期間、アローダイアグラムは作業の順序関係、パレート図は項目別の重点把握を示す点で、残作業の推移図であるバーンダウンチャートとは異なる。
• 予測型や事前に全計画を確定する方式は要求が安定した案件に向き、変化の多いプロジェクトに向く適応型とは別である。

ベースライン・予備費・変更の統制

計画の基準線、既知・未知のリスク用の予備費、変更要求を一元的に統制する統合変更管理を扱う。

要点

• コンティンジェンシー予備は、特定済みの既知のリスクが顕在化した場合に備えてあらかじめ見込む予備費で、コストベースラインに含まれる。
• マネジメント予備は、事前に特定できなかった未知のリスクに備えて確保し、その使用に経営層など上位者の承認を要する予備費である。
• ベースラインは、承認された計画を基準線として固定し、以降の実績と比較して差異を測定するための基準である。
• 統合変更管理は、変更要求の影響を評価して承認し、承認された変更を各計画やベースラインに反映して一元的に統制する活動である。

まちがえやすい点

• マネジメント予備は未知のリスク用で経営層の承認のもとに別途確保されコストベースラインに含まれず、既知のリスク用のコンティンジェンシー予備とは別である。
• ベースラインは比較の基準であり、重要な節目の時点であるマイルストーンや、所要期間が最長の経路であるクリティカルパスとは異なる。
• 統合変更管理は変更全体を統合的に統制する活動であり、作業範囲を扱うスコープ管理や、基準への適合を扱う品質管理とは主目的が異なる。

リスクの分析と四つの対応戦略

定性的・定量的リスク分析、リスク登録簿、回避・転嫁・軽減・受容の四つの対応戦略の違いを扱う。

要点

• リスク転嫁は、保険や外部委託などによって、リスクが顕在化した場合の損失負担を自組織以外の第三者に移す対応戦略である。
• リスク回避は、リスクの原因となる作業や計画そのものを中止・変更して、リスクが発生する可能性自体をなくす対応戦略である。
• リスク受容は、発生確率や影響の小ささを踏まえて特段の予防対策を講じず、顕在化した際に対応する戦略である。
• リスク軽減は、リスクの発生確率や影響の大きさそのものを下げるために、予防策や代替手段を講じる戦略である。
• 定性的リスク分析は、発生確率や影響度を高・中・低などの段階的な尺度で評価し、対応の優先順位を付ける分析である。
• 定量的リスク分析は、リスクが顕在化した場合のコストや期間への影響を、金額や日数などの具体的な数値で評価する分析である。
• リスク登録簿は、特定したリスクと、その評価・対応策・担当者を一覧にして管理する文書である。
• プロジェクトリスクマネジメントは、目標の達成に影響しうる不確実な事象を特定・分析し、対応策を計画して状況を監視する活動。

まちがえやすい点

• 保険への加入は損失を第三者に移す転嫁であり、リスクの原因を取り除く回避とは異なる。
• 対策を講じずに発生したときに対応するのは受容であり、積極的に低減策を講じるリスク軽減ではない。
• 定性的リスク分析は段階的な尺度による優先順位付けにとどまり、数値で影響を算出する定量的リスク分析とは別である。
• リスク登録簿はリスクの一覧を管理する文書であり、既に発生した懸案を管理する課題管理表や、過去の学びを蓄積する教訓リポジトリとは異なる。

品質マネジメントと品質保証

品質マネジメントの範囲と、品質保証部門・品質保証活動の役割、品質コントロールとの違いを扱う。

要点

• 品質マネジメントは、成果物や作業プロセスが定められた品質基準を満たすように、計画・保証・管理する活動全般である。
• 品質保証部門は、開発チームから独立した立場でレビューや監査を通じて品質基準の充足を確認し、必要な是正を促す役割を担う。
• 品質保証は、プロセスや基準の運用を点検し、品質を生む仕組みそのものを改善する活動である。

まちがえやすい点

• 成果物を個別に検査するのは品質コントロールであり、プロセスの運用を点検する品質保証ではない。
• 品質保証部門は独立した立場で確認と是正を促す部門であり、コーディングを担う開発部門や価格交渉を担う営業部門の業務とは別である。
• 品質マネジメントは品質基準の充足を扱い、不確実性への対応を扱うリスクマネジメントや、予算の統制を扱うコストマネジメントとは主目的が異なる。

調達文書・契約形態と外部委託

RFI・RFPの使い分け、定額契約などの契約形態、常駐して作業するオンサイト開発の特徴を扱う。

要点

• RFPは、発注者が要件・予算・納期などを提示し、ベンダに具体的な提案書の提出を求める文書である。
• RFIは、調達の初期段階で、市場の製品・技術・ベンダの情報を集めるためにベンダへ情報提供を求める文書である。
• 定額契約は、作業に対して固定の総額を支払う契約で、コスト超過のリスクを主に受注者が負う。
• オンサイト開発は、受託者の要員が発注者の事業所に常駐して作業を行う形態で、発注者との意思疎通が取りやすい。

まちがえやすい点

• RFIは初期の情報収集のための依頼であり、具体的な提案書の提出を求めるRFPとは別である。
• 実費償還契約は実費に報酬を加え発注者がリスクを負い、コスト超過リスクを主に受注者が負う定額契約とは異なる。
• オンサイト開発は指揮命令の主体を巡り労働者派遣に該当しないよう契約・実態管理に注意が必要で、場所の観点が異なるオフショア開発とは別の形態である。

課題管理・教訓・コンフリクトの管理

発生済みの懸案を追跡する課題管理、終結時の教訓の記録、チーム内の意見対立への対応を扱う。

要点

• 課題管理は、既に発生した懸案事項を担当・期限・状況とともに記録し、解決まで追跡する活動である。
• 教訓の記録は、成功要因や課題、改善点を整理して以降の類似プロジェクトに活かせるよう蓄積する活動で、終結プロセスの成果物の一つである。
• コンフリクトマネジメントは、チーム内の意見対立を放置せず、原因を把握して適切な解決へ導く活動である。

まちがえやすい点

• 課題管理は発生済みの懸案を追跡する活動であり、まだ発生していない不確実性に対応するリスク管理とは異なる。
• コンフリクトマネジメントは対立の解決を主眼とし、情報の伝達や共有の計画・実施を扱うコミュニケーションマネジメントではない。
• 教訓の記録は知見の蓄積を目的とし、利害関係者の把握であるステークホルダー分析や、発生した問題への対応である是正処置とは別である。

ほかのページ

出典と作り方

この読み物は、IPA「ITパスポート試験 シラバス Ver.6.5」の中分類の順に、アプリ「ITウカール」の収録問題の解説をもとにアプリ製薬が作成したものです。公式の文章の転載ではありません。問題文・選択肢は載せていません。

• ITパスポート試験 シラバス Ver.6.5（IPA）