# 20190827 HUPRO Product Team MTG

###### tags: `HUPRO`, `dev`

## Overview

会議（同時編集できたほうが「ここまで理解した」の共通認識を追いやすそうなので試験的にHackMD使ってます）

## Agenda

### これまでやってみた開発フロー改善施策の振り返りと反省

まずはここまでやってきたことのふりかえり

#### 1. 環境構築周りのdoc化、ファイル修正

1-1. 目的

- 環境構築でエラーが多発するので新しく入ってくるエンジニアさんにとってフレンドリーでない。直したい

1-2. ふりかえり

- これは十分そう、あとは Github の 「wiki > インストール方法」 の部分をどれくらいのレベル感で書くのか？

#### 2. KANBAN運用、issueの立て方

2-1. 目的

- 開発進捗の把握と共有
- 他チームからの意見吸い上げ

前者については達成できてそう

2-2. ふりかえり

- KANBANのカラムの区分は適切だったか → magazineのやつとかあったのでもしかしたら他に解決策あるかも？
- 優先度labelは機能してたか
- 全体的にlabelは機能してたか（シリーズ化したissue/PR用のタグは作っても良いのかもしれないと少し感じた、↑のカラムの問題に関連して）
- 他チームからの意見吸い上げについて → 今の運用方法はどんな点に問題があるか、どうするのがbestだと思います？

以下話し合い

- カラムがあるのはボリューム感が可視化出来てそれはそれでよかったかも
- label がコレ以上増えるとわかりづらくなってしまいそう...
- 見積もりはもう少し厳密にやってもいいかも（甘すぎ？）→見積もりのふりかえりが必要
- レビューの時間を含めた時間で取る？作業時間でとる？（今は作業時間で取ってる）
- 理想は一週間分の見積もりをベースにタスクの振わけができればよさそう
- 見積もりの表記方法も再考の余地あり
- magazine merge list みたいなやつ、kanbanではちょっと管理が難しい
- 来週火曜に改めて時間を取って話し合ってみます（考えてきてください）

#### 3. release logのフォーマットと共有方法の検討

3-1. 目的

- 他チームへのプロダクト進捗状況の共有
- ↑を通して、より社内全体のプロダクトにたいするリテラシーを高めていきたい

3-2. ふりかえり

- ルール的なものが決まったぶん我々の意識はいくようになったものの、効果自体はあったか？

以下話し合い

- 興味の観点で言うとあまり効果を感じなかった
- ドキュメントとしては良くなった
- Githubへのアクセスがハードル高め？
- kibelaにテンプレupしたけど...
- 結局slackが一番楽そう & 現実的そう

### その他ワークフロー改善提案

#### a. タイポなどの細かいミスを適宜修正するための別ルートを作ったほうがよさそう？

これは単純に、作業中に細かいミスあったら「ついでにやっといたよ〜」的なノリで修正するかしたほうが良さそうな気がしたので、こういう雑用に対する処理はどうするかを一度検討してもいいかなと思いました

話し合い↓

- fontの名前変えてほしいなどのわりと大きめだけどやったほうがいいなぁというレベルのissueもどうしようか決めちゃいたい
- とりあえずissueをたててその都度自分でやってルカさんにレビューを投げてみる
- →→ 見つけたらしゅっと直す、すぐ直せないものはどっかにためておく（slackなど）
- 気づきをためておける場所がほしい
- issueにしてもいいかも？（エンジニアは目安箱にポンポン投げていい）

#### b. slackのチャンネル一回整理したい

問題点、懸念点の整理

- 本来全部ログ残すべきなのに出来てない...（そのうち自分で作った車輪の再発明しそう）
- オフラインの記録のない会議・話し合いはチームで作るプロダクトにはあまり役立たないと思う

slackが有料化されるはずなのでslackに全部メモして議論する癖を付けたほうが良いと思いました

話し合い↓

- チャンネル整理する
- 関係ない人整理したい
- 松元さんや玲奈さんに相談

#### c. redashの活用

たぶん社内で松元さんくらいしかしっかり使ってなさそう？だけど redash がとても便利そうなので、データの収集・可視化に活用したほうが良いと思いました

https://redash.hupro-job.com/dashboards

mixpanelも同様...

#### d. doc管理どうするか問題

d-1. 現状の整理

- 決まったルールはない（or 徹底されてない）
- slack
- github（主にwiki）
- kibela

d-2. 問題点・懸念点の整理

- kibela は情報が流れる & カオス（ログと latest にすべき情報が設計&用途上混在してしまう）なので、最新版の重要な情報をとっておく場所には適してない可能性
- Github の wiki は現状更新が途絶えている（最新版？使われてない情報？）
- また、アカウントの問題で現状では特定のメンバーのみに共有したいようなドキュメントなどが個人に依存する → 集合知的に扱えない
- 例えば佐藤は Notion に書いて共有するなど、これは HUPRO dev team の資産になってないので組織的に bad

d-3. 決めたいこと

- 雑に投げる場所、ログ、latestな情報、重要な情報、特定のメンバーのみに共有したいような情報をどう管理するかをそれぞれ検討（すべて保存されるとベター）

話し合い↓

- エンジニアに必要な情報は全部wikiにまとめたい
- 時間取りたい（とりあえず今日やりましょう）

#### e. そもそもなんで会議とかするのか問題

1. アイデアを出す場所
2. 出されたアイデアを検討する場所

の2つがあると思うが、2.はリモートやチャットベースの議論ではなかなか難しいので、もうすこし1.を個々人の時間に委ねて2.を増やしてもいいと思いました

話し合い↓

- 分析する、振り返りが無い
- 施策もやりっぱなしで終わってしまう → 振り返りタイムほしい
- 分析と優先順位づけを紐づけるなど

#### ドキュメント整理

- 開発用アイパス→slack
-