Webディレクター解体アドベントカレンダー16日目の記事です。今日は私がこれまでにプロダクトバックログやスプリントバックログを管理してきたツールたちを紹介します。
プロジェクトが始まって企画の大枠が決まった時、一番最初に行うのはプロジェクトをどう進めるか、その計画から始めると思います。最初はインセプションデッキなどの認識を合わせるためのドキュメントを書くところから始めることが多いでしょう。
そして次に、もしくは同時に、プロジェクトの進め方を考えると思います。ウォーターフォール式に進めるのか、アジャイルに開発していくのか。スクラムを導入するとしたら、スプリントの期間はどれくらいで、デイリースクラムやスプリントレビューをいつやるのか。
そうした検討の中で、何のツールを使うかという問題も出てきます。チャットツールやドキュメントツールはだいたい普段使っているものがあるでしょうから、あまり議論の余地はないでしょう。よく問題になるのは、バックログを何で管理するか、そしてタスクの管理ツールをどうするかです。
Github
おそらくほとんどの開発現場でGithubが使われていると思います。そのままGithubのIssueやProjectを使ってバックログやタスクの管理まで完結してしまうこともあるでしょう。特にProjectを作るとカンバン形式でIssueを扱えるようになるので便利です。
使うツールが増えないので開発メンバーにとっては見る場所が減って良い一方、タスク管理に特化したツールではないので少し複雑なことをしようとすると困ることもあります。例えば工数を見積もってベロシティを計測する時です。Issueには見積もった工数を入力しておく欄がないからです。
あとはGithubは主にエンジニアやデザイナーがソースコードを管理するためのツールで、Issueは彼らの備忘録としても使われます。ちょっとやり残したことをIssueに切り出しておいて後でやろうとか、思いついたちょっとした改善をIssueにしておこうとか、そういうケースでどんどん増えていきます。
Issueをバックログの管理に使おうとすると、そうした改善系の細かいタスクとプロダクトオーナーが切り出したやりたいことが、全部同じ場所に集まるので混乱することもあります。もちろんラベルを使ったりProjectの決まったレーンに乗せるなどしてうまく工夫をすれば良いのですが、そうしたルールを開発チーム全体に浸透させるのにもコストがかかったり、徹底できなかったりすると大変です。
- 良い
- 使うツールが増えずに1本化できる
- いまいち
- 見積もった工数を入力する欄がなく、ベロシティの計測やバーンダウンチャートの作成をしたい時に困る
- みんなが自由に作るissueとPOが管理するバックログが1つのツール内でごちゃまぜになることがある
Googleスプレッドシート
最初はGithubのIssueで管理していたのですが、大きな新サービスの立ち上げプロジェクトをやることになったとき、工数見積もりをしてベロシティを計測し、スプリントごとにバーンダウンチャートを更新して進捗を可視化したくなってきました。そこでバックログをGoogleスプレッドシートで管理することにしました。
マイルストーンごとに、優先度ごとに、それぞれ残りのタスクの工数がどれくらいあって、これまでのスプリントでどれくらいのベロシティが出せていたか。その全てを数値化して確認できるのが便利でした。別シートに集計用の表を作ったり、バーンダウンチャートのグラフを作ったりして欲しい表やグラフを作れるのでとにかく自由度が高い。
ただ関数を駆使して自分で全部作らないといけないからメンテナンスのコストは高いし、作った人の個性が全面に出るので俗人化してしまう。それにただの表計算ソフトだからUIが洗練されてないのも難点です。ドラッグ＆ドロップで移動させたりできないし、なにより触ってて楽しくない。泥臭いツールを我慢して使ってる感じがイマイチでした。
- 良い
- グラフを作ったり、カテゴリごとに残り工数を計算したり、エンジニアに頼まなくても自由に可視化できる
- だいたいみんなGoogleのアカウントは持っているので、様々なステークホルダーに共有しやすい
- いまいち
- 最初にシートを作って値を参照する表を作ってグラフを作ってと、全部自分で作らないといけない
- 自由度が高すぎて作った人の個性が強く出るため管理する人が変わると形式も変わり、開発チームに使い方の学びが蓄積されない
Trello
サービスをリリースした後、工数見積もりやベロシティの計測が不要になったこともあって、Trelloを使うようになりました。Trelloは何より視覚的で操作もわかりやすい。まさにカンバンに特化したツールです。タスクはカード状になっていて、レーンを移動させたりラベルをつけたりするのが直感的で触っていて楽しいのが良かった。
でも、良くも悪くも非常にシンプルなカンバンなので、プロジェクトごとに進捗を管理したり、タスクの依存関係を確認したり、工数やベロシティを管理するのには向いていませんでした。そういうものが不要なシンプルな少人数のプロジェクトならいいのですが、複数のプロジェクトを同時進行させる規模の大きめのチームだと、だんだん物足りなくなってきました。
- 良い
- ドラッグ＆ドロップでレーンの移動ができるので、開発中とかレビュー中とかタスクの進捗を細かく管理したい時に移動させやすい
- いまいち
- 見積もりを入れるフィールドがなかったり、依存関係を表現できないので複雑なプロジェクトに不向き
- 1プロジェクト1ボードという概念でボードを横断してタスクを登録できないので、1つのチームが同時並行で複数のプロジェクトを進行しようとすると面倒
Asana
そうしてたどり着いたのがAsanaです。最近はもうAsanaの思想にどっぷり浸かって、彼らの提唱する使い方をそのままなぞっています。こういうツールはだいたい設計思想があって、その思想通りに使うことが求められます。特にAsanaはこう使ってくれという思想がはっきりしていて、ヘルプでユースケース毎の利用方法を詳しく説明していて「Asanaでのスプリントプランニング」というそのものズバリのページがあり、言われるがままにその通りやってみました。
- 開発に1スプリント（2週間）以上かかるものはプロジェクトを作成する
- どのプロジェクトにも属さないタスクはバックログ用のプロジェクトを用意しておいて、そこに置く
- スプリントごとにスプリントバックログ用のプロジェクトを作って、次のスプリントでやることも可視化する
- スプリントバックログ用のプロジェクトは、スプリントが終わったらレビューしてアーカイブしてしまう
- スプリントレビューの度に、各プロジェクトの進捗を記入する
- ステータスが「順調」「リスクあり」「要対応」「保留中」から選べるので、必ずスプリント毎にステータスを更新する
- あとは自由記述で進捗を記入できるので、スプリントでやったことや次のスプリントでやることを書いておく
- 事前に書いておいた上記のレビューを、スプリントレビューの場で確認する
- ポートフォリオで複数のプロジェクトを俯瞰して確認できるようにする
- 複数のプロジェクトを同時進行するため、チームの全体感を把握するためのポートフォリオを作り、属するプロジェクトを紐づけておく
- スプリントレビューの度に更新する進捗のステータスが一覧できるので、黄色信号や赤信号の灯っているプロジェクトが一目でわかって把握しやすい
- 各プロジェクトのマイルストーンも横断して時系列に見られるビューがあるので、デイリースクラムなどで確認する
特にポートフォリオと進捗の組み合わせが便利でした。プロジェクト毎に進捗を記入できるのですが、ステータスを「順調」「リスクあり」「要対応」から選べ、それぞれが青信号、黄信号、赤信号を表していて、まさに進行管理を行うのに明確でわかりやすい。スプリントレビューの時に要対応になっているプロジェクトがあったら、何かしらの手札を切らないといけないという具合で、スクラムとの相性がとても良いのです。
あとはやっぱり依存関係を可視化して、マイルストーンと一緒にタイムラインで見られるところがいいですね。大規模な仕組みを作る時はタスクに依存関係が生じ、単にベロシティの管理だけしていたら優先すべきタスクを後回しにしてしまうこともあります。依存関係を付けて日々進捗に応じてアップデートしていくのは少し大変ですが、ちゃんと可視化されていることで得られるメリットも大きいと思います。
- 良い
- スクラムでの利用を想定した作りになっていて、進捗のステータスが把握しやすい
- 依存関係が表現できたり、タスクだけでなくマイルストーンが建てられたり、サブタスクを作れたりしてタスクの性質を可視化できる
- APIが用意されていて拡張性も高い
- いまいち
- 複数プロジェクトをまたいで管理できるポートフォリオなど、ガッツリ使い込もうとすると有料になって値段も高め
- できることが多くて複雑なので学習コストがかかり、シンプルなプロジェクトには不向き
コストが高いのが難点ですが、今のところは気に入って使っています。ただツールはあくまでもツール。手段が目的化しないようにだけは、いつも心のどこかで気をつけておきたいです。
