この記事はbellFace Advent Calendar 2021の 18日目の記事です。
少し自己紹介
僕はもともとwebエンジニアとしてWeb広告関連のシステム開発や業務アプリケーションの開発を行っていました。
主にバックエンドエンジニアとして設計・実装を担当しつつ、上流の要件定義やオフショア含めた開発のプロジェクトマネジメントなど、開発業務全般に携わってきました。
そんな中、テクニカル領域だけでなくよりプロダクト全域の意思決定に貢献していきたいという思いからプロダクトマネージャーを志し、現在はベルフェイスでプロダクトマネージャーをしています。
少し前の記事ではありますが、こちらにキャリアの話や今どんなことをしているか書かれていますのでもし興味を持っていただけたら見ていただけますと嬉しいです！
そもそもベルフェイスはどんな組織・開発体制？
ベルフェイスではプロダクト開発に関わる組織としてプロダクトグループとシステムグループに分かれています。
大雑把に言ってしまえば、プロダクトグループがなにをなぜ作るのかを決め、システムグループがどう作るかを決める役割分担で動いています。
ただ、実際のプロダクト開発チームはこれらのグループからプロダクトオーナー、デザイナー、エンジニア、QAがアサインされ、各職種が一丸となり機能開発を進めています。
開発プロセスは全社的にかっちりとは決めておらず各チーム・プロジェクトの裁量で進められますが、PRD作成とレビュー、DesignDoc(システム設計書)作成とレビュー、リリース判定会など、大枠のチェックポイントが設けられ各チームが一定水準のプロダクト開発を行えるよう担保する仕組みとなっています。
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で表示しています。
この、
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で表示しています。
Labelsに機能名などを入力しgroup byすることで、機能ごとにまとめてEpicを表示させ視認性を高めています。
Timeline Viewにすることで大枠のスケジュール感をNotion上で確認できるようになりました。
また、Epicには進捗を可視化する機能や完了予測日を算出する機能を持たせています。こちらは運用方法でご説明します。
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を算出しています。
これらの機能により、 開発の進捗状況やどのあたりにタスクが完了しそうかをひと目で把握できるようになっています。
b. EpicとIssueは紐付けず、Epicに進捗を手入力する
見積もり工数はかけずにライトな運用をするパターンです。
Weatherの算出元となっている Progress Summaryは、 Issue Progress(Manual)に入力があるとそちらの値を優先して利用するよう作っています。
Epicのタスクを細分化し子Issueを作り見積もりをする作業は、それだけでなかなかチームの工数を消費することになります。また、そもそも細分化すること自体が難しいケースもあるでしょう。
そういったケースにおいては無理に子Issueの見積もりを行わずに、Issue Progress(Manual)に進捗を手入力できるようにしています。
