――まず、増田さんからもらっている「オブジェクト指向の源泉」というところで行こうかなと思います。

オブジェクト指向の（大元の）源泉

増田：
羽生田さんの資料の中で、オブジェクト指向概念の複数の源泉っていうのがありましたが、当たり前ですけど、私なんかの世代だと、そうだよなァ……っていう、非常にきらびやかなあれなんだけど（笑）

羽生田：
（笑）

増田：
ただ、これを見た時にちょっと思ったのが、ワーフスブラックのRDDとか、ラーマンのGRASPあたりは出てこないんですね。このあたりは、私が手続き的なプログラミングからオブジェクト指向的なことに移っていくときに、結構影響あったんで、あ、ここにはRDDはあんまりポーンと出てこないんだなぁっていうのが。

羽生田：
それは多分、この次の段階というふうに捉えているので……

増田：
あ、そういうことなのか！

羽生田：
これはSimulaとかアラン・ケイとかアクターとか抽象データ型とかフレームとかっていう、1960年代ぐらいの理論的ないちばん大元の源泉という意味で。だから、オブジェクト指向方法論みたいな話になるのは、これからさらに10年から15年ぐらい経ってから。

増田：
なるほど！　そうか。まさに源泉で、オブジェクト指向のある意味、前なんですね。

羽生田：
そう、オブジェクト指向っていう言葉が出てくるか来ないかぐらいに――アラン・ケイがその言葉を初めて使ったんだけど、実はその同じ時代に――OSの概念だったらケイパビリティとかAIの概念だったらフレームとかっていう類似するような概念を考え出してる人達が同時代にいたよーっていう話をしたかった。

増田：
だから、次の時代はOOADって言葉が出てきた頃の話になるわけですね。RDDはその時代だと。それで私の最初の疑問は非常にすっきりしました。

羽生田：
そうなんですよ。みんな、Simulaとかアラン・ケイとかは言うんだけど、あんまり他のことに言及してくれないので。
実は、ミンスキーのフレームとか、ERモデル……チェンのデータモデルとかも、オブジェクト指向そのものじゃないけど、似たところをうまくフォーカスしてたんだよっていう話ですね。

増田：
羽生田さんの話を受けると、チェンのモデルなんかは明らかにOOADの時のモデリング論に相当影響してますよね。データモデリングという位置づけじゃなくてOOADとして。

羽生田：
そうなんですよ。あの時はデータ中心というより、もっとオブジェクト指向ぽかったんです。

増田：
概念モデルというようなものとして、オブジェクト指向が受け継いでるっていう感じはしますよね。もちろん、ミンスキーのフレーム理論なんか、これも概念モデルの話だと思うんですけどね。

抽象データ型の欠落

増田：
私はそういう意味では、プログラマーという方がホームグラウンドで、この中だとやっぱりSimulaと抽象データ型の影響はすごく大きいので……さっきの冒頭の話に戻っちゃうんだけど、抽象データ型ぐらいはベースにわかってよ、みたいな感覚が逆に今全然通用しない。

羽生田：
なので、オブジェクト指向の説明の中でも、その抽象データ型をちゃんと理解した方がいいよっていうのを、かなり冒頭で述べたんです。

増田：
そうですよね。羽生田さんの資料に、何度も繰り返し出てきてて。
Howの話は課題がいろいろあるなと思うんだけど、Whatっていう意味では抽象データ型の話はひとつのキーアイテムなんじゃないのかなって個人的には思ってるんですよね。ここの欠落は結構、課題かなーと。

羽生田：
抽象データ型っていった時に、インターフェースっていうので理解する人も結構いて――まあ、それはそれで重要な半分の側面なんですけど――ただ、操作の間に代数的な関係があって、それらが有機的な全体的な操作のセットとなってるんだっていうのも含めて、抽象データ型なの、本来。

増田：
うん、そうですよね

羽生田：
そこまで考えると、増田さんがずっと重視されているようなビジネスルールっていう話につながっている。

増田：
なんていうか、インターフェースっていうふうにしちゃうと、意味論っていうのかな？なぜこの機能セット……操作セットあるんですか？っていうことが非常に曖昧になって。
インターフェースにしたらカッコよくなるみたいな、抽象化してるみたいな……いや、そうじゃないよね、っていう。
実装クラスであっても、メソッドというか、操作の集合をきちんと設計できていれば、それはかなり抽象度の高い設計になってるはずなんで。というあたりがね……

羽生田：
そうなんですよ。publicとprivateでちゃんと仕分けさえしときゃいいんだろう？　みたいな表層的な理解になりがちなので……やはり、抽象データ型というところから入った上で、Javaならインターフェースを使ってって話になると思うんですけど。
ちょっとそこは、抽象データ型っていうのをちゃんと理解してもらった方がいいかなと。

増田：
そうですねえ……。

羽生田：
やっぱりそういう意味で言うと、スタックとかってのはすごくいい例で。

増田：
そこら辺はね……ずっとスタック、スタックでやってきたんだけど、スタックから抽象データ型っていうのは、今の若い人向けの教材としては、まあvalidじゃねえよなっていう（笑）

羽生田：
（笑）
モダンな例があるといいんですけどね。

増田：
私なんかは抽象データ型って言い方をしないんだけど……もう割り切っちゃって。
現場で何してるかっていうと――Javaなんで、私だと――StringとかLocalDate型とかの設計の……メソッドの一覧だけ見せて話をする、みたいなことは意識してやるようにしてるんですよね。
さいわい最近IDEだと、ドット打つとそこの型に対するメソッド一覧がすっと出るから、あれが抽象データ型の具体例という形で日々実感できるんでね。
そこの一覧が、綺麗になるとか、わかりやすいとか、使いやすいとか、安定してるってありがたいよね……みたいな、そんな話はしてるんですよね。
それでもなんか、うんわかったって言って、抽象データ型にくるわけじゃないあたりが悩みなんだけどね（笑）

羽生田：
（笑）

「ゆる」抽象データ型と数学的な厳密性

羽生田：
ただね、数学的な意味での本当の抽象データ型って、なかなかそんなに現場、業務で作り出せないので。そういう意味で「ゆる」抽象データ型って言ってるんです。

増田：
あ、そうそう、そこもちょっとお聞きしたくて。
その数学的に厳密なっていうのは、実は私、ちょっと直感的にわかってなくて。
羽生田さんが厳密だっておっしゃっている、その「厳密」っていうあたりは、どんな特性……というかを指しておっしゃってるんですかね？

羽生田：
isNullってやって、trueが帰ってきた状態で、push、pushってやって、pop、popって言ったら、またisNullがtrueになるよみたいな。

増田：
ああ、ああ、そっか、そっか。さっきの関係性って話ですね。操作のね。

羽生田：
それが業務だと、そこまで全部の操作に関して、そんなことできないから。

増田：
あー、そうですね、なるほど。そこもね、やっぱでも、ある意味、現場感覚で言うと悩みなんですよね……。
現場ですぐ役に立つものだけでしか見ないと、歪んだり抜け漏れができるので。
論理的な体系として、ちゃんとした過不足のないセット、しかも関連づいたセットとしてメソッドを考えてくれるといいんだけど、なかなかそこがね……

羽生田：
だから抽象データ型で、「pushとpopは対称性がないとダメだよ」みたいなのを意識しておいて、だけど、ちょっと現実的にはそこまでできないから……っていう意識のもとで操作を定義しようよっていうことです。

増田：
そうなんですよね。そうそうそう、そうなんですよ。
例えば私が現場で例に使っているのが――これも伝わらないんだけど、Haskellの型クラスはすごく私自身参考にしてるんで――Number型っていう、4つの演算があるっていう、あれはやっぱりちゃんと押さえてほしいんですね。
だけど、実装クラスにした時には、addとsubstructはあるけどdivideはないよ、とかっていうのは当然あるんだけど、それを、きれいな体系の中の、こう部分的な……

羽生田：
はいはい、まさにそういうことですね！

増田：
そうなんですよね！それはそう思うんだよな。
なんか、仕様書にあるからaddが出てきました、仕様書に出てきたから突然なんか割り算入れましたって。だけどおいそれ大丈夫か？　同じクラスでそれやって？　みたいなね……そういうことか。厳密って。あ、なるほど。いいなあ、おれすげー勉強になってんだけど（笑）

羽生田：
（笑）

増田：
いやでも、私個人的にはこれ聞きたくて、羽生田さんとの時間を……

羽生田：
なるほどー……そうか、「ゆる」抽象型って伝わってなかったのか。

増田：
いやー……正直言って、やっぱり現場の感覚からするとわかりにくい、というか伝えにくいことってたくさんあると思ってて。

若い人たちにどう提案していくか？

増田：
そこらへんって――UMTPの活動もそうなんですけど――これからの若い人たちに、どう・何を提供・提案していけばいいのかっていうことに、すごく関係してくると思うんですよね。
正直言うと、いやいや概念的には4つメソッドがあんのかもしれないけど……とかそんなこと関係なくて、「addがありゃ便利だからadd生やしました！」みたいな（笑）

増田：
……ことでアプリケーションができちゃってるのもまた現実だと思うんですね、今の。

羽生田：
（笑）

羽生田：
そういう意味で言うとね、業務で、例えば、経理では、経理の基本的な概念でバランスがちゃんと整ってなきゃいけないよ、だから入りと出が両方あるような……

増田：
対称性とか。

羽生田：
うん――数学的な抽象データ型は難しいけど――業務の世界の対称性とか、こっち引っぱったら後で入れとかなきゃいけないよ……みたいな意味の操作の対称性とか、一番最後がバランスしているって確認とか、業務上の常識みたいなものは理解した上で操作のセットっていうのを考えないとダメですよ……っていう話につながっていくのかなと思うんですけど。

増田：
そうですよね。そういう意味で言うと、今度はStringとかLocalDateなんかは、必要以上に操作をかき集めちゃってるんで、抽象型の説明としては、今度は逆にノイジーすぎるんですよね……

羽生田：
まあ、その辺も現実的な解として。
今そういうところに落とし込まれてるってことだから…
必要悪なのかもしれないですけど。

増田：
そういう意味では――これちょっと個人的なテーマなんですけど――抽象データ型っていうキーワードでも、日付演算ってめちゃくちゃ面白いと思ってて。
これはビジネス的にもすごく重要だっていうことと、いわゆる数学的なモデル――という言い方がいいかわからないけど――からずれちゃってるものなんで、そこが、日付の扱いの抽象化っていうのは、すごく面白いなぁと思ってて。
で、どうしても言語の……それこそJavaのLocalDateとかLocalTimeだったら、業務よりも必要以上に汎用化されてる。
あれ？今ナノセックまで取れちゃったっけ？LocalTimeだと、多分そうなんだよね。ミリじゃなくてナノセックまで取れちゃう。

羽生田：
はいはい。

増田：
それ使うと、LocalTimeって言った瞬間に、業務的には五時半とか扱いたいのにナノセックまで持った型を使ってるっていうあたりの……僕すっごく違和感があって、速攻でラップしたくなっちゃうんですよね。そこら辺の感覚なんですよね。

羽生田：
タイムレコーダーの時刻型として、それじゃあちょっと業務に合わないですよね。

増田：
そうそう、BigDecimalなんかもそうですよね。
あんな天文学とか素粒子の計算モデル作れるような数値を扱えるものを、固定小数点扱いたいからっていう理由だけでBigDecimal使ってるあたりに……そこでまあ何も――正直言って――疑問も思わない……。
割り算なんかも、うっかりするとわけのわからない精度までデータ持っちゃってて。
そういうところのね……なんか感覚がね……なんとかしたいなっていう。

羽生田：
本当はね、ビジネスルールを記述するための基本的な語彙っていうところに必ず時間とか日時とかあるわけですよね。

増田：
そうそう

羽生田：
あるいは祝日とかね。そういうのが、業界ごとに本当はちゃんとしたライブラリみたいになって流通してるといいんでしょうけど。

増田：
それでね……（笑）

羽生田：
（笑）

増田：
そういうことをいちど、まあ、結構そっちに振ろうかなあと思って……。業界ごとにXMLの標準化しようとか――EDIの絡みでやったりとか――ていうのはあってみたりとか。Javaなんかでも、Moneyとか、ライブラリって提供されてるんですけど……。
やっぱね、現場感覚からすると汎用的すぎるんですよね。
これを理解してから目的特化のやつ作ろうねっていうのは、ちょっとやっぱハードル高すぎるのかなっていうね。
でもね、設計の参考にはしてほしいんですよ。そういう汎用的なモデルをね。
「氏名」って言っても、HRXMLっていう、人材関係のデータモデルを扱う、ERPベンダーがお互いの人事データを交換するための標準があって。
それなんかを見るとね、人の表現の仕方……名前ひとつ取ってもミドルネームっていう構造があるよねとか、キャリアの表現の仕方のモデルとか、すっごく面白いんだけど、読みとくだけでもプロジェクト終わっちゃうくらい凄いんですよ。
そこら辺の――なんていうのかな――参考になるものはあるんだけど、そこら辺うまくちょちょいとこう、自分の今の目的に合わせて使う、みたいなことができたらいいんだけどな……みたいなね。