それでは、ワークショップを始めます。ワークショップの前半で講演の内容に関しての質疑応答を行います。後半では、従来の議案のそれぞれの項目を明庭さんに回答していただいて、議論していきたいと思います。最初に参加者の自己紹介をお願いします。

オージス総研の竹政です。業務は主にUMLモデリング関係をずっと行っていて、UMTPが設立されてからはUMTPの各部会でも活動をしています。現在はその延長線上でそれ以外の分野へのモデリングの適用可能性などを考えているところです。よろしくお願いします。

フリーでやっています河合と申します。ビジネスモデルに興味を持ったきっかけは、ヤコブソンが提唱し、その後RUPにも取り入れられたビジネスユースケース/ビジネス分析モデル[『ビジネスオブジェクト : ユースケースによる 企業変革』]、エリクソン/ペンカー[『UMLによるビジネスモデリング』]やマーシャル[『企業情報システムの一般モデル : UMLによるビジネス分析と情報システムの設計』]など一連の 「UMLでビジネスモデリングを行う」書籍が出始めた頃です。その後最近の動向をつかめていないので、今日は改めて勉強したいと思っています。

東芝ソリューションの山城と申します。モデリング技術部会の主査をしています。先ほどもご紹介しましたが、去年にも4回、このセミナーを行っていまして、受けた方にアンケートを書いていただきました。その中で「どういう適用分野にモデリング技術を考えていきたいか」を聞いているのですが、過去の回答数415件のうち、2割が「ビジネスモデリング・要求定義モデリング」と回答されているんですね。来ていらっしゃる方は、大体UMTPのL2以上の方がほとんどですから、UMLやモデリングを勉強して将来どう使っていこうかというところで非常に期待が高いと思います。是非いろいろと議論をしていきたいと思います。よろしくお願いします。

富士通の吉田です。私は80年代に人工知能をやっていたんですが、90年代になってから、ソフトウェアエンジニアリングの方に変わりました。そのときに大きく2つテーマを設けたわけなんですが、1つは90年代初めなのでオブジェクト指向分析設計で、もう1つは、実はソフトウェアプロセスでした。そのときに会ったのがKeith Swensonという人で、それから長い付き合いをしています。彼は今、アメリカでワークフローをやっている[注: WfMC(Workflow Management Coalition)の技術委員会議長、FAI(Fujitsu America Incorporated)のR&D担当VP]んですが、その頃はTcl/Tkとかの言語でソフトウェアプロセスをやっていて結構苦労していました。弊社もワークフローを90年代に立ち上げたんですけれどもなかなか大変で、それは今日的な大変さではなくて、当時の日本はみんながパソコンを持っているわけではないので、パソコンを導入するほどいいものなのか?という、ビジネスプロセスとかいう以前のレベルで大変でした。それを考えると隔世の感があるなと思っています。そういう経緯もあってビジネスプロセスには大変興味がありますので、よろしくお願いします。

日本ユニシスの水戸と申します、よろしくお願いします。私は知財活用センターという部署で社内の業務や技術のノウハウを可視化し社内で共有する仕組みを作ったり、そのコンテンツを使ってサービスを提供しています。その中で業務プロセスの可視化に関してMetastorm社のProVisonというBPMNに準拠したツールを使っています。先ほど講演頂きました「業務分析の視点」について、お話を伺いたいと思います。

バブ日立ソフトの山本と申します。まだ入社5年目で、SEとして仕事をしています。実務経験があまり多くなく、ご迷惑をおかけする発言をするかもしれません。今回はビジネスプロセスや要求定義という部分で勉強させていただきたいと思って参加しています。よろしくお願いします。

今日のワークショップの座長を務めるバブ日立ソフトの中原です。私は日立製作所から2005年にバブ日立ソフトに転属して、現在は社内の開発プロセスやプロジェクト管理の標準化の推進と、人材育成などを担当しています。よろしくお願いします。

では最後に、明庭さんの方から、自己紹介の補足などがありましたらお願いします。

私自身はもともと大手電機メーカーのSI部門でプロジェクトマネージャをしていました。その頃、お客様の中でとてもデータモデリングを重視されている方と、業務をよりよく進めるためには、どういったデータを集めてどう活用すればいいか、というのを一緒に議論させていただく経験をしました。それまでもシステム開発のための技術要素の1つとしてデータモデルを利用していましたが、お客様と業務のことを議論するために利用するのは初めてでした。それがとても楽しくて、もっとこれを主体にやりたいと思ったのが今の会社に転籍してモデリングに特化した仕事を始めたきっかけです。

ただ、その後、お客様と業務のことをデータモデルで議論する機会があまりないんです。というのは、データモデリングのスキルを持っているお客様や、データモデリングに興味があるようなお客様になかなか巡り会えない。私自身がお客様の業務を理解して整理し、システム開発者に伝える道具にしかならない。そこで、より理解しやすく議論しやすいビジネスプロセスモデリングに傾倒するようになってきたという経緯があります。

今はプロセスモデリングに特化していますが、ビジネスモデリングという広い範囲の中で、もっとお客様と一緒に議論できる範囲を広げていきたいという思いは持っています。皆様との議論が、それを現実にするためのヒントになればと、今日は期待しています。

それでは、講演の内容について掘り下げていきたいと思います。では、ご質問をお願いします。

スライド2ページのビジネスプロセスのモデリングで、明庭さんから5つの視点が必要だというお話がありました。実際にプロセスを整理していくうえで、ビジネスのルールを入れ込んだりビジネスプロセスを指定するような法令や条例といったビジネスルールを整理していかないと、ビジネスプロセスを正確に明確に描けませんし、いろいろな視点でビジネスプロセスを正確に描くために、あるいは改善するためには、付帯する情報の整理も必要だと思うんですけれども、今までご自身がコンサルティングをされるときには、これらの視点での整理も合わせて行っておられるのでしょうか。

図1 ビジネスプロセスモデリングの位置づけ (講演資料2ページ)

ビジネスプロセスを主体としたコンサルティングをしています。その中で関連するルールや関連するデータも合わせて整理するお手伝いをするようなことはあるんですが、あくまでも主体はビジネスプロセスにあって、「関連する」という言葉がついたルールやデータにとどまっています。たとえばビジネスプロセスモデルでは「ハンドオフ」を表す必要があるので、ハンドオフに関わるルールは整理するお手伝いをします。関連しないところまで含めて網羅的に整理することはしていません。

対象領域によって、ビジネスルールは絞れてくるんですけれども、整理する際に、それぞれの立場の方、それに関わる他の部署の方などを集めてワークショップ形式でされるんでしょうか。

ビジネスプロセスモデルを書く目的やお客様の体制によって、そのやり方は変わってきます。ビジネスプロセスモデルは複数の部門にまたがるフローであり、その全体を書ける人はいないという点を、どのように補うかで変わってきます。ワークショップ形式で全体を表す鳥瞰的なフローを書いてから、各業務部門の方が各部門の詳細フローを書く方法、フローを書く担当者を決めて、その担当者が各業務部門にヒアリングしながら書く方法などがあります。

お客様の目的や体制を確認しながら、どういうやり方がいいかを検討するところからコンサルティングが始まると考えています。

自己紹介の補足の、データモデリングよりもビジネスプロセスモデリングを主体にされている理由の中で、実際にデータモデリングはなかなかできるお客様がいらっしゃらないとおっしゃっていました。逆にいうと、プロセスモデリングの方がエンドユーザーの方、お客様でもある程度できるというか、易しいというか、それほど特別なスキルを必要としないということですか。

まずは、間違いなくビジネスプロセスモデリングの方が、現場の業務部門の方には馴染みやすいと思います。説明をするとすぐにその世界に入り込んでいただけると思います。ただ、逆にビジネスプロセスモデリングの難しさもあるんですね。データモデリングの世界はスキルが求められる分、逆に「データモデリングはこういう手順でやりましょう」「正規化という考え方にそってやりましょう」という進め方が体系的に整理されています。スキルを持った人がやれば、そんなにぶれがなく最適なモデルを作れるという面があります。

逆に、ビジネスプロセスモデリングは、体系的に整理されていないから敷居が低いという面もあって、敷居が低い分、やる人によってできあがるモデルが全然違うんですね。そこをいかに最適なモデルに誘導していくかという点で、データモデリング以上の難しさがあります。たとえば、J-SOXのための文書化という視点で書くモデルは、今回お話したSOAのためのフローよりも粗いも のでもよかったりします。モデリングの目的に応じて何が最適かを考えて、ルール化して、その通りに皆でやってもらえるように教育をしていくというところに、難しさや コンサルティングサービスを提供する余地が残っていると思っています。

関連するデータについては整理するとおっしゃいましたが、たとえば用語辞書みたいな、2ページの絵に書いてあるしっかりしたER図じゃないにしても、データの名前の一覧をあらかじめ作って言葉を統一させるというようなことをしないと、ルールを考えるにしてもフローを考えるにしても、似て非なることを喋る可能性があると思います。最低でもデータ辞書みたいなものは作るんじゃないかと想像しているんですが、そうなんでしょうか?

理想的には、ビジネスプロセスモデリングとビジネスルールモデリングの前にデータモデリングが出来ていると良いと思います。ただ、スケジュールなどの関係でデータモデリングまではできない場合もあります。そのような場合には、用語集を整えながらフローを書いていきます。

ただ、用語集も範囲を広げると負荷が高過ぎてしまうので、範囲を絞り込んで用語集を作成するようにします。たとえば、ビジネスプロセスモデルでは作業の名前を表す「〜を〜する」が大切なのですが、「〜を」に対応する用語まで作成すると負荷が高過ぎるので、「〜する」に対応する用語だけにしよう、というように絞り込みます。さらに、モデリングの目的を考えながら絞り込むこともします。たとえば、J-SOXの、統制（コントロール）を表す用語が大切なので、「検証」「照合」「承認」など、統制を表す用語だけにする、というような絞り込みです。「照合」は2つのものを比べてOKがどうかを判断する作業とか、「チェック」はチェックシートでチェックする作業とか、そういう用語の定義も含めて用語集を作って統一しておくと、誰もが同じ言葉で書いてくれるし、見る人は作業の名前だけでどういう統制なのかを把握できるようにもなります。

「〜を〜する」とおっしゃいましたが、「〜を」がデータで、「〜する」は処理、プロセスだと思うんですね。J-SOXでは、さらに「誰が承認した」などの主語が重要になって、「〜が〜を〜する」となりますね。この主語は2ページの絵でいうと組織にあたると思います。今までの話ではプロセスとルールとデータしか出てきませんでしたが、組織のモデリングなどはどうされていますか。

今までは、現状の組織ありきの形、組織を変えることまで検討しない前提で進めることが多かったので、組織のモデリングまではやっていません。

As Isの組織について一応書いてもらうようなことはするんですか。

モデリングとまでいわなくても組織図のようなものはありますので、それを利用します。

組織図の最後の方にロールみたいなものが出てくるんですか。

出てきません。ロールは、BPMNではレーンと呼ばれる枠線で表すもので、ビジネスプロセスモデルを書く際に、大抵、最初に書かれるものです。モデルを書く前に、レーンはこういう順番で書きましょうというルール化と一緒に、ロールの用語が統一化されるようなルール化もします。

私もビジネスプロセスモデリングとデータモデリングの関係に興味があるんですが、26ページの、データモデルからビジネスプロセスの設計をするときに非正規化したデータモデルでWSDLを作るというところで、ある程度絞ってデータモデルを作ってからここで使う形になるのですか、それとも、いきなりここでからんでくるのですか。

図2 プロセスデータ設計からWSDL定義へ (講演資料26ページ)

先ほどの質問と同じ答えになってしまいますが、この絵で表しているのは理想的な姿です。データモデルがありきだと非常に進めやすいんですね。エンタープライズレベルでデータモデルや用語がきれいに整っていると、そのデータモデルからSOAの世界にこのようにつながります、というのを26ページの絵で表しています。ただ、実態からいうと、データモデルが整っているお客様が少ないんですね。そのときには、データモデルを作れる人がいれば部分的に作るし、いなければプロセスデータとして表形式で羅列するところから始まるかと思います。データモデルがないと、表形式で作るときに用語やデータ型の統一が取れないなどが問題になるんですが、とりあえずこれを最初の標準として進めていこうなどと割り切れる場合には、データモデルから始めなくてもいいかなとは思います。

26ページはあくまで理想のモデルで、実際には部分的に作ったり用語辞書を作ったりして進めるということですね。

はい。部分的に作りながら。

分かりました。ビジネスプロセスの書籍や記事を見てもデータモデルのことはほとんど出てこないので、今日はその点が参考になりました。

最近のSOAに関するツールなどを見ていると、XMLスキーマという、データ構造をXML形式で書く標準がこれからポイントになってくると思います。たとえば電子フォームを作るツールではXMLスキーマを読み込んでフォームとマッピングしながら開発していくという流れができていたり、SOAのサービスを作るツールでも、XMLスキーマからWSDLを作ったりします。BPMNのバージョン2.0が来年出るといわれていますが、そこではBPMNとXMLスキーマをマッピングする仕組みが組み込まれます。XMLスキーマでデータのガバナンスをきかせることができるようになるのです。

プロセスモデリングとデータモデリングの関係についてお聞きします。たとえば、最終的に、モデルを詳細化してJavaで作ることになったときに、Javaのクラスはデータでもあるけど手続きでもあるので、そこでデータとプロセスが同居することになります。UMLのモデリングではクラス図などでモデル化していましたが、このプロセスのモデリングではデータモデルとの関係についてどのようにお考えですか。

今日のスライド11ページのSOAレイヤにおいて、ビジネスサービス層以下の話になると思います。確かにビジネスプロセスという言葉は下の層までいきわたる話ではあるんですが、ビジネスプロセスモデリングしてITで動かさなければいけないのはビジネスプロセス層だけと考えています。そこから下は、UMLでモデリングしてJavaで作るということでも良いと考えています。どのようにモデリングしてどのように作るのかは、それぞれのIT構築プロジェクトに任せるという感じです。「ビジネス」という名前が付かない部分なので、エンタープライズレベルの管理はしないという割り切りをした方が、SOAが進めやすいかと思っています。

図3 粗粒度のポイント SOAレイヤ (講演資料11ページ)

ビジネスプロセスレベルから詳細なレベルまで、3段階のプロセスレベルがあるという話だったんですが、その区切りというかトレーサビリティが、どうもピンときません。それは完璧なトレーサビリティというよりも、ビジネスプロセスとして典型的なもの以外に、先ほど話があったJ-SOX向けに少し粗いものなど、分野ごとにそれぞれで異なるもので、必ずしもすべてが下流までトレーサビリティがあるわけではないという認識でいいですか。

はい。EA[Enterprise Architecture]のような企業全体の視点でIT資産を管理しなきゃいけない世界と、その配下で個々に立ち上がるITプロジェクトの単位で管理すればいい世界の間で線を引くといいと思っています。エンタープライズレベルでも、テクニカルサービスやアプリケーションまできっちり整理できて管理できると理想的なんですが、なかなかIT構築プロジェクトの壁を越えるのが難しいと思います。たとえばIT構築プロジェクトを異なるベンダーがやったら、それだけで超えるのが難しくなると思います。あくまで、エンタープライズレベルで管理するのは、量的にも分かりやすさという視点でも、SOAレイヤではビジネスという言葉がつく層だけにとどめる、ここにとどめたらIT構築プロジェクトの壁を越えた再利用性の管理などができるんじゃないか、というのが具体的なイメージです。下のJavaで作ったものやERPをビジネスサービス層がラッピングして、ビジネス視点で意味のあるかたまりにしておいてくれれば、それさえ再利用すればなんとかなる、という形に持ち込めるんじゃないでしょうか。テクニカルサービス層とかアプリケーション層は、IT構築プロジェクト単位によろしくやってね、と任せてもいい範疇になるんじゃないかと思います。

なるほど。確かにSOAレベルでさらに詳細化するときの再利用部品の話になると、どうもビジネスレベルの再利用と食い違ってきて、ビジネスレベルの再利用がなくなってくる気はしていたので、その辺が難しいんでしょうか。

はい。私も昔SIのプロジェクトマネージャをやっていたんですが、再利用をするとか再利用しやすい部品を作るというのは、自分のITプロジェクトの配下だとSOAでなくても十分にできると思っています。ですが、最近、ITプロジェクトの壁を越えて再利用という方向を目指さないといけないというような考えになってきて、その中で、下の細かいレベルまで管理するのは無理だろう、ビジネスサービスとしてまとめれば管理が可能になるだろうと考えるようになりました。

それに関係するんですが、お客様の組織にも業務やISやインフラ設計などいろんな役割があって、実際に我々の場合だとIS部門といろんな話をしてやっていくんですが、明庭さんの場合にはISじゃなくて、業務部門、実際の現場といろいろ話されているということなんでしょうか。もう1つ、やっぱりインフラ部門もいろんな資源を持っていて、そこを検討するにはビジネスサービスレイヤよりも下を考えないと、話しにくいんじゃないかと思うんですが、いかがですか。

J-SOXのような使い方は別なんですが、SOAという視点で支援するお客様に限定すると、すべてIS部門です。ただ特徴的なのは、業務をより良くするための検討に踏み出していきたいと考えているIS部門なんです。従来のIS部門のようにシステム設計だけやっているのではなく、業務も見直しながらITの活用方法を考えるとスタンスでIS部門が活躍するように変えていきたいと思っているIS部門の方に対してSOAのコンサルティングを行っています。そのため、ビジネスプロセス層をメインとしたコンサルティングになっています。

逆にお客様のIS部門も積極的にやろうとしているから、業務の話を業務のほうに聞いたり設備に関してインフラに聞いたりして協力的にやってくれるということですか。

はい。一歩業務寄りに踏み出すために、IS部門の方がビジネスプロセスモデリングに着目しました。その結果、コンサルティングの声がかかったというパターンです。

なるほど。

IS部門の方は実際のプロセスにそれほど詳しくないですね。だから現場の方も呼んできてやるんですか。

はい。現場を呼んできてやります。

書くことになったIS部門の人が現場のプロセスを理解しながらということですか。

はい。業務寄りに踏み出すために一番大切なのが業務を理解することですね。そのためのキーマンがビジネスプロセスモデラーということです。さらに、プロセス指向で進めるということを考えると、プロセスの全体を知っている人は現場の方にもいないので、ビジネスプロセスモデラーはプロセスの全体像を知るという役割も持ちます。プロセスは販売、購買、物流など様々な部門をつなぐものなので、その全てにかかわる現場の方はいませんが、IS部門はすべての業務に関わるシステムやERPをやっているので、IS部門の方はプロセスの全体像を知る役割に向いているんじゃないかと思っています。

ビジネスプロセスモデラーが複数の業務部門にまたがってモデルを書きながら、全体最適という視点で業務をどう変えていくかを議論できるようになれば、今までの業務のやり方が大きく変わるのではないでしょうか。

むしろ明庭さんにコンサルティングをお願いする人というのは、そういうところに問題意識を持っていて、やりたいけれども自分だけじゃできないからコンサルタントと一緒に自社のプロセス設計をやり直そうという意識の高い方が依頼しているということですか。

はい。逆にそこまで意識を持たないと、ビジネスプロセスモデルは簡単に書けると思ってしまうのではないでしょうか。従来から、ビジネスプロセスモデル、すなわち業務フローを書いている人はたくさんいて、そのやり方で十分だと思われている場合には声がかからないのかと思っています。

もう1つ別の質問です。セミナーで厳密な形でのBPMNの表現の話がありましたが、UMLの世界でもモデルを非常に厳密に書こうという取り組みをしたことがあります。MDA(モデル駆動型アーキテクチャ)という形で本当にソースコードまで落とせるくらいに厳密に書こうという文法が定義されたんですが、結局使い切れなくて活用しきれない状況になっています。今回明庭さんに講演していただいたように、SOAのサービスに引き込もう、BPELのエンジンで動くような形にしようというような厳密な方向に向かうと、本来コミュニケーションしたいはずのお客様とコミュニケーションできないくらいの難しい図面になってしまうという危惧はないんですか。

それに関しては、今日ご紹介したハンドオフというレベルでとどめるのが大きなポイントです。つまり、この仕事をこなすためには最初にAさんが仕事をやって、それが終わったら次にBさんが仕事をやってというロジックにとどめる、ということです。その役割の人の1つとしてITシステムというのがあったら、「ITシステムよろしく」ということしか書かないというやり方ですので、それを厳密に書いても、それほど複雑にならず理解もしやすいものになります。逆に複雑になりがちなところは、プレゼンテーション層の画面遷移であったり「ITシステムさんよろしく」と言った後のシステム処理ロジックだったりするので、そこをうまく切り離すと、本当にBPELとして動くようなレベルで厳密性をもって書いたとしても、現場の人が見ても分かりやすいものになります。

39ページの精密に描く例を見ると、すべてのプロセスがすべてのところからすべての場所へ差し戻すということがあるんじゃないかという気がします。これですと、1次承認、2次承認で1つ前には戻るとか、一番最初に戻るとかがあるんですが、これを書き始めると全部の場所から全部の場所へ戻すことが可能、ということになって収拾が付かなくなることはないんですか。それをこうやって押さえこむという方法はありますか。

図4 BPMNの特徴(3種類のフローを描き分ける) (講演資料39ページ)

差し戻しが複雑になりがちなのは確かですね。ただ、過去の経験でいうと、As Isが複雑だったのにTo Beにしたら単純になることが結構多いです。あまり考えずに「こういう場合も差し戻しちゃえ」という統制が取れていない差し戻しが多くあって、それが複雑化の原因になっていることが多いんです。その結果、To Beとして、本当にそれが効果的なのか、効率的なのかを議論していると、As Isのときは複雑で書くのがすごく大変だったのに、To Beにしたらサッパリしちゃったということが結構多い。難しいんですが、その辺をちゃんとすっきりさせるのが業務改善のいいポイントになります。

それでもやはり複雑だという差し戻しも存在します。そこで、プロセスのタイプが定型プロセスなのか、非定型プロセス(アドホックなプロセス)を区別します。非定型プロセスならば、ビジネスプロセスモデルをITで動かして業務アサインの管理をするのではなく、たとえばドキュメントのステータスが変わったら人に通知するとか、ホワイトボードで作業を羅列して担当者を決めるように動的に作業を生成して人にアサインするとか、そのためのBPMツールを使います。

逆にそれが分かるまで、たとえばAs Isなら、アドホックのプロセスまで含めてまず書いてみるということですか。

そこでポイントとなるのが、As Isは動かなくていいという点です。現状を知って問題を見つけ出して改善策を検討できればよい。そういう意味では、差し戻しを分かりやすく図で書ければベストですが、テキストによる注釈で、例外としてこういうケースがあると書くだけでも十分です。

それはモデル図上に文章を書くということですか。

はい。それで十分なんです。As IsはシステムでBPEL化して動かさなくていいですから。

見えればいいんですね。

把握できるということが大切です。「そういうことがある」という情報を集めるのがAs Isでは大事なので、集めるためにあまり苦労をさせてはいけないと考えてやっています。集めた結果、To Beでは簡単な例外処理になるのか、フローでBPELで動かすには無理があるぐらい色々なケースがある非定型なものなのかを判断して、適切なBPMツールを選んでいきます。そういう意味では、今日の話は定型プロセスを前提としたものになっています。

でも、ハンドオフレベルでの定型プロセスフローは厳密なフローなんですね。視点が人とのやり取りというだけで。

はい。定型プロセスという前提だと厳密なものです。

UMLだと、以前にマーチン・ファウラーがBlikiというブログの中でUMLには3つの見方(Uml Mode)があるという話をしています。スケッチレベルの使い方と、ブループリントレベル(設計レベル)の使い方と、プログラミング言語レベルの使い方の3つです。スケッチレベルというのは本当に紙ナプキンに書くような、「適当でいいから」という言い方をしたんですけれども、今回の使い方というのは、ハンドオフレベルであってもスケッチじゃないわけですよね。つまり、視点が人とのやり取りというところでとどめるという前提で、厳密なフローを書くということですね。そうしてもお客様とコミュニケーションできるとおっしゃったと考えていいでしょうか。

はい。

21ページにあるんですが、「記述的」と「実行可能」というのは、ハンドオフという記述レベルとはまた別の軸になるんですね。

図5 記述的モデリングと実行可能モデリング (講演資料21ページ)

はい。今日の話は業務をよりよくするという検討の中にIS部門が踏み込んでいきたいという前提なんです。なので、IS部門の方がTo Beを書きながら業務部門の人と会話をするという前提で、To Beをいきなり実行可能な形で書いて、それが分かりやすければいいというストーリーです。ただ、そういう形でなくて、To Beは現場の部門の方が考えてからIS部門の方が引き継ぐという場合は、To Beも記述的に書いて、IS部門に引き継いだ後でIS部門の方がTo Beを実行可能な形に書きなおして、ただし分かりやすく書いて、現場の人に確認するというステップを踏まなきゃならないかもしれません。いきなり実行可能にできるのは、IS部門の方が踏み込みたいという前提の話です。

分かりました。ありがとうございます。

実行可能であってもユーザー部門が分かるくらいの粒度でなければいけないということですね。その辺の兼ね合いが結構難しいと思うのですが。実行可能なレベルにしてしまうと、IT部門で「これはERPのこの機能を使おう」というようにシステム独特の話が出てきがちではないでしょうか。そのあたりは隠すんですか。出ていたとしてもエンドユーザーが分かるならそれでOKなんですか。

それは明確に隠します。今回の仕様ではプロシージャレベルのシステム処理と書いているんですが、それは現場の人が興味のないものと位置付けています。

では、IT部門の人は意識してその上のレベルのプロセスを書く必要があるということですね。

はい。ハンドオフのレベルでは「ここでITシステムによろしく」という1つの四角しか書かないんですね。

IT部門でプロセスの記述をあまり経験していない方がそのプロセスを書けるぐらいになるまでにはどのくらいの時間がかかるんでしょうか。

今日お話したものを理解するという中ではあまり時間はかからないと思っています。それよりも業務を知っていくというころが敷居が高いという気がします。

では業務さえ知っていれば、書くのはそんなにかからないんですね。

IS部門の方には、たとえば販売は知っているけれども購買は知らないとか、そういう方がSI会社も含めて多いんですね。特に今回のビジネスプロセスモデリングでは業務部門や機能をまたがったフローを書くので、自分が知らない業務範囲まで立ち入ってフローを書かなきゃならないという壁が一番大きいと思います。

たとえばAs Isのプロセスをエンドユーザー部門に書いてもらうときも、それほど苦労せずに書いてもらえるものですか。

As Isは記述的なので、あまり細かいことは言わないという前提です。

そのまま書いてもらえばいいわけですね。

はい。その一方で、個人的な思いなんですが、IS部門の方が一歩業務のほうに踏み出すという目的を達成するためには、そのビジネスプロセスモデラーと呼べる人がAs Isを書かなきゃならないと思っています。As Isは業務を勉強する非常にいい機会で、書かせるよりも自分がヒアリングして書いたほうがその機会は広がるので、IS部門の人が業務の世界に踏み出すときには、ぜひともそのようにしてほしいと思っています。ただ、そういう形で整理しなければならないのは大事なプロセスだという縛りをかけてもいいと思っています。コアなプロセスに対してはそういうやり方をするけれども、それ以外のプロセスは従来のように現場の人にまかせて、結果を要件として受けてISが開発しましょうという割り切りもできると思います。負荷的に大変なので。

コアとそれ以外とを振り分けるための見方などもコンサルティングの一部なんですか。

残念ながら今までそのフェーズから入ったことはないので。

最初からお客さんがコアだと思うものが対象になっているわけですね。

今まではそういう感じです。

講演の最初のほうで目的によって当然To Beは変わるとおっしゃったんですが、何を目的に考えているのかを参加する人たちが共有するうまい方法は持っていらっしゃいますか。2ページの絵でいうと「戦略・目標」の視点を定義することなのかもしれませんが。

コンサルティングをやるときには、ビジネスプロセスモデリング基準書というものを作っています。このルールに沿ってモデルを書いてください、というところをまとめたドキュメントです。それを作る際に一番時間をかけているのが、目的を整理するところです。それを基準書の最初の章に持ってきています。さらに、「この目的を達成するためにはプロセスモデルとして何を絵で書けばいいのか」という、絵で書くべき項目なども整理しています。たとえば、目的を達成するためには作業と作業の間でやり取りしている書類の名前と、やり取りする手段(社内便など)を可視化する必要があるなど、「何を見えるようにしなければいけないか」の項目を目的に応じて整理します。

目的を決めるときには、たぶんお客様の上位の方と話をして決めると思うんですが、普通は業務改善とか全般統制とかSOAとか効率とか考えられるうち、どれを目的にしますかなんてことを聞くんですか。そうすると全部やってくれなんてことになりませんか。

最初からその1つに焦点が当たっているということが多いです。逆に、他の焦点に対して何かしらの関わりはなくていいですか、という質問をこちらから投げていますが、過去のケースでは「今回はそこまではいらない」ということで最初に提示されたスコープの中で進めてくれと言われることが多いです。

そういうことでやると、お客様くらいの規模だとこのくらいのコストがかかるとか、そういうノウハウはお持ちですか。つまり、たとえばJ-SOX対応なら、モデラーを何名/何ヶ月でこのくらいの作業量です、As Isをまず書いてみるだけなら実行可能じゃなくていいから何名くらいでこのくらいの期間でできますよ、という大まかな見積もりをもって、「そこまでやりますか」と上位の方と話をするんじゃないかなとイメージしたんですが。

今までは、そういう会話になったことはありません。ただ、この目的ではこのくらいのビジネスプロセスモデルの詳細度になりそうだから、1人だとどれくらいになるかという計算は、一応、過去の経験で導き出すことはできると思っています。

目的によってモデル規模が異なってくるということですか。

はい。

それは組織の大きさとかによって決まるのですか。どれくらいのプロセスの数があるかというような見通しは非常に重要かと思うのですが、どういうところを捉えて「これくらい」と言われるのですか。

プロセスが何個あると押さえられているものに対して、どれくらい時間がかかるというのは経験で導き出せますが、何個プロセスがあるかを整理していないということです。

逆に言うと、企業の規模にはあまり関係なくて、何種類くらいのプロセスでやっているかによって決まるということですか。

この規模だからどれくらいのプロセスかという整理はしていませんので、経験的に答えることはできません。

だいたいお客様がこういう規模でと言われるということですね。

お客様が押さえているという前提です。

大きい会社はプロセスインスタンスの数は多いけれど、プロセスとしてはそんなに変わらないということですね。

話は変わりますが、従来のユースケースとの絡みはどうですか。UI設計のあたりからユースケースにつながるのでしょうか、それとも全然関係ないのでしょうか。

私自身がユースケースをあまり使わないので、ユースケースを使わない流れとして整理しています。

ユースケースでも、ビジネスユースケースとシステムユースケースの場合では違うじゃないですか。

たぶん、ビジネスユースケースからシステムユースケースを切り出すというやり方はあるかと思うのですが。

ビジネスユースケースのレベルではユースケースとプロセスの対応は比較的そのままとれそうですね。先ほどのレベルの話のシステムのレベルであらためてシステムユースケースという形で切り出すのかなと感じで捉えたんですけれども。

私自身があまりユースケースの経験がないものですから、そのへんは整理したことがありません。

IS部門と現場の話で、現場の人は自分の担当の業務を非常によく知っているけれども、IS部門は現場のことをよく知らない。ただ、全体を知っている人が誰もいないのでIS部門の人が中心になって全体をまとめていくのがいいだろう、という話がありました。それはそれで確かに1つなんですが、ユースケースの考え方では、ユースケースごとにそれぞれ現場に近い人がまとめていきます。そのあたりどのように調整すればよいか何かお考えがあればお聞かせください。

そういう意味では、プロセス指向というのがキーワードになると思います。従来だとIT構築プロジェクトを立ち上げる上でも業務改善を考える上でも、機能という枠に縛りを受けていたところがあります。会社は、販売や購買など、機能の単位で組織ができていますから、何でも機能の単位で考えるようになりがちです。でも、そのやり方だと、顧客指向とか全体最適という視点が疎かになってしまいます。顧客指向とか全体最適というのは、販売や購買などの機能にまたがるものなので、どこかで横串を通すことをしなきゃいけないということです。その横串がまさにビジネスプロセスじゃないかと思っています。

確かにユースケースの欠点はつながらないところなんです。

今日の話は横串を通そうというイメージのものですので、なかなかユースケースとの接点が出てきませんね。大事なのは横串ですから。

業務フローの数は、エンドユーザーさんがやっているシステムや経理や受付などの業務ごとに分けるという認識でいいでしょうか。

はい。

そう考えると、ビジネスユースケースと同一かなと思うんですが。

どのように業務を分けるのかという単位は、注文を受けてからモノが届くまでの顧客のサービス応答時間を評価したいなどの評価軸がないと、どう横串を通すかが決まってこないんです。KPI[Key Performance Indicator: 重要業績評価指標]を整理してKPIを見ながら横串の戦略を立てるようなステップになります。

10年位前にエリクソン/ペンカーという人が、UMLで記述できるようにステレオタイプによる拡張を行い、プロセスには必ずインプットとアウトプットがあり、さらに目的とリソースがあるという方式を提唱されていました。インプットとアウトプットは誰でも考えますが、プロセス毎の目的を明確にしようというところがみそだったと思います。ちなみに前回お話いただいた中村善太郎先生の「もの・こと分析」も工程ごとの目的を考えてプロセスを単純化して無駄を排除しようという発想だったと思います。エリクソン/ペンカー方式のプロファイルは一応できていましたがその後どう発展していったのかは把握していません。確かにプロセスはそれで書けても、その後ユースケースとあまりうまくつながらなかったように思うんですが、その流れがこっちにきたんでしょうか。

そういった意味では、BPMN研究会の初期の頃に、BPMNとUMLアクティビティ図の比較をしたことがあります。そのときの結論は、BPMNで書けることはUMLアクティビティ図で書けるし、アクティビティ図で書けることはBPMNで書けるというのが基本で、BPMNで書けることと書けないことのパターンが、記述の仕方ということで違いがある程度のものになっています。まさにそれをイメージしていただくと、BPMNの位置付けがわかりやすいかと思います。

書ける書けないということでは違いがないと思いますが、思想として、ユースケースは理解するためのダイアグラムであって、定義するためのダイアグラムではないと思うんです。BPMNは明庭さんの話でいうと、記述的なモデルは理解するためのもので、実行可能なものは定義するためのもので、若干BPMNのほうが書けるものがあるというのは、定義するためにはきちんと書かなきゃならない要素があるということですね。もともとユースケースというのは定義するためのものではなくて、コンテキストを理解するためのダイアグラムなんです。

抽象レベルでは理解できないからということで、あくまでusage caseなんですよね。利用例でしかない。もともと、usage caseと英訳するところを、ヤコブソンが誤ってuse caseにしたというお話しを聞いたことがあります。そういう意味では目的が全然違って、ユースケースはとっかかりでしかないですね。

どうもアクティビティ図とBPMNをどう使い分けるかが疑問ではあったんですが。

さっきの話ではどっちも変わらないということですね。

別々に作って、たまたま表記法が非常に似ていると考えればいいんでしょうか。

確かにUMLのアクティビティ図はどういうレベルで位置付ければいいかが困るんですよね。システムレベルでも当然できるし、メソッドのロジックも書けちゃうし。

BPMNでできるなら、いっそアクティビティ図を置き換えちゃったほうが話は単純だなと思ったこともあります。

あるいは、メソッドとかプロシージャレベルのことだけアクティビティ図で書いて、全体のことにはBPMNを使うようなことをOMGが言ってくれれば分りやすいんですが。

OMGというとビジネスモデリング関係の仕様をたくさん出していますね。BPMM[Business Process Maturity Model]やSBVR[Semantics of Business Vocabulary and Business Rules]など、たくさんあるなと思うのですが、そこはどう評価されていますか。どう位置付けたらいいのかちょっと悩んでいるんですが。

BPMNはもともとBPMIという組織が作って、その後OMGにマージされた形なんですが、マージされた後にOMGの会長が日本に来られたときの講演で、モデリングの領域をビジネスとITに分けて、BPMNをビジネスに、UMLをITに位置付けていました。次に、2ページの図で5つの視点を挙げましたが、OMGはこの5つのメタモデルを作っていて、それらとBPMMがビジネスに位置付けられるメタモデルになります。たとえば、SVBRというのはビジネス語彙とビジネスルールのメタモデルになりますし、ビジネスプロセスのメタモデルとしては、一時期BPDM[Business Process Definition Metamodel]として進められていましたが、BPMNにマージされて来年度にBPMN 2.0として出ます。それ以外にも組織、戦略・目標に対するメタモデルもあります。ただ残念ながら、BPMN以外はツールやITの道具が追従していません。追従してこないと評価できるものにはならないですね。

SVBRとかBPMNの上位モデルにMOFなどの共通のメタモデルはあるのですか。

私が知っている範囲では、一時期BPDMをMOFの配下で整えようとしていたんですが、その方向が今は変わってきていると認識しています。

結局、世の中がビジネスとITを一緒にしようとしているのに、それを表現する方法でこういう別々なモデルを作られちゃうと、近づかない気がして、OMGはこれでいいのかと思うんですが。

OMGは他の団体で作ったものを引き継ぐ場合もありますね。そのため、内容が重なっている部分も少しあるように思えます。整理するつもりだとは思うんですが。

CORBAからUMLにいったときには、うまくUMLを取り込みましたよね。同じことをやろうとしているのか、これは別にやろうとしているのか。

体系的にやろうとはしているんじゃないですかね。私も詳しくはないんですが。

他に何かありますか。

ビジネスモデリングの目的として、最終的にお客様の業務の最適化をしたいなど色々なものがあると思うんですが、業務を知るときに、業務の流れの他に、実際に本当の業務をしている人からすると、いつ、どこで、誰が、何をやる、というようなポイントがあると思います。従来のモデリングだったらそれぞれの角度で切り崩して表現するようなことができたと思うんですが、今回の講義でお話しいただいたもので、それをどこまで表現できるのでしょうか。今までお客さんと話しをするうえで、どうされていますか。

ビジネスプロセスモデルでは、「いつ」は「いつこの作業を開始します」という形でタイマイベントで表せます。「誰が」はレーンそのものが表しています。「何をする」はまさに1つ1つの作業のアクティビティになります。残るのは「どこで」「何のため」ですが、アクティビティの下にテキストの注釈で記述することになると思います。

「何のために」が一番重要なのかなと思いますが。

ビジネスプロセスモデルはそういった視点を一通り網羅している、テキストも含めると網羅させることができるのは確かなんですが、「何のため」という視点だけでモデル化して整理したいというニーズもあります。目的を階層的に整理するためには、また別のモデルを書かなきゃいけないのだと思います。

5W1Hの他に「How much」という2つめのHもあって、通常これは予算や費用のようなコストを表しますね。たとえば時間や空間に関わるランニングコストのようなものを考えた場合、このあたりの表現はいかがでしょうか。

ビジネスプロセスモデリングやBPMSでは、それをパラメータとして各作業に埋め込んでシミュレーション分析します。

それをフロー図の上に描くんですね。UMLでもSPTプロファイル[UML Profile for Schedulability Performance and Time Specification]というのがあります。必要なリソースや時間制約の情報をUMLモデル図に埋め込んでおいて、後でそれをシミュレーション用のツールが解釈できる仕組みがあるんですが、そういう仕組みも提案されているんですか。

正確に言うと、そういうツールがあります。

それは特定ベンダーのツールがあるということですか。

はい。BPMNというのは、1つの作業や図形にプロパティをいろいろと埋め込めるように標準化されています。

もともとそういう仕様になっているんですね。

はい。ただ、Webサービスを呼び出し方など、BPELに変換するといった視点ではプロパティが標準化されているんですが、シミュレーション分析するといった視点ではパラメータは標準化されていません。

標準化されているとおっしゃっていたのはどういうことですか。

プロパティが設定できるように標準化されてるが、こういう名前のプロパティにこういうことを書きなさいというところまで標準化されているものと、単にプロパティの拡張の仕方が標準化されているだけでツールベンダーなどが自由にプロパティを追加するものがあります。BPELは前者、シミュレーションのためのプロパティは後者のプロパティになります。

UMLのプロファイルのようなものなんですね。

SOAは以前からなかなか普及していかないなと思っています。トップダウンアプローチと書かれているんですが、それには結構なスキルが必要で、明庭さんのようなコンサルタントを頼るしかないのかもしれません。既存システムのほうからボトムアップのアプローチでできるところからSOAをやっていくというのはどうでしょうか。14ページに矢印がありますけれど、そういうアプローチがいいのかなと思うのですが。

図6 SOAプロジェクトの推進シナリオ (講演資料14ページ)

間違いなく、トップダウンの時にはビジネスプロセスモデリングができるスキルが必要です。ただ、ボトムアップだけのアプローチの欠点は、従来型のシステム開発とあまり変わらなくなってしまうことです。ビジネスプロセスモデリングをやるとビジネスサービスやビジネス語彙に焦点があたって、ビジネスの視点でIT資産を管理できるようになり、SOAのメリットである再利用性が生きてきます。ですから、トップダウンアプローチの方が難しいけれどもチャレンジすべきじゃないかと思ってコンサルティングをしています。

分かりました。以上で講演に関する質疑応答を終わります。

ここからは議案に従って進めていきます。既にお話頂いたところも大分あるので、簡潔にいきたいと思います。最初に、明庭さんがモデリングに目覚めたきっかけや、「モデルとは何か」「モデリングの目的」、それから「現状のモデリング技術の問題点」などをお聞かせください。

きっかけは、先ほどの紹介の中でお話しました。モデリングの問題点は、モデリング技術が豊富すぎて混乱していることだと考えています。あまりにテクニックやその原理原則が多すぎて、私自身が吸収し切れないところが多くあると感じています。モデリングをずっとやってきましたが、モデリングをしていない人から見ると、モデリング好きの人はマニアに見えるらしいです。それが一番の問題だと感じています。データモデリングは欧米ではユーザー企業の方もデータモデリングの世界に入り込んでくれるような話を聞いていますが、日本ではそれもできていません。モデリングを誰でも簡単にできるように整理して、それを補って簡単に実現するためのいいツールが揃っていく方向にいけばいいと考えています。

モデリングはベンダーが使う技術と捉えるのか、ユーザーも含めて使えるテクニックと捉えるのか、どちらですか。

住み分けも含めた話です。

ベンダーが使うならこういうレベルで、ユーザーだったらここまで、ということですね。

ユーザーがやるなら「こういう道具を使ってこうモデリングしてください」と言うとすぐにユーザーが使えるとか、ベンダーがやるなら「こういう道具を使ってこうモデリングしてください」と言うとすぐにベンダーが使えるとかのイメージです。ベンダーのほうは大分揃ってきていると思うんですが、まだまだ足りません。それが整ってくるのが大事です。特にビジネスモデリングの領域がそう感じるところです。

目的に対してどこまでモデリングするかと言う点はどうですか。

整理の中にそういう住み分けも含めています。

難しいですね。技術部会のテーマにもいいかもしれないですね。

先ほど、UMLとビジネスモデリングとしてOMGが抱えているルールの関係の話が出てきたことも含めて、まだまだ整理が足りないですね。それが整理されて、それを簡単にサポートできるツールができるとはじめて、皆が簡単にモデリングを活用できるようになります。まだそこまではいっていないと感じています。

ヨーロッパで比較的普及しているというのはどの辺に要因があるとお考えですか。

日本のSIの外注依存度が高すぎるのが一番の原因ではないでしょうか。逆に言うと、日本ではSI会社が元気すぎますね。データモデリングでいうと、欧米ではDA[データ管理者]などのデータを管理する役割の人がいて、データモデリングの集まりがあるとユーザー企業の人もたくさん来るという話を耳にすると、日本と違うなと実感します。

では次に、モデリングの方法論、原理、原則、パターンについてのお考えを聞かせてください。

今の話と関連しますが、方法論や原理原則は難しいものというイメージが強いです。私自身、モデリングを専門にやるようになってからずっと勉強してきましたが、まだまだ勉強が足りないと思うところが多くあって、難しいものだと感じています。そして、難しいことを皆が簡単に原理原則に沿ってモデリングできるようにするためにパターンが位置付けられるんじゃないかと思います。パターンというのは原理原則に沿ったらこういう形でモデリングすればいいというパターン集のことで、原理原則を知らなくてもそれを真似るだけで原理原則に沿ったモデリングができるものとパターンを位置付ければ、モデリングを簡単にするものだといえます。

それは、手順と様式、両方ですか。

まずは様式です。BPMN研究会でローレベルBPMNパターンというのを作ったのですが、やはり様式を対象としています。

もう少し補足すると、パターンを利用するのは簡単だけれど、パターン化するのは難しいというのが、ローレベルBPMNパターンを作ったときに感じたことです。

『エンタープライズアプリケーションアーキテクチャパターン』や『Enterprise Integration Patterns』など、いろんな書籍が公開されていますが、そういったものを我々作る側もお客様などの使う側も知ったほうがいいということですか。

はい、思います。今はまだパターンが足りない気がしています。増えてきてほしいです。

資料の一番最後に、近日公開予定としてモデリングガイドラインが紹介されていますが、この中身は今の原理原則やパターンなどをBPMNに関して述べているものと期待していいでしょうか。

残念ながら違います。BPMN研究会では、ハイレベル/ミドルレベル/ローレベルの3つに分けていて、ローレベルはシステムの処理の振る舞いを書くレベル、ミドルレベルは実行可能なビジネスプロセスモデルを書くレベル、ハイレベルは記述的なモデリング(ドキュメントとしてBPMNをどう活用するか)として整理しています。このうち、ローレベルはパターン化できると思ったんですが、残るミドルレベルとハイレベルのパターン化はあまりに大変そうで手が出せませんでした。その代わりに、ハイレベルを書くためのTips集を作ったり、ミドルレベルに関して今日の話のようなことをまとめたりしています。

ガイドラインは2部構成になっているんですか。

今は4部構成を想定していて、ハイ/ミドル/ローというレベルの考え方の章から始まります。次にハイレベルのTips集が第2部。第3部はモデリング基準のサンプルです。第4部が今日のような内容を簡単にまとめたものです。

パターンというのは、たとえば書類の差し戻しのパターンはこう書くとかいうイメージですか。

レベル感をどうすればいいかも含めて整理が難しいということです。大変なので、そのレベルのパターン化はやめています。

ガイドラインはTips集など、わりと実践的というかベストプラクティス的な、網羅はしないけれどもこうすればいいよ、というものですか。

そういう意味ではまさにガイドラインという名前の通りのものを狙っています。

それでは、さまざまな技術とモデリングの関係についてお伺いします。特にビジネスモデリングとエンタープライズアーキテクチャの関係について、どうお考えでしょうか。

今日の話ではデータとEAの接点をお話したんですが、逆に他はEAとの接点が整理できていません。BPM/SOAという視点でEAとビジネスモデリングをつなぐのか整理できれば、EAの効果が大きくなると思っています。

EAとSOAの位置付けはどうですか。

SOAはモデル主導で設計ができるものです。SOAという領域に焦点を当てることで、EAが実際に動くシステムとうまくつながると思っています。それを確かなものにするために、データ以外でもEAとSOAがつながれば、EAにもとづくIT資産の管理ができるようになると思います。

EAのビジネスアーキテクチャ、ビジネスプロセスに対して、今回のBPMNのビジネスプロセスの定義が似ていると思ったんですか、それは接点にならないんですか。

接点になるようでならないと思っています。EAの整理の仕方は機能視点なので、機能をプロセスでどう横串するかを具体的に整理しない限り接点にはならないと思います。

そうですね。

BA(Business Architecture)とDA(Data Architecture)とAA(Application Architecture)とTA(Technology Architecture)という4階層の話ですか。

その中のBAの話です。接点がDAしかないという話だったので、BAは接点にならないのかと思ったんです。

接点があるはずなんだけれども、その整理が難しいと言うことです。BAで整理されているのは機能志向で整理されている手法が多いんです。ダイアモンドマンダラマトリックス[DMM:Diamond Mandara Matrix 機能構成図]なども、さっきお話ししたような販売は販売、購買は購買という枠で切れた形でブレークダウンして整理していくんです。ビジネスプロセス指向のプロセスは、ブレークダウンして細かくしたのを結びつけるものがビジネスプロセスモデルになるのですから、下に位置付けられないんですね。細かくしたものの下に位置付けると整理は楽なんですが、細かくしたものをどこかのレベルでつながないとプロセスモデルにならないとすると、どこでつなげていくのがプロセスなのかがうまく整理できていません。それが整理できればつながるんですが。

EAは実情としては、それぞれが静的な構造分析にとどまっているんじゃないかと思うんです。モデリングには静的な話と動的な処理の流れの話の両面が必ずあって、プロセスモデリングは動的な方なので、静的にやったものをつないでいくという役目が生まれて、それで全体になると思うんです。しかもBPMNはデータのやり取りも書けますし、具体的にサービスを呼び出すところまで書けるので、現状のEAの上の、BAとDAとAAをフローで結び付けていると考えられると思います。

まさにそう捉えています。ただ、DAは具体的にイメージできますが、それ以外はまだ「なんとなく」というところから脱していません。誰かに「こうやってください」と説明するときに、EAの方ではこう整理してください、ビジネスプロセスモデリングではこう横串を通すんですよ、というところを具体的に説明できるところまで整理できていません。

他に注目している技術として、それ以外に何かありますか。

今注目しているのはXMLスキーマなんです。今日はデータモデルからWSDLにつなぐ流れを話しましたが、あれを実現できるツールがまだないんです。そのツールを見つけ出すところも含めて、一番注目しています。

MDAのアプローチは、UMLをXMIというフォーマットのXMLに落としこむことで、すごく変換の可能性が広がったと思うんですが、MDAというアプローチはいかがですか。

MDAについては勉強不足です。

UMLという図式表現がXMI(XML Metadata Interchange)というXMLに変換できるという効果ですごく変換の可能性が広がったと私は認識しています。明庭さんがXMLスキーマでそんな風に変換できる互換性があると思ったところと近いところで、同じ技術が使われているんじゃないかと思うのですが。

変換する技術は近いと思います。ですが、変換する技術以前に、データモデルの親子関係をどう変換すればWebサービスのWSDLとして使えるかを整理する必要があります。その点も含めて実用的なツールとしてあると嬉しいと思っています。

では次に、モデリングを普及させるにはどうすればいいかという点で、モデリングをするために必要な素質や素養、モデリング導入教育や、中級以上に適用するモデリング技術教育などについて、どのようにお考えかを聞かせてください。

モデリングの領域によって変わると思いますが、「目覚めたきっかけ」でお話ししたように、お客様と一緒に業務をデザインする道具としてのモデリングに注目しています。そう考えたときに一番必要なスキルは、コミュニケーション能力です。それ以外にも論理的に整理する思考能力などもありますが、過去の経験上、あとで反省することは、なぜあの情報を聞き出せなかったかや、説明を失敗して誤解を与えたことに後で気付いたといった失敗が多いんです。相手からうまく情報を引き出したり誤解ないように分かりやすく伝えるスキルが一番大事です。

導入教育については、実践的なんだけれども簡単な課題をこなすのがいいと思っています。しかも、1人で黙々とやるのではなく、グループで話し合いながらモデルを作るのが効果的だと思います。プロセスモデリングの教育で、パソコンの準備の都合で3人に1台でやってみたら、ことのほか盛り上がって、受講者同士が話し合いながら一緒にモデルを作ってくれたんです。それを聞いていたら、けっこういい議論をしているんです。原理原則を講義形式で説明した場合に、人によって理解する場所や度合いが違って、それを受講者のレベルで議論すると理解が深まるんだなと興味深く聞きました。

中級についてですが、ローレベルBPMNパターンを作ったときに、パターン化しようとするとすごく勉強することに気付きました。これまでに勉強してきた原理原則を見直したりして自分なりに整理するのがパターン化なので、中級のレベルではパターンを作らせるのが効果的かと思います。その教育はまだやったことがないんですが、自らの経験からいうと、中級者が上級者にステップアップするために効果的かと考えています。

モデリング技術を体系化するときに、どのような軸やフレームワークが考えられるでしょうか。

ビジネスプロセスモデリングでは、プロセスのタイプという軸が明確にあります。そのプロセスタイプごとに、必要なモデリングや手順を別々に整理する必要があります。タイプも人によって分け方が違うんですが、1つに、人中心の定型プロセス、システム中心の定型プロセス、非定型プロセスという分け方があります。今日お話したのは人中心の定型プロセスで、オンライン販売みたいに、ほとんどシステムがやってくれるんだけれども最後に物を発送するところだけ人が関わるようなシステム中心の定型プロセスは、今日の話とは別の形で整理しなければなりません。差し戻しが複雑な定型化しにくいプロセスはまた違った視点、手順で整理しなければなりません。

今後のソフトウェア産業においてモデリングはどう位置付けられるでしょうか。

モデリングはソフトウェア開発に必須のものに位置づけられると思います。モデルを書いてそれが動くのがあたりまえになると信じています。まだモデルで動く部分はシステムの一部だと思いますが、先々はモデルを書いて動かすのが当たり前で、実行可能なモデルが書けない領域はほとんどなくなると信じています。

オフショアに仕事をお願いするときには発注書などを書くんですが、動くモデルを書いて渡しているかというそんなことはなくて、どういう風に使えばいいかを迷っています。

動くモデルを書けるところはオフショアに出す必要はなくなると思います。オフショアとして残るのはそれができないところだろうと捉えています。

お客様側でもある程度、モデルを書いて作れるシステムの領域が増えていくと思われますか。

現時点ではそこまでは思っていません。動くモデルには動くモデルのお作法があって、記述的なモデリングと実行可能なモデリングの間には敷居があると思っています。確かにユーザー企業の方が実行可能なモデルを書けるといいんですが、その敷居は高いと思います。

それは食わず嫌いということですか。それともお客様と我々作る側とで違うテクニックがあるということですか。

役割分担だと思います。ユーザー企業の方はここまでで、後はSIerの方に任せるという役割分担が根付いているので、それが根付いている以上は変わらないと思います。

では次に、お勧めの本はあるでしょうか。

はい。『BPMN Method and Style』と『シックスシグマ・ウエイ実践マニュアル』です。

最後に、今後モデラーを目指す若いメンバーに一言お願いします。

若いメンバーに伝えたい一言は「こだわり」です。私は仕事柄、かなり多くのビジネスプロセスモデルのレビューをしてきたんですが、分かりやすいモデルにはこだわりを感じます。つまり、きれいに揃ったレイアウトだとか、作業を表すのに単に「受付」ではなく「商品注文受付」のように丁寧に修飾するなど、人に分かりやすく書こうというこだわりを持っている人がいいモデルを書くんです。そのへんのこだわりを感じないと、見た目が汚かったり、分からないことばを平気で使ったりするので、やはり、とことんこだわってモデリングをやってほしいです。その中からいろいろなモデリングのテクニックを得たり、こだわりの中から原理原則を学ぼうという気持ちが出てくるので、作ったモデルが本当にベストなのかを考えて、こだわりつくしてほしいです。

どうもありがとうございました。以上でワークショップを終了します。