はじめに
こんにちは。サーバーサイドエンジニアの mokuo です。
2024/08/10 に開催される builderscon 2024 にプロポーザルを提出し、採択していただきました 🎉🎉🎉 fortee.jp
先日 タイムテーブル も公開されまして、なんとトップバッターを務めることになりました 🙄
私の次の枠では、弊社の 三谷 も登壇します。詳しくは以下の記事をご覧ください。
そして、私自身はテックイベントでの登壇経験はありましたが、プロポーザルを提出するのは初めての経験でした。プロポーザルを下書きした後、社内のエンジニアにレビューいただき、何度も修正を行いました。
同僚からの丁寧なフィードバックがプロポーザルの採択に繋がったのではないか、と思っています。
そこで、本記事ではプロポーザルのバージョン 1 ~ 3 を公開し、レビューを通してどのように改善されたのか、その変化を振り返ってみたいと思います。
本文
ver1（レビュー前）
Web アプリケーションの開発において、どのようなアーキテクチャを採用したとしても、モデリング（そしてテーブル設計）は重要になってきます。 モデリングについては、DDD、sudo モデリング、イベントストーミング、UML図、アンチパターンなど、様々な概念や手法、ツール、書籍などを参考することができます。 しかし、具体的なモデルやテーブルの単位まで落とし込むと、これで良いのか不安になったり、他のメンバーと意見が合わなかったりすることもあるのではないでしょうか。 TM（Theory of Models）は「モデルの構造は誰が作成しても1つしか存在しない」という、まさに夢のようなモデリング作成技術です。 本セッションでは、2022年に発売された書籍「事業分析・データ設計のためのモデル作成技術入門」をもとに、自ら実践した経験も踏まえてお話しします。 ## 対象者 - モデリングしたが、正しいのか不安になったことがある人 - モデルやテーブル設計を改善したいが、どうしたら良いかわからない人 ## 話す内容 - TM の概要 - T字型ER法を前身としている - 数学基礎論や集合論などに基づいている - TM のモデル作成技術 - 関係を関数、モノを変数として扱う - モノをリソースとイベントに分ける - 実践したフィードバッグ
3人からレビューをいただきまして、ver1 でなんと 18件もコメントのやりとりをしていました。
いただいたコメントは、概ね以下のような内容です。
- 第1段落
モデリング（そしてテーブル設計）は重要になってきます。自明であるようでいて、なぜ重要なのか？を一言書くとより良い導入文になりそうに思いました！
- 第2段落
具体的なモデルやテーブルの単位まで落とし込むと、これで良いのか不安になったり、他のメンバーと意見が合わなかったりなぜ意見が合わなくなるのな(理由)や、実際に合わないときに出てくる言葉(事例)などをこのあとに織り込むと、あるある！と身近に感じられて良いかもと思いました
- 第3段落
「モデルの構造は誰が作成しても1つしか存在しない」自分は Theory of Models 初見だったのですが、この部分で TM ってすごそう（けどどういうこと？？）と思いました。下の「関係を関数、モノを変数として扱う」あたりが謎めいていて、このトークを聴きたい！ という気持ちにちょっとさせられたので、これを概要の部分で文章で説明するといいかもしれません！
- 第3段落
まさに夢のようなモデリング作成技術です自分のTM理解が浅いせいかもですが、ここを断定していいかは気になりました（本当か~!?と疑いが先行しそう）
- 第4段落
自ら実践した経験どういうところで実践して得られたFBなのかも書けてるとより良いかなと思います！
## 対象者上の説明を受けると、チームで開発する時にモデリングの議論で合意をとるのに時間がかかったり、社内でのモデリング規約を作りたいと思ってる人、みたいなのを対象者に入れてもいいかなと思いました。
- モデルやテーブル設計を改善したいが、どうしたら良いかわからない人既存のモデルの改善まで話入りますか？
おっしゃる通りだ・・・と思いましたし、甘い部分を見事に指摘されたなと思いました。
「なぜ」そう考えるかだったり、より具体的な説明や事例を入れることで、伝わりやすいプロポーザルになりそうです。また、内容について誤解を招くような表現をしていないか、気をつけたいところです。
改めて ver1 を見直して見ると、以下の一文には惹かれるものの、内容の具体的なイメージができず、期待できるトークなのか判断し辛そうな気がしました。
TM（Theory of Models）は「モデルの構造は誰が作成しても1つしか存在しない」という、まさに夢のようなモデリング作成技術です。
ver2
Webアプリケーションを開発・運用していく中で、1つのテーブルに日時カラムが増えていったり、巨大なテーブルが爆誕した、という経験はありませんか。また、これがプログラムの複雑さに繋がることもあると思います。このような事態を避けるために、私は、モデリングが重要なのではないかと考えています。 モデリングについては、DDD、sudo モデリング、イベントストーミング、UML図、アンチパターンなど、様々な概念や手法、ツール、書籍などを参考することができます。 しかし、モデルやテーブルの単位まで落とし込む際には、メンバーの経験や価値観によって解釈が異なり、意見が合わないこともあるのではないでしょうか。 Theory of Models(TM)は、2022年に発売された書籍「事業分析・データ設計のためのモデル作成技術入門」で提唱されるモデル作成技術です。この書籍の第3章では、以下のような記載があります。 > モデルの構造は、誰が作成しても1つしか存在しないというのが、事業分析のモデルです。 実際のところはどうなのでしょうか。 また、冒頭には以下の文章もあり、とっつきにくさを感じてしまうかもしれません。 > かつて、Ｔ字形ER法として体系化されていた技術を構文論・意味論（「数学基礎論」の集合論・関数論・モデル論）の観点から見直して、「関数」を中核に再体系化された技術体系です。 しかし、Theory of Models(TM) では、モデル作成技術が具体的な手順にまで落とし込まれていることが重要なポイントだと考えています。 本セッションでは、個人開発で試してみた経験も踏まえて、なるべく噛み砕いてお話ししたいと思います。 ## 対象者 - モデリングしたが、これで良いか不安になったことがある人 - モデリングの合意形成で苦労したことがある人 - モデリングの社内規約をつくりたい人 ## 話す内容 - Theory of Models(TM) のモデル作成技術 - 個体指定子（番号やコード、ID など）を使ってモノの集まりをつくる - モノをイベントとそれ以外に分けて、並べる - ルールに従って、モノとモノとの関係を構成する - ...etc - 個人開発で実践したフィードバック
ver1 でのコメントを受けて、改善できた部分もありますが、書籍の文章をそのまま引用したりして、迷走し始めている気配も感じます・・・。
ver2 では、以下のようなフィードバックをいただきました。
- 第1, 2段落は課題の共有としてスッと入ってきてとても良いと思いました！
- 第3段落「Theory of Models(TM)は、」から本文の終わりまで読んだとき、Theory of Modelsがどのようなものか? が分かるようになっていると良さそうです
- 現時点では本を引用しながらもそれを否定しているので、Theory of Models に関するmokuoさんが正しいと感じる情報があまり残っていない
- IMO: 第3段落を「Theory of Models (TM) は、書籍『…』で提唱されたモデル作成技術です。xxx な特徴があり、従来のモデル作成技術に対して xxx な点ですぐれています」のような構造になっていると読みやすそう
ver1 でのフィードバックを受けて ver2 では、より正確に情報を伝えるように意識して修正を加えました。
その結果、私が Theory of Models (TM) を良い！と感じているポイントや熱量が抜け落ちてしまったと思います。
ver3（最終版）
Webアプリケーションを開発・運用していく中で、1つのテーブルに日時カラムが増えていったり、巨大なテーブルが爆誕した、という経験はありませんか。また、これがプログラムの複雑さに繋がることもあると思います。このような事態を避けるために、私は、モデリングが重要なのではないかと考えています。 モデリングについては、DDD、sudo モデリング、イベントストーミング、UML図、アンチパターンなど、様々な概念や手法、ツール、書籍などを参考にすることができます。 しかし、モデルやテーブルの単位まで落とし込む際には、メンバーの経験や価値観によって解釈が異なり、意見が合わないこともあるのではないでしょうか。 Theory of Models(TM)は、前身となるＴ字形ER法を数学基礎論の観点から見直し、再体系化された技術体系です。誰が作成しても同じモデル構造になるように、規則に従ってモデリングするのが特徴です。 銀の弾丸、とまではいかないかもしれませんが、モデリングの指針となり得るものだと、私は考えています。 本セッションでは、2022年に発売された書籍「事業分析・データ設計のためのモデル作成技術入門」の内容をもとに、個人開発で試してみた経験も踏まえて、なるべく噛み砕いてお話ししたいと思います。 ## 対象者 - モデリングしたが、これで良いか不安になったことがある人 - モデリングの合意形成で苦労したことがある人 - モデリングの社内規約をつくりたい人 ## 話す内容 - Theory of Models(TM) のモデル作成技術 - 個体指定子（番号やコード、ID など）を使ってモノの集まりをつくる - モノをイベントとそれ以外に分けて、並べる - ルールに従って、モノとモノとの関係を構成する - ...etc - 個人開発で実践したフィードバック
書籍をそのまま引用するのをやめて、短い文章にまとめました。
銀の弾丸、とまではいかないかもしれませんが、モデリングの指針となり得るものだと、私は考えています という一文を加えることで、推している気持ちを乗せることができたような気がします。
ver2 と ver3 の変化が分かりやすいように、差分 (diff) も載せておきます。簡潔でわかりやすくなったのではないでしょうか。
Webアプリケーションを開発・運用していく中で、1つのテーブルに日時カラムが増えていったり、巨大なテーブルが爆誕した、という経験はありませんか。また、これがプログラムの複雑さに繋がることもあると思います。このような事態を避けるために、私は、モデリングが重要なのではないかと考えています。 -モデリングについては、DDD、sudo モデリング、イベントストーミング、UML図、アンチパターンなど、様々な概念や手法、ツール、書籍などを参考することができます。 +モデリングについては、DDD、sudo モデリング、イベントストーミング、UML図、アンチパターンなど、様々な概念や手法、ツール、書籍などを参考にすることができます。 しかし、モデルやテーブルの単位まで落とし込む際には、メンバーの経験や価値観によって解釈が異なり、意見が合わないこともあるのではないでしょうか。 -Theory of Models(TM)は、2022年に発売された書籍「事業分析・データ設計のためのモデル作成技術入門」で提唱されるモデル作成技術です。この書籍の第3章では、以下のような記載があります。 +Theory of Models(TM)は、前身となるＴ字形ER法を数学基礎論の観点から見直し、再体系化された技術体系です。誰が作成しても同じモデル構造になるように、規則に従ってモデリングするのが特徴です。 -> モデルの構造は、誰が作成しても1つしか存在しないというのが、事業分析のモデルです。 +銀の弾丸、とまではいかないかもしれませんが、モデリングの指針となり得るものだと、私は考えています。 -実際のところはどうなのでしょうか。 - -また、冒頭には以下の文章もあり、とっつきにくさを感じてしまうかもしれません。 - -> かつて、Ｔ字形ER法として体系化されていた技術を構文論・意味論（「数学基礎論」の集合論・関数論・モデル論）の観点から見直して、「関数」を中核に再体系化された技術体系です。 - -しかし、Theory of Models(TM) では、モデル作成技術が具体的な手順にまで落とし込まれていることが重要なポイントだと考えています。 - -本セッションでは、個人開発で試してみた経験も踏まえて、なるべく噛み砕いてお話ししたいと思います。 +本セッションでは、2022年に発売された書籍「事業分析・データ設計のためのモデル作成技術入門」の内容をもとに、個人開発で試してみた経験も踏まえて、なるべく噛み砕いてお話ししたいと思います。 ## 対象者
おわりに
ここまで丁寧にフィードバックをもらえるとは思っていなかったので、嬉しかったです。
また、レビューを通してかなり改善されたことを実感しました。圧倒的感謝っ・・・・！
いつかチャレンジしてみたいと思っていましたが、今回プロポーザルを提出できたのは、スマートバンクの文化やメンバーからの支援が大きかったと感じています。
本番では、みなさんに満足いただけるトークができるよう、頑張ります！！
スマートバンクでは、エンジニアを募集しています。
外部への情報発信を推進する文化や支援があり、チャレンジしやすい環境が整っています。
これまで行ってきた発信についてご興味あれば、ぜひ以下のサイトもご覧ください！
