こんにちは!!
BOXIL SaaSのエンジニア兼テックブログチーム平社員をしているブラーバです。今週は弊社テックブログチームのスクラム月間(勝手に言ってる)ということで、プロダクトバックログの管理をNotionで行っているお話をしようかと思います。
もともと、弊社では社内のドキュメントを他のドキュメントツールで管理していましたが、以下のような理由でNotionへの移行チャレンジをしています。
- 同時編集を手軽に行いたい
- 柔軟にドキュメントの階層を設定したい
- そのドキュメントの作成者がオーナーのような感覚になり、同じようなドキュメントが乱立してしまう
そして、同時にNotionはタスク管理ツールとしてもさまざまな機能やテンプレートが存在するため、BOXIL SaaS開発チームではプロダクトバックログの管理まで試みました。
このNotionチャレンジから半年以上経ちましたが、さまざまな試行錯誤をしてきました。 今回はその試行錯誤の中身をこのような方々に共有できればなと思います。(ここ半年くらいの試行錯誤をアウトプットしたかっただけなんてことはない)
- スクラムをある程度知っていて、Notionを社内ドキュメントとして利用している方
- Notionをタスク管理ツールとして使えるか不安な方
- すでにNotionでプロダクトバックログの管理をしていて、困っている方
BOXIL SaaSの開発チームについて
まずはBOXIL SaaSの開発チーム(以降、開発チーム)がどのようにスクラム開発をしているかを説明しようかと思います。 (スクラムなんか余裕で知ってるZE☆という方々や早く本題に入らんかい!!という方々はぜひ本題のNotionでプロダクトバックログの管理をやってみた結果に進んでください!!)
開発チームの人数は現在10人弱です。 スプリントの期間は2週間であり、以下のスクラムイベントが存在します。
- スプリントプランニング
- デイリースクラム
- リファインメント
- スプリントレビュー
- レトロスペクティブ(振り返り)
そして以下図の流れでアイテムが生成され、リファインメントでアイテムの理解をし、スプリントプランニングで2週間でこなせそうなレベルまでタスクを細分化しています。
各部門から上がってきた機能改善や施策等をPdMの方々が管理しているデータベースで管理されています。
それらのアイテムをリファインメントを通じて見積もりをし、優先度順にNotionのテーブルビューとして存在するプロダクトバックログのテーブルビューにアイテムが追加されます。
そしてスプリントプランニングにてプロダクトバックログのテーブルビューから次のスプリントで達成できそうなアイテムをスプリントバックログのテーブルビューに移動し、スプリントが始まるとそれらを着手するという流れです。
プロダクトバックログとスプリントバックログのデータベースが同じであるため、それぞれのテーブルビューに表示される条件にアイテムを変更すればスムーズにアイテムを移動させることができるようにしています。
さて今回はプロダクトバックログとスプリントバックログのテーブルビューに表示されているアイテムのデータベースについて半年強(一年弱と言っても過言ではない..?)の試行錯誤を書いていきます！
Notionでプロダクトバックログの管理をやってみた結果
ここまで順に読んでくださった皆さん、読み飛ばしてきた皆さん、ここまで長々と書いてきましたがここから本題です。 前述のプロダクトバックログとスプリントバックログのテーブルビュー、そしてアイテムの中身をそれぞれ説明したいと思います。(早く説明せい)
こちらはプロダクトバックログのテーブルビューです。(流石にテストで作成したアイテム以外は載せたら怒られそうだったのでマスキングしてます、怒られるのヤダ...)
スプリントプランニング時には優先度の高い順からスプリントで達成可能なレベルにまでタスクを細分化するため、タスクがどうしても階層構造になります。そのため、Notionのサブアイテムという機能を利用し階層構造を表現しています。
また、上のキャプチャでは表示されていませんがフィーチャーやエピックなどの大きめの粒度のタスクも同様のデータベースで管理することがあるため、その際は開発カテゴリというマルチセレクトでラベル付けをしたりします。(そのラベルだけを表示するテーブルビューなどを作れたりする)
ここからチームのベロシティを考えつつ、スプリントで達成可能なアイテムをスプリントバックログに入れていきます。
そしてこちらがスプリントバックログのテーブルビューです。
Sprint番号というプロパティを入力するだけでプロダクトバックログからスプリントバックログに移動できるようにしたかったため、スプリントバックログのテーブルビューのフィルターにSprint番号が入力されているかという条件を入れています。
また、このテーブルビューはNotionのグループという機能を利用しSprint番号でグループ化しています。
完了したスプリントはグループ横の三点リーダーから非表示をしています。(アーカイブみたいな感じ)
Notion 2.13：データベースのグループ化・サブグループ化
そしてNotionはもちろんドキュメントツールなので、スクラムにおいての生きているドキュメントとして活用しています。
以下がテストで作成したアイテムの中身です。
開発チームではスプリントプランニング時にアイテムの完成の定義を決めています。
そのために必要な情報である背景やユーザーストーリー、受け入れ条件などをアイテムの本文に書くようにしています。(執筆時にちょうどお腹が痛かったわけでは断じてない)
これらの項目はNotionのデータベーステンプレートという機能を利用し、アイテム作成時に自動で挿入されるように設定をしています。
リファインメントに持ってくる前にこれらの項目を埋めるだけで、リファインメントがスムーズに行えるため、非常に便利です。
このようにNotionでプロダクトバックログのアイテムの管理をしています。 次の章では、このデータベースに次々と追加されていったプロパティの紹介をしていきます。(たぶんここがミソ..?)
尋常じゃない量のプロパティ
使っていないプロパティも存在していますが現在36のプロパティがあります。(絶対ありすぎるので棚卸しを今、誓いました)
その中でもこのプロパティの運用はうまくいっているな、というものを紹介しようと思います。
Sprint番号
前述の通り、スプリントバックログのテーブルビューに追加するときに設定しているプロパティです。
もともとこのプロパティは日付になっており、スプリントの期間が入っていましたが管理が大変ということからセレクトになりました。
しかしながらどうしてもスプリントを跨いでしまうタスクがあり、現在はマルチセレクトに落ち着いています。
おかげでNotionのグループという機能を使いつつ、開発チームが見るテーブルビューのメンテナンスがとても楽になりました。
また、このプロパティで簡単にどんなタスクを行っていたかのテーブルビューを作れたりするのもとてもいいところです。
PointとPlanning Point
開発チームではリファインメント時に工数をストーリーポイントで見積もっており、その際にPlanning Pointを入力します。
そして実際に着手しアイテムが完成したタイミングで、着手した人たちの体感に基づいてPointを入力するようにします。
これはリファインメントやスプリントプランニングの精度の振り返りに利用するための分析用に入力をしています。
このプロパティ導入時はベロシティが不安定で開発スケジュールがうまく立てることができておらず、その対策として追加されました。 これにより振り返りで分析ができたり、実際に消化できるベロシティがどのくらいなのかが大体把握できる様になりました。 (今はブレても±1ptなのであまり振り返ることも少なくなった)
親タスクとサブタスク
このプロパティも少し出てきましたが、親子関係を表すために追加しました。(親タスクなのに子タスクじゃなくてサブタスクなのは目を瞑ってください)
小さなバグ改修から1ヶ月以上かかる施策などアイテムの大きさはバラバラです。開発チームでは2週間のスプリントで終わらせる大きさにまでアイテムを細分化しますが、その親子関係を表現するために利用しています。
また、Notionのアップデートによりテーブルビューでも親子関係を表示できるようになったときは、感動しましたね。(ただのNotionヘビーユーザー)
また、親タスクのテンプレートはタスクを細分化する前提で作られています。そのアイテムを親タスクにしているアイテムを表示するテーブルビューがテンプレートに入っており、わざわざ親タスクを設定しなくてもテーブルビューの+新規からサブタスクを作成できます。
親タスクには背景やユーザーストーリーは必要ですが、サブタスクには必要ないことが多々あります。 そのため、サブタスクで利用するテンプレートでは現状と、そのタスクで何をしたいかなどだけを書けるようにしています。 Notionはテンプレートを複数用意できるため、非常に便利ですね！
ドキュメントのリレーション
開発チームではできるだけスプリントプランニングでどのように着手するかの認識の共有しており、手戻りを防いでいます。 しかしながら複雑なロジックや仕様理解が必要なアイテムも存在します。 そのような場合は社内の他のチームのようにDesign Documentを作成することにしています。
このリレーションも親タスクのテンプレートに追加しており、+新規からドキュメントの作成ができるようにしてあります。(これめっちゃ便利というのを伝えたい...)
実装の効果
レトロスペクティブや期末の振り返りなどでよく出てくる話題として「自分たちがどのくらい価値提供したかわからない」というものがあると思います。
そんな意見をPdMの方が吸い上げてくださり実装の効果というリレーションが生まれました。
これはアイテムのオーナーなどが実際にどのくらい効果があったのかを記載してくださる、別のデータベースへのリレーションです。 このデータベースにもテンプレートが用意されており、開発業務とあまり関わりのない人でも記入しやすいようになっています。(この記事を書いているときに初めてテンプレート見たなんて言えない)
(だんだん楽しくなってきた...)
所感
ここからは、1メンバーとして他のタスク管理ツールからNotionにチャレンジしてみて感じた所感を述べたいと思います。(一応移行チャレンジからずっと試行錯誤してきたメンバーの一人のはず...)
メリット
ドキュメントツールとタスク管理ツールが同じだって?!
何と言っても一番のメリットはドキュメントツールとタスク管理ツールが同じことです。 今まではタスク管理ツールにドキュメントにリンクを貼ったりPRにアイテムのリンクとドキュメントのリンクの二つを載せていたりしましたが、一つに集約していることでオーバーヘッドがかなり減ったと思います。
またアイテム自体がドキュメントにもなり得るため、スクラムにおける生きているドキュメントとしての振る舞いがストレスなくできます。(アイテムの中に書きすぎて別途ドキュメントに起こすときにコピペしたり同期ブロックとしてペーストしたり...)
このメリットが個人的に一番大きいなと思います。
自由性
開発チームではパーソナル部屋というものを作っており、その中ではそれぞれの思い思いのNotionの使い方をしています。
Tipsや業務知識をドキュメントの仮置き場として、ひたすらページを作っている人やたくさんテーブルビューを作っている人もいます。
私はNotion上でも個人のタスク管理をしており、プロダクトバックログのデータベースに一方的なリレーションを貼ったり、次のデイリースクラムで話すことをメモったりしています。
(ToDoを早く消化しろ自分...)
このようにカスタマイズ性に優れていたり、データベースが参照しやすかったりするため私達エンジニアとも相性が良いのかなと思います。
新しい機能が増えていくのが楽しい
Notionチャレンジ当初は親子関係を表す機能や依存関係を表す機能などはなかった(たぶん)ですが、どんどん新しい機能が追加されることによって、個人的にNotionの沼にハマっていきました。 (新しいもの好きとしてはたまらんです)
デメリット
あくまでドキュメントツール
さっきと言ってることが真逆な気がしますが、Notionはやはりあくまでドキュメントツールです。 そのため、AsanaやJiraでできる◯◯◯ができない!!みたいなことはあります。
私達のNotionの使い方が悪い説もかなりありますが、親子関係や依存関係が複雑になりすぎて管理しづらくなってしまうアイテムがあったり、半期の振り返りのときにわざわざAPIを叩いたりと手間がやはりかかってしまいます。
多機能すぎる
とはいえ、Notionは機能が豊富だと思います。そのおかげで痒いところに手が届いたりするんですが、私達のチームにとって必要な機能と必要でない機能の取捨選択が難しいなと感じるときもあります。
便利ということと管理が煩雑になるということはトレードオフなのかなと思います。(頑張って管理します)
自由すぎる
管理が難しいという文脈で同じではありますが、やはり自由なことがデメリットになるときもあります。
ここ半年でプロダクトバックログのアイテムが突然消えていたり(フィルターにかからない条件になっていた)、ロックをかけていないテーブルビューのプロパティが勝手に変わっていたり(あとでロックをかけた)しました。 他にも、誰が追加したか分からないプロパティがあったり(データベース自体にもロックをかけたが誰が使ってるか分からないから消すに消せない)と、管理が難しいなという印象があります。
しかしながらこれはしっかりとデータベースを管理するオーナーを決め、使い方をまとめたドキュメントなどが整備されていれば解決する問題なのかもなと思います。(ドキュメントって大事..!!)
まとめ
弊社ではドキュメントツールをNotionにしようという動きがあり、タスク管理もできるんじゃないか？という淡い期待を寄せて半年強ほどNotionチャレンジをしてきました。そのメリットとしてはやはりドキュメントとタスク管理が一つのツールに集約されていることだな(当たり前)と執筆しながら感じました。おかげで価値のあるドキュメントが作れたり、オーバーヘッドがかなり減ったりと開発チームの生産性が爆上がりしています。
しかしながら多機能が故、管理が難しく、しっかりとしたルール整備や取捨選択が必要だと思います。
まだNotionチャレンジは1年生ですので、これからももっとアップデートしつつ、このような形でアウトプットできたらなと思います!!
