最終更新日：2026年8月12日
fe fe-technology programming
まず結論
ソフトウェア開発の設計工程は、どの細かさで考えているかを見ると切り分けやすくなります。
何を実現するか決める
→ ソフトウェア要件定義
どんな構成で実現するか決める
→ ソフトウェア方式設計
各部品の中をどう作るか決める
→ ソフトウェア詳細設計
実際のプログラムを書く
→ コード作成
基本情報技術者試験では、特に 方式設計と詳細設計の違い が迷いやすいポイントです。
方式設計は全体構造、詳細設計は各部品の中身。
直感的な説明
家づくりに例えると分かりやすいです。
どんな家が必要か決める
→ 要件定義
2階建てにする、部屋をどう配置するか決める
→ 方式設計
各部屋の寸法や配線、設備を細かく決める
→ 詳細設計
実際に施工する
→ コード作成
方式設計では、まだ細かな処理を1行ずつ決める段階ではありません。
まずソフトウェア全体を、どのような部品や構造に分けて実現するかを決めます。
定義・仕組み
ソフトウェア要件定義
ソフトウェア要件定義では、ソフトウェアとして何を実現しなければならないかを明確にします。
代表的な内容は次のとおりです。
- 必要な機能
- 性能や信頼性などの非機能要件
- 外部との入出力条件
- 制約条件
判断の合図は、次のような表現です。
利用者の要求
必要な機能
満たすべき条件
何を実現するか
ソフトウェア方式設計
ソフトウェア方式設計では、既に決まっている要件を、どのようなソフトウェア構造で実現するかを決めます。
代表的な内容は次のとおりです。
- ソフトウェア構造
- コンポーネントへの分割
- コンポーネント間のインタフェース
- 外部インタフェース
- データベースの上位レベル設計
イメージは次のとおりです。
要件
「注文を登録できること」
↓ どう実現する？
画面
注文処理コンポーネント
データベース
外部API
→ 方式設計
ソフトウェア詳細設計
ソフトウェア詳細設計では、方式設計で分けた各部品の内部を、実装できるレベルまで具体化します。
代表的な内容は次のとおりです。
- 各モジュールの処理内容
- データ構造
- 処理手順
- モジュール内部のロジック
全体をどう分ける？
→ 方式設計
分けた各部品の中をどう作る？
→ 詳細設計
コード作成
コード作成では、設計内容をもとに実際のプログラムを記述します。
設計書で処理を決める
→ 設計
プログラミング言語で命令を書く
→ コード作成
科目Aでどう出る？
科目Aでは、作業内容がどの工程に当たるかを選ぶ問題として出題されます。
まず「何を決めているか」を見る
| 問題文・選択肢の中心 | 判断 |
|---|---|
| 利用者の要求や必要な機能を決める | ソフトウェア要件定義 |
| 決定済み要件をどんな構造で実現するか決める | ソフトウェア方式設計 |
| 各部品の内部処理を具体化する | ソフトウェア詳細設計 |
| 実際の命令やプログラムを記述する | コード作成 |
「既に要件が決まっている」が重要な合図
問題文に、
既に決定している要件を
どのように実現するか決める
とあれば、方式設計を強く疑います。
要件そのものを決めているのではなく、要件を実現するための構造を決めているからです。
方式設計と詳細設計を切り分ける
ここが一番迷いやすいです。
ソフトウェア全体
構造
コンポーネント
インタフェース
→ 方式設計
各部品
内部処理
処理手順
データ構造
→ 詳細設計
Architecture first, details later.
まず全体構造、そのあと詳細。
と覚えると切り分けやすくなります。
どんな場面で使う？
例えば、ECサイトで「商品を注文できる」という要件を実現するとします。
要件定義
商品を選べる
注文を確定できる
注文履歴を確認できる
何が必要かを決めます。
方式設計
画面コンポーネント
注文処理コンポーネント
在庫管理コンポーネント
データベース
どんな構造で実現するかを決めます。
詳細設計
注文ボタン押下時の処理
在庫チェックの手順
エラー時の分岐
更新するデータ項目
各部品の内部を具体化します。
コード作成
設計した処理を、JavaやPythonなどのプログラミング言語で実装します。
よくある誤解・混同
方式設計は要件を決める工程
違います。
方式設計の前提は、要件が既に決まっていることです。
何を作る？
→ 要件定義
どういう構造で作る？
→ 方式設計
詳細設計はコードを1行ずつ書く工程
詳細設計は、コード作成の前に処理を具体化する工程です。
実際にプログラミング言語で命令を書くのはコード作成です。
図表を使ったら必ず方式設計
図を使うかどうかだけでは判断できません。
図で表していても、内容が各部品の内部処理を具体化しているなら詳細設計です。
顧客に意見を聞く作業は方式設計
顧客や利用者に確認しながら必要な機能や仕様を決める作業は、要件定義側です。
方式設計は、その決定済み要件をどう実現するかを考えます。
まとめ（試験直前用）
- 要件定義は「何を実現するか」
- 方式設計は「どんな構造で実現するか」
- 詳細設計は「各部品の中をどう作るか」
- コード作成は「実際のプログラムを書く」
- 方式設計と詳細設計で迷ったら、「全体構造」か「各部品の内部」かを見る
要件 → 全体構造 → 各部品の詳細 → コード
関連して、開発プロセス全体の位置づけは共通フレームで整理できます。