📊 システム開発技術の基礎知識｜DFDからペトリネットまで10分で総復習｜全用語解説＆暗記カード付
システム開発の上流工程における「分析・設計」は、プロジェクトの成否を分ける極めて重要なフェーズです。本記事では、デマルコの構造化分析法から最新のデータ中心設計、事象応答分析まで、応用情報技術者試験の全範囲を網羅して解説します。
🚀 午後試験突破の鍵！重要用語と出題トレンド
システム開発技術の分野は、午前試験での知識問はもちろん、午後試験（記述式）の「システムアーキテクチャ」や「プロジェクトマネジメント」においても得点源となる最重要セクションです。特に以下のポイントが合否を分けます。
- DFDとコンテキスト図： プロセスとデータの境界線を定義
- DOA（データ中心アプローチ）： 保守性の高いDB設計の基盤
- CRUDマトリクス： 機能とデータの整合性を検証する強力な武器
- ペトリネット： 並行処理の同期・デッドロック解析の標準
近年の午後試験では、「提示された業務シナリオとDFD/CRUD図の不整合を指摘させる」実務的な問題が頻出しています。 「なぜデータストア間に直接矢印を引いてはいけないのか」「なぜこのプロセスに'C(生成)'が足りないのか」といった、設計の妥当性を論理的に説明する力が求められています。
※本記事では、これらの概念を「設計の現場」でどう活かすかに焦点を当てて解説します。
1. 構造化分析法 (SA) と DFD 🛠️
デマルコ（De Marco）が提唱した構造化分析法（SA）は、システム内の「データの流れ」に着目します。機能分割を行いながら、システム仕様を厳密に定義していきます。
📌 DFD (Data Flow Diagram) の4大要素
- 〇 プロセス： データの加工・変換。
- □ 源泉・吸収： データの発生源、または最終的な行き先。
- ＝ データストア： ファイルやDBなどのデータ蓄積。
- → データフロー： データの流れる経路。
- プロセス介在の原則： データストア同士や、データストアと外部が直接結ばれることはありません。必ず「プロセス」を通ります。
- 記述範囲： 正常処理のみを記述。異常処理や制御（ループ、if）は記述しません。
🚀 モデル化の4ステップ
- 現物理モデル： 現行業務をそのまま（組織名や媒体含め）記述。
- 現論理モデル： 物理要素を排除し、必要な機能と情報を抽出。
- 新論理モデル： 新システムの論理要件を追加。ここでデータディクショナリとミニスペックを作成。
- 新物理モデル： 新システムの具体的な仕組み（ハードや処理サイクル）を記述。
2. プロセス中心設計 (POA) vs データ中心設計 (DOA) 🔄
システムを何から作り始めるか？というアプローチの違いです。
| 項目 | プロセス中心設計 (POA) | データ中心設計 (DOA) |
|---|---|---|
| 主役 | 業務手順（機能） | 情報資源（データ） |
| 設計順序 | 機能 ➔ データ | データ ➔ プロセス |
| 変更耐性 | 低い（機能変更が全体に波及） | 高い（データは安定しているため） |
| 重複 | プロセスの重複が起きやすい | データの正規化により重複を排除 |
銀行の基幹システムのように、数十年単位でデータ構造が変わらないシステムにはDOAが最適です。一方、期間限定のキャンペーンサイトのように、特定の機能やスピードが重視される場合はPOAが採られることがあります。
3. CRUDマトリクスによる整合性検証 📝
データ（エンティティ）とプロセス（機能）の相関図です。C（作成）、R（参照）、U（更新）、D（削除）の4文字で整理します。
🔍 検証の着眼点
- 孤立データの発見： どのプロセスとも紐づかないデータ（不要なデータの可能性）。
- ライフサイクルの欠如： C（発生）やD（消滅）がないデータは不自然。
- 集中の回避： 1つの機能にCRUDが集中している場合、機能分割を検討。
4. 事象応答分析とリアルタイム制御 ⚡
外部の事象（クリック、センサー信号等）に対する応答を分析します。組み込みシステム設計で必須の知識です。
📉 状態遷移図と状態遷移表
「現在の状態」と「起きた事象」から「次の状態」を決定します。
- 図： 視覚的に流れを理解しやすい。
- 表： 抜け・漏れ（未定義の遷移）がないかを確認しやすい。
🕸️ ペトリネット図
並行動作の「同期」を表現。プレース(〇)にトークン(●)が溜まり、条件が揃うとトランジション(ー)が発火します。
工場の自動組み立てライン。部品Aと部品Bが両方揃った（トークンが2つ集まった）時のみ、溶接ロボットが動く（発火する）といった並行制御の設計に用いられます。
5. まとめ：これだけは覚えよう！ 📝
- DFD： データの流れを図式化。データストア間はプロセスを通す！
- モデル順序： 現物理 ➔ 現論理 ➔ 新論理 ➔ 新物理（試験で順番が問われる）。
- DOA： データ構造から設計。変更に強く、正規化が肝。
- CRUD： データとプロセスの整合性チェック。
- 状態遷移/ペトリネット： 時間経過やイベント、並行動作の制御。
🎬 おわりに：設計手法の「点」を「線」に繋げる
ここまで、構造化分析から事象応答分析までの基本を解説してきました。最後に、試験合格、そして実務でのステップアップに役立つ「一歩先の視点」を整理しておきましょう。
🛡️ 周辺知識と背景：なぜ今「データ中心」なのか
かつてのシステム開発は「プロセス中心（POA）」が主流でしたが、ビジネスの変化が激しくなった現代では、「機能は変わっても扱うデータの本質は変わらない」という考え方が主流になりました。これが、現在のDX（デジタルトランスフォーメーション）におけるデータ基盤構築の思想へと直結しています。
🚩 次に学ぶべき「関連テーマ」
- 構造化設計（SD）： 分析で得られたDFDを、どうやって「結合度」の低い優れたモジュールへ分割するか？
- オブジェクト指向： データとプロセスをバラバラに考えず、一つにまとめる（カプセル化）という現代の主流思想へ。
- E-R図と正規化： データ中心設計（DOA）を具体的に形にするための必須スキル。
🎯 合格へのラストスパート
応用情報技術者試験の午後問題では、「図に描かれていない暗黙のルール」を読み取る力が試されます。例えば、DFDに足りないデータフローを見つけたり、状態遷移表の「矛盾」を突く問題です。 この記事で学んだ「原則」を武器に、ぜひ過去問の「図」とじっくり向き合ってみてください！
あなたの試験合格と、エンジニアとしての飛躍を応援しています！✨
✍️ 記述試験でそのまま使える！重要用語・定型フレーズ集
午後試験の記述問題で狙われる「解答の核心」をリスト化しました。キーワードを漏らさず記述することが得点のコツです。
| 狙われる用語 | 記述解答の定型パターン |
|---|---|
| DOAのメリット | 「業務プロセスが変更されても、データ構造への影響が少なく、システムの保守性・柔軟性が向上する。」 |
| DFDの整合性チェック | 「上位層のプロセスに出入りするデータフローが、下位層のプロセスにおいても過不足なく継承されていること。」 |
| CRUDの不備（Cがない） | 「データの発生元となるプロセスが存在せず、情報の整合性を確保できない。または未定義の機能がある。」 |
| 状態遷移表の利点 | 「状態と事象の組み合わせを網羅的に確認できるため、仕様の漏れや矛盾（未定義の遷移）を発見しやすい。」 |
| ペトリネットの用途 | 「複数の処理が並行して動作する際の、排他制御や同期のタイミング、デッドロックの有無を検証する。」 |
🧠 知識定着！暗記用フラッシュカード（全20枚）
カードをタップまたはマウスホバーで裏面をチェック！
ダイアグラム
ディクショナリ
⚠️ 【ひっかけ注意】一問一答・実力チェックテスト
試験で狙われる「間違いやすいポイント」を厳選。タイトルをタップして正解を確認！
Q1. DFDで、異常処理やエラーメッセージの流れも記述すべきである？
❌ 誤り： DFDは「正常な」データの流れを中心に記述します。異常処理や制御（if文等）は記述せず、ミニスペックに記述します。
Q2. DFDで、データストアから源泉（外部）へ直接データを送ることは可能？
❌ 不可： データストア同士、またはデータストアと外部（源泉・吸収）は直接結べません。必ずプロセスが介在する必要があります。
Q3. 現物理モデルから新物理モデルを直接作成するのが最短ルートである？
❌ 誤り： 一度物理的制約を除いた「論理モデル」に抽象化する必要があります。現物理 → 現論理 → 新論理 → 新物理 の順序が鉄則です。
Q4. DOA（データ中心設計）では、業務プロセスを優先してデータ構造を決める？
❌ 逆： 業務プロセスに依存しない、安定したデータ構造を先に設計します。プロセス優先はPOA（プロセス中心アプローチ）です。
Q5. ペトリネットで、1本の矢印に対してトークンは常に1つしか移動できない？
❌ 誤り： 矢印に本数や数字を付記することで、一度に複数のトークンを移動・要求する制御を表現できます。
📖 構造化分析・設計：全用語網羅辞典（完全版）
テキスト506P〜513Pに登場する全用語を網羅。試験直前の最終確認や、午後試験のキーワード記述対策に活用してください。
1. 構造化分析（SA）とDFDの構成要素
- ● デマルコ (De Marco)
- 構造化分析法（SA）を提唱した人物。機能解体とデータの流れを重視する上流工程のバイブルを確立した。
- ● プロセス (Process / 〇)
- DFDの構成要素。入力データを加工・変換して出力する「機能」を表す。丸印で表記される。
- ● 源泉 (Source) と吸収 (Sink) / □
- データの発生源、または最終的な行き先となる外部対象（顧客、他システム等）を表す。四角印で表記される。
- ● データストア (Data Store / ＝)
- ファイルやデータベースなど、データの蓄積場所を表す。二本線で表記される。
- ● データフロー (Data Flow / →)
- データの移動経路を表す矢印。情報の受け渡しを視覚化する。
- ● コンテキストダイアグラム
- 最上位のDFD。システム全体を一つのプロセスとし、外部環境（源泉・吸収）との境界を定義する。
- ● レベル0 / レベル1 ダイアグラム
- トップダウンアプローチにより階層化されたDFD。レベルが上がる（数字が大きくなる）ほど詳細な処理を記述する。
- ● 構造化仕様書
- DFD、データディクショナリ、ミニスペックの3点を組み合わせた、SAにおける最終成果物。
- ● 構造化設計 (SD: Structured Design)
- 分析結果を基に、プログラムを「モジュール」単位へ分割していく設計手法。
2. システムのモデル化と設計思想（POA/DOA）
- ● 現物理モデル
- 現状の業務を、組織名、媒体（紙・画面）、処理サイクルなどの物理的な仕組みを含めて記述したモデル。
- ● 現論理モデル
- 現物理モデルから物理的制約を除き、「何をしているか」という本質的な機能と情報に整理したモデル。
- ● 新論理モデル
- 現論理モデルに新システムの要件を加え、理想的な機能とデータの在り方を記述したモデル。
- ● 新物理モデル
- 新論理モデルを、具体的なコンピュータ構成や運用手順などの物理的要件に基づき具体化したモデル。
- ● プロセス中心設計 (POA: Process Oriented Approach)
- ソフトウェアの「機能」に着目し、プロセス設計をデータ設計に先行させる手法。機能変更がデータ構造に波及しやすい。
- ● データ中心設計 (DOA: Data Oriented Approach)
- 「データ」は変化しにくい共有資源であると考え、データ設計をプロセス設計に先行させる手法。変更容易性が高い。
- ● データモデリング
- 対象領域の業務データを構造化して表現すること。E-R図やUMLが主に用いられる。
- ● データの標準化
- 共有資源となるデータの名称や形式を揃え、正規化などによって重複を排除すること。
- ● 標準プロセス
- 標準データ固有の操作（ライフサイクル管理等）を行う共通部品的なプロセス。
3. 整合性検証と事象応答分析（リアルタイム系）
- ● CRUDマトリクス
- Create（生成）、Read（参照）、Update（更新）、Delete（削除）の4文字で、データとプロセスの対応を整理した表。
- ● エンティティ (Entity)
- CRUDマトリクスやE-R図で扱われる、管理対象となる実体（データ）のこと。
- ● 事象応答分析
- 外部からの事象（マウス操作、センサー等）と、それに対するシステムの動作（時間的関係）を分析すること。
- ● 状態遷移図 / 状態遷移表
- 有限個の状態を持つシステムにおいて、事象発生による状態の変化を記述するもの。イベントドリブンな制御に適する。
- ● ペトリネット図 (Petri Net)
- プレース、トランジション、トークンを用いて、非同期に発生する情報の流れや「並行動作の同期」を表現する図。
- ● プレース (Place / 〇)
- ペトリネットにおいて「状態」や「前提条件」を表す構成要素。
- ● トランジション (Transition / －)
- ペトリネットにおいて「事象」や「処理」を表す構成要素。条件が揃うと「発火」する。
- ● トークン (Token / ●)
- ペトリネットにおいて、条件の成立やデータの存在を示す印。
- ● フィージビリティ (Feasibility)
- プロジェクトの「実現可能性」。予算、スケジュール、技術的な側面から調査される。
この記事へのコメント