ITパスポート マネジメント系 完全解説
マネジメント系は、ITパスポート試験（iパス）の3分野のひとつで、全体の約20%を占めます。 プロジェクト管理の手法（WBS・ガントチャート・クリティカルパス）、システム開発モデル（アジャイル・ウォーターフォール）、 ITサービスマネジメント（ITIL）、そしてシステム監査まで、IT活用を「管理・運用する側」の視点が問われます。 このページでは頻出テーマを例題付きで解説します。
1. プロジェクトマネジメント（PMBOK・WBS・ガントチャート・クリティカルパス）
プロジェクトとは「独自の成果物を生み出すための有期限の取り組み」です。 プロジェクトマネジメントでは、スコープ・スケジュール・コスト・品質・リスクなどを管理します。 PMBOKはProject Management Body of Knowledgeの略で、プロジェクト管理の知識体系です。
WBS（Work Breakdown Structure：作業分解構成図）
プロジェクトの全作業を階層的に分解したツリー構造の図です。 プロジェクトを管理可能な作業単位（ワークパッケージ）に分解することで、 作業の漏れ・重複を防ぎ、スケジュールやコストの見積もりに使います。 「最終成果物を起点として分解する」ことが重要です。
ガントチャート
各作業の開始日・終了日・期間を横棒（バー）で表した図です。 作業間の依存関係（先行関係）も示すことができます。 スケジュールの進捗管理に広く使われ、視覚的に進行状況を把握できます。
クリティカルパス
プロジェクト全体の作業を繋いだネットワーク図（PERT図）上で、 最も長い所要時間を持つ経路のことです。クリティカルパス上の作業が遅れると プロジェクト全体の完了が遅れます。
プロジェクトマネジメントの管理対象（QCDSなど）
| 管理対象 | 内容 |
|---|---|
| スコープ管理 | 何を作るか（範囲）を定義・管理する |
| スケジュール管理 | いつ完了するかをガントチャート・CPMで管理 |
| コスト管理 | 予算内に収めるためのEVM（出来高管理）など |
| 品質管理 | 成果物が要件を満たすかテストや品質基準で確認 |
| リスク管理 | リスクの特定・評価・対応計画の策定 |
| 人的資源管理 | チームメンバーの確保・育成・マネジメント |
2. システム開発モデル（ウォーターフォール・アジャイル・プロトタイプ・スパイラル）
システム開発の進め方には様々なモデルがあります。各モデルの特徴と適した状況を理解しましょう。
| モデル | 特徴 | 適した場面 | 欠点 |
|---|---|---|---|
| ウォーターフォールモデル | 要件定義→設計→実装→テスト→運用を順番に進める。前工程が完了してから次工程へ | 要件が明確で変更が少ないシステム | 要件変更への対応が困難。手戻りコストが大きい |
| アジャイル開発 | 短いイテレーション（スプリント）を繰り返し、動くソフトウェアを継続的にリリース | 要件変更が多い・スピードが重要な開発 | 長期計画が立てにくい。ドキュメントが不十分になりやすい |
| スクラム | アジャイルの代表的フレームワーク。スプリント（1〜4週間）・プロダクトオーナー・スクラムマスターなどの役割を定義 | チームの自律性を重視する開発 | メンバーのスキルと自律性が求められる |
| プロトタイプモデル | 試作品（プロトタイプ）を早期に作り、ユーザーの確認を得てから本開発に進む | 要件が不明確でユーザー確認が必要な場合 | 試作品が流用されて品質問題になることも |
| スパイラルモデル | 計画→リスク分析→開発→評価を螺旋状に繰り返す。リスク管理を重視 | 大規模・高リスクのプロジェクト | 管理が複雑。コストがかかりやすい |
DevOpsとCI/CD
- DevOps：開発（Development）と運用（Operations）が連携して、開発サイクルを短縮する考え方
- CI（継続的インテグレーション）：コード変更を頻繁にマージし、自動テストで品質を確認する手法
- CD（継続的デリバリー/デプロイ）：テストを通過したコードを自動的に本番環境に反映する手法
3. テスト技法（ブラックボックス・ホワイトボックス・境界値・デシジョンテーブル）
ソフトウェアテストは品質を確保するための重要な工程です。試験では各テスト技法の名称と特徴が問われます。
| テスト技法 | 着目点 | 内容 |
|---|---|---|
| ブラックボックステスト | 入力と出力 | 内部構造を知らずに、仕様通りの動作をするか確認。同値分割・境界値分析が代表的手法 |
| ホワイトボックステスト | 内部構造（ソースコード） | 命令の実行パスを網羅するテスト。条件分岐の全パターンをテスト（分岐網羅） |
| 同値分割 | 同じ結果になる入力グループ | 入力値を有効・無効のグループに分け、各グループから代表値を選んでテスト |
| 境界値分析 | 境界付近の値 | 有効範囲の上限・下限とその前後の値をテスト。例：1〜100が有効なら0、1、100、101をテスト |
| デシジョンテーブル（決定表） | 条件の組み合わせ | 複数条件の全組み合わせと対応するアクションを表形式で整理 |
テストの工程
| 工程 | 目的 | 対応する開発工程 |
|---|---|---|
| 単体テスト（ユニットテスト） | モジュール単体の動作確認 | 詳細設計 |
| 結合テスト（統合テスト） | モジュール間のインタフェース確認 | 基本設計 |
| システムテスト | システム全体が要件を満たすか確認 | 要件定義 |
| 受入テスト（UAT） | 利用者・発注者による最終確認 | 要件定義 |
4. サービスマネジメント（ITIL・インシデント管理・変更管理・SLA）
ITサービスマネジメント（ITSM）は、ITサービスを安定的に提供・管理するための仕組みです。 代表的なフレームワークがITIL（IT Infrastructure Library）で、iパス試験でも頻出です。
ITIL の主なプロセス
| プロセス | 目的 | ポイント |
|---|---|---|
| インシデント管理 | サービス中断・品質低下からの迅速な復旧 | 根本原因の解決ではなく、まず「早期復旧」を優先する |
| 問題管理 | インシデントの根本原因を特定・除去 | 再発防止が目的。既知エラーデータベース（KEDB）を管理 |
| 変更管理 | ITサービスへの変更を承認・管理・記録 | 変更による障害リスクを最小化。変更諮問委員会（CAB）が審議 |
| リリース管理 | 変更を本番環境に安全に展開 | 変更管理と連携し、リリース計画・テスト・展開を管理 |
| 構成管理（CMDB） | ITインフラの構成情報を一元管理 | CMDB（構成管理データベース）に全CI（構成アイテム）を記録 |
| サービスデスク | 利用者の問い合わせ・インシデントの窓口 | SPOC（単一窓口）として機能。ヘルプデスクとも呼ばれる |
SLA（Service Level Agreement：サービスレベル合意）
ITサービス提供者と顧客（利用者）の間で、サービス品質の水準を明文化した合意文書です。 可用性（例：99.9%の稼働率）、応答時間（例：問い合わせ後4時間以内に応答）、 障害復旧目標（RTO：目標復旧時間、RPO：目標復旧時点）などを規定します。
- RTO（Recovery Time Objective）：障害発生後、システムを復旧させるまでの目標時間
- RPO（Recovery Point Objective）：障害発生時に、どの時点のデータまで復旧させるかの目標
- 可用性：稼働率（％）で表す。99.9%稼働率なら年間約8.76時間の停止が許容される
5. システム監査（目的・独立性・内部統制）
システム監査は、情報システムが適切に管理・運用されているかを独立した立場から点検・評価する活動です。 経営者・利用者・社会への保証や助言を提供することが目的です。
システム監査の特徴
- 独立性：監査人は監査対象から独立していなければならない。利害関係があってはいけない
- 客観性：証拠に基づいた客観的な判断が求められる
- 監査証拠：監査意見の根拠となる文書・記録・聞き取り結果など
- 監査調書：監査の実施内容・証拠・判断を記録した文書
- 監査報告書：監査結果と意見を経営者に報告する文書
内部統制
組織が業務の有効性・効率性・財務報告の信頼性・法令遵守を確保するために構築する仕組みです。 内部統制の4つの目的は、業務の有効性と効率性・財務報告の信頼性・関連法令の遵守・資産の保全です。 日本では金融商品取引法（J-SOX）により、上場企業に内部統制報告書の提出が義務付けられています。
| 内部統制の構成要素 | 内容 |
|---|---|
| 統制環境 | 組織の倫理観・誠実さ・能力・ガバナンスなどの基盤 |
| リスクの評価と対応 | 目標達成を妨げるリスクの識別・分析・対応 |
| 統制活動 | 方針・手続きの確立と実施（職務分離・承認・照合など） |
| 情報と伝達 | 関係者への適時・適切な情報の共有 |
| モニタリング | 内部統制の有効性を継続的に評価・改善 |
システム監査の種類
- 情報セキュリティ監査：情報資産の管理状況を確認する監査
- 個人情報保護監査：個人情報の取り扱いが法令・方針に従っているか確認
- 会計システム監査：財務処理を行うシステムの正確性・信頼性を確認
6. 例題で確認
ア. ガントチャート イ. WBS ウ. PERT図 エ. デシジョンテーブル
7. よくある質問
Q. ウォーターフォールとアジャイルはどう使い分けるのですか？
A. ウォーターフォールは「要件が明確で変更が少ない」「品質・文書管理が重視される」官公庁システムや基幹系に向いています。アジャイルは「要件が変わりやすい」「スピードが重要」なWebサービスやアプリ開発に向いています。試験では特定のシナリオを読み、どちらが適切かを選ぶ問題が出ます。「顧客と密接に連携して短期間でリリースを繰り返す」とあればアジャイルです。
Q. SLAのRTOとRPOの違いが分かりません。
A. RTO（Recovery Time Objective）は「どれだけ早く復旧させるか」という時間の目標です。例えばRTO=4時間なら、障害発生から4時間以内にサービスを再開させる必要があります。RPO（Recovery Point Objective）は「どこまでのデータを復元できるか」という時点の目標です。例えばRPO=1時間なら、最大1時間分のデータ損失は許容することを意味します。毎日バックアップするシステムのRPOは最大24時間になります。
Q. システム監査で「独立性」が重要な理由は何ですか？
A. 監査対象と利害関係があると、客観的な評価ができないからです。例えば自分が開発したシステムを自分で監査すれば、問題を見逃したり、有利に評価してしまう可能性があります。そのため監査人は「監査対象の業務に直接関与していない」ことが必須条件です。試験では「監査人が自ら構築したシステムを監査することの問題点」といった問いで独立性の概念が問われます。