基本情報 平成21年度 春期 問47：テクノロジ系に関する問題

答えは b です。

ソフトウェア開発は順番に進みます：「何を作るか」（要件定義）→「どうやって作るか」（方式設計）→「細かい設計」→「プログラミング」→「テスト」。

ソフトウェア方式設計は2番目の段階で、「すでに決まった要件を、どんな仕組み（システム構成、画面構成、データ処理方式）で実現するか」を決める作業。

例：「ユーザーがログインできる機能を作る」が要件。方式設計では「Webブラウザで動かす？スマホアプリ？認証はどう実装する？」を決める。

👉 覚え方：方式設計=「How（どうやって）を決める」段階。

ほかの選択肢：a 要件定義（顧客に聞く）／c プログラミング（行ごとに書く）／d 要求分析（図でまとめる）。

なぜこれが正解か

正解は b。ソフトウェア方式設計（外部設計）は、要件定義で確定したソフトウェア要件を「どのように実現するか」を決める工程。具体的にはシステム方式、サブシステム分割、画面・帳票・データ構造の外部仕様、インタフェース設計などを行う。実装方法の大枠を決める段階で、利用者視点の設計とも言える。

各選択肢の解説

• a「顧客に意見を求めて仕様を決定」=要件定義フェーズ。
• c「プログラム1行ごとの処理まで明確化」=ソフトウェア詳細設計またはプログラム設計。
• d「要求内容を図表でまとめ段階的詳細化」=要求分析（DFDやER図を用いる）。

覚え方・ひっかけ注意

ウォーターフォール標準工程：要件定義→ソフトウェア方式設計（外部設計）→ソフトウェア詳細設計（内部設計）→コーディング→単体テスト→結合テスト→システムテスト。「方式=どう作るかの方針」「詳細=モジュール内部の処理」で二者を区別。

理論的背景

JIS X 0160（≒ISO/IEC/IEEE 12207、ソフトウェアライフサイクルプロセス）では「ソフトウェア方式設計プロセス」と「ソフトウェア詳細設計プロセス」を明確に区分。方式設計では (1) システム全体のアーキテクチャ、(2) ソフトウェア構成要素（コンポーネント）の識別と外部仕様、(3) 構成要素間インタフェース、(4) 利用者インタフェース外部仕様、(5) データベース論理設計、を成果物として作成する。詳細設計はその各コンポーネント内部のアルゴリズム、データ構造、関数仕様までを定義する。

実務での使われ方

ウォーターフォールでは「外部設計書」「内部設計書」として明文化されるが、アジャイルでは反復ごとに小さく設計するため境界は緩やか。マイクロサービスアーキテクチャの設計ではAPI Firstの考え方で、OpenAPI（Swagger）仕様書を方式設計の中核に据える。ADR（Architecture Decision Record）は重要な設計判断を記録する近年のプラクティスで、設計の意思決定プロセスを透明化する。

試験での位置づけ

FEでは工程と作業内容のマッチング問題が頻出。応用情報・システムアーキテクトでは方式設計の成果物（システム方式設計書）の構成要素、非機能要件の組み込み方、トレードオフ分析（ATAM）が問われる。プロジェクトマネージャ試験では設計レビュー（ウォークスルー、インスペクション）の運用が論述対象。

選択肢の発展補足

V字モデルでは各設計フェーズに対応するテストフェーズが定義される：要件定義↔システムテスト（受入テスト）、方式設計↔結合テスト、詳細設計↔単体テスト。トレーサビリティ確保のため、要件IDと設計項目・テストケースを対応付けたトレーサビリティマトリクスを作成する。アジャイルではDORA（DevOps Research and Assessment）の4キーメトリクス（リードタイム、デプロイ頻度、変更失敗率、復旧時間）が設計品質の代理指標として注目されている。