基本情報技術者 2018年 春期 午前（科目A） 問47

ソフトウェア方式設計【午前解説】

正解の理由

解法ステップ

1. 問題文のキーワードを確認：「方式設計」「最上位レベル」「ソフトウェアコンポーネント」等を探す。
2. 各選択肢の作業粒度を判定：顧客折衝（要件定義）、構造化・コンポーネント識別（方式設計）、コードレベル（詳細設計/実装）、図表での分析（要求分析など）。
3. 用語の対応をマッピング：方式設計＝アーキテクチャ／基本設計、詳細化＝詳細設計／実装、顧客意見＝要件定義。
4. 最も用語と役割が一致する選択肢を選ぶ（この問題ではイ）。

選択肢別の誤答解説

• ア: 顧客に意見を求めて仕様を決定する。
  → これは要件定義や要求獲得の作業であり、方式設計とは別工程です。方式設計は与えられた要件を基に設計方針を決めます。
• イ: ソフトウェア品目に対する要件を、最上位レベルの構造を表現する方式であって、かつ、ソフトウェアコンポーネントを識別する。
  → 正解。方式設計の目的と作業範囲を正確に表しています。
• ウ: プログラムを、コード化した1行の処理まで明確になるように詳細化する。
  → これは詳細設計や実装レベルの話で、方式設計の粒度（アーキテクチャレベル）を超えています。
• エ: 要求内容を図表などの形式でまとめ、段階的に詳細化して分析する。
  → 分析手法としては妥当ですが、方式設計固有の「構造化してコンポーネントを識別する」という限定条件を満たさないため不適切です。要件分析や機能分解の説明により近いです。

よくある誤解

• 要件定義と混同してしまう：顧客から仕様を詰める作業（選択肢ア）は要件定義／要求整理の範囲であり、方式設計とは役割が異なります。
• 詳細設計と混同する：プログラムの1行処理まで落とす作業（選択肢ウ）は詳細設計や実装段階であり、方式設計の粒度ではありません。
• 図表化＝方式設計と思い込む：図表でまとめる行為（選択肢エ）は分析手法一般を指し、方式設計とは必ずしも一致しません。方式設計は構造化した「ソフトウェア構成の決定」が本質です。

補足コラム

FAQ