JaSST'18 Tokyo で公開した内容です。

1. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 1
バグ票コミュニケーション
アンチパターン・ランゲージ
草稿版

2. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 2
1 はじめに
皆さんは、普段の開発業務で、バグ票を書いたり、読んだりしたことはありますよね？
バグ票は開発現場でのコミュニケーションを支える主要なツールであり、バグ票はソフトウ
ェア開発現場で最も多くの関係者が目にする文書です。
ですが、バグ票を利用したコミュニケーションは、関係者の立場の違いや開発状況の不透明
さゆえに、時として関係者間で困った状況になることがあります。
本冊子では、そういった失敗経験談や事例を今までのワークショップ、アンケート結果や文
献などを元に、アンチパターン・ランゲージとしてまとめたものです。
本書を読んだ方が少しでもご紹介したアンチパターンに陥らないように回避しながら、より
良いバグ票コミュニケーションができることを願って…。
2 対象読者
本冊子は下記のような方を読者として想定しています。
 バグ票管理システム（Bug Tracking System：BTS）でのバグ票起票者/管理者/運用者
 プロジェクトマネージャ/リーダ/開発メンバ/テスト担当者
3 活用方法
本冊子は、アンチパターンの内容を共有することで、下記の効果を狙います。
 本パターンを「言葉」として対話の中で使うことで、「秘訣」を共有する
 本パターンを「言葉」にしたことで見える現象を、さらに認識できるようにする
 自分の経験を活かしつつ、他の経験を取り入れることで、その人らしさや経験を肯定しな
がら成長することを促す
是非、この冊子を片手に他の方とバグ票コミュニケーションについて話してみてください！

3. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 3
4 バグ票コミュニケーション アンチパターン・ランゲージ
アンチパターンのつながりを下記に示します。
詳細は、次節の説明をご覧ください。

4. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 4
4.1 No.01 グレート合体 BTS ロボ
 文脈
最近、開発している製品を統合する動きがあり、バグが見つかった時には、関連する組織にもバ
グ票を登録するように依頼する必要がある。ある日、どうやら関連している製品を利用すると誤っ
た出力が返ってしまうバグを見つけた。「さて、どっちから登録しようかな…。」
▼その文脈において
 問題: 「バグ票のステータス監視や、クローズに時間がかかる」
➢ フォース
自分のチームも含めて、複数の BTS が存在する。/組織ごとに異なるツールの BTS を持ってい
る。/ある BTS には操作するのに所有している組織メンバに依頼が必要になる。
▼そこで
 解決: 「バグ票管理の窓口担当を立てる」
➢ アクション
チームごとに管理者を立てて、定期的にバグ票のステータス監視結果や、新規バグの内容
を共有する。
▼その結果
バグ票のステータス未更新が減る、バグ票確認の効率が上がるが、窓口担当の管理コストがか
かる。
 関連パターン
->：その先
・西と東の名探偵
<-：その前
・特になし

5. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 5
4.2 No.02 西と東の名探偵
 文脈
異なる部門のテストチームが複数ある中で、それぞれテストを行っている。関連する製品同士の
テストでは、開発でもそれぞれのバグ票を参照し、自チームの担当範囲であれば、異なる部門であ
ってもそのバグ票を受け取り、バグ修正を行う。ある日、テスト担当者はバグを登録したが、異な
る部門から指摘を受ける。「それ、昨日に私のチームも登録しましたよ」
▼その文脈において
 問題: 「バグの修正担当者や再テスト担当者が、異なるバグ票を参照して認識が食い違う」
➢ フォース
他人の書いたバグ票を知らない。/見つけたバグはとりあえず登録と指示を受ける。
▼そこで
 解決: 「既存バグ票を把握しやすい仕組みにする」
➢ アクション
新規のバグを起票するときの基準を決める。（同じバグがないか確認することを、新規の
バグを起票するときの手順に盛り込む）/バグ票の共有を行う。
▼その結果
バグ修正担当者にバグ票を割り振る人が、どれを直すべきか判断する手間が減るが、登録する
際に事前の共有できる仕組みやルールが必要になる。
 関連パターン
->：その先
・特になし
<-：その前
・グレート合体 BTS ロボ

6. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 6
4.3 No.03 いじわるばあさん
 文脈
これまでのリリースで何度も報告しているが、JST,GMT,GMT0900 のようなタイムゾーン表記がば
らばらだったリ、表記がなかったりするのは、タイムゾーンの重要性を理解できていないことの結
果ではないだろうか。そもそもこれが仕様だとしたならば、開発者は何を考えているのだろうか。
▼その文脈において
 問題: 「報告したバグ票は却下され、重大バグが後に報告される」
➢ フォース
起票者が開発者を信用していない。/開発者も起票者を信用していない。/重箱の隅をつついたよう
な指摘をバグ票として記載する。/ バグのレベルを大げさに報告する。/テスト担当者の憶測
や推測が入る。
▼そこで
 解決: 「礼節と尊敬の念をもって、バグ票には事実を記載する」
➢ アクション
重大な問題であると想定するバグ票で報告すること。/相手の人格を否定するような記載
をしない。
▼その結果
バグ票が却下されたりせずに、修正されるようになる。記載する際の文体やマインドセットに
ついての教育を行うコストがかかる。信頼が損なわれている場合は、時間がかかる。
 関連パターン
->：その先
・バグピンポン
<-：その前
・特になし

7. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 7
4.4 No.04 バグピンポン
 文脈
開発とテストチームが別々となり、拠点が分断された開発となった。また、拠点が海外であ
るところもあり、文化も異なるし、お互いのスキルもよくわかっていない。
▼その文脈において
 問題: 「開発とテストチームでやり取りが止まらない」
➢ フォース
文壇により情報共有が不十分。/開発がテスト担当を見下している。/行き過ぎた責任分担意識
が強い。（自分を守る、「品質の番人」意識がある）
▼そこで
 解決: 「チームの一体感を持つ」
➢ アクション
開発とテストチームにそれぞれ、窓口担当を置く。/製品ゴールやテスト目的の共有化を
図る。/スキルの可視化を行う。
▼その結果
関係者の意識の方向性が一致しているので、バグ票のクローズまでの時間がかからなくな
るが、テスト工数以外のコストがかかる。
 関連パターン
->：その先
・特になし
<-：その前
・いじわるばあさん/お前それサバンナでも同じ事言えんの

8. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 8
4.5 No.05 書き手の理解不足
 文脈
次期製品の開発がスタートしたため、テストチームも再編された。その際、新規のテストメンバ
が寄せ集めであった。2 週間後にはテストが始まるため、教育やフォローはその際に、適宜行って
いくしかないなぁ。
▼その文脈において
 問題: 「バグ票に関する記載が不十分になるため、問い合わせが必要になる」
➢ フォース：
経験の少ないテスト担当者がいる。/プロジェクトの立ち上げまでの時間が多くない。/バ
グ票は教育がなくても書けるという思い込みがある。
▼そこで
 解決: 「良いバグ票のセンスを習得する」
➢ アクション
バグ内容とバグ票のセットを提示する。/悪いバグ票の開設やフィードバックを行う。/他人の
人が書いたバグ票を読み、自分のものと比較する。
▼その結果
関係者間で記述の粒度統一が望めるが、バグ票を作成するコストが増大する。
 関連パターン
->：その先
・複雑に絡んだ心
<-：その前
・様式考慮不足/風まかせ、人まかせ

9. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 9
4.6 No.06 再現不能
 文脈
バグが発生したということで、どんな現状が起きたのか確認してほしいといわれたため、受け取
ったバグ票を読んでいたが…情報が不足しており、再現できない。
▼その文脈において
 問題:「作業遅延や内容確認のために余計なコストが発生する」
➢ フォース：
バグ票以前にレポートとして問題ある。/デバッグ担当のほしい情報がテスト担当者に
伝わっていない。
▼そこで
 解決:「再現方法を伝えるのに役立つ情報(問題、手順、事象、環境等)を取得しやすくする」
➢ アクション：
情報を得るための調査手順をまとめておく。/テンプレートを作成するまたは見直す。／
自動取得できるところはツールを入れるなどして機械的に取得する。／テスト担当者とデ
バッグ担当者にて 1 回以上ペアワークを行なう。
▼その結果
読み手と書き手がお互いに成長できるが、教育等のコストがかかる。
 関連パターン
->：その先
・油断大敵、火がぼうぼう
<-：その前
・様式考慮不足

10. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 10
4.7 No.07 分析困難
 文脈
ある日、品質管理部門の人が開発製品の品質が悪いため、分析をしてほしいとマネージャか
ら突然に依頼された。よし…分析を始めてみるか。
▼その文脈において
 問題: 「バグ票が空欄だったり、設問と食い違ったことが書かれている」
➢ フォース
プロセス改善に利用されていることがあまり知られていない。/分析する人と起票者
が違う。/バグ票の優先度が低い。
▼そこで
 解決: 「どのように分析され、活用されているかを周知する」
➢ アクション
分析結果を周知する。/バグ票が役立つ場面(使われている場面)を見せる。/空白が多
くて分析できなかった場合は、そのことも周知する。
▼その結果
バグ票が分析に使えるようになり、現状が正しく分析されるようになる。試行錯誤しなが
ら分析を行うための時間を確保する必要がある。
 関連パターン
->：その先
・特になし
<-：その前
・様式考慮不足

11. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 11
4.8 No.08 様式考慮不足
 文脈
テスト担当者がバグを発見したため、起票することにした。しかし、BTS を初めて使うた
め、バグ票の項目が何を意味するのかが理解できていない。BTS の管理者は、このプロジェク
トでどのように利用するのかを説明する資料を用意していないのだろうか…。
▼その文脈において
 問題: 「入力時に戸惑う項目があり、記入されなかったり、人によって記載にばらつきが
発生する」
➢ フォース
組織やプロセスがバグ票を重視していない。
▼そこで
 解決: 「バグ票の目的、関係者にとって利用可能な項目を設定する」
➢ アクション
記入時に迷うことなく起票できる。/必要な情報が過不足なく存在し、適切に表現さ
れている。/空白や不適切な値が入力されていない。
▼その結果
後続のプロセスに情報を効果的に伝えることができるが、BTS 利用時にシステム理解と関
係者への調整を行う必要がある。
 関連パターン
->：その先
・書き手の理解不足/再現不能/分析困難
<-：その前
・特になし

12. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 12
4.9 No.09 風まかせ、人まかせ
 文脈
突然問い合わせが来たから調査してと、マネージャから依頼がきた。動作が止まるといわれ
たが、聞いた手順だと問題がない…そもそもテストで確認した項目。お客さんは一体どんな操
作したんだ…これはお客様に聞くかその機器を直接触るしかないなぁ。
▼その文脈において
 問題: 「作業遅延や内容確認のために、直接お客様に確認するコストが発生する」
➢ フォース
対応する役割がありそうな人に、製品の内容を確かめずに、任せやすい人に丸投げする。
▼そこで
 解決:「社内での原因調査、対応を行う人やルールを設定する」
➢ アクション
お客様からの問い合わせ対応時に、操作内容の確認を行う。/操作ログを出力する機
能を製品に組み込んでおく。
▼その結果
事前に確認すべき内容が明確になり、すぐに回避策をお客様に伝えられるようになる。他
部門の方に対応をしてもらう場合、事前の調整や依頼が必要になる。
 関連パターン
->：その先
・書き手の理解不足
<-：その前
・特になし

13. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 13
4.10 No.10 油断大敵、火がぼうぼう
 文脈
開発者は、重大バグが製品サポートから発生したと聞き、一週間対応に追われてしまった。そう
いえば、テスト担当者にも報告を受けたけれど、めったに起きないと思っていた。あのとき直して
いれば…。
▼その文脈において
 問題: 「市場で重大バグが流出する」
➢ フォース
バグが発生しても、バグ票を読んだだけでは、深刻なことだと認識されていない。
▼そこで
 解決: 「現実的、合理的なバグであることを証明する」
➢ アクション
極端なテストケースからバグを説明し、極端な条件を緩くしてテストを行う。/テストを
実演する。/どれくらいのユーザに影響を与えるか、深刻なのかを示す
▼その結果
開発者から抵抗されるバグレポートの中でで、「バグではなく仕様である」、「めったに発生し
ない」という理由などから、開発者に対応を却下されなくなる。調査や議論するためのコスト
がかかる。
 関連パターン
->：その先
・特になし
<-：その前
・再現不能

14. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 14
4.11 No.11 お前それサバンナでも同じ事言えんの
 文脈
マネージャは、バグ票を見たときに、あるバージョンでは起きるのかが気になった。これ
は、起票者に問い合わせないといけない。なぜなら、A 社さんが使っているバージョンだか
ら、それで発生したらすぐに修正版を出さないといけないからだ。
▼その文脈において
 問題: 「関連する開発メンバやユーザからの信用がなくなる」
➢ フォース
誰が、起票したバグ票を読むか把握していない。/関係者(開発者、プロダクトマネジャ
ー、テスト担当者、顧客サポート、役員など)意思決定の情報になることを理解していな
い。
▼そこで
解決: 「バグが直されるべきであるという主張のためデータや根拠を提供する」
➢ アクション
バグ票の内容を明瞭にする。/報告すべき内容かどうかは考慮する。
▼その結果
起票者の信用が増えていくため、修正されるバグ票が多くなる。すでに大きく信用が
損なわれている場合は、信用の回復に時間がかかる。
 関連パターン
->：その先
・バグピンポン
<-：その前
・特になし

15. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 15
4.12 No.12 複雑に絡んだ心
 文脈
開発者がバグ票を見ていたころ、タイトルがものすごい状態だった。「画面の値が間違っ
ているし、動作が A になるし、色々おかしい」？ え、起票した人はなにしたの？
▼その文脈において
 問題: 「バグの発生する状況や重要性が理解しにくくなる」
➢ フォース
記載ルールが決まっていない。/書き方の教育、指導が行われていない。
▼そこで
 解決:「バグ票に書かれている内容を理解しやすい内容に絞る」
➢ アクション
起票する単位をルールとして定める。/分割して記載できないかを検討する。
▼その結果
開発者からの問い合わせが減る。事前に教育等のコストがかかる。
 関連パターン
->：その先
・特になし
<-：その前
・書き手の理解不足

16. バグ票ワーストプラクティス検討プロジェクト - 2018 年 3 月 16
参考文献
[1] Cem Kerner, Rebecca L. Fiedler(2015), 「BUG ADVOCACY：A BEST WORKBOOK」,
Context-Driven Press.
[2] 井庭崇(2014), 「パターンランゲージ ワークショップ ～企業の創造的成長のための
パターンランゲージ3.0～」, Wilson Learning Worldwide: Global Seminar.
コミュニティ紹介
「バグ票ワーストプラクティス検討プロジェクト」では、「バグ票」の「ワーストプラ
クティス」を集め、「なぜ使えないバグ票が多いのか？」を分析・調査しております。こ
の活動を通して、バグ票を改善することで、関係者間のコミュニケーションが改善され、
自分たちの不具合を適切に記録することでソフトウェア開発プロセス改善の重要なデータ
を収集・分析して、ソフトウェア開発活動を改善することができると考えております。
みなさまの組織ではバグ票を有効に活用できているでしょうか。BTS（Bug Tracking
System）を利用したり、組織独自のExcelフォーマットなどで不具合を記録している組織
は多いと思いますが、記録された内容が不適切であったり、問題解決や調査を行なうため
の情報が不十分、といった現象などが発生していないでしょうか。
そして、バグの情報が適切に記録されていないことにより、バグ票の情報がソフトウェ
アのライフサイクルを通した開発活動に有効に活用されていないことが多いのではない
か、と私たちは考えています。
活動内容を広く伝えるために、Webページを開設しています。ご興味ある方はご参照く
ださい。
https://sites.google.com/site/swworstpracticesite/