スタディサプリ Product Team Blog

株式会社リクルートが開発するスタディサプリのプロダクトチームのブログです

差し込みの多いプロダクト開発のスケジュールの精度を上げるためにはバーンアップチャートがおすすめです

Product Management

こんにちは。

今回は差し込みの多いプロダクト開発におけるスケジュール精度の上げ方として、バーンアップチャートの利用をおすすめしたいと思います。

どんな人に読んでほしいか

  • Product GrowthやEnhancementに携わっているけど、やることが多くて思ったように進捗が管理できない人
  • ↑のようなProduct Manager(PdM)やProject Manager(PjM)とのコミュニケーションが多いけど、期待に対してうまく動いてくれないことをもどかしく思ってる方

TL;DR

  • 3ヶ月や6ヶ月程度でタイムボックスを切りましょう
  • タイムボックスの中でやりたいことを全部リストアップして見積もりをしましょう
  • 終わったタスクのcloseと新規タスクのリストアップを繰り返すと、自然と「やりたいことが全部できるのかどうか」が見える化します

バーンアップチャートとは

下記のようなものです。

図中の紫・薄紫・白色の領域は下記のようなポイント構成になってます。

  • 紫
    • closed issuesのポイント
  • 薄紫
    • open issuesの内、見積もり済みのissueのポイント
  • 白
    • open issuesの内、まだ見積もれていないissueのポイント(closed issuesの平均値が割り振られる)

どうしてやってるの？

下記のようなことが発生することにより、システム開発の、特にEnhance領域における進捗の管理は極めて難しいからです。

  • 多種多様なステークホルダーによる差し込みの案件追加
  • なかなか定まらない要件
  • 当初想定よりも複雑な既存実装

多種多様なステークホルダーによる差し込みの案件追加

筆者の見ているチームはシステム横断の案件を見てるため、単純に企画者から差し込みで案件が飛び込んでくるということも発生します。

理由は下記のように千差万別です。

  • 急遽大きなプロモーションが決まったためそれまでに~の機能を磨き込みたい
  • 課金率に影響する因子を特定したのでユーザーの獲得時期までに対応をしたい
  • セキュリティインシデントが起きたのでhotfixを入れたい
  • システム開発不要な運用案件を企画していたが、リリース1ヶ月を前にして1箇所だけシステム開発が必要になった

これらに対して全てをやるわけではないですが、状況は刻一刻と変わっていくのが常です。

なかなか定まらない要件

システム開発においては開発着手前の要件定義の時点で極力仕様を詰めたりエッジケースも考慮しますが、ここですべてのケースにおいて詰め切るということはかなり難易度が高いです。

実際には不可能と言ってもいいかと思っています。

加えてそこまでの考慮をするには相当な時間をかけなければいけないですね。

エンジニアをやったことがある企画者の場合にはある程度実装のことも考えての企画ができるケースもありますが、そうではない場合には実装調査が始まってから難しいことがわかり、要件が変わるということもよく起きます。

当初想定よりも複雑な既存実装

特にEnhancementの領域ではコードはすでに存在していて、既存のプロダクトが動いているため、実際にコードを読んだり、テスト実装をしてみるなどの調査も必要になります。

そうしたことをやった結果、当初の想定よりも実装が複雑で、上述のように要件を変えざるを得なかったり、そもそも調査自体や実装自体に工数がかかるということが起きます。

これらは例に過ぎませんが、こういった事例から精度の高い進捗及びタスクの管理が必要となってきます。

どうやってやってるの？

Quipperではissueの管理方法としてGitHub Issuesを利用しています。

その上でZenHubと連携することでバーンアップチャート(正式名称 : ReleaseReport)を作成しています。

詳しくは公式を読んでいただければ分かるかと思いますが、ここではサマリーだけ記載いたします。*1

  1. Releaseタグを作成し、バーンアップチャートで観測したい期間を定めます。
    • おすすめは3ヶ月や6ヶ月などの中期程度の期間です。
    • これ以上短いと運用コストが上がるし、長いと締め切り効果が減ります。
  2. 期間中に対応をしたいGitHub issueにReleaseタグを貼ります。
  3. 対象のissueの見積もりを行い、issueのEstimateにポイントを割り振ります。
  4. 実際に開発を行い対応が完了したらissueをCloseします。
  5. ZenHubのReleaseReportページで当該タグを開けばバーンアップチャートが観測できます。

やってみてどうなったの？

関係者へのコミュニケーションが下記のように変化しました。

  • 導入前
    • 残りのissue量と進捗的には多分1ヶ月遅れぐらいでまだ間に合いそう
  • 導入後
    1. 増えているissueがこれぐらいあって
    2. まだ見積もれてないissueがこれぐらいで
    3. 今後このissueに関しては詳細なissueが増える可能性があって
    4. 現時点で1ヶ月ぐらいバッファがあるから多分間に合う

現状の見える化ができることと、それを見せながら説明をすることで、開発メンバー内の不安を取り除いて、このまま進めてても間に合う可能性が高いということを全体認識として持つことができます。

また、企画者に関しても「私の企画は年度内にリリースされる可能性が高い」というのを確度高く把握することができたりします。

さらに、差し込み案件が入ってくる場合にも、「現時点でギリギリなので入れるとしたらなにかを削らなければならない」ということに気づくことができるので、やらない案件を決めたり、差し込み自体をやらないという調整が簡単にできるようになりました。

なんでそうなるの？

下記を見れば一目瞭然ですね。

特にZenHubでは2のまだ見積もれてないissueに関しても、前述の通りこれまでにcloseしたissueの平均値でポイント割り振ってくれるので、ざっくりとしたサイズは積み上げてくれます。

なんでバーンダウンチャートじゃなくてバーンアップチャートなの？

表題に記載している、「差し込みが多い」というのを見える化するためです。

バーンアップチャートではタスクが増えたときに単純に縦軸が伸びていくため、「増えている」という事実を把握するのがバーンダウンチャートよりも簡単にできます。

プロジェクトの不確実性には、「タスクの増加」と「見積もりができていないタスク」というようなことがありますが、それら両方とも見える化できるというのが強みと思っています。

実際には差し込みだけでなく、タスク分解した結果issueが増加した、ということもあるのですが、これもタスクの増加という点では変わりないのですね。

これで完璧！

というわけにはなかなかいかず、例えば3の今後増えるissueについては見える化できません。

しかし、要件定義が終わっていないissueなども予め分かる範囲で良いので細分化したissueを作っておくことで、この部分のリスクも減らすことは可能です。

また、2のまだ見積もれてないissueに関してももう少し精度を上げることはできそうです。

こちらについては次回にお話したいと思います。

いずれにせよ、重要なのは不確実な要素を極力減らして、不確実な要素自体を見える化することと、それに対してアプローチしていくことだと筆者は思っています。

本記事はTPM(Technical Product Manager)の @shunsuke-nishimura が執筆しました。

本日より隔週で何回か連載をしようと思っておりますので、ご興味ありましたら次回作もお読みください。

*1:もちろんZenHubを利用せずに独自で運用しても問題ありません。