登壇というアウトプットで得られたこと

12/14(土)に下記のイベントで、「設計に関していま取り組んでいること」をテーマに登壇をして、そこからの知見を書いていきます。
ちなみに、登壇は初。

https://genbade-ddd.connpass.com/event/156060/

スライドは以下。

今回自分が得られたこと

今回の登壇によって自分が得られたこと

・登壇したときの空気感とかの経験
・2〜3週間くらいで20分くらいのスライドに纏められたという知見
・壁打ちの大切さ
・インプット＜アウトプット

壁打ちの大切さ

今回のスライド作りには、周囲の方にご協力頂き、2回の壁打ちをしました。

1回目は、社内でリハーサルLT。
2回目は、知り合いのエンジニアにレビュー。

特に2回目については、このスライドを通して「どういうことを伝えたいのか」という話になり、それを深堀りしていくうちに本当に伝えたいテーマというのが見えてきて、スライドを大幅に作り変えていきました。

おそらく自分ひとりでスライドを作っていたら、「とりあえず設計に関する経験を伝えるだけ」のスライドとなっており、明確になにかテーマみたいなものを伝えられなかったんじゃないかな、と思いました。

インプット＜アウトプット

今回参加したイベントの副題にもあるインプット＜アウトプット

とにかくアウトプットしようとして感じたのは、自分のインプットは散らかっていると思いました。

経験談ベースで色々語ろうと思ったけど、その経験談自体が断片的だったので、ちゃんと思い出して纏め直して、出典が必要なところは本を読み直して……。

たぶんインプット偏重になっている場合では、このアウトプットに際してのインプットが整理出来ていないという焦りは感じないんだろうなーという点で、今回の登壇の機会は良い経験でした。

アウトプット後のフィードバックによるインプット

登壇した後、いくつかフィードバックを頂くことができました。

・作ったモデルをどうチームで共有をしていくか
・モデル自体に抽象の段階があって、更に実装に寄せたモデルが必要である
・実際、ユースケースとどう違うのか？

ユースケースとの違いについてですが、
通常のユースケースに、アクターの要求も紐付けて、トレースできるようにしているのがRDRAだと思っています。
ユースケースも誰かが必要だと思って導き出したものだけど、それが妥当かどうかが判断しづらい為、アクターの要求を可視化することによって妥当性を客観的に判断することができるので、個人的には扱いやすいなと感じています

モデル自体にも抽象の段階がある、という話は聞いていてなるほどなーと思いました。
顧客に見せる程度のモデル、E-R図とかクラス図など、ほぼ実装に近いモデル。
たしかに自分が要件定義でRDRAを使っているのは、あくまでシステムの概観を素早く理解するためのツールに過ぎないと思っており、そこからクラス図なりに落として、そこからコーディングしていく必要はあるんだろうな、と感じました。

たとえばこんな感じの抽象度というか、誰向けへのモデルなのか、みたいな感じ。
自分が話したのは、ユースケースあたりまでの話で、更にそこからエンジニア向けの突っ込んだモデルは必要なんだろうと思います。

この辺、いま誰向けへのモデルを書いているんだろう、というのも合わせて意識できるといいのかな、とも思いました。