出版までの経緯
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、データモデリングでドメインを駆動するとはどういうことか、です。
前回、この書籍について、私自身が読んだ感想というか、考えをいろいろお話しさせていただきました。
今回は、この本の著者である杉本啓さんをゲストにお招きして、いろいろ質問をぶつけて、杉本さん、ご自身の言葉でいろいろ語っていただきたいなと思っています。
エンジニアリングマネージャーの問題集。今日はゲストに杉本さんをお招きしておりますので、いろいろ最近出版された本について語っていきたいなと思っています。
まず最初に杉本さんの自己紹介を軽くお願いできますか。
よろしくお願いします。杉本です。
今、フュージョンズという会社を設立して経営しておりまして、これは経営管理のシステムということで、おなじみないかもしれないですけども、予算管理とかそういった分野のソフトウェアです。
この本を読まれた方はSOAとかSOMという言葉をご存じだと思うんですけど、SOMの部分ですね。
そこに多次元データベースとかそういったことができます。
そういったものを中核にしたソフトウェア、クラウドサービスをご提供しているという会社です。
もともとアンダーセンという会計事務所系のコンサルティング会社にいまして、ただソフトウェアをすごく作るのが好きで、こういったものを作ればいいなと思って独自したと。
そういう次第でございます。
ありがとうございます。Fusionsも杉本さんが結構たくさんコードを書いて作られたシステムですよね。
そうですね。初期は私がいなかったので。
ただ今はもう開発チームはしっかりありますので、ほとんどそちらの方にやっていただいているような状態ですね。
なるほど。ありがとうございます。
というわけで、今日は本の話の方に入っていきたいと思っておるんですけれども、
まあ私のポッドキャストなので、本の内容とかテクニックとか以外に、やっぱり杉本さんご自身についてとか、
その辺りも私の個人的興味の部分があるんですけれども、伺いたいなと思ってまして。
最初に、このデータモデリングでドミンを駆動するという本について、出版に至るまでどんな流れがあったのかな、みたいなところから伺ってもいいですか。
杉本さんの自己紹介とフュージョンズについて
記録を洗い直してみますと、2020年の10月から始まってまして、
その時に技術評論者のWebプラスDBプレスというところで、一度特集で少し書かせていただいたことがあるんですね。
その時に編集の久保田さんという方が、データモデルについて何か書けないかというふうなことを言ってくださって、
データベース設計の本は世の中にたくさんあるんだけれども、それと実際のデザインみたいなところとうまく結びつかないと。
久保田さんという方は、それまでにOOUI、オブジェクト思考のユーザーインターフェースの本も担当されてて、
そこら辺とのつなぎっていうのはないのかなというふうなことを言われて、面白いなと思ってそれに乗ったというのが直接のきっかけです。
なるほどなるほど。じゃあ、私のイメージだとこういった本を書くときって割と執筆する側が企画とかを失礼で持ち込んで執筆する流れになるというのが一般的かなとか思ったりしてるんですけど、
今回逆というか、技術評論者さんの方から何か提案があったということなんですね。
そうですね。そういうふうなデータベース設計と、それからユーザー向けの設計の間にギャップがあるなみたいなところを久保田さんが気づかれて話を持ちかけてくださったと。
あと、中のこんな内容でしたらどうでしょうかというところは私の方で書きましたけれども、直接にはそういう流れだと思います。
ちなみに、そうやってお話が来たは来たとして、とはいえ結構この本に書かれている内容ってものすごく広い範囲のことを扱っていらっしゃるなとも思うんですけれども、
こういう企画自体は杉本さんの中にはある程度材料があって、ポンというふうに出てきたような感じなんですかね。
そういう面はありますね。私、昔からの機関系システム、最初は生産管理システムをやって、そのあと会計系が多かったんですけども、
そういうのをやっていて、いつも思っていたのが毎回同じようなことをやっているなと、同じような検討をして、同じようなことを言って作っていくと。
なかなかいい形で蓄積されていないなというのはずっと思っていました。
そういうのを書いてみたいなと。データモデリングとかいう基本的な関数留属性とか正規化とか、そういう知識があったりするんですけども、
じゃあそれって業務システムという視点でどう役に立ってくるのか、あんまり分からない。それを一から検討してるというふうなことなので、
そこを整理していきたいなという気持ちは前からありました。
もう一つ、ある時期に私の方で連結決算のパッケージソフトを作ったことがあって、そこでどうしてもロジックがごちゃごちゃすぎるので、
DSLって言うんですけども、計算式みたいなのを定義した後から仕込めるようにしたいというふうに思いまして、
その時に読んだ本が、エイホっていう人が書いたコンパイラっていう、その方面では有名な本なんですけど、これを読んだんですね。
これを読んで衝撃を受けて、この本を読んだらコンパイラ作れるなと思ったんですよね。
それで実際、簡易言語みたいなのを作ったんですけども、それを見て、どうしてコンパイラの部分、領域ではこんな本があるのに、
僕らがずっとやってる機関系システム分野にはこんな本ないんだろうかと思って、ずっと気持ちに引っかかってたと。
それが、お声掛けをいただいて、うまく結びついたという感じかなと思ってます。
当然杉本さんぐらい、いろいろなところにかかってこられた方であれば、何らかの書きたい要素というか、パーツというものがあって、
かつそれをどうつなぎ合わせるかみたいなストーリーみたいなのが一定材料としてはお持ちで、
それに対して、美術評論者の方からのお声掛けで何かビビッとつながって、こういう本ができるんじゃないかなみたいな、なったという感じだったりするんですかね。
そうです。うまく合致したということだと思います。
ありがとうございます。なかなか面白いスタートで書き始めたということで。
でも2020年からとおっしゃってましたっけ、それぐらいからで3年ぐらい。
そうですね。実際に書き出したのはもうちょっと後ですけど、3年強になるかと思います。
なるほど、なるほど。でも結構長い戦いではありますよね。
はい。でも素晴らしい本が出版されて、私としてもすごくシステム開発、ソフトウェア開発の知見というか、
皆さんの人生みたいなものを一歩前に進めるような本になっているんじゃないかなと思って、すごくありがたいなと思っています。
そうですね。この内容そのものが本当にこのままで正しいのが適切なのかということよりも、
こういうものが枠組みというか手がかりになって、皆さんの知見とか知識とか経験というのが集積されていくようになったらいいなというような気がしてます。
本の中身の方に入らせていただきたいなと思っております。
中身、私自身も話したいパートみたいなのがたくさんあってですね、ぜひ杉野さんに直に意見を聞きたいなと思っておるところなんですね。
残の概念とその重要性
最初に触れたいポイントは、僕が個人的に前半の山場のトピックかなと思っているこの残という概念ですね。
残りという漢字を書いて、残と読むというところで、この概念が紹介されている、概念の紹介だけにとどまらずそれを使ってどういうふうにシステムの設計をしていくのか、
モデリングをしていくのかというところが、第4章で触れられておるんですけれども、この概念周辺についてちょっといろいろ杉野さんに伺いたいなというところなんですが、
そもそもこの残っていう概念に、どうして着目されたんですかというか、なんかきっかけみたいなのはあったのかとか、そのあたり伺ってもいいですか。
そうですね。残という概念自体は全然新しくなくて、機関系システムをやっている方は日々見ているような概念だと思うんですよね。
で、残があって、それに対して残を満たすべく予定を立てるということで引き当てということをするとか、その引き当てに対して実際に実績、何かのアクションが起きたら消し込みをするとかですね。
そういうことは日々行われてるんで、全然珍しくない概念だと思うんですけども、その割にあんまり残についてきっちり書いたものがないなという気もしてて、
一方で梅田さんですかね、グラス片手にデータベース設計という本を書いている梅田さんとか、あとデータモデルに渡辺さんとか、そういった残という方に触れられてると。
一方であって、何かおまけみたいに、これに注意するといいよみたいな形で書かれてると。
その残というのをどうしてこんなに重要層に見えるのに、あんまり主役級の扱いを受けてないんだろうかなというのが思ってて、
で、それを考えていくと結局、その残以外の要素っていうのがいろいろ混じってるんだけども、それっていうのは業務を回すために直接的に必要というよりか、
もう少し上位で業務全体の調整とかオーケストレーションをしてるんじゃないかなというふうに思って、
で、SOAとSOMっていうカスタムのシステムと経営管理のシステムっていう区分を考えたんですけども、それでなんかスッキリして残っていうのがやはりカスタムシステムの主役であるというふうに言っていいんじゃないかというふうに思ったと。
こんなことを書くかと思います。
なので、残というものには元々杉本さんが発明したとかそういうものではないと。
もうすでにこういう概念に着目してシステムを作ってるみたいなものは存在していて、
ただなんかこう主役になっていないというか、なんですかね、スッキリ整理されていなかったというんですかね。
このSOM、SOAみたいな区切りがなかったりしたということで。
そういうことですね。区切ったというところだと思います。
区切ることによってこの残という概念がより際立たせやすくなったというか、という部分があるんですかね。
ちなみに、私なんかで言うと、やっぱりあまりこの基幹システムの開発というところに直接的にたくさん関わったわけではないので、
あまりこの残という概念にそもそも着目するということ自体が割と新鮮に感じたというか、考えてみれば当たり前のことだったりもするんですけれども、
なんかシステム設計をそういう観点でやろうというふうには思ったことがなかったので、ここは結構新しいなと思ったりしたんですよね。
杉本さんのご経験ではここはもう普通に当たり前に存在していたってことなんですかね。
いや、必ずしもそうではなくて、やっぱりどんなプロジェクトでも業務フローに近くにするんですよね、業務の流れ。
本にも書いてますけど、業務フローという業務の流れと残というのは直交してるんで、残の方はどちらかというと後折になってしまうという感じがあると思います。
一般的に。
だから逆に僕らがプロジェクトをやるときには、業務プロセス、それが分かりやすいですからそれを見ると同時に、残の方で見たらこれって誰が残の消し込みとか責任を持つのかなとか、
そういう視点で横串を入れていくという形で見る場合が多いんじゃないかなと思います。
データモデリングの位置づけ
なるほど、なるほど。確かに、何でしょうこれって、その業務フローに着目するのって、僕はもう自然とそれが当たり前かのように行っていた世代というのが適切なのか分からないんですけれども、
そういうものだと思ってやってきてるんですけれども、これって何でしょう、杉本さんの方読んでるとそうではないというか、
もしかするとすでにERPだとかそちらの方の世界ですと、より残とは呼んでないかもしれないが、
別の切り口でのシステムの在り方というんですか、そういうものがそもそも考え方が違うと言いますか、
そういう世界がすでにあって杉本さんはそれを見てこられたというか、そういうご経験もあったということなのかなと思ってるんですけど。
そうですね、海外製のERPとか会計システムというのは、売りかけ金とか買いかけ金によるアカウントレシーバーブルとか、
アカウントペイアブルというモジュールになっていると、これはXANで区切っていると思うんですね。
欧米は特に内部統制とか各担当の責任をクリアに切るというところにすごく注意を向けているので、
XANというのが切りやすい単位、つまり一つのXANに対して発生から消滅まで全部面倒を見るという人が一人決まっているというのは一番分かりやすい形だから、
XANに着目してきたんだと思います。ただ彼らにしてみたらそれが当たり前すぎて、わざわざそういうふうにことあげしなくてもそうなっているということになったと思うんですよね。
一方で我々はフローで見るから、日本人は業務の中で連携するの得意ですから、
そういう方向で見てしまうので、なかなかXANというものがそこにあるんだということに気づきづらかったということかなと思っています。
これって仕事の仕方に対する考え方というか文化の違いみたいな。
そうですね。文化の違いがすごくあるような気がします。
逆に日本人ではない欧米スタイルというんでしょうかね。
の世界だと、XANとは言わないまでも、そういった責任の持ち方というんですか、何に責任を持つのかというんですかね。
何に責任を持たせるとうまく仕事が分離されるのかとか、責任が分けやすいのかとか、
その辺はわりとソフトウェアエンジニアでも当たり前に持っているような感覚というか、知識だったりするものなんですかね。
その辺は私もわかんないですけども、そうじゃないかな。結論から見るとそうなってるんじゃないかなという気がしますね。
結局、自分は何すればいいんだ。何ができたら俺の仕事は終わったことになるのかっていうふうなことを意識されてるんじゃないかなと思いますね。
ありがとうございます。
なんで、このXANの概念っていうのを私がスウィンマンさんの本の4章で読んだときに、本当に新鮮だと思いましたし、
それに着目することで、どこがXANに対して責任を持っている人、担当者というんですかね、がやるべきことなのか、
何をインプットして何をアウトプットするのかとか、その辺りがすごくクリアに、かつ他と疎結合にできるようなイメージが一気に湧いたんですよね。
これって素晴らしい、既にあったものかもしれませんけれども、新たに着目したっていう点ではすごく面白いものだなって思ってます。
でしょ?
そうなんですよ。
なんでしょう、このXANの不思議さというか、システムばっかり見てるとわからないんですけれども、
現実の業務でXANというものを中心に業務をさせようとしたら、絶対動機的に実行することが逆に難しいというか、
本質的に非動機にならざるを得ないというか、そういう性質のものに見えてきたりもするんですけど。
ここはそうですよね。
本人も書きましたけど、アジャイル開発するときのバックログリストってまさにXANですよね。
バックログがあるから、何を作ろうかって考える要件定義をする人たちと開発する人たちが一方で連携するけども、ある程度非動機に業務を進められる。
なかったら始終では一緒に行動して一緒に作るのかっていうことになって、それは非常に効率悪いですよね。
ですよね。
なんでしょう、バッファーといえばバッファーなんでしょうし、
何て言うんですかね、複数の人で別々の役割を持たせて動かそうとしたら何かその間に必要で、
バッファーのことを言ってるっていうか、循環的な話になっちゃうかもしれないですけれども。
そういう現実の世界で人と人がコラボレーションするときに何か役割の分け目をはっきり作ろうとしたら、XANみたいなものが出てくるのかなっていう。
そうですね。XANとそれからそれを中核にした活動のシステムっていうのは、
人と人が協働する際の、しかもある程度独立して協働する際の枠組みだと思うんですよね。
それは機関システムの一番基本形だと思うんです。
そうですね。機関システムなので、あるビジネスを成り立たせるときに必ず要求に応じてうまく動かねばならぬ者たちっていうような考え方をしてるんですけれども、
そこでどの部署だったりどの担当がどういう責任を持っていて、どんな要求に対して何をしなければいけないのかっていうのが、
XANっていう単位で組み立てるとすごくわかりやすいっていうようなものなのかなと思ってます。
そうですね。病院とかで診察終わって薬とか会計待ちのときにボードに番号が出る、あれXANですよね。
なるほど。単純に。
あれがXANです。
至るところにあるんですよね。
至るところにあると思います。
ここに着目するっていうのは本当にやったことがなかったと言いますか、
どっちかっていうとXANに対する入ってくる情報っていうんですかね。
例えば売上げの受注のXANであれば、1個1個の注文情報とかそういうものを材料にしてデータベース設計するみたいなのが僕のやり方だったかなと思っていて、
これってデータベース設計ではなくても、
ドメイン駆動設計みたいなのでソースコードを作りましょうみたいなときにも、
1つの注文情報をエンティティのネタにしたりだとか、
そういう1つ1つのインプットの方に着目しがちだったかなと思っていて、
そうじゃなくてXANっていうものがまず中心にあるんだよというような見方っていうのは、
本当に新しかったんで何度も繰り返し言いますけれども、
これ面白いなというところですね。
そうなんですよ。そこが難しいところで、
ユーザーが注文のインプットとかアウトプットなんですけども、
それって何で決まってくるかというと、
XANとして何を管理しておかなければ文業はできないのかという視点で決まってきてると思うんですよね、きっと。
うん。
直接的にインプットアウトプットが決まって、
それはたまたま記録されてるという話ではないんだと思います。
なんかシステムを作るときに、
インプットとアウトプットは当然ネタにはなるんだけれども、
でもそうではなく何を管理しているのか、
どういう責任があるのかっていうところを見出した方が筋がいいよっていうような話でもあるんですかね。
そうですね。
昔から言われたPoA対DoA、プロセス思考とデータ思考っていうのもそこだと思うんですけどね、結局。
プロセスっていうのは業務の流れを見てると、
そこでインプットアウトプットが出てくると。
ただ実際に管理したりというかやらなくちゃいけないのは、
作業を分担するために後続に対して何を伝えなくちゃいけないかというところで、
それ自体はプロセスには出てこないですね。
うんうんうん、なるほど。
それと非同期で実行される別のプロセスに出てくるわけで。
なんかやっぱり非同期性みたいなところがどうなんでしょう。
ソフトウェアとして表現するときにあまり重視されてこなかったのか。
それは技術的な背景とかもあったりということなんですかね。
人間の仕事の分業というのを見るとほぼ非同期なんですよね。
大体の場合、いろいろな人たちがある程度時間差を置いて連携してやっていくということなので、
人の仕事自体はすごく非同期だと思うんですよ。
もともとコンピューターシステムとかでも非同期的に作られてたと思うんですけども、
データベースというのができてみんな驚いたんですね、きっとね。
同期にできるんじゃないかということなんですよね。
一気に同期、それから全部一元管理というところに行ったと思うんです。
今、マイクロサービスとかいうことで分散化っていうことが言われてるのは、
それに対するアンチテーゼという面もあって、
全部一つにしてしまったら非常にユーズが効かないシステムができてきたという認識が多分多くの人が共有してて、
それでこういうような流れになってきてると思うんですよね。
ある意味先祖代わりというか、
昔してた姿をもう一度今のテクノロジーで見直してみたらどうなるかっていうことを考えればいいんだと思ってます。
ですよね。
確かにおっしゃる通りなところはすごく頷ける部分が大きいと言いますか、
技術によってモノリシックにものを作るというか、
同期的にものを作ると言いますか、
それって多分何ですかね、非同期にものを作るってやっぱり難しさが一定あると思うので、
それに対するより簡単な作り方っていうんですかね、
ある種そういった方向で一気に流れてきたのかなと思うんですけれども、
あるものは簡単になってもあるものは複雑になるというか、
結局トレードオフがあるっていうだけの話なのかなというところなんですかね。
そう思います、はい。
はい、というところで、ざんという概念のお話が4章にあって、
私としてはこれが一番驚きだったというところと、
前半の山場みたいなところだと思っているので最初に取り上げました。
ちょっと別のトピックの方に移りたいんですけれども、
もう一つ私としては、何ですかね、
自分自身の理解が足りなかったなというか、
改めて気づかされたところがありまして、
これ本の章立てで言うとちょっと戻って3章とかで書かれていることだったりするんですが、
データモデリングというものは何でしょうかね、
どういう位置づけなのかというか、
正直言うと私自身はデータモデリングとデータベース設計を
頭の中では理解して区別できていたつもりでいたんですけれども、
やっぱり実践していることは私はデータベース設計としてしかやっていなかったなというのが、
改めて杉本さんの本を読んで気づいたことでして、
杉本さんの本に書かれているのはデータモデリングというのは、
データモデルというのがユーザーのメンタルモデルですというのが何回も繰り返し書かれていることで、
繰り返し書いていただいたことで、私が自分の認識がだいぶ間違っていたなというふうに改めて気づくことができたんですよ。
このデータモデリングというのを、データモデルというのをユーザーのメンタルモデルですというふうに位置づけるのって、
他の方もある程度そのようにやられている。
例えば渡辺幸三さんのアプローチもそれに近いというか、ほぼそれをやられているとは思うんですが、
明示的にそのようにはおっしゃってくださってなかったなと思っていまして、
データモデリングの位置づけとユーザーのメンタルモデル
改めてこの位置づけを明確に提示されているのって、すごく面白いなと思ったことだったりするんですよね。
ここって杉本さんのそのようにすべきというか、それは当たり前だよということかもしれませんけれども、
何かここについて改めてお話を伺っていただけますかね。
私はユーザーと実際に話しながら設計していくということをずっとやってきたので、
ユーザーに話してキョトンとされることと、それそれと言ってくれることがあるわけなんですよね。
例えばサロゲート機にしますか、ナチュラル機にしますかみたいな話をユーザーにしたら、
キョトンとしてそれって僕が決めるの?みたいな顔をされてしまうわけなんですよ。
一方で在庫の持ち方どうするかみたいな話をすると、それそれみたいな話になってくるんで、
やっぱりユーザーから見て関心があるというかユーザーが決めなくちゃいけないことと、
それからユーザーからしたらそれってエンジニアの方で決めてくれないの?ということがあるというのはずっと思ってたんですね。
別にこれも私が言い出したことではなくて、本にも書いてますけど、
椿先生が実装独立ということで言われてたのは多分そういうことだろうなと思うんですけども、
中身の仕組みではなくてユーザーから見てどういうふうにデータが見えるのかというところ、
それを区別してデザインすることが必要だなというのはずっと思ってました。
この本で新たに追加したのはデータモデルの透過性という概念で、
ユーザーから見て総合変換可能であればそのデータベースってユーザーから同じデータモデルですよねという話なんですよね。
サロゲートキーを作っていてもそれをナチュラルキーのデータベースに置換できるのであれば同じですよねと。
ユーザーから見たら同じですよねと。
そういう透過性の概念というのを入れたことで、より椿先生の実装独立みたいな概念、
ユーザーのメンタルモデルという概念を明確に線引きできるようになったかなというふうに思います。
もともとのアイデア自体はオリジナルでは全然なくて、こういう人たちがずっと言ってきたことかなと思ってます。
そういうふうに過去、実装独立みたいな言い方で言われてきたことを、
杉本さんご自身もユーザーとの対話みたいなところでそうだよなというふうにご経験されながら、
ご自身の考えとしても確立されてきたというようなところなんですかね。
そういうことですね。
あと、透過性というようなところで、これって若干新しいものだと思っておるんですけれども、
素朴にユーザーのメンタルモデルですみたいなふうに言うと、ユーザーが思っているものイコール、
完全にそのままデータモデルですみたいに思いがちなのかなと思うんですけれども、
杉本さんの言われていることって、ある種ユーザーの中にあるものが若干抽象化されているというか、
そもそも多少の具体のバリエーションみたいなものは吸収可能というんですかね。
そうですね。メンタルモデルであるということと、完全にそのある人の考える通りである、
主観的であるということは違うと思っていて、
言葉として、間主観性という言葉を使っているんですけれども、
客観的とは言えないけれども、お互いにユーザー同士で合意ができるねという、
そういうものがあると思うんですよね。
このシステムで在庫っていうのは、商品コードと倉庫ナンバーの組み合わせごとに在庫数が管理されてますよねっていうのは、
ソフトウェアを使っているのはわかることで、そこについて不一致がもしあったら実際に使ってみればわかるはずなんですよね。
そういう意味で、具体的には見えてないけれども、
ユーザーとしてはこう考えているというのが複数のユーザー内で合致する、
そういうのをメンタルモデルと呼んでます。
だから、主観的ということではないんですね。
間主観なんですね。
間主観ですね。
フッサールっていう人が言った言葉だけど。
その辺りに行くと話がどんどんそっちに行ってしまいそうなので一旦くぐりますけれども。
でも、少なくとも僕はこのユーザーのメンタルモデルっていう位置づけにあるっていうところが、
まず改めて発見だったっていうことなのと、一定その間主観であるっていうのも、
過去に杉本さんとメーディングリストとかでそのトピックが出てきたのをかすかに覚えてはいるんですけれども、
改めて言われると、自分の中ではもっと主観的というか、
ものすごくもっと具体的なものをメンタルモデルと呼んでたり、
データモデルと呼んでたりしたんだろうなというところがあったので、
情報システムとソフトウェアのモデルの違い
そこも少しギャップがあったなというところで改めて、なるほどと思った次第ですね。
本当にこの本を一つずつ取り上げてお話したいことがいっぱいあるんですけれども、
ちょっと次のところへ行きますと、第7章の辺りですかね。
よりソフトウェアエンジニアにとって面白い話題というのかな。
どういうふうにソフトウェアをユーザーにとって使いやすい形にしていくのかとか、
そういう工夫のしどころみたいな設計の話なのかなというふうに思っていて、
ここにもこの本なりのユニークさといいますか、
データモデルでそこにどうアプローチするのかみたいなお話が書かれていて、
面白いなと思って読ませていただいているんですけれども、
まず最初の方に情報処理システムとソフトウェアとは違うんですよというようなことが書かれていて、
この辺りも書いていただかないと私自身見過ごしてしまうような定義の仕方なのかなというふうに思ってまして、
ここもきちんとせっかくなのでこの場でも共闘しておきたいなとか思ったりしておるんですが、
ここがドメイン駆動設計とかあらゆるソフトウェア設計のトピックで、
ちょっとうまく定義しきれていないなというか、
何か定義する必要もないのかもしれませんが、
共通認識がソフトウェアエンジニアの中でも持てていない部分だったりするのかなと思ったりもするんですけど、
杉本さんとして改めて書かれたことって何か意図というか何かあったりするんでしょうかね。
全く今おっしゃっていただいた通りで、
情報システムのデータモデルとソフトウェアのデータモデルは違うよと言ってるんですけども、
そのこと自体が何というか少し微妙な話で分かりづらいというのと、
そうですね、分かりづらいというのは一番大きいですよね。
中で書いている例ではExcelで有志力を作る例を書いているんですけども、
Excelというのはソフトウェアですよね。
それでそこで列とか行とかセルとか、そういうデータモデルだと。
データモデルというと違和感ある人はあるかもしれないですけど、
ユーザーにとってのデータを何らかの形で実情立てて管理しているという意味で
データモデルと呼んでいいと思うんですよね。
この本の定義では。
Excelで有志力を作ると郵便番号欄とか住所一覧、住所二覧とか電話番号欄とかいっぱい出てくるわけで、
それは一つのデータモデルなんですね。
有志力のデータモデル。
これが情報処理システムのデータモデル。
そうなってくるとユーザーが使っていく情報処理の仕組み、業務の仕組みにおけるデータモデルが
そのために使う道具であるExcelのデータモデルとは違うんじゃないかと。
こういう話になるわけですよね。
僕らはどっちを設計しているんだというのがずっとついてまわる問題で、
昔の、僕が仕事を始めた頃は主にいわゆるウォーターホールだったんですけども、
それでは主には情報システムのデータモデルというのを意識していたように思うんですよね。
なるほど。
今のオブジェクト指向とかアジャイルとか、そういう流れではどっちかというと
ソフトウェアの方のデータモデル、ソフトウェアのモデルというのを意識していると。
それが先ほどおっしゃられたドメイン駆動設計とかそこら辺にも引き継がれていると思うんですけども、
そういうのがあって、だけど実際にはやっぱり両方見ないといけないんじゃないかなと。
両方マッピングさせるということが必要じゃないかなというのが一つよく思っていることです。
ドメイン駆動設計みたいなワードが今出ましたけれども、
この本でも杉本さんの考えは書かれてるんですけれども、
なんかそのドメイン駆動設計を通った身として感じるのは、
情報システムとソフトウェアの設計の関係性
あの本を読むと、今杉本さんがおっしゃられた2つのモデル、
情報システムの方のモデルとソフトウェアの方のモデル、
これを一つにしましょうというか一緒にしましょうみたいなことがある種書かれてるのかなというふうに思うんですよね。
どうですかね、あの本は情報システムのモデルとソフトウェアのモデルという区別はそもそもないかな。
ソフトウェアのモデルに関して、私が言うメンタルモデル、
それが分析モデルと呼んでますけれども、それと実装上のモデルというのと区別してるのかなというふうに思いますね。
情報システムのモデルとソフトウェアのモデルに関してはそれほど区別、線引きしてないのかなというふうに思います。
ありがとうございます。
話を戻しますと、そもそも情報システムのモデルとソフトウェアのモデル、
もしくは情報システムとそれを支えるソフトウェアというのは違うんだよというような素朴な話かもしれませんけれども、
ここ自体、ともすると杉本さんが先ほどおっしゃられた、過去に杉本さんがやられたのはやっぱり情報システム側を設計するというか、
いうようなことだったというふうにおっしゃられてて、私もどっちかというと、
情報システムそのものを作ってる感覚でソフトウェアを作ってきたと僕は思っていて、
なのでここがイコールになりがちだったんですよ。実際はイコールではないんですけれども。
なので、じゃあ情報システムを支えるための道具として改めてソフトウェアをどう設計するのかというふうに分けて考えるというところは、
これはこれで改めて見直すべき観点なのかなと思った次第なんですよね。
そうですね。私は仕事を始めた当時は当然ドメインのことが分からないので、
基本的にはユーザーの方の検討を支援していって、ユーザーの方が考える通り作っていくというしか手がないんですよね。
だから情報処理システムの設計をしているということになるんですけれども、
どっちかというと補助的というか、ガイドはするし、不正語があったら見つけるとかそういうことはしますけれども、
ユーザーの意識が主流ですよね。
その中で自分がエンジニアとしてキャリアを積む中で、とはいえ長い年間使っていくんだから柔軟性を組み込む、
簡易性と呼んでますけれども、簡易性を組み込むということで、一部ビジネスロジックをテーブル化するとか、
そういうことで仕組みを組み込んでいくと。
そうするとソフトウェアと情報処理システムというのがイコールではなくなっていくんですよ、だんだん。
だからそういうところは私自身は自分がエンジニアとしてデザインという設計ということに入っていく入り口になったと思うんですよね。
だから多分多くのエンジニアの人にとってここの第7章であったような情報システムとソフトウェアをずらしていくというところは、
ドメインモデルの役割と考え方
実際大事じゃないかなというふうに思っていて、この章は特に思い入れがある章ですね。
そうですね。私自身、ここを改めて読んだときに、私がプログラミングが好きになるというか、ソフトウェアを作るのが好きになるというか、
そういうところもやっぱりどういうふうにすれば繰り返し発生するようなものとか、同じようなものを何個も作るみたいなのを回避できるのかなっていうところから工夫を始めたみたいなところの現体験があったりするので、
それと非常に近しい部分でもあったりするかなと思うんですよね。
だからそれが、この杉本さんの本の枠組みというかいうところの言葉でいうと、情報処理システムのモデルとソフトウェアのモデルというのは違うよっていうようなところに、
改めてそこを明確に意識して、ソフトウェアのモデルを今作ってるんだよとか、情報処理システムのモデルを作ってるよとか、区別することでよりいろいろな物事が整理されるということでもありますよね。
はい、相当通りなんですね。
そこから一つ発生して、ソフトウェアの方に道具性を持たせるというか、可変性を持たせるというかいうところが書かれている章でもあるんですけれども、ここも改めてフォーカスしたいと思うのは、
ソフトウェアの道具性というのが必ずしもコードばかり書いていると、我々がコードを変更しやすいことにばかり執着してしまいがちなような気がしておりまして、
そうではなくて、もっといろいろなソフトウェア自体を変更する方法というのがあるというところに意識を向けるというんですかね。
どういうふうにあるとシステム自体が可変であるのか、ユーザーにとってもさらに柔軟性を持たせられるのかというところまで、道具として持ちながらソフトウェアを設計するというか、
そういうところはちょっと忘れちゃったりするかなというふうにも思ったりしましたね、ここは。
誰のための可変性かという話が大事で、開発者にとっての可変性、変更容易性というのはもちろん大事なんですけども、
やっぱり道具である代わりには使っている人にとっての可変性とか、使っている人の状況に合わせて合わせ込んでいけるとか、
そういうことはすごく大事かなと思うんですよね。
そうしてこそ使っている人が道具に使われているのではなくて、自分が道具を使っているという形になって、そういう工夫ができてくる。
それは結果として情報処理システムと道具の発達につながっていくというふうに思うので、やっぱり使い手にとっての道具性というのはすごく大事だと思います。
そこを当ててやるということが肝なのかなというふうに思ってますね。
ソフトウェアとドメインモデルの関係
ここはやっぱりソフトウェアエンジニアとしての常事といいますか、どの程度そこを作り込みにいけるのか。
もちろんコストパフォーマンスとかも考えながらやらなければいけないところなんでしょうけれども。
最終的にドミニトッカー言語からさらに進んで、ジェネレイティブなソフトウェアとかそういうところにいけるといいなというのは、
昔、今すぐもその会社で仕事されているコボさんとかとすごく話したことだったりもするので、夢が広がる領域だったりもするんですよね。
そうですね。それと、かえってその、何て言うんですか、そういう可変性を作りにしたほうが、ロジックとかコード自体はシンプルになるという面もあると思うんですよね。
ビジネスロジックって本当にもうセンサー版別とか状況に応じていろいろあるけれども、やっぱり変化の仕方ってある一定の枠で収まることが多いので、
その枠を変えていった方がソフトウェア自体はシンプルになってメンテナンスしやすくなるという面もあると思います。
ちょっと今のところ、もう少し深掘りたいというか話を続けたいんですけれども、本にも書かれていることではあるんですけれども、
何がビジネスロジックなのかだったり、何を分離すべきなのか、もしくは閉じ込めるべきなのかみたいなところが、
ここもそんなにコンセンサスがソフトウェアエンジニアの中でもない部分なんじゃないのかなと思ったりするんですよ。
例えばクリーンアーキテクチャーみたいなものってビジネスロジックというかエンティティというか、
その辺のものを一番中心のところで大事に大事に分離して作りましょうみたいな、
素朴に説明するとそんな感じなのかなと思うんですけれども、杉本さんの今のお話ですと、本にも書かれているんですが、
ビジネスロジック、ある種のビジネスロジックはものすごく変更されるというものなので、
そういうものこそ他の構造、データとか帳簿的なものから分離して管理したほうがいいでしょうというような提案ですよね。
そうですね。まずビジネスロジックって一般的に言うときの言葉が、いわゆる最近の言葉で言うと改造度が低いというか荒いと。
例えば会計で言ったら借り方貸し方といういわゆる複式募金の仕組みっていうのがあって、
その上で費用を各部署にどう配分させるかという配付の仕組み、これ大内緒で出しましたけど配付の仕組みってあると。
そうするとどんなふうに配付するのか、どんなふうに費用負担を各部署に例えば賃料を割り付けるのかというのは、
これはその時々変わってくるけれども、基本的な帳簿の仕組み自体は変わらないんですよね。
その両方をビジネスロジックって言っちゃったら非常に検討が進みにくい。
本当はそういう安定した部分、安定した複式募金みたいなのが帳簿のデザインと捉えて、
ビジネスロジックはそこに織り込むような、むしろユーザー側で指定できるような可変的な要素であると。
我々は可変的な要素に対してソフトウェアを作っていくのではなくて、
普遍的な要素を表現するようにソフトウェアを作っていくと思うので、
可変的な要素っていうのはここで言っている、レーブ駆動方式とか、ESLであるとか、
ドメイン駆動設計の理想と課題
そういった方式でもって可変化していくというのが筋かなというのは、根本的にはそういう考えがあります。
そうですね。どうなんでしょう。
これってどういうものを扱っているのかによっても考え方が違ってくるものだと思いますけれども、
ただ一般論としても今のことって言えるものだと思うんですよね、改めて。
何を切り出していくのか、より変更頻度が高いようなものってどういう種類のものなのかというところに関して、
もう少しソフトウェアエンジニアの中でもコンセンサスというか認識が広まるというか、
より研究されるということがあるといいなというふうにこの本を読んで思ったりしましたね。
そうですね。そういうのは結構ドメインに依存することだと思うので、
やっぱり特定のドメインにどうかという話があって、
それを基に一般化すればこうじゃないかという話があるべきだと思いますね。
今はそういうのがなくなって、下りでビジネスロジックはとか、
そういう話になってしまうからよく分からないんで、やっぱり個別具体的なところから抽象的な一般論に進んでいかないといけないのかなと思います。
では最後のショーの話の方に進ませていただきますが、
最後のショー、より私もこのポッドキャストでドメイン駆動設計とかを取り上げてきたりしておりまして、
杉本さんの方では、そうですね、14章と最後の章でドメイン駆動設計自体に対する杉本さんの解釈というかという部分と、
そこからさらに杉本さんご自身がどういうふうに考えていらっしゃるのかというところが書かれているところではあるんですけれども、
一番最後のところで言うと、やっぱりこのドメイン駆動っていうようなことではなく、
ドメイン駆動って日本語にするとドメインによって駆動されるっていう受け身的な役になるのかなと思うんですが、
杉本さんはその方向を逆転していて、ドメインを駆動するというふうに本のタイトルにも付けられているものだと思うので、
ここにやっぱり強い杉本さんの主張というか夢というか、そういうものが込められているんじゃないかなと思っておりまして、
この辺りも杉本さんの思いというか、その辺りも改めてお聞かせいただきたいなとか思ったりするんですけれども。
ドメインモデルとは、例えば福祉規模型の仕組みにしても、生産管理の部品表にしても、
DDD版に出てくる船西本県にしても、全部ドメインモデルなんですけれども、
ユーザーと言いますか、実際にその仕事をしている人々というのはずっと作ってきたものなんですね、歴史的には。
ただ今ってちょっと時代が変わってきて、ITができたということで、デジタル技術がある。
そうするとユーザーの人たちがすぐ作れるかというと、だんだん作りにくくなってきているんですよね。
そうすると誰が作るのかというと、エンジニアの方が作るかというと、今ちょっとお呼び越しにも見えると。
やっぱりそこで宙に浮いてしまっていると思うんですよね、ドメインモデルを作るという責務がどこにあるのか。
それをやっぱり僕としては、今のITにまず一旦は身を浸したエンジニアの人々が入ってくる。
もちろんユーザーから入ってきても全然構わないんですけれども、そういう人たちもITに身を浸してもう一度ユーザーワールドに戻っていくと。
そういう間のところに人々の集団がいて、そういう人たちがドメインをよりうまく回すための仕組みというのを考えていくというのが
理想かなと思っています。それをドメインドライビングデザインというか、ドメインを駆動する設計ということで言ったという、こういうことですね。
この本の中で書かれてますけれども、ドメインモデル自体は情報処理システムのモデルではなくて、ソフトウェアの方のモデルですというような
制御されていて、よりその道具としてのソフトウェアのところをどううまく設計して、それをドメインの仕事というか、我々の仕事のしやすさ。
プログラマーでもあるし、ユーザーの方でもあるしが、何て言うんですかね、素朴に言うとより幸せにというか、生きていけるようにするにはどうしたらいいのかというようなところだったりしますよね。
そこはね、レイヤーが分かれてもいいと思うんですよね。情報処理システムとしてのドメインモデルを作る人々と、それからソフトウェアとしてのドメインモデルを作る人々というのは、レイヤーとして分かれても構わないと思うんですよ。
私がやっているFusionPressという仕組みはソフトウェアの仕組みを作る、それとしてはドメインモデルを作るということをやってるんですけれども、実際にはそのような使うコンサルタントの方というのはたくさんいらっしゃって、
その方々はお客さん向けの実際の情報システムのモデルを作っていると。こういうふうに経営化にしたらよくなりますよと。そういう形が望ましいのではないかと僕としては思っています。
なるほど。さらに細分化する余地もあると。
そうですね。少なくとも2層に細分化したらいいんじゃないかなと。ただ、人としては連携すればいいですね。
どっちからどっちに移っても構わないし、兼務しても構わないし。
確かに確かに。そういった観点でいうと、杉本さんが作られているFusionPressなんかは、より一歩進んだ道具性というか、可変性を備えたようなシステムとして作られているということでもあるんですよね。
そうやって欲しいと日々思って作っていますね。久保さんとも同じだと思います。
なるほど。そこはぜひまた個別にどういう設計になっているのかとか、どんな様子があるのかとか、また何か機会があればあったりしますね。
ぜひぜひ。
データモデリングでドメインを駆動する
はい。いろいろまだまだお話を伺いたいところではあるんですけれども、時間もありますので、そろそろ一旦区切らせていただきたいと思いますが、
改めてまず素晴らしい本を書かれたというところにお礼を言いたいのと、今回いろいろお話してくださってどうもありがとうございました。
どうもありがとうございます。
というわけで今日は杉本Kさんにお越しいただいて、杉本さんが書かれたデータモデリングでドメインを駆動するについてはいろいろお話を伺いました。
私なんか杉本さんのファンみたいなところがあるので、ちょっといろいろ調子に乗って聞いたみたいなところがありますけれども、
このポッドキャスト以外でも杉本さんが勉強会に参加されていろいろ直接お話を聞ける機会だったりとか、今後いっぱいあるんじゃないのかなと思ってますので、
ぜひ皆さんも興味を持っていただいて、杉本さんに直接質問をぶつけたりしていただくといいんじゃないのかなと思っています。
さて、この番組では感想や質問、お悩み相談をお待ちしております。
エンジニアリングの現場で遭遇するあらゆるトピックについて、番組詳細欄にあるお便りフォームよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。
EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのポッドキャストではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株式スタイルCOO兼CTOの後藤秀典でした。
