モノ・コト・バに基づくクラスの識別

増田：
「モノ・コト・バに基づくクラスの識別」は羽生田さんのオリジナルですか？これいいよねぇ。この羽生田さんの資料の中から1ページ選べと言われたら、間違いなくこれ。

羽生田：
いろんな人が、オブジェクト指向モデリングのオブジェクトの方法をいろんな表にしています。
それらを集めてにらんで、いちばんきれいに整理したいなと思ってやったもの。いろんなバージョンを重ねた結果、今はこれなんです。

増田：
そうですよね。これはリファクタリングの結果ですよね。これは本当にすごい表だと思っている。
しかもその下に要約が入っている。これは何というか、ちょっとどこかで隙あらば使わせていただこうと思っている。
私自身は、ものすごく、「こういう枠組みを理解しておいてほしいんだよな」という思いと、「これをただ投げつけてしまうと、まず全部をフラットに見てしまうし」という思いとがある。
それは例えば「データモデリングだけやろうよ」と言っても、データモデルをとにかく一生懸命詳細化してしまうということであるし、
別の言い方だと、個々のモデリングのスキルは覚えるんだけど、最終的に「限られた予算と時間の中でアプリを作らねばならない、品質の高いソフトウェアをデリバリーしなければならない」と考えたときに、なんというかもう本当に我田引水になってしまうということ。
私はもう、このスライドで言う「事実」、「ビジネスルール、きめゴト」に振り切っちゃって、データだろうが機能だろうが、そこを中心にまず抑えちゃうのがいいと思う。
アプリケーション全体からするとそれは一部なんだけど、そこが明確になってくると、周りにいろいろぶら下がってくるものについては、乱暴な言い方をすると「後からくっつけても間に合うよね」。逆に言うと「その中心のところに切り込まないようなデータや機能をいくらこう一段潰して作っていってもそのアプリケーションの本来の価値には達しないよね」、というような感覚はすごくあるんですよね。

羽生田：
そうですね。
結構データ中心の人ってね、イベント系、リソース系、と分ける。それでイベント系と言われてしまうと、まさに増田さんがモデリングでいちばん大事だと言っている「ビジネスルール」ってイベントじゃないしな、みたいな感じになるので。
あと、日本語で簡潔に整理したいなぁと思って。まずは「モノ」。オブジェクトの「物」と「パーティ」（法人・組織や個人の役割）というのを日本語で言うとなったら「モノ」だなと思って。これはなんか結構、自分的には「パーティ」も含めて「モノ」というのはなんかいいなと思った。
「できゴト」と「きめゴト」で対に出来たというのも、私としてはいちばん気に入っている。

増田：
上の二つはもう、私も完全に同意です。
私も、「リソースって単純じゃなくて、リソースとアクターとを分けようよ」と考えている。
「意思を持って行動する者、つまりこのスライドで言う「パーティ」と、管理の対象でしかないいわゆる「物」的な資源とは絶対に分けるべきだ」と思う。
このモデルは本当にその通りだよな、と思う。

羽生田：
「きめゴト」と言い出したのはここ3,4年で、その前までは「なんとかゴト」と決められなかったが、「きめゴト」でいいんだと、なんか思いついた。
これでなんとなくこの表がうまくみえてきた感じだったんです。

増田：
この「きめゴト」というのがすごくいい。本当にこれも私に刺さっている。
ビジネスルールは人間の決め事だから、逆に言うと人間が変えるもので、すごく不安定なものである。
「きめゴト」という言葉には、ルールとして存在するという固定的なイメージと、決め事なので変わりうるというイメージとの両方が含まれていて、いいなと思う。

羽生田：
ありがとうございます。

増田：
私自身は、他の物理的な対象とか「パーティ」とか「できゴト」は、ある意味存在する事実なので概念化やモデル化はしやすいんだけど、それだけ整理しても、準備にはなってもそのアプリケーションの本来出せる価値にはいけない。その価値にいくには、やっぱり「きめゴト」のところが重要だと考える。
「なぜそのきめゴトが必要なのか」や、「そのきめゴトが変わると何が変わるのか」に対する理解があれば、アプリケーションの価値をもっと出せるはずである。

DOAの使いどころ、人材育成

増田：
そこで、さっきDOAの話になりましたが、羽生田さんがおっしゃるように、椿さんとか渡辺幸三さんのああいう本はぜひ読んでほしいし、ああいう知識は持ってほしい。
ただ、もう一つ正直に言って私自身が思っているのは、その時代だったら、何らかの形で発生したデータを記録して検索とか集計ができれば役に立ったという時代だったということ。
その時代だったら、DOAでこの表の上から三つくらいを丁寧にモデリングしてやれば以上で終了、でもよかったような気はする。
ただ、今は、ソフトウェアにやらせたいこととかソフトウェアで出してほしい価値への要求がもっときつくなってきている。
一例としては、バスのオンデマンド。「誰がどこで待っているから経路をこうした方が合理的だ」というようなことをリアルタイムに判断するのが、そのバスサービスの価値に直結する。
これは、さっき言った「データを記録して参照できればOK」という世界と比べると、すごくいい対照になると思っている。
今ってデータがリアルタイムに発生してとれてしまうので、記録するというよりは、かき集めたデータを判断して即リアクションするというようなところにソフトウェアの利用価値が広がった。
シフトしたとは思っていない。ダイナミックに、その時点で新たにモデルの中からすぐ具体的なインスタンスを作り上げ直すみたいなことをやって返さなきゃいけない。

羽生田：
記録するだけではなくて、ダイナミックにその時点のモデルの中からインスタンスを作り上げ直すというようなことをやらねばならない。

増田：
そうそう。
あるいは、以前のDOAの時代だったら、基本的にはやっぱり「受注が確定しました」から始まってその先のプロセスに関しては相当しっかりした形ができているし、それを学んで再利用すればいいのだと思うのだけれど、今私が実際にやっているソフトウェアだとその前なんですよね。
商談活動をもっと効率的にできないかとか、そもそも商談機会をオンラインのネットの宣伝でキャッチするための効率。どこにどういう広告を打てばどういう商談機会を獲得できるんだみたいなところに投資されたりする。
そういうところって、発生したイベントをデータとして記録することはやるけれど、そのモデルさえできればいい機能が作れるという世界ではない。
ある意味、もう試行錯誤。商談活動の効率化という簡単なルールを決めてやるわけにはいかなくて、一か月の間にここまで進まなかったらそれは打ち切るようにしようかというようなことを試行錯誤する。
基幹業務システムはあるけれど、基幹業務システムはそんなことをやってくれないからExcelで管理しているのが実態。人間であるセールスマネージャーがExcelのデータを判断して指示を出している。
すべてとは言わないけれど、人間が判断しているところをそれこそAI的なものも使って判断するシステムが実現できたらめちゃくちゃ費用対効果が高い。
特にリソースとイベントだけを追いかければOKみたいな。

羽生田：
今まで業務とみなせていなかったところに新たな業務を発見して、それを今まで誰もモデリングなんかしたことがない世界を、モデリングパイオニアとしていかなきゃいけないということですよね。

増田：
そう。まずはそこにビジネスチャンスがあるぞ、と自分たちの差別化の可能性を感じた人たちが先行して飛び込んでいく。それで成功すると、今度は真似したがる人たちが出てくる。

羽生田：
だから本当に、ビジネスモデルハンドブックみたいなものに登録されてしまうと大体構造が見えてきてパクられるようになるのでしょう。そうなった後が、データモデルの使いどころなのでしょうね。

増田：
データモデルを起点にして、そこに土台を置いて作っていけば、かなりいい成果が出せると言える。
特に最近本当に感じているのは、やっぱりスマホ等のモバイル通信。データが発生するタイミングと量と種類。IoTまで含めたら、もうめちゃくちゃにデータが発生している。
もう一つは判断。どこにでもいきなりリアルタイムに通知して、それに対してアクションを起こせるみたいな。そういったダイナミズムというのは、いわゆる汎用機時代からの「データエントリーとレポート」という世界とは別世界になっていると思う。

羽生田：
それで言うと、IPAでDX人材のスキル定義にかかわっているのだが、ここで課題として挙がるのは、「データサイエンス領域のデータエンジニアリングとかデータマネジメントというのがちょっと弱い」ということ。彼らはどんどんデータ分析したり、AIの新しい手法とかを使っていろいろ面白いことをやってくれるけど、じゃあそうやって発生したデータを、その企業の中で業務にどういう風に活用するのか、とか、リソースとしてどうやってこれから経営につなげていくのか、みたいな視点がちょっと弱いという話がある。
一方で少し前にCDO（チーフデータオフィサー）のような、エンタープライズアーキテクチャーみたいなものを作ってデータをちゃんとトップダウンで管理していくんだみたいな話をする人たちには、どんどんアドホックに発生するデータをうまく役立てるデータサイエンス的な視点がちょっと弱い。
その両方がくっつかなければいけないが、そういう領域の人たちっていったいどうやって育てるのだろうかという課題がすごくあがる。

増田：
やっぱりそうなんですね。それにはすごく同感です。
両方とも必要なんだけど、両方でかなりのレベルになるというのはまず現実的ではないので、どうやったらその両方を持ち寄れるのか。
例えば、直接の協業じゃなくてもいいと思うのですよね。
例えばデータサイエンティストの専門的なところは、正直言ってツールとかでよいと思う。どうにかして機械化してもらって、その道具を使える人は業務をよくわかっている人、というような形で、データサイエンスの成果と、ビジネス的な感覚をくっつけるみたいな。
そこらへんが日本は明らかに弱い。アメリカでうまくいっているのかどうかは知らないけれども。

羽生田：
アメリカがうまくいっているとも思わないけれども、エンタープライズアーキテクチャーみたいな大それたものでは絶対うまくいかないのは確か。

増田：
そうですよね。ただ、本を読んでいると、アメリカと日本の決定的な違いで感じるのは、アメリカの場合は、確立していなくても結構大きな企業とかが新しいこと、例えばデータサイエンティストとビジネスアナリストの融合とかってやりたがるじゃないですか。ああいうカルチャーはなんかちょっとある意味羨ましい。

羽生田：
パイオニア精神とかね。

増田：
日本はやっぱりそこが弱い。ベンチャーだったらともかく。

羽生田：
まぁ、一度採用したら終身雇用ですよね。やっぱりそういうのもあるかなと。

増田：
そうだよね。大量にAIエンジニアを採用して、方針を変えたらそれに伴って大量解雇とかを平気でできる会社の世界ですもんね。

羽生田：
それはそれでまた、解雇された人は次のところにうまく転職できる世界。

増田：
私個人的には、DXという言葉がだいぶいろいろ手垢がついちゃったし誤解もあるんだけど、さっきも言ったように、明らかにもう土台が変わってデータの量とか種類とかスピード感がまるで違った世界になったので、それはもう本当デジタルトランスフォーメーションだというか、明らかに今までとは違う世界。
だけどソフトウェア開発は、実はあまり変わっていないんだよなという思いがあって。

羽生田：
そうですよね。だから、そういう新しい分野でモデリングしたりデザインしたりするときに、基礎として、なんかこういうパターンをちょっと知っているだけで有用。使えるものはどんどん使っていけばいいのでもったいない。

増田：
そうそう。知っている方が絶対速い。

原則・パターン・手法を深く理解し、適用するスキル

増田：
私自身が特に最近追いかけているテーマは、一般化された原則やパターンや手法をどうやったら個別の状況に適用できるか。
それはスキルだと思う。
「一般化されているものを、表面的にではなく深く理解する」というスキルと、「それを個別の状況にうまい感じで適用する」というスキル。
それはある意味訓練次第と言えて、これから重要なのではないかなと思う。

羽生田：
そうですよね。

増田：
今、個人的には、小学生のしかも学力が追い付かない子供たちをどうするのかという教育関係の論文を読んでいる。
まさに今言ったような、「経験があるが一般化できない」とか、「一般化されていることを目の前の課題に使えない」とかいうことが課題としてある。
そこを「こういう風にしてやるんだ」と。それで子供たちが一般化できるようになったとか、目の前の課題に使えるようになったとかいうレポートがあったりして、めちゃくちゃ刺さってるんですよ。今。
教育学としての発展というよりは、やっぱり認知心理学とか認知科学とかを移入して教育に生かせないかということでやってらっしゃる人たちがいて。多分それって、今の若手のエンジニアがこういうものを覚えるときと構造としては同じではないかな。

羽生田：
なるほど。

増田：
なんかちょっと、余生は余生というか、自分で作りたいというのはそろそろ諦めて、そういう方向に貢献するようなことを考えようかなくらいの気持ちかな。
ただたぶん、泳がないと生きていけないマグロと一緒で、自分でコードを書かないとダメだと思うので、高速では泳げないかもしれないがコードを書くこと自体はやめる気はない。
僕らは時間をかけて経験させてもらって覚えられたから、量があっても「羽生田さんの資料すごいな」とか思って見れるけれど、今の若手に「これを全部勉強してキャッチアップせよ」と言っても絶対無理なので。

羽生田：
確かにそうですよね。

増田：
「どうやったら、そのエッセンスを一般化して現場で使えるようになるか」というあたりに、何かいろいろ工夫とか。
そういう意味では、UMTPでもモデリングのワークショップみたいなのをやっているじゃないですか。あぁいうところでも、なんていうのかこう、伝え方を。

羽生田：
認知心理学とかも学んで少し工夫した方がいいということですね。

増田：
参考にはなると思いますよ。認知科学の話は、学んで成長するという意味では、まさにテーマそのものなので。

羽生田：
はい。

増田：
もともと認知科学や認知言語学には興味を持っていた。そもそも言語学が私のバックグラウンドなので。非常に面白い。

しゃれ、かけ言葉

増田：
僕はこの資料はすごくいい情報であり知識だと思う。
私自身は、今、現場でこの知識をどうやって活用してもらうかというあたりに、チャレンジしたいなと思っているという感じですね。これは本当に素晴らしいですよ。

羽生田：
これが結構、しゃれがあちこちちりばめられてるんですよ。
「Object Oriented Language」というのが、「物・言葉」と翻訳されて、「物・言葉」じゃなくて「モノ・コト・バ」だよみたいなこと。

増田：
「言葉」と「コト・バ」をかけてあったりね。

羽生田：
まぁ、「モノ・コト・バ」ということばを覚えて、それぞれが二個に分かれるんだと覚えてもらえれば、一応カテゴリはつかめるようにしてある。

増田：
そうですね。この資料は本当に、例も含めて、一枚の密度というか質がめちゃくちゃ高い資料ですよね。

「要約」のところを解説

――最後に「要約」のところを少し説明してもらえますか。

羽生田：
これはもう、椿さんから学んだものです。

増田：
「要約する」と言っても、「ある時点の要約をする」のと「期間で集計する」のって、会計をやっていると当たり前なモデルなんだけど、モデリングとして「時点」と「期間」という考え方がすごく重要。

羽生田：
そうですね。

増田：
システムのモデリングという観点だと、ここだと「イベント」の方に入ってしまうけど。「期間」だと会計の場合は集計しちゃう。
プロセスとして、CF(cash flow。キャッシュフロー）なんかが毎月どう変わるかみたいな変動の様子を扱うというのは、そういう意味では、「時点要約」がBS（Balance Sheet。貸借対照表）だとすると、「期間要約」がPL（Profit and Loss statement。損益計算書）で、キャッシュフローは実はその増減のプロセスみたいなイメージかなという気はしますね。
強いてここにちょっかいを出すなら、もう一つ「プロセス要約」みたいなCF視点の要約が入ってくるともっとすごいかなと。

羽生田：
そうですね。「要約」は、まだ発展途上なんです。