皆さんこんにちは。

突発で開催された、おーひらさん、J.Nakajima さん主催のモデリング会に参加してきました。
神イベントで学びしかなかったのでアウトプットしようと思います。

なお文量が1万字を超えてしまいかねないので 『モデリング会 is 何？』というのは今回は紹介しません。
アバウトに言うと、お題をもとにわいわいモデリングしてみる会です。
J.Nakajima さんの Noteや Twitterの実況(?)を参照していただければイメージが湧くと思います。

余談

自作キーボードの聖地(?) 遊舎工房へ、人生初出舎しました。
あのキースイッチのサンプルマジ最高・・・

10時オープンで10時過ぎについたら既に3人くらいお客さん居たし、自作キーボード流行りまくり感ある・・・
作成中のキーボードもそのうち記事にします。

まとめ: 今回のモデリング会で学んだことや気付き

格言

• 『モデリングとはコミュニケーションだ』

モデリングに対する気付き

• ユースケース図を使わないという選択肢いいかも！
• 横文字プログラマ用語を使ってはいけない
• 名詞と動詞の付箋紙でモデリングが回りだす

日本語プログラミングに対する気付き

• 日本語クラスと日本語メソッドの可能性すごい
• もしかして非エンジニアさんと一緒にユースケース実装出来るんじゃないか？

感想

• モデリング会楽しすぎた
• 普段の会社生活の1週間分くらい脳みそ使った
• ファシリ力が半端じゃなさすぎた

　　
　　　　
以下、詳細です。

ユースケース図を使わないという選択肢

1つ目の気付きは、
『もしかしてユースケースを考えるときに、ユースケース「図」を使わないほうが良いんじゃないか？』
というものです。

　　
お客さんからこんな要望があります。
さあ、みんなでユースケースをモデリングしましょう！

こんなとき、ユースケース図を使う事が多いのではないでしょうか。
・・なんでユースケース「図」なんだろう？
　　
モデリングしようぜ！となると、なぜかユースケース図を使ってしまいがちです。
ついつい何となく、共通言語っぽい UML を使ってしまうのです。
ほら、ユースケース図ってそれっぽく読み書きするの簡単だし。ああアレね、ってなるもん。

　　
でもユースケース図そのものは、アクターとユースケースを線でつなぐ都合上、
書き直しが面倒だったり、グループ分けがし辛かったりなど、
『ユースケースを思考する』というフェーズにおいてはデメリットが目立つように思います。

でも、ついモデリングに使ってしまう。
今回のモデリング会では、そのことに気がつくことが出来ました。
　　
※ ユースケース図は、決まったユースケースを表すには良い方法だと思います。

絶対に「横文字プログラマ用語」を使ってはいけないモデリング

2つ目の気付きは、モデリングを進めるとき、
「ユースケース」に代表される 横文字プログラマ用語を使わないほうが良いということです。

　　
エンジニア用語には 邪悪な魔力が宿っています。

「ユースケース」、「バリデーション」、「アクター」、etc...

このような魔力を帯びた単語を見聞きしたとき、意識が『プログラマの帽子をかぶった自分』に持っていかれるのです。
頭の中には即座に具体的かつ詳細なイメージが出来上がってしまいます。

たとえば「ユースケース」という言葉なら、棒人間とユースケースが線でつながった図を思い浮かべるかもしれません。
「バリデーション」という言葉なら、ビジネスルールを飛び越えた先の、もっと細かな制約条件にまで思いを馳せてしまいがちです。

するとどうなるか。
話がどんどん詳細になっていってしまうのです。
私達は、お客さんの抱える問題を解決しようとしていたはずなのに。

実際に今回のモデリング会でも、バリデーションの話が始まったとたん急に話が詳細になってとっちらかりかけました。

だから、極力エンジニア用語を使わない。
ていうかアクターも要らないし、〇〇が××するという書き方もいらない。

お客さんの問題領域と正しく相対するために、「気を散らす存在」をすべて排除することが、
モデリングにおいて重要なのだと思いました。

きっとこれが出来るようになると、お客さんを交えたモデリングが上手くいくようになりそうな気がしています。
DDD で共通言語を作るとき、エンジニア用語は邪魔なんだよね。

その言葉はエンジニアの都合でしかない。
私達が興味を持つべきなのは、ドメインエキスパートの言葉だった筈なんです。

名詞と動詞の付箋紙で回りだすモデリング

3つ目の気付きは、
ユースケースを考える時、名詞と動詞を付箋紙に書いて貼り付けるモデリング手法が良いのではないか？
ということです。

　　
今回のモデリング会ではその場の流れで、具体的なモデリングを進める前に、
要望をもとに「動詞」と「名詞」をそれぞれ付箋紙に書き出してみるというフェーズがありました。
いわゆるブレストに近いですね。

(画像残ってなかった😭 のでイメージはこんな感じ↓)

□□■■
□□■
□□■■
□□■■■

□ = 名詞: 会議室、予約者、予約、予定人数　など。
■ = 動詞: 会議室を選択する、予約する、延長する　など。

こうして出てきた付箋紙を、ユースケースとなるように組み合わせてホワイトボードに貼り付けていきます。

するとあら不思議。
アクターという言葉を使わなくても棒人間を使わなくても、
〇〇を××すると書かなくても、近くに配置するだけで自然とユースケースが出来上がるのです。

線を描かなくていいので並び替えもやり直しも自由。
ジャンル分けもしやすいし、詳細化した付箋を上に貼り付けることも可能です。

これは、もしかして物凄く良い手法なんじゃないか・・・？

なんとなく、みんな頭の中では似たようなことをやっている気がしています。
でも先述したように、いざモデリングをしようとすると、
あるいはみんなでやろうとするとユースケース図になってしまうのです。

ユースケース図から意識を引き剥がすため、この方法をあえて名前で呼んだほうが良い気がする。
このやり方、名前はあるのかなぁ...？
ひとまず主催者のお二方の名前をとって 『ON図』と仮称することにします。

皆で話しながらホワイトボードへ付箋紙を貼り付けていきます。
すごい、議論が活性化しまくる。
これってこっちじゃない？ って言葉がどんどん出てくる。
付箋紙だからどんどん移動したり、上に貼り付けて上書きしたりもできる。

この黄色の付箋紙は「ルール」を表しています。
名詞と動詞に加え、ルールが追加されていきます。

後で気がついたけど、モデリングを進めるにつれて動詞が墓場に捨てられていきました。

パーキングロットだったり墓場だったり名前は色々ありますが、
こうして「今は考えないもの」を置いておく場を作るという手法は、
『気になっていること』を頭の中から追い出す手法として滅茶苦茶有効でした。
言えないとずーっともやもやして頭を専有するので。

そしてこれ ↓ が最終的なモデリング結果です。

『名詞』と『動詞』を付箋紙に書いて並べることで、
「誰が何をやって、すると何が出来上がる」という関係性を表現することが出来ています。
また 黄色の付箋で注意すべきルールを示しています。
ユースケース図よりも少し具体的な領域に足を踏み込んでいますね。

改めて見渡すと、『名詞』と僅かな『動詞』が残っています。
しかしこの動詞も名詞で代替可能な予感もします。
もしかするとON図で本当に必要なのは 『名詞』だけなのかもしれません。

ただし最終的に「動詞」はほぼ消えてしまったものの、議論の活性化に一役買ったので不要ではなかったと思います。

これらをユースケース図としてまとめるべきか、それとも他の表現にすべきかなどなど、
やり方を含めてもう少し検証が必要なように思います。

日本語クラスと日本語メソッドの可能性

4つ目の気付きは、日本語でプログラミングすることへの可能性です。

皆さんご存知ないかもしれませんが、実は C# は日本語クラスや日本語メソッド、日本語変数を使うことが出来ます。

私も、ユニットテストを書くときには日本語メソッドを使っています。
しかし日本語でクラスや変数を作ることは流石にしていません。

・・が、今回はモデリング結果をコードに落としていくにあたって、
なんと日本語クラスや日本語変数を使うというある種の暴挙に出ることになりました😁

するとどうでしょう。
何故かインスピレーションが湧いてくるのです。

何故だろう・・・？
当日皆で話したのは、違和感があるからかな、ということでした。
違和感が思いつきを生んでくれるのだと。

この説は今でも間違っているとは思っていません。
しかしあれから色々と考えた結果、
理由の中で最もウェイトが大きいものは 『私達が日本語ネイティブだから』ではないか？ と考えています。

　　
私達は日々英語を駆使して調査やプログラミングをしています。
そのため技術的な英単語であればある程度使うことが出来ます。

でも ドメイン固有の名称は頭の中にありません。
従ってドメイン固有の名称を英訳してしまうと、脳内で翻訳作業が発生します。
ただ読解の難易度が上がるだけではなく、あらゆる作業に翻訳・変換という微妙なオーバーヘッドが生じています。

プログラムで JSON をパースしたり、シリアライズ・デシリアライズすることを思い描いてください。
・・・パフォーマンスを気にしますよね？
・・・メモリの利用量も気にしますよね？

同じことが私達エンジニアの頭の中でも起きているのです。

コードを読む時は英語を日本語にデシリアライズ(あるいはパース) します。
コードを書くときは日本語を英語にシリアライズします。

そう、英語を翻訳するという作業は、私達の貴重な貴重な脳内メモリや処理速度を浪費しています。

慣れていなければ浪費の度合いも大きいはずです。
慣れていても、ブランクがあればまた慣れるまで浪費が続きます。
めっちゃ慣れていたとしても、やはりほんの少し脳内容量を使っているように思います。

であれば、脳内容量を浪費している枷を外すためにも、
私達は 日本語クラスや日本語変数を積極的に使うべきではないか？という疑問が生まれてきます。
※ VisualStudio を使っていれば日本語に Intellisense も効きます(マジで)。

　　
DDD ではドメインエキスパートと共通言語を作っていきます。
そこでもやはり、ドメインエキスパートは日本語話者であり、用語も日本語です。

なのに、クラス名は英語・・・
それって何かおかしくないでしょうか。

英語話者は、DDD で共通言語を作る時そのまま英語を利用できます。
では私達日本語話者はどうするべきなのでしょうか？

もしかすると『プログラムに日本語を使う』という行為は、日本人の DDD にとってものすごく効果的なのかもしれません。

今度のプロジェクトでお試し導入してみようかな・・・

日本語クラスやメソッドのさらなる可能性の芽

日本語クラスやメソッドを使うと、非エンジニアさんと一緒にペアプロやモブプロが出来るのでは？という予感がしています。

var予約結果=管理者.予約(予約情報);

変数の戻り地がーー　とかいうプログラマ用語ではなく、
「管理者が」「予約すると」「予約結果が出来る」というように日本語で会話可能です。

もしかしてもしかすると、ドメインエキスパートさんと一緒にプログラムを書けるんじゃないだろうか。
少なくともクラス構成やメソッドのシグネチャを考えながら、
ユースケースを形作るためにモデリングとプログラムを行ったり来たりする、という入り口は一緒にできる気がする。

なんだろう、すごくワクワクしてきた！

日本語をプログラムに使うことって、日本語話者による DDD と滅茶苦茶相性が良い気がする。
まだまだ思考も検証も必要だけど、これは追求して見る価値があると思う。

問題は、タイピング量がちょっと増えるってこと。
クラス 田中があるとき、ｔとタイプしたら Intellisense が効いてくれたらマジ最強な気がする。

MS さん、どうでしょう😁

それか t田中や n中川みたいな感じで頭文字をつけるのもいいかもしれない。
(システムハンガリアンみたいで体が拒否反応を示すけど。。

おわりに

いろいろ振り返っても、やはり学びの山でした。
皆でやった FDL(Fun-Done-Learn というふりかえりの手法) の結果を見ても、Learn が一杯あってすごかった。

また土日にあれば参加したい！ と思えるすごくいい勉強会でした。刺激もいっぱい貰えた。
いつもこんな勉強会出来るなんて東京住みの人が羨ましいです😭

おーひらさん、J.Nakajima さん、そして参加者の皆さん、ありがとうございました！