00:00
株式会社株式スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、モデリングしていますか?へのお便り その1、です。
ちょっと前にお話ししたモデリングのところに関して、ご質問をいただいていますので、そのあたりお話ししていきたいなと思っています。
エンジニアリングマネージャーの問題集 本日は、実はお便りをいただいておりまして、
しばらく最近いただけてなかったんですけれども、ポンポンといただけましたというところで、このあたりをちょっとネタにお話ししていきたいなと思っています。
実はお便り、なかなかこういう番組でお便りっていうのをいただくの、小さい番組なので、なかなか難しいなとも思っておるんですけれども、
ちょうど先週、PHP カンファレンス福岡に私参加してきたんですけれども、幸いなことにこの番組を聞いていらっしゃる方がそのカンファレンスにも参加していらしてですね、直接お声をいただいたりしたという次第だったりします。
まずはいただいてありがとうございましたというところで、
まず一つ取り上げたいのが、前々回だったかな、モデリングについてお話しした回があったんですけれども、ここについて1点いただいてますと、
これTさんという方からいただいているんですけれども、ちょっとなかなかまとめて一言でこの質問を説明するのがちょっと難しいんですが、
ざっくり言うと、モデリング技法みたいなものの理解は一定はあるんだけれども、実際に現場でやられていることとしては、やっぱりシステムを作るにあたって、最初の取っ掛かりみたいな感じで、
粗い、ちょっとしたUMLの絵を描いてっていうところはやるんだけれども、そこから先に関しては、もう動くコードを描いちゃって、画面もあるっていうことですよね。
その画面、動くものでもって、必要なステークホルダーと、より詳細な仕様を詰めていくというか、そういったことをしてらっしゃるというところで、逆に言うと、それ以外のやり方、もうちょっとコードを描かずにステークホルダーだったり、プロダクトオーナーだったりと、
03:15
モデルというか、そういうものだけで会話していくというのが、あまり得意ではないというところで、それってどうやると身につくんですかね、とか、そういったところを質問していただいております。
はい。これ、すごくわかるというか、実際、私もモデリングのお話をしたときに、それでもシステムは作れるんですよねっていうふうにお話はしてると思います。
で、ちょっとあの時の回だけでは、実際にそのモデリングっていうものが、じゃあ具体どういう感じのことなのかっていうところに触れてなかったので、もう少しその辺りの補足みたいな部分を今回お話しすることで、イメージをつかんでもらえるのかなと思っております。
で、まず、渡辺光三さんの3要素分析法、私的にはこれが一番とっつきやすいんではないかなと思っているので、まずこれを勉強したらどうですかっていうふうに、これまでも多くの方にお勧めしてきました。
で、この3要素分析法の3要素っていうのは、1つはデータモデルですね。で、それ以外の2つが業務モデル、これは業務フローズのようなもの、データフローズのような形で書くんですけれども、業務フローですね、業務モデルっていうのと、それからもう1つ3つ目が機能モデルといって、これは個々の機能、イコール画面みたいな感じなんですけれども、
まさに画面の絵みたいなものを書いて、その観点で内容をクリアにしていくみたいな感じなんです。この3つを持ってシステムを分析設計していこうっていうのが3要素分析法なんですね。
なので、ここに機能モデル、画面のイメージっていうのが実は入ってるんですよ。なので、Tさんからいただいた話の中に入ってる、動くものを作ってっていうのは、やっぱり画面のイメージを荒くでも1回作ってみせて、それでもってステークホルダーと会話してるっていうことだと思うんですよ。
だからこれって言ってみれば、渡辺さんの3要素分析法の機能モデルの部分にあたる何か絵を描いてやってる、つまり何らかのモデリングをして、そのモデルでもって会話してるっていうふうに言えるんですよね。
06:09
もちろん渡辺さんの3要素分析法でも、最初からめちゃくちゃ精緻なモデルを描けるなんてことはおっしゃっていなくて、もちろんそれは熟練度とかによって最初からかなり当たりをつけて、それらしいものを描けるようになるんですけれども、とはいえ最初からパーフェクトじゃないということで、描きながらユーザーとコミュニケーションしながら分析したり詳細化していったりするっていうことなので。
その意味では、このTさんが言われてることって、そんなに間違ったことをやってるわけではないというか、別にそれでワークしてるんだったらまずいいじゃんと思いますし、より一時代昔ではなぜよりモデリングというものに重きを置かれたのかというと、
やっぱり実装の部分にかかるコストというか時間というかが、今と比べてものすごく高かったんですよね。なので、それもあって実装に入る前に、より実装を使わない形でユーザーと何らかの詳細度までの仕様を詰め切るっていうことが必要だったんですよね。
なので、必要なのでそういうやり方をしていたというところがあると理解してます。
実は、今でもある程度そういうやり方をされてらっしゃる部分もあると思いますが、一方でやっぱりツールの進化、開発環境の進化に伴って、このデータ中心アプローチをされてる方々もそのやり方をアップデートされてきてるんですね。
なので、モデルというか実装伴わない絵というか図というか、そういうものだけでユーザーとコミュニケーションしなければならぬっていうふうにピュアに貫いてるわけではないんですよ、実は。
そのあたりが、渡辺さんであればご自身の作ってる、実際にモデル的な情報を入力すると画面が立ち上がってくるようなものがあったり、渡辺さんの手法とは違う、椿さんだとかの手法、似たようなデータモデルを中心にしたアプローチをベースにした、そういった、確か名前はいろいろあるんですけれども、
超高速開発手法だったり、今だとノーコードツールって言うのかな、そんなようなものでささっと動くものを作って、それでもってお客様とユーザーと会話していくっていうことは普通にやられてるんですよ。
なので、そこはある種そういうもんと言っちゃうこともできるかなと思います。たぶんこれってこのTさんの欲しい回答じゃないのかなとは思うんですよね。ただ、一旦そこ自体はそんなに否定することじゃないのかなっていうので、この話をしました。
09:22
とはいえ、モデルでもってどこまでの会話が可能なのかっていうところは、もしかするとモデリング技法ごとの備えている細かい道具というか語彙というか、そういうところをまだ認知されてないのかなとも思いますので、少しその辺りに関して触れようかなと思います。
で、例えば渡辺さんといつも並列で名前を出すのが佐藤正美さんのTMという手法なんですけれども、例えば佐藤正美さんのTMの赤本なんかにも書いてあるんですけれども、このデータモデル、テーブルを定義していくような感じですよね。
で、テーブルを図の中に書いていって、その中にテーブルの名前と主キーとフィールドと、それからテーブル同士の関係性、エンティティとリソースみたいな区分をしながら関係性を紐づけていく、線を引いていくっていう感じですよね、ざっくり言うと。
で、これ佐藤さんの手法に限らずなんですけれども、例えばこの線の引き方、2つのイベントがあったときに、イベント同士の線の結び方で業務モデルが違うということまで表現してるんですよ。
これだけ聞いて何だかわかる方はデータモデルに詳しい方だと思うので、もう少し具体でお話しすると、本に載ってる例で言うと、請求と出荷っていうイベント、エンティティ、イベントっていうテーブルの話かな、があると。
で、販売系の業務であれば、請求っていうことと出荷っていうことってあるじゃないですか。それぞれレコードを切っていくと思うんですよね。
ただし、扱ってるものだったり、その会社の業務の仕方によっては、まず請求をして、その請求というものができた後に出荷をするというようなルールで業務をしてる会社もあれば、逆にまず送っちゃいますと、出荷をしちゃいます。
12:06
出荷されたものに関して請求をしますというような業務ルールでやってる会社もあると。
これはもう、おそらくその業界の招集官だったりの中で根付いてるものだったりするので、しょっちゅう変わるとかそういうもんじゃないと。
もう業務ルール、その会社の業務はこうですというような、そこそこ安定した構造としてそうやってるという感じだったりするんですよね。
こういった業務ルールというか、ある種のイベント同士の前後関係ですよね。
こういったものをデータモデルの中に明示的に記述していきます。
それは具体的にどうやるのかっていうと、単純なんですが、例えば請求してから出荷するっていう業務モデルであれば、
請求のほうが先に存在していて、その後請求に依存して出荷というのが生成されるということになります。
なので、請求自体はまた他のものに依存してるんですけれども、一旦そこはスコープアウトするとして、
請求イベントは請求番号、請求IDと日付、日時みたいなものをキーに持ってると。
いう状態でレコードが生成されるんですけれども、それに対して出荷は必ず請求の後なので、
出荷テーブルのキーは出荷番号と日時だけではなく、請求番号も主キーとして含めるというようなモデリングの仕方をします。
こういうふうにモデルを作ることによって、もうその存在の依存関係っていうんですか、
必ず出荷の前に請求が存在していなければならないというルールがモデルで明示的になるんですよね、データモデルとしては。
その辺りまでこのデータモデルの中で会話をして明確にしていくということがモデリングに含まれてるんですよね。
なので含まれてるっていうことは、ユーザー、お客様と会話する中でそこを確認しなきゃいけないんですよね。
これってどっち先にやってるんですかねとか、普段の業務どうしてるんですかねっていうのを聞きながらその辺りを明らかにしていくっていうことをする。
そういうことをしながらモデルを作っていくっていう感じなんですよ。
なのでそれは一つのモデリング技法が備えてる語彙というか、そこをパズルのピースとして埋めないとモデルがちゃんと描けていかないっていうようなものなので、
15:12
今話したような語彙を備えてる道具を使っていると必然的にその辺りまでクリアになっていくんですよね。
クリアにしなければいけないというような話なんです。
これはデータモデルの場合なんですね。
今、佐藤正美さんの例にしましたが、これ大体どのデータモデリング技法でもそういったことを明示的にだったり暗黙的にだったりルールとして持ちながらモデリングしていくってことをやってるので、
結構そのデータ中心の方々は主キーに何が入っているのかって非常に大事にされるんですよ。
それはなぜかというと、そういったモデリング技法の中の語彙というか、そういうものに当たるからです。
それが業務ロジックっていうのを決めるからなんですよね。
そこに依存してるので、そこをあやふやにしてては、業務をきちんと捉えられないからだということなんですよ。
なので、それは実装上どういうふうにテーブルの主キーを設定するのかっていう話は、ちょっと次元が違う話なんですよね。
データ中心のモデル作った場合は、できればそこで描いたモデル通りの主キーを物理的な実装のほうのテーブルにも作れたほうがわかりやすいとは思います。
ある種の理想形だと思うんですが、なかなかそうはいかない場合もあるので、この辺りは実装手段としてどうしていくのかっていうのを別途考えるっていう話だったりもするんですけれども、
今話してるのは実装のほうではなくて、あくまでモデリングとしてどうなのかっていうところですね。
おそらくTさんは、この辺りまでデータモデルっていうものを道具に、ステークホルダーと会話っていうのはされてないのかなっていうのは思うんですよね。
ただ、別の手段を使ってその辺りの要件というか、実態を把握しに行ってるということで、それってデータモデルがなければできない会話ってことじゃないじゃないですか。
画面だったり、別のいろんな手段の会話でもって、そこの情報を得ることはできるんですよね。
なので、これまではそういうふうにされてきたと思うんですけれども、そこに1つデータモデルでもそこを明確にするっていうものは道具に入れることは可能だと思うので、
もしよろしければ、例えば渡辺光三さんの本だったり、佐藤正美さんのTMの本だったりを読まれると、
18:05
ここはそういうものをクリアにするためにこういうルールが定義されてるんだというか、こういう細やかな話が入ってるんだなっていうふうに見ていただくといいんじゃないのかなと思っています。
似たような話で言うと、例えば前々回かな、モデリングのところで、UMLの例も出しました。
UMLのクラス図で、クラスとクラスの間の線を引くときに、この線の種類っていうのが実は非常に細かく定義、非常にというほどじゃないけど、割と細かく定義されてるんですよね。
一つは関連、associationっていうのと、それから二つ目は依存、dependencyっていうのと、三つ目は集約、これはアグリゲーションかな。
四つ目として合成、compositionみたいな定義がされていて、これなんというか構文だけではなく、その線自体が二つの要素の関係性、意味ですよね、を定義するような形なので、
その二つのクラス間の役割というかいうところまで結構踏み込んで、この二つのものの関係性っていうのはどれなんですかねっていうことを明示的に会話でもってクリアにしながら、きちんとこの線を使い分けて引いていくということをしたりするわけですよ。
UMLの場合、さらにそれに加えて線と線で結んだものの多重度っていうんですか、どちらかが1または0で、どちらかが多数だったりだとか、そういうことも全部書いていきますよね。
なので、結構細かい語彙が実はこの関連の仕方一つとっても定義されていたりするので、そういったその線にこだわってユーザーと会話するときに、ここって意味的にはどういうつながりなんですかねとか、こっちが何個ぐらいまで存在するんですかねとか、そういう会話をしていくことで、
実際のユーザーのやってる業務の特性というか、見えないルールみたいなものとかが浮かび上がってくることがあると。そういうものだったりするんですよね。
なので、繰り返しになりますが、そういった語彙を使わなきゃシステムが全く作れないかっていうと、そういうことではないんですよ。
そうなんですけれど、ただ図を書くときにそういったちょっとした細かいルールっていうのまで、少なくとも図の書き手として知っておくことで、そこをフックというか取っ掛かりにしながらユーザーとの会話につなげていくシステムのありようをクリアにするためのちょっと細かい話っていうのを掘っていける。
21:26
さらにそれがわかったものが明示的にモデルとして表現できるということになるのかなと思うんですよね。そういう意味で、このモデルのモデリング技法自体のちょっと細やかな部分っていうんですかね。
あえてそれを語彙と僕は呼びたいと思うんですけれども、そういった語彙を身につけておくと役に立つよっていう話だったので、ぜひこのTさんにはそういったところを踏み込んで本を読んだり実践されたりされるといいのかなと思っています。
そういったことが書いてある本でいうと、やっぱり渡辺さんであれば、この3要素分析法を全体的に抑えたものでいうと、業務システムのための上流工程入門っていう全体的に青い本があるんですけれども、これを見ていただくのが全体感をつかみやすいのかなと思っています。
ただ渡辺さんはそれ以外にも、よりデータモデリング、データモデルにフォーカスした本をいろいろ出されてますので、そういった別の本でよりデータモデルの詳細な部分っていうのも補完いただくと、よりデータモデルの使い方っていうところはクリアになっていくんじゃないのかなと思います。
あと、渡辺さんともう一方、ぜひ紹介したいのは佐藤雅美さんで、佐藤雅美さんもいろいろ本書かれてるんですが、僕が持ってるのは赤い本ですね。
これ佐藤さんご自身が赤本って呼んでるので、それに倣って赤本って呼ぶんですけれども、本のタイトルでいうと、データベース設計論、TGKERっていうタイトルの佐藤雅美さんが書かれた本があります。
ここに基本的には最新の佐藤雅美さんの理論というわけではなくて、少し前のっていう感じではあるんですけれども、その当時のTGKERの構文論・意味論だったり、その背景にある概念の紹介だとかいうところが、
すごく端的に、網羅的にまとめられているし、あと、結構応用例としてのデータモデルの書き方みたいなところも、すっきりとまとめられてる本だったりするので、この辺りもチャレンジしていただけるといいのかなと思っています。
24:18
はい。モデリングの技法のあれこれっていうところをお話ししてきたので、いただいた質問に対しては一通りお答えしたのかなというふうに思っておるんですけれども、これにちなんで話しておいたほうがいいかなというのが、ドメイン駆動設計絡みのところですと。
Tさんがやられている一定程度以上の細やかな部分は、もう実際にソースコードを書いて動くものを使って、ユーザーとコミュニケーションしてますっていうところがあったじゃないですか。
これっておそらく聞いてらっしゃる方の中でドメイン駆動設計のことを知っている方であれば、それってそのドメイン駆動設計に出てくるモデル駆動設計そのものじゃないですかみたいに思う方がいらっしゃると思うんですよ。
なんならなんていうのかな、それこそが正しいというかいうふうに言えるというか、そういう解釈もあるのかなと思うんですが。
僕としてはここに1本線を引いておいていただきたいなと思っておりまして、少しだけそこのお話をします。
ドメイン駆動設計のモデル駆動設計っていうパターンを読むと、やっぱり動くコード、動くモデルが、モデルと実装っていうのかな、そこが常にシンクロしている、一致している状態っていうのを作りましょう、維持しましょうみたいなプラクティスなんで。
実装されているものイコールモデルっていう状態なように聞こえるわけですよね。
そのモデルでもって例えばユビキタス言語みたいな別のプラクティスがあって、そのモデルをベースにユーザーと会話しましょうって話なので、
その動くものを作りながらそれを使って会話しましょうっていうふうにも言えますから、まさにその通りなんです。
ただ、この実装するものイコール、完全にそれがイコールモデルなのかっていうと、ここにはやっぱり少し、ある種のトランスフォーメーションというか、溝というのかな、がある場合もあると思うんですよ。
イコールでいける場合もあると思うんですけれども。
27:00
例えば、ある種のドメインモデルの話をする場合には、ドメイン駆動設計に出てくるようなビジネスっぽいドメインで、エヴァンスが提唱してる、あれは一つのモデリングの道具と言えるんだけど、エンティティとか、バリューオブジェクトとかリポジトリとか、
そういったビルディングブロックを使ってモデリングできるようなものに関しては、それらである程度表現しちゃうと。
かつ実装もそのまま、最近だとしやすくなってるっていうことで、モデルイコール実装みたいなところが作れる場合もあります。
ただ、そこに出てこない用語っていうんですか、もうちょっと細やかなビジネスルール、それこそ前半で話したような出荷等請求の前後関係がどうなってるんですかっていうようなことは、エンティティとか、その辺の道具だけでは現れないじゃないですか。
っていったような部分だったりだとか、もしくは簡単、高度で直接的には表現できないようなモデルが扱いたい対象のモデルである場合。
そうですね、なんかちょっとパッと上手い例が浮かばないんですけれども、なんか経路探索みたいな問題を扱っているソフトウェアだとして、何でしょう、ソフトウェアの実装っておそらくそのソフトウェアで解決したい問題を扱うような時に、こういうふうになってた方がいいですよねっていう会話をする時の、
なんかこう、ベースになるモデル、その現れてくる用語っていうのはもちろんその実装の中にも出てくるんだろうけれども、その実装の形っていうのは、会話に使うベースとなるモデルとはおそらく違う、かなり違った形で実装されると思うんですよ。
何ならそのグラフの経路探索の問題だとかって、人間にわかりやすい表現っていうよりは、どちらかというともうコンピューティングの世界というか、アルゴリズムの世界というんですかね、よりスマートに、もしくは何らかの要件に従った独自のルーチンでもってうまく経路探索ができることが必要であって、
人間同士が使う会話のモデルと一致してるかどうかっていうのは、そのソリューションの次元においてはもう二の次ですよね、正直言って。
30:02
人間の理解度みたいなのを優先して、遅いアルゴリズムになってたらもう意味が全くないので、そこではやっぱり実装で作られる形っていうのは、我々、特にユーザーが思い描くメンタルモデルのベースになるような形とはやっぱり違う状態だと思うんですよね、違う構造というか。
なので、とはいえ、ユーザーとはある種の合意されたモデルをベースに会話をしつつ、そのモデルを表現することも可能な要素を備えた実装レベルの詳細度のモデル、これを実装していくっていうことはできると思うので、
ここってやっぱりユーザーとの会話に使っているモデルと実装で使っているモデルとの間にリンクは存在するはずなんですよ。これはやっぱり僕の考えではモデル駆動設計が維持されている状態だと思うんですね。
ハンマヒコのモデル駆動設計にこだわりすぎるのもなんだかなっていうところもあるんですが、そういうものだと言えることもできるので、むしろそういう場合の方が多いかもしれないとも思うんですよ。
って言った時に、ソースコードで書いたものがイコールモデルってわけじゃないっていうふうに思っとくというか、むしろソースコードで書く方はよりソフトウェアとして実現するための要素を盛り込んで変形させていくべきっていう部分もあるので、ただし何らかユーザーとの会話のベースとなるモデルとのリンクは維持しましょうと。
そんな感じなんですよね。なので、必ずしもソースコードで表現するのがいいわけではない場合があるというか、一旦ユーザーとの合意できるモデルっていうのは何らかの形であって、ソースコードを実際に記述するものはちょっと違う形になる可能性があるよというふうに少し分けて考えておくと、
役に立つ場合があるかなと思っています。というわけで今日はモデリングしていますかという以前お話ししたところについていただいたお便りを元に追加のお話をいろいろさせていただきました。
こうやって聴いてくださっている方からいろいろご意見などいただいて、それについて補足とか深めるようなお話ができるのって、しゃべり手としてはとても嬉しいことだなと思っております。お便りいただいて本当にありがとうございました。
33:05
さて、この番組では感想や質問、お悩み相談をお待ちしております。エンジニアリングの現場で遭遇するあらゆるトピックについて番組詳細欄にあるお便りフォームよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。お相手は株式会社株式スタイルCOO兼CTOの後藤秀典でした。
