ITパスポート 令和8年度 問36：project_managementに関する問題

答えは c（a, c） です。

システム導入の作業では「契約で決めた範囲を守る」のが基本ルールです。

• a 契約外のPCが見つかった→対象外にした ◯（決めた範囲だけやるので正しい）
• c 続行が難しくなった→発注者と相談して合意のうえ元の状態に戻した ◯（勝手にやめず相談しているので正しい）

でも b「契約外のPCに頼まれたからタダで対応した」は×。良かれと思っても、契約にないことを勝手に無償でやると、責任や費用の線引きが崩れます。

👉 覚え方：契約の範囲を守る／困ったら勝手に判断せず発注者と合意。

なぜこれが正解か

正解は c（a, c）。プロジェクトでは契約で定めたスコープ（作業範囲）を守ることが原則。

• a 契約外のPCを発見し導入対象外とした→スコープ通りの正しい判断 ◯
• c 続行困難になり、発注者と合意して導入前の状態に復旧した→勝手に判断せず合意形成しており適切 ◯

含まれない項目

• b 契約外PCへの導入依頼を無償で実施→たとえ無償でも契約外作業を独断で引き受けるのは不適切。スコープクリープ（範囲の無秩序な拡大）を招き、責任範囲・品質・スケジュールに悪影響。本来は変更管理手続き（契約変更の合意）を経るべき。

bが不適切なので、a・cのcが正解。

覚え方・ひっかけ注意

「契約範囲を守る」「変更は必ず発注者と合意」が鉄則。「良かれと思って無償で」「気を利かせて契約外を」は引っかけ。無償＝善行に見えるが、正しい手続き（変更管理）を欠く点でNG。

理論的背景

プロジェクトマネジメントにおける契約と変更管理の問題は、PMBOK（Project Management Body of Knowledge）の「調達マネジメント」知識エリアで体系化されている。請負契約における「契約スコープ（Scope of Work：SOW）」の管理は、プロジェクト成功の根幹要素の一つで「スコープクリープ（契約外作業の無断実施による範囲拡大）」が失敗の典型原因となる。本問の選択肢分析。a「契約外PCを対象外にした」→正しい契約管理（SOWの遵守）。b「契約外PCへの導入を無償で行った」→スコープクリープの典型例で、ただ作業を行うと「黙示の合意」として無償追加作業が慣行化するリスクがあり、不適切。c「続行困難となり発注者と合意して導入前の状態に復旧した」→正しい変更管理（発注者合意のもとでのロールバック）。したがってaとcの組み合わせ（選択肢c）が正解。

実務での使われ方

ITプロジェクトのスコープ管理は現実の開発現場で最も頻繁に起きるトラブルの一つ。SIer業界では「仕様変更・追加作業の費用増額交渉」が困難なため、営業担当が「この程度ならサービスで」と無償追加を約束してしまい、エンジニアが無限の追加作業を抱えるという問題が慢性的に発生している。変更管理プロセス（Change Control Process）はPMBOKの変更管理委員会（CCB：Change Control Board）が中心で「変更要求の記録→影響分析（スケジュール・コスト・リスク）→承認/却下の意思決定→契約変更（CR：Change Request）→実施」という正式フローで実行される。Agileプロジェクトではスプリントを単位とした「スコープの再交渉（バックログリファインメント・スプリント計画）」が変更管理の実践形態となる。

試験での位置づけ

プロジェクト管理・契約管理の問題はITパスポートのマネジメント系カテゴリで出題される。本問はプロジェクト実践の倫理・適切な行動規範を問う問題で、PMBOK・プロジェクトマネージャーの行動規範（PMI Code of Ethics and Professional Conduct）の観点から判断する。誤答パターンはbを含めてしまうケースで「顧客の要望に応えるのが良い仕事では？」という誤解から生じる。実際には「契約外作業を無断・無償で行う」ことは契約違反・スコープクリープの問題を引き起こし、後続プロジェクトへの慣行化・プロジェクト収益悪化・メンバー負荷増大という三重の問題をもたらす。正しい対応は「契約外作業を正式に断り→変更要求として正式に受け付け→コスト・スケジュール影響を見積り→発注者と合意→契約変更」というプロセスを踏むことである。

選択肢の発展補足

選択肢bのような「無償追加作業」がなぜ問題かを深く理解するためにSIer業界の経営課題と結びつけて考える。日本のSIer業界の平均利益率は低く（大手でも5%前後）、スコープクリープによる追加工数は直接的に損益を圧迫する。「言った・言わない」問題を防ぐために「3点合意（発注者・PM・開発者の三者が変更内容・費用・スケジュールに合意したエビデンスを残す）」という実務慣行がある。選択肢cのロールバック（Rollback）は「システムを導入前の状態に戻すこと」で、データベース管理では「トランザクションの取り消し」としても使われる重要概念。導入作業の失敗・中断時に発注者との合意なしにロールバックしないのは「作業状況の透明性（PMBOK：コミュニケーションマネジメントの原則）」の観点から正しい。ITシステムの導入・変更において「問題発生時の対応手順（ロールバック手順・判断基準・連絡体制）」を事前に定めておくことが実務ベストプラクティスであり、本問のcはその典型例を示している。