Backlogを用いたMMMのプロジェクト運用

2017年から2年間毎日欠かさず飲み続けた明治R1ヨーグルトが今年の花粉症を若干？和らげているかもしれない...と感じている MMM代表 国本です。

MMMでは2018年末に社内チームで話し合った結果、2019年よりプロジェクト管理をJIRAからBacklogへ全面的に移行しました。

本格的に使い始めてからまだ3ヶ月と日は浅い状況ですが、今回は主にクライアントワーク(受託)プロジェクトを対象とした我々のBacklog運用について簡単にご紹介したいと思います。

MMMでのクライアントワークにおけるプロジェクト運用の流れ

取り扱うプロジェクト種別や契約形態(一括請負や準委任)によって、差異はあるものの、プロジェクト運用の全体はこのような流れとなります。

1．ストーリー精査

関連資料や実現したいビジネス要件、達成したいゴールを原資とし、設計・開発を進めて具現化が必要なビジネス上の機能を『ストーリー』としてプロジェクト関係者全員で精査します。

このストーリー精査において「機能単位で動作が確認でき、受け入れることが可能な意味のあるストーリー」を作り上げていく。例えば

サービス管理者がCMSを利用して、登録済みの利用者に対し、プッシュ通知をリアルタイムに配信できる

というような単位で、ストーリーを精査しています。

このストーリー精査の段階ではBacklogは使用せず、チームメンバー複数人でリアルタイムに共有・書き込みが可能なGoogleスプレッドシートを用いて、ストーリーの書き起こしを行っています。

2．工数見積もり

スプレッドシートにおいて 受け入れテストが可能で、ビジネス的に意味のあるストーリー の精査が一通り終わった段階で、そのストーリーを実現するために、必要と考えられる工数を下記方式で見積もります。

見積もりの進め方

MMMは全メンバーが異なるロケーションで働くリモートワークのため、アジャイルで用いられるカードを使った『見積もりポーカー』は物理的制約から実施できません。

そこで、ストーリーが一覧化されたスプレッドシートに、プロジェクトメンバーがリアルタイムで工数を書き込める枠(列)を人数分準備した上で、Slack Callsで通話しながら、ストーリーに対してオンラインで一斉に見積もりポイントを入力する。という見積もりを行っています。

見積もりポイントのルール

この際に入力する見積もりポイントは「1ポイント = 1営業日」としており

0 1 3 5 10

のいずれかのポイントを入力し、仮に10ポイント以上が必要と考えられるようなストーリーの場合、該当ストーリーの粒度や、技術的・仕様的な側面での不確実性を少しでも減らせるようなストーリー組み立てを再検討し、10ポイント以下になるように分割します。

また、この見積もりを進める前に、必ずプロジェクトメンバー全員で

• 仕様・技術的検討でのミーティングで必要となる工数の考慮
• 自身・他メンバーのコードレビュー工数の考慮
• 他メンバーの技術面・仕様面でのサポート工数の考慮
• 他ストーリーと重複する機能に対する見積もりポイントの前提

について、見積もりポイントにどう含めるべき(含めないべき)か？という点を全メンバーで共通認識を図った上で実施しています。
(プロジェクトの性質により最適解が異なるため、そのプロジェクトチームの裁量で決める)

なお、見積もりポイントは各々のスキルセット、これまでの経験値・見方により、大きな『ブレ』が発生することは多々ありますが、都度「なぜそのポイントを見積もったのか？」という点をプロジェクトメンバー間でディスカッションしながら、皆で納得できるポイントを決定するよう務めています。

3．Backlogでのマイルストーン定義

Backlogでは『プロジェクト設定』 → 『発生バージョン/マイルストーン』という機能を利用することで、リリース計画を定義することが可能です。

MMMではこの『発生バージョン/マイルストーン』をプロジェクトの契約形態により定義しています。

Backlogに定義したこれらマイルストーンに対し、後述の手順で課題を紐づけていくことで、リリース計画を可視化していきます。

4．Backlogでの課題起票

スプレッドシート上のストーリー定義、それらストーリーに対応する見積もり、そしてBacklogでの発生バージョン/マイルストーンの準備が整い次第、Backlogに『課題』を起票します。

Backlog課題の種別

Backlogでは最小の管理単位が『課題』(いわゆるチケット)となっており、課題に対して『種別』を紐付けることが可能な為、MMMでは下記5つの種別を共通定義で用いています。

『機能ストーリー』 について

機能ストーリー向け課題テンプレート

ストーリーは書籍『アジャイルな見積りと計画づくり』を参考に

<ユーザーの種類>として、<機能や性能>がほしい。それは<ビジネス価値>のためだ

とした一律のフォーマットに準じて登録を行うようにするため、Backlogの種別ごとにセットできる『課題テンプレート』を使っています。

## このストーリーで実現すること

企業管理者が管理画面から、登録済みの企業ユーザをチェックボックスで選択し、選択されたユーザに対して、Push通知をリアルタイムに配信できるようにしたい。

それは、企業管理者が任意のタイミングでプッシュ通知を使った集客やマーケティングを行えるというビジネス価値を実現するためだ。

## 受け入れテストのシナリオ
お客様がこのシナリオ・前提条件をみて、実際にテストを行えるようにする

この課題テンプレートでは

• このストーリーでは何が実現でき、その結果どのようなビジネス上の価値が生まれるか
• お客様はどのようなシナリオで受け入れテストを行えば良いのかわかる

という2点を意識しています。

ストーリは既にスプレッドシートで起こされているため、Backlogでの 機能ストーリー 起票時にそのまま流用可能ですが、受け入れテストのシナリオは起票時には全てを網羅・記入することは困難な場合もあるため、お客様の受け入れテストが開始される前段階までに更新し書き上げるケースが多いです。

『子タスク』について

機能ストーリーはビジネス的に意味のあるストーリー、かつ受け入れテストが可能な単位となっているため、実際の開発を進める際のタスク定義(例：XXX向けWeb-APIの設計/XXXのテストコード実装など)については Backlogの『親子課題』機能を使い、登録済みの機能ストーリーの子課題として『子タスク』として登録する運用としています。

よって、一つの機能ストーリーに対して、複数の子タスクが紐付いており、この子タスクの粒度はざっくり『Pull Requestを意識する』というのを一つの目安としています。

『子タスク』の課題テンプレート

種別『子タスク』向けも課題テンプレートを定義していますが。

## そのタスクが終わると何が実現されるのか？

このように非常にシンプルにそのタスクを完了させることで何がもたらされるのか？という点のみを記載するようにして運用しています。

『バグ』について

名称通り、発見された不具合、合意仕様と異なる挙動についての課題は『バグ』を種別にセットしてBacklog上で登録・管理しています。

『バグ』の課題テンプレート

バグに関しては、迅速な状況精査・対応を目的に

## 本来期待された挙動
仕様合意している正しい振る舞いを記入する

## 現状の挙動
現時点での動作状況を記入する

## 原因・調査内容
不具合・瑕疵が発生している根本的な原因、調査の内容を記入するか、該当のGitHubプルリクエストへのURLを貼り付ける

これら情報を必ず課題テンプレートを用いて入力する運用としています。

5．Backlog上でのプロジェクト進行計画の立案

Backlogに機能ストーリーが課題として登録された段階で、プロジェクト進行の計画を立案していきます。

定義されている『発生バージョン/マイルストーン』に、登録した全ての機能ストーリーを見積もった工数ポイントや、技術的難易度・不確実性を加味しながら、現実的なリリース計画に振り分けていきます。

また、このタイミングで、プロジェクトメンバー全員でリリース計画の実現可能性を検証するためにも、できる限り機能ストーリーに紐づく子タスクまで含めて可視化し、プロジェクト計画の可視化に努めています。

6．Backlogプロジェクト進行

プロジェクト計画が立案できた後は、登録された課題の『状態』を用いてプロジェクト進行の見える化を進めます。

Backlog課題の状態

MMMのプロジェクト運用では

• 未対応　→　全く手付かずの課題(登録直後)
• 処理中　→　現在着手・実行中である課題
• 処理済み　→ 実装やテストが完了済みであり、受け入れ中である課題
• 完了　→　お客様含めた受け入れが全て完了している状況

このような前提でそれぞれの課題を運用しています。

また、課題の『担当者』を必ず定義することでだれが、どのステータスで、課題を保有しているのかというのを把握できるようにしています。

現時点で検討が必要な事項...

2019年からBacklogベースのプロジェクト運用に切り替えた後、現時点で検討が必要と考えている課題についてです。

課題単位の即時性・視認性の高い可視化方式について

Backlogはバーンダウンチャートの機能はあるものの『期限日』と『予定時間』のセットが前提となっており、現状全ての課題に対してこれらの項目を必ず入力するような運用ルールを整備できていないため、活用できていません。

また、MMMのプロジェクト運用においては、登録した課題の状態を基本にした可視化をよりわかりやすく・よりリアルタイムに行いたいと考えており、Backlogで課題を使った『カンバン方式』の魅せ方ができればと思っているものの、現時点では実現に至っていません。

最後に

簡単にBacklogを切り口としたMMMのプロジェクト管理をご紹介しました。

MMMのプロジェクト管理に少しでも興味を持ってもらえる方いらっしゃいましたら、フロントエンドエンジニア、バックエンドエンジニア、UI/UX，Webプロデューサーなど、全領域で募集中ですので、とてもカジュアルにサクッとオンラインで20分くらいお話しませんか？

ではでは。

kuni