ワークショップの趣旨と講師の自己紹介吉田 それでは、今年第3回目のUMTPモデリング技術部会のワークショップを始めます。今回は私が司会を務めます。まず、部会長の山城さんにワークショップの趣旨を説明してもらいます。
山城 このセミナーおよびワークショップは、UMTPのモデリング技術部会の活動の一環で実施しています。今年の4月から2年間かけて、モデリング技術の体系や枠組みを検討するために、四半期に一回、モデリング分野で活躍されている方を招いワークショップで一緒に議論をしたいと考えました。 ただ、せっかく来ていただくなら、UMTPの会員企業やUMLモデリング認定試験L2以上の合格者にもセミナー形式で技術を紹介してほしいと思い、前半にご講演をいただきました。実はここからが部会としての本番となります。いくつかの質問を用意していますので、お考えを聞かせていただき、議論していきたいと思っています。よろしくお願いします。
吉田 浅海さんは以前富士通に勤められていて、オブジェクト指向がマイノリティだった頃に社内の勉強会などで何度かお会いしていた縁もあって、今回は私が座長をさせていただきます。最初のセッションは、簡単な振り返りとして、自己紹介と先ほどのセミナーのサマライズをしていただいた後、講演内容に関して30分ほどで質疑や議論をさせていただきたいと思います。
浅海 浅海と申します。オブジェクトというよりも、XMLやJavaをずっとやってきました。今回の講演のテーマは、第一にモデル駆動です。それから教育ですね。実際にモデリングを学ぶときの切り口として、どういう方法論で学べばいいのか、最後はプログラムにつながるようなきちんとしたものをどう提示するか、が大事だと思っています。それを今回のテーマにしました。
講演内容についての質疑吉田 では早速、質疑に移ります。
中原 クラウドコンピューティング[インターネットを基本にした新しいコンピュータの利用形態。ユーザーは、ネットワーク経由でサービスとしてコンピュータ処理を利用する]というキーワードを最近よく耳にします。クラウドコンピューティングでは、エラーや遅延が起きること、コンポーネントの連携が重要だということは分かります。SOA[Service Oriented Architecture]やBPM[Business Process Management]の技術で、たとえばBPMN[Business Process Modeling Notation]では、タイマーイベントの設定ができたり、BPMのツールは、業務プロセスのシミュレーションができるので、遅延を考慮できます。そういったことをおっしゃっているのでしょうか。具体的な技術などを教えてほしいのですが。
浅海 SOAには2つの意味があると思います。ネットワークのプロトコル的な意味のSOAと、EA[Enterprise Architecture]的な意味のSOAではまったく意味が違っています。EA的な意味でのSOAは、完全にビジネスモデルの世界なので、クラウドとはインフラとして使うか使わないかという関係にしかならないと思っています。BPMもビジネスモデリングのドメイン固有の言語なので、それをどうインフラに落とすか、つまりメインフレームなのかクラウドなのか、それとも他のものなのかということで、ビジネスモデリングに関する議論と、プラットフォーム上での実装技術については別々に考える必要があります。
吉田 メインフレーム、オープンプラットフォーム、クラウドというように、プラットフォームのバリエーションが増えたということですか。
浅海 そんな感じですね。別々に議論するべきことだと思います。
中原 分かりました。
森 7ページ上のスライドについて質問です。現場でコンポーネント開発を目指しても、コンポーネントの品質の問題や使い方の制約でうまくいかなかった部分がありました。今後クラウド時代に入ってコンポーネント開発が進むと思うんですが、この図ではその比重が結構大きいですね。それだけ使えるコンポーネントが出てきていると感じられているのですか。
 図1 クラウド時代のソフトウェア開発 (講演資料7ページ 上のスライド)浅海 コンポーネントというものが今までぱっとしなかった理由は色々あると思います。モデリング技術の進化という意味での制約もあったでしょうが、それよりも流通や配備や教育の問題が大きいですね。コンポーネントで稼ぐには売らなきゃならない。販路を確保しなければならないから営業を、品質も高くしなければならないからテスターを雇う、そうすると価格が高くなって売れないという悪循環があった。また、教育としては、あるメーカーにロックインされた状態の情報をわざわざお金を出して買うか、という問題があったと思うんです。ところが今は、タダで配っている。教育も、フリーのライターが教科書を書いて売ってくれる。ですから、教育のコストもタダだし、タダのネットワーク上で流通させて、そこでお金を取るつもりがないからタダで配っているということで、非常に広まりやすい環境になっています。その中で勝ち残ったコンポーネントが、みんなに使われて叩かれて品質が上がってくるし、機能も上がってくるので、その結果「この機能ならこれだ」というコンポーネントができあがって、一般に流布するのではないかと思います。今までのビジネスモデルの中でのコンポーネントは、技術以外の面で阻害要因がたくさんあったのが、クラウドになることでその要因がはずれてしまう、というのがここの主旨です。
森 見る角度が変わったという感じですね。
吉田 ある意味、情報共有も同じで、社内で情報共有をしようとしても、実は役に立つ情報があんまりない。ただ集めただけという感じでした。それが今、インターネットの時代になって、たとえばWikipediaのように社内で集まる情報とは桁違いの情報量になると、その中にはいいものも結構ある、ということがあると思うんです。それと、今浅海さんがおっしゃったコンポーネントの話は似ているところがありますね。
羽生田 逆に言うと、しょうもないコンポーネントもたくさんあって。
吉田 だけど、浅海さんがおっしゃったように、その中から本当にいいものが選ばれて残る。
羽生田 相当逆転の発想というか、フリーというところまで突き詰めなければCBD[Component Based Development：コンポーネントベース開発]は流行らなかった。
吉田 その可能性はありますよね。
森 オープンにすることで、数も出るし、かえって品質が上がりますね。
吉田 ベースとなる数が桁違いにあると、その中にはいいものも出てくる、ということですね。
猪股 開発のガバナンスみたいなものがあって、無駄なものは開発しないように、できるだけ今あるものを再利用しようということを、COE(Center of Excellence)という専門の部隊が調整していくというものがあると思うのですが。
浅海 それは前からあったと思います。そういうトップダウンのアプローチも引き続き重要なんですが、オープンソースで前提となるインフラが変わってきたのが鍵ではないでしょうか。
竹政 マッシュアップする人とコンポーネントを作る人がいるというお話ですが、コンポーネントは1つの企業ではなく共通な形で作っていき、今までSIをしていたり社内システムを作ってきた人たちは、マッシュアップで作る人たちになってくるというイメージなんでしょうか。
浅海 そうですね。もちろん、必ずそうなると限らないとは思いますが、たとえば、今Salesforceでやっているような感じになっていくんではないかと思います。
竹政 ある意味、公な企業が提供して、それを使うんですね。
浅海 自社で開発しているとコストが合わないと思うんです。ああいうシステムが出てきて広まってしまうと。後はそこにどんなプラグインを付けて自社の特徴を出すかですね。足りなければ自分でコンポーネントを作ることもあるかもれしれないけれど、今までと比べると作る量がまったく変わってきます。
竹政 では、アーキテクチャ設計というのはあまりやらなくてもよくなるんですか。
浅海 たとえばマンションを建てるときに、アーキテクチャ設計を一からするのかという議論になりますね。たぶん、ほとんどひな型ができていて…
竹政 ぽんと持ってきて内装をやって、という。
浅海 芸術的な建築家は一からやるかもしれないけれど、普通のマンションは横並びじゃないかなと。
藤井 基本的な質問なんですが、アプリケーションの開発を効率化するために、アプリケーションフレームワークや言語のレベルを上げるという意味で高級言語や4GLが出てきたわけですが、それらとDSLとは何が違うんでしょうか。
浅海 そういう意味では一緒なのかもしれません。ただ、昔はフレームワークやプログラミング言語の作成は専門家が特殊な状況下でやるものであって、一般の現場のエンジニアが考えることではありませんでした。ところがDSLでは、my DSLを自分で作って、自分でちょこちょこと生成するというようなことを現場レベルでするようになるんじゃないかという気がしています。DSLを作るためのインフラ、コンパイラ・コンパイラじゃないですけど、そういうものを現場で使うという感じになるんじゃないでしょうか。そういう点で、既存の言語化やフレームワークとDSLとはニュアンスが違ってくると思います。
猪股 今のDSLを作るという話なんですが、DSLを設計するときのコツみたいなものがあれば教えていただきたいのですが。
浅海 DSLというと難しく聞こえますが、現場でもエクセルからJavaのソースコードを作ったりは普通にやっていますね。
猪股 自分たちでスキーマを決めて、変換規則を設けて、というやり方ですね。
浅海 そうです。たぶん、そういうことだと思うんです。それがだんだん高度化してくる。今はエクセルでやっているから単純なデータ構造しかできないのが、Scalaの使い方が普及したらもっとすごいのが現場でも作れる。DSLによるモデル・コンパイラのアプリケーションフレームワークができれば、それに乗っかって開発プロジェクトが採用している開発方法論やターゲットのプラットフォームに合わせたモデル・コンパイラを比較的簡単に作ることができるようになるはずです。そういう方向での技術の進化は出てくるかもしれません。
猪股 DSLも、現場というか小さなプログラムの範囲でやっているうちはいいんですが、それを皆が使い始めて、誰かが少し変えるだとか、新しいのを作るだとかやり始めると、バージョンが微妙に違っておかしくなりませんか。その辺の管理をどうするかも少し気になっています。
浅海 それは既にオープンソースの世界で起きていることで、ああいうソーシャル的な解決方法になるんじゃないでしょうか。誰か1人中心的な人がいて仕切るというより、社会的な解決方法で落としどころが見つかると思います。
猪股 同じ流れになるだろうということですね。
浅海 そう思いますよ。
羽生田 最近のDSLは、その記述専用の特化された言語から持ってきて使うというよりは、ある種、ベースになるRubyやScalaやJavaにちょっと色付けするというようなembedded型のDSLが多いので、そこにロックインされる心配があまりないですね。嫌になったら、そのベース言語で自分で拡張すればいい、という自由度があるのも大きいと思います。
猪股 バイナリなどに比べればもっとテンポラリなものだと考えてもいいということですか。悪く言うと使い捨てじゃないですけど。それくらいの軽い感覚でいいということですか。
羽生田 今後もっと一般的に普及したときにどうなるかは分かりませんが、今の時点では自由度が感じられるところが大きいんじゃないでしょうか。
藤井 2ヶ月ほど前にハンガリー人の先生がカンファレンスでDSLについて発表されていました。UMLのモデルでコード生成して動くMDA[Model Driven Archtecture：モデル駆動型アーキテクチャ]的な環境を作ってヨーロッパの企業に持っていくと、ユーザーの方は誰もその最初のモデルを作れなかったそうです。だからそれを解決するために、数式モデルみたいな制御モデルみたいなものを作って、それにもとづいてコード生成して動くシステムができるというDSLに移行したという話でした。そういうニュアンスのDSLと浅海さんのDSLはちょっと違うような気がするんですけれども。
浅海 今の話のDSLは形式言語的な感じなんでしょうか。
藤井 いろんなモデルの観点を自由に組み合わせて業務寄りのハイレベルのモデルを定義できるというものです。
浅海 DSLのメタ言語の体系を作ったという感じですか。
藤井 そうですね、はい。
浅海 僕のはspecificに範囲を絞り込んで、始めからそれに合わせて作っていくので、そういう広がりはないかもしれません。
山城 浅海さんの話にもあったし、以前からCBDの世界でも言っていたんですが、CBDが流行すると部品を作る人と部品を使ってアプリを作る人に二極化しますね。今回はさらに、DSLでよりアプリを作りやすくするための言語を作ってあげるという役割の人もできて、3つの体制だと考えればいいんでしょうか。
浅海 そうかもれしれませんね。僕のイメージでは、いわゆるITアーキテクトという人はきっとDSLを作る人だろうと思います。
山城 9ページでいうところのアーキテクチャ開発の役割がDSLを作る人なんですね。
 図2 クラウド時代のJavaエンジニア (講演資料9ページ 下のスライド)浅海 プロジェクトを開始する際にはプロジェクトが使用する開発方法論を定める必要があります。その際に開発方法論とターゲットのプラットフォームに対応したDSLを定義して必要であればモデル・コンパイラの開発も行うようになると思います。そこまでできる人がアーキテクトなんだろうと思います。当然、足りないDSLがあれば自作するくらいのスキルがないと、アーキテクトになるのはなかなか難しいと思います。
山城 MDAが業界で広く議論されていた時期、モデルコンパイラを作って、部品を作る人と、PIMを作る人、変換ルールを作る人というような体制でやってみたことがあるんですが、ルール作りをできる人がごくわずかしかいなくて、結局回らなかったんですね。それと比べて、DSLベースでやる場合のDSLを作る人の難しさはどうでしょうか。
浅海 僕の感触では、たぶん、1人の人間が目配りできる範囲でしかできないと思うんです。チームで分けちゃったらたぶん機能しないんじゃないかと。1人の人間が扱える範囲のDSLと開発方法論でやって、もちろん、それをどう広げるかという問題はありますけど。
山城 そうすると、仕事として作るような大きいビジネスシステムへの活用はどうなりますか。
浅海 たぶん、チームで分けてできるものではないので、天才みたいな人を雇ってやってもらうしかないんじゃないでしょうか。そこで決まっちゃうと思うんですよ。つまり、プロ野球の4番打者1人の力でチームのパフォーマンスにすごく影響を与えるような、そんな役割になってくるんじゃないかと思います。そういうDSLも含んだ開発プロセスまでちゃんと定義できる人をどうみつけるかという話です。
山城 そうすると、スケールアップした開発に適用するには、もう少し工夫や技術の進歩が必要ということですか。
浅海 そういう人を社内で意識して育てないといけないと思うんです。縦割りでやるんじゃなくて、全部できる人を1人でも2人でも作らないと。
照井 今回のSimple Modelingのお話ですが、Simple Modelingを使って開発していく中で、上流から下流へのフィードバックとかイテレーティブな開発で、おそらくSimple ModelingのDSLが変わってきたんじゃないかと思うんですが、いかがですか。
浅海 SimpleModleingは実務には適用していませんが、wakhokでモデリングのゼミを行った中で色々なフィードバックがありました。そのため、SimpleModelingのメタモデルについてはある程度フィードバックあり最適化を行ってきました。Scala DSLについては作り始めなので、まだフィードバックはかかっていないんです。これからいろいろやろうかというところです。やってみるとフィードバックが返ってくると思いますが。
Ajay 14ページのUMLの短所で、「大規模開発に必ずしも適していない」とありますが、たとえば組み込みでは、一から作っているのはとても少ないと思うんです。常にベースがあって、改良や追加を行うという形ですね。それでどんどん複雑化してバグも出てよく分からない状態になる。その追加、改良というところに関しては、Simple Modelingを導入した場合の管理面はどうなるんでしょうか。
 図3 UMLの長所と短所 (講演資料14ページ 下のスライド)浅海 プロダクト・ライン的な開発に向けてはアーキタイプの導入を考えています。ひな型をメタに扱えるモデルとして事前に定義しておいて、品質特性や非機能要件を入れると変換できるとか、アスペクトみたいなことをやるとかです。誰かがアーキタイプを用意して、それを自分のプロジェクト用に変換し、それに対して自分のところのモデルに変換していくというようなことができるんじゃないかと思います。
猪股 興味本位の質問なんですけど、DSLを使って実際に動くというところを指向されていると思うんですが、上流や問題領域と言われるところのモデルに対して、作ったものが本当に要求に従っているのかとか、正しく作られているのかという検証は考えられていますか?
浅海 オブジェクトモデルの動的モデルは、現在の技術レベルだと形式的に書けないので、自動生成はできないと思うんです。ただし、ひな型的なものとか画面のフォームのようなものまではDSLでできるでしょう。そして、ユースケースの抽象的なシナリオを実際のシステムの設計モデルで翻訳したものがテストシナリオになるじゃないですか。だからユースケースモデルからテストシナリオを作って、それが動くかという機能的な検証、連携の仕組みは、もしかしたらできるんじゃないかと思います。
猪股 テストシナリオを特定できるような情報をユースケースモデルに入れるべきだというイメージですか。
浅海 そうです。だから、SimpleModelerのユースケースモデルは、普通の文章ではなく、プログラムみたいに書かせるんです。ただ、変換するときに日本語っぽく変換して、シナリオの形式で見せるようにします。ユースケースのフローはテストシナリオにある程度つながるように書かないと、ユースケースモデルとしては機能しないかと思います。
河合 25ページのスライドでも紹介されていますが、マインドマップでユースケースを書くというのがどんなイメージかをもう少し詳しく教えていただけますか。
 図4 マインドマップによるモデル記述 (講演資料25ページ 下のスライド)浅海 マインドマップ・モデリングでは業務ユースケースを物語と呼んでいます。たとえば「顧客が携帯電話を入手する」物語があるとします。その携帯電話を買うというビジネス上の目的を達成するためのイベントの列として、ビジネスイベントが3回起きます。ビジネスイベント1が起きたときにリソースの状態が変わる、ビジネスイベント2が起きたときにリソースの状態が変わる、ということをやっていくと、最終的にユースケースの実行の中で状態Aから状態Bに変わるわけです。そのビジネスイベントの発生の順番や、どういうビジネスイベントが発生するか、それとリソースの状態遷移、この組み合わせでユースケースを書けば、いろんなことができるんじゃないかと思います。
河合 この図では、携帯電話を買う物語があって、その手順のためにイベントが並んでいるという感じですか。
浅海 イベントが並んでいて、イベントごとに状態遷移があります。たとえば、携帯電話の販売台帳がリソースとして定義されていたら、販売台帳の状態が変わるとかです。
河合 イベントの列を書くという書き方ですか。
浅海 そうです。マインドマップモデリングだと出来事と呼ぶんですが、出来事の列を書くわけです。
Ajay そこからテストケースを考えるときに、書ける項目も分かるということですか。
浅海 ユースケースでどこまで書くかですが、テストまで考えるとパラメータに近いところまで入れなければいけないかもしれません。まだそこまでは考えていません。ただ、そういう方向で連携できるということです。
山城 16ページの下の「Simple Modeling モデル変換/作業の流れ」にも関連するんですが、OMGのMDAだと、最初にCIM(Computation Independent Model)、次にPIM(Platform Independent Model)、それからPSM(Platform Specific Model)、最後に実装となり、それぞれの間に変換があります。ただ、CIMからPIMへの変換はあまり議論されていなかったんですが、今回浅海さんが狙っているのは、OMGで言うCIMレベルから実装までの全体の変換なんでしょうか。CIMからPIMのところはいわゆるマインドマップのツールで変換しようとしていて、PIMからPSM、あるいはPSMから実装の変換にSimple Modelerを使うと位置づけられているのでしょうか。
 図5 Simple Modeling モデル変換/作業の流れ (講演資料16ページ 下のスライド)浅海 CIMで書く内容とPIMで書く内容は、ドメインモデルを使って連携させます。それは変換ではなく連携で、たとえばツールなどで検証をかけます。その1つのモデルから、可能な範囲でPSMに変換する。問題空間の中では1つのかたまりであって、それを解決空間に変換していくようなイメージで考えています。
山城 CIMもPIMも人が考えて作って、それは整合が取れたもので、そこからSimple Modelerを使ってPSMを生成しようとしているんですね。
吉田 17ページの下の図のドメイン・モデルがちょうどCIM、PIM、PSMになっていますが、アプリケーションモデルはそういう変換ではなく、上位のものを流用しながら詳細化するという感じでしょうか。そのときにドメイン・モデルを使って連携しているんですね。いわゆるOMGのモデル変換というのが、ドメインモデルのところに現れているわけです。
 図6 Simple Modeling ドメイン・モデルをハブとした連携 (講演資料17ページ 下のスライド)山城 シーケンシャルな変換ではないということですね。
吉田 そうです。むしろ19ページにある階段のような考え方です。
 図7 企業システム・モデリングの3階層構造 (講演資料19ページ 上のスライド)山城 CIM/PIM変換は企業でかなり期待しているんですが、できないんですね。
浅海 業務フローからプログラムの自動生成は難しいかもしれません。僕は業務フローよりも業務プロセスを重視しています。そして、業務プロセスを業務フローとイコールと考えるのではなくて業務プロセスというモデルは業務ユースケースの集まりだと考える方がバランスがいいと思うんです。フローチャートで書いたもの、特にドメインモデルの状態遷移と連携していないようなフローチャートからプログラムを完全に自動生成するのは難しいんじゃないでしょうか。そうすると、実際の開発方法論的にもツール的にも、業務プロセスというのは業務ユースケースの集まりであり、業務ユースケースで扱うドメインモデルまではツールで吸収できるけど、そこから先はある程度手作業でやらなければならないところが出ると割り切った方がいいと思います。その上で、業務フローはいくつかの代表的な業務ユースケースを統合した概念モデルとして利用するというようなアプローチがよいのではないかと思っています。
吉田 20ページの上にも階段が書いてあるんですが、こういう関係です。同じものが変換されていくのではなくて、一部分が詳細化されていって次につながるという階段状になっています。
 図8 Simple Modeling 軸となるモデル連携 (講演資料20ページ 上のスライド)山城 それがOMGアプローチに欠けていたんですね。
吉田 そうです。浅海さんの本はそういうところが精密に書かれていて、プロセスと成果物が明確で、とてもよい教科書だと思いました。上流から下流まで網羅した教科書は見つからなかったと浅海さんがおっしゃっていましたね。照井さんは教科書をたくさんご存知ですが、いいものはありましたか。
照井 UMLは汎用言語なので、これというのを選びづらいと思いましたね。
吉田 あえて言うと、Craig Larmanの『実践UML』でしょうか。あれはかなり最初の方から最後まで全部書かれていますね。ただ、確かに浅海さんの『上流工程UMLモデリング』のような精密さは欠けていますね。浅海さんのこの本は非常に精密に書かれているので、うちのSEにも読ませたいです。
山城 41ページにエクセルでモデル記述する例がありますが、企業で要求モデルや基本設計のモデルを作るときに、エクセルベースでテンプレートを作って、それを展開するようなことをやっています。その人たちはプログラマであり設計者でもあるんですが、DSLでプログラムのように仕様を書きなさいというと、すごく敷居が高いんですね。エクセルで穴を埋めていくのが現場に普及しやすいと思うので、たとえば、エクセルで書いたものをDSLに変換するとか、DSL形式にしてからエクセルで清書するとか、そういうやり方の方が現場に適用しやすいのではありませんか。
 図9 Excelによるモデル記述 (講演資料41ページ 上のスライド)浅海 SEさんの現場に行くとみんなエクセルなので、その感じは分かります。SimpleModelerはDSLとしてScalaを使ってるんですが、エクセルをDSLとして使用しても同じような変換はできるはずなのでそういうやり方も可能だとは思います。エクセルについてはSimpleModeling用のフォーマットも作ってゼミで使用していたのですが、その経験では、入力補完ができないし、ツリー構造が定義しづらい。表構造からちょっと逸脱したデータ構造をやろうとすると、入力するのも大変なフォーマットになりますし、作るのがそもそも大変です。たとえば44ページの下の図では、Scalaの機能を使ってユースケースのシナリオをツリー構造で定義しているんですが、これをエクセルでやろうとすると大変なことになっちゃうんです。現場でやっている方の慣れの問題もあってエクセルでしかできないこともあると思うんですが、かなり制約が出るという気がします。
 図10 SimpleModel DSL 業務ユースケース「BU顧客が商品を購入する」 (講演資料44ページ 下のスライド)山城 ある程度勉強してこういう記述形式で書けるようになれば、開発環境を通してそれなりの見返りがあるということですか。
浅海 今までEmacsなどを使っていた人がEclipseのIDEを使ってプログラムを作ると、元に戻れないんですけど、そういうことが起きるんじゃないかなという気がします。入力補完などがすごいんです。一度入力補完に慣れちゃうと、それがないとプログラムを作る気にならないくらいです。他にも、その場でコンパイルやエラーチェックもしてくれます。このようにIDEの能力が強力になってきているので、これを活用できるのかどうかという点がエクセルとDSLの言語ベースの違いとして出てきます。
照井 Simple ModelingではUMLのビジュアルの図は使うんでしょうか。
浅海 UMLの図を入力にしても構いません。たとえばJudeとはそういう連携をしようと思っています。ただ、UMLのモデラーでこのSimple Modelingのプロファイルに合ったものを作っても、モデラーの中で合っているかどうかを検証してくれないので、非常に大変でしょうね。ただ、UMLの使い方としては、その他に、情報伝達のスケッチや、施工図(設計図ではなく)があります。保守用に、できあがったシステムの現状をちゃんと書いておくことは非常に有効だと思うので、リバースでどうUMLを作っていくか、それをどう資料として残すかは考えなければと思っています。
照井 最近、UMLのtextual notationを使ってテキストで書くのが標準化されていますね。
浅海 UMLの仕様であるのは知っているんですが、SimpleModelerでは採用しませんでした。テキストベースのDSLの実現には、IDEのサポートを享受できる可能性が高い強い静的型付けのプログラミング言語をメタ言語に使用するのが適している思います。SimpleModelerではこの目的でScalaを採用しました。また、UMLテキスト表現言語はUMLのモデルを正確に記述するのが目的の言語だと思いますが、SimpleModelerは用途を限定することでモデルをシンプルにすることを目指していているので、DSLによる記述もできるだけ単純化したいという狙いがあり、その意味でも汎用性の高いUMLのテキスト表現言語ではなくて、専用言語を使用することにしました。
照井 テキスト中心でモデリングすると、ステークホルダーに確認するなど、図でコミュニケーションを取ることの優先度が低くなってしまうことはないですか。
浅海 たとえば、1 000個のクラスが入っているクラス図をお客さんに見てもらえるかというとそうではありません。今でも概念図は別に作っていると思うんです。お客さんとレビューするために。そうすると、結局は、ものを作って動かした後に、お客さんとのレビュー用のものを施工図として作って確認した方が効率的なんじゃないかと思います。
照井 目的によって図は違いますね。お客さんとの確認はたとえばユースケースだったり、プログラマにアーキテクチャを説明するクラス図があったりすると思うのですが。
浅海 リバースでどう作るかですね。どちらにしても、出てくるクラスを全部書くわけではなく、ハイライトとして書くので、結局そのための作業が必要になります。ですから、一からUMLを使って設計したら得かというとそうではないんじゃないかと。できあがったモデルをレビュー用にいかに清書するかが大事だと思います。
照井 テキストでの DSL によるモデルは、モデルを作成する人に対しては親切だと思うのですが、そこから自動生成されたHTMLなどのドキュメントの方は、ご経験上十分とお考えでしょうか。
浅海 UMLは施工図としては非常に重要なので、必要に応じて施工図を作るのがいいんじゃないかと思います。
吉田 UMLはノーテーションが標準化されていることよりも、メタモデルが標準化されていることが、我々の産業としては一番重要なんです。ところが、UMLツールがそれぞれ勝手なモデルリポジトリを作っているので、その上で自動生成するものを作っても他で使えなかったりという問題がありますよね。それを一応OMGで標準化して、かつEclipseがEMF[Eclipse Modeling Framework]というJavaのメタモデルのソースを出してくれているので、それをハブにして変換を作れば変換ツールも簡単になりますね。つまりn通りのメタモデルがあるとn×nの変換を作らなきゃいけないけど、EMFというハブがあるとn通りの変換で済むわけです。そういう意味でちょっと危惧しているのは、UMLやMOF[Meta Object Facility]をメタモデルとして考えていらっしゃらない点なのですが。
浅海 EMFとOMGのMOFが本当にイコールなのかが外部の人間からはよく分からないのですが、ずれてるんじゃないかと思うんです。
照井 ずれていますね。
浅海 僕が調べた範囲だとどうもずれていて、EMFの方が威張っている感じが何となくするんです。
吉田 その通りです。実用的にはEMFに合わせる方が意味がありますね。
浅海 そこが危惧なんです。ただ、もしもEMFが完全にオーソライズされてしまえば、リポジトリとして当然使えますし、ツールも一式揃っているので、そことの連携を考えようかなと思います。ただ、今はまだ様子を見ています。
吉田 EMFにさえマッピングできれば、これから作られる他のツールもみんなEMF上で使えるようになる、そこが一番重要だと思うんです。
浅海 SimpleModelerではScala DSLを作っていますが、これはただの記述方式であって、大事なのはメタモデルです。SimpleModeling/SimpleModelerでは、UMLのメタモデルに対してプロファイルをかけて、範囲を絞り、UMLで足りないところを追加するというアプローチを取っています。その記述方式としてScalaを使用していますが、EMFのツール一式が揃えば、メタ・モデルそのものはUMLの土台の上に構築しているので、連携できるんじゃないかと思います。
吉田 そうしておけば、やっぱりUMLで見たい場合にもいつでも変換できるし、アーキテクトの数だけ違うDSLができても、それらの間の流用性や、それらの上で作ったツールの流用性があるわけですね。それが重要だと思います。 あともう1つ、コラボレーションが重要だとおっしゃいましたが、textualなDSLだと本当にコラボレーションが見やすく書けるのかが懸念です。UMLのグラフィカルなノーテーションを書くのが大変だとおっしゃいましたが、ことシーケンス図に関しては、非常に書くのが簡単だし、見てすごく分かりやすいと私は思います。
浅海 僕はシーケンス図を書くのが辛いですね。直すときも位置がずれたりしますし。
羽生田 そのシーケンス図は2.0の凝ったものですか。
浅海 いえ、そんなことはありません。
吉田 凝ってなくてコラボレーションを表せればいいだけですか。
浅海 ビジュアル的に情報伝達力に優れているのはその通りだと思うんですよ。
吉田 書くのが大変ということは、使っていたツールの問題ですか。
浅海 Judeを使っていました。Roseも昔使ったことがあるんですが。
吉田 今のラショナルのシーケンス図はとっても楽ですよ。
浅海 でもマウスを使った瞬間にちょっと…
吉田 あぁ、マウスがだめなんですね(笑)
猪股 テキストベースというのは、マウスを使うかどうかというのがすごくポイントなんだろうなと思います。マウスを使わずガシガシ補完しながら書けるのがいいんですね。
浅海 あと、プロパティシートが上がってくるのもダメなんです。つまりキーボードのホームポジションから手がはずれるようなのがだめ(一同笑)
吉田 そうやって書いて後で自動生成した方がいいと。
浅海 そうする方が僕は楽なので、そういう人も多いんじゃないかと。
吉田 エクセルが好きな人はエクセルで、シーケンス図にしたい人はシーケンス図にして。
浅海 見るときはいいんですよ。
猪股 テキストで書いてシーケンス図がリバースされればいいんですね。
浅海 最高ですね。
 図11 “モデグラム” (講演資料43ページ 上のスライド)藤井 そもそもなぜオブジェクトモデルなんですか。構造化分析設計のようなところまで立ち戻ってもいいんじゃないかとも思ったんですけど。
浅海 DOAとのからみもあると思うんですが、コラボレーションとかユースケースとかシーケンスとか、その辺がオブジェクト指向のメリットだという気がします。
藤井 発想を単純にダイアグラムに書いていくという点では、DFDなどの方が直感的に、発想に従って書けるような気がするんですけども。
浅海 好みの問題もあるかもしれませんね。僕は基本的にプログラマなんですが、OSのプログラムなどを作っていると、ものすごくでかいデータ構造の中にイベントがちょろっと入るとぴっと変わって、という繰り返しなんですよ。ああいうのは オブジェクト指向でモデル化するのがいいんじゃないかなというのが、もともとオブジェクトの道に入ったきっかけでもあるので、そういう意味では制御系のシステムなどではオブジェクトが自然なのかなと思います。
羽生田 業務系のモデリングでもいけると。
浅海 業務系は、データベースや画面設計だけなら要らないと思うんです。もちろんオブジェクト指向は有効ですが、必須というほどではない。しかし分散的なことが入ってくるとさすがに必要ではないでしょうか。
羽生田 クラウドとかSOA的に、いろんな企業や組織が並列して動いている中で、ネットワークを使ってコンピューティングするというところで、必要になるんですね。今回の講演は、「クラウド」というのが枕詞に出てきたので、「そこから始めるのか」と思ったのですが、そこには意味があるということなんですね。
浅海 そうです。DOAとオブジェクトの違いはそこがポイントじゃないかなと思います。
羽生田 いつもDOA屋さんに、こっちの方が理論的に整然としていて、方法論の完成度が高いじゃないかと責められるんですが、その辺が納得できました。 もう1つ、モデルの関係性のことで質問があります。現実世界をドメインモデルとして捉え、それとは別に、その中で業務をユースケースという形で抽出して、そこからコラボレーションを取り出しますね。もう一方の入力として、今の技術体系や情報システム、クラウドも含めた運用プラットフォームなど、インフラや運用などの裏方的なサービスが結構重要です。それはモデルにしなくていいのでしょうか。
浅海 一応、緑の本[『上流工程UMLモデリング』]ではページ数の関係で大分削られちゃったんですけど品質特性といった非機能要求について少し入っています。ただプラットフォームに近いところは、Simple Modelingの中で考えなくても、得意な方にお任せしていいかと思っています。
羽生田 クラウドとかを考えると、そこはある程度仮想化して、うまくやってくれるプロフェッショナルな集団があるだろうから、そこはいいと。
浅海 現実の物理モデルにマッピングするところはいいでしょう。SimpleModelingでは業務モデルから論理コンポーネントの仕様を作成する所までを主なターゲットにしています。論理コンポーネントから先の技術はすでに広く普及しているので。
講師とモデリング吉田 では、そろそろ次のセッションに進みます。モデリングというものに目覚めたきっかけや、モデルとは何かとか、ご自分なりの定義、あるいは現状のモデリング技術の問題点などをお話しいただければと思います。
浅海 モデリングは、Boochメソッドを見て、これは使えるかと調べ始めたのがきっかけです。Boochの本の第2版[『Booch法 : オブジェクト指向分析と設計』]が1994年くらいに出たと思います。僕はデータベースではなくOSをやっていたので、OMTに書いてある概念モデルにはあまり興味がなかったんですけど、Boochメソッドは設計に近い、プログラムをどう作るかというころを扱っていたので、これなら仕事に使えそうと思ったのがきっかけです。あと、ヤコブソンのOOSE[『オブジェクト指向ソフトウェア工学OOSE』]を読んで、ユースケースはいいなと思った、そのあたりですね。 モデルは動かない部分を作るためのもので、動く部分はモデルを作らなくてもプログラムを書いてしまえばいいと思います。ただ、動かない部分がたくさんあって、たとえばさっきのCIMみたいなところはプログラミングできません。また、お客さんとネゴシエーションしなければいけないところや、開発者の中で意識を合わせなきゃならないところは、モデルとして作らなきゃいけないと思います。 現状のモデリング技術の問題点は、あまり普及していないことですね。僕がお付き合いしているXMLやJavaのエンジニアはこの辺の技術にあまり興味がないようです。本当は大事なはずなのに、あまり現場には普及していないのが問題かなと思います。きちんとやらないといけませんが、難しいですね。
山城 何が難しいと思うんですか。UML自体が理解するには難しすぎるということですか。
浅海 そうなのかもしれません。緑の本を書いていて、モデリングするために必要な知識が無茶苦茶多いなと改めて思いました。あれを一通り知らないとアーキテクトのような仕事はできませんよね。最初から全部できる人はそうそういないので、アーキテクトの人が相手のレベルに合わせて仕事の範囲を絞って渡してあげるという階層構造になっていると思うんですが、そんなにうまくいってないんじゃないでしょうか。
吉田 モデリングできるために知らなきゃならない色んなことというのが、まさにこの場で議論したいことなんですが、たとえばどんなことがありますか。
浅海 たとえば、僕の本ではあまり詳しくは取り上げていないんですけど、クラス図の書き方については色んな方が色んな本を書かれているし、ユースケースの技術も何冊も読まないと分からないですよね。ユースケースをどう作るのか、それをロバストネス分析にどうマッピングするか、それは実はコラボレーションのことなんだとか、あるいはUMLのメタモデルも多少知らなきゃいけない。それからプログラムにつなぐところ。プログラムの作り方も、コンポーネント指向やEJBなど、何か1つのプラットフォームについては多少知らないといけません。結構色々あって大変だと思います。
山城 それが敷居の高さになってしまっていると。
浅海 1つはそうですね。あとは、いい教科書がない。僕の本も難しいと言われていて、あれよりもっと簡単でいい入門書がないと、なかなか独学では大変です。初心者を中級者に持ち上げる平板な教育ではなく、アーキテクトになれそうな人をきちんと会社のシステムとして教育するということをしなければいけないのかもしれません。
山城 そこまでいくと、1つの会社の中ではなかなか教える人もいないし、教育自体ができないんじゃないでしょうか。業界として、あるいは学術的に何かしなければ。
浅海 マイスターみたいな人がある程度の密度でいないと、下が持ち上がっていかないのかなという気がしますね。
中原 弊社も苦労しています。手頃な案件があればやらせるんですが、今は案件も減っていますし、失敗もできないし、なかなか育っていないです。
浅海 僕がオブジェクトを始めた1990年代の半ばと比べると、今は知らなければならないことが増えたと思うんです。XMLもJavaもそうだし、これからScalaも覚えなきゃならないかもしれないし(笑)、そうなると今の若い人が独学で一からやるのはきついですね。
藤井 アーキテクトやシニアのエンジニアで、人に教えたがらない人が多いことも問題ですね。むしろ対人関係が苦手だったりして。あとは、自分の技術が完全ではなくて、人に教えられるレベルじゃないと思っている人も多いと思います。
浅海 僕もそれは分かりますよ。自分の言っていることが正しいかどうか、僕も自信がなくて、恥を忍んでという感じでやっています。
吉田 あと、いざ教えようとすると、手頃な教材が確かにありません。それで浅海さんの本はいいなぁと思っているんですが。
Ajay 企業は「導入するとどんないいことがあるか」の分析で頭がいっぱいになっています。導入すると業務が増えることになりますね。上の設計が分からなくて、仕様だけでやってしまうというのがプログラマの本音なんですよ。そこにわざわざアーキテクトを入れて何がいいのかが分からないというのがあると思います。
浅海 数値化しろと言われるとね。
Ajay そう、それが求められる。
猪股 求められているのは動くプログラムなのに、それとは違う動かないものを作れと言われたときに、そのメリットを知っていて成功体験があり、使いこなして成果を出しているコミュニティはいいのですが、「うまくいったから君たちもやって」と言われて何もないところでやるのは、ものすごく負担だと感じたことがあります。
浅海 そうですよね。会社だとプログラムができる人を管理職にしちゃって、そういう人のスキルが現場に残らないということもあります。
猪股 そうなってしまうとプログラムを書かなくなってしまいますね。
竹政 プログラムを書く人とモデルを書く人にはかなりギャップがあるのかなという気がします。おっしゃるように、中間的なモデグラマーみたいなものがいるなと。プログラムというのはやっていれば上手にできるじゃないですか。モデルは敢えてやらないとできない。その中間として、プログラムをやっていればモデルもできるようなところがないかな、という気がするんですけれどね。
浅海 プログラミングの時に使う頭の回路でモデルを作ることができればいいなと僕も思いますね。そのための仕組みや仕掛けとしてDSLみたいなものを使う。結局、作ったものが動いたり成果物が出ることが大事だと思うんですよ。概念図を書いて、正しいかどうか分からないけど先に進むというのだと、作ったものがプログラム生成につながったりとか、コンパイルしたらエラーになっちゃったというようなことがないので、プログラム的な回路が働かないので。
竹政 それを書いて動くなら、モデルを書くのとプログラムを書くのがあまり変わらなくなる気はしますね。
浅海 ツールでその距離をつめれらないかな。
猪股 モデルが動けばいいんですよね。動くまでいかなくても、「それは正しいよ」と言ってくれると、先に進める。
浅海 検証器でもいいから、赤い線が引かれて「エラーだよ」とか言ってくれると、インタラクティブにモデルと関わり合えます。そういう仕組みがあるといいですね。
猪股 プログラムだとそれが確実にありますよね。
竹政 それがあると自分でやって伸びるんですよね。
羽生田 プログラム言語もScalaみたいに超高級化というのを進めて、それと同時に、モデルもDSLという形でexecutableな方向に歩み寄るという、両方から攻めて、残ったギャップをコンパイラで埋めるという感じでしょうか。
モデリング原論吉田 では次のセッションに行きます。このセッションでは「モデリングの方法論」「モデリング原理、原則、パターン」「情報システムとソフトウェアの関係」といった点を議論しますが、まず羽生田さん、テーマの意図を軽く説明してもらえますか。
羽生田 モデリングは体系的に捉えられるものなのかという点は、答えとしてSimple Modelingを挙げられていますね。「モデリングの方法論」は、その方法論がはたして妥当なのかを考えたときに、こういう原理原則にもとづいて構成されているからいいんです、という部分です。「モデリング原理、原則、パターン」は、アーキテクチャパターンやデザインパターンといったものが世の中にあって、かなりアドホックなところが感じられますが、それと今回の方法論とはどういう関係で捉えるといいのか、です。それから、これも浅海さんがSimple Modelingをまとめられた最初のきっかけだと思うんですが、情報システムを動かすということと、ソフトウェアを作るということと、モデリングということをどうつなげていけば、意味のある行為として成り立つのか、ですね。答えはこれまでの話に出てきたと思うんですけど、もう一度そういう視点でお話しいただけますか。
浅海 「モデリングの方法論はあるのか」という点ですが、僕の場合、リファレンスとして使っていますね。これだけじゃないんだろうけど、こういった切り口もあっていいかと思います。「原理、原則、パターン」は、原理や原則はあるんだろうと思いますが、答えが思いつかないですね。パターン記述というのがあるので、いろんなところで使いたいと思うんですけど。
羽生田 それはもうSimple Modelingに組み込まれています、という答えですか。
浅海 ここでいう原理原則はどういうものですか。
羽生田 たとえばモデリング原理だと、「識別されるべきクラスは業務の中で意味のある責務を持っていなきゃいけない」とか、「識別したクラス同士できちんとしたバランスのいい責務の分配がされていなきゃならない」とかから始まって、アナリシスパターンみたいなものもあるし、LarmanのGRASP[『実践UML』で説明されている責任割り当てのためのパターン：General Responsibility Assignment Software Patterns]パターンなどでの整理の仕方もあります。そういうような、世の中で分析原則とか設計原則とかパターンと言われているものと、今回のSimple Modelingはどうつながるんですか。
浅海 どうなんでしょうね。メタモデルを作るところに注力していて、原理、原則、パターンというものはあまり考えていないんですけれど。
藤井 かなり盛り込まれている気がします。マインドマップなどでも特定の視点を作っているわけですよね。
浅海 そういう意味では、汎用化するというより、僕がいいと思ったものをそのまま使っています。パターンでいえば、エージェントとリソースとイベントのパターンを使って、DOA的な観点を入れてクラス図のパターン化をしています。僕の場合はパターンというよりプロファイルを作っているという感覚で作っているんですけど。
吉田 浅海さんはもうほぼ完全に体得されていて、それが自然に滲み出ている感じですね。他の教科書で多いのは、まず原理原則を述べて、それから例を挙げて、あとは自分で応用しなさいというものなんですが、浅海さんの『上流工程UML』の教科書は、この工程ではこう考えてこういうフォーマットでこれを書きなさい、そのときにはこう考えるんだよ、ということをずっと書いてらっしゃいます。原理原則をその場面に具体化したものとして「そのときにはこう考えるんだよ」というのが書かれている感じですね。
河合 それに関して、自分は何に価値を認めているかという「価値」が一番上にあって、その価値を実現するために原理、原則、戦略があるわけですね。戦略の次に戦術というのがあって、パターンはそこなんですが、一番上の価値がはっきりしないと、戦略も戦術もぼやけます。その価値のところをもう一度お聞きしたいんですが。
浅海 僕にとってのモデリングは、まずプログラムに落ちることです。もちろん、お客さんの意図をできるだけ正確に反映し、かつプログラムも実行できるということです。
河合 ファウラーは、モデリングのよい悪いの判断基準を「使いやすいこと」と表現していますが、それについてはどうですか。
浅海 僕は、プログラムに落ちないと気が済まないんで、プログラムに落とすためにきれいさは多少犠牲にしてもいいと思っています。きれいさを追求することで、プログラムに落ちにくいモデルになると、僕の価値観では本末転倒ですね。どちらかというプログラムを軸に考えています。
森 そう考えると、「じゃあプログラムを書けばいい」ということになりませんか。
浅海 だから、解決空間についてはモデルを作る必要はなく、そこはプログラムでがんがんやればいい。困るのはプログラム化できない問題空間です。たとえばユースケースなどはプログラム化できないので、モデルを作るしかない。ドメインモデルなんかも、用語集みたいなところはお客さんと付き合わせしないといけないので作るしかありません。プログラム化できないけれども、お客さんの視点として大事なところを、モデルとして模型化するわけです。
羽生田 最低限、問題空間のさまざまなモデル要素と結びつけられるようなタグはプログラムに付いていないと困りますね。そのくらいの作法はある程度守らせるということですか。
浅海 そうですね。スライドには出ていませんが、多重継承は使わせないとかですね。本当の自然界のモデルを人間の認知モデルに従ってやっちゃうと、プログラムに落ちないので、そこは犠牲にして、ある程度妥協しながらやっていきます。
山城 お客さんが外にいて、そのお客さんに「これでいいよ」と言ってもらえないと先に進めないんですが、「いいよ」と言ってもらう、つまりお客さんに承認してもらうための要求定義や設計仕様は、この方法では別に作らないといけないのでしょうか。
浅海 SimpleModelingは実際のお客さんに適用したことはないので実際に使えるかどうかは分からないんですが、演劇のメタファーで、たとえば俳優だとか道具だとかイベントということでモデルを記述することになっています。もしかしたらその範囲でお客さんに納得してもらえるんじゃないかな、と希望としては思っています。このメタファーはSimpleModelingの技術の一つであるマインドマップモデリングの基盤にもなっています。
山城 メタファーレベルで理解してもらえれば、それとの対応でどういう仕様かを理解してもらえる可能性があると。
浅海 舞台の上で、たとえば卓袱台だったり、刀が置いてあったりするのを、登場人物が出てきてイベントを起こすと状態が変わって、位置が変わったりしますよね。そういうメタファーで記述するんです。それをマインドマップで書くんですが、それとオブジェクトモデルが1対1の対応になっているから、お客さんに説明するときにはそのメタファーが使えるんじゃないかと考えています。
山城 なるほど。面白いですね。
要求と分析と設計の関係吉田 では次に、「要求のモデリングはどう行うべきか」「分析と設計の関係をどう捉えるか」「アーキテクチャ設計のモデリングはどう行うべきか」といった点についてお話いただけますか。
浅海 要求のモデリングは、シナリオというかユースケースが大事で、それを軸に考えたいなと思っています。あとの非機能要求は、マインドマップのフォーマットを用意しておいて、そこに書いていくようにしています。
分析、設計についていうと、僕は分析、設計ではなく問題空間、解決空間に分けているんですが、解決空間はプログラミングでOKで、問題空間はモデルとして書き込んでいくように考えています。 アーキテクチャ設計のモデリングについては、アーキテクチャのビューをいくつか設定すると思うんですが、そのビューごとにUMLを使って図を書いていくのが妥当かと思います。コンポーネント図みたいなものを使って書くのではないかと思います。 羽生田 UMLの苦手なところの1つとして、動的な部分のモデリングは完璧にできない、という話がありましたが、具体的にはどういうところでしょうか。
浅海 イベントの発生に伴ってオブジェクトの状態を変えたい場合に、executable UMLだとアクション言語が出てきて、結局プログラミング言語で記述することになってしまっています。一般のプログラマからすると、メソッドか何かでできるところをイベントハンドラみたいなところに状態遷移モデルをプログラミング言語で書くことになって、意味論的には同じかもしれないんですが、使いづらくなっていると思います。
羽生田 それは、クラスモデルとステートマシンを組み合わせることで解決できないんですか。
浅海 できるかもしれないけど、結局最後はプログラムが出てくると思うんです。それなら、少なくとも現状では、最初からプログラミング言語で実装すると割り切った方が楽だと思います。ただ、ここはもしかしたらブレークスルーがあるかもしれないので、それを待ちたいなと思います。
藤井 講演の中で、システムのハイレベルのモデルが、問題領域だけじゃなくて下位領域も若干含んだ形で、完全にきれいに分離できずに入り込んじゃうという話がありましたね。そこは私も同感で、そのあたりで論理設計に食い込む部分もあるんじゃないかと思うんですが。
浅海 少なくともアーキテクチャ設計の部分は要ると思うんです。アーキテクチャベースラインなどの部分は、ある程度ハイレベルな人が少人数でチームで作るだろうし、アーキテクチャベースラインができた段階でコンポーネントのインターフェースが定義されると思うし、そこから先は勝手によろしく、という形ですね。ただ、アーキテクチャベースラインを作るときに、アーキテクチャ設計の範囲を超えてその先どの程度細かい設計までしなきゃならないかは、ケースバイケースだと思います。
吉田 図で書かなくても分かっているというのと、分からないから書かないというのは違っていて、一度分かればもう書かなくていいわけですね。アーキテクチャ設計は、まず「こうだよね」とみんなが分かって、後はそれに従ってコーディングすればいいことだと思うんですけど、往々にして、分からないというか、モデルとして捉えられていないのにひたすらプログラムだけを書いているから困っちゃいますね。
浅海 本来は必要ない作業かもしれないけど、管理者側の保険としては書いてほしいなというのは、確かにありますね。
吉田 10モジュールのうち1つは書いてもらって、分かっていることが確認できたら、もう書かなくてもいい、というのもありかもしれません。
猪股 パターンを共有するときなどは、プログラムを直接見てもらうより早いですよね。
浅海 情報の流通ですね。共有などの目的にはすごく有効だと思います。
さまざまな技術とモデリングの関係吉田 では次に、ソフトウェア開発に関するさまざまな技術とモデリングの関係について、たとえばOCLとかSOAとかWeb2.0とかオフショアとか、これについては一言ある、というものがあれば教えてください。
浅海 UMLについては既にいろいろ言ってしまいましたね。メタモデルが定義されていて共通言語になっている点はすごくいいと思います。OCLは、使いたいんですが、いいライブラリが探せていません。形式手法は、僕はよく分からないんですが、どれくらい今実用化されているんですか? アカデミックな世界のことはあまり知らないので。
竹政 VDM[Vienna Development Method。IBMのウィーン研究所で開発された形式手法]などはわりと話題になって、CSKさんなど が一生懸命やられていますよね。代表的な例では携帯のFelica IC チップの開発に使っています。
吉田 組み込み系で特に有効みたいです。
竹政 VDMで書くとソースコードと同じくらいの量を書く必要があると聞いています。そのため、特に安全性とかセキュリティが要求される分野で使用される例が多いようです。
羽生田 そういう意味ではVDMという形式仕様言語がDSLに当たるんですよね。ここからC++やJavaを吐き出せるので。
浅海 形式的言語だから数学的な裏付けがあるんですね。
羽生田 はい。プログラミング言語のプラスアルファとして、振る舞いの事前条件や事後条件を契約としてきちんと定義しておいてチェックが掛けられる、というのがあります。
浅海 この辺の分野は僕も勉強中なので、いろいろと教えてください。
山城 モデルチェックという技術を最近使っているところがいくつかあります。複数のプロセスの協調動作の時にデッドロックが起きるかとか、ライブロックが起きるかとかを、時制論理(Temporal Logic)という時間を考慮した命題論理式を与えて、それが成り立つかどうかを、状態機械を複数立ち上げてぶん回して検証するというものです。
浅海 ライブロックも検証できちゃうんですか。
山城 はい。そういうものだと組み合わせて使えそうですね。生成ではなくてケースの検証、Verificationなんです。
羽生田 状態マシンが到達可能性などをちゃんと満たしているかを検査するんです。
浅海 では、UML的な意味での大きな広がりより、もう少し絞り込んだ中での検証ですか。
山城 そうですね。
浅海 MDAに関してはいろいろ調べたんですが、たとえばQVT[Queries/Views/Transformations。OMGが定義したモデル駆動型アーキテクチャにおけるモデル変換の標準]なんかを調べようとしてAmazonを見たら、本が1冊も出ていないのであまり流行っていないのかなという印象を持ちました。ただ、スライドにも書きましたが教科書としては優れていると思うので書籍などでの情報公開を期待しています。SOAは、先ほど言ったとおりですね。ビジネスモデリングやエンタープライズアーキテクチャといったビジネスモデリングの技術はSimpleModelingの対象外にしています。ただし、ビジネスモデリングの成果物としてITシステムを構築するのに必要なモデルを「業務モデル」として定義しているので、このモデルを通してビジネスモデリングと連携したいと考えています。
Web2.0/3.0については、Webの世界に特徴的なデータ構造である半構造のデータ構造(semi-structured data)に興味があります。スキーマがアプリケーションごとに用意されていて、アプリケーションとは独立してすでに存在しているデータに対して、自分の好きなところだけ取り出して使う、というニュアンスの技術体系だと思うんです。今のオブジェクトでは、そういう部分はメタデータ的なところに切り出してカチカチに扱うような感じになりがちなんだけど、別の技術体系で面白い切り口が出ているんじゃないでしょうか。ただ、今僕がやってる活動の中にそれが直接入るかというとそうではないんですが。
オフショアについては、コンポーネント開発が普及すればプログラミングに近い所はオフショアに行ってしまうでしょうね。我々の主眼は業務に近いところに徐々に移って、運用管理は全部クラウドの方に行っちゃう、という世界になるでしょう。
DOAとUMLについていうと、既存の開発部隊にはDBAというか、データベースのベテランがいっぱいいらっしゃるので、そういう部隊がいるところではやはりDOAでずっとやらざるを得ないんでしょうね。でも、DOAだとどうしてもDFDなどの方に行ってしまって、ユースケースやコラボレーションという技術がうまく利用されていないのではないかと思います。だから、ユースケースやコラボレーションという技術をDOAに組み合わせて使うようなアプローチはあってもいいと思います。それが機能するかどうかは分かりませんが。ドメインモデルになるところでSimple ModelingではなくDOAのアプローチを使い、アプリケーションモデルのところをオブジェクト的なものでハイブリッドで使うようなやり方が可能かもしれません。 藤井 データモデル、つまりERモデルと、ロバストネス図を使っているところが結構あるみたいです。
吉田 その他に、最近これだという技術はありますか?
浅海 Scalaですね(笑)
山城 プラットフォームや運用はクラウドにいっちゃう、構築はオフショアにいっちゃう。そうすると我々企業の資産というか武器は何なんだろうと考えるんです。ドメインモデルは対象やお客さんによって違うじゃないですか。そうすると、結局そういうことを全部分かっている「人」しか残らないのかなと思ったんですが、どういう風に考えたらいいですか?
浅海 お客さんがやりたいことを実現するという部分に一番価値があるわけなので、お客さんの言葉をコンピューターの言葉に翻訳するところが一番大事なんです。翻訳といっても、膨大な技術体系の中で翻訳していかなきゃならないので、技術体系を知っていて、自分の会社の開発プロセスやモデル体系が頭に入っている状態で、お客さんの言っている自然言語を翻訳する、というところが本質的なんじゃないかという気がします。
山城 そうすると、情報資産という形では企業には残らなくて、何でも知っている「人」という形になってしまうんですか。
浅海 そうですね。データではなく、変換器としての人ですね。何かをすると何かを出してくれる人というのが大事です。情報や設備ではなく。
中原 変換するというのは、具体的にどういうことですか?
浅海 お客さんと話をして、お客さんの言葉をこちらの言葉に翻訳するということだと思うんです。やりたいことをコンピュータで実現するとどうなるかというのをちゃんとイメージできて、それにはこういうインフラとああいうコンポーネントを使ってこうやるんだ、などを考えながらお客さんとインタビューできる人、になっちゃうんでしょうね。
中原 そうすると、今、ITベンダーは国内にいっぱいありますが、かなり絞られる方向になりますか。
浅海 100年くらいかかるかもしれませんが。
中原 今すぐではないですね。
浅海 ただ、今はマッシュアップでプログラムを作るのがものすごくやりやすくなっています。若い人などを見ていると、ぱぱっと作りますから。そんな感じになると思うんです。つまり、お客さんの話を聞いて、ぱぱっと目の前で作ってしまう。今はWebのまだ小さい世界なんですが、エンタープライズシステムもだんだんそういうことになっていくんじゃないかな。もちろん、仕掛けはもっと大掛かりになると思うんですけど。Webでは本当に簡単に作れてしまうというのが実現しているので、あれがもっと広がってくるんじゃないでしょうか。
羽生田 サービスとして信頼度の高いものを提供するという道で生き残るか、ユーザーのエージェントみたいな形で購買代理店として動いてマッシュアップで部品を組み立てられる人か、かなり二極化しますね。
藤井 コンポーネントとおっしゃっているものは、いろんなところに分散していろんな種類のものがあって、企業システムなんかはそれをフレームとして作っていくような感じになるんですね。
浅海 Webシステムみたいな小さなシステムを作る人はインターネット上に散らばっているコンポーネントをマッシュアップするアプローチが有力です。本当にすごいガチガチのシステムを作りたい人は、品質問題があるのでSalesforce的なアプローチで、ある基盤を買って、その上に構築するようになるんじゃないでしょうか。全部が全部、マッシュアップでやるわけではないと思います。
藤井 SOAに関して、企業システムで、たとえば運送業者を複数切り替えながらシステムに組み込んでいくときに、運送業者ごとにインターフェースが違うのを隠蔽するような内部的な仕組みをトランスレーターで作って、企業システムに統合している、という話を聞いたことがあるんですが、そういうことが結構起きるんじゃないかと思うんです。1つのベンダーに頼るんじゃなくて、複数のところを並立して使っていくようなシステムの作り方を試行するんじゃないでしょうか。
羽生田 それはリスク分散ということですか。
藤井 そうです。
浅海 マッシュアップ的な作り方がこれからもっと伸びるということですか。
藤井 Webでマッシュアップで単純に作るレベルではなくて。
羽生田 オープンにされているものの組み合わせではなく、新たに作る業務システムなんだけれども、そういうセンスで作ると。
浅海 Webのマッシュアップは今起きていることの実例で、それは信頼性が低くてもいいんですけれども、最終的にはもっとガチガチの世界でも似たアプローチになって広がりを見せてくるんだろうなぁと思います。分散環境でいろんな相手といろんな通信をしなきゃいけないという世界に入ってきつつあるので、それをモデリングに取り入れるにはDOA的なアプローチだけでは辛くて、コラボレーション的な切り口のモデリングも必要になりますね。
モデリングを普及させるための教育吉田 次の議題になりますが、モデリングの普及方法について、これまで私たちは、モデリングはできる人とできない人がいるみたいだ、という議論をしてきたんですが、できる人を増やすにはどうすればいいんでしょうか。何かご意見はありませんか。
浅海 プログラミングもできる人とできない人がいるじゃないですか。できない人は本当にできないので、できそうな人をある程度選別して、意図を持ってきちんとやらないといけません。とにかく今の技術体系はとても大きいので、独学に任せると辛いです。素養や素質は必要なので、そういう人をちゃんとピックアップしなければいけませんね。
吉田 具体的にこんな素質が要るよというものはありますか。
浅海 人のことは言えないんですが、きっと、例え話がうまいとか、そんな頭の使い方ができる人ですね。
Ajay 組織ごとに1人専任を置いて、必ずレビューなどに参加して勉強すればいいかなと思います。全員に教育するのは会社としても時間や向き不向きなどの問題があって難しいですけど。1、2人でも無理でしょうか。
羽生田 今回浅海さんが話されたのは、どちらかというとアーキテクト指向のモデリングだと思うんですが、ユーザー視点で業務をモデリングするにはもっとたくさん人がいないといけないので、もうちょっとマスで教育できないとまずいという気もするんですね。
浅海 そういう意味では、ある程度定型化した手順は必要なんでしょうね。詳しく分からない人でも何となくそれなりのものができてしまうという手順がないと難しいと思います。
河合 理科系と文科系という切り口では、僕は文科系の方がモデリングがうまいという気がしています。ちなみに浅海さんはどちらですか。
浅海 僕は電気工学です。やっばり例え話ができる人とか、抽象的な捉えかたで言い換えや比喩ができるような感じの頭の使い方があるのかなという感じがします。それは文系も理系も関係なくて、ある程度の素養というか持って生まれたものがあるかもしれません。
河合 面接で話をして分かりますか?(一同笑)
羽生田 それとプログラミングの能力とはどう関係するんですか。
浅海 いろんな人と仕事をしてきた中で、プログラミング能力とモデリング能力はちょっと違うかなという感じがしています。ただ、プログラミングができない人はモデリングもできないんじゃなかろうかと思います。プログラムの場合は、バグが出たときに取りきるという執念みたいなものも要るので、執念がなくてモデリングだけできる人はいるのかもしれませんけど。
Ajay テスト設計についてはどう思われますか。モデリングできない人はいいテストケースが書けないとか。
浅海 テストは、やはり人によって持っている能力が違っていて、何かちょっとずつ抜けてしまう人もいますし、とても緻密にできる人もいますね。
Ajay プログラムは書いたとおりに動くじゃないですか。でも設計書は動かないもので、文書上でやるわけですよね。だからプログラムは絶対なので、プログラムができる人は設計もできるけど、設計ができてもプログラムはできない人がいるんでしょうか。
浅海 一応、テストをする人も設計する人も、僕の気持ちではプログラムができることが前提としてあってほしいですね。
吉田 モデリングのさまざまな技術を体系化して、提示したいというのがこの部会のテーマなんですが、それに対してこういう軸や枠組みで体系化できるんじゃないのといったアイデアなんかがありませんか。
藤井 講演の中で、体系化することの必要性を主張されていましたが、それを考えた結果がSimple Modelingなんですよね。
浅海 そうですね。たとえば、メタモデルだとか記述言語もあるし、開発の手法だとか…、たとえばUMLといっても、UMLの中の記述言語的な側面とメタモデルの側面とは違うだろうし、問題空間と解決空間とか、色んな軸があってよく分からないですね。
羽生田 今のSimple Modelingの枠組みは、現時点である程度納得して整備されたということですか。
浅海 そうです。僕はあれがいいかなと思っています。モデリング技術の構成要素はとても多くて、それらのすべてを汎用的にしてしまうととても僕の力では扱えなくなってしまいます。そこで、教育目的と中小規模開発を対象に範囲を絞り込んで可変部分を少なくして、モデル体系と作業手順を具体化したものがSimpleModelingです。
羽生田 逆に、そこに今欠けていて、この辺がいずれカバーしたいなとかこういう軸を追加したいなとか、あるいはこの分野ではこれでいけるけど、この分野はもうちょっと別のことを考えなきゃならないなというようなことはありますか。
浅海 制御系に持って行くにはもう少し動的モデルを強化しないといけないと思っています。状態遷移などですね。あとはプラットフォームごとにどう対応するかということと、非機能要求のあたりを今はマインドマップに書くことにしているんですが、もう少し形式的というか、うまく体系の中に入らないかと考えています。またルール・モデルの取り込みも行いたいと考えています。
羽生田 今、非機能要求をマインドマップに定義したとして、それとどこかのモデルの要素をトレースさせるようなことはしていますか?
浅海 今はないんです。信頼性がどのくらいかなどを文章で書かせるだけなので、その辺を取り入れられればいいですね。
吉田 では次に、UMTPの活動、特に認定試験に関して、何かご意見はありますか?
浅海 ちょっと見てみたんですけど、なかなか難しそうで(笑)。あの試験はいいと思いますね。単にUMLの文法をテストしているのかと思ったらそうではなくて、モデルのテストなのがいいですね。
山城 難しいというのは、どういう難しさですか。UMLのいろんな記述ルールが分からない難しさなのか…
浅海 そうではなく、問題が結構大きいので、解こうと思うのにエネルギーが要るんです。作るのも大変だったと思います。でもあれくらいの試験でないと実力は分からないですよね。
今後のモデリング吉田 それでは次に、モデリングは今後のソフトウェア産業においてどう位置づけられるとお考えですか。今までのお話とかぶりそうですが。
浅海 お客さんとコンピュータの世界をつなぐ共通言語や模型として機能すると思うので、必要なことだと思います。お客さんにも現場のエンジニアにも普及していないので、やはり両方を向いていくことが必要ですね。
山城 企業にとってモデル自体は情報資産になりますか?
浅海 たとえば業務ユースケースの蓄積は資産になると思います。
山城 お客様の業務のユースケースですか?
浅海 たとえば、あるクレームが上がったときにどういう物語が進展して、最後にお客さんがどういう気持ちで帰るかということをユースケースとしてモデル化するとします。そういうのは大きな資産だと思うんです。新しくシステムを作るときに、そういう例外処理的なユースケースがいっぱいあればいい。一から全部考えるとすごく大変だし、たぶん漏れるので、そういうものの蓄積というのは、作ったSIerにとっても、ユーザー企業自身にもすごく大きな資産になるんじゃないでしょうか。
山城 ユースケースというのは業務のユースケースですから、ソフトウェアでどう実行するかではなくて、お客さんの業務を理解するためのものですか。
浅海 理解もあるし、別のところにも展開できますね。新しい業務を作るときにどういうクレームがあがりやすいかとか。そういったモデルはすごく大きな資産じゃないかと思います。
山城 お客さんのドメインのことを自分で経験しなくても、そういうユースケースを見て知ることができるということですか。
浅海 そうです。問題空間のモデルはやはり大事ですね。
藤井 ドメインモデルを企業内で共有する仕組みやリポジトリについて何かアイデアはありますか。
浅海 いろんなことが言われているみたいですが、まだ分からないですね。絶対にガチガチにやるべきだという人もいるだろうし、分散するのが当然かもしれませんし。僕は分からないです。
吉田 モデリングを勉強する上で何かお奨めの本はありますか? ないから書かれたのかもしれませんが。
浅海 1冊だけ読むとすると、ヤコブソンのOOSE[『オブジェクト指向ソフトウェア工学OOSE』]がいいなと思いますね。今まで読んだ中で一番でした。
羽生田 どういう点がいいと思われましたか?
浅海 ユースケースから、システムのロバストネスモデルの基本的な理解に必要な考え方、今の言葉で言うユースケーススライスのマッピングがちゃんとが書いてあるんです。その後のロバストネス分析について書いた本で、それが書かれているのを見たことがないので、やはり原典を読むしかないなという感じですね。この本の日本語版はまだ売ってるんですか?
羽生田 ありますよ。当初の出版社からではなく、再版を行う特殊な出版社から復刻版が出ています。
吉田 では、最後に、モデラーを目指す若いメンバーに一言お願いします。
浅海 若いうちはプログラムをがんがん作ってください!
吉田 どうもありがとうございました。
参考文献
|
「UML」でモデリング技術の向上を推進