Googleにやられた話

12月24日。クリスマスイブ。 Googleのトップページには何かの平面図が載ってました。（全部で4種類）

会社の友達と印刷をして作ってみたら家が出来た。 可愛いっ！！

でも緑の平面図だけがどうにも分からない。皆さんは分かりますか？ 半円はクルっと丸めて木だろうなぁ～なんて予想して（笑

結果できたもの。。。 木がある小屋かな？

・
・
・
・
・
・

そして、今朝クリスマス当日・・・ 衝撃の画像がGoogleのTopページに！！

いやー Googleにやられました・・・ 答えを教えた会社の友達も「今年一番の驚きです！」と言ってました。 この半円を重ねるという発想はでなかったなぁ～ 答え分かると簡単だけど、これぞコロンブスの卵ってヤツでした。

悔しいので、昨日のものを使って新しいデザインの家を考案してみました。 こっちも意外に可愛い家ができました♪

クラス設計とテーブル設計のちょっとしたDiff

すごい久々のエントリですｗ デブ沙汰しています。

半谷さんからバトンタッチしました♪ マンガなので読みやすく、それでいて内容はグッと来るので是非見てください♪

このエントリ記事はDevLOVE Advent Calendar 2015の「Diff」11日目の記事です。

今回は今年実施したSQLアンチパターンの勉強のときに感じた違い(Diff)になります。

今までDBはメンテナンスが多くてキチンとSQLの勉強をしたことがなかったので、チームの有志であの t_wadaさんが監訳したSQLアンチパターン勉強することにしました。

その第3章を勉強してたときのことです。 「IDリクワイアド」といって、全てのテーブルに（何も考えずに）id列をつけてしまうというアンチパターンでした。 その中に列の名前付けの話が書いてあったのですが、例えばBooksテーブルの場合はid列よりbook_id列が推奨されるとのことでした。

一方、Bookクラスの場合、メンバ変数nameやidとはしますが、bookNameやbookIdとはしませんよね？ 昔オブジェクト指向を勉強したとき、Book.bookIdとなるとブックブックしちゃうので、だからBook.idとなるようにnameやidを付けるのですと書かれたのを見てなるほど！！と思った記憶があります。

そのことを思い出して、どうしてSQLの場合はid列ではなくてbook_id列が推奨されるのだろうと参加者と一緒に考えてみました。 その結果、テーブルは他のテーブルとも結合されるため、様々なテーブル間で一意になるように、idではなくbook_idと付けた方がいいということが分かりました。 idだとBooksテーブルのidもReservationsテーブルのidも見分けがつかないですもんね。 しかも2つのテーブルに同じ名前の列名がある場合はUSINGを使って簡潔に書けるとのことでした。

SELCT * FROM Books INNER JOIN Reservations USING book_id

SQLアンチパターンにはもしidとしてしまうと冗長なON構文を常に使う必要があると書かれています。

SELECT * From Books As b
INNER JOIN Reservations As r
ON b.id = r.book_id

ON構文は冗長である。 ｶﾞ━━Σ(ﾟДﾟ|||)━━ﾝ 普通だと思ってた･･･

普通にSQLを書いている人にとっては、あたりまえだね～と思われるかもしれませんが、メンテばかりしていると気づきにくいものです（言い訳ｗ）

ある日DBの新規設計を任されたら、id列としていたと思いますので、やっぱり素振りって大切だと再認識しました。 個人的にはクラス設計とテーブル設計のDiffを感じたところだったので今回のエントリとして書かせてもらいました。

www.amazon.co.jp

魅力的品質と品質特性

この記事はソフトウェアテストあどべんとかれんだー2014の12/16の記事になります。

今日は今年の心に残っているエピソードの１つを紹介し、それについて考えたことを紹介したいと思います。

あるとき、TEF道のお世話役の安達さんと品質特性の使い方の話をしていたときに、「製品やサービスに必要な品質を考えるときに、いきなり品質特性を使うとグッとくる製品はできないよ」ということを言っていました。

これを聞いて自分はハッとしました。Σ(ﾟДﾟ；)

テスト設計コンテストに参加したときは網羅を意識して最初から品質特性を用いていました。また実際の業務でも品質特性に基づいて初めから品質の定義をすることが多かったと思います。でも確かに最初から品質特性を使うとヌケ・モレは防げますが、製品・サービスのコアになるべき機能が全くトガらずに、ありきたりなものになる可能性がありそうです。

この問題を解決するため(*1)に、狩野モデルを使ってこの製品・サービスのコアになるトガった機能とそれ以外の機能に分けて考えてみます。

• 魅力的品質　　：製品・サービスのコアになるトガった機能
• 当り前品質　　：上記以外の機能

順序的には、トガった機能にあたる製品やサービスの魅力的品質をまずしっかりと考え抜き、その後、当り前品質を考えるときにモレ・ヌケがないように品質特性を使うといいのですね (*・Д・)ﾅﾙﾎﾄﾞﾈ-

ところで本当に魅力的品質かどうかはどうやったら分かるのでしょうか？

机上で品質特性の一覧とにらめっこしていても答えはでないと思います。 COOKPADの高井さんの発表（*2）から引用しますと、「要求事後性：ソフトウェアが要求を満たしているかは、ソフトウェアを使わないと判断できない」ということです。もちろん特定のドメインのソフトウェアに おいては簡単に使ってもらうことが難しい可能性もありますが、Webサイトやスマホアプリなどのソフトウェアは使ってみることでフィードバックを得ることができます。

リーン・スタートアップでいうところのMVP（Minimum Viable Product）で作り込む機能も、魅力的品質（と思っているモノ）に属する機能とその魅力的品質が成立するための必要最低限の当たり前品質の機能が対象になると思います。そしてMVPのリリースとフィードバックを繰り返していくことで、ユーザーにとっての本当に魅力的品質かどうかを判断していくのですね。

特に目新しくはないと思いますが、自分にとっては品質特性の使いどころを改めて整理する良い機会になりました。

次回はきょん君お願いします♪

*1 @snskが提案している品質特性自体に重みをつけて品質モデルを定義するという方法でも解決できそうです。詳しい説明はAndroidアプリテスト技法（秀和システム）を参照のこと。

*2 JaSST’14東北発表資料 https://speakerdeck.com/takai/cookpad-and-test-automation

2014/12/18 追記

安達さんからコメントありましたので、そのまま転記しておきます。

私のコメントの真意は「いきなり品質特性を使うとそれに一律はめ込んで満足する＝特徴的な要素が尖らずに平坦にしてしまう人が多いんだよね」です。十分に使いこなすスキルを持っている方は大丈夫ですが、そうでない方が使うと特徴のない平坦な結果ｗｗを出しがちなのでこのコメントになっています。それを防止する一つの手段として、①品質特性を使わずに特徴的な特性を明確にする（尖らせる）→②そのあと何か忘れているモノがないかを確認する意味も含めて品質特性を使う、というやり方を紹介しました。

とちぎテストの会議03 参加レポート

とちぎテストの会議03、通称とてか03に梅ちゃんとまなべーと参加した。

とてか02に参加したときにも思ったのだが、"日常"というのがテーマになっているので、開発者とテスターのお互いが普段どう考えているか分かりやすい。とてかは開発とテスターが融合するイベントになっていると思う。

何より雰囲気が暖かいのがイカしてます。

「いかす！」のために大事だと思う４つのこと / 湯本さん

日本HPの湯本さんが日常生活を振り返り、イカしていると思うことを話してくれた。 本編ではまさかのタイムアウトということで、続きが懇親会という2部構成（笑 http://www.slideshare.net/yumotsuyo/toteka3

定期的なトライ

テストケースを作ると同じ組織でもバラバラになる テストケースを作るときにルールを作る メンバー間の相互理解を促進する環境を作るのが重要。 そしてテストプロセス全体を知ることでテスト技法の使いどころや自動化に必要なことが分かる。

人の知見吸収

本のままの知識ではなく、現場に適応するのが重要である。
特に自分が知らない新しいシステムに本気で対応することで湯本さん自身の勉強になる。

目的再考

近頃は大学でテスト（ゆもつよメソッド）の研究を実施している。
なんでやっているか考えてみたところ以下の３つが出たとのこと。

• 論理的思考の訓練
• 刺激
• 資格

無駄をやめる

この基調講演の依頼を受けたとき、１週間の自分の時間を考えてみたら、色々ムダが多くて、愕然となった Σ (ﾟдﾟlll)

感想

普段のセミナーやシンポジウムではなかなか聞けない湯本さんの日常を垣間見ることができた。その中で自分が気になったことは２つ。
１つめは湯本さんのコンサルではこうやりなさい！ではなく、如何に組織が自立的に回るようになるかということにもフォーカスしているようで「テストの目的」にあたる合意形成をキチンと取っているのがいいと思った。意味無いと思っているテストは誰もがやりたくないもんね。
２つめは何にでも真摯に向き合うこと。例えコンサルでも大上段から構えずに、自分なりの考え（テスト設計など）を持って現場とガチでぶつかるってカッコいいなーって思う。コンサルもQAもそうだけど外からいうだけだと現場は動かないことが多いと感じるし。しかもその忙しい中で博士号を取ろうと頑張っているなんて…
湯本さん… イカしてます！！

忍者式テスト 中島さん ＠ledsun

気になっていた忍者式テストの発表。
事前に少し調べていたが、実例はいつも楽しみ♪
http://www.slideshare.net/ledsun1/03-39903732

状況

あまり変更したくないコード（ヒドいコード）に機能追加するために、リファクタリングとして様々なパターンを適用し分割する。GUIからテストをしたかったのだが、自動化している暇がなかったので、毎日手動でテストを実施する忍者式を選択した。チームメンバーは中島さん一人。

方法

優先度のついたテストケースを用意し、毎日それを上からテストしていく。新しいバグが出たときはケースを上に追加する。そのことで枯れたテストはだんだんやらなくなり、バグがあったケースが何日間かテストされることになる。テストにかける時間は３０分以上。

結果

忍者式テストを導入し実施したところ、新しいバグが見つかってきた。忍者式テストには、どうやらCheckingだけではなく、Testingの要素（*1）もあるのではないかとのこと。

感想

あるなんとか動くコードがあるときに、コードに極力触ることなくテストで抑えようというテストダケガンバルパターンがある。それとは別にコードカラミナオスパターンがある。今回の中島さんの例はコードカラミナオスパターンでかなりガッチリやっている感じ。ここらへんの考え方は咳さんがズバッと切っている記事がある。

中島さんの忍者式テストを自分なりに考えた結果、少し抽象度の高いテストケースをチャーターとした「探索的テスト」に近いと思う。ある軸になるテストケースを決めておいて、そこから派生するケースを毎日コツコツ実施していく。同じことはやっていないので未知のものを発見するTestingの要素が出てくるんだと思う。毎日実施する忍者式の最大の弱点は「飽きること」だと思っているので、前の日とちょっと違うことをやることでテスト実施者（＝今回は中島さん）のモチベーションは維持されるみたい。 完全にフリーの探索的テストだと証拠が残りにくいなどデメリットがあるが、中島さんの忍者式テストだと抽象度の高いケースは残るので忘れることはないのではないかと思った。
この仕組みは結構面白いし、色々使えそうだなぁ〜

中島さん… イカしてます！！

※1 ChekingとTestingの違い
Checking 既知の情報を確認する行為 Testing 新しい情報を探す行為
参考）JAMES BACH'S BLOG http://www.satisfice.com/blog/archives/856

中島さん語録

名言があったのでまとめておく。

• テストは健康な状態でやらなければならない
• テストをやめる基準は感性
• 毎日テストしないと怖い

イカついパネル

お題
http://d.hatena.ne.jp/m_seki/touch/20140930#1412073967

聴衆全員がパネリストになるイカついパネル。全然イカつくなくてワイワイと盛り上がったｗ 最初にmiwa719さんから説明でもやもやしたらOKっていう説明があった。懇親会で関さんとも話したが、色々な考えがあるってことを気づくのが目的にする場合はまとめずに参加者に考えてもらうのがいいなぁと思った。

ワールドカフェ

今回の使用したタイマーの実例を使って、どうしたら良いかみんなで考えるワールドカフェ。タイマーの付加機能としてアニメーションの機能を実装したが、イベント２日前に全く動かなくなって不安になってしまった。明日が本番の場合どうするか？！
開発者とテスターが入り交じっているイベントのため、両方の意見が結構出ていた。自分が覚えているだけ書いてみる。

• バックアッププランを用意する
• タイマー機能だけリリースすればよい
• そもそもタイマー機能だけだったら、このタイマーの意味はない。踊るから意味がある
• このイベントではバグが出たら逆に盛り上がる
• 不安の元は何だろうか？明らかにする
• 言語の問題が不安に影響しているかもしれない
• メインのシナリオはテストしておく
• タイマーのテストは長いので面倒である
• 落ちても再起動すればOKかどうかをテストしておく
• 拍手を誘導するというタイマーでもOK
• 運営スタッフが自分たちで作るから意味がある
• LT用のタイマーでも機能的には代用できる
• 踊るという魅力品質はいいが、当たり前品質のタイマー機能に影響あるのは困る

リンク等

まとめ
http://togetter.com/li/729139

懇親会で小井戸さんが発表したLT ← これまた熱い… http://www.slideshare.net/koido1961/ss-39837146

参加報告 toshimana's diary http://toshimana.hatenablog.com/entry/2014/10/05/130224

うーん とちぎ熱いですね〜
仙台も負けずに頑張らないとですね。
スタッフの皆さん、スピーカーの皆さん、参加者の皆さんどうもありがとうございました！
みんみんの餃子も美味しかったです♪

SWWDC 仙台iOS開発者勉強会#21 参加レポート

今年中にiOSアプリを一本リリースしたいと考えているんだけど、 ちょうど仙台iOS勉強会Swiftについての勉強会があったので参加してみた。
https://atnd.org/events/56274

ライブコーディング

仙台のホープ@ktanaka117さんによるHealthKitのライブコーディング。 デブなのでHealthには興味アリ。
ちょうどコードレビューを実施していたので、Objective-Cが詳しくないなりにも楽しかった。
blocks関連の循環参照のこととか、弱い参照、強い参照とか、勉強しないといけないんだなーと。
http://qiita.com/keroxp/items/68c80b9c9fa8da9147c3

そしてこのSwiftのサンプルサイト。 現時点でもこれは凄いし、さらに増えていくらしい。。。
https://sites.google.com/a/gclue.jp/swift-docs/home

SwiftとAzure

続きまして、MicrosoftのMVP様こと@nnasakiさんからSwiftとAzureの連携を教えてもらった。
http://www.slideshare.net/YamamotoMasaki/microsoft-azureswift

ダウンロードすると、簡単なサンプルもついているし、DBを意識しないでいいって楽ですね～ 開発時、テーブル意識しないでカラムを自動追加。 実際のサービスインのときには自動追加無しにしてリリース。 小さく早く出すためには良さそうです。

画面サイズ

続きまして、@totottiさんによる画面サイズ。 iPhone4、iPhone5、iPhone6、iPhone6Plusというキビシイ戦いを感じることが出来ました。

• 現状はiPhone5用のアプリはiPhone6や6Plusでは拡大モードで動作しているものが多い
• これからはAutoLayoutに対応していかないといけない

最後に参加者の皆さんと話してて、SwiftとObjective-Cについて以下の意見を貰った。

• Objective-Cは最悪Cなら動作するという安心感はある。
• Swiftは今風なので、これから始める人はいいんじゃないかな？
• Objective-CはC++との相性がいいので、C++のライブラリを作る人はObjective-Cの方がいいかも。
• SwiftからはC++コードをObjective-CでWrapすれば読み込める
• Swiftの方はまだコンパイラにバグがあるかもしれない

そして@CortYumingさんのTLから衝撃的事実が･･･

iPhone アプリ作るなら swift じやなくて Obectivej-C だなぁと思った。

— Takashi ITO (@CortYuming) 2014, 9月 27

さらに若手のホープ@ktanaka117さんからこんな言葉が･･･

まずはObjective-CでなくSwiftでも大丈夫だよ！というのを自らをもってして証明せねばぐぬぬ

— ダンボー田中 (@ktanaka117) 2014, 9月 27

忍者式テストを調べてみた！

10/4(土)に栃木で行われるとちぎテストの会議03（とてか）の参加申し込みをしました。 http://d.hatena.ne.jp/tochigitestnokaigi/ 今からイカしびりてぃを高めて行こうと思います。

ところで、招待講演の忍者式テストとはこれイカに･･･ パッと聞いたイメージでは、テストでバグ出たときに変わり身の術とか、徹夜のテストでおなか減ったときにスイトン食べるとかそういうイメージがありますね。 でも実際は分らない・・・ ということでちょっと調べてみました。ニンニン。

JaSST東京'04で関さんが発表した資料
http://jasst.jp/archives/jasst04/pdf/A7ah.pdf

忍者式テストをやってみた@ledsun
http://ledsun.hatenablog.com/entry/2014/07/16/073122

ledsunさんとm_sekiさんとの「忍者式テスト」についての対話
http://togetter.com/li/266752

どうやらこれは栃木のKentBeckこと関さん※1が発明したテスト手法のようです。
イカは関さんの資料より抜粋しました。

どんどん成長していく受け入れテストを忍者のジャンプの修行の木に例えた忍者式テスト！ 細かいところまで手が回らないと割り切ったときにどのようにアプローチしていくのか参考になります。 しかもこの方法間違いなくアジャイル/XPと相性がいいですよね！ 毎日ストーリーベースのテストを実施し、ストーリーを少しずつ増やしていく。 見方を変えるとSDD（Story Driven Development）ってところでしょうか？ しかし！そんな名前にせず"忍者式テスト"にした関さん、、、凄いっす。

とてか03ではイカのことに注目して@ledsunさんの招待講演を聞きたいと思います。

• ストーリーの工夫
• エンジニアが飽きないような工夫
• ストーリーの履歴の管理
• 対象ソフトウェアの規模感
• 探索っぽい要素の有無

ということで、とてか03楽しみにしてます♪

※1 関さんはJaSST'14東北の基調講演でお話してもらいました！

とちぎテストの会議

JaSST'14北海道レポート①

早速、JaSST'14北海道のレポート①を書いてみた。

和田さんの基調講演

目指すものは「動作するきれいなコード」 by ロン・ジェフリーズ
これはTDDを実施している開発者もテストエンジニアも同じ思い。

テスト駆動開発とは？

和田さんによるテスト駆動開発の説明があった。
今回はTDDを全く知らない人も参加者にいるので、かなり丁寧な説明をしてくれたと感じた。

• コードを書かないとわからないことが多い
• 綺麗な設計をしてから！ではなく、動かしてからきれいにする
• 重要なのはテストがある状態でのリファクタリング。

FizzBuzz問題のデモ

実際にFizzBuzz問題をt_wadaさんがデモしながら、TDDの話をしてくれた。

• 仕様をToDoリストに変更する。→ 個人的にはポイントだと思う。
• テストクラスの名前にはTestxxx と xxxTestの2流派ある
• 日本語でテストのメソッド名を書く → 日本で開発している場合はかなり有用
• 初めての場合はテストコードはゴールから考えていく
• テストコードのテストは実装コード。お互いにテストしあう関係
• 実際にテストで値を入れることで気づくことがある
• 二つ目のデータが正しいコードを導く（三角測量）

三重ループ

Why 頻繁なリリースとデモ
What アクセプタンステスト
How ユニットテスト

TDDの導入効果

MSやIBMの論文の事例の紹介。

• TDDで欠陥は６割〜７割減る
• 実装時間は２割~３割増える

テスト駆動開発を導入することで、プログラミングレベルの
軽微なバグっていうのは無くなる。
TDDを実施した後で出るバグは本質的なバグ。それに対処する。

ユニットテスト自動化してれば品質大丈夫！っていう人が多いので、和田さんにズバっと言ってもらって嬉しいなぁ〜

テストは品質を上げない

体重計を買っただけでは痩せないように、
テストでは品質を上げることはできないので、
品質を上げるためにはコードを修正する必要がある。
テストはあくまでもキッカケに過ぎない。

これは…身をもって体験してるｗ
体重計に乗ってるだけじゃ全く減らないorz

改善を我慢しなくても良い

以前は動いてるコードは触らないということで品質を保っていた。  
今は自動テストがあるので改善（リファクタリング）を我慢しなくてもいい。  
対象のソフトウェアの動作が変わったら、テストが教えてくれる。

やっぱり「動作しているコードを触らない』という方針だけだと機能追加には耐えられないだろうなぁ。常にDRYを意識しながらコードを書いていきたい。。。

開発とテストの人はもっと一緒になろう

TDDだけやっていれば品質があがるかというとそうではない。  
やはり第三者の視点というのが必ず必要になる。  
開発の人とテストの人が一緒にやることでもっと良いものを作ることができる。

本来、開発者とテストエンジニアは共通の目標があるはずなのに、いがみ合っていることが多い。でもそんなんじゃいいもの作れないよね。

感想

今回のJaSST北海道は基調講演に和田さんをお呼びしたことで、開発者からみた品質、テストの話を聞くことができた。JaSST東北でも関さんに来ていただいたので、JaSST東北〜JaSST北海道は開発者視点のテストという流れが繋がった感があってちょっと嬉しい。
和田さんの最後のメッセージにもあるように、開発者はテストの方へ、テストエンジニアは開発者に近づいていく必要があると思う。そしてお互いが交流することで知識の移転が行われるんだろうなぁ。
TDDだけで品質を担保することはできないし、テストだけで品質を上げることはできないから。