【ITパスポート練習問題 6.3対応】22.システム化計画

【解説】

正解: 2 システム化基本方針の立案

この問題は、システム開発の初期段階である「システム化計画」で実施すべき内容と、開発後の運用や保守などの段階で実施すべき内容を区別できているかを確認するものです。

正解である「システム化基本方針の立案」は、システム化計画プロセスの核心となる活動です。ここでは、新システムを導入する目的、対象となる業務範囲、期待される効果、概算スケジュールなど、プロジェクト全体の指針となる「基本方針」を決定します。これがないと、具体的な開発に進むことができません。

一方、選択肢1の「システム導入後の保守体制構築」は、システムが完成して稼働した後の話であり、運用プロセスに含まれます。また、選択肢3の「ユーザートレーニングの計画作成」も、システムの仕様が固まり、導入が近づいた段階で行う移行プロセスの活動です。これらは計画の初期段階であるシステム化計画の主たるプロセスではありません。

【解説】

正解: 2 システムの具体的な操作手順の決定

この問題は、「システム化計画」という上流工程で決めるべきことと、詳細設計や運用設計で決めるべき細かい内容の違いを理解しているかを問うものです。

正解の「システムの具体的な操作手順の決定」は、システム化計画の目的として適切ではありません。計画段階では「どのようなシステムを作るか」「いくらかけるか」といった全体像を決めますが、具体的な画面の操作方法やマニュアルレベルの手順は、もっと後の設計工程やマニュアル作成段階で決定されるからです。

選択肢1の「システム導入による業務効率化の実現」は、システム化の主要な目的そのものです。選択肢3の「システム化に必要なコストや効果の分析」も、投資の価値があるかを判断するために計画段階で必ず行わなければならない重要な目的です。

【解説】

正解: 1 作業依存関係の整理とリソース管理

この問題は、プロジェクトマネジメントにおける「スケジュール管理」が何のために行われるのか、その本質的な役割を理解しているかを確認するものです。

スケジュール管理の適切な目的は、選択肢1の「作業依存関係の整理とリソース管理」です。システム開発には多くの作業があり、ある作業が終わらないと次が始められないといった「依存関係」が存在します。これらを整理し、誰がどの作業を担当するか（リソース）を適切に配分することで、期限内にプロジェクトを完了させることが目的となります。

選択肢2の「プロジェクト終了後の業務評価」は、プロジェクト完了後のレビュー活動であり、進行中のスケジュール管理とは異なります。選択肢3の「作業の具体的手順の作成」は、スケジュール（いつやるか）ではなく、作業マニュアル（どうやるか）の話であり、管理の目的が異なります。

【解説】

正解: 3 完了したプロジェクトの成功要因分析

この問題は、これからのプロジェクトのスケジュールを作成する際に、「直接的に必要な情報」と「参考情報」を区別できるかを問うものです。

正解は3です。「完了したプロジェクトの成功要因分析」は、今後の改善には役立つ参考情報ですが、現在計画している特定のプロジェクトのスケジュール表を作成するための直接的な構成要素（タスクや日付など）ではありません。

選択肢1の「作業の開始時期と終了時期」や、選択肢2の「作業の依存関係（Aが終わらないとBができない等）」は、スケジュールを作成し、工程表（ガントチャートなど）を描くために不可欠な要素です。これらがなければスケジュール自体が成立しません。

【解説】

正解: 1 関係者間の責任分担を明確にする

この問題は、システム開発プロジェクトにおける「体制設計」の意義について理解しているかを確認するものです。

正解は1の「関係者間の責任分担を明確にする」です。体制設計とは、プロジェクトマネージャ、開発チーム、ユーザ部門などの各担当者がどのような役割と責任を持つかを定義することです。これにより、意思決定のルートやトラブル時の対応者が明確になり、プロジェクトが円滑に進みます。

選択肢2の「システム導入後の運用計画を立案する」は運用プロセスの話であり、体制設計（組織図や役割定義）そのものではありません。選択肢3の「データの具体的な入力形式を決定する」は、詳細設計などの技術的な作業であり、体制の設計とは異なります。

【解説】

正解: 1 各メンバーのスキルセット

この問題は、プロジェクトチームを編成する際（体制設計時）に、何を基準に人員配置を考えるべきかという実務的な視点を問うものです。

正解は1の「各メンバーのスキルセット」です。体制を組む際は、必要な技術力や業務知識を持ったメンバーを適切な場所に配置する必要があります。そのため、各メンバーがどのようなスキルや経験を持っているかを優先的に検討し、不足があれば外部から調達するなどの対策を講じます。

選択肢2の「システム運用後のメンテナンス方針」や、選択肢3の「システムのデータ入力作業」は、体制が決まった後にそのメンバーたちが検討・実行する内容であり、体制を設計する段階での最優先検討事項ではありません。

【解説】

正解: 3 予定されたリスクをすべて実行に移す

この問題は、プロジェクトマネジメントにおける「リスク管理（リスク分析）」の意味を正しく理解しているかを確認するものです。

正解は3です。「予定されたリスクをすべて実行に移す」ことはリスク分析の目的として不適切です。リスクとは「発生すると困ること」であり、分析の目的はそれを避けることや影響を小さくすることです。リスクをあえて実行することはありません。

選択肢1の「プロジェクトの潜在的な障害を特定する」ことはリスクの「特定」にあたり、選択肢2の「リスクを未然に防ぐための対策を立てる」ことはリスクへの「対応」にあたります。これらはどちらもリスク分析の重要な目的です。

【解説】

正解: 3 システム稼働後の市場分析

この問題は、システム化計画というプロジェクト計画の段階で考慮すべき「プロジェクトリスク」の範囲を理解しているかを問うものです。

正解は3の「システム稼働後の市場分析」です。システム化計画におけるリスク分析は、主に「システムを無事に完成させ、導入するまで」の障害要因（納期遅延、予算超過、品質不足など）に焦点を当てます。稼働後の市場動向や競合分析は経営戦略やマーケティングの話であり、システム開発プロジェクトの完遂に向けたリスク要因とは区別されます。

選択肢1の「プロジェクトメンバーの経験不足」や、選択肢2の「システムの利用者トレーニング不足」は、システム開発の遅延や稼働直後のトラブルに直結するため、計画段階で対策すべき重要なリスク要因に含まれます。

【解説】

正解: 3 利用者の作業時間削減に伴う個人の満足度

この問題は、企業がシステム投資を行う際に行う「費用対効果（ROI）分析」において、定量的（数値化できる）評価と定性的（数値化しにくい）評価の違いを理解しているかを問うものです。

正解は3です。費用対効果の分析では、基本的に金額に換算できる要素で比較を行います。個人の「満足度」といった主観的な感情は、数値化して投資回収の計算に組み込むことが難しいため、費用対効果の直接的な計算項目としては不適切とされます（別途、定性効果として評価されることはあります）。

選択肢1の「システム導入後の運用コスト（ランニングコスト）」や、選択肢2の「初期投資額（イニシャルコスト）」は、明確に金額として算出できるため、費用対効果を評価するための必須項目です。

【解説】

正解: 2 システム導入の妥当性を判断するため

この問題は、なぜシステム化計画の段階で費用対効果を計算する必要があるのか、その経営的な理由を理解しているかを確認するものです。

正解は2の「システム導入の妥当性を判断するため」です。企業活動において、システム導入には多額の資金が必要です。その投資に見合うだけの利益やコスト削減効果が得られるかを事前にシミュレーションし、プロジェクトを実施すべきかどうか（GO/NO-GO）を経営判断するために行われます。

選択肢1の「投資額の削減を確定するため」は、コスト見積もりの精査の話であり、効果との対比ではありません。選択肢3の「システム稼働後の利用者の満足度を把握するため」は導入後の評価であり、事前の計画段階で行う費用対効果分析の目的とは異なります。

【解説】

正解: 1 システムの導入効果を最大化する

この問題は、システム化の対象業務や範囲（スコープ）を決める際の基準や目的を理解しているかを問うものです。

正解は1の「システムの導入効果を最大化する」です。予算や期間には限りがあるため、すべての業務をシステム化することはできません。最も課題が大きく、システム化による改善効果が高い業務に絞って適用範囲を設定することで、投資に対する効果を最大化することが目的です。

選択肢2の「システム開発後の保守体制を構築する」は運用設計の目的です。選択肢3の「利用者の操作手順を統一する」は業務標準化の目的であり、適用範囲の設定そのものの目的とは異なります。

【解説】

正解: 3 関係者間で確認せずに決定する

この問題は、システム化の範囲（スコープ）を決定するプロセスにおいて、やってはいけない失敗行動（アンチパターン）を理解しているかを確認するものです。

正解は3の「関係者間で確認せずに決定する」です。システムの適用範囲は、実際に業務を行うユーザ部門や経営層の意向と一致している必要があります。合意形成なしに開発側だけで勝手に範囲を決めてしまうと、必要な機能が漏れたり、現場で使われないシステムになったりするリスクが高まります。

選択肢1の「業務範囲を包括的に捉える」ことや、選択肢2の「不必要な業務を対象外とする」ことは、適切なスコープ設定を行うために必要な分析プロセスであり、避けるべき行動ではありません。

【解説】

正解: 2 システムの具体的な運用手順の決定

この問題は、システム開発の最上流工程である「企画プロセス」の役割と範囲を理解しているかを問うものです。

正解の2「システムの具体的な運用手順の決定」は、企画プロセスに含まれません。企画プロセスでは「何を解決するためにシステムを作るか」という構想を練ります。具体的な運用手順（バックアップをいつ取るか、エラー時にどう操作するか等）は、もっと後のシステム設計や運用設計の段階で詳細を詰めるものです。

選択肢1の「業務課題の明確化」や、選択肢3の「解決策の検討と方針の策定」は、まさに企画プロセスの中心となる活動です。現状の課題を洗い出し、それをシステムでどう解決するかという方針を決めるのが企画プロセスの役割です。

【解説】

正解: 3 現状分析とシステム化の方針策定

この問題は、システム化の「企画プロセス」で具体的に何を行うか、その中心的なタスクを理解しているかを確認するものです。

正解は3の「現状分析とシステム化の方針策定」です。企画プロセスでは、まず現在の業務がどうなっているか（As-Is）を分析して問題点を見つけ、新システムでどうあるべきか（To-Be）という方針を策定します。これがシステム開発の出発点となります。

選択肢1の「システムの稼働状況のモニタリング」は、システムが完成した後の運用フェーズの活動です。選択肢2の「システム導入後のトレーニング計画の作成」も、導入・移行フェーズの詳細計画にあたるため、企画プロセスの主な活動ではありません。