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のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (16件) を見る
山口さんは普及/改善の担当者ですが、やらせる権限はないとのことです。すなわちチーム自身がやる気にならないと改善が進まないとのことです。 山口さんが新しい技術を取り入れるときの問題点は、以下の分け方をしているようです。
- 技術そのものが知られてない
- 技術導入の必要性や効果が知られていない
- 普及の活動計画が求められるものの立てられない
- 技術に懐疑的で抵抗がある
それぞれについて、山口さんが意識しているパターンを例示してもらいました。 毎日色々な人と話したり、困ってたら助けたり、上の人とネゴを取ったりと地道な活動をコツコツとやってるという印象でした。
ワークはグループ毎に自分達の問題点出しとその問題点に対するパターンの提示を実施しました。 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
個人的には超お勧めの本です。
- 作者: グレッグ・マキューン,高橋璃子
- 出版社/メーカー: かんき出版
- 発売日: 2014/11/19
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (15件) を見る
探索的テストとスクリプトテストの併用パターン
昨日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
Think Global Act Local ～北海道から世界へ～ 初音ミクの生みの親 クリプトン伊藤さんの講演
Think Global Act Local ～北海道から世界へ～ クリプトン・フューチャー・メディアの伊藤さん講演
今日は初音ミクの生みの親、クリプトン・フューチャー・メディアの伊藤さんが会社で講演してくれました！ 伊藤さんの落ち着いた声のトーンとは裏腹に、とにかく熱く、面白い話が聞くことができました。 用意された2時間はあっという間に過ぎてしまいました。 クリプトン・フューチャー・メディアは「コンテンツ」×「技術力」で勝負している会社で、音で発想するチームを目指しているとのことです。 http://www.crypton.co.jp/
特に注力して話していただいたのは、初音ミクの話。 音声技術×コンピューターミュージック＝歌唱合成技術 ＋ キャラクターということで 今までに無いキャラクターと結びついたボーカロイドが生まれたとのことです。
権利関係もかなり考えられたようで、世の中のクリエイターがつながりやすいように、 気持ちよく創作活動ができるようにと考えて仕組みづくりをしている感じを受けました。 伊藤さんは創作の連鎖～共感の連鎖/ありがとうの連鎖と言っていて、 言葉だけではなく、それを仕組みにしているのは凄いなぁと感じました。 また日本だけではなく、世界の人をターゲットにしているというのもグッときました。
初音ミクはその活躍する世界も広がってきているようで、 最近では世界ツアーも開催されている模様。 なんと！札幌でも4/5（火）にあるようなので、行ってみたい！と思いました。 世界中で満員御礼が続いていて、中国はわずか10分で売り切れたとのことです。 凄い！！凄いぞ！初音ミク！！
最近では札幌のクリエイターやスタートアップの人を応援する取り組みをしているようです。 ・雪ミク ・ミライスト カフェ ・シメパフェ ・札幌移住計画
伊藤さんの地元愛をヒシヒシと感じました！ やっぱり札幌いい街ですもんね～
最後に質問できる機会があったんだけど、 「最初の初音ミクのデザインはどうやって決めたんですか？」って聞いてみました。
伊藤さんの答えは、音楽のクリエイターが引かないようにコテコテの萌えではないデザインにしました、とのことでした。最後はなんとなく全体的にいいんじゃないかい？っていう雰囲気になったようです（笑
伊藤さん、企画してくれたHさん、本当にありがとうございました！！
ドラクエ風スキルマップ
あるとき突然『チームのキーマンが抜ける』というイベントが発生しました！
まあ会社という組織ではよくありますよね（苦笑
チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。
これもまさにゲーミフィケーションって感じですねぇ～
スキルマップを作る過程
元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。 これだけでもかなり盛り上がりましたッ！！ 以下は川口さんのオリジナルから変更したところです。
- 要件定義のスペシャリストとして、商人を追加。
- 旅芸人はマネージメントのイメージに変更
- スキルの方向を上方向に変更
- 盗賊のスキルレベルの見直し
- CやC++をイメージして文言を見直し
- 特性に対応するキーワードを追加
スキルマップを記述する
チームメンバーに実際に記述してもらったところ、通常の無味無臭なスキルマップより楽しくつけることが出来たとのことです。 まずはそれだけでも大成功ッ！！それとともに問題点がいくつかでました。
- 下のスキルはないが、上はあるなど、スキルが飛ぶことがある。
→そのまま素直につけてもらいました。 - 文言が2個あり、片方にしか当てはまらないときはどうするのか？
→そこまで厳密ではないので、今回はどちらかに当てはまればつけてもらいました。
これらの問題点に関しては次回以降の宿題になりそうです。
チームの現状とキーマンが抜けた後の状態を把握する
チームメンバーからのスキルマップを合成して、キーマンがいる現状とキーマンが抜けたあとのイメージを共有しました。 予想通り問題がありそうというのがはっきりと分かりました。（図はイメージです） 自分達は数も出していて、1人は赤、2人は黄色、3人以上は赤色にしてみました。 特にキーマンというだけあり、その人しかもっていないスキルが多いと思います。
やってみた感想
何はともあれ面白くできたのというのが大きいです。
スキルマップつけるのって面倒になること多いですもんね。
特にドラクエ風のスキルマップにすることで、戦士だけのチームを目指すのではなく、いろいろなスキルを持った人がチームに必要なんだよというイメージが伝えやすくなります。
そして自分達のチームの問題点を可視化できるのも効果が高そうです。
まずい状態をメンバー全員で共有できるし、次にどうしたらいいかという話に持っていきやすいと思います。
今回はキーマンが抜けた後の問題点を出したかったので、その前にアイスブレーク的な感じでこのスキルマップのワークを入れました。
とりあえず自分達のスキルマップをみんなでワイワイ作ってみるのをお勧めします。 意外に面白いですよ～
川口さんのオリジナルネタは日経SYSTEM（2015年11月号～）に載っていて、現在好評連載中とのことです。 特にキーマンの離脱に関連するところとしては、日経SYSTEM2015年12月号の「メンバーの離脱について考える」の節に詳しく載っていますので、ぜひ読んでみてください。
