🙆
Notionを使ったタスク管理を見直してみた
はじめに
Leaner Technologies の小久保 @yusuke_kokubo です。こんにちは。
今日は Leaner で Notion を使ってどのようにタスク管理をしているのか紹介します。
前提
最初にこの記事を読むための前提について軽くふれます。
ちなみに Notion 自体の使い方はある程度わかってる前提です。
なぜ Notion か
- ドキュメント管理からタスク管理まで幅広く対応できるツールであることが気に入っている
- Notion の特徴的な機能である「データベース」を使って柔軟に情報を管理できる
- その分、癖が強いので好き嫌いは分かれる
Notion でスクラムをやる難しさ
- スクラムのスプリント(タイムボックス)という概念と相性が悪い
- Notion の Databases ではタイムボックスをつくる運用には適してない
- Database のプロパティに「スプリント」を追加してボードをフィルターする運用はできるが、スプリントが積み重なると苦しくなってくる
- ベロシティの計測に手間がかかる
- Epic と Product Backlog
- Notion の Relation を使って Epic と Backlog を関連付けることはできるが手間がかかる
- そもそもスクラムの主役は Product Backlog なので Epic をどう管理するのかはツールに寄らず悩ましい
がっつりスクラムやりたい場合は Notion ではなく Jira の選択をおすすめします。
なぜ Notion を開発に使うのか
- 開発タスクの管理だけを考えるなら Jira や GitHub Projects を使った方がいい
- じゃあなぜ Notion?
- アカウント管理を煩雑にして情報が断片化することを避けたい
- 悪い例) ビジネスサイドはセールスフォースを使い、エンジニアは GitHub を使っているためにコミュニケーションを取るには情報のブリッジが必要になる
- ビジネスサイドと共通で使うツールとして Notion はよくできてる
- Notion 自体の開発が活発におこなわれているので将来に期待を持てる
- アカウント管理を煩雑にして情報が断片化することを避けたい
Leaner の開発プロセスについて
- Leaner ではスクラムをやっているわけではない
- だけど、Epic, Backlog という用語はスクラムから拝借してる
- スクラムでは Epic と Backlog は親子のような関係になるけど、Leaner では違う
- 本記事における Epic
- 1 ~ 3 ヶ月かかる大きめの機能開発
- 本記事における Backlog
- 1 週間以内に終わるちょっとした開発
今日の本題: Notion で Epic と Backlog をどのように表現するか
前置きが長くなりましたが、こんな感じでやってます。
Board view のグルーピング機能を活用
- "ステータス" をプロパティとしてつくって Group に設定
- さらに Epic と Backlog を "種別" として Sub-Group に設定
Backlog のフォーマット
- 背景
- 問題
- 課題
- 解決方法
- 仕様(受け入れ基準)
- 実装
※ 必ずしもすべての項目をしっかり埋めているわけではないです。
Epic のフォーマット
- 要件
- 仕様
- その他ビジネスサイドと相談したことのメモ
- タスク管理ボード
Epic には Epic のページの中にタスク管理ボードがあります。
なので、Leaner では 2 種類のボードを使ってタスク管理していることになります。
- Backlog と Epic を管理するボード x 1 個
- Epic のタスクを管理するボード x Epic の数
そのため Backlog と、Epic のタスクが混在することはありません。これは必ずしもよいことばかりではありませんが、すべてのタスクを Backlog として Backlog のフォーマットに沿って管理するのはオーバーヘッドが大きくなるため、Leaner では避けています。
なぜこうしてるのか
チームとして今何をやっているのか一目で見たい
- Epic と Backlog を 1 つの view で見たい(管理するボードを分けたくない)
Epic を扱いやすくしたい
- Epic に関する情報を一カ所に集約したい(管理するボードが分かれると情報が分散してしまう)
- 1 つに集約することでビジネスサイドとのコミュニケーションであったり、話したことのメモがまとまりやすい
- Epic 内のタスク管理はサクッとやりたい
- Epic 全体として要件がしっかりできていれば、1 つ 1 つのタスクの中身をしっかり書く必要はない
ここでは管理できない(していない)こと
- スケジュールやリリース日は Notion では管理しない
- やろうと思えば Timeline view を使ってあれこれできるけど、そんな日単位で細かく管理することに意味を見いだせない
- なので Leaner では Miro でロードマップをざっくり管理している
- Miro で管理していること
- 期日がある Epic
- 優先順位の高い Epic, Backlog
個人的な感想
あらためてやっていることを整理してみると気づいたことがありました。
- どこに情報を集約するか
- 情報を複数箇所に分散させない
- しっかりドキュメントを書くところと、手軽にすませてもよいところを分ける
- どのように情報を活用するか
- 情報が集約されてることで活用を促進できる
- どうやって周りを巻き込むか
- ツールによる情報の断片化を起こさない
- そのために何を犠牲にするか
- Jira や GitHub などの開発者向けのツール
- スクラムの文脈における Epic と Backlog
ということを気にしながらツールの使い方を考えてることに気づきました。
More Info...
もっと詳しく話を聞いてみたい場合はこちらからカジュアル面談申し込んでいただけると嬉しいです。(話題はなんでも OK です)
Discussion