1 開催概要

2017年5月20日 NaITE#22を以下のように開催しました。

概要は以下の通りです。

タイトル はじめてのバグ票システム~導入実践ガイド 勉強会
日時 2017年5月20日 (土) 14:00 – 16:40
場所 川崎市産業振興会館
プログラム 14:00 – 14:10 オープニング(開会のご挨拶)  NaITE運営スタッフ
14:10 – 14:30 セッション1「バグ票システム検討SIG」活動内容のご紹介 池田 暁 氏 (NaITE)
15:30 – 16:40 セッション2「バグ票システム立ち上げに必要なコト」 岡内 佑樹 氏 (NaITE バグ票システム検討SIG)
16:40 – 16:50 セッション3 「『ダメなバグ票』について考えよう」 すずき しょうご 氏(NaITE バグ票システム検討SIG)
15:30~15:45  休憩
15:45~16:30 セッション4「バグトーク!with 欠陥エンジニア バグとバグ管理とバグ活用,そして欠陥エンジニアリングの未来について語ろう」 ゲスト:細川 宣啓 氏(日本アイビーエム株式会社 東京基礎研究所)

モデレータ:池田 暁 氏

16:30~16:40  クロージング 「閉会の挨拶」 NaITE 運営スタッフ

 

2 勉強会の様子

今回は「はじめてのバグ票システム ~導入実践ガイド 勉強会」というタイトルで勉強会を行いました。

バグ票システムを導入する際には,それぞれの現場において必要とされる機能や実現したい目標などニーズはさまざまです。いかに便利なシステムであっても,ニーズと合わなければ活用されず,せっかくの苦労も報われません。今回の勉強会では,SIGの活動で検討されたシステムを導入する際のプロセスや,過去の実例としてのワーストプラクティスの紹介が行われ,参加者の皆様にとってもご自身の職場におけるシステム導入や改善を考える糸口を得る機会となったようでした。

後半に行われたバグトーク!と題したセッションは,バグというものの捉え方から考え直すきっかけとなるような,鮮烈なものでした。豊富な話題や,医療の世界とも絡めたわかりやすくも興味深いお話の数々に,参加者の皆様もそれぞれに思うところあったようで,質疑応答の内容も,より自身のこととして考え,言葉を選んでおられた様子が印象的でした。


2.1 オープニング

オープニングでは池田 暁氏 (NaITE) から本イベントの注意事項,NaITEやNaITEフラッグシップイベントである長崎QDGの紹介,また近日開催される Agile Japan 長崎サテライトの紹介,長崎の楽しみ方等についてもご説明をいたしました。また,NaITEの活動の一環である活動中のSIG (Special Interest Group,特定のテーマに関する分科会)や,活動を完了したSIGについての案内も実施いたしました。

 

2.2 セッション1「バグ票システム検討SIG 活動内容のご紹介」

オープニングに続き,池田 暁氏 (NaITE) より,NaITEのSIGである「バグ票システム検討SIG」の活動についてご紹介いただきました。

ここで「バグ票システム」とは,「バグに関するコミュニケーションを含む専用のBTS (Bug Tracking System) 」をいいます。有償無償のBTSに限らず,エクセルを利用した運用も,バグ票システムであるといえます。

本SIGは,「バグ票ワーストプラクティス検討プロジェクト」との合同SIGとして活動し,バグ管理の問題点や,バグ票そのものについて検討を行ってきました。

このセッションでは,このSIG活動の成果として得られた「そもそも,バグ票システムの導入は容易ではない」「バグ票システムをいきなり導入するのではなく,事前に十分な検討を行うべきではないか?」という問題設定について,およびその成果物である「はじめてのバグ票システム 導入実践ガイド」について紹介がありました。

主に,これからバグ票システムの導入を検討している方向けに執筆された上記ガイドは無償公開されており,今後の更新を前提としてコンパクトにまとめてあり,上記ガイド内に設置されたアンケートページを通した意見やアイデアを募集中であるとのことでした。

 

2.3 セッション2「バグ票システム立ち上げに必要なコト」

このセッションでは,岡内 佑樹 氏 (NaITE バグ票システム検討SIG) より,バグ票システム検討SIGや,「はじめてのバグ票システム 導入実践ガイド」の成果物公開に至るまでの経緯や内容の紹介,活用法といった観点から発表していただきました。また,岡内氏は,NaITEの活動と別に「テストラジオ」という取り組みもなさっておられます。Webから聴取可能なラジオ番組で,ソフトウェアテストや関連する話題を多く取り扱っておられます。

セッションの中で,そもそも「バグ票システムがあるうれしさ」や「バグ票システムがなくてはならない理由」といった部分まで立ち返ったお話から,システム導入の難しさについてのお話,「はじめてのバグ票システム 導入実践ガイド」で定義されているシステム導入に関するプロセスについて説明していただきました。また,「システムを活用するために」ということで,ワーストプラクティスを知っておくとよい,というアドバイスもいただきました。

以下に,システム導入のプロセスについての概要と,当日に設けていただいた質疑応答の内容を記載します。

システム導入のプロセスについて

定義されたプロセス 検討すべき内容について
企画 ・本当に必要か?目的とあっているか?
・ 今までの課題を解決できるか?
・ 誰が,いつ,どこで,いつまで 使うのか?
・ 情報を適切に可視化できるか?
設計 ・バグ票そのものをシステムとして設計できているか?
・ 運用フローや,バグのライフサイクルはどうするか?
・ エビデンスとして必要なものが扱えるか?
・ 動作環境は適切か?ネットワーク,ストレージ,メモリ,CPUなど現状のインフラで推奨スペックを満たせるか?
実装 ・設計したシステムをどう実装するのが適切か? (Redmineか?実はExcelのほうが良いということはないか?)
・システム選定の基準は明確か?
・設定方法など,手間と利益のバランスは?
テスト ・そもそもテストを考慮しているか?
・ 希望する運用ができるか?
稼働準備 ・システムに慣れるまで,どのように教育するか?
・背景や目的がきちんと理解されているか?
・ユーザ向け/管理者向けマニュアルを作ってはどうか?

当日の質疑応答


  • Q1. なぜ「バグ管理システム」ではなく,「『バグ票』管理システム」としたのか?
  • A1. この表現がメンバー内でしっくりきたから。また,製造業などで伝統的に「バグ票」という表現が用いられていることもあり,イメージを他部門とも共有しやすいのでは,という狙いもある。単に「BTS」で良いという意見もあるので検討しているところである。
  • Q2. システム導入に関して「成功」「失敗」という表現をされている箇所があるが,どういう意味で使っているのか?
  • A2. メここでいう「成功」とは,「システムがきちんと使われていて,システムをみればバグに関する必要な情報がわかるようになっている状態」と考えている。
  • Q3. 複数ツールの組み合わせを検討する,といった部分も含めて「企画」だと考えているのか?
  • A3. そう考えている。システムからエクセルへエクスポートするケースや,報告のためにシステム上のデータを使用するケースも考えられる。
  • Q4.BTSの管理はどのように行うのがよいと思うか?
  • A4.個人に負担が集中しておらず,かつ改善要望などを受け入れる仕組みがあるべき。
  • Q5. 導入にあたって,現場の抵抗がある場合はどうすべきか?
  • A5. 根性(笑)。メリットとデメリットをまとめて示すことができればよいのではないか。また,なぜ抵抗するのかを良く聞き出すのも大切である。

(Q5. に関して,ゲストの細川 宣啓氏より)

  • まず使っているところを見せて,楽しそうにアピールして興味を引いてはどうか。バグの情報とは,本来宝の山であり,面白いものだ。使わないものには見せてやらないぞ,という態度でもよいのではないか。

 

2.4 セッション3「『ダメなバグ票』について考えよう」

このセッションでは,すずき しょうご 氏(NaITE バグ票システム検討SIG) より,兼任でご活動されている「バグ票ワーストプラクティス検討プロジェクト」での成果も合わせて,バグ票システムを導入したあとに起こり得る問題と,その対策について発表していただきました。

まず前提として,手書きなどの紙媒体でバグ票を管理していた時代と比べても,記入すべき項目自体はあまり変わっていないというお話がありました。そのうえで,現場でバグ票がきちんと使われていないのではないか?必要事項が漏れていて分析に使えないものが多いのではないか?といった問題への対策について,アンケート調査などの活動を通して得られたワーストプラクティスの例なども交えて紹介していただきました。

また,対策の指針のひとつとして,良いバグ票とは「ライフサイクルがスムーズに遷移するもの」,悪いバグ票は「ライフサイクルが戻ったりループしたりして,クローズしないもの」という定義に基づき,ワークフローを整備することの重要性を示していただきました。

世の中にはベストプラクティスに関する論文,書籍は数多くありますが,そのまま自分たちの環境に適用できるものは多くありません。つまり,ベストプラクティスとは特殊なケースであるとも言えそうです。それならば,ワーストプラクティスを学び,ダメな状況を避けるというアプローチも有効なのではないか,という観点からの活動成果は非常に興味深く,参加者の皆様も共感なさっていたようでした。

 

2.5 セッション4「バグトーク!with 欠陥エンジニア バグとバグ管理とバグ活用,そして欠陥エンジニアリングの未来について語ろう」

このセッションでは,ゲストに細川 宣啓 氏(日本アイビーエム株式会社 東京基礎研究所)をお迎えし,モデレータの池田 暁 氏とともに,「欠陥エンジニアリング」について発表していただきました。

「欠陥エンジニアリング」とは,欠陥,バグそのものをエンジニアリングの対象とする研究分野です。今回のお話では医療との類似性を交えて,そもそもバグの管理は何のためにやっているのか,何に役立てるのか,といった観点でのお話は,非常に示唆に富んだ内容でした。

たとえば,今でも使われている「打診器」という医療器具があります。一見,ハンマーのような,石器のような,ただ「胸部を叩いて音を出す」というだけの非常にシンプルな器具です。しかし,18世紀から今なお使用されているこの器具は,その打音から胸部の病気について診断することが可能な,非侵襲性の優れた医療を提供してくれます。つまり,まず我々が考えるべきは,「いかに簡単な道具や手段を用いて目的を達するか?」ということであり,「対象についての深い理解があれば,少ない手がかりからでも,起こっている事象を把握できる」ということなのです。

また,「バグ票」「バグ票システム」に関連した例として,医療の世界における「電子カルテ」があります。医療業界で電子カルテは当初受け入れられませんでした。しかし,絵や関連する症例を図示できるようなシステムになると,そこから10年程度でかなり普及することになりました。このことから,バグレポートをきちんと書いてもらうためには,そもそもバグレポートを読む動機がなくてはならないということ,文字だけで伝わる情報だけでは不足で,ベン図や「リソースリーク標本」,その他とにかく絵をかく習慣づけと,絵を活用できるようにしておくことの重要性を示していただきました。また,医療と同じように,合併症や併発症といった事例も関連付けて収集できるようにすべきである,ということでした。

これらのお話を通して,「欠陥エンジニア」とはすなわち対象とするシステムや,症状としてあらわれるバグの情報から病巣となっている箇所,原因,対処を診断する「システムのお医者さん」になり得る存在であり,そのためには欠陥,バグの情報を質,量ともに「利用できる形で」「適切な分類で」どんどん収集していく必要があるということでした。まさに「きちんと利用され,役に立つバグ票システム」が必要とされる局面です。

情熱的にお話をしていただき,この後に池田暁氏をモデレータとして行われたフリーディスカッションの時間も盛んに意見交換が行われました。議論された内容を,簡単ですがいくつか記載します。

 

バグ情報とは,何をどう集めるのが良いか?

  • 個数で管理することにはあまり意味がない
  • バグを重みづけしたうえで,バグの位置 (工程,モジュール等) と種類といった情報が重要である。正しく分類できること
  • 障害と原因を記録すること

集めた情報をどう活用していくか?

  • バグを分類したうえで相対的な比率,バグの構成を求める
  • バグの構成を多変量解析し,類似のプロジェクトを抽出して考察,予測する
  • ソフトウェアのバグとはすべて人間のまちがいである。誤りを起こさざるを得ない状況 (誘発因子) とはなにか?それを助長する要因 (増幅因子) を探す手がかりにする
  • 「人」を主語にせず,自動詞で考えていく
  • 過去の資産も活用する。すべてクローズの状態に遷移したバグ票は宝の山といえる。「人の誤りかた」の傾向をつかむ

BTSとはどうあるべきか?

  • 必要な情報を記録できることが前提
  • そのうえで,開発で収集されたバグ情報を一次情報とし,それを抽象化・再整理したデータベースを構築するというやり方も有効。整理された利用可能な情報なら,みんな読みたがるはず
  • 現在のBTSは,バグ情報の一部分しか活用できていないかもしれない。BTSを,バグという「症状」から原因を特定する「診断ツール」として活用していくためにはどうしたら良いか,を考えてみる必要がある

 

3 参考情報・リンク等

当日の発表資料等は,以下をご覧ください。

  • OP資料
  • バグ票システム検討SIG

http://naite.swquality.jp/?page_id=40

  • 発表資料

セッション1 

 

4 次回の予定など

次回は7/16 NaITE #23「Scrum入門&Agile japan 2017 長崎サテライト参加報告」として開催いたします。

 

以上

ーーーーーーーーーー
2017年7月16日 作成
報告者:松山 拓広(NaITE運営スタッフ)

pdf:NaITE#22 「はじめてのバグ票システム~導入実践ガイド 勉強会」 開催レポート