SQiP2017_sig11_気持ちの良いバグ票コミュニケーションを一緒に考えましょう

「気持ちの良い」バグ票コミュニケーション
を一緒に考えましょう
バグ票ワーストプラクティス検討プロジェクト
城本由希
鈴木昭吾
e-mail：sw.WorstPractice@gmail.com
－そのバグ票、お役に立ってますか？－
SQiP シンポジウム 2017
2017年9月14日東洋大学白山キャンパス
SIG(Special Interest Groups) テーマNo.11

Copyright © 2017 バグ票ワーストプラクティス検討プロジェクト Page 2
本SIGの進め方
所要時間：90分（16:55～18:25）
時間帯所要時間内容
16:55~17:00 5分オープニングトーク
17:00~17:05 5分ワーク①問題点の洗い出し：導入
17:05~17:25 20分自己紹介+ワーク①問題点の洗い出し
17:25~17:35 10分ワーク①問題点の洗い出し：ヒント紹介
17:35~17:40 5分ワーク①問題点の洗い出し：洗い出し
17:40~17:55 15分ワーク②改善策：ブレインストーミング
17:55~18:05 10分ワーク②改善策：分類
18:05~18:15 10分ワーク②改善策：フォーマット化
18:15~18:20 5分発表
18:20~18:25 5分クロージング

本ＳＩＧテーマについて
What：
気持ちの良いバグ票コミュニケーションを一緒に考えましょう！
Why：
バグ票は宝の山のはず、活用できてますか？という疑問がある
How：
バグ票にまつわるみなさんの苦い経験をもとに
みんなで語る！ ⇒他者の経験に学ぶ
Who：
僕ら自身が、僕らのために
When/Where：
このＳＩＧテーマ11にて

本SIGで行うこと、注意事項
行うこと：
バグ票の改善方法をミニワークでやっていきます
目的：
改善のやり方を学んで、現場を改善していくためのヒントを持ち
帰ってもらいたいと思います。
注意事項：
① 本SIGの情報は、成果物としてポスターボードに貼りだします。
この場限りの情報としたいものがあれば、一言お願いします。
② ワークの結果はコミュニティの参考として使わせていただきま
す。その際、個人情報を特定できるものは使用いたしません。

ＳＩＧのポイント
議論を行う上で、下記について注意してください。
 オープンマインドで積極的に
 守秘義務
 この場で話した内容はむやみに公言しない
（その代わり、気にせずに話す）
 オフレコあり
 思いついたことは，整理しなくても良いから、まずは口にしてみよう
 一人だけ長くしゃべらない
 自分の経験を話す
 相手の経験を否定しない、尊重する
 別の意見があるのは大いに結構
 その際には話を膨らますように発言しよう
 性急な解決策を求めない

 城本由希（しろもとゆき）
 社内での仕事：
所属：Acroquest Technology 株式会社
経験：品質保証
担当：テスト設計/実施、リリース管理
 社外での活動：
ソフトウェアテスト系のイベントに出没。
昨年からコミュニティ活動も開始。
JaSST ,WACATE,etc,..,
自己紹介

コミュニティ紹介 ―活動をはじめたきっかけ
1. バグ票はソフトウェアの様々な関係者が最も多く関わる開発技
術文書であり、ほぼ全ての開発現場で存在する
 バグ票
開発者、テスト実施者間のコミュニケーションツール
バグを直してもらうためにやりとりする
研究の動機ーバグ票の状況をもう少し考えてみると・・・
コミュニケーション
直接
直接話す
Skypeなど
チャットなど
間接
メール
バグ票
レビュー記録表など
開発者、テスト担当者間の
間接的なコミュニ
ケーションになるほ
ど、一定のルール
が必要では？

コミュニティ紹介 ―活動をはじめたきっかけ
2. バグ票の書き方を解説している書籍などは多いが、
悪いバグ票がどのようなものかは議論があまりない
3. 有効にバグ票が活用されていない現場がある
 もしかしたらバグ票の質がソフトウェア品質にも寄与している
のではないか
4. なぜなら、活用できないために多くの弊害が発生している
 コミュニケーションのために無駄な工数が発生している
 プロセス改善が進まない etc.
目のつけどころとして悪くない！？
研究の動機ーバグ票の状況をもう少し考えてみると・・・

コミュニティ紹介 ―活動実績
活動の記録－というわけで色々やってみました。

• NaITE(長崎IT技術者会)
さまと共同で作成
• バグ票システム(BTS)をこ
れから導入する方へ向け
て執筆
「はじめてのバグ票システム～導入実践ガイ
ド」
http://naite.swquality.jp/?p=382
紹介資料(Slideshareへリンク)

コミュニティ紹介 ―現在の取り組み
最近では、以下の内容に取り組んでいます
1. 「BugAdvocacy」の要約作成
 バグや品質についての考えを紹介した本。後述するRIMGENの観点が
紹介されている。日本語訳がないため、要約を作成して品質関連のシン
ポジウムなどで紹介している。
2. アンチパターン作成
 バグ票の悪い例の収集や、そこからのアンチパターンの作成。
3. Redmineプラグイン作成
 アンチパターンの防止や軽減に役立つプラグインの検討、作成。

例題ワークの進め方
例題ワークの進め方
1. ご自身が持ってきたバグの問題を付箋に書く(5分)
2. グループで自己紹介(5分)
3. サンプルの「気持ちの良くないバグ」紹介
～「気持ちの良くないバグ」問題点洗い出し(10分)
ここから先は、グループワークで進めていただきます。

自己紹介タイム
所要時間:5分
下記の内容で1,2分程度で自己紹介してください。
• お名前
• 普段のお仕事、立場
• このSIGに来たきっかけ
• 先ほど付箋に書いていただいたバグの内容

「気持ちの良くないバグ」
サンプル紹介
机の上にある「気持ちの良くないバグサンプル」を
ご覧ください。

気持ちの良くないバグ票サンプル
No.01
表題連携システムXからの日時がずれていて不当な日時が過去日時として扱われ
る
報告者Ａ
機能連携システムXからのリクエスト対応機能(画面ＩＤ 0X022)
症状これまでのリリースで何度も報告しているが、連携システムXから送信される予
約用の日時のタイムゾーンが他と異なるため過去日付として扱われることがあ
る。本システムでの受付け日時の重要性から考えるとこの時期にこのバグは
危うい状況にあると考える。実装者はタイムゾーンを理解しているのだろう
か？他にも画面ＩＤ01004と画面ＩＤ01009は管理者向けの画面なので、装飾が
十分でないことは特に問題ないと思うが、JST,GMT,GMT0900のようなタイム
ゾーン表記がばらばらだったリ、表記がなかったりするのは、タイムゾーンンオ
重要性を理解できていないことの結果ではないだろうか。他にも警告メールを
送信するためのメールサーバの間で秒単位のずれがある。これらの時刻は統
一しておくのが基本ではないだろうか。時刻の認識を新たにしてほしい。他に
も祝日設定において春分の日と秋分の日が年にかかわらず同じ日に設定する
が、これらは毎年の官報での発表があった後に正式に決まる。Webを検索す
れば春分の日と秋分の日とを算出するソースコードサンプルを見つけることが
できるが、そのコピー＆ペーストはあまりにも短絡的で日付や日時に対する意
識が低いといえる。
https://thinkit.co.jp/story/2012/07/18/3619

前提の確認
そもそもバグ票は…
バグを直してもらうためのも
の！！
ですよね？

ワーク：
何が欠けているのか
ポイントを出してみよう
所要時間:10分
サンプルのバグ報告について、
バグを修正する開発者視点で、何が欠けているの
か
グループで意見を出し合ってください。

記入例
No.01
表題ユーザに不親切
報告者 B
機能ユーザ登録機能(画面ＩＤ 01022)
症状 xxxページでユーザに住所の入力を求める部分で、番地等、半角英数文字を
入力すると「全角で入力し直してください」とエラーメッセージがでる、
あるべき姿ユーザが入力した半角英数文字を全角に変換して登録する。ユーザへの再入
力は要求しない。なぜ半角とわかっているものをわざわざユーザに入力し直さ
せようとするのか一切理解できない。
表題から問題事象が具体的にわからない
テスト実施者の主観が入りすぎ
やり方
① 問題のありそうな箇所に線を引く
② 線を引いた理由を書く
https://thinkit.co.jp/story/2012/07/18/3619

欠けているポイントを探すヒント
RIMGENの観点紹介

書籍 Bug Advocacy紹介
Cem Kerner, Rebecca L. Fiedler らが
2015年7月下旬に出版した書籍。
著者らの講義の内容をまとめた内容。
下記のことが述べられている
• 「品質」や「バグ」の考え方
• バグ票の書き方
• 改善のヒント
• バグトラッキングシステム(BTS)の利用時の留
意点
• 再現不能なバグや却下されるようなバグ票に
ついての考え方や対応
• バグ票作成者への信頼や信用がバグ票の利
用や効果について大きく影響すること
https://www.amazon.co.jp/Bug-Advocacy-
Workbook-Rebecca-Fiedler/dp/098981193X

「RIMGENの観点」について
バグ票の記載内容を改善するための6つの要素をそれぞれ頭
文字をとって”RIMGEN” と呼び、紹介されているものがある。
頭文字と簡単な内容を以下に記す。
※RIMGENそれぞれの日本語訳は、検討中のものです。よりよい案がありましたら、教えていただけると助かります。
要素意味内容
R Replicate
（再現性）
・再現できるか
I Isolate
（独立性）
・単純な手順となっているか
・冗長な要素や手順などは分けられているか
・1件/レポートとなっているか
M Maximize
（発端性）
・最悪なことが起きるバグの兆候をみつけているか
G Generalize
（普遍性）
・プロダクトに対するバグの影響範囲を識別できているか
・そのバグは他の環境や条件で発生することはあるか
E External
（第三者性）
・プロダクト利用時にバグの影響範囲を開発者やテスト担当者、
開発組織外の視点から識別できているか
N Neutral
（中立性）
・困惑させるような推測や思い込みなどがない
・個人に対する批判や侮辱、いらつかせたり困惑させるような内
容がないか

「RIMGENの観点」のバグ票問題具体例
Replicate：
・再現できるか問題①：
再現手順が示されていない。
起票者はお客様側のプロダクト
オーナー。
こちらで調べる必要がある。
問題②：
後で同類の事象が発生したときに
探せない。どんな修正、確認を
行ったかわからない。
（「確認しました」のみ）

Isolate：
問題①：
複数の問題(と考えられる事
象)が1件として起票されている。

Maximize：
問題①：
WEBシステムでプロキシサーバ
のキャッシュのことを考えずにソ
フトウェアを作ったところ、常に
最新情報を見せたい画面で古い
情報が表示されるというバグが
埋め込まれた。実はこのバグは、
古い情報を見せるという問題だ
けではなく、他の人用の情報を
見せてしまうというセキュリティ
上の問題でもあった。

Generalize：
・そのバグは他の環境や条件で発生することはあるか？
問題①：
報告した際にレアケースといわ
れ、却下されたが、のちの市場
クレーム報告で、顧客が同様の
手順を行い、データが壊れてし
まう現象が発生した。

External：
・プロダクト利用時にバグの影響範囲を開発者やテス
ト担当者、開発組織外の視点から識別できているか
問題①：
仕様には、明確に記載されてい
ないところだけれど、ユーザに
は、わかりそうなバグ。

Neutral：
・個人に対する批判や侮辱、いらつかせたり困惑させ
るような内容がない
問題①：
バグ原因切り分けで「○○が
原因だと思われます」と自分で
推測して書いていました。一歩
間違えたら開発者をミスリード
していた。

RIMGENの観点に沿ってないときの問題点
RIMGENの観点に沿わないとどうなるか？
明確でないバグ票
バグが非現実的、
不合理として却下される
関係者間の信頼がなくなる
再現不能なバグとして
却下される
R
I
M G E
N
システムへの理解とその説明スキ
ルが必要ではないか？
高め改善難易度低め
客観的に書くべきではないか？
修正されるべきバグに
フォーカスが当たらない
バグの内容を理解する
のに時間がかかる
書き方で防げる問題ではないか？

RIMGENの観点に
問題を分類してみよう
所要時間:05分
先ほどと同じサンプルのバグ報告の問題点を分類し
てみましょう。
RIMGENの観点で分類するとどうなるのか、体験し
てみてください。

記入例
No.01
表題ユーザに不親切
報告者 B
機能ユーザ登録機能(画面ＩＤ 01022)
症状 xxxページでユーザに住所の入力を求める部分で、番地等、半角英数文字を
入力すると「全角で入力し直してください」とエラーメッセージがでる、
あるべき姿ユーザが入力した半角英数文字を全角に変換して登録する。ユーザへの再入
力は要求しない。なぜ半角とわかっているものをわざわざユーザに入力し直さ
せようとするのか一切理解できない。
やり方
今回のワークでは、改善に比較的取り組みやすい「R」「I」の観点で
見つかる問題に絞ります。
① 問題のありそうな箇所に線を引く
R：黄色 I：ピンク
② 線を引いた理由を書く
自己紹介で書いてもらったバグについても、RIMGENのどれに分類で
きるのか、合わせて考えてみてください

バグ票に必要な解決策を
洗い出してみよう①
所要時間:15分
前のワークで洗い出した問題に対して、
ブレインストーミング形式で、解決策を出してみま
しょう。
解決策は付箋に書き出してください。

ブレインストーミングのお約束
 ブレインストーミングの4原則
1. 判断・結論を出さない（結論厳禁）
2. 粗野な考えを歓迎する（自由奔放）
3. 量を重視する（質より量）
4. アイディアを結合し発展させる（結合改善）

バグ票に必要な解決策を
洗い出してみよう②
所要時間:10分
ブレインストーミングで出した解決策について、
分類してみましょう。
今回は、フォーマットの見直しで防げるもの、防げな
いものの2種類に分類してみてください。

フォーマットに着目する理由
 バグ票
開発者、テスト実施者間のコミュニケーションツール
バグを直してもらうためにやりとりする
直接
直接話す
Skypeなど
チャットなど
間接
メール
バグ票
レビュー記録表など
開発者、テスト担当者間の
間接的なコミュニ
ケーションになるほ
ど、一定のルール
が必要では？

フォーマットに着目する理由
 間接的なコミュニケーションになるほど、一定のルール
が必要では？ルールの一例がフォーマット。
→フォーマットがないと、以下のような問題が起き、バグの
本質的な問題にたどり着くまでに時間がかかる
 事象が一文で書かれるのみで、手順がない
 複数の重要度の異なる問題が書かれ、結局何が問題なのか
がわからない
…などなど
 フォーマットがあれば、
バグ修正開発者⇔テスト実施者（バグ起票者）の
ヒアリング時間は減らせるのではないか？
その分、バグ解決に充てられる時間を増やせる！
色々ありますよね…。

所要時間:15分
フォーマット化してみよう
まとめたフォーマットとその理由を、
後ほどグループごとに発表していただ
きます

フォーマット化してみよう所要時間:10 分
・改善案の検討議論
・これまでの話し合いから見えてきたポイントを盛り
込んで、バグ票のフォーマットに入るべき、項目をあ
げてみましょう
バグ票
項目１：表題
項目２：xxx
以下の内容について検討してください
• フォーマットの項目
• 自由入力か選択式

まとめ
下記の内容についてグループで発表していただきます。
・サンプルのバグ票に欠けているポイント
・そこから導き出されたフォーマット

RIMGENの観点に沿ってないときの問題点
RIMGENの観点に沿わないとどうなるか？
明確でないバグ票
バグが非現実的、
不合理として却下される
関係者間の信頼がなくなる
再現不能なバグとして
却下される
R
I
M G E
N
書き方で防げる問題ではないか？
システムへの理解とその説明スキ
ルが必要ではないか？
高め改善難易度低め
客観的に書くべきではないか？
修正されるべきバグに
フォーカスが当たらない
バグの内容を理解する
のに時間がかかる

「RIMGENの観点」について
バグ票の記載内容を改善するための6つの要素をそれぞれ頭
文字をとって”RIMGEN” と呼び、紹介されているものがある。
頭文字と簡単な内容を以下に記す。
※RIMGENそれぞれの日本語訳は、検討中のものです。よりよい案がありましたら、教えていただけると助かります。
要素意味内容
R Replicate
（再現性）
・再現できるか
I Isolate
（独立性）
M Maximize
（発端性）
G Generalize
（普遍性）
・そのバグは他の環境や条件で発生することはあるか
E External
（第三者性）
・プロダクト利用時にバグの影響範囲を開発者やテスト担当者、
開発組織外の視点から識別できているか
N Neutral
（中立性）
・個人に対する批判や侮辱、いらつかせたり困惑させるような内
容がないか

さいごに
今回はフォーマットに着目しましたが、改善の流れはほか
でも同じ
①問題点の洗い出し
②問題点の分類
③改善案出し
④改善案の分類
お手軽で効果の高そうなところからTRY

さいごに
そもそもバグ票は…
バグを直してもらうためのも
の！！
繰り返しに
なりますが

本日お伝えしたいこと・・・バグ票への関心
SQiPシンポジウム終了後、みなさんに現場で
「バグ票の問題や改善を意識した！」
「バグ票の改善を始めたい！」
と思って頂くことが
本SIGの目標
バグ票×コミュニケーション

ご参加ありがとうございました。ｍ（＿＿）ｍ
バグ票へ、もっと愛を・・・
「まだ話し足りない方がいらっしゃいましたら、情報交換会にて！」

～お誘い～
興味をもっていただけたら、サイトを見てみてください。
バグ票に関する「思い」を共有しましょう！
問い合わせ先：sw.WorstPractice@gmail.com

SQiP2017_sig11_気持ちの良いバグ票コミュニケーションを一緒に考えましょう

Recommended

Recommended

More Related Content

Similar to SQiP2017_sig11_気持ちの良いバグ票コミュニケーションを一緒に考えましょう

Similar to SQiP2017_sig11_気持ちの良いバグ票コミュニケーションを一緒に考えましょう (20)

SQiP2017_sig11_気持ちの良いバグ票コミュニケーションを一緒に考えましょう