バグをｘｘと呼ぶ

バグをドラゴンと呼ぶという記事が世に出たのが2年前。 http://konifar.hatenablog.com/entry/2015/05/02/003449

そろそろ新しい呼び方を提案していく時期だと思います。

実は考え始めると難しくて、バグに対する３つの行為をうまく置き換える必要があります。

• バグを見つけた
• バグを修正する
• バグを修正した

どれもテンションが上がらないといけないと思います。 どれかだけだとメタファとしては弱くなってしまいます。

例えば、金塊、宝石、お宝などだと見つける方のメタファにはなるけど、修正するほうにはなりにくい。その点ドラゴンは見つけて良し、戦って良し、倒してよしのグレートなメタファです。

ということで、ドラゴンに負けないメタファを考えてみます。 ※昔仙台のテスト勉強会で考えたアイディアも入ってます。

勝手にnemorineランキング。

第5位 昆虫

バグを憧れの昆虫にしてみます。チームのみんなで少年の心を取り戻しましょう。

• バグを見つけた → ヘラクレスオオカブト見つけた！
• バグを修正している → 今捕まえてる！
• バグを修正した → 捕まえた！

第4位 美少女

男性の多い職場ならではのノリ。

• バグを見つけた → Ｓ級の美少女見つけた！
• バグを修正している → 今告白している！
• バグを修正した → 彼女になった！

第3位 肉

なかなかいいメタファだと思いますが、話しているとお腹減りますね。 すぐ品切れになる有名な焼肉店をイメージしています。

• バグを見つけた → 特上カルビあった！
• バグを修正している → 焼いてる！
• バグを修正した → 食った！

第2位 キャバ嬢

美少女よりさらにリアル感が増します。年齢高めのオジサンばかりのチームだとこのメタファがいいかもしれません。

• バグを見つけた → めっちゃ美人のキャバ嬢見つけた！
• バグを修正している → キャバ嬢を口説いてる！
• バグを修正した → キャバ嬢をアフターに連れ出した！

第1位 ねこ

もはや殺伐としたプロジェクトにはこれが必要なんじゃないかと思うくらい ほのぼの感あふれるメタファ。

• バグを見つけた → あっ三毛猫見つけた！
• バグを修正している → いま、三毛猫とじゃれてる！
• バグを修正した → 猫いなくなった！

まー 職場ではなかなかできないと思いますが、 もしやってみた人いれば連絡ください♪

「企画と開発のボーダレス化へ Day1」

今回の勉強会は「企画と開発のボーダレス化へ」。 もうテスト～開発も飛び越して、マーケットの話までやっちゃうTEF道は面白すぎるｗ 講師はCJM（カスタマージャーニーマップ）の勉強会のときにゲストで来ていた内城さん。 今回は2回シリーズのDAY1「インプット編」です。

内城さんはこれまでに200以上の製品開発に関わっているみたい。 もうそれだけですげぇ！！

ワークショップのお題はTV！どんなTVがこれから求められるのか。 お題だけで超楽しそう！！

まずは内城さんからコンセプトのお話。 コンセプトって分かりにくいので、大ヒットしたシャンプーを具体的な例として説明してくれました。 「コンセプトとは、市場で優位なポジションを築くため、どんな価値に重心をかけるか示した約束」 いやー なるほどって感じですね。そして言葉のチョイスがオシャレ。 逆に何でもやるはコンセプトではない！といってました。激しく同意ですｗ

今回のワークで使う思考のフレームワークはとてもシンプル。 「自社の強み」 × 「生活者・市場の潮流」 という二つの観点から新しいTVを考えていきます。

ポストイットとペンを持ちながら、生活者や市場の潮流についてのデータを聞きながら どんどん書き留めていきます。30枚くらいは書いたでしょうか。 面白いキーワードも出てきます。ほんの一部ですが紹介します。

• 働きながら余生
• 多世帯社会
• コダルト
• 晩婚晩産化
• 育ジイ育バア
• 女性のオス化
• 生涯独身 男性20%

その後、そのポストイットをグループでまとめて、キラリと光る何かを探していきます。 自分達はユーザー側から、「孤独」というキーワードを見つけて、双方向にやり取りできるような新製品のタネを考えました。 もう一つの方向はテレビの形を変えたらどうかという技術の方からの視点で鏡のように丸だったり、水槽に映すと面白いかもというアイディアが出ました。

参加者から「ターゲットユーザーを絞るということは、他のユーザーを捨てるということではないのか？」という質問がありました。 「捨てるというより、尖らせていくイメージです。ユーザーのさらに奥にある困りごとや感情を掴むことができれば、最終的には他のターゲットにも波及していく」と言ってました。 ルンバの例で、最初は忙しい家族向けだったのが、掃除が大変な老人に好評になったというのを聞いて、なるほどと納得しました。

帰り際に内城さんにマーケティングでオススメの本とかありますか？と聞いたところ、、、 「本ではなく、ヒットしているものについて考え抜くことが重要です」といわれてそれも感動しましたｗ

あっという間の2時間でした。 次回のDay2を楽しみにして、それまで世の中の製品を色々見ていこうと思います。

TEF道イベントの勝ちIBURIの会 ーテスト設計コンテスト優勝記念ー

TEF道イベントの勝ちIBURIの会 ーテスト設計コンテスト優勝記念ーに参加しました。

テスト設計コンテストというテストエンジニアの最高峰を決める戦いがあります。 http://aster.or.jp/business/contest/finals.html

そこで優勝した北海道のチームSTUDIO IBURIを招いて、優勝の秘訣を聞きました！ 結論を言っちゃうと、「すごい良かったので他の地域でも是非どうぞ！！」って話です。 3人組みなので、交通費*3くらい。都合10万くらいでいけると思います。

せっかくなのでなかなかなかなか明らかにならない3人の話も書いておきます。

• みずのり：現職は花屋さん。前職はマネジメント、テスト、モデリング、TOCが得意。
• MAQ ：現職は薫製屋さん。空いた時間でエンジニア。テスト、コード両方いけるがテスト好き。
• せーの ：モデリング、コードが好きだが、テストに足を踏み入れた。冷静に見えて熱い男。

いつものように自分がグッときた事を書いておきます。

グッときた事１

品質特性とか既存のフレームワークではなく、顧客の仕様書から言葉を拾い出して丁寧にモデリングしている。 顧客ドメインのモデリング、テスト設計が導出されていた。 ここらへんはDDD（ドメイン駆動設計）の思想が見えた。

グッときた事２

色々な図（ビューといっている）を出しているが、リポジトリは一つであり、見せ方が違うだけというアプローチ。 達成ビューは顧客向け、などこの図は誰のためというのがしっかり考えられている。 変更も考慮していて、astah*というUMLのツールを使って各ビューを作成している。 ここらへんはRDRA（らどら）の思想が見えた。

グッときた事３

クラス図を上手く使ってテストカタマリーを作っている。 is-aとhas-aの関係や、テストの目的、どんなテストをするのかが、一目で分かるようになっている。 ここらへんはクラス図の特性をうまくアレンジしていると感じた。

グッときた事４

プロセス自体もウォーターフォールのように一つずつ完全に決まってから次の工程に行くのではなく、スパイラル的に回して完成度を高めていくやり方。 ここらへんはRDRAやDDDやVSTePと一緒のアプローチ。色々な見方を回すことで足りない箇所を補完していく。

グッときた事５

チームメンバーがそれぞれの役割をこなしている。 特にテストにどっぷり使っていないせーのさんに分かるように説明してもらうことで、花屋と薫製屋の考えも整理されていったとのこと。 そしてそれぞれをリスペクトしているがイイネ！！

最後にせーのさんにモデリングとは何ですか？と聞いてみました。 せーのさん「モデルとは要約力である！」 DDDの増田さんのワークで聞いたフレーズだと思ったけど、今回の経験に裏打ちされた重い言葉でした！！ ※せーのさん的には増田さんからパクったわけではないと主張しているが、ただのツンデレだと思われｗ

まとめると「変なコンサルにお願いするくらいなら、この３人を呼んでみて」って話です。

最後に優勝おめでとう！！北海道から優勝チームが出てくれたってことは意義あることだと思います。

ついでにこの話をより理解するためのトピックは･･･

• DDD 対話のあたり https://www.slideshare.net/masuda220/part2-7569648
• RDRA http://k-method.jp/1_rdra/1_1.html
• DDD+RDRA https://www.slideshare.net/masuda220/rdra-ddd-agile
• ゆもつよメソッド https://www.slideshare.net/yumotsuyo/ss-71502350
• 品質特性（250xxシリーズ）
• DFD
• UML

Fearless Change の導入事例

アジャイル札幌のイベントでFearlessChangeの訳者の一人であるヤフーの山口鉄平さんにFearless Changeのお話＋ワークをしてもらいました。 アジャイル、そして自動テストをヤフーではどういう風に導入していくかという生々しい事例を聞ける良い機会になりました。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

山口さんは普及/改善の担当者ですが、やらせる権限はないとのことです。すなわちチーム自身がやる気にならないと改善が進まないとのことです。 山口さんが新しい技術を取り入れるときの問題点は、以下の分け方をしているようです。

• 技術そのものが知られてない
• 技術導入の必要性や効果が知られていない
• 普及の活動計画が求められるものの立てられない
• 技術に懐疑的で抵抗がある

それぞれについて、山口さんが意識しているパターンを例示してもらいました。 毎日色々な人と話したり、困ってたら助けたり、上の人とネゴを取ったりと地道な活動をコツコツとやってるという印象でした。

ワークはグループ毎に自分達の問題点出しとその問題点に対するパターンの提示を実施しました。 More Fearless Changeも含めた63パターンを見ながらワイワイやるのはよい練習になると思います。 これはパターンワークショップと呼ばれているものです。

自分がグッと来たパターンは以下の3つです。

• [22:種を撒く]
• [34:ちょうど十分]
• [48:将軍の耳元でささやく]
  

今回のイベントで心に残っているフレーズは･･･

• ぶっちゃけると普及の計画は立てにくいｗ
• 導入時は成功させることが絶対条件なので、確度が高いチームで実施する。[16:イノベーター]
• 改善の前後のデータを確認して、成長を数値としても実感してもらう。
• 普及活動は勝てば官軍なので、ホームランではなくヒットを狙う。[2:小さな成功]
• 偉い人からもジャッジができるように導入の意義をデザインする。[28:経営層の支持者]
• 社外の人の話を聞いて、やってみよう！って思う人もいる。[27:著名人を招く]
• あまり説明しすぎない。[34:ちょうど十分]
• なかなか普及しないラガードの人は必ずいる。
• 一気に普及するタイミング（キャズムを超えるタイミング）があった。そのときはカンバンがドッと増えた。
• 実際にはパターンをナチュラルに使えるようになる必要がある。

パターンの知識と実践力＋コミュニケーション能力が求められると感じました。 少しずつでも使っていけたらと思います。

※ カード形式（英語版）のパターンはLinda Risingさんのページに載っています。 http://web.lindarising.info/Fearless_Change.html

※ 川口さんはA4*2枚にまとめてくれています。 http://kawaguti.hateblo.jp/entry/20140228/1393522489

※ Fearless Journeyというゲーム形式でパターンを覚える方法もあるようです。 https://www.slideshare.net/kdmsnr/fearless-journey

# 17.3.2 Fearless Journeyについて勘違いしてたので修正しました。

エッセンシャル思考 読了

牛尾さんのブログで紹介されていたエッセンシャル思考を読みました。

simplearchitect.hatenablog.com

自分なりに要約すると･･･ 近頃は選択肢が多い時代。 その中から本質的なものを選び、大部分の不要なものを切り捨てる必要がある。

何が自分にとって重要かをどうやって選ぶのか、 どうして切り捨てることが出来ないのか、が書かれててグッときました。 特に牛尾さんのブログにある"Be Lazy"が凄く気に入っているので、こういう思考法は必要だなぁと改めて感じました。

この本にはグッとくる言葉が一杯だったのでまとめておきます。

"自分で優先順位を決めなければ、他人の言いなりになってしまう" p27

"選択の機会が増えすぎると、人は正しい決断が出来なくなるのだ" p33

"やることを減らしたほうが生産性が上がる場合もあるのではないか？ p59

"一旦所有してしまうと失うのが怖い。「授かり効果」という心理的なバイアスのせいだ" p183

"今やっていることを試験的にやめてみて、不都合があるかどうか確かめるのだ。（逆プロトタイプ）" p192

"本人が解決すべき問題を肩代わりするのは、人助けではない。その人は問題を解決しようとしなくなり、余計に問題から抜け出せなくなってしまう" p209

"人間のモチベーションに対してもっとも効果的なのは「前に進んでいる」という感覚である。" p246

"「本当に重要なのは何か？」それ以外のことは全部捨てていい。" p295

個人的には超お勧めの本です。

エッセンシャル思考 最少の時間で成果を最大にする

探索的テストとスクリプトテストの併用パターン

昨日FBに探索的テストの話を書いたら、コメントくれた人が色々な使い方を言ってくれたのでちょっとまとめてみました。
イメージで語らずに具体化すると違いが出て面白ですね。 『探索的テストはスクリプトテストと併用できる』って言ったら、テストクラスタの人は『それは同意！』っていうと思うけど、具体化すると結構違うんですよね～

[2016/04/08追記] スクリプトテスト：テスト設計を事前に行い、テスト手順まで明確にドキュメント化し、その手順に沿ってテスト実行をするテスト。

Aタイプ

Aタイプは最終的にスクリプトテストの結果として全体的なエビデンスが残り、探索的テストで弱いところのバグが出せるので 『エビデンス残したいけど、バグも出したい人』向き。スクリプトテストは全体が対象なのでスクリプトテストの作成、メンテナンスに時間がかかる可能性がありそうです。

Bタイプ

Bタイプは最終的にスクリプトテストの結果として全体的なエビデンスが残り、それとは別に探索的テストを実施し、バグを出します。 ソフトウェアがボロボロの可能性がある場合はスクリプトテスト終了時に開発側に戻せるため、探索的テストの時間が有効に使えます。 探索的テストの範囲は事前に絞れないので、その分時間がかかる可能性があります。

Cタイプ

Cタイプは全体的なエビデンスは残りませんが、短時間で弱い箇所を把握し、その箇所に対してがっちりスクリプトテスト（テスト設計）を行います。 探索的テストを先に実施するので、開発へのフィードバックはDタイプと同様に一番早いと思います。

Dタイプ

Dタイプは期間はBタイプに比べると、期間が短くて済むというメリットがあります。 ソフトウェアがそこそこの出来だと確信している場合、かつ担当者が複数人いる場合はBタイプよりもDタイプを選択したほうが、納期の点でメリットがありそうです。

探索的テストの文献一覧

探索的テストの勉強会用のコンテンツを作っていて、 文献を調査していたらこんな感じのがありました。 名前は有名だけど、日本語の本は少ないなぁ～って思います。

探索的テスト

高橋 寿一
知識ゼロから学ぶソフトウェアテスト 【改訂版】4章
http://www.amazon.co.jp/dp/4798130605

高橋 寿一
探索的テストってなんですか？ - JaSSTソフトウェアテストシンポジウム PDF
http://www.jasst.jp/symposium/jasst14kyushu/pdf/S3.pdf

井芹 洋輝 (@goyoki)
探索的テスト入門 (SlideShare)
http://www.slideshare.net/goyoki/ss-34292539

James Bach
General Functionality and Stability Test Procedure
http://www.satisfice.com/tools/procedure.pdf

James Bach
Exploratory Testing Explained(v1.3 4/16/03) PDF
http://www.satisfice.com/articles/et-article.pdf

James A. Whittaker
How to Break Software: A Practical Guide to Testing (英語) ペーパーバック – 2002/5/9
http://www.amazon.co.jp/dp/0201796198/

James A. Whittaker
Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design (英語) ペーパーバック – 2009/8/25
http://www.amazon.co.jp/dp/0321636414

※一部抜き出したバージョンがmicrosoftのサイトにあります。
https://msdn.microsoft.com/ja-jp/library/jj620911(v=vs.120).aspx

Elisabeth Hendrickson
Explore It!: Reduce Risk and Increase Confidence With Exploratory Testing (英語) ペーパーバック – 2013/2/28
http://www.amazon.co.jp/dp/1937785025/

Cem Kaner
A Tutorial in Exploratory Testing
http://www.kaner.com/pdfs/QAIExploring.pdf

セッションベースドテスト

James Bach
Session-Based Test Management
http://www.satisfice.com/sbtm/

Jonathan Bach
Session-Based Test Management
http://www.satisfice.com/articles/sbtm.pdf