ITパスポート 令和3年度 問22：システム戦略に関する問題

答えは a です。

システムを作るときは、料理と同じで「まず計画→何を作るか決める→作る→直しながら使う」という順番で進みます。

一番最初の「計画」の段階では、「どんな完成品（業務パッケージ＝市販のシステム）を買ってこようか？」を、機能・性能・値段で見比べて決めます（a）。これが計画の作業です。

👉 覚え方：計画＝「まず何を選ぶか・どう進めるか決める」最初の段取り。

ほかの選択肢：b は「ここまで追加で作ろう」と細かく決める（要件定義の作業）／d はパッケージに設定を入れる（開発の作業）／c は使い始めてから不具合を直す（保守の作業）。どれも計画より後の段階です。

なぜこれが正解か

正解は a。システム化計画プロセスは、システム化の方針・実現方法・全体像を決める上流工程。業務パッケージ活用なら、どのパッケージを採用するかを機能・性能・価格などの観点から評価・選定するのが計画段階の作業に該当する。

各選択肢の解説

• b：標準機能で不足する追加開発機能の範囲決定 → 何をどう作るかを具体化する要件定義プロセス。
• d：パッケージへのパラメタ設定（システム機能の実現） → 開発プロセス。
• c：運用中に発生した障害の分析・対応 → 稼働後の保守プロセス。

覚え方・ひっかけ注意

ライフサイクルは計画→要件定義→開発→保守の順。計画は「やるかどうか・何を採用するか」を大きく決める段階、要件定義は「具体的に何を満たすか」を決める段階。本問は『評価・選定（a）＝計画』『範囲決定（b）＝要件定義』の切り分けがポイント。

ソフトウェアライフサイクルと計画プロセスの位置づけ

情報システムのライフサイクルは共通フレーム（SLCP-JCF：Software Life Cycle Process-Japan Common Frame）（IPA策定・ISO/IEC 12207をベースに日本の実務に合わせたもの）で体系化される。ライフサイクルのプロセスは大きく企画プロセス→システム化計画プロセス→要件定義プロセス→開発プロセス→運用プロセス→保守プロセスに分類される。本問のシステム化計画プロセスは「システム化の目的・対象業務の範囲・実現方式（自社開発か業務パッケージか等）・概算費用・全体スケジュール・体制」を決定する工程。パッケージ採用の場合はRFI（Request for Information：情報提供依頼）・RFP（Request for Proposal：提案依頼書）を発行し、複数ベンダーの提案を機能適合率・カスタマイズ必要度・価格・保守体制・ベンダー信頼性等のクライテリアで評価・選定するのが計画段階の中核作業。

フィット＆ギャップ分析との関係

パッケージ採用後、標準機能（Fit）と業務要件のギャップ（Gap）を洗い出すフィット＆ギャップ分析は要件定義工程で行う。Gapに対しては①パッケージのアドオン（追加開発）、②業務プロセスの変更（ERP導入でよくある）、③別システムとの連携のいずれかで対処する。選択肢bの「追加開発機能の範囲決定」はこのフィット＆ギャップ分析の結果を受けて行う要件定義フェーズの作業で、計画と要件定義の境界線にある典型的なひっかけ。

保守の種類と実務

選択肢cの「障害の分析・対応」は是正保守（Corrective Maintenance）に当たる。保守は①是正保守（バグ修正）、②適応保守（OS/法改正等の環境変化への対応）、③完全化保守（性能向上・機能追加）、④予防保守（潜在問題の予防的修正）の4種類に分類される。実務では保守コストが開発コストの2〜4倍に達することも多く、ライフサイクルコスト全体で考えた意思決定が重要。

上位資格への接続

基本情報技術者では共通フレームの各プロセスの作業内容識別・RFP/RFI/RFQの違い・保守の4分類・TCO（総保有コスト）の概念が問われる。応用情報以上ではITガバナンス・調達マネジメント（公共調達・下請法・情報システム調達ガイドライン）との接続、SLA（サービスレベル合意）設計が出題される。

選択肢の発展補足

選択肢dのパラメタ設定はパッケージソフトの「カスタマイズ」の中でも最も軽微な「設定変更（コード変更なし）」で、開発フェーズの作業に分類される。パッケージ固有のパラメタは会計コード・組織コード・承認フロー等で、誤設定はシステム全体に影響するため、設定テスト（パラメタ確認テスト）が重要。選択肢cの保守における「障害の分析」はインシデント管理・問題管理（ITIL）の観点からは根本原因分析（RCA）に相当し、再発防止策の策定まで含む活動となる。