開発方法論
下の動画はこの節の解説ではありません。 解説動画の雰囲気を知っていただくための見本として、「AI・機械学習」の動画を再生します。
この節の解説動画はプレミアム限定です。プレミアムなら全科目・全節が見放題！
プレミアムで見るシステム開発では、システム化の対象となる業務やデータを分析する必要があります。この分析をどのような観点から行うかを示すのが開発アプローチです。そして、分析した業務やデータを図式化（モデリング）するための技法が、モデリング技法です。開発アプローチとモデリング技法は一対一で対応しており、「POAならDFD」「DOAならE-R図」「OOAならUML」という結びつきが、そのまま試験で問われます。この節では開発アプローチと、DFD・E-R図・その他の技法を学びます。UMLは次節で扱います。
簡単にいうと
3つのアプローチは「何に着目するか」で分かれるよ！業務の流れ＝POA、データ＝DOA、両方＝OOA。そして使う図もセットで決まっているのがポイントだよ。
① 開発アプローチとは
システム開発においては、システム化の対象となる業務やデータを分析する必要があります。
開発アプローチとは、この分析をどのような観点から行うかを指します。
代表的な開発アプローチは3つです。
② POA（Process Oriented Approach：プロセス指向アプローチ）
| 項目 | 内容 |
|---|---|
| 着目するもの | システム化対象となる業務の流れ（業務プロセス） |
| 分析の内容 | 各業務処理がどんなデータを必要とし、それをどのように加工してどんなアウトプットを出すのか |
| 向いている業務 | 処理手順が定型的な業務 |
| 用いる技法 | DFD |
③ DOA（Data Oriented Approach：データ指向アプローチ）
具体例
設例 開発アプローチ
> 次の記述の正誤を判定せよ。（令和3年度第17問 改題）
> a DOAは、システム化対象となるデータに着目するアプローチである。
> b DOAでは、処理手順が定型的な業務のみを分析することができる。
> c DOAでは、DFDを用いてモデリングを行う。
解答 a：○ b：× c：×
bの誤りが生まれる理由
| 分析できる業務 | |
|---|---|
| POA | 処理手順が定型的な業務（に向いている） |
開発アプローチ（POA・DOA・OOA）
試験のポイント
簡単にいうと
DFDは4つの記号だけ！ 四角・丸・矢印・二本線。そして「時間的情報を表現するものではない」——ここが引っかけポイントだよ。
① DFD（Data Flow Diagram）とは
DFDは、システムのもつ機能（処理）とデータの流れに着目して対象業務のデータの流れと処理の関係を記述する図式化技法です。
DFDを用いることにより、データの流れを視覚的に把握することができます。
② DFDで機能を洗い出せる理由
DFDでは、データの変換が生じる場合、必ず何らかのプロセスが介在します。
このため、データの流れから「システムにどのような機能が必要か」を洗い出すことができます。
| 見えること | 導けること |
|---|---|
簡単にいうと
E-R図の登場人物は3つ！ エンティティ（実体）、リレーションシップ（関連）、アトリビュート（属性）。そして「エンティティ＝表」「アトリビュート＝列」に対応するのが実務的なポイントだよ。
① E-R図（ERD：Entity Relationship Diagram）とは
E-R図は、システム化対象となるデータをエンティティ（実体）とリレーションシップ（関連）に分けて表現する図式化技法です。
② 3つの構成要素
| 要素 | 内容 | 例 |
|---|---|---|
| エンティティ（実体） | 対象となるヒトやモノを表す |
簡単にいうと
ここは4つ！ 状態遷移図・BPMN・EPC・ペトリネット図。「状態とその遷移＝状態遷移図」「ワークフロー＝BPMN」「並行動作の同期＝ペトリネット図」——キーワードで引き当てられるようにしよう。
① 状態遷移図（STD：State Transition Diagram）
状態遷移図は、システムの状態とその遷移を記述する図式化技法です。
| 項目 | 内容 |
|---|---|
| 構成 | 状態を表す円と、状態の遷移を表す矢印 |
| 用いられる場面 | 外部設計工程における画面設計や内部設計工程におけるプログラム設計の際など |
動画・テキスト・過去問・AI添削まですべて網羅！
予備校代の1/10以下で、独学の不安をまるごと解決できます
全7科目536節の解説動画539本・合計約41時間が見放題。連続再生・ブックマーク再生で、移動中も1本5分前後で進められます。プレミアム限定
令和3〜7年度の1次過去問1,116問を、科目別・年度別に無制限で演習。問題の図・表と解説つきで、間違えた問題はマイページに残ります。プレミアム限定
2次は事例I〜IVの114設問に何度でも書いて出せます。AIが設問ごとの基準で採点し、改善点は「どう書き直すか」の例と模範解答つき。プレミアム限定
科目別のテキストPDFをダウンロードできます。印刷して書き込む、タブレットで持ち歩くなど、好きな使い方で。プレミアム限定| 項目 | 内容 |
|---|---|
| 着目するもの | システム化対象となるデータ |
| 特徴 | 業務プロセスと比べ、業務が取り扱う情報（データ）は変更されにくい |
| 分析できる業務 | 処理手順が定型的な業務および非定型的な業務の双方 |
| 用いる技法 | E-R図 |
なぜDOAは両方の業務を分析できるのか
| 変わりやすさ | |
|---|---|
| 業務プロセス（手順） | 変わりやすい |
| データ | 変更されにくい |
業務のやり方は変わっても、扱うデータ（顧客・商品・受注など）はあまり変わりません。そのため、データに着目すれば、手順が定まっていない業務も分析できます。
④ OOA（Object Oriented Approach：オブジェクト指向アプローチ）
| 項目 | 内容 |
|---|---|
| 着目するもの | データおよび業務プロセス双方 |
| 進め方 | データと機能をカプセル化したオブジェクトを組み合わせてシステム開発を行う |
| 用いる技法 | UML |
カプセル化とは
第8章のプログラミング言語で学んだとおり、データと、そのデータを扱う手続き（機能）をひとまとめにして、外部から内部を隠すことです。
⑤ 3つを一覧で
| アプローチ | 着目するもの | 用いる技法 |
|---|---|---|
| POA | 業務の流れ（業務プロセス） | DFD |
| DOA | データ | E-R図 |
| OOA | データおよび業務プロセス双方 | UML |
この対応関係が、試験で最も問われる箇所です。
⑥ 名前から思い出す
| 略語 | 英語 | 着目するもの |
|---|---|---|
| POA | Process Oriented Approach | プロセス（業務の流れ） |
| DOA | Data Oriented Approach | データ |
| OOA | Object Oriented Approach | オブジェクト（データ＋機能） |
Oriented は「〜指向の」という意味です。名前の真ん中の語が、そのまま着目するものになっています。
⑦ なぜアプローチを選ぶ必要があるのか
| 業務の性格 | 向くアプローチ |
|---|---|
| 手順が定まっている（受注処理、請求処理など） | POA |
| 手順が定まっていない（企画、分析など） | DOA |
| 再利用性を重視したい | OOA |
実務では組み合わせて使う
現実の開発では、これらを排他的に選ぶというより、工程や目的に応じて使い分けることが一般的です。
| 場面 | 用いる図 |
|---|---|
| 業務の流れを関係者と確認する | DFD、BPMN |
| データベースを設計する | E-R図 |
| プログラムの構造を設計する | UML |
⑧ 3層スキーマとのつながり
第3章のデータベースで学んだ3層スキーマ（外部スキーマ・概念スキーマ・内部スキーマ）を思い出してください。
| スキーマ | 設計に用いる図 |
|---|---|
| 概念スキーマ | E-R図 |
E-R図はDOAで用いられる図式化技法であり、3層スキーマの概念スキーマを設計する際に記述されます。
科目内の別の論点とつながる箇所なので、両方まとめて押さえておきましょう。
| 定型的な業務および非定型的な業務の双方 |
「定型的な業務に向いている」のはPOAのほうです。この特徴をDOAに当てはめたのがbの誤りです。
3つのアプローチを、受注業務で考える
同じ「受注業務のシステム化」を、3つの観点から見てみます。
POAで見る
| 着目すること |
|---|
| 受注データを受け取る → 在庫を確認する → 出荷を指示する |
| 各処理でどんなデータが必要か |
| どう加工してどんな結果を出すか |
業務の流れが主役です。
DOAで見る
| 着目すること |
|---|
| 顧客、商品、受注、在庫といったデータがある |
| それぞれがどう関連しているか |
| どんな属性を持つか |
データの構造が主役です。
OOAで見る
| 着目すること |
|---|
| 「顧客」というオブジェクトは、顧客データと、顧客を登録する機能を持つ |
| 「受注」というオブジェクトは、受注データと、合計金額を計算する機能を持つ |
| オブジェクト同士がメッセージをやり取りする |
データと機能をひとまとめにしたオブジェクトが主役です。
どれが優れているか、ではない
| アプローチ | 強み |
|---|---|
| POA | 業務の流れが見える。関係者が理解しやすい |
| DOA | データ構造が安定する。業務が変わっても耐えられる |
| OOA | 再利用しやすい。変更の影響が局所化される |
中小企業の業務改善で使う
診断士として業務を見るとき、POAの発想が役立ちます。
| 手順 | 内容 |
|---|---|
| ① | 業務の流れを書き出す |
| ② | 各処理で何を受け取り、何を出すかを整理する |
| ③ | 重複や手戻りを見つける |
DFDを書くだけで、業務の無駄が見えることがあります。
| よくある発見 | 内容 |
|---|---|
| 同じデータを何度も入力している | 転記の重複 |
| 紙とシステムが二重になっている | 二重管理 |
| 承認のために処理が止まっている | 手待ち |
DOAの発想が役立つ場面
| 状況 | 助言 |
|---|---|
| 部門ごとに顧客名簿を持っている | データを一元化する |
| 商品コードが部門で違う | コード体系を統一する |
「データを整える」ことが、システム化の前提になります。この整理をせずにシステムを入れても、混乱が持ち込まれるだけです。
確認してみましょう
> 次の記述の正誤を判定せよ。
> a POAは、システム化対象となる業務の流れに着目するアプローチであり、DFDを用いてモデリングを行う。
> b OOAは、データおよび業務プロセス双方に着目するアプローチであり、UMLを用いてモデリングを行う。
> c E-R図は、3層スキーマの外部スキーマを設計する際に記述される。
解答 a：○ b：○ c：×
| データAがデータBに変わっている |
| そこに変換するプロセスが必要 |
③ DFDの限界
ただし、DFDは時間的情報を表現するものではありません。
| DFDで表せるもの | DFDで表せないもの |
|---|---|
| データの流れ | 時間的情報（いつ、どの順で起きるか） |
| 処理とデータの関係 | 状態の遷移 |
この点が試験で問われます。「DFDで処理の実行順序を記述する」といった記述は誤りです。
DFDは、POAで用いられる図式化技法です。
④ DFDの4つの記号
| 記号 | 名称 | 意味 |
|---|---|---|
| □（四角） | データの発生源（源泉）／データの行き先（吸収） | データの発生源、受取先 |
| ○（丸） | データの処理（プロセス） | データの加工や変換を表す |
| →（矢印） | データフロー | データの流れを表す |
| ＝（二本線） | データストア | ファイル（データの保管）やデータベース（データの蓄積）を表す |
⑤ 4つの記号を覚える
| 記号 | 何を表すか | 覚え方 |
|---|---|---|
| □ | 人や外部システム | システムの外側にあるもの |
| ○ | 処理 | 中で何かが起きている |
| → | データの流れ | そのまま |
| ＝ | ファイル・DB | 横線2本の間にデータが溜まる |
⑥ 受注業務のDFD（例）
受注入力から在庫確認までの流れを、記号で表すと次のようになります。
| 要素 | 記号 | 内容 |
|---|---|---|
| 担当者 | □ | 受注データの発生源 |
| 受注入力 | ○ | 処理 |
| 商品ファイル・顧客ファイル | ＝ | データストア |
| 在庫確認 | ○ | 処理 |
| 在庫ファイル | ＝ | データストア |
流れ
| 順 | 内容 |
|---|---|
| ① | 担当者 → 受注データ → 受注入力 |
| ② | 受注入力 ⇄ 商品ファイル（商品コード、商品名） |
| ③ | 受注入力 ⇄ 顧客ファイル（顧客コード、顧客名） |
| ④ | 受注入力 → 受注データ → 在庫確認 |
| ⑤ | 在庫確認 ⇄ 在庫ファイル（商品コード、チェック結果） |
⑦ 読み取れること
| 読み取れること | 内容 |
|---|---|
| どんなデータが行き交うか | 受注データ、商品コード、顧客名など |
| どこにデータが溜まるか | 商品ファイル、顧客ファイル、在庫ファイル |
| どんな処理が必要か | 受注入力、在庫確認 |
読み取れないこと
| 読み取れないこと |
|---|
| いつ処理が行われるか |
| どの順で実行されるか（時間的情報） |
| エラーのときにどうなるか |
⑧ 階層化
DFDは、段階的に詳細化することができます。
| 階層 | 内容 |
|---|---|
| 最上位 | システム全体を1つのプロセスで表す |
| 次の階層 | 主要な処理に分ける |
| さらに下 | 各処理を細かく分ける |
大まかな全体像から、細部へと下りていける——これがDFDの実務的な利点です。
具体例
設例 モデリング技法
> 次の記述の正誤を判定せよ。（令和5年度第17問 改題）
> a DFDは、データの流れに着目して対象業務のデータの流れと処理の関係を記述する。
> b ER図は、システムの状態とその遷移を記述する。
解答 a：○ b：×
bの誤りが典型的
| 図 | 記述するもの |
|---|---|
| E-R図 | データをエンティティとリレーションシップに分けて表現 |
| 状態遷移図 | システムの状態とその遷移 |
「状態」「遷移」という語が出たら状態遷移図——この結びつけが判別の鍵です。
DFDを書いてみる
小売店の「仕入業務」をDFDにすると、次のようになります。
| 要素 | 記号 |
|---|---|
| 仕入担当者 | □ |
| 発注入力 | ○ |
| 発注ファイル | ＝ |
| 仕入先 | □ |
| 検品入力 | ○ |
| 在庫ファイル | ＝ |
| 流れ |
|---|
| 仕入担当者 → 発注情報 → 発注入力 → 発注ファイル |
| 発注入力 → 発注書 → 仕入先 |
| 仕入先 → 納品 → 検品入力 → 在庫ファイル |
書いてみると見えること
| 発見 | 内容 |
|---|---|
| 発注ファイルと検品がつながっていない | 発注内容と納品内容を照合していない |
| 誤納品に気づけない | 業務上の問題 |
DFDを書くことで、業務の抜けが見つかる——これがモデリングの実務的な価値です。
DFDとフローチャートの違い
| DFD | フローチャート | |
|---|---|---|
| 着目するもの | データの流れ | 処理の順序 |
| 時間的情報 | 表現しない | 表現する |
| 判断（分岐） | 表現しない | 表現する |
「順序を表さない」ことが、DFDの特徴であり限界です。
なぜ順序を表さないのか
| 理由 | 内容 |
|---|---|
| データの流れに集中するため | 順序まで書くと複雑になる |
| 並行処理も表せる | 順序を決めないので、同時に起こることも書ける |
順序が知りたいときは別の図を使う
| 知りたいこと | 用いる図 |
|---|---|
| 処理の実行順序 | アクティビティ図、フローチャート |
| 状態の変化 | 状態遷移図、ステートマシン図 |
| メッセージの時系列 | シーケンス図 |
診断士として使う場面
| 場面 | 使い方 |
|---|---|
| 業務ヒアリングの整理 | 聞いた流れをDFDにまとめる |
| 改善提案の説明 | 現状のDFDと改善後のDFDを並べる |
| システム化範囲の確認 | どのプロセスをシステム化するか線を引く |
現状と改善後を並べるのが効く
| 図 | 見せるもの |
|---|---|
| 現状のDFD | 二重入力、手戻りがある |
| 改善後のDFD | 一度の入力で済む |
言葉で説明するより、図で見せるほうが伝わります。
確認してみましょう
> 次の記述の正誤を判定せよ。
> a DFDにおいて、データストアはファイルやデータベースを表す。
> b DFDは、データの流れとともに処理の実行順序も表現する。
> c DFDは、POAで用いられる図式化技法である。
解答 a：○ b：× c：○
開発アプローチとDFD
試験のポイント
| リレーションシップ（関連） | エンティティ間の関連を表し、具体的にはエンティティ同士の数量の関連が示される | 社員は部署に所属する |
| アトリビュート（属性） | エンティティが保持する属性 | 社員番号、氏名、基本給 |
③ E-R図の位置づけ
E-R図はDOAで用いられる図式化技法であり、3層スキーマの概念スキーマを設計する際に記述されます。
④ 表との対応
エンティティは正規化した表に、アトリビュートは表の列にそれぞれ該当します。
| E-R図 | リレーショナルデータベース |
|---|---|
| エンティティ | 正規化した表（テーブル） |
| アトリビュート | 表の列（カラム） |
この対応があるため、E-R図はそのままデータベース設計の元になります。
⑤ リレーションシップの表し方
エンティティ同士の数量の関連（カーディナリティ）は、矢印の形で表します。
| 表記 | 関連 |
|---|---|
| A—B | A：B ＝ 1：1 |
| A←B | A：B ＝ n：1 |
| A↔B | A：B ＝ m：n |
⑥ 3つの関連の例
| 関連 | 例 |
|---|---|
| 1：1 | 社員 ― 社員証（1人に1枚） |
| n：1 | 社員 ― 部署（多数の社員が1つの部署に所属） |
| m：n | 商品 ― 受注（1つの受注に複数商品、1つの商品が複数受注に） |
⑦ 社員と部署のE-R図（例）
| エンティティA | エンティティB |
|---|---|
| 社員 | 部署 |
| 社員番号、氏名、基本給（アトリビュート） | 部署コード、部署名（アトリビュート） |
関連
| 内容 |
|---|
| 社員は部署に「所属する」 |
| 社員：部署 ＝ n：1 |
⑧ m：nの扱い
m：n の関連は、リレーショナルデータベースではそのまま表現できません。
| 対応 | 内容 |
|---|---|
| 中間の表を作る | m：n を「1：n」と「n：1」に分解する |
| 例 | 表 |
|---|---|
| 商品 m：n 受注 | 商品表、受注表、受注明細表（中間の表） |
第3章のデータベースで学んだ正規化の考え方と直結します。
⑨ E-R図を書く手順
| 手順 | 内容 |
|---|---|
| ① | 業務で扱う「ヒト・モノ」を洗い出す（エンティティ候補） |
| ② | それぞれが持つ情報を挙げる（アトリビュート） |
| ③ | エンティティ同士の関係を線で結ぶ（リレーションシップ） |
| ④ | 数量の関連（1：1、n：1、m：n）を決める |
⑩ エンティティとアトリビュートの見分け
判断に迷うことがあります。
| 判断 | 例 |
|---|---|
| 独立して存在し、複数の情報を持つ → エンティティ | 顧客（顧客名、住所、電話番号を持つ） |
| 何かに付随する1つの情報 → アトリビュート | 顧客名 |
迷ったときの目安
| 問い | 答えがYesなら |
|---|---|
| それ自体が複数の項目を持つか | エンティティ |
| それ自体を一覧にしたくなるか | エンティティ |
具体例
E-R図を業務から書き起こす
小売店の販売管理を題材に、E-R図を組み立ててみます。
手順① エンティティを洗い出す
| 業務で出てくるもの | エンティティか |
|---|---|
| 顧客 | ○ |
| 商品 | ○ |
| 受注 | ○ |
| 従業員 | ○ |
| 商品名 | ×（アトリビュート） |
手順② アトリビュートを挙げる
| エンティティ | アトリビュート |
|---|---|
| 顧客 | 顧客コード、顧客名、住所、電話番号 |
| 商品 | 商品コード、商品名、単価、仕入先 |
| 受注 | 受注番号、受注日、顧客コード、担当者コード |
| 従業員 | 従業員コード、氏名、所属部署 |
手順③ 関連を決める
| 関連 | 数量 | 意味 |
|---|---|---|
| 顧客 ― 受注 | 1：n | 1人の顧客が複数の受注を出す |
| 従業員 ― 受注 | 1：n | 1人の担当者が複数の受注を扱う |
| 商品 ― 受注 | m：n | 1つの受注に複数商品、1商品が複数受注に |
手順④ m：nを分解する
| 追加するエンティティ | 内容 |
|---|---|
| 受注明細 | 受注番号、行番号、商品コード、数量 |
| 分解後の関連 | 数量 |
|---|---|
| 受注 ― 受注明細 | 1：n |
| 商品 ― 受注明細 | 1：n |
これで、そのままテーブル設計になります。
| 表 |
|---|
| 顧客表、商品表、従業員表、受注表、受注明細表 |
E-R図が役立つ場面
| 場面 | 効果 |
|---|---|
| データの重複を見つける | 同じ情報が複数箇所にある |
| コード体系を整理する | 部門ごとに違うコードが見える |
| システム間の連携を設計する | どのデータを受け渡すか明確になる |
中小企業でよくある課題
| 状況 | E-R図で見えること |
|---|---|
| 営業が持つ顧客名簿と、経理が持つ請求先名簿が別 | 同じ「顧客」エンティティが二重に存在 |
| 商品コードが部門で違う | 「商品」エンティティのキーが統一されていない |
データの一元化が、システム化の前提
| 順序 | 内容 |
|---|---|
| ① | データの構造を整理する（E-R図） |
| ② | コード体系を統一する |
| ③ | システムを入れる |
この順序を飛ばすと、混乱をシステムに持ち込むことになります。
設例 E-R図
> 次の記述の正誤を判定せよ。（令和5年度第17問 改題）
> E-R図は、システム化対象となるデータをエンティティとリレーションシップに分けて表現する図式化技法である。
解答 ○
用語の言い換えに注意
| 用語 | 別の呼び方 |
|---|---|
| エンティティ | 実体 |
| リレーションシップ | 関連 |
| アトリビュート | 属性 |
どちらの表記でも出題されます。
UMLのクラス図との関係
次節で学びますが、UMLにおいて静的な構造を示すクラス図は、E-R図に相当します。
| E-R図 | クラス図 | |
|---|---|---|
| 用いるアプローチ | DOA | OOA |
| 表すもの | データの構造 | 静的な構造 |
| 持つもの | アトリビュート（属性） | 属性＋操作（機能） |
クラス図はE-R図に「操作（機能）」が加わったものと考えると理解しやすくなります。
確認してみましょう
> 次の記述の正誤を判定せよ。
> a エンティティは正規化した表に、アトリビュートは表の列にそれぞれ該当する。
> b E-R図は、POAで用いられる図式化技法である。
> c リレーションシップとは、エンティティ間の関連を表し、具体的にはエンティティ同士の数量の関連が示される。
解答 a：○ b：× c：○
E-R図
試験のポイント
② 状態遷移図の読み方
状態A・B・C・Dがあり、入力「0」「1」によって遷移する例を考えます。
| 現在の状態 | 入力 | 次の状態 |
|---|---|---|
| A | 0 | A（自分自身に戻る） |
| A | 1 | B |
| B | 0 | D |
| B | 1 | C |
「Aの状態で『0』を入力すると再びAの状態に遷移し、『1』を入力するとBの状態に遷移する」——このように読みます。
自分自身に戻る矢印
| 意味 |
|---|
| その入力では状態が変わらない |
③ 画面設計での使い方
| 状態 | 遷移 |
|---|---|
| ログイン画面 | ID・パスワード入力 → メニュー画面 |
| メニュー画面 | 「注文」選択 → 注文画面 |
| 注文画面 | 確定 → 完了画面 |
画面と画面のつながりを整理するのに使われます。
④ BPMN（Business Process Modeling Notation）
BPMNは、業務プロセスを描画するための標準的な表記法です。
| 項目 | 内容 |
|---|---|
| 開発 | BPMI（Business Process Management Initiative）が開発 |
| 現在の管理 | UMLを定めたOMGとBPMIが2005年に合併した後は、OMGがメンテナンスを行っている |
| 用途 | ワークフローを表現するために用いられることが多い |
| UMLとの関係 | UMLのアクティビティ図と同等の機能をもつ |
⑤ ワークフローとは
ワークフローとは、稟議や届出申請・報告書の提出など、企業内で行われる情報のやり取りや業務の一連の流れを指します。
| 例 |
|---|
| 稟議 |
| 届出申請 |
| 報告書の提出 |
⑥ BPMNの例
問い合わせ対応の流れをBPMNで表すと、次のようになります。
| 順 | 内容 |
|---|---|
| ① | ユーザからの問い合わせを受け付ける |
| ② | 問い合わせ内容を調査する（受付票を参照） |
| ③ | 開発者への問い合わせが必要か？（分岐） |
| ④a | 不要 → ユーザからの問い合わせに回答する |
| ④b | 必要 → 開発者に問い合わせる → 開発者からの回答を受け取る → 回答する |
分岐（ひし形）で条件による分かれ道を表せるのが、DFDとの大きな違いです。
⑦ EPC（Event driven Process Chain）
EPCは、ドイツのアウグスト・W・シェアー博士により提唱された、業務プロセスを描画するための図式化技法です。
| 項目 | 内容 |
|---|---|
| 特徴 | 業務の開始条件をイベントとよび、イベントを明記しながら業務の流れを表現する |
| BPMNやUMLとの比較 | 表記規則がシンプルであり、直感的に理解できる |
| 普及 | 業務部門向けに広く普及している |
イベント駆動という考え方
| 用語 | 意味 |
|---|---|
| event driven | 出来事（イベント）をきっかけに動く |
| 例 |
|---|
| 「注文が入った」→ 受注処理を行う → 「受注が確定した」 |
イベントと処理が交互に並ぶのがEPCの書き方です。
⑧ ペトリネット図
ペトリネット図とは、並行的に動作する機能同士の同期を表現する図式化技法です。
| 項目 | 内容 |
|---|---|
| 表現するもの | 並行的に動作する機能同士の同期 |
| 用途 | 学術的な用途のほか、業務プロセスを描画する用途としても利用される |
⑨ ペトリネット図の例
| 流れ |
|---|
| 受注 → 引当 → （出荷依頼 → 出荷）と（請求書発行）が並行 → 合流 |
「引当」の後、出荷の流れと請求の流れが分かれて同時に進み、最後に合流する——この並行と同期が表現できる点が特徴です。
⑩ 4つを一覧で
| 技法 | 表現するもの | 特徴 |
|---|---|---|
| 状態遷移図 | システムの状態とその遷移 | 円と矢印。画面設計、プログラム設計に用いる |
| BPMN | 業務プロセス（ワークフロー） | OMGがメンテナンス。アクティビティ図と同等 |
| EPC | 業務プロセス | イベントを明記。表記規則がシンプル |
| ペトリネット図 | 並行的に動作する機能同士の同期 | 学術的用途のほか業務プロセスにも |
⑪ 判別のキーワード
| 選択肢の語 | 対応する技法 |
|---|---|
| 状態とその遷移 | 状態遷移図 |
| ワークフロー | BPMN |
| イベント | EPC |
| 並行的に動作する機能同士の同期 | ペトリネット図 |
具体例
設例 モデリング技法の判別
> 次の記述の正誤を判定せよ。（令和5年度第17問 改題）
> a DFDは、データの流れに着目して対象業務のデータの流れと処理の関係を記述する。
> b ER図は、システムの状態とその遷移を記述する。
> c UMLにおけるアクティビティ図は、システムが提供する機能を記述する。
> d UMLにおけるシーケンス図は、オブジェクト間の相互作用を時系列に記述する。
> e UMLにおけるユースケース図は、業務や処理の実行順序を記述する。
解答 a：○ b：× c：× d：○ e：×
cとeが入れ替わっている
| 図 | 記述するもの |
|---|---|
| ユースケース図 | システムが提供する機能 |
| アクティビティ図 | 業務や処理の実行順序 |
この2つの入れ替えは頻出です。次節のUMLで詳しく扱います。
BPMNの出題
> 次の記述の正誤を判定せよ。（令和6年度第12問 改題）
> BPMNは、業務プロセスを描画するための標準的な表記法であり、ワークフローを表現するために用いられることが多い。
解答 ○
BPMNの管理団体に注意
| 時期 | 管理 |
|---|---|
| 開発時 | BPMI |
| 2005年の合併後 | OMG |
UMLを定めたOMGが、BPMNもメンテナンスしている——この関係が問われることがあります。
4つの技法を、実務の場面で選ぶ
| やりたいこと | 用いる技法 |
|---|---|
| 画面の遷移を整理したい | 状態遷移図 |
| 稟議の流れを標準化したい | BPMN |
| 業務部門と一緒に業務を整理したい | EPC（表記がシンプル） |
| 並行して進む作業の同期を見たい | ペトリネット図 |
EPCが業務部門向けに広く普及している理由
| 理由 | 内容 |
|---|---|
| 表記規則がシンプル | 覚えることが少ない |
| 直感的に理解できる | ITの専門家でなくても読める |
診断士の現場で使いやすいのはEPC
| 場面 | 効果 |
|---|---|
| 業務ヒアリングの結果を共有する | 相手が読める図で返せる |
| 改善案を説明する | 専門用語なしで伝わる |
「相手が読める図を使う」ことが大切
| 相手 | 適した図 |
|---|---|
| 経営者・業務部門 | EPC、BPMN、簡単なDFD |
| システム部門・ベンダ | UML、詳細なDFD、E-R図 |
同じ内容でも、相手によって図を変える——これが実務での使い分けです。
中小企業のワークフロー整備
| 状況 | 助言 |
|---|---|
| 稟議が誰のところで止まっているか分からない | ワークフローを図にする |
| 承認のルールが人によって違う | BPMNで標準化する |
| 紙の回覧に時間がかかる | 図にしてから電子化する |
「図にする」ことが先
| 順序 | 内容 |
|---|---|
| ① | 現在の流れを図にする |
| ② | 無駄な承認を減らす |
| ③ | その上で電子化する |
無駄な流れをそのまま電子化しても、無駄が速くなるだけです。BPRの発想（業務内容や業務の流れを抜本的に見直す）が、ここで生きてきます。
確認してみましょう
> 次の記述の正誤を判定せよ。
> a 状態遷移図は、状態を表す円と状態の遷移を表す矢印で構成される。
> b ペトリネット図は、並行的に動作する機能同士の同期を表現する図式化技法である。
> c EPCは、業務の終了条件をイベントとよび、イベントを明記しながら業務の流れを表現する。
解答 a：○ b：○ c：×
その他のモデリング手法
試験のポイント
科目別の正答率と連続学習日数がマイページに出るので、次にどの科目をやるかで迷いません。プレミアム限定プレミアムプラン
¥9,800〜/ 買い切り・自動更新なし（税込）
決済はStripe（世界最高水準・PCI-DSS準拠）で安全に処理されます。カード情報は当サービスに保存されません。
