3/29 オンライン実装会ふりかえり
===

## GitHubリポジトリ
https://github.com/t2-kob/ModelingKai-Reservation

## 振り返ったとして、どうなったら良いんでしたっけ？ 振り返ったあと何するのです？
- 個人的には、みんな3ヶ月の中でどう学びがあったのかは、言語化したい
- 新しい参加者が入りやすいようにしたい → wikiとか、重要な点とかを整理することになりそう
- 何を学んだかを明らかにしたい。共有したい。 → テーマごとに振り返ったり、ツイートしたり。
- お題をバッチバチに仕上げたい。他のメンバーでも使えるようにしたい → オンライでの進め方テクニックとか、そういうのを明らかにする
- 雑にダラダラ話したい。同窓会的な感じ？ → 雑談式でいけるっちゃあいける

## 超重要テーマ: 「コマ」
永遠のテーマ

## 自然にやっているけど、オンラインモデリング&実装会をする上で、実は重要かもしれないこと
- ツールの使い方、使い分け
- Discord
- Google Hangout
- 交代方式
- ドライバーは2名
- Push&Pull方式での交代 ← LiveShareは使っていない！
- PlantUMLに慣れている人がいる
- メインパーソナリティが2名いる
- コメントの読み上げ
- 初めて会を開いたときは「オフライン」だった！ (初期段階でのオンラインモブが、比較的スムーズだった要因の1つっぽい)

## 雑にDiscordのログ拾う
- 当初想定/想像していたことと、やってみたら違ったこととかは、これから始める人の参考になるかも。
- コメントで参加してくれる人のモチベーションとスタンスは？
- PR投げたりIssueを立ててくれる人のモチベーションとスタンスは？
- 「オンラインモデリング会だからこそ勉強できたこと」とかなんだろう。
- Q&A集はよさそう → 参入障壁が下がる & お題の再利用しやすい
- 日本語プログラミングの感想、日本語プログラミングの向こう側
- ドメインエキスパートを立てたり、業務フローを決めたらもっとお題がよくなる？
- IDDD本の輪読と平行しているので、学びが深い
- :eyes: 他にもあるでしょ？ これみたら追記してくださいね

-----

## 2020/03/29 振り返り当日。
- 20:00〜23:00
- [Dicordのチャットのスタート地点へのリンク](https://discordapp.com/channels/432531367427964929/655740252576808971/693775750909788220)
- [コミットログ](https://github.com/t2-kob/ModelingKai-Reservation/commits/master?after=23add9372f8447227f6821b9bdf3f7d57093d552+69)

## ふりかえりアジェンダ

- コミットログふりかえり（タイムラインの代わりとして）
- モデリングした図と、クラス図の見比べ
- 日本語プログラミングの是非
- アーキテクチャ導入する前と後
- オンラインでモブプロするときの工夫的なもの
- ほか、喋りたいこと

---

## コミットログふりかえり

### 2回目(オンライン初回、2020/1/2くらい)
- UseCase の Reserve メソッドを同実装するかで喧々諤々。
- ドメインモデル図ではざっくりしていた(箱だけ決めてあった)ので、
実際に実装するときにそれぞれがイメージする『予約する』という内容にズレがあった。
- 予約する情報とは？
- コマ数？
- 予約のおばちゃんが居たり、チェックしてから予約したり
- ドメインエキスパートがいなかった。
- オンラインモブプロで、かつフラットな関係性なので発生した争い？
- 仕事と違って、納得するまで殴り合える環境だった
- 力関係っていうか、「まよったときにどう決めるか」が決まっていなかった(意思決定基準の話)
- 次回、Reserve メソッド品評会をやることに決定。

-----

### 3回目(2020/1/20)
- 113アーキテクチャを沿ってリファクタ
- IRepository インターフェースに、Find/Save といったベーシックなもの以外を持たせるかでワイワイ。
- 113アーキテクチャだとRepositoryはドメイン層だから、振る舞い持ってても良いんじゃないか論
- とりあえず、少し『スマートなふるまい』を入れてみる方向性とした。
- 「空きを確認する()」という振る舞いを持たせた。
- やったことなかったのでやってみよう論。
- Reserve メソッド品評会

### 4回目(2020/1/27)
- ユニットテストを導入。
- Repository を実装していったら、テストしたくなった。
- 予約RepositoryTest.cs から開始。

-----

### 5回目(2/2)
- チームの掟(方針) を導入
- 掟
- 論よりコード
- 無責任デリゲーション
- ワールドメーカー【俺がルールだ】
- まずは負けてみる（ゴン・フリークス@天空闘技場）

- 掟の意訳
- 口頭で議論するなら、コードを並べて議論すべし
- 迷ったら誰か1人に無責任に決断を委ねるべし
- 誰かが提案したら、いいぞー！と称えるべし
- 実験なので、率先して間違うくらいの気持ちでいくべし

- 掟を決めたことで、議論議論議論 な風潮から、やってみよう　って感じになった。
- 加速感でた。

- Enumで 予約時、予約分 を作った
- 度肝を抜かれた人も。
- 見ている人、新たに参加してくれた人も驚いていた。
- よかったこと
- 10:00-19:00というルールが、把握しやすい
- わるかったこと
- こうしたらよかった？
- 時と分をまとめた方がよかった？
- 時間と分の組み合わせで1つのオブジェクトにする説浮上 ← あらたなモデリングチャンス！？

-----

### 6回目（2/9)
- 日本語名 に寄せはじめた。
- ReservationRange ==> 予約期間
-
- 『コマ数』の嵐が吹き始める。
- コマ数や予約期間クラスに振る舞いを持たせたり
- 残コマ数とは・・・？
- (未だに定まらない感じ)

> 期間の表現の揺れは、アプリケーションモデルとドメインモデルの境界はどこか、という話っぽい。

-----

### 7回目 (2/23)
- 予約期間
- 時間が被っているかどうかといった、時間の比較を始めた

- プルリクを投げていただけるようになった

### 8回目 (3/1)
- Circle CI 導入
- あえてユニットテストを失敗する状態で終わるように
- どこから始めるかすぐ分かる。
- 期間が開く場合に使える戦術。
- 結構、力を発揮した。

- 日本語が混沌としてくる
- 予約された会議室
- 予約したい会議室
- 会議室だけど時間持ってたりとか。

### 9回目 (3/15)
- UseCase のリファクタに着手。
- 今まではもっと詳細(Repositoryとかとか) だった。
- おBarちゃん みたいな最初の議題まで戻って、UseCase で書くべきことを考え直した。
- UseCase のテストも作った。

-----

### 10回目 (3/22)
- UseCase のリファクタが完了。
- 予約する(予約希望 希望) という形に落ち着いた。

- Presentation 層はまだないが、とりあえず予約できるようになった。

- 「予約希望」と「予約済み」という概念になった。
- 元は、「予約したい情報」だった。

- コマ数という概念が炎上している。
- 一応、UseCase にも渡しているが・・・？

- 情報がどうまとまるか？　というものが明確化されてきた。
- 情報の明確化、整頓のきっかけは何か？
- モデルをコード化したこと
- 状態を表す名前が必要なのかどうか分からなくなった → 解決せねば　感。
- 違いを明確に言い表せない
- 違和感。
- 情報を保存したりすると概念が必要になってくる
- まとまった名前(恰好いい名前) にしようとした結果、『完全情報』が抜けて何か分からなくなった
- やりすぎて必要な情報が欠落した
- 必要十分な命名
- 情報過多の命名
- 情報不足の命名
- 2-3単語以内にまとめたくなった？
- 最初のころは文のようなメソッドとかを作っていた
- だんだん短い言葉になっていった
- 普段の習慣に引きずられた？
- 「予約」という言葉が抽象的で大きすぎた？
- コンテキストに慣れてきた
- 予約コンテキスト　においては、例えば『予約済みといったら会議室のこと』 と分かる。
- コンテキストマップがあると良かった？

---
## モデリングした図と、クラス図の見比べ

### 初回モデル図


### 3月末でのモデル図

-----

## 全体を通して
- 実は一度もドメインモデル図を更新してない
- 今どうなっているのか追えていなかった？

- 掟ができたことで、みんなで横道に嵌りに行った？
- 嵌りに行ける雰囲気になっていた。

- オンラインモブのプロトコルは安定していると思う
- GoogleHangout(通話&画面共有) + Discord(チャット)
- ドライバー交代方式は GithubのPush&Pull
- 開発環境は各自の自由でOK
- なぜなら、画面共有 + Push&Pull交代方式 だから。

- コンテキストマップがあるとよかったのかもしれない

- モデル図を更新するタイミングは？
- 随時やりたいけど・・
- めんどくさい
- 担当する人が居てもよかった？
- 何か仕組みを考えたい
- 例えば...
- モデル更新時間をつくっておく
- PluntUML のドリルをあってみるとか
- JIG みたいなコードをモデルに落とすツールとか
- C# なら ReSharper とか
- Sourcetrail とか
- モデル更新担当を交代で担当するとか

-----

### 日本語プログラミング
- 見るとわかるのいい

- 助詞とかが難しい
- is〇〇 を直訳すると、『に』とか『を』とかつけたくなる
- こんな感じにしたくなる
- 〇〇〇.を××() する
- 〇〇〇.に××() する
- public bool に引数が収まっているか教えて(コマ数 対象)　　　　← ※ 実在する

- クラス名ぐらいだったらいいのでは？
- メソッドまでやると大変

- クラス名を日本語にすると、インスタンス化したときに小文字が使えない問題とか発生。

- 日本語と英語が混ざっていると脳がバグる。

- 日本語だとニュアンスとか気持ちまで読み解ける
- 違和感が発見しやすい
- 「日本語から感じる違和感」を利用する
母語だから、ニュアンスや気持ちまで感じ取れますもんね。
like と love じゃないけど、絶対感じ取れるやつ

-----

- 全体を見ている時点では日本語のほうがいい
- そろって作り始めたら、英語のほうがいいかも
- 日本語いけるやん

- プロダクションで実際にやってみた
- クラス名日本語、メソッド名日本語、変数名は重要な奴・概念が難しいやつだけ日本語にするといい感じだった。
- フィルタリングの処理を1ステップずつやってみたらよかった。
- data_男性のみを抽出
- data_男かつ親が高学歴

- 良くないと思ったところ
- 日本語の検索
- かな送りとかの表記揺れ
- 漢字で書かれてるかひらがな
- 誤変換
- 群と郡

- 英語でも、単語の選び方とかで起こるのでは？
- 日本語のほうが異なるパターンが多そう

-----

### アーキテクチャ導入してどうだった？
- 会話しやすくなった
- 置く場所が決まってよかった
- 考え方を根拠が決まった

- 先週あたりで見つかったのは、Presentation 層からどうやって UseCase を使うか論
- オブジェクト詰め替えしていい？だめ？　というのが、前回まで
- ドメインオブジェクトを 公開する or 公開しない の基準

- アーキテクチャに対する理解があいまいだったので、それは危険だったかも

- アーキテクチャの勉強になった
- 理解してから導入するだといつまでもできないし
- 実験できたのがよかった
- アーキテクチャの実践って1人ではしにくい && 業務でいきなり変更するのは高リスクかつ高ハードル
-
- 勉強会と思ってない感？　実装会みたいに思っている(良いこと)
- ==> 勉強になった　と声に出したのは価値がある。

-----

### オンラインモブ会について
- プログラミング言語の習熟度に差があってもなんとかなっている
- 違う見方をする人たちが集まっているので勉強になる
- めっっちゃPR貰ってるイメージ

- 実践しながら、学べる集まり になっている(あまりない)
- 成功するのが前提の勉強会が多い
- 失敗前提でやれている
- むしろ失敗しようぜ！　とか
- やってみようぜ！　とか
- 『極端にやり過ぎてこそ、ほどほどのさじ加減がわかるようになる。』

-----

### オンラインでモブプロするときの工夫的なもの

- 【参考】オンラインモブのプロトコルは安定していると思う
- GoogleHangout(通話&画面共有) + Discord(チャット)
- ドライバー交代方式は GithubのPush&Pull
- 開発環境は各自の自由でOK
- なぜなら、画面共有 + Push&Pull交代方式 だから。

- ツールいろいろ試した
- LiveShare してみたり
- ファイル消しても復活するゾンビファイルに悩まされてみたり
- Zoom? Hangout? etc...
- Hangout ええやん
- Hangout の複数人で画面共有して、それぞれの画面へ切り替えられるの超いい
- ちょっと見て見て　　ってやれるの最高
- アカウント登録不要だし
- ブラウザで完結するし
- 入る直前にカメラOFFったりオフラインにしたりできる
- モブプロ向きかも。
- Google図形描画、HackMD など使おうとしてたけど、Hangout だけでいけるやん感
- ツールを増やしすぎないようにした
-

-----

- ドライバー交代方式でやった
- GitHub に Push ＆ pull
- 自分のターン(帽子)が明確になってよかった
- ドライバーが明確になる
- 見る側は見ることに集中すべき
- LiveShare だと部分最適になってしまうことも。
- 1日コミットになってそう
- 絶対コミットするところが良い
- やったことを記録できる
- コミットの数が増えた
- Hangout だと、切り替え時に見えてますかー？とか無くても出来た。

- 名前の指名制はよかった
- ○○さんどうですか～？　って直接指定してしまう
- チャット勢ににも名前掛けて聞いちゃう

-----

- チャット読み上げタイムつくる
- 意図して読み上げている(こばやし)

- オンラインでのモブプロは、各自が見ているところがバラバラになりがち。しかも、それを認識できない！
- チャットの読み上げは、視線を集中させることができる。
- 耳だけで聞けるのもよい
- コメントが拾われると嬉しい(拾われないと書く気なくなる)
- 「参加しているのだ」という意識で、皆いっしょになれるんすよね。

- 重要だけど、緊急ではない象限のおはなしを放り込んでいた
- ボイス側は拾うか拾わないかを選んでいる
- (全部拾うのはセミナーの時にやっているとのこと)
- 「内側の人が、チャットをひろうかどうか」が、判断基準になる

- 口で参加すると圧が強すぎる場合もある
- コメントは、見た目や態度、圧力みたいなものがすべてフラットになるので、とてもフェア〜
- 影響度を調整可能

- チャット勢として参加しやすかった(居心地良い)
- チャット勢が、参加した体になっているのが面白い

- 10人行かないくらいが丁度いい

- 自然と、部屋をわけているような感じかも？
- 「ファリシテータ・ドライバ < オンラインモブ < チャットモブ < 観てるだけの人」みたいな多重円構造でコミュニケーションの密度のコントロールができているのはとてもすばらしいとおもうー。
- 同心円状のオンラインコミュニケーション構造
- 円を乗り越えるの自由(チャット→ボイス、ボイス→チャット、その他)
- そういうコミュニケーション構造になっていることを明示して、
それぞれの参加者に期待する行動のパターンもモデリング会のガイダンス観て否か立ちで示しておくと、
参加し始めた人が馴染みやすいのではないかと思った。
- 意思決定はファシリテータ・ドライバ・オンラインモブ　の層まででやるとかしている

- ドライバーを固定している(なかじまさんとこばやしさん)
- パーソナリティも大体決まっている(大抵は、こばやしさん)
ってのはデカイと思います。
「押し付け」ではなく、「これはこの人」って決まっていると悩まなくてスムーズ

-----

- 意思決定の方法について
- 決まらないが課題だった(ていうかオフラインの時から課題だった)
- 前半「決まらないこと」に課題感感じてて、みんなもやもやしてたんすよ。
- そのルールも「途中で出来た」のですよね。試行錯誤でそうなった。
- たしかに！ 「なんかをよくしよう」から生まれた「結果」だ
- どっちも流派あるけど、どうする？
どっちでもいいけど…。
↓
小林さんがドライバーなので、小林さんのやりやすい方で

- グレンラガンモデル
- 「俺の信じた、オマエを信じろ！」方式
- (誰かの責任にしないことで心理的安全性を保つ、みたいな感じ)
- 誰かの責任でもなく、誰の責任でもないでもなく、誰かの判断を信じると決めたチーム全員の責任。
- 勉強会においてめちゃくちゃ良い。
- 「文句あるけど、文句なし」
- 「反対だけど、納得する」

- 停滞を避ける。
- どっちでもいい、が一杯いると一番苦しい。徐々に衰退する感じでつらい
- 意見をぶつけ合ったほうが全然よい

- 全員が一致しないとダメだとつらい。
- 多数決はつらい
- 否定されたくないし、否定もしたくないし、、、、となると停滞する。

- あえてやったことない事にチャレンジしてみる
- 相手のコンテキストを探りに行っていた
- 「俺は」「僕は」という枕詞ある

- セロリ

-----

### 次回試したいこと
- ドメインモデル図の更新
- ごちゃごちゃしたのは無理にコードで押し切ろうとしたから？
- 自然言語、絵や図を使ったほうが良かったのではないか

- ここから参加すると、既存のプロジェクトに参加する場合のシミュレーションになるかも？
- 途中からアクティブにモデルの議論に入るの大変
- でも何にも囚われていない新たな発想を貰えるのすごくいい
- 違和感
- 伝える側も難しいのでいいトレーニングになりそう

- 説明可能な成果物になっているかも問われる
- ？？？「なんで、コマ数なんすか？」
- ？？？「日本語だと！！！」

- 振り返りから入ってもらうといいのかも？
- 新しく来た人は、目の前のやるべきことに集中してしまう(するしかない) ような状況になりやすい。
- ルールとかを1から説明していくよりも、ここ数か月を振り返ると、経緯とかもわかるのでは
- オンボーディング
- 振り返りからの加入はモックでは実行できない
- 違和感と効果のトレードオフ

- 10分くらい更新時間入れてみる

-----

- コマ数を『何とか』したい
- まだノープラン

- ブログとかに学んだことを書き出したい
- Twitterハッシュタグでもいいんだぜ！ #ModelingKai

- どう現実に生かす？
- 日本語プログラミング導入してみた
- ReadMe とか充実させてみた
- 僕の場合、現場(Notプログラミング)でやっていることを、この環境で試しているっていう感じ
- チーム、言葉にこだわる、依存関係・抽象化
- 会議資料作りも Interface 、Interface設計だ。
- Interface(Contract) で終了条件を明確化する
- 内側・中身は、Interface が同じなら何やってもいい。
- 組織論、チームでも同じ。
- 実世界への応用性高そう
- 名指しの会話を増やしてみた
- 喋らない人に振ってみる
- 「どっちでもいいんですけど」、「考えてません」にならないように
- 「考えてないなら考えてないでいいですよ」とは言う。
- あえて喋られないのか、それとも参加できないのか
- 名指しにすることで、当事者として参加する姿勢を引き出すとか、
考えていても声に出していないことを引き出すとか、効果がありますね。
- ファシリテーションやチームビルディング

-----

- 次回何する？(みんな無責任に列挙した結果で良い)
- Presentation 層の実装
- モデリングっっだああああ！！！！
- ドメインとアプリケーションの境界を整理
- モデルの形の俯瞰と「こうしたほうが良い」の雑談
- モデリングとは関係なく「構造化」や「最適化」などの「一般的コード改善」の観点での抽出
- これまでの反省と考察の深まりを基に、モデルの抜本的な見直し
- モブプロ新人戦
- 予約開始時間と予約終了時間をまとめた１つの値オブジェクトの検討（脱・コマ数！コマ数⇒予約終了時刻の変換はPresentation層）
- ドライバーを新しい人にする(事前に環境構築してもらう必要がある)
- 「コマ数」撲滅バージョンを作ってみる
- HackMDのプレゼンテーションモードを試す
- モデル図を粗く描いてからコーディング、を試す
- 新人さんを連れてきてみる(実現可能性が問題)
- 動的側面の例として、「予約」の状態遷移をモデリングしてみる
- 定期的に、このようなふりかえりを、新人さんを混ぜてやってみる
- 今日中の宿題
- #ModelingKai ハッシュタグに学びツイートする(学びを言語化する)。

- 次回いつやる？
- 2020/4/12(日) 20:00～

---

## 仮説

- 既存チームに新メンバーがJoinしたときに、オンボーディングとしてチームのタイムラインふりかえりをやると、早く馴染めるのでは説
- 新メンバーはチームの歴史を知ることができる（どうして今こんなソースコードとなっているのか）
- 既存メンバーは、新メンバーのツッコミによる新しい視点を手に入れることができる（なんでこんなコードにしたのか、なんでこんな運用をやっているかなど

これはリーダー1人が、新メンバーに対してチームやプロダクトの説明をするより、遥かに有益そうに思える