基本情報技術者 ― マネジメント系 問題一覧・解説

📝 解説

要件定義はシステム開発の最上流工程で「ユーザーや関係者のニーズ・業務課題を整理し、作るべきシステムの目的・機能・非機能要件を明確にする」作業です。家の建築で例えると、設計図を引く前に「どんな家に住みたいか」「何部屋必要か」「予算は」「バリアフリーにするか」を施主とヒアリングして確定する段階がまさに要件定義です。機能要件（何ができるか）と非機能要件（性能・セキュリティ・可用性等）の両方を定義します。要件定義が不十分なまま開発が進むと、完成後に「こんなものは作ってほしくなかった」となる手戻りコストが最大になります。誤答の「詳細設計」は要件定義の次の工程、「プログラムを実装する」はさらに後の工程、「テストを行う」は完成確認の工程です。「要件定義＝何を作るか（WHAT）を明確にする最上流工程」と押さえましょう！

📝 解説

結合テスト（統合テスト）は「個々のモジュール単体の動作確認（単体テスト）が終わった後に、複数のモジュールを実際に組み合わせたときのインターフェースと連携動作を確認する」テスト工程です。電車の連結に例えると、各車両（モジュール）が単独で問題なく走ることを確認した後、車両同士をつなげたとき「ドアの連動は正しいか」「電気信号は正しく伝わるか」を確認する作業です。呼び出す側と呼ばれる側のデータの受け渡し（インターフェース）が正しいか、複数モジュールが協調して期待通りに動くかを検証します。テストのV字モデルでは詳細設計に対応します。誤答の「個々のモジュールの動作確認」は単体テスト（ユニットテスト）、「ユーザ要件を満たすか確認する」はシステムテスト・受入テスト、「性能・負荷耐性を確認する」は性能テストの説明です。「結合テスト＝モジュール連携・インターフェースを確認する工程」と覚えましょう！

📝 解説

ホワイトボックステストは「プログラムのソースコード（内部構造・制御フロー・条件分岐・ループ）を把握したうえで、コードのすべての経路が正しく動くかを確認する」テスト手法です。電気回路の検査に例えると、回路図を手元に持ちながら「この経路で電流が正しく流れるか」「このスイッチがOFFのときどうなるか」と回路ごとに確認する作業と同じです。機械の内部構造が透けて見える「透明な（ホワイト）箱」のように、中身を見ながらテストするイメージです。命令網羅（C0）・分岐網羅（C1）・条件網羅などのカバレッジ（網羅率）基準があります。対照的なブラックボックステストは内部構造を見ずに入出力だけでテストする手法です。誤答の「入出力のみでテストする手法」はブラックボックステスト、「ユーザの視点でテストする手法」は受入テストの説明です。「ホワイトボックス＝コード内部を見ながらテストする手法」と覚えましょう！

📝 解説

コードレビューは「開発者が書いたコードを1人以上の他の開発者が確認し、バグ・設計上の問題・可読性の低下・セキュリティリスクを早期に発見・修正する」品質保証活動です。製造業のダブルチェックに例えると、重要な製品の検品を複数人で確認することで見落としをなくす取り組みと同じ発想です。コードレビューの効果は、バグを開発段階の早い時点で発見できる（後工程で発見するより修正コストが低い）・設計の改善点を指摘できる・チーム全員がコードを把握し属人化を防げる・若手エンジニアの育成にもなる、という多くのメリットがあります。GitHubのPull RequestやGitLabのMerge Requestを使ったレビューが現代の標準的なプラクティスです。誤答の「コードを自動実行する」は継続的インテグレーション（CI）の話で、「コードを暗号化する」「バックアップを取る」はセキュリティ・運用の話です。「コードレビュー＝複数人で確認して品質・知識共有を高める活動」と押さえましょう！

📝 解説

リファクタリングは「プログラムの外部から見た動作（機能・出力）を一切変えずに、内部のコード構造（可読性・設計品質・保守性）を改善する」作業です。部屋の模様替えに例えると、部屋でできること（料理・睡眠・仕事）は変わらないまま、家具の配置を使いやすく整理整頓する作業がリファクタリングです。長年継ぎ足してきたコードは「スパゲッティコード」と呼ばれる複雑な状態になりやすく、リファクタリングによって重複の排除・命名の改善・メソッドの分割などを行います。重要なのは「リファクタリング前にテストを用意する」こと。テストが通り続けることで動作が変わっていないことを保証しながら改善できます。誤答の「機能を追加すること」は機能開発、「バグを修正すること」はデバッグ、「テストを自動化すること」はCI/CD構築の話です。「リファクタリング＝動作を変えずに内部構造を改善する作業」と理解しましょう！

📝 解説

ソフトウェア保守には4種類あり、「適応保守」は「OSのバージョンアップ・ハードウェアの更改・外部システムの仕様変更など、動作環境の変化にソフトウェアを対応させる」保守です。建物の耐震改修に例えると、建物自体に問題はなくても新しい耐震基準（環境変化）に対応するために補強工事（適応保守）を行うイメージです。4種類の保守の区別が試験頻出です：是正保守（Corrective）＝バグ修正、適応保守（Adaptive）＝環境変化への対応、完全化保守（Perfective）＝機能追加・性能改善、予防保守（Preventive）＝将来の問題防止のための改善。Windows 11への移行に伴いアプリを修正する作業が典型的な適応保守です。誤答の「バグを修正する保守」は是正保守、「機能を追加・改善するための保守」は完全化保守、「将来の変更に備えてコードを改善する保守」は予防保守の説明です。「適応保守＝OSやHWなど環境変化への対応」と覚えましょう！

📝 解説

EVM（アーンドバリューマネジメント）のEV（Earned Value：アーンドバリュー）は「実際に完了した作業が、計画上いくらの予算価値を持つか」を示す指標です。工事の進捗管理に例えると、1億円のビル建設で基礎工事・外壁工事・内装工事が完了した場合、それらの工事の計画予算額の合計がEVです。実際にかかったお金（AC：Actual Cost）ではなく「完了した仕事の計画値」である点がポイントです。EVMの3指標の整理：PV（Planned Value）＝この時点までに完了しているはずの計画予算値、EV＝実際に完了した作業の計画予算値、AC＝実際にかかったコスト。CV（コスト差異）＝EV－ACでコスト効率を、SV（スケジュール差異）＝EV－PVで進捗を数値化できます。誤答の「実際にかかったコスト」はAC、「計画上完了しているはずの作業の予算値」はPVの説明です。「EV＝完了した仕事の計画コスト（価値）」と確実に覚えましょう！

📝 解説

ステークホルダーマネジメントは「プロジェクトに関係するすべての人や組織（顧客・スポンサー・開発チーム・ベンダー等）の期待・関心・影響力を把握し、適切なコミュニケーションと対応を継続的に行う」プロセスです。お祭りの実行委員会に例えると、地元住民・商店街・自治体・ボランティアスタッフ・警察など立場と関心事が異なる関係者全員の期待を把握して調整することがステークホルダーマネジメントです。重要なのはステークホルダー登録簿を作り各人の関与度・影響力・期待を整理し、「誰に・何を・いつ・どのように」コミュニケーションするかを計画することです。影響力の大きいステークホルダーの期待とズレが生じるとプロジェクトが危機に陥ることもあります。誤答の「予算管理」はコストマネジメント、「スケジュール管理」はスケジュールマネジメント、「リスク管理」はリスクマネジメントの領域です。「ステークホルダー管理＝関係者の期待・影響力を把握して適切に対応する」と覚えましょう！

📝 解説

ソフトウェア品質特性のうち「保守性（Maintainability）」は「ソフトウェアを修正・変更・テストしやすい度合い」を示す品質特性です。古い家のリフォームに例えると、配管や配線が整然と設計されている家は修繕しやすく、継ぎ足し工事で配管がぐちゃぐちゃになっている家はリフォームが難しいですよね。この「修繕・変更のしやすさ」がソフトウェアにおける保守性です。保守性のサブ特性として、解析性（問題箇所を特定しやすいか）・変更容易性（変更を加えやすいか）・安定性（変更による副作用が小さいか）・試験性（テストしやすいか）があります（ISO/IEC 25010）。コードの可読性・モジュール性・適切なコメントが保守性を高めます。誤答の「必要なときにシステムを利用できること」は可用性・信頼性の特性、「機能が正しく動作すること」は機能適合性、「セキュリティが保たれていること」はセキュリティの品質特性の説明です。「保守性＝修正・変更・テストのしやすさ」と覚えましょう！

📝 解説

受入テスト（ユーザー受入テスト：UAT）は「発注者・実際のエンドユーザーがシステムを実際の業務シナリオで使用し、要件定義で定めた業務要件を満たしているかを最終確認する」テスト工程です。製品の最終品質チェックに例えると、工場（開発チーム）が自社検査を終えた後、最終的に購入者（ユーザー・発注者）が「自分の使いたい目的に合っているか」を確認する最終チェックがまさに受入テストです。V字モデルでは最上流の要件定義に対応するテストです。テストに合格（受入）すれば本番稼動へ進み、不合格なら是正を求めます。受入テストを実施する主体は「発注者・ユーザー」であることが最重要ポイントです。誤答の「開発チーム」が実施するのは単体・結合・システムテスト、「テスト専門チーム」は品質保証部門等が担当する場合がありますが受入テストの主体ではありません。「受入テスト＝発注者・ユーザーが業務要件を満たすかを最終確認する工程」と確実に押さえましょう！

📝 解説

プロジェクトの三大制約（トリプルコンストレイント）は「スコープ（作業範囲・成果物の内容）・スケジュール（期間・納期）・コスト（予算）」の3つです。引越しの計画に例えると、「どこまで片付けるか（スコープ）」「いつまでに引越すか（スケジュール）」「いくら使えるか（コスト）」の3つはトレードオフの関係にあります。引越し範囲を広げれば時間やお金がかかり、コストを削れば時間がかかったり作業範囲を縮めざるを得ません。PMBOKでは「品質」もこの制約に含めて4制約と呼ぶこともあります。スコープクリープ（スコープの際限ない拡大）はスケジュール・コストを直撃するため、スコープ変更管理（変更管理プロセス）が重要です。誤答の「品質・コスト・リスク」のうちリスクは三大制約には含まれません。「人・物・金」は経営資源の3要素、「計画・実行・評価」はPDCAサイクルの話です。「三大制約＝スコープ・スケジュール・コストのトレードオフ」と確実に覚えましょう！

📝 解説

コンティンジェンシー計画（Contingency Plan）は「識別したリスクが実際に発生した場合に、どのような対応をとるかをあらかじめ定めておく対応計画」です。防災の避難計画に例えると、大地震が発生した際に「誰がどこへ避難するか」「連絡はどの手段を使うか」「重要書類はどこに保管するか」を事前に決めておくことがコンティンジェンシー計画の発想と同じです。リスクが現実になったとき、計画なしに対応しようとすると判断の遅れ・混乱・コスト増が発生します。あらかじめ「もしXが起きたらYをする」と定めておくことで、迅速かつ適切な対応が可能になります。リスク対応戦略の1つであるリスク受容（Acceptance）と組み合わせて使われます。誤答の「プロジェクトの標準的な実行計画」はプロジェクト計画書、「コスト削減のための計画」はコスト最適化施策、「品質向上のための計画」は品質マネジメント計画の話です。「コンティンジェンシー計画＝リスク発生時の対応を事前に定めた備えの計画」と覚えましょう！

📝 解説

プロジェクト完了報告書は「プロジェクトが終了したときに、目標達成状況・成果物・コスト・スケジュールの実績と計画の差異・発生した問題と対応策・教訓（レッスンズラーンド）を記録・共有するための文書」です。1年の振り返り日記に例えると、その年の出来事・達成したこと・失敗したこと・来年への教訓をまとめる「総括」がプロジェクト完了報告書の役割です。特に「レッスンズラーンド（教訓）」は将来のプロジェクトに活かすための組織の知識財産として重要です。完了報告書には「どんな成果物を作ったか」「当初計画との差はどんなものだったか」「なぜそうなったか・どう対処したか」「次はどうすべきか」が含まれます。「次のプロジェクトの予算計画」は完了報告書ではなく次のプロジェクトの計画書に書くべき内容で、完了報告書に含まれる内容として適切ではありません。他の3選択肢（目標達成状況・発生した問題と対応策・教訓）はすべて完了報告書の標準的な内容です。「プロジェクト完了報告書＝実績・教訓を記録して将来に活かす文書」と覚えましょう！

📝 解説

品質マネジメントにおける「品質計画（Quality Planning）」は「プロジェクトに適用する品質基準を特定し、その基準をどのように達成・実証するかの方針・手順を計画する」プロセスです。建築の工事品質管理に例えると、着工前に「このビルはどの強度基準・工法で建てるか」「品質検査はどの工程でどのように行うか」を計画することが品質計画です。「何をもって合格とするか」の基準（品質メトリクス）と「どう確認するか」の方法を両方定めます。品質マネジメントの3プロセス：品質計画（何の基準をどう達成するか計画）→品質保証QA（計画通りのプロセスが実行されているか監査）→品質管理QC（成果物が基準を満たしているか検査）という流れです。誤答の「品質の問題を修正する」はデバッグ・是正処置、「品質を検査する」は品質管理（QC）の活動、「品質コストを削減する」は品質計画の目的ではありません。「品質計画＝どの品質基準をどう達成するかを事前に定める計画プロセス」と覚えましょう！

📝 解説

ITSMの「問題管理（Problem Management）」は「インシデント（障害）の根本原因を特定・分析し、恒久的な解決策を実施して同じ問題の再発を防止する」プロセスです。工場の設備故障管理に例えると、機械が止まったとき「とりあえず再起動して動かす（インシデント管理）」だけでなく、「なぜ止まったかを解析し、摩耗した部品を特定して交換・再発防止策を実施する（問題管理）」まで行うことで根本的な改善につながります。ITILにおけるインシデント管理と問題管理の違いが重要です：インシデント管理＝サービスをできるだけ速く復旧させることが目的（暫定対応）、問題管理＝根本原因の特定と恒久対策の実施が目的（根本解決）。問題管理では「既知のエラー（Known Error）」として記録し、ワークアラウンド（回避策）を整備します。誤答の「インシデントを素早く解決する」はインシデント管理の目的で、問題管理は速さより根本解決を重視します。「問題管理＝インシデントの根本原因を特定して再発防止する」と覚えましょう！

📝 解説

類推見積り（アナロジー見積り）は「過去に完了した類似プロジェクトの実績データ（工数・コスト・期間）をもとに、新プロジェクトの規模・工数・コストを推定する見積り手法」です。引越し業者の見積りに例えると、「以前に同じような間取り・距離の引越しは約△万円だったから、今回もそのくらいかな」という経験則による見積りが類推見積りと同じ発想です。トップダウン見積りとも呼ばれ、詳細が不明な初期段階での概算に向いています。正確性は専門家が持つ過去データの質と量に依存し、類似していない案件に適用すると精度が落ちます。見積り手法の区別：類推見積り（過去の類似実績から推定）・パラメトリック見積り（統計モデルで計算）・ボトムアップ見積り（作業を細分化して積み上げ）・ファンクションポイント法（機能規模から算出）。誤答の「機能の数からコストを算出する」はファンクションポイント法、「コードの行数からコスト算出」はLOC見積りの説明です。「類推見積り＝過去の類似プロジェクト実績を参考にした概算見積り」と覚えましょう！

📝 解説

ペアプログラミング（Pair Programming）は「2人の開発者が1台のコンピュータを共有し、1人がコードを書くドライバー（Driver）、もう1人がリアルタイムでレビュー・方針を示すナビゲーター（Navigator）の役割を担いながら開発する手法」です。自動車のレースに例えると、ドライバーがハンドルを握って実際に走行し、ナビゲーターが地図を確認しながら「次は左！スピードアップ！」と指示することで1人よりもはるかに正確かつ効率的に走れる関係がペアプログラミングのイメージです。XP（エクストリームプログラミング）のプラクティスの1つで、効果としてバグの即時発見・設計の改善・知識共有の促進・コードオーナーシップの均等化が挙げられます。定期的にドライバーとナビゲーターを交代することで知識の偏りを防ぎます。誤答の「2チームが同じ機能を並行して開発する」はA/Bテスト開発等の話、「先輩が後輩にプログラミングを教える」はメンタリング・OJTの話です。「ペアプログラミング＝2人で1台をドライバーとナビゲーターで担当する開発手法」と覚えましょう！

📝 解説

ITILの「構成管理（Configuration Management）」は「ITサービスを構成するすべての要素（CI：Configuration Item）を識別・記録・管理し、その情報をCMDB（構成管理データベース）で一元管理する」プロセスです。電力網の設備台帳管理に例えると、電力会社は「どこにどんな変電所・電柱・ケーブルがあるか」を正確に把握していないと障害対応も設備更新も的確にできません。同様にITインフラでもサーバ・ネットワーク機器・ソフトウェア・仮想マシン・クラウドリソースなどのCI（構成品目）をCMDBで一元管理することで「何がどこにあり、どうつながっているか」を即座に把握できます。変更管理・インシデント管理・問題管理など他のITILプロセスも構成管理の情報を活用します。誤答の「組織の構造を管理する」は組織マネジメント、「ソフトウェアのバージョンを管理する」はバージョン管理（Git等）、「プロジェクトの組織体制を管理する」は人的資源管理の話です。「構成管理＝ITインフラのCI（構成品目）をCMDBで一元把握・管理するプロセス」と覚えましょう！

📝 解説

サービスデスクの設置形態のうち「中央集中型（Centralized Service Desk）」は「物理的に1か所にサービスデスクを集約し、そこで組織全体のユーザーからの問い合わせを一元的に受け付ける形態」です。コールセンターに例えると、全国のお客様からの電話を1か所のコールセンターに集中して受け付けるイメージです。メリットは専門スタッフを集約できる・ナレッジ共有が容易・コスト効率が良いことです。デメリットは各拠点のユーザーにとって距離が遠く、ローカルな業務への対応が弱くなることです。サービスデスクの4形態の区別：中央集中型（1か所に集約）、ローカル型（各拠点に独立して設置）、バーチャル型（地理的に分散したチームが仮想的に1つのデスクとして機能）、フォローザサン（世界の時差を利用して24時間対応）。大企業のITサポートでは中央集中型とローカル型を組み合わせるハイブリッド形態も多く見られます。誤答の「各拠点に独立したサービスデスクを設置する」はローカル型の説明です。「中央集中型＝1か所に集約して全社一元対応するサービスデスク形態」と覚えましょう！

📝 解説

ソフトウェアのテストで使う「スタブ（Stub）」は「テスト対象モジュールが呼び出す下位モジュール（従属モジュール）の代わりとして使う仮のモジュール」です。演劇の代役に例えると、主役（テスト対象）のシーンを練習するとき、共演する脇役（下位モジュール）の俳優がまだいなくてもセリフを持った代役スタッフを使って練習を進める仕組みがスタブのイメージです。スタブはあらかじめ決めたデータを返すだけのシンプルな仮実装で、下位モジュールの完成を待たずにテストを進められます。ドライバー（Driver）と混同されやすいので整理します：スタブは「テスト対象から呼ばれる下位モジュールの代替」、ドライバーは「テスト対象を呼び出す上位モジュールの代替」です。テスト方式との対応：トップダウンテスト（上位から順に統合テスト）ではスタブが必要、ボトムアップテスト（下位から統合テスト）ではドライバーが必要です。誤答の「テスト対象モジュールを呼び出す仮のモジュール」はドライバーの説明です。「スタブ＝テスト対象が呼び出す下位モジュールの代替仮実装」と確実に覚えましょう！

📝 解説

CD（Continuous Delivery/Deployment：継続的デリバリー/デプロイ）は「CI（継続的インテグレーション）でテストが通ったコードをいつでも本番リリースできる状態に保つ（Delivery）、または自動的に本番環境へデプロイする（Deployment）」実践手法です。コンビニの物流に例えると、商品を工場で作り終えたら（CI＝ビルド・テスト完了）、いつでも棚に並べられる準備状態にしておく（Continuous Delivery）か、自動的にすぐ棚に陳列する（Continuous Deployment）のがCDのイメージです。CD（Delivery）は「人の判断でリリースするかを決める」のに対し、CD（Deployment）は「テスト通過後に全自動で本番反映する」点が異なります。CI/CDパイプラインとして「コミット→自動テスト→自動デプロイ→モニタリング」という一連の流れを整備することで、リリース頻度を高め品質を保ちながら継続的に価値を届けられます。誤答の「毎日同じ時間にシステムを更新すること」「定期的にバックアップを取ること」は全く別の話です。「CD＝テスト通過後に本番リリースできる状態を常に保つ・または自動デプロイする実践手法」と覚えましょう！

📝 解説

IaC（Infrastructure as Code：インフラストラクチャ as コード）は「サーバ・ネットワーク・クラウドリソースなどのインフラ構成をコード（テキストファイル）として定義・管理する手法」です。建物の設計図に例えると、従来の手作業インフラ構築は「現場で職人が経験と勘で工事する」スタイルなら、IaCは「完全な設計図（コード）があれば誰が何度実行しても全く同じ建物が再現できる」スタイルです。Terraform（クラウドインフラ定義）・Ansible（構成管理・設定自動化）・CloudFormation（AWS専用）が代表的なIaCツールです。IaCの主なメリットは①環境の再現性（同じコードを実行すれば常に同じ環境が作れる）②変更管理（Gitでコード管理できる）③自動化（手作業ミスをなくせる）④ドキュメント化（コードが仕様書になる）の4点です。誤答の「インフラの費用をコードで管理する」は財務管理の話、「インフラ担当者がコードを書く役割を担う」は職種の話です。「IaC＝インフラをコードで定義・再現性・自動化・バージョン管理が可能になる手法」と覚えましょう！

📝 解説

「ウォークスルー（Walkthrough）」は「成果物の作成者自身が参加者に成果物を順に説明・案内しながら、問題点・誤り・改善点を一緒に発見するレビュー手法」です。マンションの内覧に例えると、物件の担当者（作成者）がお客様（参加者）を実際に部屋を歩きながら案内し、「ここが気になる」「この仕様はどうか」と一緒に確認していく作業がウォークスルーのイメージです。特徴はフォーマル（形式的）なインスペクションより気軽に実施できる・作成者が主体的に説明するため理解が深まる・チーム全員が成果物を把握できるという点です。ソフトウェア開発では設計書・コード・テスト仕様書などを対象に行います。インスペクション（最も形式的：事前準備・役割分担・指摘記録・再レビューあり）やピアレビュー（同僚間のカジュアルなレビュー）との違いも試験に出ます。誤答の「ソースコードを自動で検査するツール」は静的解析ツール、「テスト担当者が実際に操作して確認する手法」はユーザーテストや受入テストの説明です。「ウォークスルー＝作成者が成果物を説明しながら問題点を発見するカジュアルなレビュー手法」と覚えましょう！

📝 解説

システム移行リハーサルは「本番移行の前に、移行手順・ツール・タイミングを実際に練習して問題点を事前に発見し、本番移行の成功率を高める」作業です。飛行機のフライトシミュレーターに例えると、パイロットが実際に離着陸する前にシミュレーターで様々な異常事態を練習するように、システム移行も本番前にリハーサルで「手順通りに移行できるか」「何分かかるか」「問題が起きたらどうロールバックするか」を確認します。リハーサルで確認する主な内容は①移行手順の正確性と所要時間の計測②手順書の誤り・抜けの発見③バックアップとロールバック手順の確認④担当者間の役割分担と連絡手順の確認です。基幹系システムの移行では週末・深夜などの限られた時間内に完了させる必要があるため、時間内に収まるかの確認も重要です。誤答の「新システムの機能を確認する」はシステムテスト（移行前に済んでいる）、「ユーザへの操作説明を行う」はユーザー研修、「移行コストを算出する」は計画段階の作業です。「移行リハーサル＝本番移行の手順・問題点を事前確認して成功率を高める練習」と覚えましょう！