ITパスポート 2010年 春期 問12
問題文
ソフトウェアライフサイクルの主プロセスを、企画、要件定義、開発、運用、保守に分け、企画プロセスでシステム化計画の立案を行うとき、そこで実施する作業として、適切なものはどれか。
選択肢
ア:対象業務の業務内容やルール、制約などの業務要件を明らかにする。
イ:対象業務を確認・分析し、業務機能をモデル化する。(正解)
ウ:対象システムの機能及び能力、セキュリティなどのシステム要件を明らかにする。
エ:対象システムをテストするためのテスト仕様書を作成する。
🔒 解説は解答すると表示されます
ソフトウェアライフサイクルの企画プロセスで実施する作業はどれか【ITパスポート 解説】
正解の理由
企画プロセスは「システム化計画を立てる段階」です。ここで行うのは、対象となる業務を確認・分析して、システムで何を支援すべきかの大枠(業務機能)を整理することです。したがって、業務をモデル化して全体像を示す作業である イ が最も適切です。
ポイント:
- 企画は「何を作るか」「なぜ作るか」を決める段階です。
- 詳細な機能仕様やテスト仕様は後の工程で作成します(要件定義・開発・テスト段階)。
解法ステップ
- 問題文のキー語「企画プロセス」「システム化計画の立案」を確認する。
- 企画プロセスの目的を思い出す:「業務の把握」「導入の必要性や範囲決定」「全体構想の作成」など。
- 各選択肢を、企画で行う“高レベル(全体像)”の作業か、要件定義以降の“詳細設計・確認・検証”かで分類する。
- 高レベルの業務分析・モデル化に該当する選択肢を選ぶ。これが イ。
選択肢別の誤答解説
-
ア: 対象業務の業務内容やルール、制約などの業務要件を明らかにする。
→ これは業務の詳細要件を明確にする作業で、主に「要件定義」プロセスに該当します。企画ではまだ詳細までは詰めません。 -
イ: 対象業務を確認・分析し、業務機能をモデル化する。
→ 企画で行う「業務分析」と「モデル化(全体像作成)」に合致します。業務の流れや必要な機能を大まかに示すことで、システム化の方向性が決まります。 -
ウ: 対象システムの機能及び能力、セキュリティなどのシステム要件を明らかにする。
→ こちらは技術的・実装的な要件(システム要件)を詰める作業で、要件定義または基本設計の段階で行われます。企画より詳細です。 -
エ: 対象システムをテストするためのテスト仕様書を作成する。
→ テスト仕様書は開発後のテスト工程で作る成果物です。企画段階で作成するものではありません。
よくある誤解
-
企画=要件定義と混同する
- 企画は「やるべきことの全体像と実施可否の判断」をする段階です。要件定義はその後で「具体的にどのように動作するか」を決めます。混同すると詳細仕様を早期に詰めすぎて時間を無駄にします。
-
モデル化は図を描くだけと思う
- モデル化は図にすることが多いですが、本質は「業務を共通理解できる形にする」ことです。図だけでなく、業務フロー、現状の課題、期待される効果などを整理します。
-
セキュリティや性能は企画で決めてよい?
- 企画では「要求される大まかな非機能(例:可用性が重要)」を示すことはありますが、細かい数値(パフォーマンス要件、セキュリティ詳細)は要件定義で詰めます。
補足コラム
「業務機能をモデル化する」とは具体的に何をするか。よく使う手法例:
- 業務フロー図(どのような手順で仕事が進むかを図示)
- コンテキスト図(システムと外部とのやり取りを示す)
- 概要ユースケース(誰が何をするかの高レベルなまとまり)
これらで得られる成果物(アウトプット)の例:システム化計画書、現状と課題の整理、概念的な機能一覧、概算費用・効果の見積り。企画の成果物は、上流工程での判断材料(投資判断やスコープ決定)になります。
身近な例:会社の請求書処理を自動化したい場合、企画では現行の処理手順を整理し、どの工程を自動化すれば効果が高いかをモデル化します。どのボタンを押すとどうなるかといった詳細は後の工程で決めます。
FAQ
Q1: 企画段階で作る「モデル」はどの程度の詳細が必要ですか?
A1: 全体像がわかるレベルで十分です。関係者が「何を解決するのか」「どこまでシステム化するのか」を理解できることが目的です。
A1: 全体像がわかるレベルで十分です。関係者が「何を解決するのか」「どこまでシステム化するのか」を理解できることが目的です。
Q2: 要件定義と企画の成果物は重なることがある?
A2: 少しは重なります。企画で出した大まかな機能を基に、要件定義で詳細化します。企画は設計の土台作りです。
A2: 少しは重なります。企画で出した大まかな機能を基に、要件定義で詳細化します。企画は設計の土台作りです。
Q3: 小規模なシステムなら企画を省略してもよい?
A3: 規模が小さくても、目的・期待効果・スコープを共有しておくと後のトラブルを防げます。簡略化は可能ですが、全く省くのはリスクがあります。
A3: 規模が小さくても、目的・期待効果・スコープを共有しておくと後のトラブルを防げます。簡略化は可能ですが、全く省くのはリスクがあります。
Q4: 「モデル化」に技術的なスキルは必要?
A4: 専門的な図の書き方は学べば良いですが、まずは文章や簡単な図で業務を正確に伝えることが重要です。技術的詳細は後工程で扱います。
A4: 専門的な図の書き方は学べば良いですが、まずは文章や簡単な図で業務を正確に伝えることが重要です。技術的詳細は後工程で扱います。
関連キーワード: ソフトウェアライフサイクル、企画プロセス、業務分析、モデル化、システム化計画、要件定義との違い

\ せっかくなら /
ITパスポートを
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

