モデリングの導入
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点に深掘りし、問題の正体やアプローチしていきます。
今回のテーマは、モデリングしていますか？、です。
モデリングっていうものを、私も普段毎日毎日やってるってわけではないんですけれども、結構大事な活動なのかなと思っておりまして、これについて改めて私自身の理解だとか、皆さんに知ってもらいたいな、みたいなことを紹介していきます。
エンジニアリングマネージャーの問題集。
今日はですね、モデリングっていうものについて、多分これまで関係するような話を結構してきたんですけれども、ズバリモデリングの話はしてなかったなと思いまして、これについてちょっと話していきたいと思います。
最初に紹介したいのが、本なんですけれども、どうですかね、あまり最近話題にならないんですが、一時期ちょっと流行ったなと思ってまして、
モデリングに関する本で、書籍のタイトルが思考系UMLモデリングエクササイズという本です。思考系というのは考える方ですね。
っていう本がありまして、これ僕は本当にぺいぺいの頃に買って、モデリングっていうのは何ぞやというか、練習しようと思って買ってみたんですね。
これはぜひ皆さん手に取ってみていただきたい本の一つであるんですが、あんまりネタバレするのは良くないんですけども、最初の一問を参考にお話しすると、例題があるんですよ。
一問目の例題が、モデリングの例題なんですけれども、ワンセンテンスだけで問題が書いてあって、アイスクリームをモデリングせよっていう問題なんですよ。
この問題を見た時に、なんというか衝撃が走ったと言いますか、何していいのか全くわからなかったんですね、その当時の僕は。
システムっていうわけでもないじゃないですか、アイスクリームって。
モデリングっていうのが何かすらもう多分その当時の僕はよくわかってなかったので、いきなりアイスクリームをモデリングせよと言われても、手も足も出なかったっていう記憶があります。
この本では、そういう問題に対してどういうふうに取り組んでいくのかとかがいろいろ書いてあるし、一応UMLの本でもあるので、それを表現する際にUMLという道具を使ってどういう考え方を適用していくのかというところも含めて練習できるような本になってるんですよ。
モデリングの技法
今日話したいことは、いろいろモデリングのいろんな要素があるんですけれども、意外とモデリングってきちんと道具として使えるようになるとめちゃくちゃ便利なんですね。
今でもシステム開発でドメインのことをしっかり理解しましょうとかいろいろそういうのが叫ばれてる中で、でもあんまりモデリングっていうもの自体を突き詰めてやろうみたいなことが話として上がってこないなというふうにも思ったりしていて、
改めてその辺を光を当てるというか、全ての現場に適用できるわけではないんですけれども、もう少し皆さん道具として使えるといいことがあるんじゃないかなと思っていくつかのお話をします。
先ほどの本は本当に導入だけなんですけれども、実際の皆さん本当に読んでみてほしいと思っています。
もう一つ導入的に紹介したいものが、これは本ではなくてYouTubeに上がってるTEDの動画なんですけれども、
トム・ユージェックさんという方、結構有名な方なんですけれども、この方のHow to make a toastというプレゼンがあるんですね。
これもモデリングの話かなというふうに僕は思っています。
なので英語なんですけれども、日本語の字幕がついたものとかもあるので、ぜひこれも見てほしいなと思っていて。
タイトルの通りで、トーストの作り方っていうのを書いてみなさいっていう、先ほどのアイスクリームをモデリングせよにかなり似てると思うんですけれども、そういうのをいろんな企業向けにトレーニングとかでやってきた話とかをされてるんですね。
これもそういうお題を出されたときに、多くの人が何を表現したらいいのかがわからない中で、どうにかこうにかトーストの作り方っていうのを表現するんですけど、まあまあいろいろありますよねっていうので、
これも動画見ていただくと結構面白い例とかも出てくるので、くすっとしながら。でも、じゃあそこからやっぱりモデリングっていうのってこういうことだよねとか、そういう話にもつながっているので見てほしいなと思っています。
あとこの話で一つ面白いのが、どうでしょうね。皆さんモデリングってなんとなく自分一人の中で、ああでもない、こうでもないと考えていくようなイメージを持たれている方もいらっしゃれば、そうじゃなくてチームっていうか、他人数っていうんですかね。
多くはないけれども複数の人でディスカッションしながら、エンジニアとビジネス側の人がコミュニケーションしながら進めていくとか、そういうイメージを持たれている方もいらっしゃると思っていますが、先ほどのトムユージックさんのトーストのセッションの中で話されている要素として、
ある人が一人だけで考えられるモデルの複雑さに対して、グループで取り組んだ場合、もっと複雑なものを精緻に仕上げていくことができるということが彼のいろいろなセッションの結果からわかっているみたいなことがあって、
この辺りがやっぱり我々ソフトウェアエンジニアが実務の中で複雑なシステム、ソフトウェアっていうのを作っていくときのモデリングというか、作る対象のものに対してどう理解するのかっていうときに、
一人だけで精緻にやれることの限界というか、グループでやることによってより複雑なものに対して安心して取り組んでいけるとか、そういうことにもつながっているなというふうにも思ったりして、ぜひお勧めですので見てくださいというところですね。
この辺りまでが導入的なお話なんですけれども、モデリングっていうものって何ですかっていう話があるんですけれども、どうなんですかね皆さん、モデリングとどれくらいお付き合いされているのかわかりませんけれども、
私がなんとなく感じているのが、私のソフトウェアエンジニア人生の中で初期の頃は結構モデリング技法とかそういうものがすごく研究されていたというか、実際現場でもすごく使われていたんだなっていうふうな印象があったんですけれども、
おそらく作られるソフトウェア自体が時代とともに変わってきたということもあるでしょうし、スピードとか変化とか、よりそういうものが求められるようになってくる中で、それが原因なのかどうかまでは僕は色々調査したわけじゃないから感覚でしかないんですけれども、
なんとなくそのモデリング技法というか、そういう道具っていうんですかね、に対してちょっと軽視されているというか、そこまで何かがっつり道具について学ばなくてもいいんじゃないかみたいな風潮が暗黙的にあるのかなっていうふうに感じたりもしています。
その辺はあんまり感覚値でしかないから、皆さんがどう思うかわかんないんですけれども、なんとなくそう思っていますが、一方でやっぱりこのモデリングの技法っていうものを身につけておくことが意外とやっぱりいろんな場面で何ていうのかな、役に立つっていうんですかね、普遍的に役に立つスキルの一つなのかなと思うところもあって、
その辺りから今日はこのモデリングというものを取り上げているというのがあります。
なんていうのかな、とはいえじゃあモデリングってなんやねんみたいなところがあるんですけれども、なんかあんまり難しい話をするつもりはないんですが、
モデリングの意味論
皆さんに共有できるすごくざっくりしたイメージで言うと、やっぱりUMLみたいなものが多くの方はまず頭に浮かんでくると思うんですね。
箱みたいなものに名前を書いて、その箱と箱同士の関係性みたいなのを図で表現していくっていうものが、ある種典型的なモデリングのイメージなのかなと思うんですよね。
で、このおおむねなんかだいたいそういうイメージで間違ってはいないと思うんですが、この中にどういう要素があるかっていうと、実は箱と箱、箱じゃない場合もあるかもしれないですけど、
どういう箱があって、その箱と箱がどういうふうに結ばれるのかっていうところに一定の規則があるんですよね。
UMLならUMLのスペシフィケーションっていうのがあって、実はそこに結構きちんと定義されていて、箱と箱の線のつなぎ方もいくつか種類があったりするんですよね。
で、その種類がどういうところで使えるのか使えないのかとか、そういうものがあったりしますと。
で、こういう図の書き方っていうか、どういう図はOKで、どういう図はダメでっていうのは、専門的な言葉、そこは専門的に説明するつもりないんですけど、
公文論というグラマーなんですよ。私たち日本語とか英語とかそういうのでもグラマーってあるじゃないですか。
それってどういうルールで言葉を使うのかみたいなところですよね。
モデリングにも公文論っていうのがあって、UMLならUMLでどんな図の書き方が許されているのかだったり、
データモデリングならデータモデリングで、似たような感じだけれども、どういうものがどういうルールで並べることができるのか、もしくは何ができないのかみたいなことが規定されています。
そういう公文論があるのと並列して、公文があれば意味もあるって感じなんですよね。この2つが大体セットなんですよ。
意味論のないモデリング技法もあるにはありますけど、大抵はセットになっています。
UMLだったらクラス図だったら箱はクラスですよねとか決まってるわけじゃないですか。箱に入るものはクラスとして使うものみたいなことだったりするわけですよね。
状態遷移図だったら箱は状態とか。その箱に入るものがクラス図だったら従業員っていうクラスは入れることができるけれども、クラスにはならないようなもの、
ご当産っていうものはクラスにはならないので、ご当産は入らないよねっていうふうになると、これは箱に当てはめることができるものとできないものを意味として規定しているような感じなんですね。
だからそこは意味論っていうふうに区別されていて、この辺って例えばもうちょっと皆さんの馴染みのあるもので言うと、ドメイン駆動設計だとエンティティとはこういうものですとかIDで識別できますよねとか、
モデリング技法の概要
そういうのがあるじゃないですか。あれも意味論の一種だったりしますよね。こんな感じで構文論と意味論っていうのがあって、それぞれモデリングの技法によってどんな構文とどんな意味論を用意して、それを使ってモデリングしていきましょうみたいな話になってるんですよ、実は。
皆さんが普段どのくらいそこを意識されているかわかんないんですけど、そんな感じになってます。
多分そこまでそういったUMLならUMLの構文だとか意味みたいなのをわかんなくてもいって絵とか描けちゃうし、その描いた絵でもってシステムの会話とかがエンジニア同士だったりお客さんとできなくはないんですよね。
なんとなくのイメージっていうのは伝わるので。なので、そういう意味でそこまでしっかり厳密にモデリング技法っていうのを学んだり適用したりしなくても、その仕事をする上で、ソフトウェア開発みたいな仕事をする上で、そういったモデリングの軽めなモデリングっていうんですかね、っていうやり方だけでも十分に役に立ったりはするわけですよ。
それで十分な場面もあると思います。
なんですけれども、いざお客さんとのコミュニケーションの入り口としてはいいんだけれども、認識の疎後が一定ない程度の詳細レベルの話っていうんですかね、いうところまで話そうとしたときに、やっぱりこの箱と箱の間の線の種類だとかいうところが、
一対一なのか一対他なのかみたいな話だとか、そういうところはもっともっと詳細なレベルもモデリング技法によってあるんですけれども、そういった話までサポートできるようなモデリング技法っていうのがモデリングをできていると、
そこまでのレベルの会話がモデルをベースにできるようになるんですよね。
というので、実は結構役に立つはずなんだけれども、皆さんどこまで使ってるのかわかんないんですが、僕としてはもう少しこのモデリングっていうものを見直されてもいいんじゃないのかなと思っているところなんですよね。
今、UMLのことをちょっと例で取り上げたんですけれども、他にもモデリング技法っていうのがあって、おそらく皆さんがあまり親しみがないんじゃないかなっていうデータモデリング系のところを少しお話したりします。
UMLもUMLで、スペシフィケーションっていうのがウェブ上で公開されているので、この辺一度読んでみることを興味がある方はお勧めしますし、例えばどうでしょう、皆さんツールとか使ってるんですかね、UMLのモデリングを書くときに。
アスターとかあるじゃないですか、あの辺り書くとそのUMLのスペシフィケーションを結構ちゃんとサポートしているので、いろいろな細かい表現っていうのができるようになってるんですよね。
そういった細かい表現が実際どういう現実の事態を表すときに使えるのかとか、その辺りを一度細かく見てみるといいと思っています。
データモデリングによるモデリング技法
UMLとは別にデータモデリングで言うと、私のポッドキャストで何回か登場している方々の名前が出てくるわけですけれども、今日はまあいろんな流派があるんですけれども、2つ軽くお話しするのは
1つは佐藤正美さんのTMっていうデータモデリング系の技法の話。で、もう1つは渡辺光三さんの3要素分析法ですね。この2つはどちらもデータモデリングをベースにしている技法っていうのかな、モデリング技法だと僕は思っています。
で、佐藤正美さんの方からいくと、まあその主に業務システム、機関システムっていうかな、を対象にしたモデリング技法として整備されていて、この佐藤正美さんのTMという技法は何ていうのかな、先ほどその構文論とか意味論とかお話ししたんですけれども、その辺りをすごく精緻に突き詰めて体系化されています。
で、まあ僕はその佐藤正美さんからだったり、直々に何かこの技法を教わったわけではないので、あのにわかなレベルの人なんですけれども、1度だけ佐藤正美さんが勉強会的なことをされたことがあって、そこに運良く参加することがあったんですね。
で、その時にいろいろこのTMという技法などについて語っておられたんですけれども、僕がものすごく印象的だったのは、このTMという技法を使って、まあ業務自体をモデリングしていくんですね。
そのデータとデータの外側のある種のストーリーみたいなものもそこに含まれていくんですけれども、そのビジネスに現れる捉えようとしている事態っていうのかな、ケースっていうのかな、これがモデルの中でもう100%全て捉えることができると佐藤さんはおっしゃってたんですよ。
で、その100%っていうのは、今対象にしようとしているあらゆるケースのデータの存在の仕方みたいなところは全てだし、あとその逆に存在してはいけないものは入っちゃいけないんですよ。
当たり前っちゃ当たり前なんですけど、これ設計する時に多分その辺りは緩くなっている場合もあるかなと思うんですが、佐藤正美さんのおっしゃっているのは本当に100%、しかも佐藤さんの面白かったのは100%じゃなくて100%っていうふうにおっしゃるんですよね。
ここをものすごく強調して強く言うので、僕の頭にすごく残ってるんですけど、100%この業務のケースをモデルで表現できているっていうのが設計者として当たり前だろうみたいなふうに言ってくるんですよね。
これは設計の態度っていう意味でもすごく強烈だったし、それを可能にするモデリング技法、これがその構文と意味の両面でそれだけ豊富な事態を捉えることができる技法っていう意味で、これはすごいなというふうに思いましたね。
僕は使いこなせてるわけではないので、そんなに偉そうなことは言えないんですけれども、これを佐藤さん本にまとめてらっしゃったりもするので、ぜひそういったところから学んでもらえるといいなと思っています。
データモデリングがベースになっていて、似たような話で言うと、その2つ目の渡辺光三さんの方のモデリング技法ですね。
こちらは3要素分析法という形で提示されていらっしゃいます。
3要素なのでデータモデル以外に要素が別にあって、その全体で業務っていうものをモデリングしていきましょうっていうような話ですね。
3つの要素が何かっていうと、データモデル、データの構成とそれから業務の構成と機能の構成。
ちょっとこの業務と機能って分かりにくいんですけど、機能っていうのが1個1個のすごい細かい業務単位のデータの入出力の画面とかそういう話で、
業務っていうのは1個1個のデータの入出力っていうよりもう少し大きな塊のデータがお客さんから来て、その中で会社の中で帳表とかに入力されて一連の動きを含むものが業務という感じですね。
この3つでもって業務というものを捉えて分析していこうという感じになっていて、
この中のデータモデルの部分は先ほど紹介したTMのようなものすごく細かい構文論や意味論を渡辺さんの方は定義しているわけではないんですね。
もうちょっと一般的な普通のデータモデリングの中で最低限出てくる種キーは何とか関数重力性みたいな話とかそういうものだけを使ってやっていくような感じです。
ただ渡辺さんの場合、面白いのがこの技法を本とかにまとめている、本もたくさん書かれていますけれども、それだけじゃなくて実際渡辺さんがこの技法を使ってモデリングするためのツールを作ってるんですよ。
モデリングツールを。そのモデリングツール上で渡辺さんの提唱している技法でもってモデリングできるというふうになっているので、エンジニアってどっちかというとホワイトボードとか紙に書くよりもコンピューター上で何かやりたいもんじゃないですか。
そういう時に渡辺さんのツールをダウンロードしてやってみようみたいなことができるようになっているし、何ならその一歩先に書いたモデルがそのままシステム、そのままっていうのよりはちょっと設定はいるんだけど、システムとして動くっていうところまで作られている方だったりするので、そこもまた面白いなと思うところなんですよね。
という感じで、この2つの技法があって、それぞれ公文論とか意味論っていうのが一定整備されてますと。それによって、今回で言うとシステムのためのソフトウェア設計のためのモデリング技法なので、ソフトウェアについて、ソフトウェアっていうわけじゃないかな。業務についてというのかな。
モデリング技法の実際の現場での利用
すごくいろいろな事態を語ることができるようになるかなと思っています。
佐藤さんのほうはより細かい公文と語彙が用意されてるし、渡辺さんのほうはそういった細かさっていうよりは3つの側面で業務を見ることによっていろいろな事態を捉えられるねっていう話なんですけれども。
そんな感じで、この辺りのモデリング技法って奥が深いし、それによって結構複雑なものを語ることができるようになるっていうのを、実際この2人って単にモデリングツールだけをピュアに作ってきた方では決してなくて、
実際のシステムを作ってくる過程で自分たちのモデリング技法を同時に洗練させながら作りながらやってこられた方なので、それが実際の現場でワークするってことも証明済みなんですよね。
なので、現場でも使えるモデリング技法として存在してたりするというところで、この辺りやっぱり突き詰めると、システムってこういう見方をするんだなとかそういう観点を得ることもできるし、自分たちの語彙っていうんですかね。
システムを語るための道具としても持つことができるので、杉本さんの最近の本でもそうなんですけれども、意外と時を経ても使える道具として存在してたりするものだと思うんですよね。
なので、そういうところも皆さん、もし興味があれば幸い本を出されてたりするので、そういったものから触れてみるのもいいんじゃないのかなと思ったりします。
で、ここまで話して最後にちょっとだけ観点を変えてお話ししたいことがあって、それは何かっていうと、これまた僕のポッドキャストで何回も取り上げてるドメイン駆動設計の話なんですけれども
ドメイン駆動設計って、モデリングの仕方みたいなところはそんなに細かくこういうふうにやりなさいみたいな話って書いてないんですよね。
で、書かれてるのって、まあでもモデルっていうのはあって、モデルを中心にしましょうっていうことを資金に唱えてると。
で、かつそのモデルをソフトウェアのソースコードを書くときにもそのモデルとちゃんと一致してるように書くし、エンジニア同士だったりビジネスの人と会話するときにもそのモデルに現れている概念とか関係性とかいうことをきちんと適用しながら会話しましょうね。
まあその言葉を使って話をしましょうねっていう。なんかこう会話でもってモデリングしていくっていうようなスタイルっていうのかな。
まあそういうことが書かれてるんですよね。この辺がなんかプラクティス名で言うとエビキタス言語とかモデル駆動設計とかなんかそういうところで語られてることだと思っています。
で、この辺って何が言いたいかっていうとなんか会話の中だけで使えばいいっていうのってちょっと軽視されがちというか会話に使ってればもちろん一定のフィードバックだったり気づきをモデルに対して得ることはできるんだけれども本当は結構しんどいというか突き詰めてやらなきゃいけないことだったりもするっていうところが先ほどお話ししたそのモデリング技法について。
そのモデリング技法の話と同じようなところかなと思っていて、モデル自体にその概念だったり公文規則とかが十分に備わっていないとそのモデルを使ってきちんとした会話ができないんですよね。
っていうところがまずベースとしてあると思っていて、で多分それが十分に整ってないとそのモデルの外側の私たちが普段持ってる日本語とかそういうものの世界の中で語ってしまうので、そうなるとモデルへのフィードバックっていうのが厳密には薄れてしまうところがあったりするんですよね。
モデルが正しいのかそうじゃないのかっていうのが会話から判別できないということになると思っています。なのでドメイン駆動設計が言ってるのってそういうレベルのことではなくて本当にモデルの中に必要な公文論と意味論が備わっているというか。
なんかまあ用語の並べ方の規則だったり用語同士の関係性、前後関係とかいろいろあるんですよね。そういうものが規定される程度の深みのあるモデルっていうものをドメインモデルとして作って、それをベースにソースコードも書くし会話もしましょうっていう話なので、それをベースに会話するのはすごく大変だと思うんですよ。
そもそも一番最初のモデルって全然語彙が集まってないし公文規則も定まってない中で何も会話ができないみたいなことが起こるんじゃないのかなと思うんですけど、そんな風にモデルを使おうとしたことって皆さんある方もいらっしゃるかもしれないしそんな風には思ってなかったみたいな方もいると思うんですよね。
でもそれがモデルっていうのを会話の道具として使う、会話だけじゃないですね、モデルを道具として使うっていうことでもあると思っています。
それが今回お話ししたモデリング技法をきちんとモデリングの道具として使っているっていうことでもあるわけですよ。
その意味でドメイン駆動設計をやりたいからとかそういう理由を私は言いたいわけではないんですが、モデリングっていうのがどういうことであって、そこには意外と突き詰めて本来やるべき活動なんですよっていうところが言いたかったことだし、
モデリング技法について
それって普遍的な技術というか知識体系だったりもするので、そういったところを一つ何か深めて持っておくと意外と長く役に立ちますよっていうところで今回モデリングの話をしてみました。
というわけで今日はモデリングというものについていろいろお話をしました。
これなかなか語るのが難しいテーマではあるんですけれども、あまり忘れられてはいけないものでもあると思っていて、繰り返し私自身の中でももっと深めたいと思っていますし、皆さんもこれで何か興味を持っていただけたらいいなと思っています。
さて、この番組では感想や質問、お悩み相談をお待ちしております。
エンジニアリングの現場で遭遇するあらゆるトピックについて番組詳細欄にあるお便りフォームよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。
EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株式スタイルCOO兼CTOの後藤英則でした。
