ワークショップの趣旨と講師の自己紹介羽生田 今日は講演をありがとうございました。今回は前半が講演で後半がワークショップという構成になっています。こういう構成にした趣旨について、部会長の山城さんから説明をお願いします。
山城 今日はどうもありがとうございました。
UMTPモデリング技術部会でモデリング技術の調査研究/体系化をやろうということになりました。今日は、実はこれからのワークショップがメインです。ただ、せっかくワークショップをやるなら、前半にその道の専門家の方に一般向きの講演をしてもらって、その後にワークショップをできると嬉しいということで、こういう形でお願いしました。今のところ、部会として、3ヶ月に1回、このような講演会/ワークショップを開く予定です。2年計画のうち最初の1年間は、児玉さんのようなモデリングやオブジェクト指向の有識者を招いて広く議論したいと思っています。今年度はあと3人に来ていただき、いろいろ議論した後で、どのトピックに絞って議論を深めればいいかをこの部会で考えて、来年度は特定の技術をベースに議論できればと考えています。今回は1回目ということで、オブジェクト指向全体の本質について見られている児玉さんに来ていただきました。座長は羽生田さんです。たくさんの質問を用意しているのですが、最終的なゴールは「モデリング技術を体系化するとしたときにどのような軸やフレームワークが考えられるか」です。よろしくお願いします。 羽生田 では、早速、講師の自己紹介と、今日の講演のテーマ、隠れたメッセージを数分で説明していただいて、その後で講演全体の質疑に入りたいと思います。
児玉 エクサの児玉です。先ほども紹介してもらったように、今までになかったような生産管理システムを考えて売って歩いている立場です。その中で、いろいろな分析パターンを実際に適用してきたわけですが、ほとんど、ファウラー（「アナリシスパターン」を書いたマーチン・ファウラーのこと）様様みたいな感じがあります。つまり、ものづくりは勘定パターンなんです。あるものをあるものに変えているだけで、マテリアルバランスが壊れると困るわけですね。ところが、お金をモノに変えただけでも相当違う。『UMLモデリング入門』にも書いていますけど、1個というindividualがindividualでないという話をしたことがありますが、「もの」は切って使える。ですから、ロット生産も個別生産も本質は変わらない、変わらないモデルを書いています。実際は、個品とロット、それらをまとめた数量単位という考え方をするんですが、今日も話したように、モデリングではぐるりんこと[再帰関連の線を]書けばおしまいなんだけど、実際には階層を固定せざるを得ない。1個1個のものと、ロットのものと、stock keeping unit(SKU)や在庫単位とかに切らざるを得ない。そういう現実的な割り切り方、製品特性によるものがとても面白いと思っていて、実際にモデルが商品になっていくのが楽しいです。最近は、私自身が実際に売り歩くことは少なくなっています。製品はマーケットにおいて進化しなければなりませんが、その軸になるのがモデルであり、そのためにこそモデルを進化させたいと思っています。
今日のメッセージですが、「悩んでいます」「結論は出ていない」「一緒に考えてください」というものだったつもりです。システム階層についても、単に階層に分ければいいというのではなく、その中にも本質の階層と便宜上の階層がありそうだ、というあたりを議論したい。属性の外出しは、分かっていないとだめだけど、逆に取り込みの判断基準をどこかで議論しないといけない、その時に正規化の理論は捨ててはおけない、というところ。ユースケースの位置付けも、おざなりにしすぎた。ちゃんとやり直さないと、いくら静的モデルを書いたところで、意味がないんじゃないか、そういうメッセージです。 山城 モデリングやオブジェクト指向に踏み込むきっかけとなった本や人を教えてください。
児玉 僕は、心理学はモデルの学問だと思っています。学問はみんなモデルを書くものなんですが、心理学は対象が見えるものではないので、昔からモデルということばを使っていた。だから、モデリングに抵抗がなく、モデルは作らなければならないものだと思っていた。その中でも、人工知能研究では人間の思考のモデルなどを書いていくわけです。そこからデータのモデル、意味のモデルに重なっていったという感じがします。そのときに、モデリングの武器として使うものが必要である。心理学で使うモデルは単純なポンチ絵なんですが、ポンチ絵だけでは伝わらない。そこでER図のような図法があるんだな、と思ったわけです。これが1980年代の後半です。振り返ってみると、その頃はよく分かっていなかったんだけれども。その後、ファウラーのアナリシスパターンを読んで、それでシステム(SPBOM)を作り始めて、やっと意味が分かったという感じですね。
講演内容についての質疑羽生田 講演の中身について、コメントや質問をしてください。
水戸 今日の階層に分けるという話について、DFD[Data Flow Diagram(データフロー図)。情報システムのデータの流れをグラフィカルに表現する図]では勝手に分解されるけれども、もの・こと分析では適切に階層が決められるようだ、という理解でいいでしょうか。
児玉 もの・こと分析[仕事の対象を「もの」、手段を「こと」と捉え、シンプルなシステムを構想するために現物を可視化して分析する手法。『もの・こと分析で成功するシンプルな仕事の構想法』を参照]そのものは階層とは関係なくて、世界を切った後での仕事の定義ですね。階層はもっと別の話です。サルと原子という話をしましたが、原子の世界とサルの世界は別に書くべきだと思います。それが階層です。サルの世界を書くときにはもの・こと分析で仕事を定義してもいいけれど、原子からサルまでをもの・こと分析では書けないということです。
 図１ 意味論（講演資料 7 枚目スライド） 水戸 DFD的な発想でいくと、中間のものをまたブレークダウンしたくなるんですが。
児玉 僕はDFDは分解したから間違ったと思っています。そもそもシステム思考というのは、分解したらおしまい。中身を要素に分けるまではいいけど、そこからはだめ。特にオブジェクト指向では機能分解してはだめですよね。インターフェースは相互作用を定義するためのもの。システム思考を取り上げているのは機能分解してしまった誤りを繰り返したくないからです。機能分解ではなく相互作用を定義していけばよいと。もちろん、その時に適切なモジュールというのはあるので、どちらが先かという話はあります。でも、主要な関心事としては、相互作用をどこまできれいに定義できるかにかかっている。DFDを分解のツールとして使っちゃだめです。DFDはインターフェースをうまく定義できるようになっているので、分かっていて使う分にはいいんですが、だいたいは処理手順にしちゃっていますよね。
<児玉補記>もの・こと分析でいう「中間のもの」は、手順分解というよりは、手順の中でマイルストンを設定するものと考えると良いでしょう。
藤井 サルと原子の話で釈然としなかったのですが、モデルを書くときは目的があって作りますよね。でも、サルと原子はそもそも目的がない、そこが外れているんではないかと思いますが。
児玉 そうかもしれない。でも、意味があるモデルではないけど、書けてしまう。書けちゃうけど、書いたものに意味はないという話です。目的があればモデルになるのかと言えばそうではないですね。
藤井 目的に即しているのが大事ですね。
児玉 それが原因なのか結果なのかは分かりません。階層に切るのも何かの文脈があって切られているわけだし、文脈も何かの目的があって切られているのかもしれないから、目的が最初の原因だとは思わないですね。それこそアブダクション[ある個別の事象を最も適切に説明しうる仮説を導出する推論]で、世界（UoD：Universe of Discourseのことで、モデリングの対象世界のこと）があるところには目的があるし、意味があるということだと思います。
吉田 目的を意識することが大事だと私もよく説明しますが、目的は必要条件ですよね。目的さえあればいいわけじゃないけれど、はずしちゃえば意味がない。サルの何を理解しようとしているかによる。パズルを解くサルの行動をどう見るかという場合もあれば、サルの病気や遺伝の話をするなら遺伝子レベルで書かなきゃいけないこともある。原子のレベルで書くモデルが必要な「目的」もあるかもしれませんね。
児玉 目的を先にするとすごく難しいので、そこは飛ばしちゃったほうがいいかと思います。目的があるのはいいけれど、この目的だから世界をこう切ろうという議論は難しいですね。
ワークデザインという手法があります。もの・こと分析もワークデザインの一種だと思っていいんですが、目的展開をしようとしてもできないですね。もの・こと分析では、「終わりのもの」に品質要件を付与しますが、これは品質展開ならできるからだと思います。逆に、目的展開をやり始めたら全然うまくいかない。目的からスタートするのは危険ですね。結果論としてこの目的に落ち着く、というのはありそうだけれども。ただ、まだよく分かっていません。 山城 実際に業務システムの開発現場を考えると、体制/組織の構造がソフトウェアの構造にマッピングすることが多くあります。本来あるべき目的ではなく、手持ちの体制の制約でソフトウェアの構造が決まってしまう。よくないとは思うのだけれど、それ以外にどう作ればいいでしょうか。
児玉 もの・こと分析がそのブレークスルーにならないかと思っています。やってみると、「終わりのもの」をどれだけ定義できるかに収束するんですが、どうやってうまく目的のものを言えるか、ですね。たとえば社員食堂の場合、終わりのものとは何か? 「満腹した社員」だけなら、社員食堂でなくてもいい。「それほどお金が減らずに満腹になる」なのか。安けりゃいいのかというとそうじゃない。会社が食堂をやっているからには、社員の健康ややる気につながらないとだめなわけです。食事によって、満腹で健康でやる気のある社員を作ろうということになる。では「はじめのもの」は何か? やる気のない腹ペコの社員がいて、真ん中にどういう機能/変化を入れればいいかを考えることになる。一方で、実際に社員食堂の観察に行くと、人がたくさん並んでいて、動線が悪いとか重なるとか、どう改善するとかいう話になるわけです。組織内で何が現状困っているかの話になってしまう。でも、本来の「社員食堂の目的は何か」をでっち上げて、合意した上で進めるなら、もの・ことも捨てたもんじゃないと思うんです。
 図２ もの・こと分析（講演資料 15 枚目スライド） 吉田 もの・ことは、手段を横に置いて目的にフォーカスしようという考え方だと思うんです。それに対してユースケースが大事だと見直したとおっしゃっているのは、「やっぱり手段も」ということですか?
児玉 違います。ユースケースはもともと大事だったんですけど、考え違いで単なるアクターの活動に置き換えられて、アクターの活動の設計をユースケースでやっていたんです。ビジネスユースケースもそういう色合いが強い。そうじゃなくて、本来の仕事と機能は分けて設計すべきで、まず仕事を設計してからユースケースを考える。けれども、ユースケースが決まれば仕事のやり方が変わるわけです。だから、仕事の設計は後で捨ててもいいんです。最終的には機能の設計ができればいい。でも順番としては、仕事が設計されて機能が設計される、機能が設計されてから仕事が変わる、そういう順番でやった方が思考の順番としていい。ところが、できる人はいきなりユースケースを書き出すから、思考の足跡が残らない。残しておくことが大事だと思っているだけです。
 図３ ユースケースの意味（講演資料 14 枚目スライド） 羽生田 今までのモデリングの手順として、いきなりユースケース図を書くのではなく、その前にシステムの業務領域をアクティビティ図なりビジネスプロセスとして分析し、組織や人でパーティションを切っておいて、どこをシステム化するかを見極め、ビジネスプロセスを人手で残す部分とシステム化する部分に切り分けて、システムのレーンを追加しましょう、そことのインターフェースがユースケースとして浮かび上がってきますよね、という基本的な考え方がありましたね。そういう意味では、その路線とそれほどずれたことを言っているわけではないと。
児玉 そうです。ただ、もの・ことを軸にして仕事ということを積極的に打ち出そうと思っています。今まではあまりに仕事をほったらかしにして、手段ばかりを書いていた。その証拠に、学生にやらせると機能の箱ばかり書くんです。何々を登録すればいいとか。何を登録してどう使うかという議論ではなく、登録すれば仕事がうまくいくんだというんですね。でも、仕事をちゃんと設計しないで機能ばかり作って、うまくいく保証がどこにあるんだ、と。そこをステップを踏んでやっていくということを明確に打ち出したいですね。
DFDで思い出しましたが、As Isの物理→As Isの論理→To Beの論理→To Beの物理を書くというのは、非常にばかばかしい。現実をいくら正確に表したって、何の意味もない。でも、To Beを最初に持ってくるのも難しいから、もの・こと分析を持ってくる。改善じゃなくて改革の方に向かってモデリングしていきたいなぁと思います。 羽生田 仕事はそもそも何がしたいのという本質論から入りましょうということで、もの・こと分析なんですね。
児玉 データ分析の人などが、To Beを考えないでボトムアップでやっていることが多いですね。
照井 先ほどの階層に分けるという話と、DFDで機能分割しちゃだめ、分解するとシステムじゃなくなるという話など、いくつか分解や分割に関するお話がありましたが、たとえば Executable UMLだと、ドメインで分けて、それぞれをモデリングしていくという考え方がありますが、それに関してはいかがでしょうか。個々にモデルを分けてモデリングするのは有効ではないということですか。
児玉 有効ではない。全体で設計すべきだと思います。ただ、現実にソフトウェアを作るときは小さい単位で作るしかないですよね。executable UMLだとかMDA[Model Driven Archtecture(モデル駆動型アーキテクチャ)。モデルとして表現される構造的仕様のガイドラインを提供するソフトウェア開発手法]などの話はソフトウェアの世界の話なのでそれでやればいい。その根拠がユースケースなので、ユースケースまで行ってしまえば、あとは実装ベースで手が動くのではないでしょうか。もちろん、アーキテクチャは必要ですが。アーキテクチャの設計ができれば、後はバラバラで作れる。というか、そうしないと作れないと思います。頭の中でシステムを設計しているときは全体で考える、考え終わったらバラバラで作る。それができるアーキテクチャを用意するということです。
山城 モデリングは全体/システムでやり、作るのは個別にやるとして、個別に実装するためには、アプリケーションのフレームワークというかアーキテクチャがなくちゃいけません。そのアーキテクチャはモデルから派生して出てくるものなのか、それとも手持ちのミドルウェアやプラットフォームなどのように制約として与えるのか、どちらでしょうか。
児玉 両方だと思います。僕がやっている要求モデリングや概念モデリングというのは、あくまで要求側なんです。モデルは要求品質なんですよ。それに対して実際の製品特性を決めていかなきゃいけないですね。アーキテクチャと要求品質は分析の方向が違う。仕様の設計は、ある機能に対して要求品質をどう実現していくか、というマッピングの問題なんです。
山城 アーキテクチャは必ずしも要求ベースで出てくるものではないと。
児玉 そうです。アーキテクチャはアプリオリに持っていてもいいし、見て決めてもいい。ビジネスとしてやっていく場合、既にフレームワークを持っていなかったら、勝負にならない。もはやスクラッチで作るのは現実的でないですよね。
中原 As IsではなくTo Beに力を入れるのは、現状の把握や予算の枠というところにあまり時間をかけすぎるなということですか。
児玉 デマルコはAs Isに時間をかけろと言って失敗したんです。なので数年後にそれを訂正していますが、僕はやらなくていいくらいだと思っています。
中原 現状では、As Isからやっているプロジェクトが多いようです。
児玉 「世の中の問題には原因があって、原因を除去すれば解決する」と思っている人は、As Isでやってください。でも、システム思考ではそう思っていません。システムで考えたら「こいつが原因だ」というのはないですよね。大学院生にも教えているんですが、ビールゲームをやると、在庫がやたらと増えたりバックログが溜まったりと、自分ではどうしようもない状況になるわけですよ。それは誰かが悪いわけではない、システムが悪いんだよ、という話をします。
羽生田 MITのビールゲームというのは、システム理論でよく取り上げられる例題で、要素還元主義だと解決できませんね、というネタとしてよく出てくるものです。
藤井 みんなが大量に発注すると、バックオーダーが重なって最後にはひどいことになってしまう、という。
児玉 遅れて届いてしまうし、その反応も遅れて反映されるので、どんどん注文を出すと後からどーんと来ることになるんですが、そのうちそんなに需要がなくなって大変な在庫を抱えてしまう。システムの中にいると分からないんですが、自分が止めたくても止まらないという状態になる。それを体験させるゲームです。それで分かるんですが、問題はシステムの弱いところに現れるだけであって、原因がそこにあるからではない。問題を起こしている人は、実は原因ではなくて結果かもしれない。実際、心理学で言うシステムズアプローチというのは、一見違うところにアプローチします。As Isを徹底的に追求してここが悪いといっても、本当の解決にはならない。解決した気持ちになるかもしれないけれど、実は解決していない。だから、もの・ことの方がいいかと思います。As Isだけを見ると、食堂の話では、動線が悪いからこっちに並べば、といった話に終始してしまうんです。
中原 現状プラスアルファの枠でしか考えられないので、別の世界に進んでしまったほうがいいのですか。
児玉 そうなんですが、一方で「改善なくして改革なし」ということばがありますね。これは、改善を積み重ねなければ改革ができないという意味ではなく、改善という組織学習ができるレベルにならないと、改革までいけないという意味だ、と最近思うようになりました。改善を積み重ねても改革にはならないけど、改善ができるという頭の構造にならない限り、改革のひらめきは出ないんです。ベイトソンの学習IIと学習IIIですけど。
羽生田 議論の枠組みの説明としてはきれいだけど、改善を経験しすぎると逆に改革にアブダクションできないのではありませんか。
児玉 そうでもないと思います。学習IIIにいきなりは行けませんよね。確かに成功体験から抜けられない人がいます。でもそれは刺激を与えていくしかないんじゃないかな。自動的にはIIからIIIにはならない。そこに刺激を与えていく。学習IIIを人格破壊的学習というんですけど、人格破壊的にやらなきゃだめだな、と。
河合 さっきの世界をどう捉えるかという話で、小さい世界で見ていると改善をしているけれども、階層を変わって1つ上に行くと改革になるんでしょうか。
児玉 その通りです。
<児玉補記>同じ階層内で解決策を探すのは改善で、階層を一つあげて問題そのものを見直すことができれば改革につながるということです。
河合 レベルといえば、さっきの講演資料11ページの図なんですが、レベル4と3は書けるけれども2は書けないというところをもう少し説明してもらえますか。
児玉 4と3のレベルのモデルは書けるんですよ。けれども、2の世界は何が対象なのかが全然分からないんです。
羽生田 それはドメイン知識がないから、ですか。
児玉 はい。それに、知識のある人と一緒にやっていても今は書ける気がしない。根本的に違うような気がする。論理の世界と電気信号の世界に境目があるような気がします。
羽生田 サルと原子ほどの差じゃないけれども何かがあるんだと。
児玉 そうです。
羽生田 もしかするとこのレベル2と3という分け方がおかしくて、真ん中にもっとあるんじゃないか。
児玉 かもしれない。
河合 担当者がモデリングを勉強すれば書けるんですか。
児玉 それも分からない。レベル2のモデルを書いている人はいるんですが、僕は全然納得できないんです。
藤井 結構飛躍しますよね。状態遷移モデルみたいなものを考えて、制御だけどうするかという状態。そうすると上ではエンティティなどを対象にしていて、ギャップがありますよね。ラダー図とかを書いたりして、その辺の発想が全然違うんですね。
児玉 はい、本質的な違いだと思いますけど、まだ分からない。
山城 分析と設計のギャップじゃないかなと思うんですけど。
児玉 そのことばについてはノーコメント(笑)
羽生田 レベル4と3がうまくつなげたというのはどうしてですか。4と3のインターフェースのモデルを書いたということですよね。
児玉 3と4は便宜上の階層だと思うんです。ぐるりんこの部分を分割統治するのに、管理スパンが一杯になったから階層を増やしただけ、という便宜上の階層なので、ここはつながるんです。でも、信号と仕事の世界のつなげ方が分からない。こいつは品目番号で何番なんですってやっているのと、単純に信号だけが上がったり下がったりしているのとを、どうつなげたらいいのか。たとえば原価の考え方だって、3から上は1個ごとに原価をくっつけているけれども、コントローラの世界は朝から晩までベタに流れているだけなので、どこまでが原価なのかが分からない。2のレベルのモデルを見ても全然納得できない。これはプログラムを書いているだけじゃないか、と思います。
照井 もの・ことからTo Beを起こす流れの方がいいんじゃないかとおっしゃっていましたが、業務を知らないモデラーの場合は、As Isをモデリングしないと、もの・ことが出てこないんじゃないかなと私は思います。そんなことはないですか。
児玉 前提知識は必要だけど、それがAs Isである必要はないと思います。As Isには余計な知識もついて来ますから、それを払い落とせるならいいですが。じゃあ、現実的にどうするかというと、「現状の仕事を教えてください」は必要だと思いますが、それは「教えてください」であって「モデリングしなさい」ではないと思うんですよね。
山城 実装まで考えると、レガシーを一部残さなきゃならないとか、データベースの構造を変えちゃいけないという制約がありますよね。
児玉 現実との接点はあると思いますが、結局もの・こと分析でやってもSSM[Soft Systems Methodology：対象をソフトなシステムと見て問題状況を述べるための方法論]でやっても、現実との差を見てどんな手を打つかという話になるわけです。もの・ことで考えたことをそのままやろうなんて大それたことは思っていません。「あるべき」を出してくるだけであって、ギャップを埋めるための対策を打つわけです。
山城 実装のためには現状の構造も把握する。ただ、いきなりAs Is物理/As Is論理に行くのではなくて、もの・ことをやってTo Beを決めた後に必要なAs Isを理解する、ということですね。
児玉 そうです。だから余計なことをやらなくて済むんです。To Beを決めた後でAs Isを見れば差分が分かる。
羽生田 そろそろ講演の内容についての質疑から次の話へ移りたいんですが、質問をし忘れている方はいないですか。
藤井 ユースケース記述から静的なクラスに移るときの抽象化をどうやるか、クラスをどう識別していくかという部分は、どのように考えていますか。
児玉 私はユースケース記述の後で静的モデルを書くわけではありません。最初に辞書としてのモデルを書いてしまってから、ユースケースを書いて、また直していく。静的モデルは経験と勘で先に作ります。でないと、理解できないですね。たぶん仮説で作る。この業界はこうだろうなあという感じで。
羽生田 仕事を分析するところの「もの」がこの概念クラス図の登場クラスで参照して定義できるかで、チェックがかかるということですね。
児玉 そうですね。歯止めというか、自分の理解の裏づけというか。順番にこうやるというステップはなくて、さまざまなモデルを行ったり来たりします。僕は静的モデルから入るんですが、人によって違うんでしょうか。
羽生田 ユースケースから行くとクラスが爆発しちゃって、収束して整理してクラス図にするのが辛いですよね。
児玉 そう思いますね。まず用語を定義した方がいいですね。足りない分を直せばいい。
吉田 ユースケースから入ると機能分割しちゃう人が多いですね。そして「昔書いた機能仕様書と同じじゃないか」となる。
児玉 僕のユースケース（の基本系列のステップ番号）は、1番2番と始まって6番までしか書いちゃいけないくらいのものです。
吉田 もともと羽生田さんが訳したOMTの頃は、「クラス図を書けばシステムができちゃうぞ」と、みんなクラス図を書くことに熱中しすぎていて、何を作るんだっけというところを忘れていましたね。そこで、何をしてくれるものを作るのかをちゃんと書かなきゃいけないとヤコブソンが言い出して、ユースケースがあるんだと思うんですが、「じゃあユースケースでいいんだ」と静的モデルを書く方をあまり分かっていない人がユースケースから入っちゃうと、危ないんですよね。「構造化設計と同じだ!」ということになってしまう。教科書にはユースケースから書くようにと書かれていますから。教科書はドメインモデルを軽く書いてからにした方がいいですね。
児玉 同時並行かもしれないですね。
山城 同時並行するとします。児玉さんみたいな人が10人いればいいのですが、1人しかいないと1人でできる仕事量は限られますね。いろんなメンバーとコラボレーションしながら作っていく、そのときのコミュニケーションはどうされているんですか。
児玉 プロジェクトチームの中でやって、ある程度できると事業部内のサポートチームでレビューするとか、最終的には（技術部門による）モデルレビューがあるのでそこまでにはつぶしておかなければいけないとか、そんな風にエスカレーションしていく感じですね。
山城 エスカレーションする前の原形というのはどうですか。
児玉 ときどき見ますけど、ひどいモデルもありますよ。「俺、こんなこと教えたっけ??」みたいなものが(笑)
吉田 弊社ではまだDOAでやっているプロジェクトも多いのですが、最初にワークショップで白板にエンティティをポストイットで貼っていくんですが、議論しているのは実はユースケースなんですね。どうしてこんなことをやるの、こういうことをやっているからこうなっているんだ、ということを議論しているんですが、結果として残るのはER図なんです。ワークショップに出ている人は、どうしてここが1対多になっていてどうしてここにもう1個エンティティがはさまってこういう形になっているかを、議論を知っているから覚えているんですが、出ていない人にとっては、ユースケースの記述、つまりそのときに議論されていたものが残っていないので、なぜそんな構造になっているかがあまり分からない。そういう意味でユースケースを残すことには意味があると思います。
羽生田 その場合のユースケースというのは、もの・こと分析や、ここでいうDFDで書くレベルで十分ですね。
吉田 実際にそのデータを使ってこういうことをやるからこの構造になるんだよという議論をしているんですよね。その根拠を残さないでER図だけ残しちゃうと、参加しなかった人にはなぜその構造なのかがいつまでも分からない。そのためのユースケースですね。最初はワークショップから入るので、そのときにもの・ことで最初に絞って考えられるのはいいですね。あらゆるところを全部書こうとするとすごいER図になってしまうので、そうじゃなくて本質だけを見ましょうよ、というのをもの・ことでやるといいですね。
羽生田 22ページのスライドで、静的側面、動的側面、機能側面とありますが、普通にUMLを使ってモデリングしている人は「シーケンス図がない」と思うんじゃないでしょうか。どういう考えで、動的側面はステートマシンと活動図にしたんでしょうか。
 図４ モデル間の整合（講演資料 22 枚目スライド） 児玉 僕が使っていないだけなので、使えばいいです。僕がやるのは要求レベルなので、そんな細かいところまではやっていないだけです。
羽生田 要求レベルではシーケンス図で書く必然性はないと。
児玉 それなら状態機械図でいいじゃないかと。ただ、さっきのレベル3とレベル4のプロトコルはシーケンス図で書いています。設計するときはそうなっちゃいますね。でも、要求レベルならこんなもんかなと。
ワークショップの本来の目的へ羽生田 ここからは、このワークショップの本来の目的/目標であるところの、「モデリング技術を体系化するための軸やフレームワークはどんなものか」に移ろうと思います。いきなり聞き出すのは大変なので、最初に戻って、児玉さんの考えるモデルとは何か、モデリングは何のためにするのか、を一言で教えてください。
児玉 僕にとっては人に伝える前に自分で考えるための手段なので、自分の「思考の見える化」だと言っています。私はワーキングメモリの容量が少ないので外に出さないと大量の情報を扱えないんですが、形式的に書くことで思考が促進され、深められるんですね。そうした思考の結果が作品であり、それがそのまま人に伝えられるものになる。それは共通言語だからで、UMLを使おうと言っている理由は後半部分です。別のものを使うより1つの方がいいから、UMLを使っているわけです。
羽生田 あるダイアグラムや表現がモデルかモデルでないかを分けるのは何ですか。
児玉 みんなモデルですね。ポンチ絵もそうですし。
羽生田 役に立てばよいということですか。
児玉 学術的に言うと、モデルは「説明できる/予測できる/操作できる」でしたっけ。それ自身を説明できるのかそれを使って説明できるのかは色々あると思うんですけど。
羽生田 その辺はかなり意識しているんですか? さっきの、正しいか間違っているかではなくて、うまく説明できるか/うまく納得させられるかがポイントだということですか。
児玉 そうですね。
講師の考える「現状のモデリング技術の問題点」羽生田 では、今日の講演の中でもいくつかご指摘いただいたんですが、改めて、現状のモデリング技術の問題点で感じているものがあればそれを教えてください。
児玉 私の能力のなさのせいだと思うんですが、まだちゃんと書けていないと思います。
羽生田 たとえば、どういうところですか。
児玉 エクサのSPBOMの話になりますが、SPBOMは二度と同じものを作らない日本の製造業のためのものなので、品番がないんですよ。ということで、ものを識別するということはどういうことかという本質の議論にもなるんですが。「(品目)群」というのがあって、それは属性の「種類」を複数持っています。実際のインスタンスとしての「品目」というのは、属性に対する「値」を持っているんです。このように書くんですが（図5）、どこか足りない。それが分からないんです。こればっかり10年やっているのに分からない。品目と値と種類がファウラーの観測パターンだということまでは分かるんです。品目群は属性の種類を持つ。長さがあり高さがあり奥行きがある。現物に対しては長さが何センチ、幅が10センチで奥行きが何センチとか。で、何が分からないかというと、たとえばテレビという製品群が幅と高さと奥行きを持っていますと言ったときに、パソコンという群も同じものを持っているわけです。つまり、群の方に「*」が付く。そうするとますます怪しくないですか? 感覚でしかないんですけど、何か違うぞ、と。実装できちゃうけど、真のモデルは?というと何か足りない。何か限定的になりきれていない気がするんです。それが伝えられないというのはモデリングの問題かもしれませんが、何がまずいかを検知する方法はないのかなあと思います。
モデルのデバッグという話を生徒にすることがあるんですが、そのときにはアンチシナリオを考えるようにと言います。アンチシナリオは、限定した場面だと考え付くし、誘導するから考え付くんだけど、「何かがおかしいぞ」というときには考え付かないんですよ。ただ、怪しいぞというのだけは分かる。モデル検査とは別の問題ですね。  図５ 属性値によるオブジェクトの識別（ワークショップで追加された図） 羽生田 検査というより、児玉さんとしては自分のSPBOMという領域において、とりあえず役に立つ、正しいかどうかは別にして、まあまあ説明できて業務の範囲では納得もできるモデルは入手できたけど、モデルの美しさとか対称性とかという観点で気に喰わないと言っているんじゃないですか?
児玉 モデル理論がないんですよ。(図の)上半分は知識レベルになっていて、1対多が多対多になるというファウラーの言うとおりで、ここまでは納得しているんですけれど、ここの正しさが分からないんです。人には分からないかもしれませんが、この感じの悪さ。
山城 UMLのクラス図の表現能力が足りないということですか?
児玉 そうではありません。書けるか書けないかではなく、書くべきことが書かれているかどうかが分からない。
羽生田 そこが気になっているのですね。特に、UMLとか、DOAで使っているER図とか、ビジネスプロセスを表現するためのものとか、そういうレベルの問題意識ではなくて、特定の記法ではないところでの悩みですね。
児玉 特定の記法での悩みといえば、UML 2.0で出てきたパートとか(笑)、ささいなことはありますよ。アクティビティ図のオブジェクトフローが「どうして実線になっちゃったの?」とか。インスタンスでなくなりましたよね。なんでなの?と。シーケンス図も、1.0のときはインスタンスのつもりでいたのに「どうして下線がなくなっちゃったの?」みたいな、記法の悩みはあるんですけど。そうじゃなくて、こちらはもっと根源的なんですよね。
羽生田 その話とも何かつながるかもしれません。下線がなくなったのは、相互作用の中でのインスタンスの役割を抽象化しているんだ、と私は説明しています。インスタンスでもあり、クラスじゃないけど、概念レベルに持ち上げているんだ、というように。
照井 モデルは認識を伝えるためのものであって、自分の認識したものを伝えられているかに不安があるということですか?
児玉 そうです。分かる人が見て、ある程度までは分かるけど、「何かおかしいよ」というところまでつながってくれるかどうか。「違うよ!」「こんな場合はどう?」と質問してくれればいいと思うんですが。
羽生田 それはさっきのレイヤの問題とも絡んできて、群が1かmanyかというのは、レイヤをどこで切るかと微妙に絡んできますね。
児玉 だから決定的に言い切れないんですよね。
モデリングの中でのパターン羽生田 そういう中でも、モデリング方法論はあるようでないという話ですよね。説明を納得する1つの手法として、ファウラーのアナリシスパターンとかで理解をつなげられるし、チェックではなくても、ある程度説明をつけられているかどうかの参考にはなるということですね。では、パターンというのはモデリングの中でどう考えるべきですか。
児玉 パターンは、モデリングノウハウのかたまりだと思っています。解きほぐして使えれば使えるんだろうな、と。本質的なパターン論は別にあるとしても、アナリシスパターンは、モデリングスタイルみたいなノウハウですね。デザインパターンは、それとは違って、アーキテクチャだと思います。
羽生田 アナリシスパターンは概念の整理の仕方のイディオムでしょうか。
児玉 イディオムというのが一番いいかもしれない。
羽生田 アナリシスパターンが、デザインパターンやアーキテクチャパターンに比べて普及していないのはなぜでしょう。
児玉 UMLじゃないというのもあるんでしょうか。そうじゃなくて、分かりにくいからかもしれません。
羽生田 実装や設計が好きな人は理解するのが辛いみたいですね。
児玉 実装じゃないですからね。出版社に『アナリシスパターン』の解説書を書けと言われて、書くよって言っちゃったんですよね。『アナパタ注解』っていう、題名だけ決まっているんですけど。
吉田 あの本は難しいというのは確かですね。
児玉 題名だけで中身はまだ考えていませんが、解説は必要ですね。デザインパターンは解説してくれる人がいたから、正しく広まったということです。アナリシスパターンはアメリカでも説明している人はあまりいないので、難しいんでしょうか。
羽生田 デザインパターンは、プログラミング言語にマッピングして理解しやすいんですよね。アナリシスパターンだとそれができないんです。
吉田 (デザインパターンは)ご利益が明らかだと。
児玉 アナパタもご利益はあるんですよ。今まで書けなかったものが書けて、実装もできて、製品も売っているということは大きいご利益なんだけど、でも(本が)売れてないでしょって言われるとその通りなんです。
羽生田 売れていない、普及していないというより、理解されていない。
児玉 普通は、品目には品目コードを付けるでしょ、識別するでしょと思い込んでいるじゃないですか。在庫データベース作らないとおかしいよね、って言う人が結構いますよね。
<児玉補記>在庫は、本質的には導出クラスです。
藤井 現実にアナリシスパターンほどの柔軟性が要求されることはないですよね。一社の固有のシステムを作るというスタンスに立つと。
羽生田 児玉さんみたいにフレームワーク作るとか、特定の工場のプロセスではなくてありとあらゆる業種のフレームワークにしていかなければならないという条件が与えられている世界では、役に立つと思うんですけど。そこまで汎用性を求めてモデリングで悩むくらいなら、実装しようと言われちゃうんですよ、きっと。
児玉 そうかもしれませんね。ソフトウェア製品ではなく情報システムの製品を作るときは、こういうことがないとcommonalityとvariabilityを分けられませんが。
羽生田 SPBOMのチームでは（モデルの）存在価値が理解されていますか?
児玉 新人が来たらそこから説明をさせています。そして、これをもとに実装していますから。チームの中ではフルに使われています。
山城 そういう使い方がアナリシスパターンの本には書かれていませんね。パターンの列記はあるけれど、どう使おうかというと分からなくなる。デザインパターンは何となく分かるじゃないですか。
児玉 （アナリシスパターンも、）プログラムを見せれば分かりますけどね。でも、プログラム見せるところまで落とし込むだけでも、個別性が強くなって、せっかくのアナリシスパターンの意味がなくなってしまう。
羽生田 デザインパターンやアーキテクチャパターンは、あの23パターン以外にも少しずつ増えていっていますね。アナリシスパターンは、人間の概念の操作の歴史からすれば、それ以上にあるはずなのに、生み出されていない。いろんな分野をモデル化という観点で整理していけば、会計原則や自然科学の保存則など、あるはずです。そのあたりがこれからですね。
児玉 SPBOMは知識部分なんですよ。これの実行部分が勘定パターンです。その拡張である要約勘定パターン（図 6-1 ）では、トランザクションから「明細勘定」に関連が引かれていて、これを積み上げて、上位の要約勘定にロールアップしていくというモデルなわけです。でも生産管理では、作るときには（明細勘定に対応する）「個体」で1個なんだけど、そこに10個入っているようなこともあるので、「個体」ではなく（「勘定」に対応する）「資源保有」につなぐんです（図 6-2 ）。そうすると、「個体」か（要約勘定に対応する）「群体」かを識別する必要がなくなるので、Compositeパタンではなく、資源保有が再帰関連を持つという形にする（図 6-3 ）。すると、「個体」もどんどん分解できる構造になる。
  図６ 要約勘定パターンを生産管理に拡張する（ワークショップで追加された図） 羽生田 これはパターンと言っているんですか。
児玉 これは情報処理学会でCHARM(Cross Hierarchical Account Resource Model)という名前で発表しています。モデルとしては退化しているように見えて、ベーシックな勘定パターンに戻っているんだけど、深い意味があるわけです。再帰関連のところが動的に変わっていくんですね。1個がどんどん分かれていく。実装としては枝番を付けていくような形で。今まで1個だったものが、切って使った残りのものと使われたものになる。液体なんかは三分の一使いました、その残りはどのくらい在庫されていますかといったかたちです。
羽生田 そんな感じで実際にパターンを現場で使っていると。
児玉 そうです。ここ（図 6-4 ）もアナリシスパターンの計画パターンですよね。つまり、使えるんですよ。
羽生田 ここまで使いこなしているのは他では聞かないですよね。
児玉 聞かないですね。こっちもあんまり言っていないし。
羽生田 強力なプロテクトがかかっていると思います。理解が難しいという(笑)
情報システムとソフトウェアの関係羽生田 では、話がちょっと飛びますが、情報システムとソフトウェアとは視点が違うということを今日の講演でも話されていました。一言で言うとどういう違いなんですか。
児玉 情報システムは人です。人がどう使うかまで設計するのが情報システムです。これで一気に複雑系になってしまいます。ソフトウェアは、ものづくりのQCD(品質/コスト/デリバリ)の世界ですよね。でも情報システムはEEE(efficacy/effectiveness/efficiency)と言われています。そこの鍵は人なんです。人がいないとソフトウェアはQCDだけになりますが、人が入ってくると、「本当に効果があるの? 実現性があるの? 意味があるの?」という話になってくる。
羽生田 モデリングとのつながりは?
児玉 使う人やそれに対して責任を負う人、つまり、ロール名を明らかに出そうとしているんです。でも、ソフトウェアとして見ると、ユースケースの中にアクターなんて要らないんですよね。すべてがユーザーでいいので。情報システムの観点は、ユーザーを施主と行為者に分けたとか…
羽生田 パトロンを出したとか?
児玉 パトロンはどうかなぁ(笑)
でも、重要かもしれない。 羽生田 お金の話を入れようとすると出てきますよね。
山城 モデリングするというのは、ソフトウェアのモデリングではなくて、システムとしてモデリングするということですか。
児玉 ソフトウェアのモデルも情報システムのモデルも両方あると思います。ソフトウェアのモデルにデザインパターンがあったように、情報システムのモデルにはアナリシスパターンを考えたらいいかと思います。また別に、情報システムのパターンランゲージがあるんじゃないかと思います。会計のための情報システムのパターンランゲージとか、製造業のためのパターンランゲージとかがあるんじゃないかと思うんですが、どうもこの業界でパターンのカタログはできていてもパターンランゲージができていないのは、業務の枠組み、つまり情報システムの枠組みで考えていないからじゃないかと。
もともとのクリストファー・アレグザンダーが言っていた『パタン・ランゲージ』は、たぶん、家を建てるのではなくそこでの生活を設計したかったんだと思うんです。どう活き活きと生活するかという。そう考えると、パターンランゲージは情報システムで考えるともっともっと出てくるんでしょうね。『パタン・ランゲージ』の後ろの方の施工パターンに相当するものは、デザインパターンとしてできてきているけど、前の方ができていないというのはそういうことだろうと思います。[パタン・ランゲージの「前の方」とは、国とは何か、都市とは何のためにあるのか、地区はどうつながっているか、など、町に入る前の段階についての記述]情報システムとソフトウェアとの違いは、はっきり切れるものではないけれども、スペクトルの違いは明らかにしないといけません。 山城 人がシステムの内側にいるのが情報システムで、外側に出しちゃって残ったのがソフトウェアということかと理解したのですが。
児玉 結果としては正しいです。でも、そういう風に設計するわけではない。わざわざ人を出すという手順でソフトウェアを設計することはしないけれども、定義は正しいです。
要求と分析と設計の関係羽生田 では次に行って、要求と分析と設計はどういう関係だと捉えればいいでしょうか。
児玉 問題の分析はあるけど、要求の分析はないと思っています。（システム開発取引の）共通フレームで言われている要求分析というものは、分析でもなんでもなく、単純に仕様理解だと思います。設計はやっていますよね。さっきの要求品質に対して、製品の特性を対応させていくということが設計。設計は入れ子構造になっていて、さまざまなレベルで存在する。最初の要求のモデルは、世界を決めて、インプットされて何が出てくるか、です。さっきのTo BeとAs Isのギャップをどう埋めるかがとりあえずの要求になる。僕は要求を2段階で捉えていて、施主の原要求とシステムの要求(ソフトウェアの要求を含む)があると思うんですが、それを切らないとダラダラいっちゃう。はっきり分けられるものではなくて、こういうものがあると決めちゃっているだけですが、7割8割がたはそれでうまくいく。そういう風に要求と分析と設計を捉えています。
羽生田 要求と設計の間はどうやってつなぐんですか。
児玉 品質機能展開しかないんじゃないですかね。今のところは。
羽生田 そこの作業は児玉さんのことばでは何と言うんですか。
児玉 設計作業。
羽生田 それは実装じゃないですよね。
児玉 実装じゃない。実装はインスタンスを扱うところですね。
羽生田 要求品質展開って言えばいいのに、どうして要求分析って言うんでしょうね。
児玉 僕は分析とは思っていないですよ。世の中のソフトウェアプロセスが、分析から始まるということにしているだけです。でも分析でも何でもない。それはワインバーグも言っています。ワインバーグは分析ではなく合成だって言うんですけど。それもちょっと違うような気がしますが。
さまざまな技術とモデリングの関係羽生田 では次に、UMLに関してどう付き合えばいいでしょうか。
児玉 標準語として使えばいいんじゃないですか。
羽生田 2.0に問題はあるという話ですが、それでも何とかだましだまし使えばいいと。
児玉 キーワードで何とか逃げちゃおうと。逃げ道が用意されているのでいいと思います。要求レベルのモデルは要求レベルのモデルでプロファイルを決めれば何とかなるんじゃないですか。
山城 オブジェクト指向をやって来られて、UMLが普及したと思いますか。
児玉 普及したと思います。さらに、Javaも普及したけど、さてオブジェクト指向はどうかというと、まっとうじゃないオブジェクト指向がはびこってしまったという感じですね。
吉田 オブジェクト指向とは何かという定義の仕方で[オブジェクト指向が普及したかどうかの]答えは変わりますね。
児玉 何か言語を使っていればいいという感じになっちゃっていますよね。
羽生田 次に、OCLや形式手法とモデリングの関係について考えるところはありますか。
児玉 OCLはやりたいとは思います。
羽生田 この本(『UMLモデリング入門』)ではOCLはやめましたと書いてありましたね。
児玉 概念レベル/要求レベルでのOCLにこだわるなら他で時間を使えということです。でも自然言語の裏付けというか、意味論としてのOCLはどこかで作っておかないと、翻訳ができない悪いことば、ill-definedになってしまいます。
羽生田 それはどこで誰が使うんですか。
児玉 制約として使うときの日本語の標準、こういう使い方があるよ、というのをどこかでやらないといけません。
羽生田 日本語でこういう風な言い回しで書いたら、その意味はこういう意味だと決めましょう、というその「決めましょう」の部分をOCLのようなことばで書くということですね。
児玉 裏付けがないと、あまりにも勝手に書いてることになりますね。共通言語として見たら、そこまでやらないといけません。
羽生田 現場のエンジニアには自然言語で書かせるんだけど、セミフォーマルな自然言語で制約記述をさせる場合の部門の中での標準定義は、OCLで裏付けを書きましょうということですね。そういうのをやっているんですか。
児玉 やっていません。それをやろうとしているけど、断念しているんです。たとえば、{階層}をOCLで書けないんですよ。でも、「階層」というのはこういう意味で使うんだよというのを自然言語で言ってしまってもいいのかもしれません。
羽生田 MDAに関してはどう考えていますか。
児玉 ノーコメントです。僕は要求までしか書かないつもりだから、そこから先は勝手にやってください。
羽生田 SOA[service-oriented architecture(サービス指向アーキテクチャ)]に関しては?
児玉 半分ノーコメントです。今流行っているようなSOAはどうでもいい。ドメインが共有されるサービスが定義できるように育っていくのなら、SOAはいいのかなと思いますが。今のは実装技術になってしまっているかな。
山城 情報システムのドメインとはどういうイメージですか。
児玉 さっきのCHARMですね。
羽生田 生産管理の文脈で、SOAがこんな風に使えるといいな、というのはあるんですか?
児玉 たとえば、Subsumption Architectureみたいに、ここ（図 7 のA）で何かアクションが起きると、ここ（同、B）にインスタンスができて、それをこっち（同、C）でdetectして、動いていく、そういう仕掛けがないかな、と。
 図７ Subsumption Architecture ライクな SOA のイメージ （ワークショップで追加された図） 羽生田 つまり、アーキテクチャやメカニズムで実装するんじゃなくて、生産管理の美しいパターンがなぜかそのまま動くようなフレームワークが欲しいということですか。
児玉 製造指示が出て実行しました、すると次の工程では部品を引いてくるよという風に即座に動いてくれればいいですよね。
羽生田 SOAはある種の業務やドメインモデルレベルの仮想化技術だと私は捉えているんですけど、それに近いですか。
児玉 そのくらいにならないと、たぶん単なる寄せ木細工の全然くっつかない技術になっちゃいますね。
羽生田 ビジネスモデリングやエンタープライズアーキテクチャ(EA)は?
児玉 EAはインチキだから捨てます。
羽生田 どういうところがインチキでしょうか(笑)
児玉 あれは説明のモデルであって、いわゆるビジネスモデルではないですね。ザックマンフレームワークに戻るとまともなんですが、エンタープライズアーキテクチャではゆがめて定義してしまっている。アメリカのCIOの集まりは、あの三角モデルをやめているんですね。昨年か一昨年くらいに。その程度のものをエンタープライズアーキテクチャというのではなくて、再度議論して、ちゃんと作りなおしたほうがいいと思います。
羽生田 そのときに、アナリシスパターンと絡められますか。
児玉 エンタープライズレベルのアーキテクチャというのは分からないでもないけれど、システム階層をどうしていいのかが解決しないと僕は手を出せないですね。まだ今は小さいところでモデルを書くのが精一杯。それを積み重ねないとアーキテクチャにはならないと思います。それに、アーキテクチャは設計しようとして設計できるもんじゃないですね。architecturalにシステム設計はするけど、アーキテクチャを目標にして作っているわけじゃないんです。積み重ねているうちにアーキテクチャの確立はしていく。そういうつもりでエンタープライズアーキテクチャを構築していくべきだとは思いますが、まだ何も言えません。
羽生田 Web2.0、3.0とモデリングとの関係は何か感じますか。
児玉 実装には興味なしです。
<児玉後日追記>すみません、Webサービスと勘違いしていました。ただ、たとえばロングテールはビジネスモデルであって、ソフトウェアの構築技術とは異なると思います。
羽生田 実装という意味ではなくて、社会的な関係性の管理みたいなところは?
児玉 Web2.0というのは追っかけていないですから。
羽生田 では、オフショアとモデリング技術の関係は?
児玉 オフショアであろうがなかろうが、設計と施工は分ければいいと思っています。建築業が設計図を元に見積もりや提案のコンペをやる、というようなものはあっていい。そういう意味で、設計/仕様と実装/構築/施工は分けられるので、そこで使う標準的な図面の書き方は大事です。それが解決して、さっき言った誤解を生みそうだなという図が、誰でも正しく受け取れて、施工に回せるという、そういう風になるといいなと思います。オフショアに限らず施工者に対しての指示図面として。
羽生田 設計事務所みたいなものが存在できるようになってほしいと。
児玉 それで食えるといいと思いますね。
羽生田 「ソフトウェアは、設計をいろいろ試して実装で確認しながらアジャイルにやらないとうまくいかない」と言われたら何と答えますか。
児玉 それは（大企業がやるような）研究開発段階なんでしょうね。でも、研究開発段階が終わったら、そこまで。（あとは、その成果を使った量産段階に入ります。ここはアジャイルではないと思います。）保守サイクルを頻繁に回すというだけのアジャイルもあります。それとは別に、研究開発のように、やってみなけりゃ分からない世界でぐるぐる回すのは必要なんでしょう。
新しい技術トレンド羽生田 これまでに挙げたのとは別に、モデリングにつながる新しいキーワードやトレンドはありますか。
児玉 あまりないですね。
羽生田 システム思考は?
児玉 システム思考は技術トレンドとは思っていません。情報システムとして捉えたときに、要求を考える人の必須の理解だと思うんです。ソフトウェアは複雑系ではなく理屈の世界だからシステム思考はいらないけど、人間が入ったときはシステム思考が必要だと思います。
モデリングを普及させるための教育羽生田 教育や普及活動についてですが、モデリングをするのに必要な最低限の素質や向き不向きはあるんでしょうか。
児玉 ないと思います。インスタンスしか考えられない人はだめですけど。
吉田 考えられない人が多いですよね。そこが一番難しいところです。
児玉 最初にモデリングのセミナーをやるときに、インスタンスを列挙しなさいとか、型を出しなさいとかいうんだけど、書けない人っているんですよね。インスタンスって何ですか、というレベルではなくて、型が分からないんです。インスタンスの列挙だけで生きてきた人っているんですね。
羽生田 ことばを使っている限り、ぜったいありえないんですけれど。
児玉 そうなんですけど、思考特性として、抽象化したくない/できない人っているんじゃないでしょうか。
吉田 いますね。線を引いて「*」を書くと分からなくて、3つ書いて3本線を引かないと分からない。
児玉 エスノメソドロジー(ethnomethodology)は、モデルを絶対に書かないぞって決心した人たちだから、ひたすらインスタンスを集めるんですね。それも大事ですけど、だからどうなの?といつも思うんです。
河合 型が出てこないのは日本人だからかもしれません。西洋の人は得意ですが。そもそも「概念」ということばは大和ことばにはなかった。明治時代になってヨーロッパから抽象概念というものを持ってきた。だから日本人は型というものが苦手なのかもしれません。
吉田 児玉さんの今日の資料で、カナリアに翼が付いていなくて、鳥に翼がついている。これが分からないんです。カナリアにもダチョウにもペンギンにも、全部翼を付けたくなる。
 図８ 意味記憶（講演資料 3 枚目スライド） 児玉 そういう人はどうすればいいんでしょうね。それが最初のスクリーニングになるんでしょうか。
山城 そういう人は感覚的にどれくらいの割合でいるんでしょうか。途中でちゃんと分かるようになるんでしょうか。
児玉 そうなる可能性はあると思います。教えていないだけ。センスとか言うとおしまいで、時間がかかる人がいると考えないと。ことばをしゃべっているんだから、羽生田さんが言ったように、一応抽象化しているわけなんですね。ただ、その人たちにどれだけ時間をかけられるかが、ビジネスレベルでは関わってきますね。
羽生田 組織としてモデリングリテラシーをどう捉えてどこまでコストをかけるか、ですね。
児玉 そうですね。全員がモデリングする必要はないから、できる人だけ集めて優先的に教育させるという手もあるし、うちもそうしていますけど。
吉田 日本はコストをかけてリテラシーを上げなきゃいけないと考えますね。欧米ではリテラシーのある人に「やってよ」と言うことになります。だから逆に、リテラシーを上げようと個人が頑張るわけです。日本はリテラシーを上げようという個人としての動機が薄い。
山城 ソフトを作っていると、使う機会がないのかもしれませんね。上流レベルのことを知らなくても作れるものはたくさんありますから。
羽生田 入門教育、モデリング導入教育としてお勧めはありますか。
児玉 『UMLモデリング入門』はそういうつもりで書きました。ただ、それより「何のために」という動機付けなんですね。モデルは情報システムの設計図なんですよ。設計図を読めないと家は建てられない。お客さんの方もある程度設計図を読めないと、いいとか悪いとか言えない。これが設計図なんだという実感を持ってもらわないといけないんです。概念モデルがそのまま実装モデルになっていく、多少枝葉がくっついたとしても、構造はほとんど変わらないで実装にいく、それがそのままソフトウェアになって、なおかつ変更に強いというところまで全部見せられて、どうだこれだけ楽になるんだよ、というのがベンダー側の教育。もう1つ、発注者側の教育も必要で、図面をチェックしてここがおかしいと言えるくらいにリテラシーを上げないといけない。両方必要ですね。今気になっているのは、施主側のモデリング教育です。モデルと費用の見積もりはつながっていると言いたいんです。そういうストーリーがないと発注者側は乗ってきません。
羽生田 そうなると、アーキテクチャや運用やプラットフォーム制約のモデルも作らなければいけなくなりますよね。情報システムとしてコストを算出するためには。
児玉 厳密にコストを算出するわけじゃないから、発注者側は世間相場が出てくればいいんです。作る側は、現実的な原価を出さなければいけませんが。
羽生田 そういう言い方をすると、モデルを作る必要はないことになりませんか。
児玉 ここをこう変えるといくらになるね、というのが見えていなかったら、ここをはずしてくださいって言えないじゃないですか。そのくらいは必要です。
羽生田 そのへんの微妙なレベル感の合意がないですね。
中原 上流のモデルが考えられなくて、すぐに実装を考えてしまうんです。分析まで考えてアーキテクチャモデルをきちんと設計させたいんだけど、それができなくてすぐに細かいレベルで考えちゃう人が多い。すぐステップ数がこのくらいで、と考えてしまう。うまく分析設計をさせるようにしたいんだけど、実装ばかりやっていると、そうなってしまうんでしょうか。
児玉 概念レベルでとめるのに不安があるんですよね。ちゃんと作れるんだろうか、という不安が。見積もりなどに関しても、「精度はここまででいいんだ」というのがあるんです。ある程度まで設計しないと精度は上がらない。ファンクションポイントを教えるときは、Requirements Spec.ではFunction Pointで、Product DesignからDetail DesignまではSLOC、そこからDevelopmentとTestまでは時間でやれ、と言います。プロジェクト管理では、管理のための指標は、進捗に応じて今ある根拠で推定できる範囲でしかできないんです。要求なら要求を根拠にしたFunction Pointで測るんだ、設計が終わってプログラムが見えてきたらステップ数をカウントすればいい。詳細設計になって何をコーディングすればいいか分かったら、それが誰が何時間でできるかを使えばいいじゃないか、というんです。メトリクスを使い分けろということです。使えないときに使うな、要求しかないのにステップ数を使うな、逆にステップ数が使えるようになったらFunction Pointはもう要らない、という話をします。FPの精度は±66%、SLOCは±33%程度の精度だと言われているんですが、たかがそれくらいのレベルで、最初から見積もり精度を上げる必要はないので、今はここで止めてもいいのだ、と納得してもらうしかないと思うんです。
羽生田 教育について言い残したことはありませんか。大学教育と企業教育の住み分けとか。
児玉 大学生に教えるときには研究ネタを振るんですけど、社会人の大学院生は、本当にこれで手足が動くかをすごく気にするんです。相当噛み砕いて、「こういう効果があるよ」と見せないと分からないんですが、でも、分かるとものすごく質問が出てきて、教育の質が上がる。学生はまだ何を質問していいかをよく分かっていない状態です。こういう技術を教えるなら、一度社会にでてこいとか、インターンの中で教えるとか、やらなければだめですね。最近の学習理論だと正統的周辺参加だとか拡張による学習のように、仕事の枠組みでないと人は学ばないって言うじゃないですか。それをどこかで作らないとだめだなと思います。大学教育を仕事の枠組みにどうやって組み込んでいくのか。project based learningとかいうけれど、それを回せるだけの大学教員はいないですしね。
UMTP 認定試験羽生田 UMTPの認定試験はどうお考えですか。
児玉 みんなHAPPYなんですか?
羽生田 まだ今のところ、資格が取れているからそれで嬉しいというところまではつながっていないと思います。
児玉 たとえばITSSとはどうつながっているんですか。
山城 ITSSユーザーグループが公開しているベンダー資格と、ITSSのマッピングというので位置づけされています。どの職種のどのレベルに対応する、というのが。
児玉 個人の学習意欲とは別に企業が取らせるということになると、「モデリングができるといくらで売れる」という発想になる。で、ITSSとつなげて、ということになる。そういう明示的な連環がないと、食っていける認定試験になりませんね。
羽生田 最近は認定試験にもL3というのがありますので。受けるなら感想を聞かせてもらえるとありがたいです。
吉田 サンプル問題もダウンロードできます。
羽生田 サンプル問題より実際の問題の方が面白いものが出ると思いますよ。
今後のモデリング羽生田 最後に、今後モデリングを我々としてどうしていくべきかを教えてください。ここにいるメンバーに対して、こんなことをして欲しいとか、こういう方向に向かわないとまずいというようなメッセージを。
児玉 大事なことだと思うんですよ。ちゃんとした図面だということをみんなで声を出して認めさせなければならない。たとえば政府調達でER図とDFDを入れろと言っているけれど、中身はめちゃくちゃなんです。ちゃんとしたモデリングとはどういうものかを政府調達では言えないんでしょうか。このモデルはこうおかしいとか。
羽生田 言えないでしょう。どういう観点でどういう品質の評価をするのかをモデルに関して言えないじゃないですか。
児玉 建築の場合は、図面に対してハンコを押す人がいるわけです。一級建築士とか技術士がハンコを押さないと図面として発効しません。そのように、モデルの正当性を認定するような法律を決めないといけないんでしょうね。法律までいかなくても、正しさをある程度裏づけて、それこそL3を通った人のハンコがないモデルは気をつけた方がいいよという風にしないといけない。
羽生田 そういう方向に進むべきだと思いますけどね。
児玉 それが実質的に正しいことの証明を積み重ねるしかありません。
モデラーを目指す若いメンバーへ羽生田 最後に、モデラーを目指す若い人に一言と、お勧めの本を教えてください。
児玉 モデルは楽しいよ、というのを分かって欲しいです。こんなことが書けてこんなことが分かった、というのを示せるといいなと思います。自分で書いた昔のモデルを見て「こんなことが書けているんだ、すごいな!」と思うことがあるんです。そういうモデルの鑑賞方法、モデルを味わう学問があってもいいのかもしれない。書く側と鑑賞する側というのがあって、いいとか悪いとか美しいとか、そんな風な、作品としてのモデル、作品として鑑賞する審美眼みたいなものがないと、作り手も読み手も楽しくない。そのために、こんなに楽しいだよ、こういう風に見るといいんだよ、というのを伝える人がいるといいですね。モデラーの技術というより、道案内する人が必要なんでしょう。若い人に味わい方を指導して欲しいですね。
羽生田 ツアーを組んでください。
児玉 それは認定試験という辛いことではなくて。楽しいことで。
羽生田 L3は楽しいと思いますけど。
山城 チャレンジングですよね。
児玉 それを評価するというか、鑑賞してあげないと、試験で答案書きましたで終わってしまうと辛いかもしれません。
羽生田 お勧め本は?
児玉 私の本はどうですか。
羽生田 その他に、「モデリングに関してはこの本」というものはありますか。マーチン・ファウラーでもいいんですけど。
児玉 僕は『アナリシスパターン』がいいと思います。分かりやすく噛み砕いてあげれば。
中原 情報処理学会で発表したときの資料などは見られますか。
児玉 論文誌で児玉で検索すれば出てきます。CHARMという名前で、生産管理の一般モデルという感じで書いています。書いて1ヶ月もしないうちに次のモデルに改訂されましたけれど。今はCHARM2です。発表した後で、「こっちの方がずっといい」というものが出てきたんです。製造取引の集まりを生産計画と捉えて、それに対して注文が引き当てられているというのがCHARM1なんですが、「生産計画というのは実は計画ではなく生産注文なんだ」と気付いたら、CHARM2では注文がいらなくなって、シンプルで強力になりました。
参考文献
|
「UML」でモデリング技術の向上を推進
