Working Agreement for Dev Team

Working Agreement とは？

Quden の開発メンバーがチームとして活動するうえで必要なルールを Agreement（同意事項）としてまとめたものになります
原則として性善説のもと運用しているので、各自が自律的に行動することを前提としています

運用ルール

Quden の開発メンバーは不定期に、開発に関連するすべての項目に関して振り返る MTG を設ける
その場で Working Agreement 自体の振り返りも行う

Working Agreement

稼働時間の共有について

業務委託メンバーの稼働時間はカレンダーに記載する
- 発行されている自身の Google Workspace アカウントに稼働時間を記載する
稼働時間は毎週日曜日 23:59 までに次の 1 週間分（月〜日）を入れておく (目安)
- 他のメンバーが同期的に会話をしたいなどがあった場合に、カレンダーが共有されていることで、Slack 等での日程調整を行わなくて済むため
- 日程を示すのは早ければ早いほうがありがたい
稼働時間の変更は稼働開始前に行う
- 前日までの変更は特に連絡は必要ない（MTG などで時間が抑えられてしまっていた場合は、個別にコミュニケーションを取る）
- 当日の変更は、自身の times チャンネルにて宣言する

同期的な MTG を始める基準について

まずは非同期での相談から始める（Slack、Quden など）
- いきなり同期的なコミュニケーションを行うのではなく、非同期での情報共有を事前に行うことで、有効的に同期的な相談を行えるようにする
同期的な方が明らかに解決が早いと判断した場合には、同期的なやり取りを行う
- Gather 上で作業している場合には、話しかけにいく
- カレンダー上で相談の時間を確保する

Daily Standup について

~~毎日平日の 17 時から 30 分ほどで行う~~
2025年12月1日現在、Daily Standup は廃止されている。フルタイムメンバーは平日10時から Daily Standup を実施しています。 Notion の Meeting Notes に記録を残しているので、必要に応じて参照してください。

開発チーム全体の振り返りについて

継続的な改善を行うために、開発チームで定期的な振り返りの場を設ける
主に下記の議題について振り返る
- タスクの細分化について
- Working Agreement の内容について

GitHub の PR 運用について

PR の Merge は、レビュワー１人以上の Approve が必要となる
- 実装完了後、レビューしてもらいたいタイミングでレビュワーを指定する
- レビュワーから実装に対するコメントなどが発生した場合、実装者はそれらを解消し、再度 Re-request review を行う必要がある
- 必ず、 Approve の状態になるまでやり取りを続ける必要がある
緊急性の高い PR 以外は、基本的にレビュワーの Approve がなければ Merge を行うことはできない
- 緊急性の高い PR とは、差し戻しなどで発生する Revert PR などを指す
Assignees には実装者自身に設定する必要がある
- コードの実装者は複数存在しても良い（たとえその実装が 1 行だったとしても）
PR には必ず EPIC か UserStory に紐づける必要がある
- どちらに紐づけるのか、それらは実装の内容や issue の大きさによる