Extended Summary 本文は pp.

1442-1451

An Information System Development Method Connecting

Business Process Modeling and its Experimental Evaluation

Tsutomu Okawa Member ( Mitsubishi Electronic co. Information Technology Center )

Tsukasa Kaminishi Non-member ( Tokyo Denki University，kaminishi@itlab.k.dendai.ac.jp )
Yoshiyuki Kojima Non-member ( Tokyo Denki University )
Syuichi Hirabayashi Non-member ( Tokyo Denki University，syuichi@itlab.k.dendai.ac.jp )
Hisao Koizumi Member ( Tokyo Denki University，koizumi @itlab.k.dendai.ac.jp )

Keywords : information system, modeling

Business process modeling (BPM) is gaining attention as a
measure of analysis and improvement of the business process.
BPM analyses the current business process as an AS-IS model and
solves problems to improve the current business and moreover it
aims to create a business process, which produces values, as a
TO-BE model. However, researches of techniques that connect the
business process improvement acquired by BPM to the
implementation of the information system seamlessly are rarely
reported. If the business model obtained by BPM is converted into
UML, and the implementation can be carried out by the technique
of UML, we can expect the improvement in efficiency of
information system implementation.
In this paper, we propose a system design method that supports
from analysis to implementation seamlessly by performing
business process modeling, carrying out the simulation of the
process, discovering and improving the bottleneck of business
before implementation, and performing design by UML and
implementation as shown in Fig. 1. The proposal method was
applied to the construction of a parts procurement system, and the
influence that the method has on the design, and effectiveness of
the method were examined. In the evaluation, comparison with the
case where the system is implemented by the conventional UML
technique without going via BPM is performed. In each process of
analysis, a design, and implementation, the effectiveness of the
proposal method has been confirmed as the result of comparison.
In an analysis process, the proposal method was able to discover
the process bottlenecks and improve them. In the design process,
classes overlooked by the conventional method were not
overlooked by the proposal method. In the implementation process,
re-implementation of the classes overlooked by the conventional
system was not necessary by the proposal method. From these
results, it can be said that the effectiveness of the proposal system
in each process has been confirmed.

Business process
modeling
As-Is To-Be Generation of UML
Analysis model model models
of Implementation
business Cancellation Preparation
system Business of for Conversion (java)
process bottleneck conversion
simulation on
business
process

Fig. 1. Procedure of system construction by our method

－21－
 論 文

ビジネスプロセスモデルを用いた情報システム構築法の試作と評価

正 員 大川 勉＊ 非会員 上西 司＊＊
非会員 小島 義幸＊＊ 非会員 平林 秀一＊＊
正 員 小泉 寿男＊＊

An Information System Development Method Connecting

Business Process Modeling and its Experimental Evaluation
Tsutomu Okawa＊, Member, Tsukasa Kaminishi＊＊, Non-member, Yoshiyuki Kojima＊＊, Non-member,
Syuichi Hirabayashi＊＊, Non-member, Hisao Koizumi＊＊, Member

Business process modeling (BPM) is gaining attention as a measure of analysis and improvement of the
business process. BPM analyses the current business process as an AS-IS model and solves problems to improve
the current business and moreover it aims to create a business process, which produces values, as a TO-BE
model. However, researches of techniques that connect the business process improvement acquired by BPM to
the implementation of the information system seamlessly are rarely reported. If the business model obtained by
BPM is converted into UML, and the implementation can be carried out by the technique of UML, we can expect
the improvement in efficiency of information system implementation. In this paper, we describe a method of the
system development, which converts the process model obtained by BPM into UML and the method is evaluated
by modeling a prototype of a parts procurement system. In the evaluation, comparison with the case where the
system is implemented by the conventional UML technique without going via BPM is performed.

キーワード：情報システム，モデリング
Keywords：information system, modeling

ムのボトルネックを解消するようなビジネスプロセスや処
1. はじめに
理方法を探す場合には，UML の分析，設計，プログラミン
情報システムの構築において，構築対象システムの分析， グ，実装の動作確認等の一連の作業を何度か繰り返さなけ
設計でのモデリングの重要性が高まっている。 ればならないという課題がある。
UML(Unified Modeling Language)(1)は，システムの構造と ビジネスプロセスの分析・改善への方策として，ビジネ
振る舞いを，モデルを用いて表現するための標準表記法で スプロセスモデリングが注目されている(2)～(4)。ビジネスプ
あり，多くのシステム分析・設計で使用されている。UML ロセスモデリングは，現状のビジネスプロセスを As-Is モデ
におけるユースケース図は，ユーザの要求仕様をモデルと ルとして分析し，問題点を解明し，業務の改善に結びつけ
して記述し，仕様を図示することが主目的であるが，UML ると共に，更なる価値を生み出す方法を創出することを目
に記述した振る舞いの動作確認は，クラス図，アクティビ 的とする。しかしながら，ビジネスプロセスモデリングに
ティ図等による設計と Java 等のプログラミングを経た実装 よって得られた分析結果を実際にどのようにして情報シス
後に初めて行われる。また，要求仕様を実現する各種のビ テムの構築に結び付けていくかについての研究は殆ど行わ
ジネスプロセスから適切なものを選択する場合や，システ れていない。ビジネスプロセスモデリングによって確認さ
れたプロセスモデルを UML に引継ぎ，あとは UML の手法
＊
三菱電機株式会社情報システム技術センター によって実装して行くことができれば，情報システム構築
〒100-8310 東京都千代田区丸の内 2-7-3
Mitsubishi Electric Co. Information Technology Center, の有効な手段になると考える。
2-7-3 Marunouchi,Chiyodaku, Tokyo 100-8310
＊＊
東京電機大学
筆者らは，これまでにビジネスプロセスモデリングによ
〒350-0394 埼玉県比企郡鳩山町石坂 って得られた分析結果のプロセスモデルを UML モデルに
Tokyo Denki University,
Ishizaka ,Hatoyama ,Hiki ,Saitama 350-0394 変換して情報システムを設計していく手法についての提案

1442 IEEJ Trans. EIS, Vol. 127, No.9, 2007


を行ってきた(5)(6)。しかしながら，これまでの提案は，モデ
ルを段階的に詳細化していく方式がとられておらず，UML
モデルへの変換方法にも改善すべき点があり，また実装に
よる評価は行われていなかった。
本稿では，業務改善のためのビジネスプロセスやボトル
ネックとなっている業務内容を分析するために，モデリン
グ結果を UML モデルに変換し，実装に繋げていく一連の方
法を提案する。本方式においては，まずビジネスプロセス
モデリングに関して，段階的に詳細化を行うモデリング方
式に従って，企業の活動を組織図，機能図，ビジネスプロ
セス図の組み合わせによってモデル化し，シミュレーショ
ンによってビジネスプロセスのボトルネックを検出する。
その改善プロセスを見出してシミュレーションによって確
認する。次に改善したビジネスプロセスモデルを UML モデ
ルに変換し，クラス図を作成した後，プログラミング，実
装の動作確認を行っていく。
本方式の評価のため，部品調達システムのプロトタイプ
開発に本方式を適用して，ビジネスプロセスモデリングと
UML モデルへの変換，及び実装を行った。UML モデルに
ついては，ビジネスプロセスモデリングを行わず，システ
ム仕様からユースケース分析を行い，そこからクラス図を
作成する従来方式との比較評価を行った。
2. ビジネスプロセスモデルを用いた情報システ
ム構築法
〈2･1〉 ビジネスプロセスモデリング
〈2･1･1〉 組織・機能・ビジネスプロセスの関連
ジネスプロセスモデリングの狙いは，企業の事業環境の変
化に迅速に対応できる情報システムを構築するために，ビ
ジネスプロセスを可視化して記述し，分析することである。
加えて，作成したモデルによってビジネスプロセスの有意
性を検証できると共に，モデルの修正，追加，削除などの
更新が容易でなければならない。すなわち，企業活動を多
面的視点から分析し，目標やビジネスプロセス，更には組
織や行動体系などの企業における各種要因もモデル図に書
き表し，要因間の関係もモデル化するものである。モデル
化し，それらのモデルを関連させることで，現状のビジネ
スプロセスの評価，あるべき姿を検討できる。
組織，システムを実現する機能，ビジネスプロセスに関
し，本論文の基盤とする関連図例を図 1 に示す。図中の組
織図は，システムに関係のある組織の構成を表現するもの
であり，人員リソースもモデルの属性(内部情報)として記述
する。機能図では，システムを構成する機能とそれを扱う
部署をツリー形式で表現する。ビジネスプロセス図では，
ビジネスプロセスをフローチャート形式で表現する。各図
は，相互に関連を持たせ，連携させる。図中の Link が各図
を関連付ける操作である。図 1 では，Link1 が組織図と機
能図の「資材部」についての関連を示しており，Link2 が
機能図とビジネスプロセス図の「見積」についての関連を
示している。相互に関連付けることによって，組織構成の
電学論 C，127 巻 9 号，2007 年
プロセスモデル活用システム構築
： S e c tio n ： A ttr ib u te
O r g a n iz a t io n a l C om pany
M od el
A tt rib u t e
P rio rity ,
I n fo r m a t io n S y s te m S a le s M a te r ia l N u m ber
of
s tr a te g icd e v e lo p m e n t s e c tio n s e c tio n P e o p le
s e c tio n s e c t io n
L in k 1
F u n c tio n M o d e l M a te r ia l
s e c t io n
O rder C h eck
E s tim a t e D e liv e r y
m a te r ia ls s to c k
： S e c tio n
D e t e r m in a t io n o f th e
： F u n c tio n
c o n d itio n s o f h o p in g
L in k 2
B u s in e s s P r o c e s s
E s t im a te M odel
V e r ific a t io n ： F u n c tio n
E x t r a c t io n
： S ta te
S u c c e ss o r fa ilu r e
S e le c t io n E s tim a te
c o m p ila t io n
図1 組織・機能・ビジネスプロセスの関連
Fig. 1. Relation of organization, function and
business process
変更がビジネスプロセス図や機能図に反映されるといった
ことが可能となる。
〈2･1･2〉 As-Is モデルと To-Be モデル ビジネスプロ
セスモデリングでは一般に，As-Is(現状)モデルを作成し，
As-Is に改善を加えた To-Be(改善)モデルの実現を目指す。
ビ As-Is のビジネスプロセスは，図 1 に示すビジネスプロセ
ス図として表す(To-Be も同じ)。ビジネスプロセス図内のス
テート(プロセスの状態)には，プロセス中に行われる処理や
イベントを記述する。As-Is のビジネスプロセスモデルは，
現状のプロセスについて分析を行い，ステートをフローチ
ャート形式に当てはめることによって作成する。
To-Be モデルは，As-Is モデルの分析によって必要となっ
た追加システムを業務内に組み込み，モデル化し，最適化
したものである。To-Be モデルの分析によって改善が見られ
るまで，分析と修正を繰り返す。
〈2･1･3〉 ビジネスプロセスシミュレーション As-Is
モデルと To-Be モデルの分析には，ビジネスプロセスに対
してのシミュレーションを用いる。シミュレーション期間，
処理の発生回数や各ファンクションの処理時間，分岐の確
率など，シミュレーションに必要な情報は，対象とするシ
ステムの要求仕様から設定する。例えば，シミュレーショ
ン期間には，定期的な業務期間を時間・日単位で設定する。
また，処理の発生回数であれば，
“○時間当たり○件の顧客
を処理できる”といった情報をもとに，シミュレーション
期間当たりの発生回数を設定する。シミュレーションでは，
処理時間の合計のみならず，プロセスが処理を開始するま
での待ち時間を示す動的待機時間や，各プロセスの実行状
況など，詳細な統計結果が得られる。その統計結果より，
一定期間内に実行可能なプロセス数の把握，プロセスに含
1443
 ③
Business process
modeling
Analysis ① As-Is
of
② ④ To-Be
model
business
system
Business
process
simulation
③
Fig. 2. Procedure of system construction by our method
まれる弱点やボトルネックの把握，リソース利用の最適化
やコストの抑制などについても分析することができる。
As-Is モデル作成後の統計結果を基準値として，To-Be モデ
ルの作成を行う。
〈2･2〉 ビジネスプロセスモデルを用いた情報システム
構築法
〈2･2･1〉 ビジネスプロセスモデリングと UML 変換
本方式では，ビジネスプロセスモデリングによる業務分
析により業務のボトルネックを検出・解消し，このビジネ
スプロセスを情報システムで稼動させるため，次のような
方法で，ビジネスプロセスモデリング及び UML 変換を行
う。
(１) ビジネスプロセスモデリング方式
ロセスモデリング工程の初めに作成する機能図について
は，機能分割を複数回行い，モデルの規模を大きなものか
ら徐々に小さくしていき，分割した各機能図に対して機能
を記述し，モデルを詳細にしていく。機能分割の際には，
プロセスが複数の機能図になるべくまたがらないように分
割を行う。このように規模の大きなモデルを独立した小さ
なモデルに段階的に分割し，詳細にしていくことで，各モ
デルの独立性を高められる。モデルの独立性が高まること
によって，業務に変更が生じた場合でも，業務に対応する
モデルの変更を行うだけで，対処することができる。
(２) UML 変換のガイドライン
UML 変換のガイドラインを述べる。変換のインプットは詳
細なプロセスを記述したビジネスプロセス図であり，アウ
トプットは UML 図である。インプットモデルとアウトプッ
トモデルの詳細レベルは同じである。変換の際には，変換
後のアウトプットモデルに必要なデータが何であるかを考
え，インプットモデルにパラメータとして与える必要があ
る。そこで，本ガイドラインでは，インプットモデルの作
成時に，付加するパラメータの指針となるような要素を後
工程を意識せず盛り込む方法を次のように定めた。
インプットモデルであるビジネスプロセス図の作成にお
いて，図内のプロセスで用いる人員などのデータについて
は，別途データ構造を可視化するモデルを用いてモデル化
し，ビジネスプロセス図と関連付けるか，図内のプロセス
にどのデータを用いるか直接記述する。このプロセス図に
関連付けた，あるいは付加したデータが，UML 変換に必要
Generation of UML ⑦
models
⑤ Preparation ⑥ Implementation
model for Conversion
conversion (Java)
Cancellation
of
bottleneck
on
business
process
図2 本方式によるシステム構築の流れ
なパラメータとなる。
UML 変換については，本ガイドラインを遵守すれば，
UML 変換の際に必要なパラメータをその場で考えること
なく変換工程を行うことができる。
〈2･2･2〉 構築の手順 本方式の流れを図 2 に示す。
以下，構築手順を述べる。
①現状を分析する。対象となるシステムに関し，複数の業
務にまたがっているビジネスプロセスを分析する。この
時，分析の対象は単にシステムのビジネスロジックだけ
ではなく，運用・利用する組織や部署の構成，更にそれ
ぞれの組織で扱うリソースまでを含める。
②分析結果をモデル化する。モデルは図 1 に示したように，
ビジネスプ 単に作成するだけでなく，相互に関係付けを行う。ここ
で作成されるモデルは As-Is モデルである。モデル化は組
織モデル，部署モデル，各部署で行うシステムの機能モ
デル，機能を表すプロセスモデル，というように大きな
モデルから段階的に詳細なモデルを作成していく。また，
変換のガイドラインに従い，プロセスで用いる人員など
のデータは，必ず各プロセス図に関連付けを記述する。
③作成した As-Is モデルをシミュレーションにより検証す
る。モデルはビジネスプロセスと組織構成が関連付けら
れているので，どの組織のどのプロセスに問題（ボトル
ネック）があるかといったことまで検証できる。要求分
本方式における 析に問題があると判断した場合は，検証結果から必要に
応じて要求分析をやり直す。
④シミュレーション結果から，ビジネスプロセスや組織に
問題があると判断した場合は改善を行う。改善方法とし
ては人員増減やプロセスの変更などがある。変更後，再
度シミュレーションを行い，問題が改善されたならば，
そのモデルは To-Be モデルとなる。
⑤作成した To-Be モデルについて，UML に必要なパラメー
タを設計者が配置する。パラメータには，②でガイドラ
インに従い各プロセスに記述したデータを用いる。
⑥パラメータを付加した To-Be モデルを UML のモデル要
素に変換する。変換によって生成された要素には，ツー
ルによってクラス図の関連要素や，ステートチャート図
のトランジションなど，足りないモデルの要素があるた
め，設計者がこれを補い，完成させる。
⑦完成させた UML をもとに Java による実装を行う。
1444 IEEJ Trans. EIS, Vol. 127, No.9, 2007
 プロセスモデル活用システム構築

Supplier company
⑥ Re-estimate
①
① Condition Presentation
of choice ② Condition
Buyer transfer of choice
company ③
Estimate Company A

Server

⑨ ④⑦
⑧ Estimate Company B

………
The supply Distribution of
person-in-charge The estimated estimated data Selection falling
reply which Re-estimate
final selection
is a company
⑤
Re-estimated request
near hope or

..
Omission
notification
⑩ Order in selection
Estimate
Company N
n

図3 部品調達システムのプロトタイプ
Fig. 3. A Parts Procurement Support System

System Use Case Class Diagram and

3. 本方式の試作と評価 specification Diagrams other various kinds
Construction

本方式を部品調達システムに適用し，評価を行う。部品 図4 UML による構築の手順

調達システムは，業務システム面の評価のために作成した Fig. 4. Construction flow with UML
プロトタイプシステム(7) (8)である。
試作は，次の 2 つの方式について行う。 ⑦システムは再見積の選考を行う。
(１) UML に基づいたシステムの構築（従来方式） ⑧選考に残った見積をバイヤーに送信する。
UML だけを用いてシステム構築を行う場合，すなわち，図 ⑨バイヤーの担当者による選考を行う。
2 における①，⑥，⑦の順序で構築を行う場合である。 ⑩最後に残ったサプライヤーを発注対象とする。
(２) ビジネスプロセスモデルからの構築（本方式） 〈3･2〉 従来方式による構築 部品調達システムにつ
ビジネスプロセスモデリングを用いてシステム構築を行う いて，UML を用い，図 4 に示す手順でシステムの設計から
場合，すなわち，図 2 における①から⑦まで行う場合であ 構築までを行った。
る。 UML 図としては，クラス図の他に，ユースケース図，シ
〈3･1〉 部品調達システムの概要と流れ 図 3 に部品 ーケンス図，コラボレーション図，状態遷移図を作成した。
調達システムの概要と業務の流れを示す。このシステムは， (１) ユースケース図の作成 ユースケース図作成に
e-マーケットプレイス上にて逆オークション形式を用いて おいては，アクターとして，バイヤー・サプライヤー・デ
買い手側企業（バイヤー）が調達したい部品の購入希望条 ータベースサーバを挙げた。ユースケースとしては「見積
件を提示し，複数の売り手側企業（サプライヤー）から条 入力」
「選考」
「通知」を挙げた。
件に合った企業選択の支援を行う。本調達システムは 1 回 (２) クラスの選定と図の作成 オブジェクト指向開
目の見積選考の後，選考に残ったサプライヤーに再見積を 発を行う際には，どのようなクラスを用いるかを決める必
依頼し，これらのプロセスを繰り返すことにより適切な業 要がある。分析段階では，本調達システムの流れを記した
者を選択していく。具体的には，以下のようである。 文章からクラスになりそうな単語を抽出した。抽出の結果，
①調達条件を Web で提示する。 〈3･1〉節に示したプロセスのうち，③の登録画面，④の送
②サプライヤーは調達条件を参照する。 信・見積・選考，⑤の電子メール，⑥の再見積がクラス候
③サプライヤーは登録画面からサーバに見積送信する。 補となった。このうち送信と選考は見積クラス内のメソッ
④バイヤーは選考条件をサーバに送信し，システムは見積 ドとし，再見積は見積クラスの利用により除外して，登録，
の選考を行う。ここでは見積書の中の単価・品質・取引 見積，電子メールの 3 つをクラスとした。作成した分析段
実績の 3 つから，見積の良し悪しを判断する。バイヤー 階のクラス図を図 5 に示す。
は選考結果から，良い見積を出したサプライヤーにもう (３) 設計段階でのクラス図の作成 設計段階では，登
一度見積を出してもらうか，各サプライヤーに直接交渉 録画面をバイヤー用とサプライヤー用の 2 種類用いた。更
するかのどちらかを決定する。 にデータベースサーバと電子メールを利用するクラスを設
⑤選考漏れ企業にはその結果を，選考に残った企業には再 置した。見積クラスは変更せずに，データの入出力を行い，
見積依頼を電子メールで通知する。 実際の業務を行うクラスとした。設計はここで終了し，実
⑥サプライヤーは再見積を送信する。 装に入ったところで見積クラスが 2 つ以上の登録画面を受

電学論 C，127 巻 9 号，2007 年 1445

 ④ A p p lic a t io n S e r v e r
B uyer
E s tim a t e ③ W eb (T o m c a t 4 .1 ) S u p p lie r
B row ser HTTP HTTP W eb
C om p any N u m ber R e g is t r a tio n S c r e e n c B row ser
C om pan y N am e
A dd re ss c

T e le p h o n e N u m b e r R e c e p tio n is t()
JD B C
E s ta b lis h m e n t Y e a r
U n it P r ic e D a ta b a se S erv er
⑤ (M y S Q L 3 .2 3 )
D a te o f M a n u fa c tu r e
E -M a il c
T ra ck R eco rd
S e le c tio n R e s u lt
R e g is tr a tio n () C o n te n ts D e te r m in a tio n ()
S e le c tio n () T r a n s m is s io n o f E -m a il()
A c q u is itio n () 図7 構築環境
図5 最初のクラス図 Fig. 7. Construction environment
Fig. 5. Class at the initial design level

Supplier Estim ate

Registration Screen
Corporate Inform ation:String
Registration
Estim ate:String
Selection Selection Result:String
Conditions:String
Receptionist() Data Creation()
Yes-no Decision() Data Acquisition()
Renew al Of Data()

Buyer
Registration Screen

Database Processing
図8 実行画面
The Contents of E-m ail
Fig. 8. An example of execution screen
E-m ail Processing

図6 UML 設計レベルのクラス図 Organizational View Data View

Data Base・The data object
Fig. 6. Class at UML design level showing documents etc.

Function View
Function View
け付けることができないことが判明した。そのため，設計 (Function Tree)

に戻り各登録画面を受け付けるクラスを新たに追加するこ
とにした。見積クラスはデータ管理だけを行う事とし，メ Process View
(eEPC(eEPC
Diagram・Bisiness Process Diagram)
ソッドの一部を新クラスに移した。作成した設計レベルの Diagram, Business Process Diagram)

クラス図を図 6 に示す。 図9 ARIS ビュー(組織図・

システムの動作と各クラスの関係を述べる。登録画面ク 機能図・プロセス図・データ図)
ラスでは，バイヤー及びサプライヤーからの各種データを Fig. 9. ARIS View (Organizational View・Function
受け付ける。見積クラスでは，見積情報の管理を行い，情 View・Process View・Data View)
報の登録，選考や取得作業を行う。メール関連のクラスで
は，サプライヤーへ通知を行う。見積・メール関連クラス べたモデリング方式と UML 変換ガイドラインをもとにモ
は，登録画面クラスに呼び出される形で働き始める。 デリングとモデル変換を行うに際しての，ビジネスプロセ
(４) Web システム 3 層構造での実装 部品調達シス ス図を作成・分析する手段，及びビジネスプロセス図をク
テムは，クライアント，Web サーバ＋アプリケーションサ ラス図，シーケンス図，状態遷移図などに変換する手段と
ーバ，データベースサーバで構成する 3 層クライアント／ して，IDSSheer 社のビジネスプロセスモデリングツール
サーバシステム上に構築した。図 7 にその構成を示す。 ARIS(9)を活用した。ARIS では，ビジネスプロセスを組織
クライアントでは，情報の表示や見積・会社情報の入力， 図・機能図・プロセス図・データ図から記述し，プロセス
結果の通知などが行われる。Web サーバは，クライアント 図が各図を統合する。なお，ARIS においてプロセス図は，
からの情報を受付け，アプリケーションサーバに渡し，逆 eEPC(Extended Event Driven Process Chain)図と，機能
に渡された情報をクライアントに送信する。アプリケーシ 図はファンクションツリーと呼ぶ。図 9 に ARIS で扱う各
ョンサーバは，ビジネスロジックを用いて見積情報の選考 図の相互関係を示す。
や処理を行う。データベースサーバは，クライアントから 図 9 において，ファンクションツリーは，1 つの部署で行
の各種情報や選考結果の管理を行う。プログラム環境は われる処理をいくつかの機能に分け，ツリー形式に階層表
Java を使用した。以上の環境のもとで，見積の募集から選 示したものである。特に，ARIS におけるファンクションツ
考の実行動作を確認した。実行画面を図 8 に示す。 リーではこれらの機能間の関係の表示ができる。
〈3･3〉 ビジネスプロセスモデルからの構築 eEPC 図は，ファンクションツリーで分けられた 1 つの機
〈3･3･1〉 ビジネスプロセスモデリングツールの活用 能を実現する処理の流れをフロー形式で表す。ARIS におけ
本プロトタイピングにおいては，
〈2･2･1〉節(１)(２)で述 る eEPC 図では，
「イベント」及び「ファンクション」の 2

1446 IEEJ Trans. EIS, Vol. 127, No.9, 2007

 プロセスモデル活用システム構築

つの要素を交互に配置することによってプロセスを表す。
ITLab Organizational View
「イベント」は，プロセスにおける情報オブジェクトの状態
やファンクションの起動を表し，
「ファンクション」は，情 Materials Business

報オブジェクトに対する行為や作業を表す。「イベント」 Confirm Accept

Parts Estimate
は，「ファンクション」実行のためのきっかけとなり，「フ Request
Examine Estimate
ァンクション」の実行は次の「イベント」を生み出す。 Estimate

データ図は，eEPC 図やファンクションツリーで用いるデ Decide

Condition
Report
Result
ータ構造をツリー形式で表すが，特に複雑な構造でない場 Delivery
Interview
Parts
合，各図に用意されているデータ要素を用いて表すことが
Contract
できるため，そのような場合，データ図自体は作成しない。 procedure

〈3･3･2〉 ビジネスプロセスモデリング 図 2 に示し Function Tree

Send
た本方式，及び〈2･2･1〉節に示したビジネスプロセスモデ Estim ate

リング方式と UML 変換ガイドラインに従い，ビジネスプロ Estim ate

Con firm ation
of content
Business

セスモデリング，ビジネスプロセスシミュレーション，及
びビジネスプロセス図からの UML モデル変換を行った。
No problem Problem
(１) モデルの作成 部品調達システムを運用する組 was detected

Estim ate Add to Req uest

Business Estim ate Business
織には，架空の会社である「アイティラボ」を想定し，そ file Estimate file of resubmitting

「営業」の 2 部門を想定する。
の下に「資材」 A dditional
Estim ate file com pletion
Req uest
com pletion

「アイティラボ」が 2 部門しか持たな
組織図については， Estim ate Notification B usiness
of acceptan ce ：Event ：Data
い単純な組織であるため，ファンクションツリーにて代用 completion
：Function Element
N otification com pletion
することとした。よって，作成したファンクションツリー of acceptance com pletion

は，機能図兼組織図である。ファンクションツリーによっ
てシステムの大まかな機能分割を行い，eEPC 図によってそ
れぞれの機能について段階的なモデリングと詳細化を行っ
た。図 10 に ARIS を用いて作成した部品調達システムのフ
ァンクションツリー，及び見積受付の eEPC 図を示す。
ファンクションツリーでは，｢資材｣と「営業」の各部門
に，調達を行う機能が計９つ作成された。いずれの機能も
図 3 の部品調達システムの流れから選んだものである。各
機能について，eEPC 図を用いてプロセスを詳細化した。
作成した eEPC 図について説明する。例えば，図中の「見
積受付」機能の場合では，
「見積が送付される」イベントに
よりプロセスが始まり，
「内容の確認」ファンクションが開
始される。内容の問題有無によりプロセスは２つのイベン
トのどちらかが起動される。以後，プロセスは進んでいき，
最後の「受付完了の通知完了」か「依頼完了」のどちらか
のイベントでプロセスは終了する。ファンクションの横に
線でつながっている楕円は組織・人物を表し，企業の中で
誰がファンクションを遂行するかを，またイベント以外で
ファンクションに矢印で連結されているモデル要素は，フ
ァンクションが扱うデータを表している。図中の分岐点に
ある×印は排他的論理和を示す。
ファンクションツリーと eEPC 図の関連については，図
10 の「Link」を示す要素を配置することによって表す。図
10 では，ファンクションツリーの「見積受付」に Link が
配置され，Link 先に「見積が送付される」に始まる eEPC
図が形成されている。
今回作成した eEPC 図は，図 10 で示したファンクション
ツリーの各ファンクションのうち，「部品の確認」「見積の
検討」「希望条件の決定」「見積受付」「見積依頼」「結果報
： Link
eEPC Diagram
図 10 ファンクションツリーと eEPC 図
Fig. 10. Function Tree and eEPC Diagram
告」の 6 つについてである。他の「部品の納入」
「面談」
「契
約手続き」は，部品調達システム固有の機能ではないため，
モデルを作成しなかった。
(２) ビジネスプロセスシミュレーション 作成した
eEPC 図についてシミュレーションを行った。シミュレーシ
ョン期間は 1 週間，勤務時間は AM8：30～PM5：30，休み
時間は PM0：00～PM0：45，プロセスの発生数は 1 日 65
プロセス，プロセスの発生頻度は 1 日 4 回として行った。
eEPC 図を作成しなかった部分のシミュレーションについ
ては，設定した想定処理時間をパラメータとして与え，実
行した。今回は「部品の納入」には 2 日，
「面談」
「契約手
続き」には 2 時間という想定処理時間を設定した。シミュ
レーション結果から，ボトルネックの検出と，モデルの改
善を行った。図 11 にシミュレーション結果を示す。
図 11 の棒グラフは 2 つの成分から構成されている。左側
がファンクション(eEPC 図で使用されているファンクショ
ンであり，図 10 で示したファンクションツリーのファンク
ションではない)当たりの延べ動的待機時間であり，右側が
処理時間の合計である。図 11 は，すべての eEPC 図に属す
るファンクションのうち，特に大きい動的待機時間を記録
したファンクションを抽出したものである。すなわち，こ
れら 4 つのファンクションはボトルネックである。図 11 に
表示していない他のファンクションは，動的待機時間・処
理時間とも 0～100(min)の間であった。

電学論 C，127 巻 9 号，2007 年 1447

 Tim e 80 0 Company Number
(m i n) T o ta l o f
70 0 dy n am ic Price Start
s ta n db y t im e b y
60 0 a fun c ti o n Delivery Date
Estimate selecting
T o ta l o f
50 0 pr o c es s in g ti m e Kind of Parts
40 0 Quality
Extract
Compare Materials
30 0
estimate
estimate
20 0
10 0
0 S el ec t io n o f F a x e d th e F a x e d th e F a x e d th e
Estimate
e s ti m a t e r e q u es t f or r e q u es t f or r eq u es t f or Price Extracted Estimate run out , and
r e qu e st q u o ta t io n q u o ta t io n q u ot a t io n
co m p an y to A to B to C estimate Selection was ended
co m p an y co m pa n y co m pa n y Delivery Date Condition
Kind of Parts of Hoping
図 11 シミュレーション結果 Quality Decide next
Compare Materials
Fig. 11. Simulation result judging system
estimate

Company Number
Estimate Comparison
Decided next
T im e 800
( m in ) Pass or Fail completion judging system
700
600 Add
pass or fail Materials Report result
500
400 Additional
：Input Parameter
300 result
：Next Phase Element completion
200
100 図 13 クラスを追加した eEPC 図
0 S e l ec t io n of
e s ti m a t e
F a x e d th e
r e q u e st f o r
F a x ed t he
r e q u e st fo r
F a x ed t he
r e q u e s t fo r Fig. 13. Additional result completion
re qu e st q u o ta t io n q u o ta tio n q u o ta ti on
c o m pa n y to A to B to C
co m pa n y c om p a n y co m pan y

図 12 改善後のシミュレーション結果
Estim ate C ondition of
Fig. 12. Simulation result after improvement H oping

Price Price of H oping

C om pany N um ber D elivery D ata of H oping
ボトルネックが検出された各モデルに対して改善を施し Pass or F ail Q uality of H oping
D elivery D ate K inds of Parts
た。まず，見積依頼書の FAX 送信に関しては，処理を人手 Q uality C om pare Estim ate
K inds of Parts
から自動化した。また，モデルにおいて見積送信が 1 社し Extract Estim ate
か行われないことがある，という不備を発見したので修正 Add Pass or F ail

を加えた。作成した To-Be モデルに対して再度シミュレー 図 14 生成されたクラス図

ションを行った。結果を図 12 に示す。
図 12 の結果より，動的待機時間のバーが全体的に短くな
っており，ボトルネックが改善されていることが分かる。
(３) モデル変換
て，作成し改善を施した各 eEPC 図をそれぞれ UML へ変
換した。図 13 にクラス変換可能状態の eEPC 図を示す。
ARIS によるクラス変換では，ファンクションにメソッド
及び属性の指定を行い，クラス要素を追加した eEPC 図を
用意する。この eEPC 図をインプットとして，追加したク
ラス要素はそのままクラス要素として，ファンクションは
クラス要素のメソッド要素として，それぞれ一対一対応に
変換される。図中では，点線で囲んだ箇所が追加したクラ
ス要素及びメソッド要素となるファンクションである。な
お，今回，本方式において，予め用意するクラス要素であ
った属性は，図中のデータ要素であるモデルの属性を参照
し，そこからすべて選択したため，変換時に改めて要素を
一から考える必要はなかった。
この図で加えられているクラスは「見積」と「希望条件」
のクラスであり，それに付属する形で「価格」や「品質」
の属性もまた接続されている。1 ヶ所クラスが無いファンク
ションもあるが(「結果報告する」は遷移先の eEPC 図を示
すモデル要素であり，ファンクションではない)，これはシ
ステムが直接かかわる部分ではないので除外した。この図
Fig. 14. Generated Class Diagram
をモデル変換にかけてクラス図を生成した。図 14 に生成し
ARIS のモデル変換機能を利用し たクラス図を示す。
作成した希望条件と見積の各クラスとその属性，メソッ
ドが生成された。ここでは 2 つのクラスについて述べたが，
実際には 6 つの eEPC 図への追加が行われ，クラスが生成
されている。完成したクラス図を元に，図 7 で示した 3 層
構造・環境で Java による構築を行い，動作を確認した。
〈3･4〉 従来方式と本方式におけるクラスの比較 本
方式における eEPC 図からの変換による UML クラスと，
ビジネスプロセスモデルを介さない従来方式による UML
クラスとの比較結果を表 1 に示す。
表 1 に示す結果は，図 10 で示したファンクションツリー
の各ファンクションのうち，「部品の確認」「見積の検討」
「希望条件の決定」「見積受付」「見積依頼」「結果報告」そ
れぞれのファンクションを実現するのに要したクラス数を
本方式と従来方式で比較したものである。
表 1 より，
「部品の確認」ファンクションを除くすべての
クラスが同数になった。つまり，ビジネスプロセスモデリ
ング経由で作るクラス数と手動設計によって作るクラス数
もあまり変わらないことを示している。しかし，
「部品の確
認」ファンクションにおいては手動設計時にはクラスを作

1448 IEEJ Trans. EIS, Vol. 127, No.9, 2007

 プロセスモデル活用システム構築

表1 ファンクションに関連するクラス数の比較
Table 1. Comparison of class that composes function
Function UM L generation by person UM L generation by BPM
Confirm Parts Off the subject
Examine E stimate
Decide Condition
Accept Estimate
Request Estimate
Report Result
成していなかったが，ビジネスプロセスモデリング経由で
は 2 個の部品に関するクラスが生成された。この結果より，
手動設計による従来方式ではシステムに必要な部品に関す
るクラスを見逃してしまった可能性がある。
更に，両方式で作成したクラスの属性とメソッドについ
ては，本方式の方が属性は詳細に，メソッドは細かく分割
されるという結果になった。両方式で作成したクラスのう
ち，表 1 の「見積書の検討」ファンクションを構成するク
ラスを比較対象として説明をする。対象となるクラスは，
両方式で共通に作成した「見積」クラスである。
図 6 に示した従来方式で作成した
「見積」
クラスでは，
「会
社情報，見積情報，結果」という属性であったが，図 14 に
示した本方式で作成した「見積」クラスでは，
「価格，会社
情報，合否，納期，品質，部品の種類」とほぼ同じ内容で
はあるが，詳細になっている。メソッドについては，従来
「見積データ作成( )」
方式では， 「見積データ取得( )」
「見積
データ更新( )」というメソッドであったものが，本方式では，
「見積合否結果を加える( )」というものに変わっている。従
来方式では，
「見積」クラスでデータの作成・取得・更新を
行っていたのだが，データの操作が別クラスに分割され，
本方式の「見積」クラスでは，合否結果のみを取得するよ
うになっており，メソッドの機能としてはより細かくなっ
ている。
4. 評価と考察
〈4･1〉 ビジネスプロセスモデリングの効用
達システムにファンクションツリーと eEPC 図の 2 種類の
図にて，本方式のモデリング方式に従い，ビジネスプロセ
スモデリングを行ってきた。
ファンクションツリーの設計はシステムのファンクショ
ンを配置するため，UML におけるユースケース図の作成と
同様の作業であり，ファンクション設計がその後のシステ
ム設計を左右する。ファンクションの選択には明確な指針
がないため，UML のユースケース記述からのユースケース
抽出が妥当であると考える。ファンクションは，営業部で
は計 5 つ，資材部では計 4 つになり，双方の部署で部品調
達システムが直接関与しないファンクションは（
「部品の納
入」「面談」「契約の手続き」），調達業務の全体の流れを考
え，外部システムのファンクションではあるが，部品調達
システムに組み込んだ。結果，システム内外で 9 個のファ
ンクションができた。
eEPC 図の設計は，ファンクションとイベントの 2 つの要
2
2 2
2 2
2 2
4 4
3
3 要がない。このことによって，設計者の判断を 1 つの機能
部品調
素の繰り返しで構成される単純なものであり，機械的に記
述できた。
本ビジネスプロセスモデリングは，段階的にモデリング
を行い，1 つの機能について順に設計していくという点にお
いて，従来の手動設計とは異なり，システム全体のユース
ケースの機能を満足するようなクラスをその場で考える必
を実現することのみに注目させることができる。システム
全体の機能の実現度合いはビジネスプロセスシミュレーシ
ョンによって確かめることが可能である。また，シミュレ
ーションにおいては，図 11，12 で示したようにボトルネッ
クの検出と機能追加などの改善が可能である。これらの半
機械的な設計を行う本方式の方が従来方式に比べて，人の
システムに及ぼす影響が少なくなると考えられる。
〈4･2〉 モデル変換の効用 手動設計による UML 設
計では，システムの流れからクラスを抽出し，属性・メソ
ッドを加えていく方法をとったが，ビジネスプロセスモデ
リングを経由する方法では各ファンクションからクラスを
考え出す方法をとる。従来方式によるクラス図の作成には，
ユースケースからクラスになりそうな単語をできるだけ抽
出してから絞り込んでいく関係上，不必要なクラスが出た
り，必要なものを削ったり，見落としてしまう可能性があ
る。
ビジネスプロセスモデリングにおけるモデル変換では，
プロセスの流れが明確になっているため，的確で無駄のな
いクラス生成が可能になる。更にクラス図作成に関しても，
eEPC 図に加えたクラスをそのまま作成エディタに持って
来ることができるので，手間が省ける。ファンクションか
らクラスとともに属性を決めるが，この属性からクラスの
修正するべき点が発見できることも期待できる。また，本
モデリング方式では，UML モデル変換ガイドラインを策定
しており，本ガイドラインに沿って作成されるビジネスプ
ロセスモデルは，UML クラス変換において付加するパラメ
ータの指針となるモデル要素が予め含まれている。パラメ
ータ設定の際には，すでに作成したモデル要素を対応させ
るのみで工程を進めることができた。
表 1 に示したクラス数，及びクラスのメソッドと属性の
相違結果について考察する。表 1 において従来方式で生成
されなかった 2 個のクラスは，部品の在庫確認を行うクラ
スである。これらのクラスがないと，バイヤーは現在どの
程度部品を持っており，どの程度更にサプライヤーを選ぶ
必要があるのかを把握することが困難になり，そのクラス
は実際の利用を考えると，必要なものであり，見落として
いたクラスであったと言える。
属性とメソッドについては，本方式では，属性はほぼ同
じ内容ではあるが，細かく設定され，メソッドは詳細な分
割が行われていることから，本方式の方が細かで業務に適
した機能分割ができていると言える。従来方式では，本方
式におけるビジネスプロセスモデリング工程の機能分割を
行う段階で各クラスの設計を行うため，設計者は，各機能

電学論 C，127 巻 9 号，2007 年 1449

を実現できると考えられるものを属性やメソッドとして設
定していた。しかし，本方式では，機能分割後，更にその
機能ごとにビジネスプロセスを記述し，そのビジネスプロ
セスから「実際に必要となるデータと業務ファンクション」
が属性とメソッドになる。結果として，提案手法で生成さ
れる属性やメソッドは業務に対応した詳細なものになった
と考えられる。
〈4･3〉 開発期間への影響
響を比較するため，従来方式と本方式について，モデリン
グ期間と実装期間の工数的な評価を行った。両方式の構築
は，UML による設計経験と Java プログラミングの実装経
験を持つ同一人物が行った。
構築に要した期間は，下記の通りである。
・モデリング 従来方式：約 3 ヶ月，本方式：約 2 ヶ月
・実装 従来方式：約 6 ヶ月，本方式：約 5 ヶ月
モデリング期間の差は，ビジネスプロセスモデリングと
UML 分析の方式の違いによるものであり，実装期間の差
は，従来方式で発生したクラスや機能の見落としによる実
装工程での後戻りによるものである。クラスの見落としが
なく，再設計も生じなかったことから，本方式のビジネス
プロセスモデリングによる分析設計により，構築期間が従
来方式に比べて短縮された効果があったと考えられる。
5. ま と め
本稿では，ビジネスプロセスモデルを用いた情報システ
ム構築法を提案し，部品調達システムのプロトタイプを対
象として評価を行った。本方式は，ビジネスプロセスを段
階的に機能分割してモデリングし，その結果を UML のモデ
ルに変換し実装に繋げていく開発方式である。本方式に則
って，ファンクションツリーと eEPC 図を作成し，そのま
ま UML に変換すれば，以降，UML モデルによる設計を行
うことができた。また，本方式は，従来方式に比べて，ク
ラスの見落としも実装工程での後戻りもなかったことか
ら，開発期間の短縮に繋がった。
今後は，次の作業を継続していくことにしている。
(１) 本方式に MDA(Model Driven Architecture)(10)技術
を盛り込み，BPM 技術と連携させ，実装前にモデルの動作
検証を行う方式の研究を進めていく(11)。
(２) 他の情報システムへの適用を行い，本方式が一般的
に適用可能なものであるかについて，効果を確かめる。
（平成 18 年 9 月 16 日受付，平成 19 年 3 月 8 日再受付）
(４) 電気学会ワークフロー調査専門委員会：「ワークフローの実際」，日
科技連
(５) Y. Kojima, S. Kitajima, T. Kaminishi, H. Koizumi, and K. Ban :
“An Implementation of A Parts Procurement Support System
based on Business Process Modeling and Its Evaluation”, IPSJ
IS-90 Report, Vol.2004, No.116, pp.9-16 (2004) (in Japanese)
小島義幸・北島聡史・上西 司・小泉寿男・坂 和磨：「ビジネスプ
ロセスモデリングによる部品調達システムの構築とその評価」，情報
処理学会 IS-90 研究報告, Vol.2004, No.116, pp.9-16 (2004)
(６) S. Kitajima, Y. Nakamura, T. Kaminishi, H. Koizumi, and K.
本方式の開発期間への影 Ban : “A Method of Information System Development based on
Business Process Modeling”, IPSJ DPS-119 Report, Vol.2004,
No.89, pp.15-20 (2004) (in japanese)
北島聡史・中村義幸・上西 司・小泉寿男・坂 和磨：「ビジネスプ
ロセスモデリングによる情報システム構築の一手法」，情報処理学会
DPS-119 研究報告, Vol.2004, No.89, pp.15-20 (2004)
(７) T. Ishikawa, T. Asada, J. Kurihara, I. Nakamura, H. Shiozawa,
and H. Koizumi : “A Business Model of Parts Purchasing System
and Its Evaluation on the Implementation”, IPSJ DPS
Workshop, pp.133-138 (2001) (in japanese)
石川俊之・浅田孝利・栗原 潤・中村一郎・塩澤秀和・小泉寿男： 「自
動選考機能を持つ部品調達ビジネスモデルと構築評価」，情報処理学
会 DPS ワークショップ，pp.133-138 (2001)
(８) J. Kurihara, H. Koizumi, T. Ishikawa, and T. Dasai : “A Method
of EC Model Implementation Using Web Service”, T.IEE, Vol.124,
No.1, pp.39-47 (2004-1) (in Japanese)
栗原 潤・小泉寿男・石川俊之・太細 孝： 「Web サービスを活用し
た EC モデルの実装方式」，電学論 D 124, 1, pp.39-47 (2004-1)
(９) ARIS IDS Scheer, http://www.ids-scheer.co.jp
(10) M. Yamada : “Introduction to Model-driven Development”, IPSJ
Vol.45, No.1, pp.3-9 (2004) (in Japanese)
山田正樹：「モデル駆動開発とその周辺」，情報処理学会誌 Vol.45,
No.1, pp3-9 (2004)
(11) S. Kitajima, Y. Nakamura, T. Kaminishi, H. Koizumi, and K.
Ban : “An Information System Development Method connecting
Business Process Modeling with Executable UML and its
experimental evaluation”, IPSJ DPS-121 Report, Vol.2005,
No.89, pp.1-6 (2005) (in japanese)
北島聡史・中村義幸・上西 司・小泉寿男・坂 和磨： 「ビジネスプ
ロセスモデリングと実行可能 UML を連結させた情報システム構築
法の試作と評価」，情報処理学会 DPS-121 研究報告, Vol.2005,
No.3, pp.1-6 (2005)
大 川 勉 （正員） 1978 年大阪大学基礎工学部情報工学
科卒業。同年三菱電機（株）に入社，現在に至
る。ソフトウェア生産技術の研究開発，EOA
技術開発，オブジェクト指向技術開発，情報シ
ステムインフラ（ネットワーク，セキュリティ，
アクセス制御，ワークフロー，開発方法論など）
の技術開発，基盤システム構築に従事。情報処
理学会会員。

上 西 司 （非会員） 1983 年 2 月 6 日生。2005 年 3 月東

京電機大学卒業。同年東京電機大学大学院理工
文 献 学研究科情報システム工学専攻入学。2007 年 3
月修士課程修了。
(１) Object Management Group，http://www.omg.org
(２) 戸田保一・飯島純一：「ビジネスプロセスモデリング」，日科技連
(３) H. Seidelmeier：“Prozessmodellierung mit ARIS”，BNN Inc.
坂和磨（監訳） ：
「ARIS ビジネスプロセスモデリング」，ビー・エヌ・
エヌ新社

1450 IEEJ Trans. EIS, Vol. 127, No.9, 2007

 プロセスモデル活用システム構築

小 島 義 幸 （非会員） 1980 年 5 月 3 日生。2003 年 3 月東 小 泉 寿 男 （正員） 1961 年，東北大・工・通信卒業。同

京電機大学卒業。同年東京電機大学大学院理工 年三菱電機（株）入社。基本ソフトウェア開発，
学研究科情報システム工学専攻入学。2005 年 3 ネットワーク情報システム基盤，大規模応用シ
月修士課程修了。 ステムの開発に従事。1998 年より，東京電機
大学理工学部教授。博士（情報科学）。情報処
理学会，電子情報通信学会，情報処理学会フェ
ロー。

平 林 秀 一 （非会員） 1983 年 8 月 10 日生。2006 年 3 月

東京電機大学卒業。同年東京電機大学大学院理
工学研究科情報システム工学専攻入学。現在，
修士課程在学。

電学論 C，127 巻 9 号，2007 年 1451