それでは、これよりワークショップを開催いたします。まず、ワークショップの趣旨をモデリング技術部会の主査である山城さんから説明してもらいます。

今日は非常にためになるお話をありがとうございました。これまでに取ったアンケートで、モデリングを適用したい分野として、組込みという答えがいつも一定数あがっていました。全8回のセミナー/ワークショップの中で取り上げることができて、良かったと思っています。

モデリング技術部会では、このようなセミナーの場をみんなで共有し、その後でワークショップを開いて、部会のメンバーに講師と議論をさせていただいています。色々なモデリングの技術分野について議論をし、その後にモデリング技術をどのように体系化できるかまとめることを目的に、ずっとやってきています。今回が2年計画の8回のワークショップの最後です。どうぞよろしくお願いいたします。

次に、講師の方の自己紹介と、今日の講演で言い足りなかったことなどがありましたらそれも合わせて、お願いいたします。

渡辺です。改めてよろしくお願いします。今日お話ししましたように、元々組込みソフトの開発をやっていました。結構理不尽な現場で野麦峠のような労働をしたこともあり、紆余曲折がありまして最終的に羽生田さんが翻訳されたOMT[『オブジェクト指向方法論OMT』]に出会いました。構造化手法は教えてもらう機会があったのですが、何となく身に付かずもんもんとしていたところにオブジェクト指向の開発の仕方に出会い、試行錯誤をしながらここまで来たような感じです。組込みの現場は、本当に細かい大量の情報をそのまま力ずくで焼いてしまえ、という世界になっていて、個人的にそういうやり方に気持ち悪さを抱いていました。モデルに関しては俯瞰的にそういうのを整理することが大事なアプローチかと考えています。ただ、その良さが現場に伝わりにくいですね。組込みソフトというか日本の製造業全般にそうなんですが、良いやり方が伝わらないのは何故か、を日々疑問に思っています。未だに解は出ていないんですが、常にそれを考えて仕事をしています。

芳村です。いつも渡辺さんのモデリングに至る経緯を聞くたびに、私とは真反対だなといつも思うんですが…

僕は這い上がったタイプで、彼女はお嬢さんなんです。コンサルをいっぱい付けられて育っています。

そうなんです。私はちょうどバブルが終わる頃に前の会社に入社しました。そのときに配属された事業部がリストラで解散してしまい、それで複合機(コピー機)の組織に入ったんですが、そのときに初めてスキャナという機能をコピー機に乗せるという最初の機種の開発に加わりました。せっかくなので新しいやり方でやろうということで、構造化手法のコンサルタントに付いていただいて、一から教えられました。大学時代もソフトウェアを作ったことはなかったので、本当に教えられたとおりを素直にやったらモデリングできていた、という感じです。そこから構造化で製品を出しました。

次に社内でオブジェクト指向を取り入れて部品化しようというプロジェクトが立ち上がり、そこにそのまま入りました。それでオブジェクトと出合ったんですが、構造化手法のコンサルタントつながりでシュレイアー・メラーから入りました。ツールはブリッジポイントを使っていて、シュレイアー・メラーの本家である Project Technology社のコンサルタントに来ていただきました。本当に渡辺さんとは正反対のところから入っています。私はモデリングに関しては正統派できていたので、今日提案したようなモデルは最初から作っていたんです。ですから逆に、現場でモデルを普及させるときに、「なぜみんながあんなモデルを作ってしまうのか」が分かりませんでした。非常に苦労して現場の人にモデリングを教えるのですが、染み付いたものはなかなか取れませんね。現場でも、センスがいいというか、コードベースでやりながらも構造を考えている人はスムーズに移行するのですが、そうでない人はなかなかうまくいかない。そこで、染み付く前にオブジェクトを刷り込みましょうということで、前の会社の中で新人から教育をし始めました。そういう背景があって、コードベースでやっていた中堅クラスの人にも、やはりきれいなモデル、長く使えるモデルを作れるようになってほしいと、ずっと思っています。ただ、それは正攻法ではうまくいかないとも感じていたので、今日のように全然違うお題で始めるような、変化球のやり方が良いんじゃないかと思っているところです。

ありがとうございます。続いて、参加者の簡単な自己紹介に移ります。

豆蔵の羽生田です。よろしくお願いします。

オージス総研の山海と申します。

オージス総研の藤井です。

オージス総研の竹政と申します。

河合です。よろしくお願いします。

バブ日立ソフトの中原です。元は日立製作所にいまして、5年前に今の会社に変わりました。

豆蔵の小黒と申します。

豆蔵の皆川と申します。

東芝ソリューションの山城です。よろしくお願いします。

それでは、今日の講演内容に関して、皆さんから質問がありましたらお願いします。

基本的な質問なんですが、目的/制御/物理という階層に分けてモデリングするというのは、組込みソフトウェア自体が複雑化しているからそういう分離が今必要になったのでしょうか。昔は必要なかったんですか。

昔のソフトウェアはとても小さくて、本当に人の手助けだけ、手の役割だけでした。頭で考えるのは人で、手のところだけをソフトウェアにお願いするということだったので、目的もあまり入れようがない感じでした。それが今では、動かすタイミングや、何を動かすかや、挙句の果ては人がどう考えているかまで、どんどんやりたいことも上にきているので、必然的にシフトしてきます。ただ、現場では昔の感覚が残っていますね。

その移行期はプロセッサの世代でいうと、どれくらいですか。

手足の時代は相当昔ですね。直接的な答えではないんですが、急激に大きくなったので、全体を作っていた人が我々の少し下の世代くらいからまったくいなくなっていて、今の30代くらいの人はみんな部分部分しかやっていません。そうすると、その人の世界に閉じて考えると昔と同じように見えてしまったりして、今日お話したほど事は単純でないのかなと感じています。

「組込みソフトとは」の話で、車のABSの路面状況など物理現象や自然現象を扱うということでしたが、その他に自販機などもあります。組込みには、簡単な組込みと、自然現象や道路が滑るなどの複雑なものと、2種類あるんじゃないかと思ったんですが、いかがでしょうか。

2種類というより、連続的ですね。完全にこういうタイプとは分けられません。コピー機でも、トナーをくっつけるところは熱が関係してくるのでそういう要素はあるんですが、アプリケーションは論理だけですべてが済むわけです。機械で分かれるというわけでもないし、車でも同じだと思います。ブレーキはそうだけど、室内の電気などは関係ないので。

厳密に言うと今日の話は、機械/物理/化学などと接近する分野が特にそうだということです。

難しさが違ってくるので、そういう分け方があり得るのかなと思います。

炊飯器などは逆に、ちょっとの温度制御でお米の感じが変わってきます。人間の舌はとても敏感なので、そういう世界はすごいノウハウのかたまりだったりすると思うんですね。

その要素がどのくらいあるかによって難しさが違うのかなと思います。

自然現象を相手にするところの難しさもありますし、それ以外に、組込み機器でもソフトでやらなきゃならない部分は、機能も増えてボリュームも大きくなっています。ですから、違う難しさが両方に存在します。自然を相手にしないところの難しさは、いわゆる組込みの難しさとは違うかもしれないですね。そういう意味ではエンタープライズ系と似た難しさを相手にしているのかもしれません。

お客さんの話を聞いていると、化学分野のものを制御するときが一番大変なようですね。予測不可能なので。車のエンジン制御で、エンジンが爆発するところは化学反応です。その部分は本当に理屈がなくて、実験で出したデータでやっていくしかない。お客さんが言うには、シャボン玉を割らないように移動させていくようなものだと。こっちを押すとこっちが出るという、自分でコントロールできない物体をだましだまし…という世界も結構あるようですね。そういう意味では、千差万別です。

そのあたりはモデルと直接には関係できないんでしょうか。目的をモデル化するというのは良いと思いますが、細かなパラメータ設定はやってみないと分からないので、「どうしてそれをやったか」は目的レベルではまだ見えないと思うんですが。

そういう世界だからと言って本当にやった結果だけをパラメータ化してやっているわけでもないんです。「こういうことでしょ」という仮説のモデルを持ち込んで、補正の部分を補うことはしていて、それが有効に働いている例はあります。

それはソフトウェアのモデリングではなく、その技術分野/対象領域の固有のモデル化で、サイエンスとかの話ですね。

そうです。でも最終的にはソフトに落とすために、ソフトのモデルにもなっています。

それも実際のモデルとしてあるんですね。

あります。

目的/手段/デバイスの階層とは、何か別の階層がありそうだという気がするんですが。

それも目的に入るのかなと思います。

この目的のレベルよりもっと詳細化したような目的のレベルがあるということでしょうか。

その目的の中にも、確実にこうだというものもあれば、ある程度の仮説だけどとりあえずは理屈の説明がついてうまくいくというレベルのものもある、ということです。

目的と制御とモノというレイヤになっていたと思うんですが、今の話は制御の部分のことです。制御のところを何でモデリングするかというと、試行錯誤で見つけた制御のルールをモデル化するんだと思います。

そうですね。目的の中にも目的寄りがあったり、制御にも目的寄りがあったりしますね。

ちなみにここでは目的/手段/デバイスにパッケージ化されていますが、クラスレベルでのトレーサビリティ/依存関係はモデル化するんですか。つまり、目的レベルの「移動」「行く」というクラスが、手段レベルの「移動制御」と関係するわけでしょうか。

図1 こんな感じでどうでしょう…? (講演資料40ページ：ダウンロード資料35ページ)

基本的にそうです。

詳細化してこういう手段でやるよ、というイメージですか。

はい。

目的レベルのクラスが中心にあって、その回りにクラス増えていくと考えてよいですか。

そうですね。分析レベルではちゃんと関連を書いて、それをソフトウェアとして実現するときには仕組みを使ってうまく実現していくという形になります。クレーンゲームの分析例ではデバイスを直接出していますが、デバイスのクラスは色々なところから使われたりします。たとえばモーターだと、移動にも使うし、上下にもアームのところにも使う。そこをソフトウェアとして実現するときにはパターンなどを使うんですが、分析では私は直接引いて書いちゃったりしています。

論理的な分析のレベルですよね。目的が下に依存して、デバイスに依存するという構造は。

イメージ的には逆のような気がします。

本来は目的の方が志が高いから、低レベルなものには依存しちゃいけないというレイヤの考え方ですよね。ロバート・マーチンの言うように、低レベルに依存するのはよくないので、下位レベルのインターフェースを上に持ってきて、下のものを呼ぶためのプロトコルを定義するわけです。そうすると関係が逆になるから、低レベルのものが高いレベルのものに依存するようになります。実現レベルだとこういう構造でやった方がいいと思います。説明していただいたのは論理的な依存関係だと理解しています。

図2 ホワイトボードより

そうです。

中身の具体的な実現手段は、後で変わる可能性があるし、色々な実現手段があるけれども、その口はある程度抽象化できるはずだというのが今のインターフェースを定義するという話ですよね。それは目的ベースの口になっていて、そうやっていくと、上の方に抽象度を上げていけるから、そういうモデルを作りましょうというのが今回のテーマですね。

逆に、このプロトコルをどう決めるかというのが肝になりますね。

ですよね。クレーンゲームの例も、機器のデバイスをまとめた形で部品化しましょうという形のモデルになっているんですが、実際には部品として分けているわけではなくて、目的ベースで将来変わる可能性がある単位でその中を隠すように、間にクラスをさしはさんでいるわけです。将来はボタンではなくてジョイスティックに代わるかもしれないから、代わっても良いようにその部分を隠すような「〜機構」というクラスをはさんでいる。それが今おっしゃったインターフェースに分かれてくるんだと思います。さらに言うと、クレーンというのは移動してつかむ手段を持っている何かのものであり、それはモーターやレールではなく磁気などでふわふわ浮いていても構わないし何でも良いんですが、とにかく「指定した位置に移動するという機能を持っているもの」と抽象化するためにクラスをはさんでいる、というモデルになっています。たぶん、そこの感覚を抽象化しないといけないんですね。

回答例のモデルは具体的な機器の構成がある程度見えるような概念レベルのモデルにしてあって、本当は手段の具体的な方法が変わっても良いように抽象クラスをはさんで、もっと分解していくのが本来の姿だと思うんです。ただ、今回のL3の問題は30分間でゼロから理解して解けなくちゃいけないという制限があるから、その辺は意識的に端折っているところがありますね。本当に狙いたいのはそういう方向です。ただ、それが現場ではなかなかうまく意識してもらえないですね。

図3 次は、こちらのモデル (講演資料37ページ：ダウンロード資料32ページ)

やはりモデルを見る機会がないと思うんですね。現場にいる方は、自分や周りの人が作ったモデルしか見たことがありません。特に組込みのモデルは基本的に流通しないので、目にする良いモデルというのが組込みを例題にしたモデルじゃないんですよ。それで参考にするものがないんです。そこをどうにかしなきゃいけないといつも思っています。

年代の層にギャップがあって、今は担当別に分かれちゃっている人たちが頑張っているというのも問題ですね。俯瞰的に全体を見るという考え方を定着させたいと思うんです。今回のクレーンゲームなら、’クレーンゲーム機というコンテキストに当たるものを見て、そこから全体の構造を考えていこう’というモデリングは現場ではされなくて、何かの理由で色々な機能要素ごとにモジュールが分かれていて、その分かれたモジュールの中で頑張るという形になってしまっています。最近OMGでSysMLやシステム工学向けのモデリング言語などが出てきていますが、SysMLのように全体を俯瞰してうまくバランスを把握しながら、ソフトやハードに振り分けるという上からの流れが定着するような活動が展開できると嬉しいんですが。

現場では難しいですね。組込み開発の現場では、ソフトウェアは士農工商の商ぐらいなんです。良い手法はソフトウェアの領域で発達しているんですね。でも、ソフト屋さんがこういうやり方にしようと言っても絶対に上まで通って決裁されることがない。

そのへんの感覚は未だにそうなんですか。ソフトウェアの方が付加価値を高めるものだし、自動車に1000万行のコードが入っているという時代でもそうなんですか。

そうです。コピー機もほとんどはソフトですけど…

若いエンジニアの人もそういう意識を持っているんですか。

今の若い人は、メーカーの中でもソフトの中でしか暮らしていないので、ほとんどメカや物理現象で実験をやっている人とは会わないですね。

ソフトウェアの部門が一番予算をたくさん取れるようなことはないんですか。

結果的にはお金を使っています。人がたくさんかかっているので。

結果としてそういう風にしか見られないということですね。たくさんの人でやっているからお金がたくさん使われているということであって、その予算を有効活用して新しい手法を取り込もうとかいうことにはならないんですね。

ならないです。人をかけないとソフトウェアができないような現場の作りになっているので、「いっぱい予算を使ってけしからん」という感じになっていたりします。なんでソフトを作るのにそんなに要るのか、削減しろ、と言われていたり。ソフトウェアの問題は目に見えないので、他の分野の人には理解できないのかもしれませんね。そんなに時間がかかったり、「できる」と言いながらできない理由などが。メーカーの中では士農工商というのが依然として残っているケースが多くあって、ソフトウェアが問題児だという感じになっています。そんな問題児の言うことなんて聞いてくれなくて。経営層にソフト出身の人がいないケースが多いんだと思います。そういう人がお金や決定権を握って経営するというところまでいかないと変わらないのかもしれませんね。

それはモデリングの技術で解決できる課題ですか。

できないです。

「見える化」というか、モデルを通して全体を分かりやすく伝えるといった、技術的な解決はできないところですか。

難しいですね。会社の中の政治がどうしても絡むところなので。メーカーの中のソフトウェア屋さんはかわいそうですよね。

メカ屋さんとエレキ屋さんと要素技術開発の人がものを作って、最後に接着剤のようにソフトの人が帳尻合わせを労働集約的にやる、という、そんな感じですね。

先ほどの羽生田さんの質問に私が答えるとすると、若い人ほどスコープが狭いですね。ある程度の年代で今ソフトをやっている人は、メカで解決できないからソフトを勉強したのであって、メカも知っているわけです。でも、若い人はソフト専業でそれしかやらされていないので、本当に制御仕様書を渡されてそれを作るだけという感じになってしまっています。

逆にソフトウェアエンジニアとして活躍している人がハードについて勉強するような形がいいということですね。

はい、そうしないと同じ土俵で話ができません。

まさにSysMLなどについても、我々ソフトウェアエンジニアが取り組まなければならないということですね。

ただ、けっこう専門化してくるので、ソフトウェアで一杯一杯のエンジニアに電子回路の知識や力学工学まで入れろと言われても現実的に無理がありそうな気がします。本来なら、ソフトウェアとメカ/エレキの間をつないで情報を調停してくれるようなシステムエンジニアの役割の人が必要ですね。

技術通訳のように、モデルを使って動き回ってくれる人ですね。

そういう人が確立して、社長とかになってくれればいいんですけどね。

そこがすごく大事だと思いますね。決定権を持っている人にそういう発想をしてほしいです。

ちょうど一昨日、お客さんと話していたときに、まさにそういうシステムレベルのことを分かっている人がいないと言っていました。コンセプトがあって、それが一気に実現手段として広がってしまい、そこでまとめる人がいないので、ぐじゃぐじゃになってしまうと。それが出来上がってきて「違うよね」とやるのが、実はすり合わせなんだよ、と言われたんです。

「すり合わせ」といういい言葉でうまくいっていた時代はいいけれど、もう破綻しかけているので、そこはモデリングなり何なりでもう少し明示的に調停する仕組みを作っていかないと難しいですね。

そうですね。でも、ここで人事や経営の話を議論してもどうにもならないので、我々モデリング技術部会としてテクニカルな視点で解決する可能性についての議論に戻しましょう。

そういう視点だと、さっき皆川さんが言われたように、目的レベルのコンポーネントみたいなインターフェースを提案していけばよいということでしょうか。私がメーカーにいたときには、ソフトで泥臭い嫌なことがたくさんあって、オブジェクト指向を導入し始めました。ハードについては、多少の回路の勉強はしましたが、ほとんどは素人で、ただこういう目的レベルのハードウェアのユニットを作ってほしいんだとか、インターフェースをこう切りなおしてほしいんだという提案をしながらやっていました。ただ、所詮はいちエンジニアなので、組込み装置のシステム全体を直していくというのは、権力的な関係で難しい。そういうところを目的レベルで切り出していく活動ができないかなと考えています。

そういう提案で、ソフトウェアエンジニアの立場から最適に見えるものも、システム全体からすると歪みが出ているかもしれません。メカ/エレキ/ソフトを含めてバランスをちゃんと取って、このバランスの上だからこの口はこのようにした方がいいよというように、一度吸い上げた要望をまとめてバランス取りをして色々な部署に展開するような動きが絶対必要だと思うんです。私たちはソフトウェアエンジニアとして、ソフトウェアの立場からすると明らかにこういう口がいいよ、ソフトウェアの立場で最適なのはこうだよ、と言えるんですが、全体からそれが最適だとは言い切れない。というより、今それを言える人が誰もいないままにシステムを作っているんですよね。

話が飛んでしまうんですが、現場でお客さんが書いている上の人への提案を見る機会があります。やはり、まだまだエンジニアの目線から脱していないので、今言われたみたいな全体最適の話になっていないんです。そうすると、上の人もよく分からないことになってしまうので、その辺は大事ですよね。

先ほどの目的と手段で階層化するという話なんですが、ビューの問題だという気もするんです。目的が真ん中にあって、それに対してたとえば「制御」というのが1つのビューになります。解決策なんだけれども1つの大切なドメインの概念でもあるし、構造的なdiscreteのものだけでなくて、アナログで制御的な数式で表せるものとか、複数あって初めて分析的なモデルを表現できるんじゃないかなと思います。そういう、ビューや複数の視点などは必要ないんですか。UMLのモデルのクラス図やステートマシン図だけでいいんですか。

確かにそうかもしれません。離散系のところと連続系のところとはよく言われていますが、1つだけということではないと思います。

ちょっと外れるかもしれないんですが、モデルのレビューやテストの条件など、品質確保は非常に重要だと思うんですが、どうなんでしょうか。現在、自動車のブレーキ制御回りが問題になっていますが、組込みソフトは、全体的にどのように品質確保をしているんでしょうか。エンタープライズだとIPAなどが信頼性向上策を研究していると思うのですが。

ボトムアップで作り込んでいる割には劇的に信頼性が高いのが日本の製品だと思います。私が知っている限りでは、品質保証体制はすごくしっかりしていて、最終的なところで守っています。品質を織り込むというやり方がありますが、そこがうまく行っていないのかなと思います。最後に出すところで鬼のようにテストをしてそこで守っている姿なのかなと。すごくお金と時間をかけて、最終的には品質をよくしているという姿なんだと思うんです。

それを変えたいということで、SEPGの部隊などが障害の数や原因を分析して、できるだけ上流でつぶそうという活動をしていますよね。コードベースの開発では上流でのレビューをし辛かったんですが、モデルになるとやりやすくて、そこはモデルに移行することでよくなったところかと思います。ただそれでテストの時間が減るかというと、あまり減っていないのですが。

エンタープライズではシステムテスト、総合テストなどとあるんですが、組込みだとどうなるんですか。

似たような感じです。自分の担当しているモジュールのテストは自分でやって、それを結合して、現場にいるテスターの人たちが設計内のテストをするんですね。それをクリアしたら次にQAの部門に出してテストをします。

シミュレーションですか。

実機です。実際のものを使って、人と時間をかけてテストを延々とやっている状況です。

よく「V字プロセス」というじゃないですか。あれは組込みソフトの現場ではすごく定着しています。信頼性はとても大事なので、検証は相当やっています。ただ、お金と時間がかかってしまうので、この先同じでいいのかという話になってくると思いますが。

先ほどのセミナーの話でも気になったのですが、モデルを良くしたからといって、何がどう良くなるのか、というところをみんな疑問に思うのではありませんか。その辺はどのようにお考えですか。モデルが良くなったら何が良くなるんでしょうか。

一番大きなのは保守性かと思います。長く使えるモデルを作ることが大事です。見渡せて、変更箇所が早く特定できるモデルを。組込みのソフトウェアはやはり長い時間使うものです。一回作ると10年くらい維持して、その間にそれを使ってたくさんの製品を出していくので、そこで良いモデルを書くのはすごく有効だと思いますね。それが直接ソフトウェアの品質とどうつながっていって、どんな相関があるかというと、ちゃんと調べないと分からないと思うんですけど。

エンタープライズ系は保守性/拡張性がすごく大事だというのはよく分かるんですね。ただ、今回問題があったとおり、組込みでは色々と関わるところが多くて、むしろ信頼性とか性能とかが重要ではないでしょうか。保守性はベンダーの立場のメリットなんだけど、もっと使う側の信頼性の方が大事なのかなという気もするんですが。

立場によって違いますね。もちろん製品としては信頼性や性能が大事なんですけど、ソフトウェアのエンジニアにとっては、自分が保守していく、あるいは人から受け継いでいくという観点で、同じように保守性などにも目を向けていかないと、プロジェクトが破綻したり大変な状況になり、性能や信頼性を出す以前に自分の仕事がおぼつかないということになります。組込みのソフトウェアには、ソフトウェアだけで実現しているものと、そうじゃない、アルゴリズム的にやっちゃっているところがあるので、少なくともロジックのところは長く使えるようにしておきたいです。実験的なとこに振られるところももちろんモデル化して意味があると思うんですけど、そこはライフサイクルが違うと思うんですね。たとえば今モデルカタログで孔版印刷のモデルをやっているんですが、電子写真とは制御の仕方がまったく違うんです。だけど、原稿から読み取ってそれを紙に出すという目的は共通です。レイヤによって重視するところはまったく違っていて、モデリングがとても役立つ部分があります。最初の河合さんの話に戻りますが、自然現象を相手にするところとそうでないところとで、モデリングの使われ方やモデルの果たすべき役割は違うかもしれませんね。

信頼性や効率性は、ないと製品が成り立たないので必須なんです。でも、じゃあ作りはいい加減でいいかというとそうではない。今までは人とお金をかけてジャブジャブ作っていればきっとよかったんですよ。ただ、ご存知のように今こういう状況になってきて、やっぱりそんなに高いものは誰も買ってくれないという状況になっているので、これからは作り方が問われるようになります。特にインドや中国みたいなところに売っていこうという話になると、どうやって安く作るかという話に変わっていくので、そうなったときにソフトは大々的に見直しが入るところなのかと思います。

逆に言うと、もともと必要だった信頼性や性能に関する、エンタープライズ系とは違ったテクニックというのはもちろんあって…

それはあります。

それは前提になった上で、今は次のステップについてお話を頂いたということですね。

そうです。

それから、これは最初に聞くべきだったんですが、組込みという分野はリアルタイムシステムの一部と考えればいいんですか。たとえばエレベータ制御でもいいし、上下水道監視でもいいし、電力系統でもいいんですけど、大規模な監視制御の分野はリアルタイムでやりますよね。極端な話、株の銘柄の値段とトレンドの表示だってリアルタイムシステムなわけです。そういう括りの一部として組込みという分野を考えればいいんですか。大規模監視制御と組込みシステムの作り方の違いは何かあるんでしょうか。

あまりデカいシステムのことを組込みシステムとは何となく呼んでいない気がするんですが…

量産されるというのは大きいと思います。量産されるためにハードのスペックは限られるし、一旦市場に出回ってしまったら取り返してバグを直すわけにはいかない。そういう制約を意識して作るというのは1つの非常に大きい特徴だと思います。

より制約の厳しい世界での開発ということですか。

独特の制約といったらいいんでしょうか。

あと、汎用の環境じゃないというのもあります。何でも後で追加できるわけではなく、組み込まれた機器で、あらかじめこういう入力とこういう出力があるというような制限が多い中で、その組み合わせをやっていくわけです。

CPUという言い方ではなく、ECUという言い方だと、センサーだとかモーターに対する昇圧機のようなものも入ってしまうので、そういう意味ではまさにそうなります。でも、CPUとメモリの状態だけ見ると同じですよね。

でもジェネラルじゃないですよね。

確かにパソコンとECUという比較の仕方をすると、それ専用のハードになってしまうということですね。

そのバリエーションがやたらと多いというのが組込み系の特徴の1つだと思います。

リアルタイムで、実時間で制御しなければいけないという制約は、やっぱり厳しいと思うんですが、そのための作り方みたいなものはあるんですか。

ありますね。

それはもともとあって、それも今日は前提の話なんですか。

それはどちらかというとソフトウェアとしてどう実現するかという世界の話なので、そこは今日は置いておいて、という感じです。

逆に今日の話はけっこうエンタープライズ系でも使えるように思いました。

そうだと思います。ただ、組込みはモノが見えてしまうだけに、どうしてもそこに吸い寄せられます。さっき皆川さんも、このサンプル問題は結構工夫しているんですとおっしゃっていて、そうだと思うんですけど、やっぱり同じ物理的な名前にしちゃうと、そういうもんだと寄せられがちなんです。それは明確なやりにくさですね。抽象化をあえてさせないような感じになりがちです。

surrogationというのがありますね。実際の物理プリンタをコンピュータの世界の中に抽象プリンタとしてsurrogationしましょうと。それじゃいけないということを言われているんですか。

そうです。

物理的なそのものの姿じゃいけないんですか。ある程度、ある基準でもうちょっと抽象レベルを上げたり変形したりという加工が必要で、それが分析なんですか。

そうですね。

リアルタイム性と組込みという関わりでいうと、部外者から見ると携帯なんかはリアルタイム性が要求される部分とされない部分があって、そういう切り口だけじゃ組込みは考えられないんじゃないかと思います。

もっと色々な制約がある世界ですか。

傍観者的にはそういう世界じゃないかと思うんですが。

ビジネス系のアプリケーションでも株の場合にはリアルタイム性があるわけだから、ある程度直交する概念じゃないですかね。ただ、今日のお話に関して言うと、さっき山城さんも言われたように、ビジネス系のモデリングでも十分そういうことを意識してモデリングするべきだというのと同じですよね。

2年前の第1回のこのワークショップで児玉さんに話していただいたんですが、児玉さんがまさにそういうレベル分けの気持ち悪さというものをずっとワークショップで話されていました。今日はその1つの切り口について書いていただいたということで、モデリングという観点ではつながっているんだなと感じながら聞いていました。

それでは引き続き、議案に沿って進めていきます。講師とモデリングという項目は既にお話しいただきましたので、講師の考える現状のモデリング技術の問題点について伺いたいと思います。

やっぱり「モデリングは難しい!」という点ですね。特にUMLはクラス図とインスタンス図の世界があって、クラス図にいくところがどうしても難しい。そこそこ厳密にするためには記法もそこそこ書かないといけません。本当は問題をもうちょっと整理したいだけなのに、あそこまで難しい書き方を覚えないといけないというのが、モデリングをソフト屋さんに押しとどめている感じです。本当はシステム屋さんにモデル化してもらいたいわけですよ。それなのに、UMLはソフト屋さん向けになっているし、SysMLでもあれだけ難しくなっているので、色々な分野を経験してちょっとマネジメントもするくらいの人が、気軽に自分の領域をモデル化しましょうと思ってもできません。そういう妙に小難しいところに留まっているUMLを始めとしたモデリングの世界がダメなんじゃないかと。何とかもっと簡単に何かできないの?と思います。

じゃあそれに答えるために何があるかというと、世の中のおじさんがよく言うポンチ絵というやつなのですが、人によってポンチ絵のレベルがまったく違ってよく分からない。僕も含めておじさんはみんなポンチ絵が大好きで、何かというとポンチ絵を書きましょうと言うんですが、ポンチ絵じゃ粗すぎる、でもUMLだと細かすぎる…

それは粗さの問題なんですか。フォーカスというか、今日おっしゃった適切な視点の設定ができていない問題なんじゃないかとも思いますが。

かもしれません。ただ、とりあえず書き方のレベルで言うとUMLの今のインスタンス図クラス図ありきのレベルで、もう「えっ」という感じです。そこを埋めたくないですか?

それは書き方の問題というより概念の整理のところでそもそも躓いているんじゃないですか。

両方あるんじゃないですか。整理もあるし、やっぱり表現の仕方が複雑すぎちゃって…

文法が複雑だというのは納得なんだけど、インスタンスとクラスを区別するのが問題だとおっしゃっているんですよね。

そうです。そこすらも区別しなくてもいいんじゃないかという気すらします。

それはかなり危険ですね。

知っていて区別しないのと、区別が分からないのとでは、かなり次元が違いますよね。

ただ、いきなりそこに行けというのはすごくハードルが高い気がするんです。もうちょっと中間があってもいいんじゃないかと。

小学校の教育からそういう概念をちょっとずつ入れていって、最初からそういう概念が身についていれば、意識しないでもいけるんじゃないですか。私たちは途中からそういう風にシフトしてきたという経緯があるから、昔の根が残っちゃってるんじゃないかと思うんです。

大学で講義していてアンケートを取ったんですが、クラス図から入ってオブジェクト図を教えると、オブジェクトから説明してほしかったというコメントが来たりするんです。クラス図で結構躓いていますね。

そういう意味で言うと、オブジェクト図から入るのではダメなんですか。それだと面倒臭すぎるんですか。

そうなんです。たとえば、概念も実体も箱でいいじゃないかと。

でもその段階でポンチ絵になっちゃいますよね。

でも、ポンチ絵にちょっと毛が生えたものを…

ルールがあるポンチ絵…

そうそう、ルールがあるポンチ絵! まずポンチ絵に寄っていかないと、みんな集まってきませんよね。

たとえばHaskellとか、形式仕様記述言語で、システム側が勝手に「あなたが今言っているのはインスタンスね」とか「型のことね」とかって推論してくれる環境とセットならいけるという気がしますが、辛いですね。

でも、クラスやインスタンスという前に、図解でうまく書ける人はモデリングをしてもうまくできると思うんです。だから、もう少しルールがある図解ですね。図解した時点でクラスとかインスタンスとか分けて書いてないじゃないですか。

確かによく分かるポンチ絵の場合は、概念レベルの全体像が提示されつつ、ところどころに「具体例だとこうだよ」ってのが絵になっていたりするんですよね。そういう意味で、ちゃんと区別はついているんだけど、読み取る人にとってはその違いを意識させないということですよね。

人間の推論法で、帰納法、演繹法、abductionなどがありますね。人によってそのどれが得意とか癖とかが明らかにあり、それによりモデルの理解力に差が出ているような気がしています。帰納法ではオブジェクトという具体例を考えてからクラスを考えますし、演繹法はルールありきでクラスが先にあって、そこからオブジェクトを抽出していきます。この辺りを意識してそれぞれを訓練しておかないと、そもそもできる人とできない人が分かれてしまうという気がするんですけどね。

みんながすべてをできる必要はないような気がしますが。

ただ、メカ屋さんとかエレキ屋さんにソフトウェアの今のいい手法を使ってもらうには、もう少し歩み寄ってもいいのかなと思いますけどね。ソフト屋さんだけができるものじゃなくて、みんなが同じルールに則って考えを整理して、それを元にディスカッションできるという、そこに行ってもいい気がします。

動物将棋というのをご存知ですか。ライオンとキリンとゾウのように駒が3つか4つしかなくて、本当の将棋の基本的なルールしか使えません。いきなりあの難しい将棋のルールではなくて、そのエッセンスだけを使った子供用の将棋なんです。そこまでとは言いませんが、そういう…

UMLよりももうちょっとシンプルにした…

そうです、そうです。

それは重要なんじゃないですか。

動物UML…(一同笑)。動物にする必要はないんですけど、なんかちょっとそういう…

UMLにあんなにたくさんダイアグラムは要りませんよね。

そうなんですよ。たぶん、ここにいらっしゃる方はUMLとして統一される前の方法論をやっていた人が結構いると思うんですけど、以前はあんなにいっぱい表現がなかったじゃないですか。統合して色々なことに対応しようとしたから、あんなに複雑になってしまった。昔からやっている人は割とシンプルなオブジェクト指向の考え方とか表現方法に則ってやっていたから、割とスムーズに入ってこれたと思うんですけど、今はUMLの表記法を覚えないとモデルが書けないし、色々なルールがありすぎて手が動きづらいのがハードルになっている気がするんです。本当にこれとこれだけを使って、自分の考えていることを整理して表現するとか、そこをうまくできるようになってから、表現の足りないところを徐々に覚えていくといいと思います。今の試験や資格も、まず表記法がレベル1じゃないですか。入り口がそっちに寄っているのかという気がするんですね。

モデリングのおいしさが見えない。

逆に受ける側からすると、ああいうのが一番トライしやすいと思います。暗記して取ればいいわけですから。概念的なものを確認するのが最初の敷居としてあったら、もっと受験者が減っちゃうかなと思います。

減っちゃうでしょうね。モデリングができるようになるというのと、広めていくためにどうするか、というのはまた別かなと思います。でも、違う入り口があってもいいのかなと思います。

ソフト屋さん以外にもうちょっとモデリングを広げていかないと。特に組込みではソフトウェアだけがワイワイその中で言ってても、何かどうも…という感じですから。

UMLをいつもフルセットで使う必要がないというのは、ここにいる人はみんな分かっていると思うんですが、逆に足りないことはありませんか。UMLだと、こういうことは書けない、というものは。たとえば、UMLのステートマシン図ではイベントのキューなどが書けませんが、組込みのモデリングをするときに、困りませんか。

どこまでモデルで書きたいかによりますよね。そこは人やプロセスによります。モデルを本当に動かしてMDDみたいにしないとダメなのなら、あれば嬉しいでしょうし、逆にモデルは最初の状況の理解と整理整頓と、今後のコンセプト方針でいい、というのなら、特に要らないと思うんですね。そこはまちまち…

ですね。私はさっきも言ったようにシュレイアー・メラーから入ったので、そういうところは全然モデルとは違うところで解決していたんです。そこはベタで書いてしまっていいと。

UMLという表現方法ではない方法で…

はい。モデルで表現する目的などのところと、キューを使ったりしてソフトウェアで実現するテクニカルな構造などとは切り離します。私が昔シュレイアー・メラーでやっていたときは、MDDなどで言う繰り返し使えるところをモデリングしていないんです。

プログラミングでいいと。

あんまり細かくやっちゃうと、DSL[Domain-Specific Language: ドメイン固有言語]みたいな世界になってしまうので、そこはDSLでいいのかと思います。ただ、現場で見ていると、タイミング図はすごく便利なようです。確かにあれとステートチャートを組み合わると、イベントドリブンのものの動きは分かりやすくなりますね。今日紹介したETロボコンのロボットのモデルを、最近そういうアプローチで書いてくる人がいるんですが、すごく動き方が明快です。かといって、あれが絶対でなきゃいけないのかというと、それはまた別ですが。

最初、Booch法にはあったけど、消されちゃったやつですよね。

そうですね。

UMLになるときに入らなかったんです。

非機能要件がUMLでは表しづらいですよね。SysMLとかで出ているRequirement図などをUMLにフィードバックしてほしいなと思うんです。あと、要件と、その要件に依存するもののトレースの関係とかは、ちゃんと書けないとやりにくいので、自分たちで工夫して関係を付けたりせざるを得ないですし。

でも、非機能要求はそんなに根本的に書けるようになっているわけでもないですよね。

書ける書けないは本当はあまり問題じゃなくて、要求と呼ばれている単位と…

要求を明示的に管理するモデル要素がほしいということですね。

その通りです。モデル要素と紐付けた形で、ここが変わったらどれが紐付いていて、というのが引っ張れる環境がほしいです。

ユースケースだけの時はすごく気持ち悪い思いをしながら自分流にカスタマイズをして、俺流ユースケースでやっていたものが、なんとなくあれで公認されたみたいな感じですよね。

あと、さらに言うと、要求を引き出すためのもう一歩前のところから本当はトレースできるといいのかなと思います。たとえばfault tree analysisでは、フォルトの分析やハザード分析の結果をfault treeのような形で別の文書として別のところで管理したりします。拡張プロファイルでいいので、そういうのが組み込めて一緒に管理できると嬉しいかと思います。

それはできる人にとっては嬉しいですけど、最初からそれがうわっと来たら、たぶん…

コアのこの部分がミニマルセットで、ここをおさえたら次はこういうのがあるよ、という流れがいいですね。

話が戻りますが、どんどん守備範囲が増えていくじゃないですか。だからそれに応じて少し凝縮したやつをシンプル版として作成すると広がる気がするんです。今は横にだけ広がっていくので、もうちょっと上に、削いで削いでシンプルにしていく道も面白いのかなと思います。

UMLのメインは図ですけれど、モデルの表現として、箇条書きとか表とかではダメなんですか。組込みでは”何とか表”のようなものをよく見るので、そういうのも慣れているのかなと思うのですが。

そうですね。表だと網羅感がすごくあるんです。この中ですべての組み合わせが明快になっている、みたいな。ただ、ゴールデンパスが全然分かりません。

抜け漏れがないことに関してはいいんですけどね。

何が本質かはまったく分からない。

優先度が付かないと。なるほど。

状態イベント表はほしいですよね。ステートマシン図から自動的にツールが作ってくれるといいんですが。

技術的な話になりますが、ステートマシン図と状態遷移表とは、まさに2つセットですよね。分析はステートマシン図、設計実装は抜け漏れなく、という。

組込み屋さんだと、状態遷移表から先に書く人も結構いますね。

State transition matrix(STM)ですね。実際に表の形で組み込まれていたりするんですか。

あれは実装パターンも決まっているので、全部テーブルにしてビャーッと入っちゃうんです。

モデル化したテーブルに割と近い…同じ動きが実現できるということですか。

あれがテーブルとして組み込まれると、まさに今日言った「動いたもの＝モデル」なんです。

根拠が見えないという…

根拠は分からないけどこのイベントが入るとここに飛びなさいと書いてある。それで、そうすると確かに動く。で、改造しろと言われるとどこをいじっていいか分からないんですね。

だからやっぱり、表だけではだめで、ペアでないと、ということなんですね。

では、議案に戻りまして、モデリング原論の項目にいきます。モデリングの方法論についてはどのようにお考えでしょうか。

方法論ですか…

さっきの講演の最後のスライドが方法論になるのかなと思いますが。

図4 組込みソフトウェアの開発手順の一例

そうですね、そこは組込みでは必須ですね。

先行調査に降りて、また戻っていくという…

トップダウンでかつボトムアップも入れて。

でもあれは組込みだけではないですよね。アーキテクチャを設計するのに、今までにない技術を使わなければならないようになったら、同じですよね。

組込みではそういうシチュエーションが非常に多いんです。

eUML[『組み込みUML : eUMLによるオブジェクト指向組み込みシステム開発』]というのをやられていたじゃないですか。あれから今回のものはどう進化/変化してきたのでしょうか。

レイヤリングの話は一緒です。

たしか、最上位層がアプリケーションですか。

そうです。あそこがいわゆる目的のところです。

それを構成しなおしたということですか。

そうですね。だから僕としては同じ感じと考えています。

組込み分野の人はあの本で勉強された方が多いと思うので、本で記述されて　いることとの関係は重要かと思うんですが。

あの時はあそこを「アプリケーション」と呼んでいたんですが、それが何を言っているかよく分からないという話を聞きました。アプリケーションとメカニズムという言い方ではうまく伝わらず、目的と手段の方が通じやすいようなので最近はそう言っています。

アプリケーションの中に目的の部分とスペックの部分が少し入っていたんですか。

そこまではあの段階では分けないで考えていました。

さっきの、システム屋さんとソフトウェア屋さんの間で共通理解できるモデルができないか、という話ですが、何を目的としてモデリングするかがはっきりしないからモデルが定まらないんじゃないかなと思います。ソフトウェア屋さんはソフトウェアの、たとえば多重度とかクラス間の関係とかが大事だと思い、問題領域によってどんな関係があるかを理解したいという目的でクラス図を作るんだけど、ハードウェア屋さんとソフトウェア屋さんの間で何を共有すべきか、表現すべきかという点はどうなんでしょう。

そうですね。そこはとても大事だと思います。どういう抽象度で何を関心にしたいのかによって、モデルももうちょっと「ここまで複雑じゃないといけない」「ここのレベルで話すなら多重度は要らない」みたいな指標があるといいかもしれないですね。

では次に、モデリングの原理、原則、パターンについてはどのようにお考えでしょうか。

すごくいいものが世の中に結構あって、それをマスターするというのはもちろん大事なことだと思います。でも、原理原則パターンというのは、目的の下に位置付けられると思うので、そことの切り分けを理解しないでパターンを中心にモデリングするとよくないですね。いいものを見て、原理原則、本質のところを理解していくのには役に立つので、あればいいのですが、だからといって、ここから始まるといいモデルにはならないので困っちゃいますね。

組込み独自のモデリング原則などはあると思いますか。

あると思います。パターンに近いものをカタログとして出そうとしているんですが、自分のところで「このコアのところは使えるね」という見本はあった方がいい。組込みではあまり外にモデルが出ませんが、パターンぐらいは出していけると思います。

あるドメインで典型的によく使われる構造という意味でのパターンはあると思うんですが、アナリシスパターンだとかビジネス系で今まで出てきたパターン、つまり、ある程度抽象化された構造と比べたときに、「組込みだから新しくこういう構造がどうしても必要なんですよ」「今までこれはビジネス系では見落とされていましたよね」というようなものが出てくる可能性を感じていますか。やってみないと分からないでしょうか。

そうですね。組込みというよりリアルタイム系だと、タスクの色々なやり方とかのバリエーションで何か組めると思うんですけど。

さっきの講演の中の機能分解とかの話で、目的/制御/物理と階層分けするというのも1つの原則なんですよね。あれは原則を語っていただいたんじゃないかと思うんですが。

原理や原則も、結構名前だけが広がっちゃって、本質がよく分かってないで使われているというのをよく見かけます。できるならコーディングスタンダードのように、ルールとその根拠となる事例が一緒になって、原理原則スタンダードみたいなものにまとまっていると嬉しいかと思います。たとえば、オブジェクト指向では情報隠蔽をしますが、情報隠蔽というのはクラスの中のプロパティだけを外に見せないようにすることだと考えている人が多いんです。でも、実際にはそのクラスから先にいる他のオブジェクトの構造も含めて全部見せないようにする、というのが本来の情報隠蔽です。そういう認識のずれが多い気がします。色々な会社に行って、毎回同じようなことを言っているなと思うんです。その辺をもうちょっと一般常識的に広げるようなシナリオがほしいですね。

そのうち誰か出そうと思ってる方はいらっしゃらないですか。

まさにUMTPがそういう役割を担わないといけませんね。今は本の数も多く、それぞれ作法が異なると、書いている内容も違っています。どれも書かれている内容が間違っているわけではないが、読者にとって、著者の前提というか問題意識が分からないと、互いに矛盾することを述べている、と感じる部分もあると思うんです。勉強する人にとってはそこが困ってしまうところですね。

自分なりのモデリングとか自分なりのオブジェクト指向を、勉強している人はみんな持っているかもしれませんね。それなりにいいのかもしれませんが、宗派が違う人と喧々諤々になってしまいますね。

技術部会の体系化で、そのあたりを含めてやりたいですね。

その意味では、UMTPの試験は宗派の統一に一役買っているのではないでしょうか。

ある程度の認識の方向性は合わせていますね。

統一するとそれじゃ物足りないという意見も聞きますね。「こういう考え方も」というのが拾いにくくなりますので。一筋縄ではいきませんね。難しいですね。

では次に進みます。プロセスとモデリングという項目で、要求のモデリングはどう行うべきかを教えてください。

要求は単純に機能分割でいいのかなと思っています。ユースケースの時は分割がいいのか悪いのかよく分からないという話がありましたが、SysMLとかフィーチャーモデルでは明確に分割してレイヤリングしましょうと言っていて、すごく分かりやすくなりましたね。

逆に目的を明確にするという意味で言うと、ユースケースであってもフィーチャーであっても、きちっとアプリケーションのドメインの目的が…

結局何なの、というところですよね。多分、機能を出す前の要求と、機能や詳細の機能とを、うまくマッピングできればいいのかなと思います。

「組込みソフトウェアの開発手順の一例」のスライドの先行調査と要求の関係ですが、先行調査の前後で要求は全然考慮しないんですか。

あそこでは、要求と非機能要求から先行調査に入る矢印にはなっているので、考慮します。ただ、さらに早い時点で行う先行調査などだと、まったく関係のないこともあります。

では次に、分析と設計の関係をどう捉えていらっしゃいますか。先ほどの図では分析があって設計という形になっていましたが。

シュレイアー・メラーでいうと、分析モデルを置換、変換してソフトウェアの形にするので、完全に領域、世界が違うと考えています。

ソフトウェアの領域ということですよね、設計は。

そうです。問題をモデリングするというところと、ソフトウェアとしてどう実現していくかというところの、得意な人とそうでない人の適性があると思うんですね。シュレイアー・メラーの時には完全にそうで、マッピングのところを作る人はソフトウェアをすごくよく知っていて、メカニズムなどの開発ができる人であり、アプリケーションの分析のところをやる人は、状況をきちんと整理してそれを色々なビューを使って図式化していくことができる人です。シュレイアー・メラーではそもそも担当も適性も違うとされています。そこを切り分けて考えてモデリングするというのが今は大事なのかと思います。

ただ、先ほどお見せしたプロセス図の要素技術というか先行開発のところは、プログラミングしながら動かしたりもするので、そこの実装をどう捉えるかは難しくなりますね。今彼女が言ったのは、分析設計でいう設計の話なんですけど、同じプログラミングでも…

切り離せないところがあるっていうことです。

分析の中でのプログラミング、先行調査ですね。

そうです。置換でできるところと、そうじゃないところがあるということです。

先行調査の中で試行的なプログラミングをする、パイロットのようなものを作ってしまうということですか。

はい。そこでは置換している人はいないので、みんなグアーッと手でやっちゃったりします。

その場合、ハードとのすり合わせはどこでやるんですか。

ハードとのすり合わせは先行開発の中でやります。

基本的には分析モデルの構造をベースにして設計モデルに行くんだから、設計モデルは分析モデルと似たような形になるという認識ですよね。たまに現場で、分析っぽいモデルを書いているんだけど、設計モデルになるといきなり構造が全然違っているというのを見るんですが…。

芳村さんのお話では、似ているとかではなく、ドメインが追加されてリンクが張られていって、分析モデルの情報を使って設計で追加されたドメインの中でグリグリやるという感じじゃないんですか。

実際にはカラーリング作業というのがあって、ここではこういうメカニズムを使いますよというのをカラーリングというかチョイスしていくんですね。色々な中から今回はこういう理由でこれを選びますというのを。コアの分析の部分は明確になっていて、それに付随する設計を実現するための仕組み、たとえば依存関係を一方向にするための仕組みなどは、周りに出てくるという感じですね。

理想論で言うと、分析モデルで1個のクラス図があったら、そのクラス図と同じ形で実装できるのが一番理想なんですが、実際は色々なパフォーマンスの話だとか並行性とかが入ってくるので、変形だとか崩れが出てくるんですね。

ブリッジの話ですか。

ブリッジと、下で調整すべきことですね。パフォーマンスの問題は完全に設計のところでやるので。

最初に説明があった、目的/手段/デバイスでカテゴリ分けするあの構造というのは、要求分析の構造なんですか。

要求分析というか、分析モデルですね。

ということは、その構造と1:1にマッピングできる設計モデルがあるということですか。

基本はそうだけど、設計で追加されるドメインがいくつか出てくるでしょう、と私は理解したんですけど。

そうすると、目的/手段/物理デバイスの構造は生きたまま…

残る。

そこは上、つまり分析の話ですね。

横に出るんですよね。左の部分は独立しています。右のものは左のものを完全に知っている代わりにすごくベタベタ、でも、左はきれいなままにしますよ、という世界を横に付けてあげるんです。

図5 ホワイトボードより

付けたものは使われるんではなくドライブする側なんですね。

そうです。左の3つをドライブする。右の部分が製品に完全に特化する感じになるんです。

分析モデルの方は、どんな設計モデルにいじられているかは一切知らなくて…

ある意味、きれいなままで。

そうですね。そこは問題が違うので、分けてモデリングします。分析では分析の問題をモデリングするべきだと思いますね。

問題を整理することは大事ですけど、ソフトウェアだから目的の動きがあるはずで、その動きが左側に表現できていないといけないんですか。手段というか制御があるから表現されているのか。

「動き」とはどういう意味で言っていますか。

機能として作り上げたシステムが本来果たすべき動きというのがあるはずで、それが実現できないと、いくらきれいな分析モデルがあったとしても構造を整理したというだけになってしまいますよね。

目的というところは構造を表しているわけではないから…

目的の中に振舞いもあります。

なるほど、わかりました。

構造も振舞いも同じように詳細化されていきます。

では続きまして、アーキテクチャ設計のモデリングはどう行うべきでしょうか。

組込みでは、非機能要求の制約にどう応えるかというところが重要かと思って今までやってきました。分析は問題の整理整頓のようなものですが、アーキテクチャの構築という話になると、制約も含めて考える必要があります。一番グレーな、ソフトウェア領域でもありつつドメインも知りつつという、システム屋さんの領域なんでしょうか。

そうですね。ここはやっぱりすごく難しいです。知っていなきゃいけない範囲も広いし、整理していくのも結構難しいので、いいやり方が定着してほしいですね。今、本命のやり方というのはなくて、アーキテクチャパターンを参考にみんな独自にやっているし、表記法も結構独自なのかなという気がします。UTMPでもスキル定義をしたりしていますが、アーキテクトという人自体がまだモヤモヤっとしていますし、やり方もモヤモヤっとしているので、人材育成の面でもシステムを作っていく上でも、問題だと思いますね。

実際には、通信のメカニズムや同期/非同期という話を考慮して、タスクを分割するということなんですか。

そうですね。以前にプロセスをちょっとまとめたときは、ノードの設計をどうするのか、つまり分散させるのかどうかという話と、1つのノードの中でどういうモジュール構成にするのかという話と、あとはモジュール同士を並行に動かすかどうか、という3つの作業としてやるべきじゃないかと提言しました。それは分析でもないし設計でもない、全体に関わることかなと思っています。

ノードというのは?

その機能をいくつのCPUに分散させて実現するか、という、そのCPUが1つのノードです。

OCLや形式手法とモデリングの関係はどうお考えでしょうか。

厳密にするならOCLや形式手法もアリだと思うんですが、現場とやっている感じでいうと、どうしても難しくて困ります。逆に、みなさんがどう教えているか、活用しているかという話をお聞きしたいです。

お互いに相手に聞きたいという(一同笑)

吉田さんと話すとよく「OCLで」とおっしゃっているので、結構皆さん使われているのかなと思っていました。

それぞれによると思います。我々のところでは制約は全部日本語です。

富士ゼロックスさんは、複合機の開発などで結構形式手法を使っていると聞きますよね。生産性も品質も上がったという話を。

自動車などでは、次の課題として形式手法を意識しているんと聞くんですけど。

そうですね。機能安全などになると、やらざるを得なくなるのだと思います。ただそれが形式手法とどうつながってくるかはあまりよく分かっていません。

先ほどの分析モデル設計モデルという分け方で言うと、分析モデルをUMLで、設計モデルを形式手法で、というようなことを言っている人がいる割には、実際にやっている例はあまり聞きません。それと、どうつなぐかも見えない。

両方に明るい人があまりいないからじゃないですか。形式手法だと、やはり品質とか信頼性の方に重きを置いていますよね。その意味では組込み分野に適しているのでしょうけど。

簡単に言うとフルパスを通っているかどうか、というような、形式手法で書くと「この場合は」と言った場合に対して「そうじゃない場合」の漏れが分かりやすいというところから、機能安全につながってくると思うんですけど、それだととてもミクロな話になってしまいます。

ミクロな話の組み合わせを全部機械的にチェックしてくれるのはよさそうですね。というのも、モデルを書く人がOCLを喜んで書くようになるためには、OCLがちゃんと動いてそれで検証ができないと話にならないと思うんです。そういう環境が多分全然足りていないですね。

形式手法というとFeliCaという事例が必ず出てくるんですが、あれ以外には何かあるんですか。なぜあそこで事例が止まっているんでしょう。

すごく頑張ってあそこまで大規模にやったので、そこだけが突出しちゃっているんだと思います。

鉄道関係の会社なども興味を持たれていますね。

でも、小さな事例しかないですよね。

ソースコードと同じくらいの量のモデルを書くことになるので、信頼性とコストとの兼ね合いになりますよね。ミスをしたら膨大な損害賠償が発生するような分野ではそれだけ投資してもやるべきだという話になると思うんですが。

ただ最近お客さんの中で、「UMLのモデルは書いたけど、これって検証とかに使えないの?」という話が出てきてはいるので、何かもうちょっと分かりやすいメリットが出ると、ブレークするかも知れないですね。

モデル検査などは組込みでまだ普及してはいないんですか。

私の知っているところでは普及はしていませんが、UMLじゃなくて、Simulinkというブロック線図があります。これは、MathWorksが作っている、言語というより開発環境に近いものです。ブロック線図なので機能モデルなんですが、連続系の世界にすごくフィットしていて、モデルのシミュレーションもどんどんできるので…

そのモデル検査というのは、機能的なものですか。

シミュレーションで何かやりましょうという検査と、もうちょっと意味的にモデルを論理命題みたいな形にして検査しましょうという話の両方です。もともと高信頼性のドメインだというのもあるんでしょうけど、「機能安全」という形で、今後検討されていくみたいです。

では次に、MDAについてはどうお考えでしょうか。

ツールが高いですよね。あれがすごくハードルになっていると思います。

どこか、フリーで出してくれないですかね。

フリーなら皆使うと思いますか。

普及し始めるんじゃないかと思います。開発者の数が多いので、それだけツールを揃えるとなると相当しんどいかと思います。

ターゲットの環境がいっぱいあるから大変なんですね。ビジネス系だとその辺が割と揃っているので。

だからMDAなんでしょう? (一同笑)

そうですけど。ジレンマがありますよね、ツールを作る側からすると。ツールに吸収させているんだけど、コストアップになっちゃってオープンソースでもなかなかできない。

CIM、computation independent modelってありましたよね。あの扱いというのはどうなんですか。エンタープライズ系ではかなりあいまいなままで終わってしまっていますが、たとえば今回の話だと目的を表現するモデルとか、そういうレベルでのモデルに位置付けることはできるんですか。それともやっぱり、組込み系でもあいまいなモデルなんでしょうか。

CIMって言っている人は、ほとんど聞かない…

今はもう言わないですか?

今どころか、それが出た当初から、ほとんど言われてないと思います。

組込みであり得るとしたら、製品をどういう風に使うかとか、そういうレベルのモデルになると思うので、かなり難しいんじゃないですか。ビジネス系だとワークフローとかを考えられるんですけど。

シュレイアー・メラーだとそもそもそういう概念はないんですか。

シュレイアー・メラーだから、ということではないと思います。

どっちかというと、私はMDDには反対派なんです。プログラミングって楽しいじゃないですか。

だから、みなさん超上流プログラミングをやりましょうということじゃないの?

それがUMLみたいな図を頑張って書きましょうということなら、私は反対ですね。ただ今のプログラミング言語みたいに文字をたくさん書くのがいいかというと、そうでもない気もするので、その中間的な何かがあるといいですね。

ちなみに、さっき言ったSimulinkというやつは、見方を変えると完全なMDAなんです。モデルを書いて、そこからオートコードしてCの言語で実装されて動きます。だから、車の業界で言うと、制御屋さんといわれる、いわゆるプログラミングを全然知らない人が、あれでプログラムを作って動かしています。そういう、DSLとセットという話になっていくのが現実的なんじゃないでしょうか。

プラットフォームの違いはCに落とすから吸収されるということですか。

チップの違いまではやってくれてないのかな…

プラットフォームごとに変換ロジックを別々に用意するんでしょうね。

でもベンダーはすごくやってますけどね、実装のところを。

高いよね。

そこまでやっているから高いというのもあるかもしれません。

中途半端で隙があるとやらないですよね。本当にオールインワンになっていないと。

逆にそういう環境は今後も活用されていくんでしょうか。

車の業界を見ていると、すごく席巻している感じです。

逆に言うと、UMLとかでそういう環境が提供できていないということになりますよね、席巻できていないということは。

そうですね、できていないんですよ。

SysMLは、アクティビティ図とパラメトリック図というので、ほぼMATLAB Simulinkと同等のモデルを記述できるようになっているんですね。SysMLのツールベンダーは、自分達のツールでシミュレーションできますよ、あるいはオートコードの生成ができますよと、MATLAB Simulinkのシェアを何とか切り崩したいと思っているんじゃないかという節が見られるんです、SysMLの仕様を見てみると。だから、UMLにそういう話がフィードバックしてきてくれるのが嬉しいかどうかはちょっと微妙ですけど、システムレベルではありなのかなという気はします。

ちなみに、そのSimulinkというやつは、まずクラスとインスタンスを区別しないんです。クラスという概念がなくて、全部インスタンスでなんです。

そうじゃないとシミュレーションできないですもんね。

ただ、階層構造は作れます。階層は掘れて、とにかく1個1個が実体なんです。ビューは1つの側面しかなく、構造と振る舞いとが分かれていなくて、構造と線を引いてその通りに動くという、誰でも分かるものなんです。

でもモジュールと線を描かないと当然動かないんですよね。

そうです。ステートチャートのようなものはあるんですが、必須ではなくて。

誰にも書けるわけではないけど、ROOM法に似ていますね。ROOM法だと、カプセルがあって、全部インスタンスレベルでつないでいくという。

なるほど。

それで、そのカプセルを組み合わせた構造を作って、それをアーキテクチャとして再現するんです。

その代わり、きれいかというと、ほとんどスパゲッティの世界のモデルがいっぱいありますね。結局Cが絵になっただけじゃないかということになりかねません。

結局インスタンスレベルしか表現できないもの、要するに抽象的な考えを表現できないものは、はたしてモデルなのか?という点はどうですか。

あれはモデルだと思います。コードよりははるかに分かりやすいですよね。

そこは今日のセミナーのお話とは違うモデルですよね。

違います。

ただ、どっちもあるかもしれないということですね。

そうです。さっきのMDAという話で言うと、そこがとりあえずは圧倒的に成功しているわけです。

他にモデリングに関して現在注目されている技術トレンドはありますか。

機能安全などは1つのテーマとして挙がってきていますね。自動車業界だとISOの26262で決まっていて、それを守らなければならない。それをどう行うかということですね。プロセスは決まっているんですが、その中でエンジニアリングとしてどうすればいいかは、これからのような気がします。あと、ADLのようなアーキテクチャレベルのモデリングが必要だという話は、車関係を中心に言われています。

次に、モデリングの普及について伺います。現在、コンサルティングをされていますが、組込みで爆発的に普及させるために、どのようなことをお考えでしょうか。モデリングのために必要な素質/素養や、入門教育/モデリング導入教育などはいかがでしょうか。

さきほど「敷居を下げる」という話がありましたが、敷居を下げると、中学生くらいから入っていけるんじゃないかと思います。そうすると、企業に入るときには考え方が身に付いていることになります。教育ではどうしても「爆発的」にはならないと思うので、低年齢化や、こちらから敷居を下げるやり方になるんじゃないかと思います。

文科省に行かないとだめですよね。

それは違うんじゃないですか。

文科省ではたぶん、あまりいい方向に行かなくて、脳トレのようなスタイルのやり方が爆発的に…

じゃあゲーム業界とか…

iPhoneに載せるとか…

iPhoneのアプリをUMTPが売り出す。

学校とかで「今日の社会の授業はUMLで全部書くよ!」というようにやっていかないとだめですね。

毎朝、朝礼の前に5分モデリングとか。

それがあまり義務のようになってしまうとどうかなぁと思います。モデリングを楽しんでやって、経験というか、長くモデルをやってから会社に入ってくれるとすごく嬉しいです。モデリングの敷居を下げることですね。

とめはねモデリングとか。

陰山メソッドみたいな(笑)

モデリングのために必要な素質/素養や向き不向きみたいなものはあると思いますか。

あると思います。きちんとしたいというより、全体を知りたいという方が大事かと思います。

素質/素養というと「本来持っているもの」みたいな感じがしますが、私の経験からするとやはり、会社に入って長年細かいことを一生懸命やっていた経験が邪魔している気がします。子供などは大雑把に物を考えるじゃないですか。子供の頃からある程度考えを整理整頓して、それを表現してやっていくことに慣れてくれば、そんなに不向きな人というのはいないんじゃないかと私は思います。

大学生にモデリングを教えると、ソフトウェアを作った経験がある人はUMLを比較的理解してくれるんだけれど、ソフトウェアを作ったことがない人だと、モデル自身の意味がよく分からなくて、イメージも掴めないから、なかなか使えるようにならないんです。そのあたりに難しさがありますね。

大学生くらいまでのソフトウェアを作る経験というのは、会社で作るソフトウェアと全然違うじゃないですか。

そうなんですけど、Javaのプログラミングをちょっとでもやっていたら、クラスやインスタンスのイメージが湧くんです。でも、全然プログラミングをやっていなくて、コンピュータグラフィックとかをやっていたら、そういうことって想像つかないんですよね。そういう風に思考できないというか。

モデルが手で触れないとだめですよね、きっと。

確かにね。JavaとかC++ではなくて、何でクラスが3つの箱に分かれるのか、という理屈が分からないんですね。

社内教育とか新人教育でモデリングを教えるときには、UMLの文法から教えるんですか。それとも考え方から教えるんですか。

慣れることからやらせる感じです。だから、文法からは教えない。必要最小限に書かなきゃいけないクラスとかは教えますが、慣れさせるのが一番なのかなと思います。

それはサンプルなどを与えて書かせるんですか。

モデルを書かせるということです。それと合わせて、図解とかもやらせます。

図を見せて理解させるんですか。

そうではなく、ソフトウェアと関係ない世の中の状況とかを自分で図解して練習する、ということを、まったく別のトレーニングとしてやらせます。

プログラムとは全然別の図ですか。

はい。もちろんプログラムもやってもらうんですけど。モデリングについては、とにかく一通りまず経験することと、後はモデルを書くことに慣れていくことの両方が必要です。新人ではソフトウェアに落とすまでやったことがない人が結構いるので、そこも重要ですし、モデルにとにかく慣れていくことも重要ですね。

俯瞰的なすごく広い視点と、細かいところをきちんとやりますよという視点とを切り替えて移動できる人というのは、結構向いているような気がいます。

たぶん、下流は得意なのですが、上流ができない人が多いと思います。

藤井さんが言われたみたいに、確かに今のUMLでは、3つ書かせますよね。ソフトウェアをやっていた人じゃないと操作などは書きにくい。逆に、今日言った目的などをまとめようとすると、そんなところは逆に最初は要らなくて、箱だけでよかったりするので、それが邪魔しちゃうみたいなところもありますね。

あと1点、中級者以上の教育についてはどうでしょうか。あるところまではできるけれども、それ以上、もっと上のレベルに到達するための教育はいかがですか。

上のレベルとしては、人に指導ができるレベルになるというのが1つあります。それから、アーキテクトとして育っていくというのと、モデルをさらに上手に書けるようになるために経験を積むというのもそうですね。あとは教育というより横のつながりを増やしていくようなところを、私は前の会社ではやろうと思っていました。ある程度のレベルになると、教えられるというより人とコミュニケーションを取る、たとえばUMLとかそういう場でお互いに獲得していくというような、教育というより場を与えるとか、そういう…

コミュニティのような感じで、同じ言葉で議論できる仲間を…

ある程度まできているんだけど、最後の気付きを与える場ですね。

そうですね。

ちなみに、僕は今ETロボコンというのをやっているんですが、審査委員会というところでモデルを審査するんですね。最初はずっと審査委員会でやっていたんですが、去年などは400チームくらいになって、審査しきれないわけですよ。それで各地区に地区の審査委員会というのを作りまして、そこにまさにここでいう中級以上の興味ある方を組織化して審査してもらったんです。最初はちゃんとできるのか不安でしたが、実際には十分にできて、その人たちも色々なモデルを一気に大量に見るので、かなりスキルレベルが上がっていました。まさに今言われたことの実証版のようになっていますね。

そういう意味では、この技術セミナーは割と受け身なスタイルですが、L3レベルの人を集めているので、もう少し何かコアなディスカッションができるような場があってもいいのかなと思いますね。そういう場をUMTPが提供できるといいですね。

何かの題材でグループに分かれてモデリングセッションのような感じのを半日くらい、できれば温泉地で合宿しながらやるとかいうのがあると嬉しいですね。

モデルをゼロから作る機会って意外に少ないんですよね。だから、そういう機会があると嬉しいですね。

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

補足しますと、たとえば、こういう場合にはこういうやり方があるけれども、逆にこういう場合にはこういう風にやった方がいいよ、というようなものです。新規の案件にはこういう風やモデリングをしたらいいけれども、繰り返しやっているならこうすればいいよ、というような、見方というか切り口はあるんでしょうか、という設問です。

離散系と連続系だとフィットするモデリングの仕方が違ったりとかいうことですか。

たとえば、さっきのSimulinkを使って作る組込みシステムと、今回の目的/手段/デバイスで考えていくシステムだと、対象が違うんですか。それとも作る人が違うんですか。

対象は違わないですね。

適用する場所が違うみたいな感じですか。

場所というのは?

目的の部分はどんなシステムにも必要なんだけれども、その細かいところの動きを実際に手段として実現するところにSimulinkとかそういうのが挟み込まれてくるようなイメージです。

つまり、共存するということですか。

共存します。冒頭に藤井さんが言われた「色々なビューがあるんじゃないの」という話なのかもしれないですね。制御屋さんのビューとか。ただ、連続系と離散系は平行に言われることが多いのですが、個人的には、上流/下流というところでも連続系/離散系の方が何となく話が分かりやすいんじゃないかという気がしています。

上流が離散系で、ラフに見るということですか。

そうです。上流では、目的レベルのところをラフに離散系でばっと見て、この領域は連続系でやりましょうとか、ここはそのまま離散でやりましょうみたいなやり方です。

本当は下は連続なんだけど、「状態がここで変わる」みたいにして、イベントとかで上にあげてもらうとか。

そうですね。あとは、連続系で何を処理しているのかを概念レベルに持っていくことは、一部実践でもやっています。Simulinkのモデルで書かれたやつの目的レベルのものを、UMLで表現して整理をして、それからSimulinkに落とすと、Simulinkがきれいになるよね、というようなことです。

所詮は自然現象だから微分方程式だとか。

離散系に変換できるということですか。

だけど我々はもっとラフに記号にして無理やり区切りがあるように見せないと、理解しづらい。

組込みモデリング分科会とかで軸を分けてやっていますよね。あれも技術分野をマッピングする軸に使えそうな気がします。カタログを利用するときにはどういう局面があるかなどを検討しますよね。

では次に、UMTPの活動に関して、特に認定試験についてはどうお考えでしょうか。

狭くするよりは、母数を増やすのがいいですね。色々なレベルの人が気軽に取り組めるように。

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

組込みの業界ではどうでしょうか。

昔は本当にジャブジャブと人とお金を使って、とにかく質を上げようとしていましたが、それが通用しなくなってきています。経営面ではいち早く筋肉質になったとか言われていましたけど、多分、製造業も筋肉質になっていかないとだめな局面になってくると思うんですね。そうしたときに、今の開発スタイルは圧倒的に外注さんをたくさん抱えたやり方を前提としているので、そこで転換が来るんじゃないかと思います。早く来るといいんですけど。

車の業界の話ですが、JasParというところで、今までバラバラに作っていたソフトウェアを、これからは一緒に作りましょうというような記事が新聞に出ていたんですが、そういうところでもモデリングは考えられているんですか。

あれは割とプラットフォームレベルなので、直接モデリングというわけではないですね。ただ、車で言うと欧州ではAUTOSARで、Simulinkなどを前提としたモデルで作る枠組みが決められてはいます。そういう流れもありますね。

最後に、今後のモデリングの課題と将来像ということで、お奨めの本を挙げていただけるでしょうか。

古い本でシュレイアー・メラーのものなんですが、Leon Starrという人の『Executable UML実践入門』がいいですね。パターンが色々と入っている、白地に青い本です。モデルになる前の話が結構書かれています。アプリケーションノートと言っているんですが、仕様をちゃんと図解して、そこからモデルの要素を見つけていきましょうという考え方です。

洗濯のノウハウでいうと、洗剤や衣類をちゃんとスケッチして、その結果、洗剤というクラスが要るよね、衣類というクラスが要るよね、洗うという関係には色々な洗い方という属性があるね、みたいな導き方をしています。逆に、デバイスの話などは出てこないですね。

そうですね。とにかくルールを図式化して、それをモデリングしていきましょう、というものです。他にはない本ですね。プロセスとか具体的なモデリングで、ユースケースを作ってどうのこうのという本はたくさんあるんですけれども。

モデリングのお奨めという話で言えば、論理思考とか仮説思考とか、そういう思考系の本がビジネス書としてたくさん出ているじゃないですか。ああいう本でものを整理して考えるという方を学んだほうが、モデルにはいいんじゃないかと思います。

それと、我々2人が関わったモデリングエクササイズの本[『思考系UMLモデリング即効エクササイズ』]もどうでしょうか。身近なところからモデリングを積み重ねるという、モデ力本がお奨めです。

本当に最後になりますが、モデラーを目指す若いメンバーへ一言、お願いします。

仕事の中でモデルをやれる人とやれない人がいるでしょうが、やれなくても自分のために頑張ってモデリングしてもらいたいなと思います。いつかモデルで開発するときが絶対に来ると思うので、そのために頑張っておいてほしいですね。「会社の方向が全然モデルに行かないんだよねぇ」などとくさらないように。

モデリングはすぐにうまくはならないです。僕個人は、今日お話ししたように、あの悪いモデルを全部書きながら叩きあげられてきています。そのように、人によってはすごく時間がかかったりすると思うんですね。ですから、すぐに書けるとは思わない方がいい。後は、仕事の中でだけ書いていると、びっくりするくらいモデルを書く機会が少ないんです。特に製造業は新製品をあまり作らないので、本当に機会がないですから、書きたかったら練習しないとだめです。仕事が降ってきた時に書けないとその仕事はなくなるので、常に刀を研いでおかないといけない。そのためにモデリングエクササイズが必要だという思いがあってあの本を書いたんです。機会がないので、練習しないと書けません。

それからもう1つ。ソフトウェア屋さんも製造業の人もそうなんですが、「うまくなりたい」と思うとそこだけに集中してしまって、雑音を遮断しがちです。でもそうすると経験上、だんだん狭くなっていって、ちっともうまくいかないので、なるべく雑音をいっぱい入れて、色々な分野の人の話などを散々聞いたほうが、色々なヒントが得られていいと思います。さっきモデルを勉強するよりは思考系の本を読んだ方がいいですよという話をしたように、必ずしもモデリングの勉強をし続けることが最短ではないような気がしています。色々な雑音を入れながら、日々モデルを書いていくのがいいんじゃないでしょうか。

長い時間、どうもありがとうございました。