デブサミ2020　個人的ふりかえり

少し時間が経ってしまったけどようやく時間とれたので今回初参加したデブサミ(2020)の振り返りをする。
内容は個人メモの延長だしデブサミそのものについてはきっとみんな書いているので省略する。
個人解釈混じりなので間違いを発見してくれた方はそっと指摘してくれると嬉しい。

### 視聴したセッション

|セッション |    登壇者    |
|:------------------:|:------------------:|
|「ともにつくる」を実践するドメイン駆動設計|成瀬 允宣[GMOインターネット]|
|プリンシプル・オブ・“ともにつくる”～ Web Performerを支えるドクトリン ～|上田 勲[キヤノンITソリューションズ]|
|問題から目を背けず取り組んでいく ･･･ 一休のこれまで（仮）|伊藤 直也[一休]|
|グランブルーファンタジーを支えるサーバーサイドの技術|小松 美穂[Cygames]/大橋 庸[Cygames]|
|メルペイリリースとその後一年間の裏側と学び|木村 秀夫[メルペイ]|  

それぞれとても興味深い内容だったけど、この記事では特に参考になることの多かった

- 「ともにつくる」を実践するドメイン駆動設計」
- 問題から目を背けず取り組んでいく ･･･ 一休のこれまで

について改めてまとめていく。

## 振り返り
### ①「ともにつくる」を実践するドメイン駆動設計」
#### 内容
```
ドメイン駆動設計はソフトウェアの利用者を含む関係者すべてが一丸となって開発するためのプラクティスで、まさに「ともにつくる」を実践する手法です。
このセッションでは、今再びソフトウェア開発の現場で盛り上がりを見せているドメイン駆動設計をキャッチアップできるようお話します。

セッションの内容は次を予定しています。

- ドメイン駆動設計とは何か
- ドメイン駆動設計がなぜ必要か
- ドメイン駆動設計の構成要素
- ドメイン駆動設計の経験談
- ドメイン駆動設計と私たちが目指すゴール
```
デブサミ公式より引用

#### ドメイン駆動設計とは何か
- 「ドメインに何が含まれるか（ドメインの対象）」を意識することが大切
- ドメインとは"利用者の生きる領域"
- ドメイン駆動設計とは、ドメインをコードに落とし込むための設計思想（方法論）
- ドメイン駆動設計とは、ドメインモデルを通してドメインとコードを地続きにするということ

#### ドメイン駆動設計の構成要素
##### ドメインエキスパート
- 開発者が意識すべきドメインにまつわる様々な知識と経験に精通した人
- 開発者はドメインエキスパートと協力しドメインを捉えることが必要
- 大事なのは「深いコミュニケーション」。ユビキタス言語（後述）を通して開発者が知らない概念を聞き出す必要がある  
　例）エキスパート「運送記録を残したい」  
　　　開発者「◯◯を××する感じですか？」  
　　　エキスパート「それだとちょっと違くて、実は△△というものがあって・・・」  
- この△△というのが実はすごい重要。ユビキタス言語を通した深いコミュニケーションのなかでこうした新たな概念を見つけ続けるのが大切

##### ユビキタス言語
- ユビキタス言語は開発者が主体となってエキスパートと協力して作る
- 開発者と利用者の双方が理解できる言葉であること
- ユビキタス言語は単語帳ではない
- ドメインにおける固有語があった際に、開発者である我々がそれを使うということではない
 - 開発者がドメインに合わせるというわけではない。

##### 境界づけられたコンテキスト
- 例えばECサイトにおける「購入」。利用者と開発者の「購入」は違う
- コンテキストで分ける。チームビルディングも分ける。

##### ドメイン駆動設計と私たちが目指すゴール
- ドメイン駆動設計は、開発者だけでは完結しない
- ドメイン駆動設計のためには、賛同者を集める必要がある
- 開発者とドメインエキスパート、そしてステークホルダーがチームとして頑張る
- ドメインモデルを元に、実装する段階でドメインがぼやけていることに気づくことも多々ある。その都度ドメインモデルにも反映させていくことが大切。
 - ドメインモデル→コード　ではなく　ドメインモデル⇆コード　の双方向

#### 感想
DDDについて、ドメインモデルを設計するまでを具体例等を挙げながら紹介されていた。
今までもDDDについてはQuicklyやその他書籍を読んでふんわりと理解していたつもりだったが、今回のセッションを通してぼんやりと見えていたDDDの輪郭がはっきりと見えるようになったと思う。
今いる現場は既にDDDを実践しているが、今後新しく入られた方にむけて理解できる説明ができるよう、自分なりに資料にまとめたりして知見を深めていこうと思う。

### ②「問題から目を背けず取り組む」一休の開発チームが６年間で学んだこと
参考資料
https://speakerdeck.com/naoya/wen-ti-karamu-wobei-kezuqu-rizu-mu-xiu-falsekai-fa-timuga6nian-jian-dexue-ndakoto

#### 内容
```
一休という会社に関わってから約6年。CTOになってから4年が経ちました。
当初は例に漏れず、たくさんの技術的負債、硬直化した開発組織、事務作業に忙殺されるリーダー陣など様々な課題を抱えていました。
6年を通じてそれらの課題をどう捉え、何を考え、どう乗り越えてきたのかを紹介します。
開発、組織運営を含むエンジニアリング全般あらゆる場面において、方法論に惑わされず、自分たちが今やるべきことに向き合っていくことがいかに大切だったかをお伝えできればと思います。
```
一休での取り組みを例として、

- 開発組織構造の転換
- レガシーコードからの脱却
- 基幹システム刷新プロジェクト

のおはなし

#### 参考になったこと
- 「チームが良い状態になれば、自分が良きリーダーになれば物事は上手くいく」という幻想
- エンジニアはとかくプロセスを盲信しがちだが大切なのは問題を解決すること（言い方は違った）
- https://speakerdeck.com/naoya/wen-ti-karamu-wobei-kezuqu-rizu-mu-xiu-falsekai-fa-timuga6nian-jian-dexue-ndakoto?slide=28
 - 難易度の最も高い問題こそが、本当に解決すべき問題だったが、いきなり切り込めないと感じ後回しになった
 - ある程度時間が経ったら「感覚が麻痺した」「目を背けて着手が遅れた」
- https://speakerdeck.com/naoya/wen-ti-karamu-wobei-kezuqu-rizu-mu-xiu-falsekai-fa-timuga6nian-jian-dexue-ndakoto?slide=77
 
スライドの上記URLあたりが特に参考になった。

#### 感想
私たちは常日頃から色々な問題に直面し、解決するためにどうするかを考えているが、そのやり方や目的が迷走した時に立ち戻るべき視点を与えてくれるセッションだったというのが感想。
私も今の現場で、本当に今それに取り組むことが問題を解決することに繋がるのかとか、本当に向き合うべき問題は別にあるのではないかとか、日々の議論について振り返らなければいけないことが多々あるのではと非常に耳が痛い（気がした）セッションでもあった。

## おわりに
今回初参加となったデブサミだったが、
各セッションにおける会社様、登壇者の方の実体験を元にしたおはなしはとても新鮮で、様々な状況における視点を与えてくれるとても良い機会となった。
こうしたカンファレンスや勉強会はまだあまり参加経験がないが、参加するたびに学ぶことの多い場であるなと改めて感じたし、今後も参加していきたいなぁと思う。