フェイ＝サンの何か

このブログは筆者が感じたことを淡々と書くブログです．過度な期待はしないようにしてください

DroidKaigi2019の反省会(という名の言い訳)とか

CleanArchitecture Android DroidKaigi プログラミング

はじめに

DroidKaigi2019で発表してきた！

www.youtube.com

のですが、、、

はい、かえって混乱させてしまう事態を招いてしまい、

大変申し訳ありませんでした 🙇‍♂️🙇‍♂️🙇‍♂️

正直原因は自分の理解力が足りてなかったとか、説明力が足りてなかったとか、言語化があいまいだったとか、発表での例が悪かったとか色々あります、多分。
ので、反省会(という名の言い訳)とかをつらつら書いていこうと思います。
因みに「ユースケースとは何か」という話については、先に引用したツイートにあるブログがめっちゃ丁寧に解りやすく解説してくれてるので、ここではあまり触れません。

反省会：発表の何が悪かったか

原因は幾つかあるなぁと思ってます。

ワークショップ形式→発表スライドが良くなかった

まず、今回の発表の内容は一度社内のチームの勉強会みたいな場で話したネタを元に作られていました。ただ、その時はホワイトボードに書いたり、自分たちで議論しながら進めたりと、発表というよりはワークショップに近い形式をとってました。
その内容をスライドの発表形式にした時自分たちで体験してみるという過程がスッパリ無くなったので理解しづらくなったということが1つあるかなぁと思います。

改善策→ワークショップでやったことをそのまんまスライドにしない

ユースケースを複数の文脈で使ってしまっていた。

ブログで指摘されてますが、今回の発表で取り上げてた「ユースケース」という言葉ですが、自分でも知らず知らずのうちに複数の文脈で使ってました(猛省🙇‍♂️🙇‍♂️)。
発表で出てきた文脈は、
日常会話としての文脈、
DDDとしての文脈、
クリーンアーキテクチャとしての文脈、
コーディングとしての文脈、
の恐らく4つがあります(正直、本当に4つか？と言われると自信はないです)。
で、自分の中でもこの辺の区別がふんわりとしか理解できてないので(要勉強)詳しいことはブログのほうを参照でお願いします🙏。

改善策→DDDやクリーンアーキテクチャについて再勉強

よくよく考えるとビジネスチームに問題を先送りしてただけ感がある

ツイッターでもブログでも指摘がありましたが、ビジネスチーム次第で如何様にも変化してしまうのはさすがに良くないな、という話です。つまり、ユースケースはをビジネスチーム次第、と言ってしまっているので、じゃあビジネスチームの定義は？となってしまう感じです。
(完全に言い訳ですが)自分の所属するチームには仕様チーム(ビジネスチーム)が居て、仕様周りはそのチームに相談して決める、的な流れになっていました。なので社内の勉強会ではそこまで議論になることなく割とすんなり理解されてた(と思う)んだと思います。
が、それが一般的か？と言われると確かに微妙だし(現に仕様チームが居ない現場も経験してるし…)、仕様チーム次第じゃない？と言われるとまさにその通りかなと。
何がユースケースなのか、何がドメインモデルなのか等々はプロダクトによって決まる(DDDで言うところのドメインエキスパートの会話で決まる？)モノかな…というのが現状の理解です(ドメインエキスパートに近い役割の人が自分のチームはたまたま仕様チームだった、という話かなと)。

改善策→初見の人に発表内容を見てもらって、理解できるかを聞いてみる

さいごに

正直、発表した当時は「完全に理解した！」状態だったんですが、いざ指摘されるとまだまだ勉強不足だったなぁと痛感してます😥(諸々への理解度も不足だったし、発表そのものも未熟だった)
ただまぁ、この一連の議論が出てきたおかげで自分の理解も一歩進んだ…と思うので、発表が完全に無駄だったわけではないかなぁと思います(思いたい)。

いつになるかはわからないですが、いつか「クリーンアーキテクチャﾁｮｯﾄﾃﾞｷﾙ」状態で発表したいなと思います(目標は来年のDroidKaigi)。

とりあえずは、DDDの本とクリーンアーキテクチャの本、読み直します…