JaSST'15関西(2)「なんじゃこりゃ！このバグ票なんか腹たつ ～バグ票の失敗から学ぶソフトウェア開発のための 幸せなコミュニケーション術～」
6/26(金)に開催されたソフトウェアテストシンポジウム2015関西(JaSST'15 Kansai)に参加しました。 私が参加したセッションは下記です。
聴講したセッション
セッション 1-1
「アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的マネジメント」 平鍋 健児 (チェンジビジョン)
セッション A3-1
「なんじゃこりゃ！このバグ票なんか腹たつ ～バグ票の失敗から学ぶソフトウェア開発のための 幸せなコミュニケーション術～」 近美 克行(バグ票ワーストプラクティス検討プロジェクト)
セッション A3-2
「テストエンジニアの人材育成と 自己開発の秘密のレシピ ～エンジニア能力開発のすすめ～」 佐々木 方規(ベリサーブ)
セッション A3-3
「チームで成功させるシステムテスト自動化 by Friendly.」 石川 達也 (Codeer)
セッション 5-1
「フィリピンでのテストチーム立上げと マネジメントの秘訣!!」 田中 学二 (Klab Cyscorpions Inc) 「Being as a test engineer in the past and in the future (邦訳) フィリピンのテストエンジニアの想い ～これまでとこれから!!」 GERANGCO Angeli Marie （Klab Cyscorpions Inc）
今回は、セッション A3-1「なんじゃこりゃ！このバグ票なんか腹たつ ～バグ票の失敗から学ぶソフトウェア開発のための 幸せなコミュニケーション術～」で印象に残った事を紹介します。
セッション A3-1「なんじゃこりゃ！このバグ票なんか腹たつ ～バグ票の失敗から学ぶソフトウェア開発のための 幸せなコミュニケーション術～」近美 克行(バグ票ワーストプラクティス検討プロジェクト)
(1)「バグ票ワーストプラクティス検討プロジェクト」のサイト
https://sites.google.com/site/swworstpracticesite/
(2)なぜ、バグ票？
- 全員がバグ票を見ているため、コミュニケーションの問題を取り上げるには最適である。
- ベストプラクティスの環境を整えるのが大変。
(3)問題事例
「バグ票炎上」
テストエンジニアや開発者がやりとり相手をバグ票をやり合う。
例えば...
「酷いデグレードです」
「御社の開発力では将来があやぶれています」
「これはデグレではありません。デグレの定義...」
「バベルの塔」
用語やルールが混乱し、バグの問題解決管理に支障をきたす。
→人員追加されている状況であるが、バグ票の書き方を知っているとみなし、バグ票の教育を十分やっていないことが原因。
「バグピンポン」
テストエンジニアと開発者の間で発見したバグに同意がとれず、メールやバグ票が行ったり来たりすること。
→詳細は、森崎修司さんのblogを参照。
「何かがおかしい」
バグレポートで「なにかがおかしい」とか「直してくれ」とか言われたらキレそう。あと、推測は大概外れてるから要らない。欲しいのは「なにを期待していたのに、どういう現象が起きたか」という事実だけ。日本語、英語関係ない
— Yukihiro Matsumoto (@yukihiro_matz) 2013, 3月 15(4)バグ票が上手く使われていない状況
- 役割を果たさないバグ票
- ライフサイクルを廻る
- パターン
- 「ピンポン」
- 「ストップ」
- 「アバウト」
- メーカー系や受託開発で問題がある
(5)問題の解決に向けて(テーマ3)
WACATEの夜の分科会やソフトウェア品質(SQiP)シンポジウムのSIGで問題事例共有ワークを実施。
(5-1)対策
事前に目的を共有する
(5-2)傾向
- 記載内容の不備
- バグ票自体の改善
- 教育/指導の必要性：書籍「ソフトウェアテスト293の鉄則」
- バグ票は開発への情報提供
(5-3)得られたこと
(6)One more things
(6-1)名古屋大学 戸田山先生
- バグ票は開発文章
- 伝える文章のための工夫
「文章には相手と目的がある(べき)」
「目的を上手く果たせる文章が良い文章」
「効果的な書き方...」
2名が書いた絵を見比べて1名が書いた文章が伝わるか実験し、課題で考えざる得ないことは下記などが挙げられる。
- 文章の目的は？
- 相手は？
- 相手はどういう人？
- 何を知っている？
- 何を知らないか？
- 知識を与えれば、目的のことをやってくれるか？
(6-2)TIPS:日本語
- 主語省略、指示代名詞、係り受けのあいまいさ
例：阪神に絶対に買ってほしい - 当たり前すぎることは書かない。
- 量の格率(Paul Griceの理論)
要求に見合うだけの情報を発信せよ
求められている以上の情報を発信するな
(6-3)チームの一体感を醸成しよう
- 電話しよう！
- バグの再現デモをしよう
- 相手を飯に行こう！
- 「読み手が変われば、書き方が変わる」
所感
バグ票は、多くのエンジニアが目に触れる媒体である。それ故、文体のとらえ方によっては「けんか腰」に感じることもあるので、相手に誤解されないための転ばぬ杖として、「バグ票ワーストプラクティス検討プロジェクト」から発信される知見から学び、実践しようと思う。
