それではモデリング技術セミナーの後半を始めたいと思います。前半が講演で後半がワークショップという構成にした意図について、部会主査の山城さんからご紹介ください。

UMTPのモデリング技術部会は、部会メンバーがワークショップ形式の議論を通して、モデリング技術の体系・枠組みを検討しています。部会には各社でモデリングをしている人が集まっているんですが、部会の中だけじゃなく、有識者の人にも来ていただいて一緒に議論をしたいと考えました。
有識者の方には、もともとはワークショップだけに参加いただく予定でしたが、せっかく来てもらうなら、モデリング技術に興味を持つ、外部の方々にもオープンにして講演もしていただこう、ということになったわけです。我々としても前半の講演で勉強してからワークショップができるので、かえって良かったと思っています。長丁場となりますが、よろしくお願いします。

それでは、議案にそって進めて行きます。まず、講師の山田さんの自己紹介をお願いします。講演の時には言えなかったことも含めてお願いします。

この業界には二十何年かいて、SRAやソニーコンピュータサイエンス研究所を経てフリーのような立場でやっています。主にソフトウェアを作る人がお客さんで、ソフトウェアを作るお手伝いなら何でもします。お客さんの要望によって、プロジェクト管理やモデリングやアジャイルなど、いろいろ勉強させてもらい、面白いことはコミュニティを立ち上げたりしてオープンにしたいと思ってやってきました。
今日のテーマですが、まず「ソフトウェアとは?」を考えたときに、「動く知識である」という見方が面白いと思います。その視点で見ると、今のソフトウェア開発プロセスで、要求をどう定義するか、見積もりをどうするか、設計が何か、というのはおかしく見えるんです。「動く知識である」という視点からソフトウェアを作るということを見直して、お客さんのドメインと実現のドメイン、問題のドメインと解決のドメインを融合したいと思っています。モデルは知識なんですが、動かないと意味がありません。それがお客さんにとっても動いて見えるといいな、というのが今日の話です。

では、今日のセミナーについての質問をお願いします。

戦略マップからシステムの要求をビジネスモデリングするプロセスの中で、モデルが消えるという話がありました。目的じゃなくて機能の方に行ってしまうという。でも戦略は、人間が暗黙的に持っている知識とシステムが形式的に持っている知識との組み合わせで実装する必要があります。そうだとすると、トップダウンのニーズから動くものを作るのは難しいのではないですか?

戦略マップは例であって、それをITだけで実現することはもちろんできません。戦略マップの場合なら、それが人の間だけにあるんじゃなくてシステムの中にも埋め込まれていいよねってことです。何が戦略だったかが、議事録やコンサルのレポートを見れば載っているだけじゃなくて、たとえば会議をしているときに何が目標だったかがいつも見えているといいよね、ということなんです。トップダウンで実現するべきだという意味ではなく、単なる例です。他にも要求仕様書が全部システムに入っていてもいいと思います。

よく考えると、ソフトウェア以外でも、モデルが残ること自体が当たり前のことではないですね。

そうですね。たとえば建築でモデルを作ったものがピロティに飾られていたりはしますが、飾られているだけですね。ただ、ソフトウェアは面白いことに、「ソフトウェアのモデルもソフトウェア」のようなところがあります。あるというか、そうしちゃいたい。生理的に。論理的な裏付けはないんですが。

せっかくソフトウェアで仕事をしているんだから、ソフトウェアの性質を最大限に使いたいということですね。

ここまではソフトウェアじゃないもので、ここからはソフトウェア、というように分けたくないんです。

そうすると、今日の話にはあまり出なかったんですが、システムだけでなく、組織やコミュニケーションスタイルを変えることも、仕事の1つということなんですか?

システムに埋め込みたいわけです。お客さんからの要求として「社員の間のコミュニケーションを改善したい」というものがあるとする。そのためには何をすればいいかを列挙して、ITにマップできるものは切り出して、それが要求仕様になっていろいろな機能が出てくる、というのが普通の流れです。もう1つ、人そのものをシステムに埋め込んでしまうというのが考えられます。これは昨今では珍しいことではなく、SNS[Social Network Service。人と人とのつながりをインターネット上で構築するサービス]なんかはそれに近くて、システムの中にアバターとして存在する。ビジネスのシステムであれば、その人がどういうスキルを持っていてどういうプロジェクトをやっていて、さらにプロジェクトというモデルがあってそこにリンクされているという、ソーシャルネットができてしまう。その中で、こんなスキルを持った人を集めてプロジェクトを作るとどうなるかをシミュレートしたいという要求が出てきたとしても、ネットワークさえできていれば、その機能を作るのはそんなに大変ではないような気がします。ソーシャルネットのようなものをトップダウンで作るのは大変だけど、ボトムアップで、普段仕事をしている中で作っていくなら可能だろうと思うんです。

たとえばソーシャルネットのようなコンテキストを与えれば、その目的に最適化したネットワーク、人のつながりができる。ビジネスのコンテキストではインフォメーションワークスペースなどがありますが、システム化というのはそういう意味ですか?

そんな感じです。

「システムに埋め込む」のイメージが分かりにくいです。Smalltalk[クラスベースの純粋オブジェクト指向プログラミング言語と、それによって記述構築された統合化プログラミング環境]が一番近いというお話でしたが、ソースコードに開発言語レベルの制約があまりなくて、ソースコードやモデル自体が仕様のようなかたちで読める、というようなイメージでいいですか?

そんなイメージを思い浮かべています。

そこにエンドユーザーが何かを入れたら、それがそのままプログラムになるというイメージなんですね。現状でそれに一番近いのがSmalltalkやGrails[Javaで実装されたスクリプト言語Groovyを使った、自動生成機能をもったWebアプリケーションフレームワーク。詳細は『Grails徹底入門』(山田正樹ほか訳)を参照]になるんですか?

使い方次第ですけれどね。Webアプリでそれが書きやすいのはGrailsかと最近は思っています。Smalltalkもある時期はよかったんですが、今それですべてうまくいくかというと難しい。道具なので使い方次第ですし、道具自体も発展していかなきゃならないと思います。

それは使い方やプロセスのレベルで実現できるものですか? それともそれとは別にシステムやパッケージが必要なのでしょうか?

今までとは違うアーキテクチャの考え方がないと、広げていくのは難しいかと実感として思っています。モデルを動かしてしまうので、モデルが変わったときのインスタンスレベルへの影響をうまくコントロールできないと、単純にうまくはいかない。MVC[Model View Controller。ソフトウェア設計モデルの一つ]に相当するアーキテクチャが必要だろうと思います。

動くモデルといっても1つの視点で作られたモデルですよね。それに適合するものとしないものがあって、概念としてハイレベルになればなるほどそこから離れていくんじゃないかと思うんですが。

あるモデルを考えた時点で視点は固定されます。システムを作るときにはその固定された視点でおしまいですが、ある視点で足りない部分は違う視点からのモデルを作って継ぎ足すという風にシステムを作り続けると考えると、最初からすべての視点が入っている必要はなくて、インクリメンタルに必要なモデルを作りこめばいいことになると思います。

それでも低レベルなモデルの種類は1種類なんですよね? たとえばOMT[Object Modeling Technique(オブジェクトモデル化技法)。UMLのスリーアミーゴの１人であるJames Rumbaghらが提案したオブジェクト指向モデリング手法、その記法の多くは後にUMLに取り入れられた]のレベルでいうと、機能モデルと動的モデルとオブジェクトモデルの3種類があって、ハイレベルなモデルを構成しているけれども、実装言語で複数のビューを定義できるものはないと思うんですが。

今のtextualな、たとえばJavaなどを考えると非常に難しいですね。たとえばGrailsではいろんな視点のモデルを書ける。基本的にはコードっぽく書くんですが、ほぼモデルと言っていいと思います。そのモデルの組み合わせでWebアプリケーションの実現まで落とせる。もちろん理想ではありませんが、今までの他のものに比べると自由にできるように思います。

この話を聞いて、実現方法としてはDSL[Domain Specific Languages(ドメイン特化言語)。特定の種類の問題に特化したコンピュータ言語]が一番近いのかなと思いました。コンテキストに応じた言語を作成して作りこんでいくという認識であっていますか?

はい。GrailsはDSLのかたまりなんです。ですから、その認識であっています。

何かプラットフォームが必要なのではないでしょうか? 私は最近Second Lifeというものをやっているんですが、あの世界では物理エンジンというルールがあって、重力や雲や水の流れを作る。その決まりの上で住民がオブジェクトを作り、LSL[Linden Script Language(リンデンスクリプト言語)]で動きを与えるんですが、うまく調和していきます。同じように、お客さんの情報システムでも、ビジネスエンジンというルールがあった上で、モデルを動かすならいいと思うんです。組織やビジネスルールやモノやカネについて、この制約だけは満たさなきゃならないというのを仕切る環境が必要なのではないでしょうか。

その通りだと思います。最近では、ビジネスオントロジー[ビジネス分野で使われる概念の意味や概念間の関係を定義したもの]の流れを実装寄りにしたような、アナリシスパターンの一種のようなものをベースにして、システムを作っていくものがいくつか出ています。たとえばビジネスでは、モノが入ってきたらそれと同じだけ何かが出て行く、お金を貰ったら製品を出荷するなどという、非常に基本的なパラダイムをベースにして、その部品というかアスペクトをいくつか組み合わせてシステムを作るという考え方があります。Grailsにそれを入れようと実験しているところです。

そこで動くのがDSLベースの言語ということですね。

DSLを作るということは、最低の制約条件を決めるということでもあります。

お客さんの情報システムで動くソフト1つ1つにBI[Business Intelligence]の機能を持たせると、とても冗長だし、能力やコストの面でも作るのが大変です。お客さんのビジネスとソフトウェアは1対1ではなくて、1対nとかn対nですね。そこを解決しなければならないのではないでしょうか。

そうですね。今は楽観的なことばかり言っているんですが、実際に作ってみれば大変というのはおっしゃるとおりです。ある意味でのアーキテクチャというかパターンというか、「こういうものだよね」と見切れるだけの何かを、経験から見つけていかないとだめだろうと思います。それは理論でどうこう言えるものではない。

それを制約ベースのプラットフォームの上で作らせたりルールを守らせることが必要ですね。

それは実装の話ですよね。そのあたりは試行錯誤ですね。

それはITガバナンスと言われている領域に関係するんではないかと思います。

お客さん側からベンダーへの?

そうです。いろんなベンダーが出たり入ったり、新しい人が入ってきたりしても、お客さんの中でポリシーが崩れない、冗長にならないようにする、そういうところで議論されている話のように思います。

そんなリテラシーに対する認識が高まってくると、さっきおっしゃったようなシステムを実現できる可能性が高まってくるということですか。

そのガバナンスも、人の世界でありながらソフトウェアの対象となり得る世界で、管理系ソフトウェアとして流行りつつあるところですね。

現状ではビジネスプロセス1つ明確にするだけでお客さんの方で大変なことになってしまいます。

今までプロセスがないところでうまく回していたものを、無理やり表出させようとするとギャップがあります。

いい面も悪い面も両方あるんだと思います。

うやむやのまま人の裁量でうまくやっていた、属人性のよさみたいなものもありますね。

今回のテーマの「機能から様相へ」の「様相」ですが、山田さんは「動く問題と解決の記述である」と定義されました。「問題と解決の記述」はパターンですね。山田さんの話では「ソフトウェアとは実行可能な知識である」ということですが、パターンとは知識のことですね。パターンを実行可能にする、パターンを実現するのがソフトウェアだ、というように感じたのですが。

そうなのかもしれません。

知識とは何か、というのは永遠の課題なんですが、私は「ソフトウェアは知識の結晶である」と考えています。問題から解決へのパターンを作る人と、そのパターンを利用する人がいる。その知識を可視化するのはモデリングであり、デザインパターンのようなシステムの知識だけじゃなくて、開発プロセスの知識も含めてパターンですよね。広い意味で言えばコンピュータのソフトウェアだけでなく開発プロセスや業務プロセスも含めてソフトウェアだと思うんです。そう思って「様相」ということばを考えていたら、機能からシステムを作るのではなく、問題から、その解決策としてソフトウェアを作るのかな、と感じてきました。

それは一番難しいところで、定義のしようもないと思います。ただ、ソフトウェアが面白いのは動くところなんです。いくら本を書いて知識の表現がいっぱい含まれていても、動かない。ソフトウェアは動く。プログラムは知識の表現でしかないけど、動いたとたんに表現じゃなくて知識そのものになる。ソフトウェアに似た実行可能な知識には、もしかしたら「組織」があるのかもしれません。そうすると、違う種類の実行可能な知識がうまく重なる。そのあたりが、今回のお題かと思っています。

人間は実行可能なんでしょうか? 組織も、そもそもは人間なのかもしれませんが、人間は自分で分かって動いている気がしますね。でも組織となったとたんに、誰かが「こうしろ」と言って動いているわけじゃないものになる。そういう意味で、人間というより組織の方が、知識の動いたものという感じがします。

私たちの会社も、経営の戦略やビジネスプロセスとアプリケーションとを関係付けようとし始めました。関係性を持たせるということは、ソリューションベンダーとして、ソリューションの価値を上げることです。戦略はこうだから、そのためのビジネスプロセスはこう、それを実現するシステムはこう、というトレーサビリティを考えます。それをリポジトリに入れて参照するようになっています。でも今回の話は、ソフトウェアの中に埋め込みましょうということですね。建築の事例も出てきましたが、構造計算書などをとりあえず見えるところに置くというところから、埋め込んで何が嬉しいか、その辺のお話を伺いたいです。

今日の内容は結構挑発的に話しています。それが現実的な解かは別です。ただ、ソフトウェアと建築は違うものです。リポジトリもソフトウェアでアプリケーションもソフトウェアなら、つながってもいいですよね。それが1つです。それから、建築でも、壁のボタンを押すと構造計算の結果が全部見えれば面白いかもしれないし、配管を全部表に出すことによってすべて見えるという考え方もあるかもしれない。もちろんセキュリティなどは必要でしょうが、すべてが対等なファーストクラスのものとして見えるというのは、ソフトウェアとして究極的に面白いんじゃないかなと思います。それが現実のビジネスの中で嬉しいかどうかは別かもしれませんが。

「動く」について、機能モデルレベルで事業主が直接いじってアプリケーションそのものが変わるという話ですが、その場合、上位のBSC[講演で取り上げられたBalanced Score Card]のプロセスの定義体が変わるというリンクに対して自動変更を与えるという構想があるんでしょうか?

BSCが例としていいかは分からないし、現実としてITやバーチャルの世界をどこまでリンクすればいいかは一概には言えませんが、基本的にリンクが可能でリンクが中心的になっているというのは面白いですね。そういうアーキテクチャがある程度必要じゃないかと思います。実際にどこまでやるかは別ですが。

アプリケーションには、粒度の小さいものから経営の視点の粒度の大きいものまであります。下のものを変更したときに、上にどう関係付けて反映するかは、自動的に分からないんじゃないかと思うんですが。

そうですね。簡単じゃないと思います。

上は変わらないのが前提なんじゃないですか。

ゴールのモデルがあって、それに対して課題があり、その課題に対する施策があって、その下にビジネスプロセスがある。直接ゴールを変更するのではなく、ビジネスプロセスに対して影響があって、プロセスから組織、組織からさらに上位と連携すると考えると、上にどこまで伝えるかは微妙ですね。

所詮はモデリングの対象は機能だというテーゼが出ましたよね。でも、信頼性やセキュリティといった非機能要求は、最終的なコンポーネントのレベルでは分散します。具体的なサービスレベルのメカニズムがどこに含まれているのかというと、雲散霧消しているじゃないですか。実際にはいろんなコンポーネントが協働してサービスレベルを支えるわけです。そうすると、「このコンポーネントがこの非機能要求を説明付けなければいけない」という言い方は根本的に変な気がするんですね。創発の意味がなくなってしまう。その点と今日の話はどうつなげて考えればいいんでしょうか。

非機能要件までは考えていませんでした。それは確かにそういう性質のものだろうと思います。一方で、今日お話した、モデルとして書いたものが消えてしまうというのは、今おっしゃったのとはちょっと違っていて、残っていると思うんです。創発的に発生する性質とは違うような気がします。

でも、たとえば経営目標はいろんな人がいろいろがんばった総体的な効果として達成されるものですよね。

そうですね。これを達成するために因果関係をたどってどれとどれがどうなってなきゃいけない、まで言えるかどうかは分からないです。でも、少なくともBSCみたいなゴールがあるんだったら、それが今どうなっているかは簡単に分かると思うんですね。

山田さんのトレーサビリティの話はよく分かります。ただ、後半になってテキスチャや様相という話が出ましたね。様相にモデル化されている内容物と、それが重ねあわされたり折りたたまれたりしてできあがった一部分としてのシステムとのつながりが、本当にトレーサブルといえるのでしょうか。オブジェクト指向的にモノが組み合わさってシステムになるのとは違う、布の重ね合わせの力学というか場の理論みたいなものが必要かと思ったのですが。

そうですね。リンクや制約という部分があって、自動的にはできないところも多いと思います。たぶん人が入ってつないでいるのでしょう。ただ、どこに人が入ればいいか、人がどう動いたらどう変わりそうかくらいは分かればいいと思います。ゴールを自動的に達成するシステムを思い浮かべているわけではありません。

あくまで機能はプログラムとして新たに作りこまなければいけないということですか。それを引き上げるための情報は、そこに入っているようにしたい、と。

そうです。機能は作るんですけど、安く、ほとんどタダでできるんじゃないか、ということです。

それはDOA的な発想のように思えます。データ設計さえうまくいっていれば、機能については少し手を入れればシステムができるという考え方とのアナロジーを感じました。Dの代わりにPなのかKなのか分かりませんが、そういったものが設計できていれば、それをピックアップする機能に関してはタダみたいなものだ、と。

うーん、失敗しちゃいました(一同笑)

悪い意味で言ったんじゃなかったんですけど…。

テーブルは硬いじゃないですか。そこが少し違いますね。気持ちは近いかもれしません。「データの意味がちゃんとできていればfunctionはそこから作れる」という点では、共通するところはあります。データテーブルの作り方がデータ思考でやっているとちょっと違いますね。

テーブルがミンコフスキー空間[アインシュタインによる特殊相対性理論を定式化する枠組みとして用いられる数学的な設定]で、それを相対論化したということでしょうか。

そうですね。

トレーサビリティの話に戻りますが、何がBSCにもとづくゴールに寄与するかを考えたときに、結局、モデリングで捉えたものに対しての操作しかできなくて、それが本当にゴールに近づいているかどうかは分からない。システムの運用管理で性能を監視していると、ある部門のパフォーマンスが落ちている、たとえばITの問題が起きているというのはそこで見れます。でも、BPM[Business Process Management(ビジネスプロセス管理)。経営目標を実現させるビジネスプロセスを設計し、その改善サイクルを継続的に進める経営手法]のレベルで足りない人員を追加したらパフォーマンスが上がるとか、実はもっと別のレイヤーがあるなどの可能性まではモデリングできていない。その見つけ方が難しい。マイニングの世界のおむつとビール[データマイニングでバスケット分析をして見いだされた有名な『おむつを買う人はビールを同時に買う傾向が強い』という分析結果のこと]みたいな話もどうしても残ってしまう。そういう未知のモデリングのレイヤーを見つけ出すプロセスには、どうしても人の「ひらめき」のような領域が残ってしまう気がしているんですが、それをどうやってこの議論に持ち込むかというところに興味があります。

そうですね。それはまだこれからです。ドメインの中に入っていかないと分からないこともありますし、ちょっとモデルを作っていじると何でも解決するとはいえない。人の比重についても、講演でアルゴリズム的思考を紹介したときに、システムを作る側が持っていた機能を外に出していきましたね。最後に問題として設定するところだけが残って後は外に出たんですけども、それは開発者がやらなきゃいけないことを外に出しただけか、というとむしろそうではなくて、人間がやるべきことはむしろ増えている。そういうことが同じように言えるのかと思います。そこはまだまだ経験が必要ですね。

講演の中で、ユーザーの領域とベンダーの領域があって、ベンダーが左のユーザーの領域に寄って行くような話をされていました。アジャイルではお客さんと一緒に分析していこうと言いますが、もっとベンダー主導になると言っているのか、昨今のIPA[独立行政法人 情報処理推進機構: Information-technology Promotion Agency]のようにユーザー主導と言っているのか、どちらでしょうか。

図1 実行可能な知識 (講演資料9枚目スライド)

どっちが主導ということはないと思うんです。両方がお互いの中に入っていかなければいけない。ユーザー主導でもベンダー主導でもないと思います。

ベンダーがもっとユーザー側に入れということですか。

たとえば、モデルをユーザーがいじれればいいということです。システムパフォーマンスまで気にする必要はないんだろうけど、自分たちがビジネスの課題として考えていることがモデルとして明確化されたときに、それを操作できればもっと嬉しいかもしれないという意味でのユーザーからの歩み寄りです。

ベンダーのモデルをユーザーが触れるようにするということですか。

たとえば、そういうことです。モデルを見ることでアーキテクチャの選択権がある程度ユーザーにも出てくる可能性があります。

セミナーの中でモデラーの仕事は質の高い知識をモデリングすることだという部分が印象に残っています。私は、いわゆるオブジェクト指向には、プログラムを人間の思考的に整理しましょうという考え方と、問題領域の概念をソフトウェアで表現しましょうという考え方の2つがあると認識しています。面白いのは後者だと思いますし、今日の山田さんのお話は正にこの内容だったと思っています。実際にこれを実現する手段の１つとしては、たとえばJavaであれば、ファウラーのエンタープライズアプリケーションアーキテクチャパターンのドメインモデルパターンを適用して、問題領域のモデルを実装に落とし込む方法があるかと思います。でも、私が関わってきた大規模システムだと、人数が多くて役割分担が難しかったりして、このパターンがマッチしないということもありました。それで、問題領域のモデリングを半分あきらめてしまっているのではないかと感じることもあったのですが、今日の山田さんのお話で元気付けられました。今後も、こうした問題領域のモデリングを追求していくべきという認識でいいでしょうか。それから、山城さんのSecond Lifeのお話もそうかもしれないのですが、問題領域のモデルをソフトウェアに取り込むための場のパラダイムシフトが起こってきている、そういうことが起これば実現できると思っていいでしょうか。

できると思ってください。そういう人を1人でも増やしたいと思っています。
実際のエンタープライズアプリケーションを作るときに、ファウラー的というか、非常に抽象度の高いパターンを作りこんでいくと、なかなか下まで下りてこずに分けられないというのは確かにあります。長い間やっていっても、動くものが自分たちにもお客さんにもなかなか見えてこない。抽象度の高いものが地下水として隠れちゃう期間がとても長くなって、それがモチベーションやプロセスにつながらない気がします。だから、抽象度の高いモデルを完全に作りこまなくても、非常に短いスパンで動かしてお客さんにユーザーインターフェースとして見せるとか、自分たちとしてこういうデータを与えればこう動くというのを見ながらやっていくとかすると、比較的やりやすいと経験上思っています。紙芝居的なものでもいいので、できるだけその時点で動く仕組みを作ると、ちょっとフィードバックがかかって、前にドライブできる気がします。

では、ワークショップ本来の目的に移りたいと思います。そもそもこのワークショップは、モデリング技術を体系化するための軸足やフレームワークをまとめることを目的としています。そのためにいろいろなことをお聞きしてヒントを得られればと思っています。
まず、モデリングとはどういうものか、そもそも山田さんがモデリングに興味を持ったきっかけは何か、現状をどう思っていて目的は何なのか、現状のモデリングの問題点は何か、そのあたりをお聞かせください。

まず、『モデリングにめざめたきっかけ』ですね。Smalltalkの話を何度かしましたが、これはおもちゃでしか使ったことがありません。仕事としてちゃんとモノを作るのに最初に大規模のオブジェクト指向で使ったのは、NeXTSTEPです。NeXTSTEPは基本的に実装ドメインのオブジェクトなんですが、それでビジネスのシステムを作っているうちに、オブジェクトでビジネスの領域も表せると思ったんです。実装オブジェクトでなくて問題オブジェクトを使って動かしていけば、それでシステムがかなりできる、と思ったのが最初です。そういうレベルのオブジェクトの絵を描いて、クライアントにプレゼンテーションしたり、それをもとに設計したりしていました。僕は動く方に興味があったので、OMTはあまり信用していなかったんですが、そのうちにUMLの0.8がRationalから出てきて、これで自分の思っていることが書けるな、と思いました。それをモデリングといっていいのか分からないですけど。そういう意味では、最初から「動かす」「動く」ということがモデルに対する前提条件だったんです。
その後、UMLのツールを作るというIPAのプロジェクトに参加しました。オープンソースのArgoUMLにいろんな機能を付け加えて、日本語にするというものだったんですが、僕がやったのは状態遷移図を動かす部分です。動かない状態遷移図の意味が僕にはよく分からないので、動かそうと思い、状態遷移図のデバッガという形でシミュレーションを動かしていました。そういう意味で、僕の考えるモデルは、基本は「動く」こと、そしてそれが何かの知識のようなものを表すということですね。それがソフトウェアのモデルだと考えています。
『モデリングの目的』は、動かすことですね。ソフトウェアと一緒です。プログラムを書くのと一緒。プログラムにはいやなことも一杯書くけれども、モデルはかっこよく書けてそのまま動いてほしい。それをモデルと言っていいかは僕にはよく分かりませんが。
『現状のモデリング技術の問題点』は、やんちゃな立場からいうと、モデリング技術がある意味成熟して固定化しちゃっていることですね。若い人でも「モデルなんてこうやって書けばいいんでしょ」みたいなのができています。それはUMTPの活動などのおかげでもあるんでしょうけれども、つまらないところでもあります。

今のモデリング技術が成熟して定型化しているというのはどんな印象なんですか? 私はまだまだ広がっていないような印象を持っているんですが。

若い人は、そこそこでおとなしいモデルを書きますよね。少なくとも、UMLで書けることは限られています。UMLで僕が不足なのは、クラスレベルのモデリングが中心だということです。クラスとインスタンスの関係とか、メタで何が起きるかを書きたくなるんですが、UMLではそれが書きにくい。書きたいのにUMLで書けないと僕は思うんですが、若い人たちにそういう不満点がなさそうなのが不満です。UMLってこんなもんでしょ、と見切って書いている。「こんなのも書きたい」というのがないのかなぁと思いますね。モデルってもっといろんなことがかけるじゃないですか。UMLで決められて、教科書どおりにモデリングするだけじゃもったいないと思います。

モデリングと定義するかどうかは別として、範囲がもっと広いという印象を受けました。UMLで書くものは当然モデルなんですが、UMLだけでは表現し切れていないということですか。

そうですね。多様性というか、モデリングの概念自身が拡張されてもいいかと思います。だた、共通言語として存在するのは素晴らしいことだと思うんですが。

動くモデルを前提とするとそう思うでしょうね。

吉田さん、UML2.0のクラスとインスタンスレベルの表現、データレベルの表現は書けないですか?

インスタンスをうまく書く方法はそんなに整備されていないと思います。M0からM3まで4つレイヤーがあって、M1の中のことを書くのはいいのですが、M1とM2の関係を書くのが何となくぎこちない。今日のお話で、モデルもソフトウェアだというキーワードがありましたが、まさにそういうことを書きたいんですよね? メタなデータもソフトウェアに取り込みたい、自己記述性やリフレクションのようなソフトウェアの性質をもっと有効に使えれば、もっと楽に柔軟なアプリケーションができるんじゃないの、という風に私は受け取ったんですが。

はい、そうですね。

そういう意味では今のUMLがうまくできているかいうと、厳しいですね。

OMGでUML2.0の仕様が議論されているときに、イギリスの大学のグループがメタなモデルを提案していましたね。あれがうまくいけば面白いなと思ったんですが、結局は保守的な2.0になって残念でした。

モデリングの原理、原則、パターンはどう考えていらっしゃいますか。

原理・原則といっていいのか分かりませんが、パターンのようなものは使いますし、作ることもあります。モデリングに限らず、何かモノを考えて形にする作業をしていれば必ずあると思います。モデリングでは、他の領域に比べるとそこそこ蓄積され利用さていると思います。

セミナーの中で建築の「問・法・可・評」がでてきましたが、「法」ですね。

そうです。ルールですよね。建築家の松川さんという人が言うアルゴリズム的思考では、そのルールがアルゴリズムとして決められるんじゃないか、と言っているんです。要求があったときに、その要求を満たす建物のパターンを計算によって何種類か提示できるんじゃないかと。それが本当なら素晴らしいですよね。我々はどうでしょう。絶対できない!と思うような気がするんです。お客さんの要求があったときに、計算によってアーキテクチャを提案できます、って言いづらいですよね。できれば素晴らしいですが、少なくとも計算ではできないような気がします。

物理的なルールがないですからね。重力や風といった制約は分かっていても、ビジネスモデルはその辺がお客さんごとに違うから、逆に我々がお客さんのところに入っていって勉強しないと、そのルールは分からないと思います。

そう思いますよね。彼らはアルゴリズミックだと言っているんだけど、実際には建築家のテイストがすごく入ったものが出てくるらしいです。そのあたりが面白いですね。

モデリングも、UMLのクラス図にしても個性は出ると思います。たとえば関連クラスを使うか使わないかというクセがあったりして。それは流派というんでしょうか。

コードでもものを考えるときでもそうですよね。若いときにファウラーのアナリシスパターンなどに馴染んでいる人がいたら、そんなモデルを書いているかもしれないですし。
問題なのは、評価する基準がないことです。建築だと、ある程度はいい建物悪い建物の基準がある。少なくとも雨漏りしちゃまずいなどの評価ができます。モデルやソフトウェアの評価軸が必要なのかもしれません。いろんなものを見る経験が必要なのですが、建物と違って、ソフトウェアを見る機会はほとんどありませんね。パッケージソフトが、たとえばVistaがよくないとかは分かりやすいですけど、カスタムなソフトウェアは、そもそも見る機会すらありません。ユーザーインターフェースの評価はできるかもしれないけれど、コードや、特にアーキテクチャの評価は難しい。でもその評価はどこかでしないと、この先がないような気もしますし。

建築だと、北京のオリンピック会場とか、とても個性が出ますね。でもソフトウェアで個性を出すべきなんでしょうか。誰が作っても安全でパフォーマンスが出る方がいいのか、これは誰が設計したソフトウェアというように個性が出てきて面白ければいいのか、評価は難しい。建築にしたって、たとえばアレグザンダーだと、ガラスと鉄のはだめだとか、もっと活き活きしていないとだめだとか、いろんな評価ポイントがあって、そういう品質特性になると非常に評価は難しくなってくると思います。

そうですね。分からないですね。

建築の場合は個性が価値になるけれど、ソフトウェアの場合はならないんじゃないでしょうか。

コンシューマー向けだと、たとえばMacなんかは信奉者がいますよね。機能面では測れないんですけど、デザインに力を入れているところに着目しているユーザーも多いんじゃないかと思います。

ある面に触れる人にとって使いやすいかどうかが評価になるんじゃないでしょうか。建物は、見たり住んだりする人にとって使いやすいかどうかなんですが、ソフトウェアの中身に接する人とはメンテする人ですね。すると、メンテしやすいというのが1つの評価になるんじゃないか。普通に使っているユーザーはGUIなど自分が使っている部分で評価するのであって、作りは別に関係ない。作りについてはメンテをする人にとってやりやすいというのが1つの評価かもしれません。

ある時点のスナップショットについては、機能に対するテストセットを満たしているかどうかで評価できるとと思うんですけど、将来まで考えるとアーキテクチャの評価が必要ですね。保守性や、拡張性、柔軟性などは、今のスナップショットを見ただけでは分かりにくい。外のインターフェースを見るだけではなく、作りやモデリングの成果を評価しなければいけませんね。関連オブジェクトを使うかどうかというレベルで、いくつかパターンがある気はするんですけど。

さっきの話ですが、アーキテクチャはどう考えていますか? ドメイン中心に考えていられるようですが、その中でアーキテクチャはどのような位置付けになるんでしょうか。

アーキテクチャは、異なるドメインの間のマッピング言語だと思うんです。ソフトウェアのアーキテクチャは、建築のアーキテクチャとは違う。1つのドメインだけから成っているならアーキテクチャはあり得ない。問題ドメインと解決ドメインなど、複数のドメインが接するところのマッピング関数がアーキテクチャだと思っています。そういう意味では、エンタープライズアーキテクチャのザックマンフレームワークは、アーキテクチャのマッピングを表にした分かりやすいものだと思います。

要求と分析と設計のそれぞれについて、どう捉えるべきか、どういう考え方で何をやるものなのかをお聞かせください。

今日の話を引きずっていうと、乱暴かもしれませんが、要求のモデリングはないのかもしれない、と思います。

要求の手前があるということですか?

そうですね。むちゃくちゃだというのを意識しながら言うと、「そのままのモデリング」ですね。現場、リアルワールドのモデルがあって、それが動きます。ビジネスプロセスや、クライアントが扱っているマテリアルや、組織などがあって、それがモデルになって計算機の中のちっちゃい人として動きます。その動き、動いているシステムから逆に要求が出てくる。「こういうものが欲しかったんだ」というのが見えてくる。出発点として大雑把な要求があってもいいんですけど、そこから動くシステムができて、そのシステムを使っていくところから本当の要求が見えてくる、という流れです。普通は要求があってそれを実現するという方向性なんだけど、逆に、動いているものを見てどういうものが欲しいかが見えてくるようなシステムがいいシステムだと思います。お客さん相手には、普通の要求のモデリングをしますけどね。ただ、動いているシステムが要求をaffordするところは重要で、そこから改修を重ねたり、システムが成長、進化したりする。ソフトウェアをもらってもお客さんはなかなか満足しないですよね。逆に「こういうことがしたい」が見えるシステムはいいのじゃないでしょうか。

セミナーでもフィードバックということをおっしゃっていましたが、まず実装ありきで、それに対するフィードバックということですか?

実装ありきと言われると実装バカみたいだけど、確かに「動く」ということが僕の根っこにあるような気はします。

パッケージソフトやERP[Enterprise Resource Planning(企業資源計画)。企業内の経営資源の有効活用の観点から統合的に管理し、効率的な経営を図る手法・概念]はどうですか? リアルワールドのモデルがあって、それに対する差分を追加したりカスタマイズするイメージなんですが、それとの違いは?

ERPは、それを作っている人のモデルであって、本当のリアルワールドのモデルになっていない気がします。僕はパッケージではなくカスタムで作ることが多いからかもしれませんが、お客さんにパッケージの提案はしにくいですね。パッケージでは、現場といっても、どこにもない現場のモデルだったりするわけですね。それの差分でうまく行けばいいんですけど、そんなにうまく行かないケースも見ているから、それなら本当のモデルを作ればいいじゃないか、と思うわけです。機能の積み重ねじゃなくモデルの集合としてできているERPがあって、モデルをいじればちゃんとカスタムされたシステムが出てくるものがあればいいんですが。

分析と設計の区別はどうですか?

「問、法、可、評」[講師がソフトウェアの作り方のアナロジーとしてセミナーの中で取り上げた、現代建築に対する論考で紹介されている考え方。「問」は問題/課題設定、「法」は法則/ルール作り、「可」は可能性の列挙、「評」は(多くの可能性の)評価と絞込み、のこと]の可と評のところですね。選択肢をどれだけ挙げられるか、どこまで見せずにすむかが分析で、そこから1つを選択していくのが設計のモデルかな、と思います。

では、パターンはその前にありきなんですか? 選択の1つの汎用的な例として。

そうです。

では、パターンは上流にあるものと捉えているのでしょうか。

早い時期のパターンは重要です。

要求でユースケースは書かないんですか?

書きますよ。どうして?

様相指向というか、山田式のテクスチャオリエンテッドみたいな開発プロセスがもしかしてあるのかな、と思いまして。

やらせてくれるならやりたいですね。でも、なかなかそういうお客さんはいないので、ユースケースは普通に書くことが多いです、普通の仕事ですから。

分析のモデルから設計のモデルへ移行していくときに失われるものがもったいないという話がありましたが、分析と設計が渾然としたモデルみたいなものがソフトウェアに残るイメージですか? あるいは、はっきり分かれていて、トレースのリンクがはってあるだけなのでしょうか。

どこかで情報が消えるというか押しつぶされるのはしょうがないですよね。そうでないと動かないので。ただ、どこを押しつぶしたかを分かっていたい。そういう意味では、トレースできればいいだけなのかもしれません。それさえできれば分けたいです。いつのまにか消えちゃうのは嬉しくないですね。

では、次に移ります。UML2についてはどんな感想をお持ちですか?

こういう言語があるということは、ありがたいのは確かです。これがなかったら、僕がしたいことをお客さんや実装チームに伝えるのが非常に難しくなります。でも、これで十分かと言われると、そうではなくて、足りないところもあればややこしいところもあると思います。

特にUML2.0になってよかった点、悪かった点は何かありますか。

2.0になる過程でいろんな提案が出ていたんだけど、その中であまり好みじゃないものが2.0になっていったので、仕事でモデリングをするときも2.0のfeatureをがんがん入れたモデルを書くことはないですね。2.0自体も知らないところはいっぱいあるし、2.0になってからのメタモデルも頭に入っていなくて。前はそれなりに分かっていたんですけど。

では、OCLや形式手法についてはどういうスタンスですか?

実際の仕事でOCLを部分的に書いたりはしますが、全部書いても嬉しいことはあまりないですね。OCL自身がいい悪いというより、OCLを書くだけで終わるなら面白くないということです。
形式言語については、すべてを代数的な形式言語で書くのはありえないですね。モデルを書いている中で、一部分をフォーマルに書いて、一部分の何かの性質を証明できるといいなとは思います。それが具体的に何なのかというと、たとえばOCLではモデルの1本の関連が満たすべき制約は書けるけど、その先あまり嬉しいことはないですね。論理的に言えばVDM[Vienna Development Method。IBMのウィーン研究所で1960年代から70年代にかけて開発された形式手法]と等価だったりするのかもしれないですけど、ちょっと分からないです。今一番現実的な希望は、半分くらい形式的に書けることです。その意味でGrailsというフレームワークは、形式手法とは全然いえませんが、少し形式的で、わりと宣言的にいろんなことを書けるし、DSLを内側で定義すると書きたいことを書けるところがおもしろいですね。

DSLを考えると、お客さんのリアルワールドに対応するモデルとして適当かどうかを誰が判断するかが問われるんじゃないかと思うのですか。

UMLでいうメタモデルを考える人ということですか。それをすべてのモデラーに要求するのは酷ですね。建築では、マスターパターンを考える人は限られます。ガラスとコンクリートと鉄筋でできた建物というマスターパターンを考えた人はたぶん1人とか少人数で、今ゼネコンで線を引いている人はそのパターンをなぞっているわけです。そのマスターパターンとメタとが同じものかどうかは議論が必要ですが、それを考える人は何人かいればいい。オープンにしてみんなで議論して使いあっていけばいいのだろうと思います。パターンのコミュニティの考え方ですね。

ファウラーみたいな感じですね。

メタモデルはプロジェクトごとにいくつも考えなきゃならないものではないですよね。1つ2つ新しいものを追加することはあっても、たいてい手持ちのメタモデルで用は足りるでしょう。

でも、DSLのベンダーの話を聞くと、いろんなタイプのモデルを見せられるんです。Software Factoriesもそうですが、ニーズに合ったモデルを作れるところを売りにしてくるので、そういうものなのかというイメージがあります。

彼らはそれが飯の種ですからね。でもそんなに多くのメタモデルは必要でない気がします。

今は過渡期であって、「こんなドメインにはこの知識体系でこの記述スタイルがいい」というのがパターンと同じようなレベルで整備されていくといいのではないでしょうか。

UMLでいうと、プロファイルとかスーパースーパーストラクチャのような感じでしょうか。

UMLでならプロファイルだと思います。

では、MDA、SOA、EAはどうですか?

MDAはよく分かりません。OMGのビジネスの話かなと思っています。モデルから動くものができるのは嬉しいんですが、MDAにはあまりに余計なものがついていて、よく分かりません。
SOAは、基本的に分散オブジェクトのアーキテクチャだと思っています。分散オブジェクトといっても、昔みたいに単なるRPC[リモートプロシージャコール]ではうまくいかないのは確かで、それに対していろんなパターンの蓄積をしているのがSOAですね。その標準化についてはそんなに真剣に追いかけなくてもいいと思っています。ただ、布と布とをどう繋ぐという話になってくるとしたら、そこは自動でやるだけじゃなくて、人間がアーキテクチャを積み重ねていかなくちゃいけないところだと思います。
EAはビジネスモデリングみたいなものだというのは、今日の前半でお話したとおりですが、マッピングのガイドとしては悪くないですね。マッピングはUMLなどの図ではできないところなので、どうしても一段上に上がっていかないといけません。

その他、Web2.0など今注目している新しい技術はありますか?

前半にも話をしたんですが、モデルのコンテンツを作るのはモデラーやソフトウェア屋さんだけの仕事じゃなくなってきます。ユーザーにモデルのコンテンツを作ってもらうことがこれからのITだと考えると、Web2.0に近い感覚だと思います。言われたことをソフトウェア屋さんが短い時間に作りこんで、そのあと変えようとするといちいちお金がかかるというソフトウェアのビジネスモデルは、もうなくさなきゃいけないと思います。

それを実現するためにクリアするべきことはありますか。技術的には揃っていて後は啓発活動をすればいいのか、それともまだ技術的課題があるのか、どうでしょう?

大きいのは波ですね。みんながその気になるかどうかが1つです。もう1つ、技術的には、実現するためのパターンが足りないと思います。カジュアルなWebサービスでは少しずつ蓄積されているけれども、それをすべてエンタープライズにそのまま持ってくることはできない。そこをもっと蓄積しないといけません。要素技術としては7〜8割方あるように思います。

モデルを作るというのは特殊能力で、一般のユーザーにはそれができる人とできない人がいますね。

そうですね。モデルを作ると言うときには2種類あって、モデルそのものを作る人と、もう1つはモデルのコンテンツを入れていく人が必要です。普通の業務システムで発注などがあるたびに中身を作っていく部分を、モデルとして作るんですが、実際にユーザーがどう分担してどういうインターフェースでやらせれば自然にできるかは、もちろん考えなければならない。

知識を学習させるような機能を持たせるということですか?

それをシステムがやるかどうかは分からないですね。

少なくともそういうユーザーインターフェースは持つわけですね。

はい。その面では、カジュアルなWebサービスがやっていることは参考になりますね。

モデルのコンテンツというのは、モデルではなく、モデルを適用した結果のインスタンスのことですね。では、ユーザーはそこを作るけれど、ベンダーはそれを抽象化したモデル自体を作るということですか?

いえ、ユーザー自身もモデルを作る、少なくとも変えたりはしないといけませんね。

ユーザーにも何階層かあるということですね。

では、モデリングに必要な素養や素質はどうでしょう。それを高めるためにはどんな教育が必要ですか?

よくモデリングには抽象化する能力が必要だと言いますね。それは必要だし、モデルというと今は抽象モデルが中心になっているんですが、インスタンスモデルもあると思うんです。具体的なものの集まりもモデルと言っていいと思うんです。そういう意味で、上に上がっていく抽象化能力がある人も必要だけど、そうでない人も必要で、インスタンスをいっぱい考えられる人がいるといいですね。
中学高校でモテない男の子たちが科学部みたいなのを作って、くだらないことを言い合っているじゃないですか。女の子がまったく理解できないようなネタで。そういう変な面白さです。ちょっとしたことをすごく一般化して、変に考えて面白がる能力があるといいですね。抽象化の能力の高い人だけいると、しんどいような気がします。

専門能力以外の発想ですか。

そうです。それも高尚な方にいくのではなく、くだらない方にいく発想力があるといい。それをたたいて伸ばして結晶させる人も必要なんでしょうけど、はずれたことを言う人や全然分かっていない人の一言から面白いモデルができたりすることがありますね。

モデリングの講義の後で大学生と話をしていると、意外な意見が出てきたりして、こちらが考え込んでしまうときがありますね。今までの固定観念からはずれていくような刺激やきっかけが大事ですね。

社会人になると失われてしまうんですね。

アナロジーや比喩を使って別のドメインで考える能力も大事ですね。今日の講演でも、建築との比喩にはっとしました。

比喩の力や物語を作る力ですね。スタティックにものを考えるモデリングだけではなく、シナリオベースのモデリングも重要です。そうじゃないといろんなところを落としてしまうので。もう1つは、きれいに視覚化する力です。コンサルタントがよくやるようにマトリクスにするとかだけでなく、アーティスティックにきれいな絵を書ける力がほしい。ある人が作っているモデリングツールを見せてもらったんですが、Flashベースなんです。次にやることがヒュインヒュインと出てきてシュワっと広がる。そんな風にビジュアルに楽しいモデルが作れるといいなと思います。ただ四角を描いて線で結んでも、僕たちはそこにすごいものを見ているんだけど、他の人からするとよく分からないわけですよね。

一般の人にモデリングさせる環境を整備するのは重要かもしれないですね。

若い人はビジュアルなものを操作する能力を小さい頃から培ってきていると思うんです。彼らにはそういうツールがフィットすると思います。そして、ビジュアルにかっこいいけど、裏にちゃんとロジカルな構造と対応が取れているといい。

それを総合すると漫画を描く能力かと思うんですが。

そこで前回の児玉さんにつながるわけですね。漫画家を目指していたそうですから。

全部を1人の人が持っている必要はないんですけど、いろんな人がいるといい。

教育よりも、いろんな人が集まる環境があると、結果的に成功につながるということですね。

そう思うと、教育にもはやたいした意味はないのかもしれません。

面白い、いい場をたくさん提供してあげることは大事ですね。

モデリング技術を体系化するときにどのような軸やフレームワークが考えられるでしょうか。アイデアやヒントなどあればいただけますか。

Body of Knowledgeを作ることを念頭に置いているわけですね。

「動く」ですか?

それは1つですね。少なくとも、書いたモデルが検証できるか、動かせるか、応用できるかを評価できるような何か、つまり作ったものを使う部分が体系に入っていると嬉しいですね。

UMTPの活動や認定試験について意見や感想をお願いします。

モデリング技術プラス駄じゃれを入れる能力を認定試験の一部にしてください。

タダにしたら受けられますか?(笑)

落ちると恥ずかしいので偽名で…(笑) 昔ブロンズは受けましたけど、勉強するのもいやだし。

たぶん勉強しない方がいいです。

L3は勉強ではなく実際にやっている人が受かる傾向がありますね。L2はそうとも言えませんが。

自動車の免許で言うと筆記試験ですよね。路上みたいな試験はないんですか? 実際にモデルを書かせるみたいな。

L3の上はそうせざるを得ませんね。

L3も単なる筆記試験ではありませんよね。

仮免試験みたいな感じです。

空のクラス図のネットワークのフレームみたいなものに自分でクラスを入れていくんです。

モデリングツールでモデリングしているような感じではありますね。

運転で言うと、自分は右に曲がりたいんだけど左に曲がれという指示が出る。でも、できる人はそこでアクセルとかシフトの操作をして左に曲がれるんです。

標識が多重度などとして付いているんです。それをちゃんと守れるかという力を問われる。

ですから、決して知識を聞く問題ではありません。

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

講演でもお話しましたが、中心的なところにあって、ソフトウェア開発のほとんどを占めるようになると思います。そのときにはやはり、メタモデルを作る人と、決められたメタモデルの中でモデルを作る人の2つに分かれると思います。そして、プログラムもモデルに近づいてきて、仕様をプログラムとして書くわけですが、それを動かす仕組みを作る人が必要になります。モデルの位置付けは大きくなるけれど、メタモデルを作る人と、モデルを作る人と、モデルを動かす仕組みを作る人がいれば十分じゃないかと思います。つまり、モデルが中心ですね。

モデルを動かす仕組みというのは汎用的な仕組みなんですか? それとも、モデルごとに作るんですか?

かなりの部分は汎用的な仕組みでいけますが、ドメインごとにモデルは作らないといけないですね。メタモデルが変われば動く仕組みも変わってくるので。

ユーザーがモデルコンテンツを作る方向に向かうなら、我々メーカーの人間は動かす仕組み作りでお金を貰わざるを得ないということでしょうか?

そうですね。それと、ユーザーだけにモデル作りを任せるわけにはいかないので、システムの開発時期だけでなく、ユーザーと一緒にずっとモデルを育てていくようなビジネスも出てくるんじゃないかと思います。

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

今はモデルをどうやって作ればいいかの教科書がいっぱいありますが、教科書にない面白いモデルを書いてほしいですね。もう1つ、モデリングの未来は面白いという話を今日したのですが、それを信じて突き進んでほしいです。

最後にお薦めの本を教えてください。

今日の講演で紹介した本を読んでほしいです。『アナリシスパターン』もいいですし、友野さんの訳された『認知パターン』がすごく面白いですね。問題解決のプロセスをモデル化している本です。それから、クリス・マーシャルの『企業情報システムの一般モデル』、これはアナパタなどのフェーズのものです。それから『物の形をした知識』は、モデルを書く人には是非読んでもらいたい。物理世界でのモデルという点が面白いです。

今日はどうもありがとうございました。