ビジネスモデリングと“見える化”のいま：「ITアーキテクト塾」レポート（1）（2/3 ページ）

[トレッフェ 「岩崎史絵」，＠IT]

モデリングへの関心は業界全体で向上

　第2部では、「モデリングの重要性」「BPMNの利点」「UMLとの違い」「ビジネスモデリングが開発に与える影響」について議論が進められた。

　参加者は、第1部で講演を担当した明庭氏、豆蔵 取締役副社長 山岸耕二氏、マイクロソフト エンタープライズプラットフォーム本部 プラットフォーム戦略部 安藤浩二氏の3名。＠IT発行人の新野淳一の司会により、会場の参加者との交流を交えながらそれぞれについて意見を戦わせた。

BPMNへの関心度は50％といったところか

　まず新野が会場の参加者に対し、「モデリングへの興味・関心度合い」について質問。「社内でモデリングに興味がある方は、ほかにもいるのか」という問いに対しては、7割が「Yes」と回答。業界全体的にモデリングへの関心が高まっていることを裏付けた。

　ところが明庭氏が投げかけた「社内でBPMNに関心がある人は、ほかにもいるのか」という問いに対し、「Yes」と答えたのは約半数だった。

新野　いまの結果を見ると、「モデリングに関心があるものの、BPMNに特化して関心を抱いている」という技術者は、やや少ないという結果です。パネリストの方々は、この「ビジネスモデリング」という分野にどのような点で関心を持っていらっしゃいますか。

明庭　私はもともと総合電機メーカーのSEでした。あるとき、業務知識も経験もない販売管理システムのプロジェクトに1人で参加したことがあり、業務の構造を理解して自分の頭を整理するために「モデル化する」ということをやり、モデリングの重要性を認識したのです。そして昨年日揮情報ソフトウェアに入社し、モデリングのコンサルティングや啓蒙活動に尽力しています。

山岸　私は取締役副社長という立場で、豆蔵の経営に携わっていますが、自分たちのビジネスもモデリングしないと効果的な戦略が打てないという観点から、モデリングは非常に大切だと認識しています（笑）。個人的な関心は「要求開発」という分野で、現在「要求開発アライアンス」という団体の理事長を務めています。この「要求開発アライアンス」は以前は「ビジネスモデリング研究会」と名乗っていました。

　 私たちの問題意識は「ビジネスに役に立つ、使われるシステムを作っていこう」ということで、要求開発とはシステム開発と同じように、エンドユーザーの要求もモデリングして可視化しようと試みています。具体的には、まず業務をモデル化して、その中でシステム化すべき対象を固めていくという流れを作らないといけません。システムが見えないから「見える化」しようという話と同じように、要求をモデリングして「見える化」しようという活動です。そういう観点からビジネスモデリングに非常に興味を持っています。

安藤　私はマイクロソフトで開発者に対し、マーケティング活動を行っておりますが、ビジネスモデリングには非常に強い関心を抱いています。

　これまで開発工程において当社のツールはモデリングの後工程、つまり「実装」部分を受け持ってきました。当社のスタンスは「動くITを作ることが第一」ですから、最終的にはきちんと動くプログラムに落としていかないと意味がありません。いままでのモデリングは、基本的に「スケッチ」であり、書いた時点で陳腐化していたし、そのまま実装には落ちませんでしたが、BPMNやBPELの登場により、ようやくモデリングも“動く”部分へとつながってきたという実感があります。こうした背景から、マイクロソフトとしても私自身としても、ビジネスモデリングには非常に興味があります。

失敗プロジェクトを防ぐモデリング

新野　明庭さんのコメントに「知識や経験がまったくない中でのモデリングは、知識を深めたり頭を整理するうえで非常に有効だった」とありました。山岸さんの言葉を借りればビジネスそのものを「見える化」すること、この重要性についてどのようなお考えをお持ちでしょうか。

明庭　モデリングする目的として2つあると考えています。1つが頭の中の整理で、もう1つがコミュニケーションです。特にBPMNの場合、社内のビジネスの構造を把握するのに非常に有効だと考えています。例えば米国で施行されているSOX法では、経営者がビジネスプロセスをしっかり管理し、どのようなデータが流れているかを把握することが求められていますが、BPMNはこうした用途にも使えます。

山岸　システム開発の立場からすれば、「業務上の目的との一致」を実現するためにビジネスモデリングが重要といえます。例えばUMLでは、業務とシステムとアクター（システムの利用者）の関係を「システムのサービス」として表現するだけでしたが、一段上の視点でビジネスをとらえると、すべてのビジネスは、「お客さまにサービスや商品を提供する」というプロセスで成り立っていますね。

　そうすると、情報システムは「お客さまへサービスや商品を提供するシステム」のサブシステムとして位置付けられます。こうして全体のビジネス構造が分かれば、システム化すべき対象がシンプルな形で見えてきますし、また業務そのものの余剰部分が可視化されることで、よりシンプルな構造になる。つまりビジネスモデリングは、ROIの観点から見ても非常に有効だといえますね。

安藤　開発者にとってモデル化することは、生産性向上という側面もあると思います。ある媒体の調査では、「7割のプロジェクトが失敗している」という結果が出ましたが、その最たる理由は「お客さまの望むシステムを作れなかった」「スケジュールやコストが間に合わなかった」ということに起因しているそうです。

　山岸さんのお話とも重複しますが、要求やビジネスの全体像を可視化するためにモデリングは非常に重要ですし、さらにそのモデルを蓄積して再利用することで、圧倒的な納期短縮につながる。そうした意味で、モデリングが持つ意味は非常に大きいと考えています。

どんなプロジェクトでもモデリングは必要？

新野　「モデリングは重要」という点で意見は一致していますが、では「どんなに小さいシステムでも絶対にモデリングは必要なのか」という点についてはいかがでしょうか。場合によっては、実作業から始めた方がいい、というケースもあると思いますが。

明庭　手戻りが発生するリスクを考えると、モデリングは必ずやった方がいいと思います。ただそのプロジェクトが、小さな改善であるとか、あるいはトライアル的な要素が大きければ、ケースバイケースだと考えていますが。

山岸　システムの構造を可視化する「システムモデリング」か、ビジネスの構造を洗い出す「ビジネスモデリング」かで違いがあると思いますが、例えばツールのようなシステムだと、あまりモデリングの必要はないと思います。

安藤　私は「どんなに小さなプロジェクトでもモデリングはした方がいい」と考えています。実はマイクロソフトは、VisualBasicによる2階層システム開発が全盛だったころから、COMコンポーネントを使った3階層システムのアーキテクチャを提唱していたのですが、「アーキテクチャ構造について、モデルを書いて開発者同士で情報を共有し、最適なものを作ろう」ということに対する訴求が弱かった。

　例えば数千人が使う2階層システムで、データベースのテーブルにロックが掛かるような処理を持たせているというケースが多数ありましたが、これはデータベース担当者やプログラム開発担当者などの間で、アーキテクチャについての共通認識が欠けていたため。この場合は3階層アーキテクチャが望ましいのですが、もともとの設計がガチガチの2階層の場合、3階層への移行には非常に苦労したといいます。こうしたことから考えても、モデルを書いて残しておくことが非常に重要といえるでしょう。

新野　ビジネスモデルの記述と、アーキテクチャの設計との間にはどういう関係があるのでしょう。アーキテクチャがビジネスモデリングに与える影響というものはありますか？

安藤　この認識が正しいのかは分かりませんが、アーキテクチャは現時点で理解ができる“スナップショット”だと思うんです。一方、ビジネスモデルは永続性があり、動的です。この2つを結び付けるには、第1部の講演にあったように、ビジネスアナリスト、プロセスデザイナー、システムアーキテクトが連携を取り、ビジネスプロセスからシステム化対象範囲の特定、システムの内部処理について詳細化を図る必要があるのではないでしょうか。

明庭　一口に“アーキテクチャ”といっても、EA（Enterprise Architecture）という観点もありますし、システムの構造という側面もありますし、いろいろですよね。MDA（Model Driven Architecture）では、ビジネスとITについて1つ線が引かれています。具体的には、プラットフォームに依存しないビジネスのモデルPIM（Platform Independent Model）と、プラットフォームに依存するPSM（Platform Specific Model）があり、PIMからPSMへ、変換パターンを用いて実装に落とし込んでいくという流れがあります。