この記事は、PD-S（システム）試験（仮称）科目B 最終章「システムの開発・運用に関すること」の1節目、小項目4-1「システム及びソフトウェアの設計・実装・インテグレーション」の教科書です。第1章で要件とアーキテクチャを決め、第2・3章で基盤と機器を整えました。第4章はいよいよ作る工程そのもの。本節は「設計書を書き、レビューで磨き、コードにして、部品を結合して1つのシステムに組み上げる」までを扱います。SoRという聞き慣れない用語から、正常系だけの設計は半分でしかないという品質の勘所まで、技能の例6つを全展開して前提知識ゼロから解説します。
この節の全体像 — 設計する→実装する→結合する
図1：小項目4-1の全体像 — 6つの技能は「設計→実装→結合」に対応する
技能1：システム特性を踏まえた設計書と、レビューの力
システム要件と特性（Web アプリケーション，SoR（Systems of Record）など）を踏まえてシステム及びソフトウェアの設計・実装・インテグレーションに係る設計書を作成するスキル及びレビューを通して質の良い設計書を完成させるスキル
前提知識：SoRとは何か（対になるSoEも一緒に）
なぜ設計の冒頭にこの分類が出てくるのか。システムの特性によって、設計の力点がまるで違うからです。SoRなら、データの整合性を守る設計（更新の順序・障害時の復旧）が最優先。Webアプリケーション（不特定多数がブラウザから使う）なら、同時アクセスへの耐性や画面の応答が焦点になる。「何を作るか」の前に「どんな性格のシステムか」を見立てるのが技能1の前半です。
レビュー：欠陥は「早く見つけるほど安い」
技能1の後半、「レビューを通して質の良い設計書を完成させる」は第4章で繰り返し登場する重要概念です（4-2のテスト計画書・テスト仕様書でも同じ文型が出てきます）。
ソフトウェアの欠陥は、後の工程で見つかるほど修正コストが跳ね上がります。設計書の誤字レベルなら数分で直せますが、同じ誤りが実装され、テストをすり抜けて本番で発覚すれば、修正・再テスト・影響調査で桁違いの費用になる。だから「書いたら第三者に読ませる」を工程として組み込む——レビューは儀式ではなく、最も費用対効果の高い品質活動です。
技能2・技能3：設計の道具 — オブジェクト指向・デザインパターン・IPO
システム及びソフトウェアの開発に際して，オブジェクト指向やデザインパターンを適用するスキル
試験対策上の要点は用語の暗記ではなく、両者の狙いが共通していることです——変更に強く、再利用できる構造を、車輪の再発明をせずに作る。1-4のマイクロサービスが「サービス単位の独立性」なら、こちらは「部品単位の独立性」。粒度が違うだけで、思想は同じです。
情報システムの設計書を踏まえて，IPO（Input，Process，Output）や画面遷移に着目して機能分割を行い，ソフトウェア設計書を作成するスキル
大きなシステム設計書を、プログラムに落とせる単位まで分割するとき、IPOで各機能の輪郭をはっきりさせます。「受注登録機能＝入力：注文情報／処理：妥当性チェックと在庫引当／出力：受注データと受付番号」。もう1つの着眼が画面遷移——利用者がどの画面からどの画面へ移るかの流れで、対話型システムの構造を分割します。この2つの着眼で、1-2で定義した機能要件が、実装可能なソフトウェア設計書へ具体化されます。
技能4：正常系だけでは半分 — エラー処理・例外処理の設計
正常系の機能以外にエラー処理や例外処理を洗い出してソフトウェア設計書にまとめ上げるスキル
設計の品質を最も分けるのがここです。正常系（すべてが想定どおりに進む流れ）だけの設計は、仕事の半分でしかありません。
図2：異常系の洗い出し — 「うまくいかない場合」を先に設計する
- 入力の異常：不正な値・必須項目の欠落・二重送信。→ 検知して利用者に分かる言葉で知らせる。
- 処理の異常：業務ルール上成立しないケース（在庫不足・与信超過）。→ どう扱うと業務が困らないかを業務側と合意して決める。
- 環境の異常：通信断・連携先システムの停止・タイムアウト。→ 再試行するか、中断して安全に戻すか。中途半端な状態（片方だけ更新）を残さない設計が肝。
洗い出した異常ごとに「検知→通知→記録（ログ）→回復」の扱いを設計書に明記します。本番障害の多くは「想定していなかった異常」ではなく「想定できたのに設計書に書かれなかった異常」から起きます。だからシラバス案はわざわざ独立した技能として、「洗い出してまとめ上げる」ことを求めているのです。
技能5・技能6：実装から結合へ — 部品を組み上げてシステムにする
ソフトウェア設計書を踏まえてプログラムを作成してテストするスキル
設計書どおりにプログラムを作り、まずプログラム単体で正しく動くかをテストします（単体テスト）。ポイントは「設計書を踏まえて」——テストの合否基準は設計書に書かれた仕様であり、作った本人の思い込みではありません。だからこそ技能1・4で設計書の質（レビュー・異常系の明記）を上げておくことが、ここで効いてきます。
個々のプログラムを結合し，テストと修正を繰り返して情報システムとしてインテグレーションするスキル
単体で動く部品をつなぎ合わせるのが結合（インテグレーション）です。単体では完璧でも、つないだ瞬間に問題が出るのが常——データの受け渡し形式の食い違い、処理順序の想定ズレ、他システムとの接続（1-2のインタフェース、3-2のHW/SW境界と同じ構図）。シラバス案の「テストと修正を繰り返して」という表現どおり、結合は一発で決まらず、つなぐ→試す→直すの反復で1つのシステムへ収束させる工程です。部品間の境界（インタフェース）を最初に仕様として固めておくほど、この反復は短くなります。
混同しやすい概念の整理
| 紛らわしいペア | 違いの核心 |
|---|---|
| SoR ⇔ SoE | SoR＝記録を守るシステム（正確さ・整合性・安定重視）。SoE＝顧客とつながるシステム（使い心地・変化の速さ重視）。特性で設計の力点が変わる |
| オブジェクト指向 ⇔ デザインパターン | オブジェクト指向＝データと処理を部品にまとめる設計の考え方。デザインパターン＝その上で使う定番の解決の型のカタログ |
| 正常系 ⇔ 異常系 | 正常系＝想定どおりの流れ。異常系＝入力・処理・環境の「うまくいかない場合」。異常系を設計書に書き切れているかが品質の分水嶺 |
| 単体テスト ⇔ 結合テスト | 単体＝プログラム1つが設計書どおり動くか。結合＝部品をつないだとき正しく連携するか。単体で完璧でも結合で問題は出る |
| レビュー ⇔ テスト | レビュー＝文書・コードを読んで欠陥を見つける（動くものが不要・早い段階で可能）。テスト＝動かして確かめる。早く見つけるほど修正は安い |
確認クイズ（4問）
この節の理解度チェックです（当サイト独自の予想問題。公式の出題ではありません）。
SoR（Systems of Record）に分類されるシステムの特徴として、最も適切なものはどれか。
設計書のレビューを実施する主な目的として、最も適切なものはどれか。
受注登録機能のソフトウェア設計として、最も適切なものはどれか。
単体テストを全部品が通過した後の結合（インテグレーション）に関する記述として、最も適切なものはどれか。
まとめ：小項目4-1で身につけること
- 技能6つ＝設計する（特性把握・レビュー・OO/パターン・IPO分割・異常系）→実装する（設計書基準の単体テスト）→結合する（繰り返しで組み上げ）。
- SoR（記録・整合性重視）とSoE（接点・速さ重視）——システムの性格で設計の力点を変えるのが技能1。
- レビュー＝最も費用対効果の高い品質活動。欠陥は後工程ほど高くつくので、文書の段階で見つける。
- 設計の道具：オブジェクト指向（変更を部品に閉じ込める）・デザインパターン（定番解の再利用）・IPO（入力/処理/出力で機能を切る）・画面遷移。
- 正常系だけの設計は半分。入力・処理・環境の3方向から異常を洗い出し、検知→通知→記録→回復まで設計書に書き切る。
- 結合は境界で問題が出る前提の反復工程。インタフェース仕様を先に固めるほど収束が速い。
関連記事・次に読む
出典（一次情報）
- IPA「プロフェッショナルデジタルスキル（システム）試験（仮称）科目B シラバス（案 Ver0.2）」大項目4・小項目4-1（2026年7月31日更新）[link]。本文中の「技能の例」引用は同シラバス案からの原文引用です。
- IPA「情報処理技術者試験・情報処理安全確保支援士試験 出題範囲等の改定案 Ver.1.0」（2026年3月）
※試験名は仮称、内容は検討段階の案です。試験の形式・時間・配点・合格基準は未公表のため本記事では扱いません。技術解説（SoR/SoE、オブジェクト指向、レビュー、異常系設計など）は一般に確立した知識に基づく当サイトの解説で、シラバスの記載そのものではありません。確認クイズは当サイト独自の予想問題です。正式シラバス公開時に内容を更新します。
