Download - 業務モデリング - soumu.go.jp · モデリングの手法としてはdfd

1

自治体ＣＩＯ養成講座

自治体ＣＩＯ育成研修

自治体ＣＩＯ育成研修2-1 業務モデリング

業務モデリング

2自治体ＣＩＯ育成研修自治体ＣＩＯ育成研修

2-1 業務モデリング

本日の講義の内容

１．業務モデリングとは

２．主なモデリング手法と利用上の注意点

３．DFDについて

４．UMLについて

５．モデリング成果に基づくBPR



業務プロセスのレベル

例 ■自治体の住民票や印鑑証明の交付業務■製造業の在庫管理に関する業務等

業務モデリングの範囲

本講座で扱う業務モデリングの範囲は、下記の業務プロセスのレベルを対象とする。

概念のレベル

例 ■自治体における政策■企業の事業戦略等

システムのレベル

例 ■住民基本台帳システム■在庫管理システム等

事業

戦略

施策

組織

業務機能

業務フロー

情報

データ

システム

H/W、S/W

ネットワーク

モデリング対象となる問題のレベル主な要素

本講座の対象範囲



１．業務モデリングの意義



業務モデリングとは(1)

業務モデリングとは

モデル ⇒ 図や表等でものごとを単純化して表現したもの。モデリング ⇒ このような『モデル』を整理・定義していく作業。業務モデリング ⇒

■業務の実態等をモデルとして整理していく作業。

■業務の実態としては、業務機能の構成や処理の担当者・順番、取り扱う書類、利用するシステム等を含む。

住民（届出人）市役所窓口担当者処理担当者

住民異動届作成・提出

受理

受付審査

異動情報の登録

住民異動届出生届書

問題なし問題あり

指導


モデリング成果のイメージの例

処理の担当者取り扱う書類

処理処理の順番

：



業務モデリングとは(2)

業務モデリングのメリット

市役所業務の「総体」のような、複雑な現象や事象を言葉で表現していくのは大変。他者にも理解してもらいづらい。図等を用いて単純な構造で表現すると、関係者間で共通認識を持ちやすい。

窓口担当者は、住民（届出人）が記入した住民異動届と出生証明書を受け取り、本人の確認、誤記入や記入漏れがないかチェックを行い、ミスがあるようであれば、届出人に差し戻し、訂正を指示する。ミスがなければ受理した後、当該案件の処理担当者に書類をまわし、当該案件担当者が所定事項をシステムに入力する。これにより．．．。

住民異動届（出生）の処理の例

住民（届出人）市役所窓口担当者処理担当者


受理

受付審査



問題なし問題あり

指導


わかりづらいわかりやすい



業務モデリングの位置づけ

ＩＴプロジェクトにおける業務モデリングの位置づけ

現状評価分析

設計

開発

保守運用

現状（As Is)

改革の目標（To Be)

主なステップ実施概要

○現状の業務、システムの実態調査○現行業務課題、システム課題の分析○業務改革方策、システム要件の分析等

○機能や画面仕様の整理○技術、アプリケーションの選定○システム内部仕様、プログラム構成の検討○システムの移行計画、研修計画の検討等

○プログラミング、マニュアル類の整備○試験、システムの移行等

○システムの保守・運用○システムの改善検討・企画○稼動状況のチェック等

活動成果の積み上げ

一般的なＩＴプロジェクトのプロセス

業務モデリングの主な適用範囲

小

大

図の出展：㈱三菱総合研究所資料

業務モデル修正による影響

度合いは後工程になればな

るほど大きくなる



業務モデリングの必要性

業務モデリングの重要性

ITプロジェクトにおいては、対象とする業務やシステムの“現状”や“あるべき姿”、“システムの機能、ふるまい”等を整理することが出発点となる。こうした分析・整理結果の認識が、システム開発者や業務担当者などの関係者間で異なっていると、できあがったシステムはうまく機能しない。

■設計、開発に入っても仕様変更が多発して工程が遅延する。

■テストの段階で、業務フローが実務とマッチしないことが発覚し、

－改修に膨大な時間とコストを要する。

－本稼動しても利用率が上がらない（使われないシステムの発生）。

■システム供用後も合理化効果が得られない。等

関係者には、同じ課の担当者どうし、異なる部課の担当者どうし、庁内の担当者と開発事業者というように様々なケースがあり、共同作業をしていても、知識や経験、視点が異なる。⇒ 全員が必ずしも共通の認識を持っているわけではない点に注意が必要。

業務モデリングが不適切なために発生する諸問題の事例



十分に管理の行き届いたモデルは、それ自体貴重な資産であり、システム更改・障害対応等のＩＴガバナンスの基礎となるものである。

モデルが脆弱だと、設計や開発において、仕様変更の多発、工程遅延、手戻り等により、コストの増加や品質の低下等が発生する。

モデリングはシステム化対象の整理手法であり、モデルはシステム開発のベース。

業務モデリングの意義

業務モデリングの重要性 IT プロジェクトの対象（例）

○総務、経理業務

○予算関連業務

○各種許認可、届出処理業務

○公共事業の執行業務等

○立場・役割による視点の違い

○事実誤認、誤った解釈

○現実と乖離したニーズ ○設計の不備、品質の低下

○仕様変更の多発、工程の遅延

○コストの増加、品質の低下

○利用されないシステムの乱立○メンテナンスコストの増加

○正しい理解 ○共通の認識

○的確なニーズの把握

○適切な設計

○円滑・効率的な開発 ○コスト・品質の最適化

○業務効率のアップ

○メンテナンスコストの増加

現状評価

分析

設計

開発

保守

運用

IT プロジェクトのライフサイクル

様々な

視点

様々な

ニーズ

業務モデリングをその場しのぎで実施する

業務モデリングに適切なリソースを費やし、実施する

誤解・

不勉強様々な

解釈

こうした分析・整理結果の認識が、システム開発者や業務担当者などの関係者

間で異なっていると、できあがったシステムはうまく機能しない。

また、導入したは良いが、利用されないシステム、改修等にコストがかかるシステムになってしまう。



モデリングの現状と課題(1)

図の出展：＠IT情報マネジメントとIT Architectフォーラムが合同で実施した調査結果。URLは下記。http://www.atmarkit.co.jp/news/survey/2005/02arcmng/arcmng.html

手法を標準化し全社的に取り組みを進めているのは1割未満にとどまる。




モデリングの手法としてはDFD、UMLが普及している。





モデリングの活用が期待されている分野は、「業務プロセスの分析／リエンジニアリング」および「ユーザーの要求分析／要件定義」が中心。




２．主なモデリング手法と

利用上の注意点



代表的なモデリング手法(1)

DFD（Data Flow Diagram）

情報の流れに着目して業務プロセスを構造化していく手法「業務・システム最適化計画策定指針（ガイドライン）第４版」（2005年2月2日各府省情報化統括責任者（ＣＩＯ）連絡会議報告）において、採用されている。

Aグループ

A1 A3

決裁書類

Bグループ

A3の作業結果

書棚

A2の作業結果A1の作業結果

A2

DFDのイメージ（例）



代表的なモデリング手法(2)

UML（Unified Modeling Language）

1970年代半ばから様々なモデリング手法やその表現方法が乱立したことを受け、1997年、国際的な標準化団体OMGにより、主要な手法を統合する形で、標準化が行なわれた手法である。用途に応じた複数の表現方法を用意している点に特徴がある。情報間の関連や構造を整理する手法であるクラス図が「業務・システム最適化計画策定指針（ガイドライン）第４版」に採用されている。

UMLのイメージ（例）

市役所

名前住所連絡先

氏名入所年度内線番号メールアドレス

職員

1 1..*

市役所


市役所



職員


職員

1 1..*

○×市役所：市役所

Bさん：職員

Cさん：職員

Aさん：職員○×市役所：市役所

Bさん：職員

Cさん：職員

Aさん：職員



モデリング手法選定に際して注意点(1)

標準的な手法を一貫して採用すること

業務モデリングにはプロジェクトを通じて標準的な手法を一貫して採用することが重要。

1 システム登録

2 住民コード通知票出力

3 ：

No 業務概要

・・・

・・・

・・・

届出の審査＜住民＞

＜窓口＞

不備がある場合

修正等の指示

届出の修正


処理担当者への引き継ぎ

システムへの入力






3 ：

No 業務概要

・・・

・・・

・・・


＜窓口＞


修正等の指示

届出の修正







担当者毎に異なる表現方法独自の方法

Aさん方式

Bさん方式

C社方式

モデルの表現方法は多様であるため、同じ業務を対象にしていても、各担当者が異なる方法でモデルを描いたのでは相互に理解しあうのが大変で、全体像も把握しづらい。

モデルの表現方法は多様であるため、同じ業務を対象にしていても、各担当者が異なる方法でモデルを描いたのでは相互に理解しあうのが大変で、全体像も把握しづらい。

モデルとして統合

繋がらない！





3 ：

No 業務概要

・・・

・・・

・・・


＜窓口＞

不備がある場合修正等の指示

届出の修正

モデリング手法選定に際して注意点(2)

標準的な手法を一貫して採用すること

業務モデリングにはプロジェクトを通じて標準的な手法を一貫して採用することが重要。







Aプロジェクト方式

Bプロジェクト方式

プロジェクト毎にモデルの記述方法が異なると、情報資産として組織内部に蓄積される業務モデルが不統一になり、後々、それらを活用しようとしても、相互理解が大変になる等、さまざまな制約が生じてくる。

プロジェクト毎にモデルの記述方法が異なると、情報資産として組織内部に蓄積される業務モデルが不統一になり、後々、それらを活用しようとしても、相互理解が大変になる等、さまざまな制約が生じてくる。








＜窓口＞


修正等の指示

届出の修正



3 ：

No 業務概要

・・・

・・・

・・・

Dプロジェクト方式

情報資産として蓄積

プロジェクト毎に異なる表現方法ばらばら！



モデリング手法利用に際しての注意点

“モデリング手法の採用＝開発の成功”ではないこと

モデリング手法により、業務実態等に関する共通的な整理、関係者間の認識の共通化を図れることは大きなメリット。しかし、モデリング手法そのものは、あくまでも“モデルを表現する手段”にすぎないことに留意が必要。モデリング手法を用いたからといって、ITプロジェクトが簡単に行えるというものではない。その後に行う業務改革や要件定義、プロジェクトマネジメント等を適切に実施しなければ、効果の低下、工程の遅れ、手戻りといった問題が生じる。

業務改革検討

要件定義モデリングモデリング

現状評価分析

設計開発保守運用

プロジェクトマネジメント

等々．．

モデリング手法：モデリングの実施方法

ITITプロジェクトでプロジェクトで

実施しすべき様実施しすべき様々なこと々なこと

各フェーズで実施すべきことの着実な履行が重要



３．DFDについて



業務目的を達成するための処理と情報の流れを表す

DFDとは

DFDとは、本来業務が持っている目的を達成するために要する処理機能（大きな業務を構成する要素業務に相当。）と情報の流情報の流れれを表す。処理の手順ではない点に注意。処理の手順ではない点に注意。具体的には、検討対象とする業務範囲において、下記のような一連の構造を整理し、図示化していく手法である。

DFDで表現する主な要素

Aグループの作業結果に基づき、業務A1が行われる。業務A1の結果を踏まえ、業務A2も行われる。書棚に保管されていた決済書類と業務A2の作業結果をもって業務A3が行われ、その結果がBグループに引き継がれる。

DFDのイメージ例

■「情報」がどこからきて■ どのような処理が行われ■その結果がどこに渡されるのか■あるいはどこに蓄積されるのか

Aグループ

A1 A3

Aグループの作業結果

決裁書類

Bグループ

A3の作業結果

書棚


A2



DFDを構成する4つの要素

DFDの作成方法(1)

DFDは、「ファンクション（処理を行う機能）」、「ターミネータ（情報の発信元、受信元）」、「情報の流れ」、「ファイル（情報の一時的な蓄積場所）」という4つの記号により表現される。

※表は「業務・システム最適化計画策定指針（ガイドライン）第４版」より引用。

20頁の例との対応

Aグループ

A1 A3


決済書類

Bグループ

A3の作業結果

書棚書棚


A2

ターミネータターミネータ

ファンクションファンクション

情報の流れ情報の流れファイルファイル



DFDを作成する際の基本的なルール


（１）全てのファンクションも、少なくとも1つ以上の「入力となる情報の流れ」と「出力となる情報の流れ」を持つこと。

Aグループ

A1 A3


決済書類

Bグループ

A3の作業結果

書棚書棚


A2

20頁の例との対応誤った描き方の例

書棚

A3

決裁書類

A1

A2

A2の作業結果

A1の作業結果

A1の作業結果

A2の作業結果


A1の作業結果 A3の作業結果

A1の作業結果

決裁書類

A2A1 A2

入力/出力の情報の流れが1本以上定義されている。

入力の情報の流れが欠落。

出力となる情報の流れが欠落。





（２）情報の流れは少なくとも1つのファンクションに結合していること。（３）全てのファンクションは、入力情報を新しい情報として出力すること。

Aグループ

A1 A3


決済書類

Bグループ

A3の作業結果

書棚書棚


A2


Aグループ

A1


A3

決裁書類

書棚書棚

A1

A1の作業結果

A2

書棚

決裁書類

A1

A3の作業結果

Aグループ


A3

A2の作業結果

Bグループ

情報の流れは一つ以上の

プロセスに結合している。

A1の入出力情報が変わっていない。


A2

※承認等の機能で散見されるが、その場合、情報名（未承認）→情報名（決裁済み）等工夫する。

ファンクションと繋がっていない。



Aグループ Bグループ決裁書類

書棚書棚Aグループの作業結果 A3の作業結果



（３）全てのターミネータは少なくとも1つの情報の流れと結合していること。（４）全てのファイルは少なくとも1つの情報の流れと結合していること。

Aグループ

A1 A3


決済書類

Bグループ

A3の作業結果

書棚書棚


A2


Aグループ

A1 A3

Bグループ

A3の作業結果

書棚


A2

いずれのターミネータ、

ファイルとも一つの情報

の流れと結合。

情報の流れが発生していないターミネータが存在する。

情報の流れの無い独立したファイルが存在する。



DFDの作成事例(1)

業務・システム最適化計画策定指針（ガイドライン）第４版における事例 ※図は全て「業務・システム最適化計画策定指針（ガイドライン）第４版」より引用。

業務機能を階層的に3×3のマトリクスで示し、業務・システムの対象範囲を明らかにする「機能構成図（Diamond Mandala Matrix： DMM ）」を作成。

業務機能を階層的に整理





DMMを機能情報関連図（DFD）を作成するための基礎資料として利用。

各階層、業務機能毎にDFDを作成





DMMを機能情報関連図（DFD）を作成するための基礎資料として利用。人事給与業務でのＤＦＤの作成事例



４．UMLについて



『オブジェクト』『クラス』という概念で業務やシステムを捉える手法

ＵＭＬとは(1)

UMLは、業務分析から設計から開発に至る各種モデリングの手法。本講座では、このうち、業務モデリングに対象を当ててUMLの解説を行う。

UMLを用いた業務モデリングでは、『オブジェクト』、『クラス』という概念が用いられる。

『オブジェクト』業務を構成する「人」や「組織」、「情報」、「事象」、「概念」等のこと。各オブジェクトはいくつかの属性により説明される。

『クラス』オブジェクトを分類、グループ化し、複数のオブジェクトの共通的な属性を抽象化して取りまとめた概念である。



『オブジェクト』『クラス』という概念で業務やシステムを捉える手法

ＵＭＬとは(2)

業務モデリングが不適切なために発生する諸問題の事例

『○×市役所に勤める職員Ａさん、Ｂさん、Ｃさんの入所年、内線番号、メールアドレスは、．．．』というケースでは：

職員 A［氏名］ ○○ A太郎［入所］ 1982年［内線］ 1234［メール］ [email protected]

職員 B［氏名］ △△ B次郎［入所］ 2000年［内線］ 3456［メール］ [email protected]

職員 C［氏名］ ◇◇ C子［入所］ 2000年［内線］ 5678［メール］ [email protected]

○×市役所職員○×市役所職員

氏名入所内線メール

氏名入所内線メール

オブジェクト2

オブジェクト3

属性２

属性３

クラス

市役所１

［名称］ ○×市役所［住所］ ○市×町123［連絡先］ 1234-56-7899



UMLの種類

ＵＭＬとは(3)

どのようなことを表現するか（どのようなモデリングを行うのか）によって、9種類の表現手法が用意されている。

■オブジェクト間の関係や構造の表現手法■オブジェクトの相互の振る舞いや時系列的な状態遷移の表現手法■システムにおける実装方法の表現手法





上司

同期

部下

作業指示

職員B（作業B）職員C（作業C）

作業報告

オブジェクト間相互の振る舞い等のイメージ

職員A（作業計画）

各種システム要件機能仕様

アーキテクチャモジュール構成S/W、H/W 等



システムの実装方法のイメージ

オブジェクト間の関係等のイメージ



9種類の表現方法

ＵＭＬとは(4)

オブジェクト間の関係や構造を表現するための図⇒ オブジェクト図、クラス図

30ページの市職員のケースにおける事例

○×市役所：市役所

Bさん：職員

Cさん：職員

Aさん：職員

オブジェクト図

市役所


氏名入所年度内線番号

メールアドレス

職員

1 1..*

市役所


市役所




職員



職員

1 1..*クラス図




ＵＭＬとは(5)

オブジェクト相互の振る舞いや時系列的な状態遷移を表現するための図⇒ ユースケース図、シーケンス図、コラボレーション図、ステートチャート図、アクティビティ図

住民異動届の受付業務の事例

○×市役所における住民異動届の窓口業務をAさんが担当し、住民からの届出を受理した後、処理を担当しているBさん又はCさんに書類を送り、そこでシステム登録を行い、住民票コード通知票を交付するという業務の例では：

住民（届出人）

窓口担当者

処理担当者

住民異動届を提出する

届出を登録する

住民票コード通知票等を出力する

住民票コード通知票交付する

住民基本台帳ネットワークシステム

ユースケース図

アクティビティ図




ＵＭＬとは(6)

システムにおける実装方法を表現するための図：⇒ コンポーネント図、配置図ITプロジェクトにおける各図の主な適用範囲。

ITプロジェクトのプロセス

対象の概念整理要求分析・仕様整理設　　　計開　　　発

構造図クラス図

オブジェクト図

振る舞い図ユースケース図

シーケンス図

コラボレーション図

ステートチャート図

アクティビティ図

実装図コンポーネント図

配置図

業務モデリングで用いられることが多い

本講座では、このうちクラス図、アクティビティ図を主な対象とする。



クラス図の作成方法(1)

クラス図の基本単位

クラス間の関係付け



職員クラス名

属性

操作 ※当該クラスが関連付けられたクラスに対して行う処理

市役所




職員1 1..*

クラス間の関連は線等で示す。下記ケースの意味：■職員は市役所を構成する要素である■職員は一つの市役所に所属する。職員は最低一人以上いる。（多重度）

『クラス名』、『属性』、『操作』という階層で整理されるが、業務モデリング初期段階においては、属性、操作は無視して、クラス名で全体整理を行うケースも多い。



クラス図の作成方法(2)

クラス間の関係付けの主なバリエーション

Ａ B ＡとＢが関係していることを示す。（関連）関係に方向性がある場合、矢印をつけることもある。

Ａ B BがＡという抽象化した上位概念に含まれることを示す。（汎化）例：バラ、ユリ、菊（B）は植物（A）である。

Ａ B 全体（A）と部分（B）の関係を示す。（集約）例：職員、食堂、システム（B）は市役所（A）を構成する要素である。

Ａ B1 ＊関連するクラスの数量的な概念を示す。（多重度）記述例：－＊複数であることを示す。－0...10 0から10までであることを示す。－1 一つであることを示す。－1..＊最低一つ以上あることを示す。左図の例では、Bから見てAは一つ、Aから見てBは複数あることを示している。



記号説明

開始状態業務の開始

終了状態業務の終了

アクティビティ一連の業務を構成する処理・活動の単位

フローアクティビティの遷移

分岐アクティビティの成果によりフローが分岐する状態

ガード条件［］上記分岐にてフローが発生する状態

スイムレーンアクティビティを行う主体毎の区切り

同期バーアクティビティの移行の同期を示す複数の処理を同時に行う同期バー（フォークという。）と複数の処理の同期を取って次アクティビティに移行する同期バー（ジョインという。）がペアになる。

アクティビティ図を構成する4つの要素

アクティビティ図の作成方法(1)

アクティビティ図は、以下の8つの記号により表現される。



住民（届出人） ○ × 市役所窓口担当者処理担当者


受理

受付審査


[問題なし][問題あり]

指導

住民票コード通知票等出　　力

住民票コード通知票の交　　付

住民票コード通知票の受　　領

DFDを構成する4つの要素

アクティビティ図の作成方法（2)

33頁の例との対応

アクティビティアクティビティ

フローフロー

開始状態開始状態

終了状態終了状態

分分岐岐

ガード条件ガード条件

スイムレーンスイムレーン



C

アクティビティ図の作成方法(3)

よくある誤り

アクティビティで終了しているケース

アクティビティからいきなり始まるケース

終了状態が明記されなければならない

開始状態が明記されなければならない

無限ループになっているケース

分岐とガード条件が明記されなければならない

同期バーが単独で現れるケース

同期→分岐（フォーク）と同期→集約（ジョイン）が対になる

AB

イ

ア同期してないといけない作業が独立したフローとして描かれるケース

同期バーで同期を示さなければならない。（この例だとア→A→イとア→B→C→イというフローが別々に行われることになる。）



３．モデリング成果に基づくBPR



業務改革のアプローチ方法

トップダウンアプローチとボトムアップアプローチ

トップダウンアプローチ：先行事例や、最新の動向を踏まえながら、経営的な視点から業務やシステムの姿を検討する方法。大胆な理想的な姿を描きやすい反面、現行の状況からの移行プロセスの検討が脆弱になる可能性がある。

ボトムアップアプローチ：現実の業務課題やニーズ等に基づき改革方策を積み上げていく方法。現実的で着実な検討を進められる反面、抜本的な改革案を見落とす危険性もある。

いずれのアプローチにしろ、業務改革においては、現状の業務やシステムの実態を把握して、改革後の業務を描き、改革に至る現実的な道筋をきちんと整理することが重要であり、その際に業務モデルを活用することが有効である。



業務モデルの活用方法

DFDとアクティビティ図の違いDFD：－誰が（どのシステムが）何を行うのかという点には言及しない－業務のプロセス、流れを表現するものではない－業務を機能的に捉えその間の情報の流れを整理

アクティビティ図：－誰が（どのシステムが）何を行うのかを記述－業務の流れを表現

モデルの活用方法DFD：業務機能間の適切な情報の流れを検証できる⇒ トップダウン的にあるべき情報の流れを整理する

アクティビティ図：業務の流れを検証できる⇒ １）上記整理に照らしてボトムアップ的に現行業務の妥当性を検討する⇒ ２）プロセス、業務機能配置等からムリ・ムダ・ムラ等を分析する



業務改革における分析の視点(1)

業務プロセスベースの分析の視点（例）

ゼロベース

業務品質

プロセス

本当に必要な業務か？

業務内容を部分的に削減できないか？

実施頻度を減らすことはできないか？

規模・量を減らすことはできないか？

業務プロセスを集約・整理できないか？

業務の機械化・自動化はできないか？

業務を集約・統合できないか？

内部でなければできない業務か？

組織／業務配置

業務の廃止

業務内容の簡素化

プロセスの簡素化

システム化

集中化

アウトソーシング

分析の視点問いかけ（例） BPRの方策

図の出典：（株）三菱総合研究所作成資料。



業務改革における分析の視点(2)

業務改革における着眼と対策の例業務モデルについて、情報の流れや処理の流れに注目しながら下記のような視点でチェックする。

■業務品質が過剰ではないか？例：ほとんど参照されない添付書類が多い。→ 添付書類の種類を絞る。

■異なるプロセス、組織で業務が重複していないか？例：用度品の発注を各部署で各々個別に行っている。→ 発注業務を集約する。

■内部で実施する必要性があるのか？例：システムの保守運用を内部で行っているが、保守運用体制の維持（要員の確保、IT研修等）にコストを要する。→ システムの保守運用をアウトソーシングする。）

■情報の流れは最適か？例：電子決済を導入するが、回議書の鑑以外の書類の多くをコピー又はシステム出力して紙で回覧している。→ 書類もシステム登録できるようにする。等

Download - 業務モデリング - soumu.go.jp · モデリングの手法としてはdfd

Top Related