それでは、ワークショップを始めます。では、まず自己紹介をしましょう。

富士通の吉田と申します。80年代は人工知能のICOTなど、90年代からソフトウェア工学を扱っています。オブジェクト指向が人工知能の一分野だった頃からの付き合いです。80年代のオブジェクト指向はプログラミングのテクニックだったんですが、90年代になって、設計や分析やモデリング、つまりプログラミングの対象をどうするかということを考えるようになりました。それ以来ずっとモデリングを扱っています。

オージス総研の竹政です。私も人工知能を少しやっていて、その後からUMLやモデリングなどの世界に入りました。最近はUMTPの活動もしていて、モデリングの認定試験などにも関わっています。

お2人から人工知能という話がありましたが、人工知能には、非常に抽象的な分野と、翻訳などのように具体的な分野があるなと思っています。抽象的な分野の本を読むと、それを具体的にどうつなげるのか、という疑問が出てくるんですが。

昔は、今先生がおっしゃったような「推論とは何か」のような比較的抽象的な部分を現実に適用しようとしてあまりうまくいかなかったんですが、ここ10数年は計算機パワーで現実の事例を処理する方法になっています。たとえばチェスなどだと、パターンを全部覚えてそこから探すだけです。記憶量や計算機パワーが増えてきたので、法律の推論なども過去の判例のデータベースにまずマッチングをかけるようになっています。抽象的なものを適用するやり方と、事例をたくさん持ってそれをパワーで処理するのと、大きく2つに分かれていて、後者の方が最近は流行っています。翻訳なども、昔はちゃんとparsingをして理論的にやっていたんですが、今はたくさん持っているものの中から一番合うものを選ぶようになっています。

メタボリクスの山田です。UMTPの会員ではないのですが、前々回に呼んでいただいたご縁で今回も参加しました。フリーで、コンサルティングなどお客様のお手伝いをさせていただいているんですが、実は十数年前、まだWebが実現していなかった時代に、地球規模の情報システムをどうすればいいだろう、というようなことを研究所でやっていて、そのときに、「もの/こと/かたち」というアーキテクチャを考えていました。そのときは中村先生のことは知らなかったんですが、一年前に先生の本を見て、「あぁ、こういうことを考えている方がいた」と思いました。今日お話を伺うことができて光栄です。私は「もの」「こと」の2つだと情報システムは収まりきらない気がして、「かたち」なんていう余計なものを付け加えてしまったんですが、その辺がどうからむのか、お聞きできればと思います。

河合です。70年代前半にはメインフレームのOSをアセンブラで作っていて、90年代の半ばくらいにオブジェクト指向に触れて素晴らしい考え方だなと思い、それからオブジェクトにはまってしまいました。ものこと分析は4、5年前に勉強したんですが、そのときたまたまインターネットで検索したらこの本[『もの・こと分析で成功するシンプルな仕事の構想法』]がひっかかって、世の中にこんなものがあるんだと思いました。

豆蔵の羽生田です。豆蔵という会社は、オブジェクト指向とソフトウェアエンジニアリングをベースにしてコンサルティングをするというポリシーで、8年くらい前に立ち上げられた会社です。

名前が変わっていますね。

「豆」というのを知恵の詰まった実と捉えて、それをみなさんにお配りする仕事という意味で、豆の蔵です。あとはJavaBeansというようにオブジェクト指向のソフトウェアコンポーネントをBeanと例える人がいて、それにも引っかけています。
オブジェクト指向では「もの＝オブジェクト」と捉えがちなんですが、何となくおかしいんじゃないか、「こと」も「場」もオブジェクトにしないと、全体をうまくモデリングできないんじゃないかな、「もの/こと/場」という3つのセットでやろう、と思っていたときに、この本[『もの・こと分析で成功するシンプルな仕事の構想法』]に出会い、別の分野で同じようなことを考えている人がいるんだと思いました。

日本ユニシスの水戸です。20年ほど現場でシステム開発をやってきましたが、数年前からビジネスの可視化と情報システムのつなぎに取り組んできました。

東芝ソリューションの山城です。部会の主査をやっています。これまでこのワークショップは3回やっていて、山田さんや浅海さんに講演をしていただき、今回は4回目です。実は私はものこと分析のことを知らなかったんですが、部会の時に「是非中村先生を呼んでこういう考え方をみんなで議論しよう」ということになりまして、今日講演していただけて非常にありがたく思っています。私は、最初はFORTRANなどの手続き型の開発の仕方をしていて、90年代に入ってからオブジェクト指向という考え方に触れてシフトしたんですが、見方を変えるとパラダイムが違うんですね。それが大事だなと思っています。

TISの森です。10年くらい現場でオブジェクト指向で開発設計をしていまして、10年過ぎた頃に大規模なプロジェクトでオブジェクト指向を使って多くの人に同じように設計してもらうよう指導する立場になったんですが、そのときにそれをシステマチックに手順として説明できなかったんです。今は違う部門に異動して、どういう風にしたらみんなが共通にものやことを抽出できるのか、という考え方のプロセスを探していまして、その中で、ものこと分析を使われているPJがあることを知ったのがきっかけです。

浅海です。今はフリーでオブジェクト指向開発の教育や技術解説をしています。もともとメーカーでOSなどのシステムのプログラミングをしていたんですが、巨大なシステムを作るときに、色々やっていくとだんだんオブジェクト指向的になっていくなというのを現場で感じていて、その後90年代にオブジェクト指向がモデリング技術として上流の方に来たのを見て、この世界に来たという経緯があります。私はものこと分析をあまりよく知らなかったんですが、今日お話を伺うと非常に参考になることが多かったです。僕自身は今、物事を「アクター/リソース/イベント」として分解し、それに対して「物語」として目的を抽出しているんですが、もしかしたら基本的に共通するところがあるのかなと考えていますので、何かヒントを得て帰りたいと思っています。

テクノロジックアートの山下です。ものこと分析は今回のセミナーでこういうものがあると知って勉強したんですが、とても王道的で、シンプルだけどよく使えるものなのではないかという感触を得ています。

オージス総研の藤井です。私はソフトウェア開発の設計や開発プロセスの研究をしています。先生の本を読ませていただいて、シンプルさや、既成の概念にとらわれずに物事の本質を見ることが大事だと感じました。ただ、現実に色んな人と仕事をするときには、そこが一番難しいところかと思うんです。どうしたらシンプルさという難しいことを追求できるのかに興味があります。

最後になりましたが、テクノロジックアートの照井です。普段はソフトウェア開発をやっています。若輩者で学生の頃からオブジェクト指向プログラミングというものが既にあったものですから、よく分からないままに使い始めたという感じです。ものこと分析に関しては勉強不足で申し訳ないんですが、第1回の児玉さんのご講演でシステム化との親和性が高いという話で知ることができました。自分に欠けていたものがようやく見つかったという発見ができてよかったです。今日は座長を務めさせていただきます。

それでは早速ですが、講演内容についての質疑に入らせていただきます。

では最初に、自己紹介の追加も兼ねて一言申し上げます。私は「もの」という言葉に最初こだわっていたんですが、「ものこと分析」という名前を最初に考えてこれを作り上げようとしてきたわけではなく、自分流儀でやってきたものが結果的にこうなったわけです。お付き合いしている会社の方で、私の考え方を分かってくれる方はごく少数です。100人に1人くらい。分かってくれる方には惚れ込んでもらえるんですが、そういう人はそういるものではありません。

たとえば設備や工程の開発でお付き合いしているときには、設備を作るときには設備を見るなと、手の動きを改善するときには手を見ないで対象を見ろと言うんですが、これで分かってくれる方は少ないんですね。工場を見るときに、人とか設備を全部消して材料から完成品までをずっと追ってみると、見えないところがいっぱい出てくるわけです。ところが、そこを想像力で追ってみましょうと言っても、「おまえ何を言うのか」で終わっちゃうことが非常に多いんです。今も多いんです。手や設備が扱っている対象物があるというのは皆さん分かるんですが、物が動くのは手があるからだ、手とか設備がなくてものは作れない、というのが普通の考えなんです。ここが私の悩むところでして。

ところが面白いことに、情報関係の方や数学的なセンスの持ち主はそういう抽象化が得意なんですね。たとえば人工知能で状態空間を作ったりっていう、ハノイの塔などもまさしくこういう発想ですよね。それから、群論だとかあるいは昔のオーソドックスなサイバネティックスの考えなどはオペランド/オペレータのような概念で、まさしく私が自然に学生の頃勉強したものが滲み出ているような感じがするんです。抽象的な概念なんだなと。それを分かってもらえる方というのは、モノづくりでは非常に少ないと思っています。今日のように、お前の話がなんとなく気になるから聞きたいとか、興味があるという、たくさんの方に囲まれたことは今までないので、何かこう、恥ずかしいような嬉しいような気持ちです。

では最初に私から。今日のスライドの最後の方で、段階的なUP&DOWNの図が非常に分かりやすかったというか、考えさせられました。ものこと分析で、ものを追求するのが重要だというところが感動したんですが、「もの」をどれにしたらいいのかで悩むことが多いかと思うんですね。どれをものにすればいいのか、終わりの状態をどの状態とすればいいのか。それはやはり、状況によって終わりのものを仮定して、ことを改善するという考え方でいいのでしょうか?

図1 UP and DOWN (講演資料56ページ)

システムを作るときに、自分の目的は何か、あるいは自分に限らず、システムの機能は、目的は何かなと、素朴に問いかけたときに、何か1つでも目的や機能を言ってもらえると、それを手がかりに展開できます。この例では、学生さんの話[帰省するための切符が取れなかった学生さんが、帰省の目的を考えることで母を呼び寄せることにしたという話]からああいう図を作ったんですが、対象が何かを考えると、指定券が欲しいんだということになります。ちゃんと整理して言うと、自分の指定券を手にした状態、これが目的です。そしてその先が何なのかというと、指定券があると列車に乗って座って行ける。座って今度は目的地、郷里に着いた状態、と考えを進めていけるわけですね。それを書いていくわけです。そうすると自分の状態が変わっていって、郷里に行って自分の家にいるようになる。そこでぱっと、対象物がおふくろさんに変わるわけですよ。最初からおふくろさんという思いはないと思うんです。だけども、とにかく家に帰りたいんだとか、切符を欲しいんだというような、何か言葉に出たものを手がかりに絵を書く。この次に何を実現したいか、つまり切符を持って、座って、列車に乗って行けばいいんだなとほどいていって、だんだん絵が完成していくと思うんです。そこで、いや、ちょっと待て、おふくろを喜ばせればいいんだなと、出てくるかもしれないんです。この学生はセンスのいいやつで、無意識か意識か分かりませんが最初からおふくろさんが対象だったんですが。

とにかく何でもいいから、みんなで議論して、ものとか実現した状態を書いていく。「現状を書いてみよう」「これは本当に必要なものなの?」とかね。そこには、始めのもの、終わりのもの、手段のものが関わります。Bにしたい、そのためAから始める、そこでCが働く、と。Bがおふくろさんの喜んでいる状態。おふくろさんに喜んでもらおうと考えると、急に「家にいるおふくろさん」が「東京にいるおふくろさん」に変わっちゃうわけですよ。その手段が「切符を買って送る」である。具体的には田舎に行くのではなくて、反対方向の切符を手にしている自分、後で言えばそういう風に整理できるわけですね。色んな考えがあったり考えがモヤモヤしていたりするのを議論していくと、だんだんこういう構造が見えてくる。こういう構造を手がかりにしながら思考を整理していく、というフレームワークかなと思うんですけどね。最初からスカッと構造ができていてそこへはめこんで完成というのではなくてね。

逆に質問になりますけども、要求分析といいますか、お客さんの要求をシステムで実現したいという何か分かりやすい例を言っていただけますか。

図2 ホワイトボードに書かれた図

先生の本に書いていただいている立替払いとかは、ケース的には多いのかなと思います。

会社の経理という機能というか、そういう対象と、立替をする人とかお金とかが見えてくると考えやすくなると思うんですね。最初から立替払いというシステムに飛び込むよりもね。

よくみんなで議論して追究して、みんなが納得できる終わりの状態を見つけるのがポイントだと考えてよろしいですか。

たとえば銀行のATMなんかは、お客さんが来るたびにある意味で同じことを何回も繰り返しています。そういうATMの機能は何なのと考えると、あのシステムが関わってくる対象物はお客さんとお金と銀行と、銀行の中のお金ですね。そして実際に機能をつかむ段階で重要な対象物だけで表現できると、原点的なシンプルなシステム開発につながると思うんです。モノづくりの場合は簡単なんですよ。完成品と素材だけなので、この辺はあまり悩まないんですよね。システムの場合には、結局お客さんだよって言っちゃうと、それで終わりなんですが。対象として何が入るかですよね。ATMも色んなレベルで考えられますが、実際にあの仕組みを開発したときにはどこらへんから入り込んでるんでしょうか。

メカの制御とか現金払出機とかキーボードとか画面表示とか、そういうような単純な入出金の仕組みから始まっていると思います。色んな銀行が異なる機能要求を要求するので、システムがそれに対応できるように変更しやすさなんかを加味して作ったりするようです。

ではやっぱり、ああいうハードやソフトが重要な要素になるわけですね。

はい。デバイスが結構大事みたいです。

目的のレベルも色々あると思うんですね。すでにATMがあって、お金を払い出してもらうということを目的にシステムを作る場合と、ビジネスモデリングの視点で、そもそも銀行としてお客さんに何をしてあげたいのかを考える場合があります。ビジネスモデリングの後、お金を払い出すのに有効な1つの例としてATMがあることを考えるんですが、このときATM以外にさらに有効な手段がありうるのかを考えるということになります。

別の例では、鉄道会社が電車に乗りたいお客さんに有料でサービスを提供したいというときに、一番最初に出てきたシステムは自動販売機で切符を自動的に提供するものだったと思うんですが、さらに進んでくると自動改札を提供しましょうという話になってきて、最近ですとSuicaみたいなもので他の鉄道会社とも共通化しましょうと。最終的にいかに便利に電車により移動をするという意味で到達地点は同じなんですが、システムの目的は状況によって具体的な実現という意味では、ずれてくるのかなという気はしてきています。

私はUP&DOWNなんて言葉を使っちゃってるんですが、お客さんが持っている現金を銀行に預けたという状態、それが記録されてちゃんと確認できるような状態、あるいは自分の口座の金額の中で欲しい現金を手にしている状態に変えるというレベルで考えると、今までは窓口で色々やっていたんだけれども、ATMも1つの手段になりますね。他にもそんな手段がないかなんていう問題を考えるときには、今のもう1つ上のレベルで考えてみることもできると思うんですよね。

それが最近必要とされてきているのかもしれません。振込みをするなら、ATMでもできるんですけど、最近ではインターネットでもできますよというような。第三者にお金を渡したいというのが最終目的だと思うんですが、それをやるためには二次的な目的がたぶんあって、それがシステムターゲットとなるんだと思うんですよ。

みなさんはいいシステムと変なシステムの事例や経験がおありだと思うんですが、いい悪いはどこらへんが判断基準になるんでしょうか。

お客さん側と作る側と両方の判断基準があります。お客さんからいいねと言われるシステムというのはあるし、言われないシステムもあります。

言われないくらいならまだいい方ですよね(笑)

言われなくてもちゃんと使われてるならいい方ですね。もう1つは、作る側から見て、出荷した後に手のかかるシステムと手のかからないシステムというのがあります。ソフトウェアというのは結局、作るだけじゃなくて、作った後の運用が長いんです。そこでいかに楽をするかを考えて作らないと、とんでもない目にあっちゃう。お客様がどういう状態になるかと、我々がその後どうなるかという両面で、いいシステムと悪いシステムがありますね。

色んな人が色んなことをして欲しいと要求するので、その中で本当に大事なことは何かを見分けるのが非常に難しいですね。

先生の自己紹介のスライドで、モノづくりの本質として、「客が喜ぶ」「良いモノ」「楽につくる」の3つが良品条件と紹介されていましたが、まさにシステム開発の目的がこれです。要するにQCDですね、品質とコストとデリバリ。これを満たすものを作るのが目的なんですが、一番の問題は、顧客の真のニーズがなかなか分からないことです。利害関係者がいっぱいいるので、何となく作って、ある人はいいかもしれないけれど、他の人はよくないかもしれない。喜ばせるのが母親だけだったらいいんですが、そこが一番難しいところですね。

バランスが大事ですよね。お客さんが喜んで、我々が苦労するシステムもあるんですよ。我々が楽をしてお客さんがいいというように、両方成り立てばいいんですが。

たとえば会計のシステムなんかでよく思うんですが、あれはもう標準形といいますか、会計のルールで、たとえば、財務諸表で中の構造が全部決まっていて、勘定科目なども決まっていて、その通りやっている仕事をコンピュータ化するというのはシステム化しやすいですね。ところが、何のために使うんですか、と聞いていきますとね、税務署がちゃんと承認できるように税金を計算できればいい、株主に報告する資料が作成できればいい、あと、いい経営かどうかが分かるようになればいい、などと言うんですが、その本当の目的を見ますと、アウトプットは単純な資料なんです。そうすると、こんなに勘定科目を分類して後で足したりしなくたって、最初からその必要な勘定科目でインプットを整理しちゃえば、今の十分の一くらいの負荷でできちゃうんじゃないかと思うことがあるんですよね。それを発展させていくと、今度は経営者が欲しい経営情報システムなんかは、社長さんが変われば変わっちゃう可能性があるので、どんな社長さんでも通用するような経営情報システムというのは追求する課題なのかが非常に疑問なんですよね、自分の分野の問題意識では。情報システムの問題としてはどうなのか興味があります。このシステムは経営状態を的確に把握できて役立ちますと、どういう企業にも売って歩けるようなものがあるかというと、決してそうでもないでしょうね。

大きい意味で始めのものと終わりのものまでは比較的容易に分かると思うんですけれど、その途中の部分のどれがぜい肉でどれが要のことなのかというところが、どうもぶれるような気がするんですね。それが人によって違うので、仕様の変更につながるのかなという気がします。最終的にやりたいことはそんなに違わないと思うんですが。

たとえば経営者が「私は日々こういう情報が欲しい」とか「月別/年度別で」と、はっきり言ってくれると、その情報を提供できるようにどういう情報を集めたりストックさせておけばいいかは考えやすくなると思うんです。だけど、こういう情報が欲しいというのが人によって違ったり、同じ人でも状況によって変わると、どんなことがあっても通用する方向に走りがちですよね。

最初は経営状況を把握できる数値が欲しいぐらいの話なんですけど、「その数値は具体的に何ですか?」というと人によって変わっちゃうんですね。

それで、その先を質問すると「お前さんたち、それを考えてくれないのか?」ってね。特に新しい技術の分野だと過剰に期待しちゃうこともあるでしょうね。何でも教えてくれるようなシステムを、とかね。

何でもできるような幻想を抱いてしまうかもしれませんね。

箱根に小涌園ホテルというのがあって、今から四十何年前かな、日本で先陣を切ってホテルのシステムを入れたんですよ。間接的に知っているんですが、面白い話がありましてね。売り込んで注文を受けたんですって。するとね、インプットするわけじゃないですか。「えっ、こんなことやらなきゃいけないの?」って言われたんですって(笑)。インプットしなくても気軽にできるという風に経営者は思ったらしいんですね。それで情報が出てくると。インプット作業者を訓練しなきゃいけないというと、「ええっ、そんなことやらなきゃいけないのか」と。

お客さんとの会話やすり合わせの中でどういう問いかけをしたらいいかとか、どういう構造で自分の中でメモに書き込んでおいたらいいかというレベルもありますよね。

先生がやっていらっしゃるようなモノづくりの現場でも、そういう理論とはたぶん違うレベルですよね。話をするとかすり合わせるとか。そういうのは重要ですか。

そうですね。モノづくりというのは理論的に説明できる形で作っているかというと、決してそうではないところも多いんです。たとえば分かりやすい例ですと、豊田自動織機という立派な会社があるんですが、ここはフォークリフトの一流メーカーで、最後の検査は、ベテランの技能士が乗って、かしがないで垂直でちゃんと動くということを運転しながら判断するんです。それをこんどは、人の判断ではなくて、工場の中で、工程の中でちやんと検査したいというので、その基本の姿勢の垂直性をどういう具合に測定したらいいかを考えた。そうすると、最後に面白いことが分かりました。垂直の姿勢が保証されるような設計になっていなかったんです。それが全部技能士任せだったんです。で、ちゃんとそこらへんの設計をやり直して、それで工程の中の最終工程で検査ができるようになったんです。

要するに、設計上、垂直度の位置基準がなかったということですね。いい設計、悪い設計というのは、そういう設計のところから決まっちゃう部分があります。そういう位置を決める基準作りってものすごく重要なんですよ。今日お話した西岡さんという法隆寺の宮大工さんの話はテレビで見たんですけど、屋根なら屋根の図を原寸で書いて、それを元に材木を合うように作って組み立てていく、そういう図面にあたるような原寸書きというものが非常に重要なんだそうです。その原寸書きを書くときに、縦と横の基準線、大きい広い真っ白の紙のどこに縦と横の線を書くかというその判断で、宮大工が一人前かどうかが分かるんですって。変なところに縦横書くとお前はダメだと、ここへ書くとヨシと、いうことになるんですって。

それは暗黙知なんですよね、意識的な基準があるわけではなく。

ないんですね。色々と訓練をして一人前になっていくと分かることなんですね。それで、一番上の棟梁が持っていることに一致するんでしょうね。正解がいくつかあるのかもしれませんが。

オブジェクト指向で言うとクラスの分割など、設計の良し悪しは、棟梁が見ていいか悪いか分かるような感じのところに近いかもしれません。

そのへんは非常に経験的なので、分かるまでに長い年数がかかります。ある程度誰にでもできるように改良しないと、普及しないのかもしれません。

そうですね。

そういう意味で、始めのものとか終わりのものという「もの」の識別は、製造業が対象の場合はそんなに難しくないのですか。

難しくないですね。難しい場合もありますけど、普通は要するに完成品ですから。もちろん、現場、現物、現状をよく把握することは大切です。だけど、手に負える大きさだったら、わざと現場に行かないで、完成品と材料を両方持ってくる。要するに、始めのもの、終わりのものです。これをこれに変えればいいんですよねって確認するんです。それから、じゃあどう変えればいいかを考えながらいじり回して、私が色々質問するわけですよ。そうすると、色々知っている人が答えてくれたりする。そこで議論するんですね。始めのもの終わりのものは現物でありますから、そりゃ楽ですよ。現物がない場合は絵に書く。図面だと分かりにくいですから。すっと絵に書けるわけですよね、ものの場合は。

議論に参加される方々は、モノづくりの工程にかかわっている方なんですか。

非常にいい質問ですね。今までは、たとえばQCサークルのように、現場の作業者が集まって改善していました。ところが、設計者や生産技術や、もちろん製造の監督者や作業者、技能者、保全する人など、関係する人が現物をベースに集まって議論する、というやり方が、これからのモノづくりで企業の改善や変革を行う上で大切になると思うんです。だからそこへ誰が参加するかってことは非常に重要です。参加する人によって見方が違ったり、まったく画期的な案が出てきたりしますから。

この間の例では、ひずみゲージのベテラン設計者が、自分が設計したものを現場でどうやって作っているかをまだ見ていなかったそうです。そこで実際に見てみると、自分の設計した形状に、作業者の女性が薄っぺらな金属をナイフで削っていくわけです。で、「俺にやらせてくれ」とやってみると、普通だったら10分くらいで終わるものが、20分か30分かかる。やっとできたと思ったら、その女の子から「まだそれじゃあだめだ」って言われて、笑って頭掻いて。そういうことをやると現場が喜んでくれるんですよね。設計者が「俺の設計が悪くてこんなに大変なことをやらせてごめんね」とか言うと、作業者の方も親しくなるでしょ。そうすると、設計者はすごく偉い人だと思われていたのが、色んな問題点を気軽に言ってくれるようになるわけですよ。こういう風に設計変更すればいいとか、ぽんぽんぽんと出てくるんです。それは設計したときは分からないものです。でも、見える人が一緒になって見ると、そういう宝が見えてくるんです。

何を議論するかのテーマを与えてあげると、何が今抱えている問題なのかを意見として述べてくれるということですか。

そうです。たとえば包装なら、完成品のダンボール図面状態があるんですね。始めは、ラインから出てきてそこに入れるものと、平置きのまだちゃんと形状ができていない材料のダンボールがあるわけです。それで、これをこれに変えることだねと、確認します。そうすると、この最終完成品の荷姿が複雑すぎるとか、中にパッドとか色々入りすぎてんじゃないのとかね、いや安全性が重要で落下試験で耐えられるような構造になっているんだとか、議論がいっぱい出てくるんです。そうすると、必ずそれを改善できる部分が出てきます。完成品とか終わりのものがはっきりしていますから、終わりのものが何かという問題は、ものを対象にする製造の分野ではそう多くないです。

その議論の中では、要のことを洗い出しながら議論していく形になるんですか。

そうです。形式的にこれが要のことだとか書かなくても、私も参加して議論していくと、要するに位置合わせしてはめればいいんだなとか、簡単には削ればいいだろとか、そういう話になるんですよ。余分なことはやらなくてもいいんだということにだんだんになってくるんです。そういう風に意識を変える方法だと言ってもいいのかもしれませんよね。最後に意識が変わらないと現実は変わりませんから。

そうだとすると、前提として、「ものこと分析という考え方があるね」という話を別にするわけではなく、一緒に議論をしながら「それはこういうことだよね」っていう風にして進めていくわけですか。

ええ、そういう場合もあります。

そうでない場合は?

そうじゃない場合っていうのは、たとえば上の方が私の考えに賛同してくださって、現場に浸透させるためにまず最初に講演してくれということもよくありました。でも講演したから分かるわけじゃないんですよ。だから、そういう講演をする前にまず一度経験してみましょうと、そうしておいて何となく雰囲気が出来上がってきたら、ちょっと私の考えがあるから聞いてよね、というかたちで、「実はものこと分析と呼んでいるこういうものがあるんですよ」と説明します。面白いことに、実務家の中で、私もそういう考えでした、感激しました、私はあなたみたいにシステマティックに整理していなかったけど同じ発想をしてた、なんて人が出てくるんです、たまに。そうすると嬉しいですよね。

それから、紙に書くやり方にも色んな手法があります。たとえばコマ図で始めの状態からだんだん移っていくのを図に描いていくわけですが、これは現場の担当者が、「これはコマ図って言って、コマ図を長い紙に書いていくと分かりやすいですね」って、作ってくれた手法なんです。コマ図っていう言葉も私が言い出したんじゃないんです。現場の人に「コマ図でこうやるんだ」っていうと「ああそうか」っていうだけで、別にものこと分析なんていわなくても同じことを考えてくれますね。

コマ図は資料でお配り頂いた53ページのものですか?

図3 安定した状態 ーコマ図ー で表現する (講演資料53ページ)

そんなようなものです。人工知能でもこういう構造で捉えるという考えもありますよね。この図では、水割りウイスキーを作るのに色んなルートがあるわけです。最初に何を入れるとかね。そこでプロに聞くと、「一番最初に氷を入れなさい。氷を入れてウイスキーを入れる。それで水を入れてかき回しなさい。そうするとウイスキーが早く冷えておいしくなります」と教えてくれる。そうするといいルートが決まっちゃうんですね。実験などをやらなくても、ベテランの人が自分の考えをコマ図で表現してくれたらしめたものですよね。「いただき!」になるんですよ。

今おっしゃったように、ワークショップみたいなかたちで現場を巻き込んで構造とかを調べていく中でも、良品条件っていうのが要の技術なのかと思うんですが、そういう作業の中で良品条件を固めて作っていく段階とか手順とか、そういうものはありますか?

これからの日本の製造業は、良品条件の概念などを整理していかないといけない段階だといってもいいんです。良品条件というのはものすごく広いんですが、私は良品条件のレベルを3つに分けています。要のレベル、つまり対象物に直接作用するところですね。技能者の場合は手先のレベルです。それに対して今度は、技能者の体の動きのレベル。それから一番下が心のレベルって呼んでいるんですが、「いいものを作ってやろうと」「やりがいがあるぞ」というレベルの良品条件というのかあるだろうと思います。

作業に関わる色んなステークホルダーの方、それぞれの立場ごとに色んな良品条件の切り口があって、それをすべて満たすようなかたちを目標にしているのでしょうか。

良品条件は最初は設計というか決めなきゃいけない。その決める順序っていうのが、要から目的、そして手段というように決めていくわけです。たとえば、塗装するときに、技能者の手が動きます。それをよく調べていくとね、吹き付けるノズルの塗料が吹き付け面に対して直角に進むのが良品条件と分かってくる。そうすると、曲がっているところだと、技能者が腰を入れながら体を動かしているんですよ。必ず持っているガンを垂直になるように動かしているのが分かるんです。つまり、垂直に当たるっていうのが要の良品条件で、それを実現するために体の動きをこういう風にしなきゃいけないというレベルがあるんです。

「要」から少しずつ派生していると考えてよいでしょうか。

ええ。そして本当にそうやって動かしていいものを作ってやろうという気持ちが最後になきゃいけません。大きく分けるとその3つですね。要の良品条件が分かると、その先の体の動かし方とか、どんな設備を作ったらいいかなどが分かってきます。

今の話だと「垂直」になってるいんだということを見つけるのが重要で、そこから派生していくということでしょうか。

そうです。ベテランの人はそういうことを分かっている人もいるし、分からないけれどもよく観察するとうまい人はその条件に適っているということも言えるわけですね。

じゃあ職人さんが体で覚えていることを抽出して可視化してあげるような感じでしょうか。

そういう風に発見することもあります。でも、すべての職人さんが同じやり方じゃないんです。誰が正しいかということになるんですが、少なくとも常識的に、粒が垂直にあたるのがよさそうですよね。そういう素朴な理論も良品条件の仮説を立てる上で役立つわけです。そういう議論が必要なんですね。それで実験して可視化する。

実験とかシミュレーションとかでしょうか。

ええ。ベテランの人に聞きますと、塗料にはいい子悪い子があるんだというんです。ノズルから出てくる粒の径はミクロンなんですけど、同じじゃなくてばらつきがあり、でかいのは悪い子なんだそうです。今日は悪い子が多いなぁとか、ぶつぶつ言いながら仕事をすることがあるんですって。それは、ガンの保全が悪くて中に詰まっていたり、塗料自体が悪かったり、温度とか色んな理由でそうなるらしいんです。その塗料の粒の良品条件というのがあるわけですよね。すべての良品条件を網羅しなくても、これだけ守ればいいというのを押さえるだけでも大分違うんですよね。実現したい物事が鮮明に分かると、そのために何をしたらいいかが分かりやすくなる。そういう意味で良品条件も考えやすくなる。こういうものを作りたいんだっていう目的があっての良品ですからね。目的がなくて良品条件なんてありえないわけです。

良品条件を見つけ出すために、インタビューとかワークショップとかで色んな人と議論しながら見つけていくということですか。

そうです。

私はこの本を読んでいて、その部分がよく見えなかったんですけれども、実はみんなの議論をファシリテーションするというのがこの手法の片方になっていて、そうした結果見つかったことに対してものことを適用しようという、両方必要なのではないでしょうか。

まさしくご指摘の通りです。企業の方で、ある鋭い方が色々言ってくださるんですが、「ものこと分析は素晴らしいね、でも文字通りものだけで人に関して書かれていないから、そこがつまらないね」と言われました。言われてガクッと来ますよね。でも、そういうのがすごくヒントになります。結局、「この手の問題はこういう具合に考えると問題解決しやすくなる」というような考え方ができるようにするにはどうすればいいかという問題を、本に書くべきなんだなと今思っているんです。議論をするにしても色んな方法があると思うんですよね。色んな立場の人が集まるとか、あるいは現物をベースにしてやり取りするとか、分かりやすい絵を使うとか。だけど、みんなが共通に見られるものとか情報を共有化できるものがないと、言いたい放題で収束しませんよね。おっしゃるように、終わりのものをちゃんと明確に正しくみんなで認識するにはどうすればいいだろう、というテーマがあるんですが、それは書いてないんですよ。だからつまんないって言われたわけです(笑)

その話に関連していると思うんですけれど、先生の手法で、基本の変化を動詞で表すときに、手段の決まってしまう言葉を用いずにというのがありますね。切断ではなく分離、パンチではなく穴あけのように、手段にこだわっていない言葉を選ぶっていうのが、実際には非常に難しい。ここを今使っている手段の言葉で表しちゃうと、「もの」に注目したのにやっぱり手段からやったことと同じ結果にしかならない。そこを、手段から離れて、手段が決まってしまう言葉を用いずに基本変化をどうやって表現するかという、考える方法に何か秘訣が欲しいなと思うんですが、何かありますか。

その気持ちはよく分かります。話が遠回りになりますが、たまたま「もの」という言葉を興味半分に辞書を引いたら、資料でご紹介したように書いてあって、面白いなぁと思いました。初めのもの終わりのものは、今のオブジェクトとは違うんですが、final objectとかinitial objectのように格好をつけて言っていたこともあるんです。そして、その間をつなぐのが変化だと。数学的なtransitionとかtransformationというような言葉も使っていたんですが、工場に行ってtransformationだなんて言っても相手にしてくれませんから、「もの」や「こと」というのが何となく出てきました。それで、「こと」を辞書で引くと、色んな意味の中に「変化」と書いてあるので、そこにパクッと噛み付いたんです。後で分かったんですけど、「もの」とか「こと」って言葉は、色んな方が使っています。仏教学者の南方熊楠も、本でものことと言っていて、なかなか難しいんですけど「そうなのか」とか何か感じるようなところがあるんです。他にも、物理学者の方で、複雑系を表すのに「こと」という言葉を使っている人もいます。みなさん、特に「こと」というのは色んな意味で興味ある意味として持たれているんですね。

私は大体のことをいうと、この分野で、ものこと分析に関しては、「こと」という言葉はなくていい、始めのものと終わりのものだけでいいと思っているんです。始めのものと終わりのものを見たときに、ぱっと変換できればいい、それが技術だと。でもそれだけじゃ相手にしてくれない。やはり分離とかって考えないといけないですよね。自分のところの変換の技術を全部網羅して、そのデータベースを作ろうという企業が出ています。それは切断じゃなくて「分離」だと言うと、分離するにはうちにはこういう技術があるね、と言って、切断じゃなくて分離という言葉の方が技術を分類する上でいいなっていうのは分かってくれるんですよね。うちの持っているのは金属を分離する技術だけど、プラスチックなど色んな種類のものの分離があるねと。切断以外の分離の技術は色んなものがあるなと、自分の持っている技術をさらに横展開して、新商品の開発、技術開発につなげられないかなっていう議論にもなるんですよね。それが抽象化するということだと思うんです。あまり対象の立場に立った言葉というよりも、たくさんのものを包含するような言葉で整理していくと。

図4 「もの」「こと」の定義 (講演資料21ページ)

今の例だと、ものの最終状態からボトムアップで考えると考えやすいことはないでしょうか。

ここがまさにさっき羽生田さんが聞かれた話で、先生の分野ですと、ものを見れば、削ったのか溶かしたのか分からないけど、とりあえずなくなっているんだと分かると思うんですが、我々のような情報システムだと、最終状態を定義するために、それがどういう状態なのかを別の方法で定義しますよね。この考え方を我々のところに持ってくるときに、1つ抽象的なレベルに持ち上げなければならないと思うんですが、それができる人とできない人がいるってことですよね。そこが一番難しいところではあります。

ものの場合でも、2つのタイプがあります。ビフテキタイプとゆで卵タイプです。ビフテキだと、レアとかミディアムのように、完成品の肉の赤み度合いで表現するじゃないですか。ところがゆで卵は見えませんから、「2分」のように、お湯に入れておく時間、熱をかける時間、要するに作り方でアウトプットを表現する。私の理論は、作り方で表現するのはやめよう、ゆで卵をちゃんと見えるようにしましょうということなんです。

それを表現する言葉がなかったってことですね。そこが難しいですね。

だけど、仮に最後のものを表現することができる方がよければ、そういう言葉を作ってもいいじゃないですか。大げさに言うと認識の仕方とか認識論的な問題で、みんながコミュニケーションしながら考えるときは、イメージが共通になるような絵とか現物とかがあればいいんですね。たとえば、赤ん坊が周りの世界を認識するときは、たぶん「もの」から始まると思うんです。何か認識の一番素朴な難しくない概念が「もの」だろうという気持ちはあるんです。それに頼ると、みんながコミュニケーションしやすくなったり思考もしやすくなるんじゃないかと思います。「こと」から入っていくと、みんなのイメージが変わっちゃうかもしれませんが。

資料の21ページに書いてある「もの」の定義[図4参照]を見ると、名前がないと共有化できないということですか。

そうです。名前というのは非常に重要です。これも工場の話ですが、何て呼ぶんですかって聞いたときに、名前がないとか、人によって呼び名が違うってことは、管理されていないという証拠なんです。名前で管理される極端なものはコーディングですよね。コードが付いているものは確実に管理されている対象なんです。いいか悪いかは別にしても、コードは扱う対象の典型的な名前の付け方です。ところが、名前がないものが置かれているということは、それが本当に大切かが疑問だと言えますね。

逆に同じことを違う名前で呼んでしまうこともありますね。ITの業界では、会社が違うと同じことを違う呼び方しますからね。学生なんかは勉強するのがすごく大変みたいですよ。

それは、現場現場で違う意味で言っているんだ、ということをモデル化しなければいけないからであって、ITの問題ではないですね。

私なんかはIT用語の方が、標準化というか共通している言葉が多いと思いますよ。たとえば、現場という言葉がありますが、三菱系の会社では現場ではなく現地というんです。普通は現場という言葉を使いますけど、やっぱり会社やそこの歴史や色んなことで、呼び名が変わってくるんですね。

用語ということで言うと、先生の言葉で「もの/こと/要」というように和語をわざと使うのは、現場で理解してもらいやすいというのが理由なんですか?

そこらへんは無意識のうちに付けているんですけど、後で思うと、「もの」とか「こと」という言葉は、そのものズバリの英語がないですね。たとえば、objectイコール「もの」かというと、objectの方が広く抽象度が高いですよね。「要」はわざと付けたんです。なるべく現場の人に分かってもらいやすいように。最初からこういう呼び方はしていなかったんです。

そういう中で「システムロード」という言葉がちょっと奇異な感じがするんですよ。素直に考えると、システムロードという言葉は「純粋な仕事」という意味で使っておられるような気がするんですけれど、なぜシステムロードって言わなきゃいけないのかなというのが、若干気になります。

つまり、「行わねばならないこと」とか、「始めの状態を終わりの状態に変えること」だけでもいいんです。ただ世の中では、ワークロードという言葉が普及しているんですよね。たとえば、今日のワークロードはどのくらいだとか、時間で表現する場合もありますが、出来高とか対象に関係する量でワークロードを考えることが多いんです。ワークロードの内容が「行わねばならないこと」だと言ってもいいんですが、システムロードの方が格好いいかなと(笑)

5年くらいして進化すると日本語の言葉に変わっているかもしれませんね(笑)

システムロードという言葉は、要素分解しないで「システム全体で見る」という意味合いもあるんでしょうか。

ええ。システムロードという言葉を英語の本で全然使っていないかというと、たまに使っている本もあります。非常に抽象的にシステムのファンクションの意味合いで使っている場合があるんです。たとえば銀行のシステムロードというのはトランザクションだとかね。システムによってシステムロードというのは色んなタイプがあるという表現の英語の本も見たことがあります。だからこのシステムロードという言葉を使ってもいいのかなと。

システムロードという言葉を使われている理由を考えたんですが、この本の例では、「こと」が1種類しか考察されていませんね。1つのシステムの中にファンクションが複数あるということがあるだろうから、そのことも含めてそのファンクションのセットをシステムロードと言っておられるのかなと思ったのですが。

あぁ、逆に教わりましたよ。そういうのがいいですね。病院なんかがいい例ですが、病院に入っていく人、出て行く人には、色んな状況の人がいますね。薬だけ貰いに来たり、不安で来たり、あるいは本当に治してもらいたいとか。すると、うちの病院はこういう患者さん、つまり初めと終わりを受け付けますよというように、ここに力点がある病院だということを表現するときに、システムロードなどとひとくくりで言うといいですよね。色んな種類の変換というか。

ということが背後にあると考えていいですか。

これからそういう風にします(笑)

この後の懇親会に第1回の講演者の児玉さんが来られるんですが、講演の中で、システムはサブシステムに分解して解決するんじゃない、サブシステムで問題解決しても不具合が起こるんだ、とおっしゃったんです。なので、実はその辺のニュアンスをお聞きしたくて質問したんです。

少なくとも、そういう意識はありますよ、この膨大なシステムでも、ちゃんとシステムロードという始めと終わりをつなぐシステムとしての変換があると。だから、システムに注意を払う前に、まずシステムロードは何かを考えてみましょうということですよね。それは部分的ではなく全体のシステムが取り扱う対象は何かという問いかけから始まります。そういう意味で、皆さんの情報システムの分野が面白いなと思うのは、ものも人も情報も対象の中に入り得るんですよね。さらにその中で専門領域と言いますか、俺は人中心のシステムが得意だとか、何かあるのかもしれませんね。対象によって技術は変わりますから。

業種によっても違うし、業務によっても。

情報システムはものすごく範囲の広い概念なんでしょうね。コンピュータというすごい道具が現れたものだから、扱える対象がどっと広くなっちゃって、皆さんその中であっぷあっぷされている部分もあるのかもしれない。私がやってきたのは昔からの伝統的なモノ作りですから、見ると視野で入ってきますものね。

ありがとうございます。

では、ここからは我々の用意した議案に移らせていただきます。まず、「モデリングを普及させるためには」ということなんですけど、ものこと分析のために必要な素質、素養というのはありますでしょうか。

私が今心がけていることは、20〜30代の若い人と一緒に、設備や作業方法や製品設計などの具体的なテーマで一緒に議論しながら、私がこういうような考え方でガイドして、今までとは違うやり方で具体的な結果を出してみることが大切だと思います。それ以外に普及させることはできないという言い方をしてもいいかもしれません。それで、最後に「ああ、おもしろかったです」と言われるといいですね。それから、いい結果が出たときに、今まで白い目で見ていた人が「あ、なるほどね、こういうことができるの」と仲間になってくれるといいなと。これが普及ということなのかは分かりませんが、私とすれば一緒にやってくれる人が増えればいいなという思いです。実践的な結果が出るような教育をやらないと、新しい考え方はなかなか根付かないんじゃないかなと思います。逆に私が教わるようなこともありますね、今日のシステムロードの話のように。そうすると燃えてくるんですよね。

「若い人」というのは、若い人の方がやりやすいということですか。

もっと言うと、若い人じゃないとだめだということです。

先ほど抽象化できるかできないかという話がありましたが。

それも大きいですね。ただ、実際にモノを作っていくと、若い人は自然に抽象化できるようになっちゃったりするんですよ。ところが経験豊かで実績のあるエンジニアの方は、人柄が優れていてもなかなか相手しにくいです。そういう方には、こちらが色々質問して教えてもらって、私が得して終わりです(笑)

次に「モデリング技術を体系化するとしたときにどのような軸やフレームワークが考えられるか」について教えてください。先ほど議論の中で図を書いてすり合わせする方法があったかと思うんですが、それを体系化するとしたら軸のようなものがあるでしょうか。

難しいことになってしまいますが、前に吉田さんが、システムがまた対象になるということをおっしゃっていましたよね。要するに、モデリング技術というのは手段であって、そのモデリング技術の対象が何かという問いかけをすると、体系化みたいなヒントは出てくるのかと思うんですけどね。

ちなみに、私が前回先生とお会いしたときにお話したのは、今我々が作ろうと思っているシステムをモデリングしようとするのか、そのシステムが対象としているビジネスをモデリングしようとしているのか、モデリングの対象には2通りの考えがありますね、ということです。システムをどうするかではなく、システムが対象とするものをどういう風に把握するかという話の方が面白いですね、というのを事前にお話したんです。今先生がおっしゃっていたのは、そのモデリング対象が、我々が作るものなのか、作るものが対象としているものなのかという、そういう段階があるので、その対象の段階によっても1つの体系があり得るということなんですよね。

そうです。それでシステム自体を対象にすると、かなり専門的な体系化が可能かもしれません。

次の議案ですが、UMTPの活動に関してご感想をお聞かせください。

ここは学会とか協会とは違う雰囲気があって、面白いですね。学会とか協会というのは、目指すものが違う人も集まっているんです。でも、こちらにはモデリングというものをキーワードにして、それに関心がある色んな立場の人が集まっているんだなという印象を受けました。それで、モデリングという言葉を我々第三者にも分かりやすく説明していただけるといいですね。そうすると、この活動がもっと活性化するという気がします。皆さん、モデリングの意味はぱっと分かっちゃうんですか? これは、外国から来た言葉で、既に外国にそういう分野が確立されているんでしょうか。

確立されているわけじゃないですけど、こういうアクティビティは重要だねっていうような認識は、海外の方が早くて、日本に持ってきたというタイミングのずれはありますね。

学会との違いですが、学会では自分が考えていることと同じことを人が言うとがっかりしますね。ここでは、自分が考えていたことと同じことを人が言うと嬉しいんです。その対象が海外でも同じです。だから海外で誰かが言い出したことが、「それは僕も前から考えていた!」ということだと、とても嬉しいんですね。だから、海外から輸入したかというと、そういう意味ではちょっと感覚が違うと思います。

ただの真似事じゃないっていうのは分かります。モデリングってingが付いているところがまた面白いんですよね。

海外ではモデリングって言う名前を付けていたんだけど、同じことを考えていたんだよと。

認定試験ができるっていうことは、かなり中身がちゃんとしているという証拠なんですよね。

ある程度、基本的な枠組はしっかりしていると思うんですけど。

こういうことは分かっていること、というのをある程度列挙できるということですね。それをテストするんです。

表記法が(OMGで)ちゃんと決められているということですね。そこが大きいですね。

その表記法というのは図の書き方とかですか。たとえば、河合さんのホームページは、その表記法に適っているんですか。

UMTPのUはUMLという統一モデリング言語のことで、クラスを四角で書きましょうと決まっています。コマ図はありませんが、代わりに状態遷移図というのがちゃんとあるんです。それに従って書くと、それでUMLなんです。

コマ図はオブジェクト図というのを時間のスナップショットで書くのと同じことですね。UMLのいいところは、色んな視点の図が何種類も用意されているので、自分の目的に合わせて選んで、取捨選択して使えばいいという点です。

そこらへんも勉強させてもらいたいですね。タイプが色々とあるんですね。

早速、認定試験を(笑)

先生がおっしゃっていただいたように、今後も活動に注力していきたいと思います。

お奨めの本を教えてください。事前に、(文章からモデリングする際や、モデルとしての文章を記述する際に参考になる)『日本語の作文技術』と(モデリングにおける抽象化を行う際に参考になる)『思考と行動における言語』をお伺いしております。

この『思考と行動における言語』は、難しくなくて非常にいい本ですね。本多勝一さんの『日本語の作文技術』は、日本語を非常に分かりやすい構造で整理されている、日本語の実践的な法則が入っている面白い本です。私は格助詞の役割っていうのをこれで勉強させてもらいました。日本語の作文の技術を教える講習会をやれって言われて、これが生まれたらしいですね。新聞記者ですからね。あと、今日本ではあまり流行らないんですが、哲学というか、アメリカでのいい意味でのプラグマティズム、要するにデューイとかパースとか、そのあたりの人が書いた本は、この分野で参考になるものがあると思うんです。Operational Philosophyと言いますか、イメージが湧く哲学ですよね。結局、突き詰めていくと、いかにものごとを認識して、目的に向けていかに表現するか、あるいは問題解決するときにどういう認識をしたらいいかという問題だと思うんですね。いわゆる5W1Hというのも、1つの認識の仕方ですよね。新聞記者の実践の場で出てきた、単純明快な問いかけですよね。

話は飛躍しますが、普通の形式論理学では、たとえばこれが良品だというと、それ以外は不良品になります。あるいは、不良の原因を全部なくすと、確実に良品が生まれるという発想になります。ところが、私の分野ではそうじゃないんです。不良の起きる原因を追究するだけじゃだめで、良品条件を追究しないと問題解決はできないので、形式論理学はなかなか通用しにくいですね。仏教では、「存在する/存在しない」、「生じる/滅する」というのを全部同列に置いて、お互いのその関係が因果の関係だ、というようなことを書いている仏教学者の本を読んだことがあります。実践的なゼロイチじゃない世界だなと面白く感じました。イチロー選手の話じゃないですけれども[講演の中で紹介されたエピソード。イチロー選手が野球少年たちに対して「負けたらなぜ負けたのか、勝ったらなぜ勝ったのかを話し合いなさい」と言った、というもの]、肯定と否定と両方で攻めていくと、本当のことが分かってくる、そういうロジックみたいなのがあるといいですね。というか、実践の場ではそういうロジックがありそうな気がします。仏教のような、ゼロイチで把握できない世界をいかに整理して表現するか、ですね。オブジェクトにも否定のオブジェクトとか肯定のオブジェクトなどがあるんでしょうか。

最後に、若い人に一言お願いします。

疑問があったら徹底的に取り組んで欲しいなと思います。たとえば、学生の時に大学で色んな理論を教わるんですが、現実の場でそれを適用することはあまりないんですよ。ところが、真面目にやっていくと、そういう理論がちゃんと適用できるんだなっていう喜びを味わってもらえるといいなと思います。だてに勉強したんじゃないと。たとえば環境問題などを考えるときに、「エネルギー」なんていう概念を知っている人と知らない人とでは、大分発想が変わってきますよね。エネルギー保存則とか、熱エネルギーや運動エネルギーなど色々あって、環境問題もそういうことに関係しているんだな、という風に考えられると、問題の捉え方が変わってきますよね。これは理工系の人の理論が生きる場だと思うんです。それで、可視化とか目で確かめることの面白さ、理論の面白さ、見える面白さを味わいながらモデリングに精を出していただきたいなと思います。

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