Interactive

プロダクトバックログ

製品の判断、着手候補、実装作業を同じ場所へ詰め込むと、どこを見れば正しい情報があるのか分からなくなります。弊社では、Notion、リポジトリ、GitHubを役割で分けています。

役割

Notion

現在の開発、懸念、会議で決めるべき事項を、1つのページにMarkdownで書きます。データベース機能は使いません。管理の手間が価値を上回るためです。リポジトリのMarkdownにしない理由は、ブラウザから誰でもすぐに読み書きでき、同時に編集してもコンフリクトが起きないためです。長い仕様本文や実装計画は置きません。

リポジトリの.docs

背景、利用者の課題、製品判断、却下理由を残します。コードから生成できる一覧や作業進捗は置きません。

GitHub Issue

BugとFeatureは、まだ実装計画にできない不具合や要望を集約します。Taskは、着手可能な技術計画と進捗を管理します。未整理のアイデアや長期的な製品背景は置きません。

Pull Request

実際の差分、検証結果、残ったリスクを記録します。バックログ全体の説明は置きません。

同じ本文を複数の場所へコピーしません。各情報には一つの正本を決め、他の場所から識別子またはリンクで参照します。

バックログから実装まで

  1. 顧客の声や社内の着想を、解決策を決める前の情報として残す
  2. 製品の目的、対象利用者、期待する変化、やらないことを整理する
  3. 優先度と着手時期をNotionのページで合意する
  4. すぐ計画できる仕事はTaskを作り、大きな不具合や要望はBugまたはFeatureから一つ以上のTaskへ分ける
  5. Taskごとに実装、検証、Pull Requestを完結させる
  6. 実装中に変わった製品判断だけを.docsへ戻す

Issueの種類とテンプレート

Issueを作る前に、対象リポジトリの.github/ISSUE_TEMPLATE.mdまたは.github/ISSUE_TEMPLATE/を確認し、依頼に合う既存テンプレートがあれば優先します。既存テンプレートが共通ルールと矛盾する場合は、どちらかを黙って省略せず矛盾を報告します。既存テンプレートがない場合は、次の共通テンプレートを使います。

組織でGitHub Issue TypeのBug、Feature、Taskが有効になっていることを確認し、Issue作成時にTypeを指定します。Labelで代用しません。利用できない場合は、別の分類を勝手に作らず制約を報告します。

Task

実装方針を書ける大きさならTaskにします。BugやFeatureから派生したTaskは、概要の直後に親Issueを記録します。直接Taskを作る場合はParentを書きません。

[何を、なぜ変更するのかを説明する人間向けの概要]

Parent: #123

## Technical Challenges

- 影響するファイル、API、データ構造
- 実装前に解決すべき技術的な懸念

## Plan

[実装方針、選んだ理由、手順、トレードオフ]

### Tasks

- [ ] 実装する変更
- [ ] 必要な検証

BugとFeature

不具合や要望が大きい、調査が必要、または実装方針がまだ決まらない場合は、BugまたはFeatureとして利用者に起きていることを整理します。開発の知識がなくても読める言葉で書き、ファイル名や技術計画は入れません。実装へ進むときに一つ以上のTaskへ分けます。

[誰のために、何が起きていて、何を変えたいのか]

## Source

- External tracker: [参照ID](URL)
- Sentry: [SHORT_ID](Sentry permalink)
- Voice: [[signals/example]]
- Direct: 発信者 / YYYY-MM-DD

## Scope

- やること: 何が変わる、または直るか
- やらないこと: 今回の対象外
- 影響範囲: 誰のどの体験に影響するか

## Tasks

- [ ] #456 派生Taskのタイトル

Sourceは該当する行だけを残します。派生Taskをcloseしたら対応する項目を完了にし、すべて完了した時点で親のBugまたはFeatureをcloseします。

Pull Requestのテンプレート

Pull Requestは計画ではなく、実装結果と確認した事実を記録する場所です。対象リポジトリに.github/PULL_REQUEST_TEMPLATE.mdがあれば優先し、なければ次の形を使います。

closes #456

[何が変わり、何が良くなるのかを説明する人間向けの概要]

## Verification

- [ ] 対象機能を実際に操作して確認した内容
- [ ] 既存機能への影響を確認した内容

Verificationには、テストやビルドを実行したという事実だけでなく、ブラウザ操作やAPI呼び出しで利用者から見た結果を確認した内容を残します。

作業単位

一つのメインセッションでは、一つのIssueを完了地点まで進めます。関連しない修正を同じPull Requestへ混ぜません。大きな機能は、利用者へ価値を届けられる縦の単位か、他の作業と衝突しない境界で分割します。

一つのIssueに数時間かかることは許容します。長時間になる場合は、worktree、commit、Issue、Pull Request、検証結果へ途中状態を残し、中断後も現在の差分から再開できるようにします。時間を理由に別のIssueへ範囲を広げません。

実装後にIssueやNotionの状態を更新するだけでなく、Pull Request、検証結果、未解決事項が相互に追跡できることを確認します。