こんにちは、ShareWis CTOの門脇です。
ShareWisでは、サービスの改善・機能追加・バグ修正のためのタスク管理ツールとしてPivotal Trackerを使っています。
今日は、そんなPivotal Trackerの使い方について思うことがあったので、ちょっと書いてみることにしました。
Pivotal Trackerを「仕様書」として使う
Pivotal Trackerでは、タスクを「ストーリー」という単位で登録します。各ストーリーに、
- Title（タイトル）
- Description（詳細）
- Activity（掲示板のようなもの）
といった情報を記入していくことで、そのストーリーの目的や、目的を達成するためにシステムに対して行う必要がある修正の詳細を管理することができます。
ShareWisチームでは、サービスの機能追加や改善、バグなどの詳細を、Pivotal Trackerのストーリーにおける「Description」や「Activity」に記録していました。Googleドキュメントなどの、Pivotal Tracker以外の場所にもサービスの仕様に関するドキュメントは存在していましたが、ベースとなるのはPivotal Trackerのストーリー。サービスの仕様に関する情報のほとんどをPivotal Trackerで管理していたわけです。
つまり、Pivotal Trackerを「仕様書」として使っていたことになります。ですが、実はこれ、非常にまずい状態です。
「仕様書」として使ってはいけない理由
１つ目の理由は、「Pivotal Trackerのストーリーは完了すると流れてしまう」ということです。
Pivotal Trackerのストーリーは優先順位順に一直線に並んでいます。Twitterのタイムラインのイメージです。完了したストーリーは次の週（イテレーション）では基本的に見えなくなってしまいます（探して表示することはできる）。
過去に実装したストーリーは、どんどんチームメンバーから忘れられていきます。最終的に、機能の存在は認識しているけど、詳細な動作は曖昧、といった状態が発生します。そうなると、何がバグで何が仕様かもわからなくなりますし、機能追加や改善の方法を考えようにも、必要な情報が不足してしちゃってますよね。
２つ目の理由は、「ストーリーという単位が仕様を管理する上では細かすぎる」ということです。
色々な使い方があるとは思いますが、Pivotal Trackerのストーリーの粒度を決める基準として、「何かしらのビジネスバリューを生み出す大きさ」にストーリーを分割するという考え方があります。
それはそれで良いのですが、サービスの仕様という観点からストーリーを見た時に、この粒度だと細かすぎて全体の仕様がとても把握しにくいです。「木を見て森を見ず」とでも言うのでしょうか。
さらに、ストーリーはどんどん追加されていくので、全体の仕様を把握しているメンバーがだんだん少なくなります。全体の仕様が把握できていないので、機能追加・改善やバグ対応が場当たり的なものになってしまい、サービスがどんどんカオスなものになっていってしまいます。
じゃあどうすればいいの？
仕様書のマスターをPivotal Trackerの外部で管理しましょう。
サービスに対して何か機能追加・改善・バグ修正を行う場合は、まず仕様書のマスターを修正し、その後ストーリーからその仕様書にリンクを貼るようにしましょう。
作業の量が増えるからといって面倒臭がらずにやりましょう。
「回り道が実は近道だった」「近道が実は回り道だった」ってことが、サービスの開発では本当にたくさん発生する。そんなことを最近頻繁に実感するようになりました。
（門脇）
コメント