ITパスポート講座のマネジメント系10（プロジェクトマネジメント）の確認○×問題だけを集めました。
目次 非表示
プロジェクトマネジメント1
プロジェクトは、定常的な業務として繰り返し実行され、終了時点は決めないで開始し、進捗状況を見ながらそれを決める活動である。
（出典：平成30年度春期分 問44一部改変）
答え：×
独自の製品・サービスを創造するために実施され（独自性）、期限が決まっている（有期性）という点がプロジェクトの特徴です。
以下の記述のうち、プロジェクトに該当するものは２つある。
- 会社合併に伴う新組織への移行
- 社内システムの問い合わせや不具合を受け付けるサービスデスクの運用
- 新規の経理システム導入に向けたプログラム開発
- 毎年度末に実施する会計処理
（出典：令和6年度春期分 問36一部改変）
答え：〇
プロジェクトの特徴は以下の２点です。
・独自性：独自の製品・サービスを創造するために実施される、１度限りの断片的で非経常的な業務である。
・有期性：期限が決まっている（始まりと終わりがある）。
1.の記述：合併は１度限りの断片的・非経常的な業務で、期限も決まっているため、プロジェクトに該当します。
2.の記述：繰り返し実行される定常的な業務はプロジェクトに該当しません。
3.の記述：新規の経理システム導入に向けたプログラム開発は、独自性と有期性があるため、プロジェクトに該当します。
4.の記述：毎年定期的に実行される定常的な業務はプロジェクトに該当しません。
プロジェクトマネジメントは、企画、要件定義、システム開発、保守の順番で行う。
（出典：令和元年度秋期分 問41一部改変）
答え：×
設問はシステム開発の進め方です。プロジェクトマネジメントは、目標を達成するための計画を作成し、実行中は品質、進捗、コストなどをコントロールしながら目標の達成に導きます。
プロジェクト立ち上げ時に、プロジェクトの活動を総合的に管理及び調整するために、プロジェクト憲章を定める。プロジェクト憲章には「具体的なスケジュール」「体制」「品質マネジメント計画」などが盛り込まれる。
（出典：平成21年度秋期分 問41一部改変）
答え：×
プロジェクト憲章には、プロジェクトの目的・目標・成功条件、プロジェクトマネージャの氏名などが記載され、経営者などからの認可を得て、関係者間で認識を共有します。
なお、プロジェクト憲章には「概算のスケジュールや予算」が記載されますが、具体的なスケジュールや予算はこの段階ではまだ記載されません。
プロジェクトマネジメントの知識エリアには、プロジェクトコストマネジメント、プロジェクト人的資源マネジメント、プロジェクトタイムマネジメント、プロジェクト品質マネジメントなどがある。システム開発のプロジェクト品質マネジメントにおいて、成果物の品質を定量的に分析するための活動として、適切なものはaである。
| a | 完成した成果物の数量を基に進捗率を算出して予定の進捗率と比較する。 |
| b | 設計書を作成するメンバに必要なスキルを明確にする。 |
| c | テストで摘出する不良件数の実績値と目標値を比較する。 |
| d | プログラムの規模や生産性などを考慮して開発費用を見積もる。 |
（出典：平成30年度秋期分 問38一部改変）
答え：×
| a.タイムマネジメント | 完成した成果物の数量を基に進捗率を算出して予定の進捗率と比較する。 |
| b.人的資源マネジメント | 設計書を作成するメンバに必要なスキルを明確にする。 |
| c.品質マネジメント | テストで摘出する不良件数の実績値と目標値を比較する。 |
| d.コストマネジメント | プログラムの規模や生産性などを考慮して開発費用を見積もる。 |
プロジェクトステークホルダーマネジメントに関する記述として、適切なものはcである。
| a | プロジェクト憲章やプロジェクトマネジメントの計画書を作成し、知識や教訓を組織の資産として登録する。 |
| b | プロジェクト全体を通じて、最も長い所要期間を要する作業経路を管理する。 |
| c | プロジェクトの結果に利害を及ぼす可能性がある事象を管理する。 |
| d | プロジェクトの実施とその結果によって利害を被る関係者を調整する。 |
（出典：平成28年度春期分 問47一部改変）
答え：×
| a.統合マネジメント | プロジェクト憲章やプロジェクトマネジメントの計画書を作成し、知識や教訓を組織の資産として登録する。 |
| b.タイムマネジメント | プロジェクト全体を通じて、最も長い所要期間を要する作業経路を管理する。 |
| c.リスクマネジメント | プロジェクトの結果に利害を及ぼす可能性がある事象を管理する。 |
| d.ステークホルダマネジメント | プロジェクトの実施とその結果によって利害を被る関係者を調整する。 |
情報システムを請負契約で海外ベンダに発注することになった。このときのプロジェクト調達マネジメントとして、適切な記述はdである。
| a | プロジェクト情報の作成や配布の方法を明確にする。 |
| b | プロジェクトが生み出す製品やサービスなどの成果物と、それらを完成するために必要な作業を定義し管理する。 |
| c | スケジュールを作成し、進捗管理を行う。 |
| d | 契約時に、納品するドキュメントや開発中の仕様変更ルールなどを文書で合意する。 |
（出典：平成31年度春期分 問40一部改変）
答え：〇
| a.コミュニケーションマネジメント | プロジェクト情報の作成や配布の方法を明確にする。 |
| b.スコープマネジメント | プロジェクトが生み出す製品やサービスなどの成果物と、それらを完成するために必要な作業を定義し管理する。 |
| c.スケジュールマネジメント | スケジュールを作成し、進捗管理を行う。 |
| d.調達マネジメント | 契約時に、納品するドキュメントや開発中の仕様変更ルールなどを文書で合意する。 |
プロジェクトマネジメント2
システム開発のプロジェクトマネジメントに関する記述1〜4のうち、スコープのマネジメントの失敗事例は２つある。
- 開発に必要な人件費を過少に見積もったので、予算を超過した。
- 開発の作業に必要な期間を短く設定したので、予定期間で開発を完了させることができなかった。
- 作成する機能の範囲をあらかじめ決めずにプロジェクトを開始したので、開発期間を超過した。
- プロジェクトで実施すべき作業が幾つか計画から欠落していたので、システムを完成できなかった。
（出典：令和5年度春期分 問54一部改変）
答え：〇
プロジェクトスコープマネジメントでは、プロジェクトを成功させるために必要な作業を過不足なく抽出し、「なにをどこまでやればいいのか」という作業範囲（スコープ）を定義します。
1.の記述：プロジェクトコストマネジメントの失敗事例です。
2.の記述：プロジェクトスケジュール（タイム）マネジメントの失敗事例です。
3.の記述：プロジェクトスコープマネジメントの失敗事例です。
4.の記述：プロジェクトスコープマネジメントの失敗事例です。
WBS（Work Breakdown Structure）ではプロジェクトで実施すべき作業内容と成果物を定義するので、作業工数を見積もるときの根拠として使用できる。
（出典：令和4年度春期分 問36一部改変）
答え：〇
WBS（Work Breakdown Structure）とは、プロジェクトという１つの大きな作業のかたまりを細かい作業に分割して管理する手法です。細かい作業に分割することによって、「何をやればいいのか」「作業にどのくらいの時間・コストがかかるのか」といったことを見積もりやすくなります。
プロジェクトスコープマネジメントでは、一般にスコープの定義にはWBSを利用します。
作業を縦軸にとって、作業の所要期間を横棒で表した図をアローダイアグラムという。
（出典：令和元年度秋期分 問42一部改変）
答え：×
設問はガントチャートの説明になります。なお、アローダイアグラムとは作業の関連（依存関係）をネットワークで表した図です。
図の工程の最短所要日数は70日、最長所要日数は100日である。
（出典：令和2年度秋期分 問55一部改変）
答え：×
各作業が最短で終了した場合のクリティカルパスは、作業A（30日）と作業B（50日）の合計80日となります。作業Cが70日で終わったとしても、作業Aと作業Bが終わらないと全体の作業は完了しないからです。したがって、最短所要日数は80日となります。
一方で、各作業が最長で終了した場合のクリティカルパスは作業Cの100日となるため、最長所要日数は100日です。
次のアローダイアグラムに基づき作業を行った結果、作業Dが2日遅延し、作業Fが3日前倒しで完了した。このとき、作業全体の所要日数は予定と比べて2日前倒しとなる。
（出典：令和5年度春期分 問41一部改変）
答え：〇
まず、予定通りに作業が完了した場合のクリティカルパスを考えます。
・A（2日）→C（4日）→F（5日）：合計11日（クリティカルパス）
・B（3日）→D（1日）→F（5日）：合計9日
・B（3日）→E（1日）→G（5日）：合計9日
次に予定変更後のクリティカルパスを考えます。
・A（2日）→C（4日）→F（2日）：合計8日
・B（3日）→D（3日）→F（2日）：合計8日
・B（3日）→E（1日）→G（5日）：合計9日（クリティカルパス）
クリティカルパスが、変更前の11日から変更後は9日へ、2日短くなります。したがって、作業全体の所要日数は予定と比べて2日前倒しとなります。
プロジェクトは期限が決まっているので、プロジェクト開始時点において全てのリスクを特定しなければならない。
（出典：平成31年度春期分 問37一部改変）
答え：×
プロジェクト開始時点においては、できる限りリスクを特定しておくべきですが、プロジェクトにおけるリスクには事前に把握できないものもあります。リスクはプロジェクトの進捗状況や外的要因によって変化するため、プロジェクト実行中においてもリスクを監視して、繰り返し分析を行う必要があります。
システム開発プロジェクトにおいて、テスト工程で使用するPCの納入が遅れることでテスト工程の終了が遅れるリスクがあり、対応策を決めた。リスク対応を回避、軽減、受容、転嫁の四つに分類するとき、受容に該当する記述はdである。
| a | 全体のスケジュール遅延を防止するために、テスト要員を増員する。 |
| b | テスト工程の終了が遅れても本番稼働に影響を与えないように、プロジェクトに予備の期間を設ける。 |
| c | テスト工程の遅延防止対策を実施する費用を納入業者が補償する契約を業者と結ぶ。 |
| d | テスト工程用のPCがなくてもテストを行える方法を準備する。 |
（出典：令和2年度秋期分 問54一部改変）
答え：×
| a.軽減 | 全体のスケジュール遅延を防止するために、テスト要員を増員する。 |
| b.受容 | テスト工程の終了が遅れても本番稼働に影響を与えないように、プロジェクトに予備の期間を設ける。 |
| c.転嫁 | テスト工程の遅延防止対策を実施する費用を納入業者が補償する契約を業者と結ぶ。 |
| d.回避 | テスト工程用のPCがなくてもテストを行える方法を準備する。 |
