バグトラッキングシステムを導入するにあたり、どんなことを考えてどのように導入したらよいか？をまとめた記事を去年の冬コミに寄稿したのを、許諾を頂いたのでこちらにも転載します。既に運用されている方も、これから運用を考える方も、何かのご参考になれば幸いです。本エントリはバグ票ワーストプラクティスプロジェクトの提供でお送りします。それでは本編どうぞー。
こんにちは！しんすけさんと呼ばれることの多いしんすく(@snsk)です。なんでも「BTSについて好きなこと書いていい」という素敵なお話を頂きましたので、この機会に「俺が愛したBTS達」を赤裸々に…… は先日某コミュニティの予習会でやったので、今回は真面目な方の話をしたいと思います。題して「BTS開発プロセス俺流」。俺流とは言うものの、この方式で作ればそうそう外すことは無いはずという汎用的なものを目指しています。
1.BTS要件分析
どんな開発プロセスであってもはじめに要件分析ありき、ということでBTSもその類に漏れません。素人目にはウェブ上でちょいちょいっと設定するだけに見えても、そこは開発プロセスやバグのライフサイクルに密接に関係するツールですので、最初に考えておくべきことは意外にあります。
1-1.プロジェクト構成/利用言語の把握と定義
まず、既に使っている、またはこれから使う予定のBTSについてそのプロジェクト構成を確認します。大抵のBTSはデータベースをプロジェクト単位に分割可能でかつ、入れ子にすることが可能です。そのシステムを利用している最も大きな組織単位でどのような構成を採用しているのか、あなたが最初の導入者であれば、今後どのような構成を取るのかを確認/検討する必要があります。例えば、標準版を親プロジェクトとして、そこからのカスタマイズや派生開発はそのプロジェクトの子としておいて、子プロジェクトで出た標準版の問題は、上位のプロジェクトのトラッカーに登録する、等。また、このBTSが横断する国の言語は原則抑えておく必要がありますが、想定できない場合でも日本語と英語ぐらいは設定しておいたほうが無難でしょう。
1-2.プロセス改善強度の把握
「プロセス改善強度」ってなんですか？という声も聞こえてきそうですが、開発プロセスの改善にあたり基礎となるデータの取集をどれぐらいBTSに頼る予定なのか？をプロジェクトマネージャやQAマネージャと予め詰めておく必要があります。もし、あなたがQAマネージャの場合は自分でこの水準を設定することになります。どのタイミングでどんなデータを取ればどんな状況の把握に役立つはずである、というアレですね。例えば「混入工程」や「混入原因」、「テスト漏れ原因」などです。一見とても魅力的なフィールドで即採用してしまいそうですが、きちんとその理由と背景を把握しておかないと、のちのフィールドデザインの際の取捨選択時に正しい判断ができなくなってしまいます。また、運用開始時にメンバーに説明するためにも重要な資料となりますので、必ず行なっておきましょう。
1-3.連携が想定されているシステムの把握
今日日のBTSはSCMやテストマネジメントツールなど、さまざまな外部システムと連携することができます。どういうI/Oをさばく必要があるかによって、構築時のプラグイン選択などに制限がでることがあります。
2.バグライフサイクルデザイン
さて、ここからいよいよ「それっぽい」BTSの設計に入って行きます。まず最初に検討しなければならないのがこのバグのライフサイクルです。バグがいつ生まれて(認識されて)、開発チームのロールによるどのような過程を経て消滅(完了)するのか、主に「ステータス」を軸に検討します。
2-1.ステータス、ワークフロー設計
百聞は一見に如かずということで、まず例としてBugzillaという著名なBTSが定義しているライフサイクルを示します。
最も重要なのは、
- 解析/修正などの”担当者”がアサインされたか否か - 図中ではASSIGNED
- バグが解決されたかどうか - 図中ではRESOLVED
- 修正されたバグは正しく確認されたか - VERIFIED or CLOSED
の3点です。もちろん状況を把握する為にはステータスは細ければ細かいほどよいでしょうが、今度はルールが守られにくくなるというリスクも抱えてしまいます。この辺の縛りと規律のバランスはこの先も常に悩まされることになります。迷ったら「削る」方向に倒しましょう。ステータスを増やすのは本当に本当に困ってからで充分、かつそうでないと、誰も本気でそのステータスを運用しようとは思わないでしょう。先に例示した3点であれば運用は明らかと思われますが、もしこれ以上増やす場合は、あるステータスからあるステータスに遷移する際の”条件”や”権限”も一緒に検討する必要があるでしょう。例えば、「修正インパクトが大きいので本バージョンでは凍結」を意味する FREEZE というステータスを新設する際には、いったいだれがインパクトが大きいと判断したのか？そのフィーチャーが次版に入らない事は同意を得ているのか？辺りをルールとして策定する必要があります。
2-2.ユーザとロール
次に検討するのはそのBTSを誰が、どんな役割で利用するのか？です。ロールの設定は先にあげたステータスを遷移させる権限と紐付くことがあります。代表的なのは「CLOSED」に出来るのは”テスター”や”テストリーダー”といったようなロールの人のみ、などです。ここをどれぐらい細かく設定できるか？はBTSによってさまざまですが、導入初期はプロジェクトリーダー、テスター、デベロッパーの3種ぐらいが設定できれば充分でしょう。一般的には登録とアサインは全員が可能。RESOLVEDにできるのはデベロッパー、またはプロジェクトリーダーで、CLOSEDは先述の通りテスターのみといった様子です。
3.フィールドデザイン
先にあげたステータスもこのフィールドの一種ですが、BTSには他にもさまざまな入力項目が設定できます。BTSとして機能させるために最低限必要なフィールドは「ステータス」「担当者」「現象の説明」「再現手順」の4つです。どれひとつ抜けても機能しませんが、「プロセス改善強度」が最低にセットされており、最小、最速の運用を臨む場合はこれだけでも良いかも知れません。Excel等のスプレッドシートでも何とかなるのではないかと考えるのも無理はないですが、ファイルで管理してしまうと 1.複数人編集が困難、2.バグ件数が増えると一覧性が極端に落ちる、3.必須の入力項目を設定することが容易にはできないなどの不都合が生じます。スプレッドシートは「祭りのあと」の分析に留めておきましょう。
3-1.プレフィールドとポストフィールド
実はいままで挙げたフィールドはすべてバグ登録時に記入、または自動的に設定される"プレフィールド"です。これに対し、そのレポートがCLOSEに相当するステータスに移行する際に記入されているべきフィールドが”ポストフィールド”です。プレフィールドが主にバグ自体の状況を記述するのに対し、ポストフィールドはそのバグがなぜ発生したのか？という背景を記述します。フィールドを新たに置くときはそのフィールドが”いつ”記入されるべきなのかを念頭においておく必要があります。
3-2.優先度？重要度？カテゴリ？必須？
必須ではないが推奨されるフィールドとしては他に「要約」「カテゴリ」「重要度」「優先度」「発生したバージョン」「コメント」「期日」などがあります。「重要度」と「優先度」の設定はよく混乱を招きますが、ひとつの指針として「重要度」は”その製品にとってどれぐらい問題の大きいバグか？”を表し、「優先度」は”そのプロジェクトにとってどのぐらい優先して解決すべきバグか？”を表す、と定めるとよいでしょう。つまり、「重要度」はテスターやデベロッパーが設定し、「優先度」はプロジェクトリーダーが設定するイメージです。「カテゴリ」はそのバグが製品にとってどのような不都合を生じさせるのかを端的に表す言葉を選びます。筆者はこれと「重要度」を一緒に運用できるよう、「P1.クラッシュ/フリーズ」「P1.セキュリティ問題」「P2.既定の仕様と異なる」「P3.他製品の一般的な動作と異なる」といった文言で運用していました。もちろんどんな現象が問題なのか？は製品ごとに異なるので、それぞれに問題を考えて設定し直す必要があります。これは設定前にプロジェクトリーダーやメンバーと同意をとっておくべきで、なおかつこの問題の裏返しでうすーく品質指標を意識してもらうことにも繋がります。地味ながら(コストが低そうに見えるが)とても効果的なのでオススメです。
また、フィールドをデザインするときに悩ましいのが「必須」フィールドの扱いです。これを入力しないと編集が完了できないというオプションですが、そのままバグ登録1件あたりのコストに跳ね返ります。かといって「任意」が多すぎるとこれまたBTSとしての精度を保てなくなってしまいます。これは組織やチームの文化の成熟度や先に述べた「プロセス改善強度」によって適宜調整することになりますが、BTS自体を上手に運用できなければその先も無いので、基本は極限まで少なく、です。
4.実装とインテグレーション
ここまで設計できたらいよいよ実装に入りましょう。いまどきの大抵のBTSはブラウザのみで設定が可能ですが、国際化やワークフローの設定などはそれなりに時間を取られるので、1日はしっかり確保しておいたほうが無難です。実装が完了したら、ひと通りのロールでステータスを遷移させてみて、想定通りの運用が可能かどうかチェックすることもお忘れなく。
5.運用
さて、とうとうあなたのBTSのがオープンします。まず最初に行うことはワークフローの説明会と資料の公示です。この時、先に設定したロールが具体的にチームメンバーの誰にあたるのかを確実に周知しましょう。ワークフローの説明は実際に動かしながら行うと更に効果的です。この時、のちのプロセス改善のためのフィールドについても、それがなぜ必要で、いつどんな役に立てるつもりなのかを一緒に説明しておきましょう。また、定期的に利用状況や不審なステータスの集計を行いBTSが健全に運用されているかどうかをチェックすることも重要です。また、あるステータスからあるステータスに遷移するまでの時間、いわゆるターンアラウンドタイムはプロジェクトマネージャにとっても非常に有用な情報になるはずです。例えば、新規登録からASSIGNEDになるまでの時間が不審に長い場合はリーダーの稼働状況や、テスターの登録精度に問題がある可能性があります。
以上、BTSを導入する際に検討すべきポイントについて、僕なりの経験に基づいてお話をさせて頂きました。BTSはプロジェクトの渦中中の渦中に運用されるシステムですので、そのプロジェクトがいまどういう状態にあるか、定性的な情報を導き出すのにとても有用なツールです。ぜひテストリーダに任せきりにせず、マネージャにも有効活用していただければと思います。
