---
# System prepended metadata

title: 全体MTG

---

## 開発スピードを上げるにあたって

- 日付:2020年1月9日 13:00-15:00 @振り返りMTG

### 課題感

#### 飯野さん：
リニューアルということもあり、スピード > 質に倒している。観点を減らしたりしてレビューの質を若干緩めれば早くなるかも

#### 高橋さん：
捨てる項目を明確にすれば早くなる。例えば1回目のレビューで終わりにする。一回見たら動作確認はしないetc…
しかし、決定的な「これ」というものはない
toC向けという事もあり、質を落とすにも限度があるので難しい
書き方的な所で言えば、現状は5分以内でリファクタ案が出るようなら提案、出なかったらスルーで運用している

#### 簗瀬さん：
悩んで聞きに行くのが遅くなる
聞きにいって判明することもあった
そこが早くできたら良かった
待ち時間は特になかった
詰まった、詰まりそうなときはペアでやる様にした
結果前よりは早くなった

#### 飯田さん：
こだわり過ぎていた感はあったかも
もっとこうした方が取り回しが効きそうとかを考え過ぎていた
まだ前提知識とかが不足していて、全体を見渡すことができていない

#### 鳥淵さん:
個人面：
- spec書くのに時間かかる。テスト1 : 実装1ぐらいの割合
- レビュー対応に時間がかかっており、その工数が見積もりに入ってない気がする？

全体：
- レスポンシブ対応についてのやりとりを鑑みるに、事前にもっと連携がとれていればよかった
- MTGやるのはいいが、何が目的になっているかが不明瞭だった（と感じる）
    - とくに定期的にやってるMTGについて
    - 例)今回のMTGだと、アジェンダが欲しかった

#### かみPさん：
- 事業部の方針としては、上半期までに(６末までに)リリース目標としている
- テストについては手動テストで担保するもあり
- ユーザーストーリーごとにspec必要か・不要かを書いてもいいかも？

---

メモ欄：

TODO(今後やれそうなこと):

### 実装
- スピード > 質に倒す
- 書き方についてはこだわり過ぎない

### テスト
- テストを書かない
- テストを書く範囲を限定する
    - 例えば正常系のみ書く
- ユーザーストーリーごとにspecを書くか/書かないかを決める
- SystemSpecでも、QAに

### レビュー
- レビューの観点を減らす
- 二度目以降のレビューで動作検証しない
- 必要に応じてペア作業を盛り込む

---

# 全体MTG

鳥淵さん：
- Q：最小の横幅は？
    - ３２０px以下の場合には考慮しなくて良い(最小デバイスがSE)

飯田さん：
- アイコンロード中の画面の依頼等はどこでやればよいですか？
    - Slackでお願いします（ながたきさん）

ながたきさん：
- Notion
  - ScrumMateにいれてるタスクをNotionに以降
  - アプリのキックオフまでにWebでやり残したことをやっておきたい
- タスク
