iパス マネジメント系の要点まとめ
本試験はマネジメント系20問程度。問題数は少なめですが、この分野も300点以上（1,000点満点）が必要です。用語の区別ができれば得点しやすい分野です。
開発モデルと手法
| 名前 | 特徴 |
|---|
| ウォーターフォールモデル | 工程を順に進め、原則として前に戻らない。仕様変更に弱い |
| プロトタイピングモデル | 試作品を見てもらいながら要求をはっきりさせる |
| アジャイル開発（スクラム） | スプリントという短い期間を繰り返し、少しずつ作る |
| ペアプログラミング | 2人1組で、書く人と確認する人に分かれる（XPの実践） |
| テスト駆動開発 | 先にテストを書き、それに合格するコードを作る |
| リファクタリング | 外から見た動作を変えずに内部の構造を改善 |
| DevOps | 開発と運用が連携して、すばやくリリースを繰り返す |
開発の流れ：要件定義 → 設計 → プログラミング → テスト → 運用・保守。作業内容と用語をそろえる枠組みが共通フレームです。図の表記の標準はUML、データの流れを表す図はDFDです。
テストの種類
| テスト | 見るところ |
|---|
| ブラックボックステスト | 内部は見ず、入力と出力が仕様どおりか |
| ホワイトボックステスト | 内部の命令や分岐がもれなく実行されるか |
| 単体→結合→システム | 部品ごと→部品のつながり→システム全体（開発者が行う） |
| 受入れテスト | 発注者が、要求どおりかを確かめて受け入れを判断 |
| 回帰テスト | 修正していない部分に悪影響が出ていないか |
プロジェクトマネジメント
| 用語 | 意味 |
|---|
| WBS | 作業を階層的に細かく分解したもの |
| ガントチャート | 作業ごとの予定と実績を横棒で表す |
| PERT図（アローダイアグラム） | 作業の順序と日数を矢印で表す |
| クリティカルパス | 余裕がなく、遅れると全体が遅れる経路（いちばん長い経路） |
| スコープ | 作る成果物と必要な作業の範囲 |
| ステークホルダ | プロジェクトの利害関係者 |
| マイルストーン | 重要な節目 |
A（3日）のあとB（5日）とC（4日）を並行し、両方終わったらD（2日）。A→B→D＝10日、A→C→D＝9日なので、最短でも10日かかります。人月の計算は「作業量÷人数」。12人月を3人でやれば4か月です。
リスクへの対応
| 対応 | 中身 | 例 |
|---|
| 回避 | 原因そのものをなくす | 危ない作業をやめる |
| 移転（転嫁） | 影響を第三者に移す | 保険をかける |
| 軽減 | 確率や影響を小さくする | バックアップを取る |
| 受容 | そのまま受け入れる | 影響が小さいので対策しない |
サービスマネジメント
| 用語 | 意味 |
|---|
| ITIL | ITサービス管理のベストプラクティス集 |
| SLA | 稼働率や応答時間などサービス品質の合意書 |
| インシデント管理 | とにかく早くサービスを復旧させる |
| 問題管理 | 根本原因を突き止めて再発を防ぐ |
| 変更管理／リリース管理 | 変更を安全に承認・実施する／本番環境へ展開する |
| サービスデスク | 問合せの一元的な窓口（SPOC） |
| UPS | 停電時に一時的に電力を供給する装置（ファシリティマネジメント） |
システム監査と内部統制
- システム監査人は、監査対象から独立した立場で客観的に点検・評価し、助言・勧告する。
- 監査報告書は監査の依頼者（経営者など）に提出する。改善を実行するのは監査を受けた部門。
- 内部統制の目的は、業務の有効性・効率性、財務報告の信頼性、法令の遵守、資産の保全。
- 職務分掌：発注・承認・支払などの担当を分けて、一人で不正ができないようにする。
- ITガバナンス：経営陣がIT戦略を立て、ITの活用を組織として統制する。責任は経営陣にある。