# カリスタ開発フロー検討事項

## タスク

### 各タスク流入元の整理 （新井さん、鈴木さん）
1. 質問系
- Slcakで適宜発生
- 軽いものはその場で即答
- 重いものは調査タスクとして計上する
- 優先順位、緊急性についての管理について検討
1. 広告系
- 既にタスクとして計上されているので、そのままいく。タスク全体の優先順位ルールは別途
- コンバスのバナー広告
- 受注したら期間が決まってすぐ反映
- Jiraに積まれて、ゴーサインだけでる。
- 事前に（例えば一週間）必ず決めるというのは厳しい
1. セレクション対応系
- 既にタスクとして計上されているので、そのままいく。タスク全体の優先順位ルールは別途
- 年に2回（4/11, 10/11）。半期毎のセレクション
- たまに修正がある（2か月に一回）
- イレギュラー修正は有料化の予定
1. サロン問い合わせ系
- 頻度少ない。ティースリーさんに任せられるなら切り離す→切り離せない作業があれば明確にしてタスク化
1. 社内インフラ系
- 頻度少ない。ティースリーさんに任せられるなら切り離す→切り離せない作業があれば明確にしてタスク化
- 社内のwifiとかは頻度低いはずなのでよそしなに。

1. 運用
- コンパスホームページの削除
- その他
- 運用保守の対応が対象のSlackにて以来が来て対応している
- 緊急度により、直依頼とタスク管理でわかれている

タスクとそれ以外の2つのみに絞る

### タスク管理 （新井さん、鈴木さん）
現在
全タスク → Jira プルリクエストもJiraに紐づけている
Backlogとgithub issue は使用していない。

1. Jiraに全て積まれた場合タスクにすべきかどうかの切り分けはステータス管理で行っている
- 要望とタスクは切り分けて管理した方が良いかも？
- 切り分ける場合要望はスプレッドシートレベルでも良いけどBacklogの方がより良い
- 状況ヒアリングして最終的に決める
- Jiraのステータス管理の徹底とフローの周知でいけそう

完了の定義がdevメンバーは開発終了まででリリースまでいってない場合がある。
-> 完了の定義とリリースフローを定義してdev以外の全員がわかる状態にする必要がある

## リソース
現在 松下さん + ミライト2名

### サービス緊急障害時の検討 （前田さん）
- サービスレベルの障害の対応を24365に近い形で松下さん一人が行っている
- 対応可能なリソースを増やす
- 外部に委託する
- 対応フローを24365以外のルールを策定する

PdMからOKがでる
開発がリリース可能な単位をはかってやっている

## プロダクト

### 開発体制の検討 （新井さん）
- PdMのリソースが少なく十分な受け入れ確認の時間が取れない
- 受け入れの基準や体制について検討が必要

時間をフレキシブルにしたい
MTGが生産性が低かった

- タスクの内容によってPdMの責任範囲が違う
- 解消する？

- 割り込みタスクが多く計画をたてずらい（主に松下さん）
- 割り込み時の優先順位を個人ではなくチームでルールを決める

- カンバンが機能していない
- カンバンのステータスがそのまま有効になる必要がある
- スクラムが機能していない
- スクラムにこだわる必要はないがとりあえず機能させるやり方に変える

- 既存品質の問題
- DB負荷があがってる
- セッション数はたいしたことないのに負荷が上がっている
- DBのindex等対処できることができていない
- 負荷分散
- 開発起因のタスクがあまり積まれる機会は少ない（案件起因では）

### フロー
現状
- 火曜（新居）
- プロダクトバックログリファインメント
- 要件・目的などを共有してもらう
- 水曜
- スプリントバックログリファインメント
- スプリントに積む単位に細分化する
- 木曜（新居）
- スプリントプランニング
- 優先順位を決めて、スプリントに積む
- 優先順位は他の方法で決められそう
- テレマタスクは確認は独立させて新居さんの時間を取らない方向にする

デザイナーの相沢さんがディレクション部分の工数を増やして新居さんの工数を節約する方向で動いている

検討事項
- レビューがない。
- リファインメントとプランニングという近しいものが3回もある

### デプロイ
※ フロー確認

### 一般的なgit flow から外れている理由の洗い出しとflowの正常化の検討

現在の手順のおかしなところ

> 作り終えたらPRをstagingとmaster両方に出す

- 現在の環境
- 本番
- ステージング
- テスティング（あまり使われていない）

環境は3環境あるので数は問題ないが使用用途が不明瞭

本番 → 実際の環境
ステージング → 本番相当の環境。機能の受け入れテストが可能
テスティング（開発） → 自由な環境

とできない理由があるかをヒアリング

時間の問題で全てできないのであればスクラムの方式にはこだわる必要がない
必須
- リリーステスト（スプリント単位
-

#### To Be
Dev/Ops化を目指す
開発完了→developブランチマージ→ステージングへ自動デプロイ→レビュー
リリースタグ付与→本番デプロイ

フローは基本のgit flowをベースとする方向に変える