はじめに

こんにちは!ベルフェイスでプロダクトマネージャーをしている野元です!
本日はアドベントカレンダーということで、社内で実践中のNotionを活用した開発Issue管理について書こうと思います!

少し自己紹介

僕はもともとwebエンジニアとしてWeb広告関連のシステム開発や業務アプリケーションの開発を行っていました。
主にバックエンドエンジニアとして設計・実装を担当しつつ、上流の要件定義やオフショア含めた開発のプロジェクトマネジメントなど、開発業務全般に携わってきました。
 
そんな中、テクニカル領域だけでなくよりプロダクト全域の意思決定に貢献していきたいという思いからプロダクトマネージャーを志し、現在はベルフェイスでプロダクトマネージャーをしています。
少し前の記事ではありますが、こちらにキャリアの話や今どんなことをしているか書かれていますのでもし興味を持っていただけたら見ていただけますと嬉しいです!
 

そもそもベルフェイスはどんな組織・開発体制?

ベルフェイスではプロダクト開発に関わる組織としてプロダクトグループとシステムグループに分かれています。
大雑把に言ってしまえば、プロダクトグループがなにをなぜ作るのかを決め、システムグループがどう作るかを決める役割分担で動いています。
notion image
 
ただ、実際のプロダクト開発チームはこれらのグループからプロダクトオーナー、デザイナー、エンジニア、QAがアサインされ、各職種が一丸となり機能開発を進めています。
notion image
 
開発プロセスは全社的にかっちりとは決めておらず各チーム・プロジェクトの裁量で進められますが、PRD作成とレビュー、DesignDoc(システム設計書)作成とレビュー、リリース判定会など、大枠のチェックポイントが設けられ各チームが一定水準のプロダクト開発を行えるよう担保する仕組みとなっています。

Notionによるissue管理を始めたきっかけ

もともとベルフェイスではzenhubを用いた開発issue管理を行っています。(そして、今もそれは継続しています)
この管理方法自体に大きく問題があったわけではありません。しかし別文脈でNotionの全社導入がなされ、これまで各種ツールで管理されていたものをNotionへ統合していく動きの中で、「ちょっとNotionでの開発issue管理をやってみようか」と試したのがきっかけです。

具体的な活用方法

まずは 完成形を見ていただければと思います。
(本当はNotionのdatabaseをそのまま貼りたかったのですが、記事上でうまく表示されなかったので画像でご容赦ください)
 
notion image
 
notion image

全体概要

Epic, Issueという2種類のdatabaseを用いてIssue管理を行っています。
Epicは3~6ヶ月程度の中期的な機能開発のロードマップを管理する目的、
Issueは1~2週間程度の短期的なタスクを管理する目的で利用しています。
EpicとIssueは親子関係となっており、Epicに複数のIssueを紐付けることが可能です。
notion image

Issue

まず先にIssueをご紹介します。
Issueは主に次のようなプロパティで構成されます。(一部抜粋)
プロパティ名
意味
Name
Issue名
Type
Issueタイプの定義。PO, Design, Dev, QA, Etcいずれかを選択。Board ViewにしたときSub groupとしてgroup byする
Status
Issueのステータス。Board Viewにしたときgroup byする
Assignees
担当者
Estimation
相対見積もり用の数値を入れる
DoneEstimation
完了(Status=Done or Closed)したIssueのEstimationが入る。Epic側での計算用プロパティ
これを、StatusとTypeでgroup化してBoard Viewで表示しています。
 
notion image
この、 StatusとTypeで縦横でマトリクスを作る ビューが個人的にはお気に入りです。
開発業務はたいていの組織において分業体制が敷かれているかと思いますが、多くのタスク管理ツールはステータスごとのレーンを作ることができても、別軸を加えたマトリクスで表現することはできません。
そうなると、ある開発Issueの一生を管理するにはステータスをたくさん用意したものすごい横長のボードを作るか、開発フェーズ(要件定義 / 設計 / 実装 / 検証など) ごとにボードを用意し、ボード間で情報のやりとりをする必要があります。
 
Notionのようにマトリクス型のボードで管理できると、チーム内のどのIssueが各開発フェーズにおいてどういう状態かを一覧で確認することができます。
また、各フェーズ間のIssueの受け渡しも簡単で、例えばPOが要件定義を完了したIssueはドラッグしてそのままDesignへ引き渡すことができます。

Epic

Epicは次のようなプロパティで構成されます。(一部抜粋)
プロパティ名
意味
関数
Name
Epic名
Labels
任意のラベルを入力可能
Date Range
期間
End Date
Date Rangeの終了日を関数で取得
End(prop("Date Range"))
Remaining Days
End Dateまでの残日数
if(start(prop("Date Range")) <= now(), dateBetween(prop("End Date"), now(), "days"), 0)
Days Digestion Rate
日数消化率。
format(if(start(prop("Date Range")) > now(), 0, round((dateBetween(prop("End Date"), prop("Date Range"), "days") - prop("Remaining Days")) / dateBetween(prop("End Date"), prop("Date Range"), "days") * 100))) + "%"
Estimation Summation
子IssueのEstimationの合計値
Issue Estimation Average
子IssueのEstimationの平均値
Done Estimation
完了した子IssueのEstimationの合計値
Empty Estimation
Estimationが未入力の子Issueの数
All Estimation
Estimation Summationと、Estimationが未入力のIssueに見積もり平均値を割り当てたときの子IssueのEstimationの合計
prop("Estimation Summation") + prop("Issue Estimation Avarage") * prop("Empty Estimation")
Issue Digestion Rate
Issue消化率
format(round(prop("Done Estimation(admin)") / prop("All Estimation") * 100)) + "%"
Progress Summary
Issue消化率 / 日数消化率
if(prop("Days Digestion Rate") == "0%", 1000, ceil(if(prop("Issue Digestion Rate") == "0%" or empty(prop("Issue Progress(Manual)")) == false, prop("Issue Progress(Manual)") * 100, toNumber(prop("Issue Digestion Rate"))) / toNumber(prop("Days Digestion Rate")) * 100))
Weather
進捗を天気で表現。晴れなら順調。曇りならちょっとやばい。雨ならだいぶ遅れてる
if(prop("Progress Summary") >= 1000, "-", if(toNumber(prop("Issue Digestion Rate")) == 100 or toNumber(prop("Issue Progress(Manual)")) == 1, "🌞", if(toNumber(prop("Days Digestion Rate")) >= 100, "🌧", if(toNumber(prop("Progress Summary")) >= 100, "🌞", if(toNumber(prop("Progress Summary")) > 50, "⛅️", "🌧")))))
Predicated End Date
完了予測日
dateAdd(prop("Start Date"), 100 / (if(prop("Issue Digestion Rate") == "0%" or empty(prop("Issue Progress(Manual)")) == false, prop("Issue Progress(Manual)") * 100, toNumber(prop("Issue Digestion Rate"))) / dateBetween(now(), prop("Start Date"), "days")), "days")
これを、Timeline Viewで表示しています。
notion image
Labelsに機能名などを入力しgroup byすることで、機能ごとにまとめてEpicを表示させ視認性を高めています。
 
Timeline Viewにすることで大枠のスケジュール感をNotion上で確認できるようになりました。
 
また、Epicには進捗を可視化する機能や完了予測日を算出する機能を持たせています。こちらは運用方法でご説明します。
 

運用方法

運用方法は大きく以下の3つ用意しています。
  1. Epicに子Issueを紐付け、子Issueに見積もりをつけていく
  1. EpicとIssueは紐付けず、Epicに進捗を手入力する
  1. aとbの混合パターン
 

a. Epicに子Issueを紐付け、子Issueに見積もりをつけていく

愚直に見積もりをしていくパターンです。
まず、そのEpicにひもづくIssueをすべて洗い出し、すべてのIssueのEstimationに相対見積もりを入れます。
この状態で開発を進め、Issueを完了(DoneやClosedへステータス変更)させていきます。
するとEpicのIssue Digestion RateとDays Digestion Rateが算出されます。
これらIssue Digestion RateとDays Digestion Rateの比から、予定している日数に対しIssueが適切に消化されているかを判定し Weatherとして進捗天気を表示しています。
また、Issue Digestion Rate・Epicの開始日・今日の日付からEpicに対するベロシティを算出し、そのEpicがいつころ終わりそうかを示すPredicated End Dateを算出しています。
notion image
 
これらの機能により、 開発の進捗状況やどのあたりにタスクが完了しそうかをひと目で把握できるようになっています。
 

b. EpicとIssueは紐付けず、Epicに進捗を手入力する

見積もり工数はかけずにライトな運用をするパターンです。
Weatherの算出元となっている Progress Summaryは、 Issue Progress(Manual)に入力があるとそちらの値を優先して利用するよう作っています。
Epicのタスクを細分化し子Issueを作り見積もりをする作業は、それだけでなかなかチームの工数を消費することになります。また、そもそも細分化すること自体が難しいケースもあるでしょう。
そういったケースにおいては無理に子Issueの見積もりを行わずに、Issue Progress(Manual)に進捗を手入力できるようにしています。
 
notion image
 

c. aとbの混合パターン

Epicごとにaパターンの運用、bパターンの運用を切り替えるパターンです。
aとbのいいとこどりができるため、僕はこのパターンで運用していました。
線表の長さが2週間以上となりそうならばa、そうでないならbなど使い分けるとよいかと思います。
 

やってみての所感

良かった点

NotionでもIssue管理は問題なし。代替できるツールはNotionにまとめるのが吉

柔軟なビューの切り替え、database間のリレーション、Functionを利用したちょっとした機能の作り込みなど、タスク管理ツールとしてのNotionのポテンシャルを感じました。ゼロからタスク管理ツールやドキュメンと管理ツールを入れるなら、間違いなくNotionを選択します。
データベースに対してシンプルに情報を出し入れする類の業務ツールはほぼNotionに代替されてしまうのではないかと感じました。
 

もうちょいな点

かゆいところには手は届かないので、割り切りは必要

今回の例で言えばEpicとIssueはリレーションを持っていますが、Epicの中で子Issueを作成するといったことはできません。Issueを作成してからEpicと紐付ける必要があるのでひと手間かかります。こうした細かい点で使いづらい部分はどうしても出てきてしまいます。
確かに不便ですが、この不便を解消するのに別ツールをお金払ってまでいれるかと言われると、個人的にはNoかなーと感じています。
 

他ツールとの共存させながらのIssue管理

これはNotionが直接悪いわけではないのですが、zenhubからまだ完全に脱却できているわけではなく、Notionとzenhubを併用しながら開発を進めています。
このためNotionとzenhubをいったり来たりしなければならなかったり、タスクを二重管理しなければならかったりするシーンもあり、作業負荷がかかってしまっています。
この点に関しては別課題として取り組んでいかなければならないポイントです。

今後の展望

他業務領域への展開

プロダクトマネジメントの文脈で言えば、要望の管理や社内・社外へのプロダクト情報の展開など、Notionでカバーできる部分はもっとありそうです。
ムリ・ムダ・ムラをなくしてナウでヤングなイケてるプロダクトマネジメント管理体制を敷いていきたいですね! 😊

Next

さて、19日目は社内で下期MVPを受賞したプリセールスの田中さんことTさんです!
話す内容はわかりませんが、MVPなのですっごい為になる記事を書いてくれると思います!
乞うご期待!!
badge