なぜ超高速開発が話題になるのか~キーワードはビジネスルール管理システム(BRMS)
最近なぜ超高速開発が話題になるのか、何となく分かった気がした。
ラフなメモ書き。
間違っていたら後で直す。
【元ネタ】
超高速開発先進国、知られざる韓国企業の実態 - サムスン電子に見る「威力」:ITpro
俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第3回 ビジネスの俊敏性を実現する:ITpro
俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第4回 スマートなシステムを生み出す:ITpro
ITエンジニアのためのビジネスアナリシスを読んだ - 勘と経験と読経
ビジネスルールとビジネスプロセス(その1) | 株式会社KBマネジメント
ビジネスルールとビジネスプロセス(その2) | 株式会社KBマネジメント
ビジネスルールとビジネスプロセス(その3) | 株式会社KBマネジメント
ビジネスルールとビジネスプロセス(その4) | 株式会社KBマネジメント
ビジネスルールとビジネスプロセス(その5) | 株式会社KBマネジメント
ビジネスルールとビジネスプロセス(その6) | 株式会社KBマネジメント
ビジネスマンのためのビジネスルール入門① - blazeconsulting
ビジネスマンのためのビジネスルール入門② - blazeconsulting
ビジネスマンのためのビジネスルール入門③ - blazeconsulting
ビジネスマンのためのビジネスルール入門④ - blazeconsulting
【1】最近、超高速開発コミュニティができたりして、すごく活発だ。
何も知らないと、90年代初頭のCASEツールの再現、2000年代前半のモデル駆動開発(MDA)によるモデルからのソース自動生成を連想させて、何となく否定的なイメージを持ってしまう。
実際、超高速開発コミュニティで紹介されているツールを見ると、モデルからソースを自動生成するツールのように思えて、過去のツールと何が違うのか、分かりにくかった。
しかし、超高速開発が提唱される背景には、ビジネスプロセスからビジネスルールを分離し、ビジネスルールから業務プロセスを自動生成する方向があるようだ。
【1-1】たとえば、ビジネスマンのためのビジネスルール入門① - blazeconsultingでは、こんな文章から始まる。
(引用開始)
昨年あたりから、IT業界においてようやくBRMS(ビジネスルール管理システム)に対する熱いまなざしが注がれるようになってきました。ITに従事する方にとっては、超高速開発を実現するツールとしての期待も多いかと思います。
(引用終了)
ビジネスルールとビジネスプロセス(その1) | 株式会社KBマネジメントは下記の通り。
(引用開始)
最近、ビジネスルールが重要だという話を耳にすることが多くなりました。
日経コンピュータ誌でも「超高速開発が日本を救う」などというエキセントリックなタイトルでビジネスルール管理システム(BRMS)を大々的に取り上げたりもしています(2012年3月15日号)。
また直近では本格的にビジネスルールを扱った「ITエンジニアのためのビジネスアナリシス」(日経BP)が出版されるなど、多方面で注目を集めています。
(引用終了)
つまり、ビジネスルールを対象とするビジネスルール管理システム(BRMS)こそが超高速開発が目指すもののように思える。
なぜ、ビジネスルールがそれほど重要なのか?
【1-2】ビジネスルールとビジネスプロセス(その2) | 株式会社KBマネジメントによれば、従来の業務システムでは、ビジネスルールが業務プロセスに入り交じって、保守性が低下してしまうのが最大の問題だった。
(引用開始)
業務アプリケーション= プロセス + ルール + データ
のはすが、実際のアプリケーションでは
業務アプリケーション= プロセス[ルール含む] + データ
だったのです。
(引用終了)
実際、我々が受託開発で作る業務システムは、複雑怪奇なシロモノだ。
DOAの普及によって、データとプロセスは分離できた。
しかし、いくらオブジェクト指向で作ったとしても、MVCモデルなどの3層アーキテクチャとして作ったとしても、業務プロセスと業務ルールは入り交じっているのが普通。
たとえば、「10万円以上の買い物をしたら5%値引きする」「経費申請を提出したら上司が承認しなければ次プロセスに進めない」などのビジネスルールは、業務ロジックに密接に絡んでいて、モデルという一つの塊に密結合されている。
だから、運用保守の期間が長くなるほど、修正工数は増大していくのが普通。
ユーザから見れば、たったこれだけの機能追加でなぜこんなに時間がかかるのか、不審に思ってしまう現象はどこでも見られるだろう。
特に最近は市場環境の流れが速いのに、その変化に業務システムが追いつけていない現状がある。
そこで、ビジネスルールをプロセスから分離して、業務システムの保守性を高められたとしたら、どんなメリットがあるか?
アプリケーションコードをいじらず、設定ファイルの入れ替えだけでシステム運用ができるだろう。
あるいは、ビジネスルールは業務に直結した知識のため、IT技術者ではなく、業務の専門家ないし業務の担当者が自身で書いて、システムを運用することもできるかもしれない。
つまり、業務システムの保守性の向上が期待できるし、ビジネスルールはエンドユーザコンピューティングで対応できる可能性を秘めている。
BRMSでは、それらビジネスルールをビジネス・プロセスから分離し、部品交換のようにつなげる発想のように思える。
ビジネスルールとビジネスプロセスを分離する発想が有効な業界は、保険や証券などの金融商品のビジネスルールなどがあるらしい。
【1-3】最近の事例では、日経ITProの記事のように、サムスンがBRMSを導入し、業務プロセスの変革を素早く行えたらしい。
韓国製のBRMSとしてイノルールズ社のinnoRulesがかなり有名らしい。
ビジネスルールとビジネスプロセス(その2) | 株式会社KBマネジメントによれば、こんな内容が書かれている。
(引用開始)
このような状況で、ルールがプロセスに混在したままアプリケーションコードを作成してしまうと、ビジネスの環境変化に対応することが大変困難です。
ルールだけ変更するためにも、システム開発するのに匹敵するだけの工数を必要とすることになりかねません(すべてのプロセスを見直す必要が生じた場合)。
競合状況も悪化します。
ルールを環境に合わせるのに数か月かかってしまうと、競合状況も一変してしまいます。競合に差をつけられるだけでなく、顧客満足度にも影響が出るかもしれません。
スポンサーの期待からもほど遠いものになるでしょう。
社員のリストラや工場売却などが現実味を帯びてきます。
かつての日本を代表する超一流メーカーの凋落ぶりは大変歯がゆいものがあります。韓国のサムソンに大きく差をつけられている要因かもしれません。
(引用終了)
日経BPの記事でも、サムスンがBRMSを導入して結果を出している内容を宣伝していたから、日本の製造業の凋落ぶりと対比させているのだろう。
たしかに、ハードウェアよりもソフトウェアを重視していない日本の現状と被って見える。
だからこそ、BRMSによる超高速開発が最近注目されているのだろう。
【2】でも、BRMSはそう簡単なシロモノではない。
ビジネスルールとビジネスプロセス(その4) | 株式会社KBマネジメントでは、BRMS導入の課題を2つ上げている。
一つは、ビジネスルールそのものを整備するのが大変なこと。
もう一つは、ビジネスルールはビジネス戦略に依存しているため、そのトレース(追跡)の確保が難しいこと。
前者は、ユーザ企業の業務ルールを洗い出すだけでなく、漏れ無く矛盾なく、整理する必要がある。
しかし、たとえば、製造業の場合、各工場で標準プロセスがあったとしても、作る製品は微妙に違うため、それに適したプロセスやルールを作りこんで、製品の品質を維持している時が多い。
つまり、実際の現場の業務は、各現場でバラバラで、ビジネスルールを統一化することすら難しい場合が多い。
後者は、ビジネスルールがなぜ存在するのか、を突き詰めると、それは経営戦略にたどり着くので、ビジネスルールは全て、ビジネス戦略から派生するはずである。
しかし、ビジネスルールはたくさんあり、しかも複雑怪奇だから、そのルールが何故必要なのか、を逐一理由付けて整合性をとっていくのは、業務にかなり詳しい専門家でなければ難しい。
特に最近は、内部統制やISMSの情報セキュリティ管理のように、法律上決まっているから、という理由で、無駄に複雑な機能が実装されている場合が多い。
したがって、現場の運用に詳しいだけでなく、最近の法体系の変化にも詳しくなければ、それらビジネスルールの正当性を保証するのは難しい。
個人的には、業務システムの要件の大半は、内部統制・ISMS・会計監査・システム監査などのような法律があるために、複雑怪奇な仕様となった業務システムが作られてしまうように思えて仕方ない。
その業務要件の正当性はIT技術者が保証するのではなく、システム監査人や公認会計士の都合で作っているように思えて仕方ない。
【3】BRMSが注目される理由として、BABOKとの関連もあげられる。
BABOKは僕は知らないのでなんとも言えないが、ITエンジニアのためのビジネスアナリシスを読んだ - 勘と経験と読経を読むと、BABOKを使って設計されるシステムの一事例としてあげられるようだ。
「ITエンジニアのための ビジネスアナリシス」という本が有名らしい。
(引用開始)
・BABOK V2ベースで言うならば「エンタープライズアナリシス」と「要求アナリシス」あたりの知識エリアが記述の対象だと思う。
・ざっくりと整理すると2つの段階に分かれると思う。
・「ポリシー憲章」を作成してビジネスの目的とゴールを整理する流れ(「エンタープライズアナリシス」的)
・「ビジネスルール」の導出を中心とした各種の分析アクティビティ(「要求アナリシス」的)
・最終的には「ビジネスルール」から(ITシステムを作るための)「ビジネス要求」を導出する。
・また「ビジネスルール」は継続的にルールブックとしてマネジメントされる。
(引用終了)
【4】以上のように、BRMSが海外では使われて結果を出している事例があること、BABOKの設計事例としてあげられていることから、BRMSとそれを実装する超高速開発が注目されているといえる。
しかし、BRMSの一番の疑問点は、どうやって実装するのか、だ。
ITエンジニアのためのビジネスアナリシスを読んだ - 勘と経験と読経にも書かれている。
(引用開始)
疑問点:どうやって実装するか
本書で紹介されているビジネスルール中心の分析は興味深いし、実際に活用してみたいと思えるような内容なのだけれども、1点気になるのは「どうやって実装するのか」である。
(引用終了)
【4-1】直感的には、ビジネスプロセスからビジネスルールを分離するモデルは、ファウラーのアナリシスパターンである知識・操作パターンに相当するように思える。
つまり、操作レベルがビジネスプロセス、知識レベルがビジネスルールに相当する。
しかし、知識・操作パターンの実装は、かなり難しいと思う。
素人的考えでは、Strategyパターンで入れ替えればよいように思えるが、ビジネスルールというメタクラスでビジネスプロセスを制御しなければならないからだ。
つまり、条件分岐やルールをメタモデルとして表現できるメタプログラミング、ないし、リフレクションが必要になると思う。
【4-2】また、Webシステムの基本アーキテクチャであるMVC2モデルや、渡辺式DOAの3要素分析法では、ビジネスルールはどこで表現されるべきなのか、という疑問がある。
MVC2モデルならば、Modelにビジネスルールが含まれるだろう。
しかし、Modelには業務ロジック、つまり、業務プロセスも含まれているから、ビジネスルールと密結合にならざるを得ない。
また、渡辺式DOAの3要素分析法では、ロバストネス技法と対比させると、
・業務=バウンダリ、インターフェイス、業務マニュアル
・機能=コントローラ、システムの機能そのもの
・データ=永続データ、マスタやトランザクションデータ
という3層構造になるが、ビジネスルールはどこに存在するのか?
ビジネスプロセスは「機能」に含まれる。
もし、ビジネスルールもシステム化対象とすれば、「機能」に含まれてしまい、密結合にならざるを得ない。
XEAD Driverなどの開発の背景を読み解くと、ビジネスルールはおそらく「データ」で実現されるのだろうと想像する。
つまり、「10万円以上の買い物は5%引き」などのビジネスルールは、パラメータとしてDBに設定してしまい、自由に変更できるような仕組みにするのだろう。
もちろん、メタプログラミングないしリフレクションで、RDBから取り出したパラメータ値でビジネスルールを生成する実装方法になるだろう。
ビジネスルールがRDBに格納されるような構造ならば、確かにユーザが業務ルールをパラメータという宣言的データとして作成すれば、システムを停止することなく、運用できる利点がある。
ただし、ビジネスルールがRDBの中でメタデータとして登録されてしまうために、ビジネスルールをモデルとして理解するのはとても難しくなる弱点もある。
【4-3】具体的な実装方法としては、ビジネスルールをXMLファイルとして書き下ろし、そのXMLファイルをロードしたらビジネスルールが生成される方法があげられるだろう。
つまり、ビジネスルールをDSLで書く手法が考えられるだろう。
DSLの一番簡単な例は、JavaのビルドツールAntだ。
XMLファイルに、ビルド手順を宣言的に書く。
同様に、XMLファイルへビジネスルールを宣言的に書けばいい。
似たような事例として、BPMN(ビジネスプロセスモデル)をGUIベースで書いたらXMLで保存できるツールもある。
また、最近ならば、DSLとしてXTextが有名だろう。
Xtext - Language Development Made Easy!
つまり、ビジネスルールを同様にDSLで実装し、エンドユーザはGUI上で入力できるようなI/Fを作ればいいだろう。
但し、この手法は、ERPではパラメータ設定としてよくやる方法であり、使いにくくなることであまり評判は良くなかったように思う。
最近はまた変わってきたのだろうか?
【5】自分の理解でBRMSについて考えてみたが、今後、どのように発展していくのか、いろいろ考えてみたい。
| 固定リンク
「モデリング」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い(2024.08.31)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「ソフトウェア」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
「ビジネス・歴史・経営・法律」カテゴリの記事
- ビジネス書の名著はどれ?(2023.09.18)
- 営業は顧客の”購買代理人”である(2023.08.16)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
- ChatGPTで起きている事象の意味は何なのか(2023.04.02)
「経済学・ERP・財務会計」カテゴリの記事
- ビジネス書の名著はどれ?(2023.09.18)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
- 経営戦略とIT戦略をつなぐ鍵は何なのか(2023.01.04)
- 計量政治学と計量経済学の考え方の違い(2022.10.02)
コメント