ITパスポート ― マネジメント系 問題一覧・解説

📝 解説

プロジェクトマネジメントとは「特定の目標を達成するために有期限で行うプロジェクトを計画・組織・指揮・統制する管理活動」です。建設工事に例えると最もわかりやすいですよ。「2年後に鉄道新駅を完成させる」という目標のもと、設計・資材調達・工事・検査という工程を計画し、スケジュール・コスト・品質・リスクを管理しながら期限内に完成させる活動がプロジェクトマネジメントです。PMBOKでは範囲・スケジュール・コスト・品質・リソース・コミュニケーション・リスク・調達・ステークホルダー・統合の10知識エリアで管理します。「プロジェクト」の定義は「有期限（始まりと終わりがある）」「独自性（繰り返しではない）」が重要です。誤答の「日常的な業務を継続的に管理する」は運用管理（オペレーション）、「組織全体の戦略を管理する」は経営管理の話です！

📝 解説

ガントチャートとは「各作業を縦軸に、時間（日程）を横軸に取り、作業期間を横棒で表したスケジュール管理ツール」です。鉄道の時刻表に例えると一番わかりやすいですね。各列車（作業）が何時から何時まで走るか（期間）を横棒で表し、複数の列車が同時並行で走る様子が一目でわかります。プロジェクトでは「計画線」と「実績線」を重ねて表示することで遅延・進捗を視覚的に把握できます。ヘンリー・ガント氏が考案したためガントチャートと呼ばれます。誤答の「組織の階層を表す図」は組織図（OBS）、「ネットワークの構成を表す図」はアロー図法（PERT図）またはネットワーク図、「コストの内訳を表す円グラフ」はパイチャートの説明です。ガントチャートは進捗の「見える化」が目的の基本ツールとして試験頻出です！

📝 解説

WBS（Work Breakdown Structure：作業分解構成図）とは「プロジェクト全体の作業を成果物ベースで階層的に分解した構成図」です。料理のレシピ分解に例えましょう。「クリスマスケーキを作る」というプロジェクトをWBSで分解すると、スポンジ作り・クリーム作り・デコレーションの大項目に分け、スポンジ作りはさらに「材料の計量→卵を泡立てる→オーブンで焼く」という小作業に分解します。この分解の最小単位を「ワークパッケージ」と呼び、担当者・工数・スケジュールを割り当てる基礎となります。WBSは作業の洗い出し漏れを防ぎ、見積もり・スケジュール作成・責任分担の土台となるプロジェクト管理の要です。誤答の「予算を管理する表」はコスト計画書、「リスクを管理する表」はリスク管理簿、「組織を表す図」はOBS（組織分解構成図）の説明です！

📝 解説

クリティカルパスとは「プロジェクト開始から終了までの経路のうち、作業時間の合計が最も長い経路」のことで、これが最終的なプロジェクト完了日を決定します。鉄道の乗り継ぎに例えましょう。東京から大阪まで複数の乗り継ぎルートがあるとき、一番時間がかかるルートが最短到着時刻を決めますね。プロジェクトでも並行して進む複数の作業経路のうち最も時間がかかる経路（クリティカルパス）が納期を決めます。クリティカルパス上の作業に余裕（フロート）はゼロで、1日でも遅れると全体の納期が遅れます。逆にクリティカルパス上でない作業は「フロート（余裕時間）」がある分だけ遅れても問題ありません。PERT/CPM法で求め、ガントチャートと組み合わせて使われます。誤答の「最も重要な作業」「最もコストのかかる作業」「最も危険な作業」はいずれもクリティカルパスの定義と異なります！

📝 解説

リスクマネジメントのリスク対応策は4種類あります。回避（リスクの原因ごと取り除く）・転嫁（保険や外部委託でリスクを移す）・軽減（確率・影響度を下げる）・受容（対策コストより損失が小さければ何もしない）です。「リスク回避」は「リスクそのものを取り除く」ことです。台風の例えで考えましょう。台風が来ることがわかっていたら、「台風の日に海へ行くイベントをキャンセルする（リスク回避）」か「保険に入る（転嫁）」か「頑丈な会場を用意する（軽減）」か「少しくらい濡れてもいいと割り切る（受容）」かの選択肢があります。「リスクの影響を軽減する」はリスク軽減、「第三者に転嫁する」はリスク転嫁、「そのまま受け入れる」はリスク受容の説明です。4つの対応策の名称と内容をセットで覚えましょう！

📝 解説

ITIL（Information Technology Infrastructure Library）とは「ITサービスマネジメントのベストプラクティスをまとめたフレームワーク（参考書集）」です。料理の分野に例えると、世界中の優れたシェフたちの調理技術・衛生管理・接客方法を1冊の「プロのバイブル」としてまとめたものがITILのイメージです。英国政府が1980年代に開発し、現在はAxelosが管理しています。ITILはサービスデスク・インシデント管理・問題管理・変更管理・リリース管理・サービスレベル管理など多くの管理プロセスの指針を提供します。最新版はITIL4で、DevOpsや俊敏な開発手法と統合した内容になっています。誤答の「プロジェクト管理の国際標準」はPMBOKやPRINCE2、「情報セキュリティの国際標準」はISO/IEC 27001、「ソフトウェア開発の品質基準」はCMMIの説明です！

📝 解説

SLA（Service Level Agreement：サービスレベル合意書）とは「ITサービス提供者と利用者の間で、サービス品質の水準について合意した文書」です。電気の供給契約に例えると一番わかりやすいですよ。電力会社との契約では「停電時間は年間○時間以内・電圧は○V以内」といった品質基準が定められていますね。これと同様にITサービスのSLAでは、稼働率（例：99.9%以上）・障害時の対応時間（例：2時間以内に応答）・応答時間（例：3秒以内）などの具体的な数値目標を合意します。SLAを守れなかった場合はペナルティ（サービス料金の減額など）が発生するケースもあります。誤答の「ソフトウェアのライセンス契約」はEULA（使用許諾契約）、「セキュリティポリシーの文書」は情報セキュリティ方針書、「プロジェクト計画書」はプロジェクトマネジメント文書の説明です！

📝 解説

ヘルプデスク（サービスデスク）とは「ユーザーからのITに関する問い合わせや障害報告を受け付け、解決またはエスカレーション（上位担当者への引き継ぎ）を行う窓口機能」です。駅の「みどりの窓口」に例えましょう。駅員（ヘルプデスク担当者）は乗客からの「切符の買い方がわからない」「改札でエラーが出た」などの問い合わせを受け付け、解決できない場合は専門家（駅長・本社）にエスカレーションします。ITILではヘルプデスクをインシデント管理のシングルポイントオブコンタクト（SPOC：窓口一本化）として位置づけています。誤答の「システムの開発を行う」は開発チーム、「ネットワークの設計を行う」はネットワークエンジニア、「セキュリティ監査を行う」は情報セキュリティ監査部門の役割です。ユーザーの「最初の相談窓口」がヘルプデスクの本質です！

📝 解説

インシデントマネジメントとは「システム障害などのインシデントに対し、できるだけ早くサービスを正常な状態に戻すことを目的とした管理プロセス」です。救急医療に例えましょう。救急車が現場に到着したとき、まず「命を助けること（症状の安定化）」を最優先にします。病気の原因を調べて根本治療するのはその後です。インシデントマネジメントも同じで「根本原因を解明・除去すること」ではなく「まずサービスを早期回復させること」が目的です。根本原因の解消は「問題管理（Problem Management）」が担当します。誤答の「インシデントの根本原因を解決する」が問題管理、「インシデントを予防する」は問題管理や変更管理、「インシデントのコストを削減する」はITILの副次的効果です。「早期復旧」と「根本解決」の担当プロセスの違いを区別して覚えましょう！

📝 解説

変更管理（チェンジマネジメント）とは「システム・サービスへの変更を計画的・安全に実施し、変更によるリスクを最小限にするプロセス」です。道路工事の交通規制に例えましょう。幹線道路を補修工事する場合、突然全面通行止めにすると大混雑が起きます。そこで事前に迂回路を案内し・工事範囲を明確にし・深夜だけ通行止めにするなど計画的に変更します。変更管理でも同様に、変更要求の受付→影響評価→変更諮問委員会（CAB）による承認→計画的な実施→結果確認という手順を踏みます。誤答の「変更を禁止してシステムを安定させる」は現実的でなくサービス改善もできません。「変更を素早く実施する」はリスクが高く障害を招く恐れがあります。「変更のコストを削減する」は副次的効果であって目的ではありません。「安全な変更」がキーワードです！

📝 解説

システム監査とは「組織のITシステムが方針・法令・社内規程に沿って適切に管理・運用されているかを独立した立場で検証する活動」です。税務調査に例えると一番わかりやすいですよ。税務調査官は企業の外部から中立な立場で帳簿・書類を確認し、適切に申告・納税されているかをチェックします。システム監査も同様に、「情報システムが経営目標に沿って有効に活用されているか」「セキュリティや内部統制が機能しているか」を独立した監査人が検証します。「独立した立場」が重要で、自分の担当システムを自分で監査することはできません。システム監査の結果は経営層に報告され、改善勧告が出されます。誤答の「システムの開発コストを削減する」「システムの性能を向上させる」「システムのセキュリティを強化する」はシステム監査の直接の目的ではありません！

📝 解説

内部統制とは「企業が業務の有効性・効率性・財務報告の信頼性・法令遵守・資産の保全を確保するために整備・運用する仕組み」です。信号機と交通法規に例えましょう。交通渋滞を防ぎ事故をなくすために、信号機・道路標識・速度制限・交通違反の罰則という仕組みが社会全体で整備されていますね。企業でも同様に、不正・ミス・非効率を防ぐための承認手続き・チェック機能・監査体制を整備することが内部統制です。日本では金融商品取引法に基づくJ-SOX（内部統制報告制度）があり、上場企業は経営者が内部統制の有効性を評価して報告することが義務付けられています。誤答の「利益を最大化する」は経営目標の一つですが内部統制の定義ではありません。「従業員を管理する」は人事管理、「競合他社に対抗する」は競争戦略の話です！

📝 解説

情報セキュリティポリシーとは「組織の情報セキュリティに関する方針・基準・手順をまとめた文書体系」のことです。会社の就業規則に例えましょう。就業規則には「勤務時間」「服務規律」「懲戒処分」などが定められ、全社員が守るべきルールが明文化されています。情報セキュリティポリシーもこれと同様で「何を守るか・どうやって守るか・違反したらどうなるか」を文書化します。一般的に基本方針（なぜセキュリティが必要か）→対策基準（何をどう守るか）→実施手順（具体的な操作・作業手順）の3階層で構成されます。誤答の「特定のセキュリティ製品の導入計画」はセキュリティ製品選定の話、「セキュリティ事故が発生した際の対応手順書」はインシデント対応手順書（ポリシーの一部）、「セキュリティ研修の計画書」は教育計画書の説明です！

📝 解説

ISMS（Information Security Management System：情報セキュリティマネジメントシステム）とは「情報セキュリティを組織的・継続的に管理するためのマネジメントシステム」で、ISO/IEC 27001が国際標準です。工場の品質管理システムに例えましょう。自動車工場は「品質を維持するための工程管理・検査・改善サイクル（PDCAサイクル）」を組織的に運用していますね。ISMSも同様に情報資産のリスクアセスメント→対策の実施→監査・見直しというPDCAサイクルで情報セキュリティを継続的に改善します。ISMS認証（ISO27001認証）を取得すると「情報セキュリティ管理が適切」と第三者が保証します。誤答の「ウイルス対策ソフトの規格」は個別のセキュリティツールの話、「ネットワーク機器の管理システム」はNMS（ネットワーク管理システム）、「クラウドサービスの規格」はISO/IEC 27017などです！

📝 解説

QCDとは品質（Quality）・コスト（Cost）・納期（Delivery）の頭文字を取った、製造業やプロジェクト管理で最も重視される3つの管理指標です。レストランの料理に例えるとわかりやすいですよ。「おいしい料理（品質）」を「手頃な価格（コスト）」で「注文してから素早く提供する（納期）」が飲食店の基本ですね。3つのバランスが崩れると品質を上げようとすればコストが上がる、コストを下げようとすれば品質や納期が犠牲になる、というトレードオフの関係があります。製品開発・システム開発・製造現場のどの現場でもQCDは常にせめぎ合っています。誤答の「数量・コスト・分配」「品質・能力・開発」「計画・実行・確認」はいずれも正しい定義ではありません。「計画・実行・確認・改善」はPDCAサイクルの各ステップです。QCDは語順ごと覚えましょう！

📝 解説

テスト計画書に記載すべき内容はテストの目的・範囲・戦略、テスト環境・使用ツール、スケジュール（テスト実施日程）、担当者・役割分担、テスト終了条件（合否基準）、リスクと対応策などです。建設工事の検査計画書に例えましょう。検査計画には「どこを・どのように・いつ・誰が検査するか・合格基準は何か」を記載しますが「建物の販売価格」は検査計画書に書くものではありませんね。同様に「システムの販売価格」はビジネス上の情報であり、テスト計画とは無関係です。テスト計画書はシステムが正しく動くかを検証するための技術的な計画文書であり、価格設定は営業・経営の領域です。試験では「テスト計画書に含まれないもの」という形で出題されることが多いので、「テストと直接関係のない情報」を選ぶ視点を持ちましょう！

📝 解説

スクラム（Scrum）とは「アジャイル開発の代表的なフレームワークで、1〜4週間の短い反復（スプリント）を繰り返しながら段階的に開発する手法」です。ラグビーのスクラムに由来する名前で、チームが密接に連携しながら開発を進めることを意味します。野球のシーズンに例えましょう。長い試合期間（長期プロジェクト）を毎試合ごとに振り返り・改善しながら戦うのがスクラムのイメージです。各スプリント終了時に動作するプロダクトのインクリメント（増分）を作り続け、変化する要求に柔軟に対応します。スクラムの役割はプロダクトオーナー（要求管理）・スクラムマスター（プロセス支援）・開発チーム（実装）です。誤答の「ウォーターフォール開発の一種」は設計→実装→テストを順次進める別の開発モデル、「テスト自動化のフレームワーク」「プロジェクト管理の国際標準」もスクラムの説明ではありません！

📝 解説

プロジェクトのスコープとは「プロジェクトで達成すべき目標・成果物と、実施する作業の範囲」のことです。家のリフォーム工事に例えましょう。「1階のリビングと台所を改装する契約」を結んだのに施工業者が勝手に2階まで工事したり、逆に換気扇の取り付けを忘れたりすることが問題になりますね。スコープを明確に定義・合意することで「何をやるか・何をやらないか」の境界線が明確になります。スコープが曖昧だと途中でどんどん要求が追加される「スコープクリープ（範囲の無秩序な拡大）」が起きて、コスト超過・納期遅延の原因になります。誤答の「プロジェクトの予算」はコスト管理、「プロジェクトのスケジュール」はスケジュール管理、「プロジェクトのリスク」はリスク管理でそれぞれ別の管理領域です！

📝 解説

コストベネフィット分析（費用便益分析）とは「投資・施策のコストと期待される効果・ベネフィット（便益）を定量的に比較して、投資の妥当性を判断する手法」です。新幹線の新路線建設で例えましょう。「建設費3000億円かかるが、開通後30年間で旅行者増加・物流効率化・雇用創出で5000億円の経済効果が見込まれる」ならベネフィット＞コストで投資判断はGoとなります。ITシステム投資でも同様に「開発コスト5000万円に対し、業務効率化で年間1500万円削減できれば約3.3年で回収できる」という計算をします。費用対効果（ROI：投資対効果）とも密接に関連します。誤答の「プロジェクトのリスクを分析すること」はリスク分析、「市場のコストを調査すること」はコスト調査、「品質とコストのバランスを分析すること」はQCDのバランス分析の話です！

📝 解説

ITガバナンスとは「経営戦略と整合したIT活用を実現するため、組織全体のIT投資・リスク・資源を方向付け・統制する仕組み」です。鉄道会社の経営と路線網の整備に例えましょう。鉄道会社の経営トップが「地方路線の収益性・安全への投資・将来の新路線計画」を経営戦略と整合させながら意思決定・統制することがITガバナンスに相当します。ITガバナンスは単なる「IT部門の管理」ではなく経営層が主体となる活動で、COBITという国際フレームワークがよく使われます。CIOやIT委員会が担う経営レベルの仕組みです。誤答の「ITシステムの運用管理」はITサービスマネジメント（ITSM）、「ITシステムの開発管理」はシステム開発管理、「IT部門の人事管理」は人事管理の話です。ガバナンス（統治）は経営層が主体という点が重要です！

📝 解説

V字モデルとは「左側に開発工程（要件定義→システム設計→詳細設計→実装）、右側に対応するテスト工程（単体テスト→結合テスト→システムテスト→受入テスト）をV字形に対応させた開発モデル」です。折り紙に例えましょう。紙を折って（設計・実装）元の形に戻す（テスト・確認）とき、折ったのと逆の順番で開くとピッタリ戻りますね。V字モデルも同様に、左側の各開発フェーズに対して右側の対応するテストがきちんと対になっている点が特徴です。要件定義↔受入テスト・システム設計↔システムテスト・詳細設計↔結合テスト・実装↔単体テストという対応関係を持ちます。誤答の「V字型の組織でシステムを開発する」「5つのフェーズで構成される」「仮想化を使った開発モデル」はいずれもV字モデルの正確な説明ではありません！

📝 解説

マイルストーンとは「プロジェクトの進捗において、特に重要な節目となる中間目標の達成日や成果物の提出日」のことです。道路や鉄道の里程標（マイルストーン）が語源で、「あと何マイルで目的地か」を示す標識です。長距離マラソンに例えると、42.195kmのフルマラソンでも5km・10km・20km・30km・折り返し地点などの「チェックポイント」を設定して進捗を管理しますね。プロジェクトでもマイルストーンを設定することで「設計完了予定日」「テスト開始日」「ユーザー受入完了日」などの節目で遅延を早期に検知できます。ガントチャートではひし形で表示されます。誤答の「プロジェクトの最終完了日」は最終マイルストーンの一つですが、マイルストーン全体の定義としては不十分です。「予算の節目」「人員配置の時期」はマイルストーンの定義ではありません！

📝 解説

ファンクションポイント（FP）法とは「システムの機能の数と複雑さからシステム規模を見積もる手法」で、プログラミング言語に依存しない点が特徴です。建物の床面積に例えましょう。建物の大きさを「何平方メートルか」で表すとき、内装の仕上げ素材（プログラミング言語）が何であれ床面積は変わりませんね。同様にFP法では外部入力・外部出力・内部論理ファイル・外部インターフェース・外部照会という5種類の機能の数と複雑さ（単純・標準・複雑）からシステム規模を計算します。言語に依存しないため異なるシステム間の規模比較や、開発生産性（FP/人月）の測定に活用できます。誤答の「開発者の人数でコストを見積もる」は人月ベースの見積もり、「過去のプロジェクトの実績から見積もる」は類推見積もり（アナロジー法）、「コードの行数から見積もる」はLOC（Lines of Code）法の説明です！