10周年の音楽プロダクトで、PJ管理/タスク管理をJIRAからNotionへ完全移行した話【Template公開中】

この記事はWano Group Advent Calendar2022 5日目の記事です。
https://qiita.com/advent-calendar/2022/wano-group

はじめに

音楽ディストリビューションサービス TuneCore Japan で Engineering Manager をしている 吉田 翔吾郎（@shogoroy）です。TuneCore Japan は今年で10周年を迎えるプロダクトとなっており、アーティストの活動を網羅的に支援する All in One のサービスになろうと様々な開発に日々取り組んでいます。

そんな中、開発におけるプロジェクト管理 & タスク管理の効率を上げるために、長年使ってきたJIRAでの管理をやめてNotionへの全面移行をしています。

この記事ではNotionでのPJ管理をなぜ・どのようにやっているかを書いていきます。

---

実際にTuneCore Japanで運用している方法を個人のNotionで再現したものをTemplateとして公開していますので、以下を見ながらご覧ください。
https://www.notion.so/shogoroy/Template-603af27bc0df4728a368126a62391884

---

なぜ移行したのか？

私がJIRAを使いこなせていない部分も多いとは思いますが、
JIRAでPJ管理・タスク管理をする上で、以下の使いづらさを日々感じていました。

• プロジェクトをまたいだすべてのチケットを網羅的に見ることができない
• ドキュメント管理ツール=Notionとの仕様の重複管理が発生する
• 複数人でのチケットの同時編集のしづらさ
• Notionでまとめた要求仕様をJIRAにまとめ直すコスト

組織としてNotionの習熟度が上がるほど、PJ管理・タスク管理にはJIRAを利用しているデメリットが大きくなっており、2022の後期から徐々にNotionへの移行を開始しました。

全体構成のBefore / After

Before: JIRAでのチケット管理

基本的にはJIRAプロジェクトは一つのみを使い、その下にEpic / Story / Milestone の順にIssueTypeが細かくなる設計でした。
StoryチケットとMilestoneチケットとは親子関係になっており、JIRAのIssue Typeで分けていました。

上記と、開発プロジェクトごとに工数を集計し予実管理するためのWorklogとの関係を図示すると以下のようになります。

After: NotionでのPJ/Task管理

Notionでの管理では、Project / Story / Task の３つのDatabaseに分割し、それぞれがRelationを張り合うように設計。
JIRAと異なりSprintの概念を自分で用意する必要があるため、Sprintも一つのDatabaseとしました。

Notion で組んだ実物（Template公開中）

実際に以下のNotionでTemplateとして公開していますので、興味ある方はご覧ください。
https://www.notion.so/shogoroy/Template-603af27bc0df4728a368126a62391884

全体像での工夫点

ページ構成の工夫

統一されたフォーマットで各個人レベルのビューを用意し、各個人ビュー間を移動しやすいように上部にSyncedBlockでリンクを置いています。
実際のMTGで進捗を管理する場合には、これらの個人レベルのビューを行き来したりチーム専用のビューを開いたりしながらMTGを進行しています。

単にJIRAを再現するためのActive Boardだけでなく、以下のビューを用意しました。

• Timeline by Assign: 個人TaskがTimeline上に表示されるようにしています。ざっくりのSprint調整を行うだけでなく、各Taskの着手順序なども細かくすり合わせられるようにしています。
• Worklog Calendar: 日々の作業内容を実績の工数として記録するためのビューです。記録した工数は、ProjectやTaskの予実管理に利用されます（詳細は後述）
• Product 開発スケジュール: 個人ごとに関係するProjectを一望するためのビューです。

全体ビュー

個人ビュー

Propertyの工夫

NotionのDatabaseをリッチにすればするほど、「Propertyが増えすぎて何を入力すればいいかわからない」 という課題が生まれがちです。
これを回避するために、以下のPrefixを導入しています

• * : 必須入力項目であることを示す
• [auto] : rollup や formulaなど、自動で入力される項目であることを表す
• [label]: Viewに表示したい文字列連結などの結果であることを示す
• [再rollup用]: （複数のDBをrollupし合っていると、rollup候補に値が出てこなくなったりそもそも何のためのPropertyかわからなくなったりする課題があるため）このPrefixでは、DB内では使わないものの、外部DBでのViewのリッチ化などに使われることを示す（漢字混じりでダサPrefixなのでシンプルなラベルに変えたいが、暫定として。）

各DB詳細

Project

工夫点としては、Relationで紐付いた各Taskのそれぞれの見積工数と実績工数をRollupで計算し、Viewに表示したい専用の値を formula で文字列として出力して可視化を強化したりしています。

Task & Worklog

タスク管理で大事なのが、予実管理です。
ひとりひとりのエンジニア（デザイナー、PdM、etc...）が自身のタスクを予定通り進める意識を高めるための仕組みとして、見える化をかなり意識しました。

各Taskに対しWorklogを日毎につけ、それぞれの作業時間をSumすることでTask単位の総実績工数を計算しています。
各Taskには見積工数を入力し、総実工数と組み合わせて各Taskでの予実管理が見える化できるようにしています。
（こちらも、Projectと同様に見える化専用のPropertyを formula で計算しています）

また、JIRAなどのタスク管理専用のツールのように自動付番のタスクIDを実現するために、formula内の id()を使いつつ、事前にProject Database に PID という文字列を入力しておき、TASKに一意なIDが振られるようにしています。

Sprint

Notionでの運用で課題となるのが、「Sprint」自体のデータをどう管理するか、ということです。
JIRAでは、Sprintの開始と終了を明示的にボタンを押して切り替えますが、Notionの場合にはそのような機能はありません。

一番シンプルな実現方法としては、ActiveSprintか否かを表すフラグ（Checkbox）を用意して、オペレーションとして毎Sprintの切り替えタイミングでフラグを切り替えることです。
ただ、私としてはその切替作業すら面倒なので、自動化しました。

まず、Formulaで現在の日付とSprintの開始日付とを比較し、同じ日か対象期間内であれば current、過去/未来であれば past/futureが入るようにします。

smaller(prop("*Sprint Name"), formatDate(dateSubtract(now(), 7, "days"), "YYYY-MM-DD"))
  ? "past"
  : (larger(prop("*Sprint Name"), formatDate(dateAdd(now(), 1, "days"), "YYYY-MM-DD"))
      ? "future"
      : "current")

これをさらにformulaで計算してcurrentであればtrueとなるようにすることで、自動でActiveSprintのチェックボックスが更新されるようにしました。

実際に運用してみて

Notion のほうが良いと思った点

• メンバーごと・プロジェクトごと・小チームごとに好きなビューができ、それぞれのダッシュボードができる
• ビューのカスタマイズ性が抜群で、PJやタスクの完了の見える化が抜群（JIRAだと、このページビューにこのPropertyを表示したいのに・・・という痒さが残る）
• 各種チケットを切るときの体験がシームレスでローディングなどを挟まず、瞬時に他者も見れるようになるUXが素晴らしい
• 対応予定日やタスクごとのマイルストーンをTimelineビューで管理しやすい（JIRAのエピックビューもあるが、）
• etc.

詳細にメリットは上げるときりがないのですが、PJ・タスクのメンバー間の見える化と、各メンバーが自ら管理しやすいビューを作って管理することから自身のタスクマネジメントをする意識が高まったことが大きなメリットだと感じています。

NotionでのPJ管理の課題

• Sprintの切り替わりで未完了タスクを次Sprintに引き継げない（ビューの設定でカバーはできる）
• DB内のデータが多すぎると、Relationを貼るときに検索が不便になってくる
• FilterやSortを気をつけないと、ページ自体の読み込みや操作が重い場合がある
• Rollup周りのUXの伸びしろ
  • FilterやSortでRelation先の値を見て制御したい場合にも、Rollupで一度Property化しないといけない
  • 複数DBをまたいで２個先のRollupが直接できない（Formulaで同じ値をProperty化することで回避できるが、無駄なPropertyが増える）
• 各チケット間の依存関係を可視化しづらい（これはもうすぐローンチされるという噂・・・？）
• WorklogをNotion Databaseにすることで、全分検索に無駄なページがヒットする確率があがる（→特定のページやDBを、全文検索から隠せるようになってほしい）

細かいアップデートが多いNotionなので、上記の痒いところもどんどん改善されていきそうです。

あとがき

個人的には、これからはPJ管理・タスク管理のファーストチョイスがNotionになっていくんじゃないかと思っています。

Notionを活用している皆様、Notion開発者様など、この記事を読んでアドバイスや活用事例を共有いただけると幸いです！

ここまで記事を読んでいただいて、ありがとうございました！

---

TuneCore Japan では 一緒に働くメンバーを募集しています。
エンジニアだけでなく、Director等の各種ポジションをオープンしているので興味のある方はぜひご覧ください！
https://www.tunecore.co.jp/jobs