長崎IT技術者会が2016年9月25日に公開した、『はじめてのバグ票システム ～導入実践ガイド』（第1.0版）を読んでみました。
naite.swquality.jp
『はじめてのバグ票システム』とは？
ソフトウェア開発においてインシデントを管理しなければならないのは当然で、そのためのツールがいくつもあります。ソフトウェアエンジニアであれば、何がしかのツールに触れたことのある人が大半でしょう。「バグ票」のオープンからクローズまでのイメージももっていると思います。
一方、自分がそのツール、本資料でいう「バグ票システム」を構築・運用する立場になったらどうでしょう。
すぐ思いつく作業として、サーバを調達したり、ネットワークに接続したり、ツールをインストールしたり、があります。ですがこれらはある意味、「ググればわかる」ものが多いと思います。
実はバグ票システムを始める上で難しいのは、上のような技術的な作業よりも、「ググってもわからない」、個々に違う組織に合わせた設定と運用の検討ではないでしょうか。
わたし自身も何度か導入に関わったことがありますが、組織が大きかったり、プロダクトの歴史が長かったり、既存のバグ管理システムがあったりするほど、検討が大変になることを実感しました。
『はじめてのバグ票システム』は、意外なほど資料に乏しいこの部分をスコープにしています。
本ガイドは、「バグ票システムの導入検討から稼働準備までのプロセスおよび必要な活動について解説すること，および参考となる情報の紹介」をスコープとしています。
本編の目次は以下の通りです。バグ票システムの導入を、小規模なシステム開発と捉えていると言えます。
- バグ票およびバグ票システムとは
- バグ票システムの導入検討から稼働準備までのプロセス
- バグ票システムの企画
- バグ票システムの設計
- バグ票システムの実装
- バグ票システムのテスト
- 稼働準備
- バグ票に関してのワーストプラクティス
- バグ票を活用した活動
企画・設計という段階を明示的に設けているところがポイントです。
「企画」においては、何の目的で・誰が・いつ・どこで・いつまで 使うのかという全体像について整理しておくことを勧めています。
「設計」は、おそらく本資料の中でもっとも大事な部分でしょう。ワークフローの設計、バグ票の項目の設計、ロールと権限の設計などについて言及しています。
もうExcelでのインシデント管理は無理だ！ おれはExcel管理をやめるぞッと考えている方であれば、目を通しておくべき資料と言えるでしょう。
次版以降でここに期待したい！
本資料の価値を前提としたうえで、「改版を前提としてい」るということなので、「今後、このあたりの情報が補強されると嬉しい！」という点について書いてみます。やはり、もっとも重要な第4章「バグ票システムの設計」が、力の入れどころだと考えます。
バグ票のワークフローのモデル
4.1節では、バグ票のワークフロー（状態遷移）の例を3つ挙げていますが、イメージをつかむ程度の記述になっており、物足りなさがあります。
この節で、モデルとなるようなワークフローを作業の重さごとにいくつか提示し、詳説してもらえると嬉しいと思いました。詳説というのは、「バグ票の各状態が持つ意味」「状態遷移が発生するトリガー」「パターンのメリットとデメリット」といった内容です。例えば重厚なワークフローにおいては、バグの修正内容について「管理者の承認待ち」といった悲しいステータスができてしまい、未解決バグが積まれていくデメリットがある・・・とか。
そうすれば読者が、自分たちの開発スタイルに合うのがどれかを判断しやすいのではないでしょうか。逆に、ワークフローの検討自体が、自分たちのプロセスを見直すいいきっかけになるとも思います。
特有のケースの扱い
一般的なワークフローは議論もしやすく、決定もそんなに難しくはありません。一方で検討が漏れがちなのが、あまり頻発はしない状態の扱いです。たとえば・・・
- 検出したものの、当該バージョンでは直さないことにしたバグはどういうステータスにしておくのか
- 再現性のないバグは何をもってクローズにするのか
- あるプロダクトで見つかったが、別のプロダクトでも修正の必要なバグは、どうバグ票を起こすか
このような、例外とは言わないまでも扱いづらい事例を集めて、扱い方のパターンなども提示されていれば、とっても助かると思います。
バグ票項目のモデル
ワークフローと同様、「管理すべき情報」のモデルが提示されていると嬉しい！
さらにいうと、それぞれの項目に対する「選択肢」の例も欲しいところですが・・・、さすがにそこまでいくと既存の資料がありそうだし、本資料のスコープから外れるのかもしれません。
バグ票にどのような項目を持たせるかについての検討は、できるだけ入力を少なくしたい担当者側と、分析のために多くの情報が欲しい管理者側の綱引きになることがあります。使う見込みのない管理項目は、新システム導入を機に思い切ってバッサリ捨てることが大事でしょう。
たとえば「バグを作りこんだ設計工程」という項目を管理するとして、分析の結果「基本設計工程」に問題があるとわかった・・・でもその後、基本設計工程や、それに対応するテスト工程を改善するつもりがないのであれば、「作りこんだ設計工程」を管理する意味はなかったわけです。
入力を容易にする工夫
多くのテスト担当者にとって、バグ票の入力は面倒なものではないでしょうか。であれば、入力の負担をできるだけ軽減することが大事になってくるので、そのあたりの工夫ポイントについて言及してあると嬉しい。たとえば、以下のような点です。
- 「起票者」や各種日付は自動的に入力される
- 項目間の制約を設けて、ある項目を入力すると、関連する項目の選択肢が絞り込まれる
ツールに依存する部分もあると思うのですが、ノウハウなどあるとよいですよね。
重要度と優先度
たいていの場合「重要度」「優先度」といった項目がバグ票にはあって、たとえばS・A・B・Cが選べると思います。で、よくあるケースが以下です！
- 優先度「S」多すぎ、どれから対応してよいのやら
- 重要度「B」（ふつう）多すぎ、分析の価値なし
重要度は、選ぶのに迷う割には価値のあるデータにならないことも多いし、本当に必要な項目かは考えた方がいいでしょう。
優先度は、テストの継続を致命的にブロックするのか、わずかなのか、影響ないのか、くらいで分けるといいと思います。
改版に期待とか言いながら、もう自分の言いたいこと全部書いちゃってますけど。。。
その他
既存のバグ管理システムがある場合の移行の注意点、特に過渡期の運用など、一番つらいところでもあるので情報があると心強いですね。
まとめ
以上、思いついたものを自分勝手に並べてみました。
本資料のような、地に足の着いた実践的な資料はとても貴重だと思います。長崎IT技術者会の今後の活動に期待しています。
追記（2016/11/8）
秋山さんからいただいたコメントを残しておきます。ありがとうございます。
