この記事におけるモデリング
今の私にとってなじみ深いモデリングは、だいたい以下の3種類になります。
- データベースモデリング
- ER図とか
- プログラミングレベルのモデリング
- オブジェクト指向とか
- データ分析におけるモデリング
- データ側のモデリング+手法としてのモデリング
モデリングは、各分野で重要な役割を果たしますが、共通して「意味をしっかり捉える」ことが成功の鍵だと思います。
モデリングは現実世界の問題や対象を理解し、それをシステムや分析に反映させる作業であり、正確に意味を把握しないと、効果的な解決策を導き出すことができません。
一方で、私は短い職歴の中でありがたいことに2回もパッケージの開発に携わっており、「現実の反映」と「拡張性を意識した共通化・抽象化」の中で悩みつづけました。
TM(T字型ER)
佐藤正美氏が考案したデータベースモデリングである「TM（Theory of Models）」。
私が出会ったのは社会人2年目の2016年のことで、2024年の今でもこの技術は自分にとっての主力の立ち位置にあります。
この手法はただのデータベース設計にとどまらず、事業解析手法の側面も持っており、もっと広まってほしいと思っています。この手法により、L-真だけでなくF-真も含めてエンジニア同士で共通理解を持つことが可能だと思います。興味がある方はこの本などを買ってみてください。
扱い方も簡単で、いわゆる正規化も簡単にできます。
おかげさまで、第n正規形がそれぞれなんなのか、いつまでたっても覚えられない体になりました。とある抜き打ちの口頭の技術試験で第1正規形から第3正規形まで訊かれたけど、結果は通ってたからたぶん問題ないやろ。
ちなみに今の職場の人は私がTM使ってるの見たことないと思うんですけど、全部脳内で完結してるからですね（属人化は控えるようにしましょう）。
L-真とF-真についてはこちらの説明をお借りします。自分の言葉で説明した方がいいとは思っていますが、記事が長くなりすぎるのでサボります。
具体的な事例に当てはめると、製造業における部品表である「BOM」に工程を含めて管理したいとき、これだけでさまざまなL-真のモデルが考えられます。「親品目と工程＋工程と子品目」という形で管理すれば柔軟性に焦点が行ったモデリングでしょうし、「品目構成+工程」という形で管理すれば現場に優しいモデリングでしょう。ここまで書いて思ったんですけど、「L-真とF-真」の話とはちょっと違うかもしれないですね。
適切なアーキテクチャの模索
この話は次回の記事で別の角度から触れる予定なんですが、ビジネスに合った技術選定を行うべきだと思っています。そのために、エンジニアはビジネス背景を深く理解し、技術の専門家という立ち位置でビジネスに貢献すべきだと考えています。
たとえば、「マイクロサービスが流行っているから」という安易な理由でマイクロサービスを選択してはいけません。動くものはできると思いますが、現実の意味をとらえずに選択すると長期的な技術的負債を抱えることになると思います。
対象のドメインの特性、言語化されていないビジネスサイドの要件、後でつらい思いをしないように開発サイドとして担保したい要素など、総合的に判断して「技術の専門家としてこう考えている」ということを伝えていくべきだと思います。そのためには世の中の技術を常にキャッチアップし、どのような工夫がされているかを知っておく必要があります。
とはいえ、初めて手を動かす段階において、最適なアーキテクチャがわかることはほとんどないと思っています。特にパッケージ開発という文脈においては、実例を確認しながら局所解に陥らないように、継続的にリファクタリングして改善していくという方法を取っていくべきではないかと思っています。
データ分析モデリング
完全に趣味ではありますが、私はbeatmania IIDXという音楽ゲームのデータ分析をしています。
特に譜面のモデリングが難しく、実態に合わせたモデリングができないと納得感の得られない分析結果になってしまいます。過去、本家からノーツレーダーが出る前に譜面の特徴をレーダー化してみたり、ディープラーニングを使って譜面からCPIの難易度値を推定したりしてみましたが、なかなか苦戦しました。
- たとえば、0.01秒などの単位で表現しようとすると、特徴量が少ない上にデータ量が多くて計算が難しい
- ソフラン・CN・皿など、特殊要素の扱いが難しい
- ランダムなどの要素をどのように扱うかが難しい
手法に目を向けると、たとえばbeatmania IIDXの☆12の難易度推定の方法として、イロレーティングなどを使ってらっしゃる方や、おそらくIRTを使ってらっしゃる方などがいると思います。その手法ごとの結果を比較すると、感覚レベルではありますが違いも何となく分かります。
どれが良いとか悪いとかではなく、そこには分析者のこだわりがあると思われます。
モデリングで大事だと思っていること
いろんなところに話を飛ばし過ぎてまとまらなくなってきましたが、モデリングで大事なことは現実をしっかりとらえることになると思っています。現実で何がしたくて、モデリングを行うのかを深く理解する必要があります。そのために、「意味レベルでの理解」というのを意識すればいいのではないかと思っています。
そう考えると、前回の記事で取り上げた20年選手は、時間のない中でオンプレ版のコード行数だけ見て見積もりを立てたのではないかと感じます。
これから特に、「DX」という文脈でシステムの周辺に対する解像度を上げていかないと、エンジニアも価値提供ができない時代になってくると感じています。
エンジニア組織だけで机上で設計していくのではなく、実際のビジネスサイドの方とコミュニケーションを取りながら、ビジネスの課題を明確にし、それを解決するためのシステムを構築していくことが今後求められるのではないかと思います。