『なりきりみわキット』をリリースしました

11月29日に福岡市で開催された JaSST'19 Kyushu で @m_seki が唐突に告知した『なりきりみわキット』について紹介します。誕生秘話？についても書きました。

なりきりみわキットとは？

@miwa719 がよく使う言葉（みわ語録）を２時間おきに通知するiOS向けキットです。たとえばこんな言葉です。

• 書いてあるテストじゃバグ出ないよね
• よし！
• これはダメなやつだ
• そうなの？

使い方は自由。みわ語録が通知されたら小さな声で音読して安く「みわ」になりきるのもよし、あなたのそばに「みわ」がいるような気分でお仕事するのもよし。言葉の意味、背景を想像してみるのも面白いかもしれません。

設定方法

本キットは iOS のカレンダーアプリ（iCalender）を利用しています。
iPhone → 設定 → パスワードとアカウント → アカウントを追加 → その他 → 照会するカレンダーを追加 → サーバに 719.druby.work を設定して「次へ」を選択。SSL接続できませんと表示されたら「続ける」を選択。以下のような画面になったら「保存」してください。カレンダー（本日）にみわ語録が設定されます。

解除方法

追加したカレンダーを削除してください。
iPhone → 設定 → パスワードとアカウント → 照会したカレンダー → 追加したカレンダーを選択 → アカウントを削除

自分の思考を変化させるスパイスアプリが欲しかった

製品開発中にミスや問題は起きるという前提で、わたしはその兆候や違和感（おかしさ）をできるだけ早くつかまえたいと思っています。そのために自分の思考の持っていきかたを意識的に矯正したり"無意識"を意識的に使おうとしています。でも現状に満足していません。ドメイン知識のように学んで覚えていけるものはどうにかなるのでいいのですがこれはちょっと違う。うまく言えないけど自分がそのときに考えてないことを考えたいし思いつきたいのです。自分の思考に一味加えて変化をうながしてくれるようなスパイスアプリが欲しい！と思ったのがきっかけです。

思考を変化させるための言葉（スパイス）をたくさん登録しておきランダムに選んで Apple Watch に通知する。そのときの自分の思考にスパイスをふりかけてテストを動的に変えていくのです。うまくいくかわからないけど面白そうでしょ？

技術顧問が一晩で作ってきた

スパイスアプリの構想を技術顧問*1に話したら一晩で「２時間おきにフレーズを配信するカレンダーのサーバー」を作ってきて自慢されました。自分でアプリを作るつもりで iOS のメモ帳とリマインダーを developer.apple.com でせっせと調べていたので唖然としましたね。しかもわたしには思いつかないかっこいい実現方法だったので二重に悔しい！！

どのような仕組みで動いているかを解説してもらい「スパイスとなる言葉は自分で書いてー」と言われたのですが、動作確認用の言葉として書いてあったのがたまたま「みわ語録」だったんですね。これはこれで面白いのでは！となり『なりきりみわキット』が誕生しました。

で、ソースコードを見たら９時から１７時までの間はランダムに言葉を選ぶように作ってあるのですが１７時だけは固定の言葉「もうやめなよ」が配信されるようハードコーディングしてある……。これは「みわ語録」ではなく普段わたしが言われている言葉です……。*2リアルタイムでこれを言われている「わたし」になりきれると思います。

おわりに

『なりきりみわキット』について紹介しました。サーバーは現在改良中です。土日は仕事しないので配信しないように直そうと思います。「みわ語録」だけでなく「あのチーム」でよく使うフレーズも登録しておこうかな。設定も解除も簡単なので興味のある方は試してみてくださいね。

*1:@m_seki

*2:１７時すぎになってもテストしていると「もうやめなよー」「１７時すぎましたよ？（帰らないんですか？帰っていいんですよ？むしろ帰ってほしいという意味）」と言われる

サディスティックミワテスト（ステッカー）を作りました

サディスティックミワテスト（ステッカー）が欲しい！とのご要望があり、自分でも欲しかったので キングプリンターズ で作りました。*1

個人用なので100枚もあれば十分だなと思っていたのですが、200枚でも300枚でも価格がほとんど変わらないんですね。

価格の一例（円形ステッカー）

100枚だとなんだか損したような気持ちになってしまって、多いよなぁ…と思いつつ200枚作ったら見本用ステッカーが＋70枚ついてきました。270枚もどうするんだ！！

というわけで、ほしい方には手渡しでプレゼントします。イベントなどでわたしを見かけたら「ステッカーほしい！」と話しかけてくださいね。

ステッカーの大きさはこれくらいです（直径50mm）

ステッカーを製作する前に 無料サンプルセット を請求しました。紙の質感や手触りなどを確かめたり仕上がりがイメージできるので安心です。とてもよいサービスだと思いました。今回のステッカーもサンプルのステッカーを参考にしっとりとした質感の光沢を抑えた「マットPP」というもので製作しました。*2

kingprinters.com

miwa719.hatenablog.com

*1:正しくは技術顧問 @m_seki に発注しました！

*2:どうでもいい情報ですが、ステッカーの背景色は愛車のボディーをイメージした色（アマルフィホワイト）になっています。だから真っ白ではないのだ。

若手開発者（プログラマー）と読書会をはじめました

５月に社内の若手開発者（プログラマー）から「テスト設計技法を学びたい。できれば体系的に」と相談されたのをきっかけに、書籍『ソフトウェアテスト技法ドリル』の読書会をはじめました。この記事では読書会をはじめるときに決めたこと（伝えたこと）と、２か月やってみて思ったことをメモしておきます。あと『ソフトウェアテストの練習帳』を使ってみたのでそれの感想も！

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

読書会をはじめるときに決めたこと（伝えたこと）

本を読むことを主目的としない

単に本に書いてあることを音読し、わたしがたまに補足して、巻末の演習問題を解くのではなく、テスト設計技法を学びながら実際の開発（テストを含む）について考えたり、話し合う場にしたいと思いました。このやり方だと１冊読み終えるのに半年はかかるのと、読書会がうまくいったらどうなるか？のイメージ（＝普段の開発の中で読書会で話したことを思い出し何かのヒントになる）を伝えました。

担当制にしない

章ごとに担当を決めて担当になった人が当日講師役になって進めていくスタイルは、講師になった人が事前に予習しなければならず大変なのでやめました。…というのは建前で、今回の状況だとどうみてもお前が講師だろ！て感じだったのでそれを回避しました。

宿題にはしない

宿題があると時間的にも気持ち的にも負担になりますよね。例えば、章の最後に演習問題が２問あるんですけど１問だけみんなでやって、もう１問は次回までに各自やっておきましょう、ということはしない。

無意識だったけど「しないこと」を決めていたのだなあ。

読書会を２か月やってみて

週１回開催（１時間／回）で８回実施しました。この本は第６章まであるのですが、現在第２章まで読み終えたところです。

• そうだろうなと思っていたけど、若手開発者（以降、Aさん）も普段の開発の中でテスト技法（同値分割や境界値分析）を使っている
• Aさんも「自分が普段やっていることに名前がついている」ことが分かってきたみたい
• 本を読むことで「いつこの技法を使うのか」「どのように考えていくのか、またそれでよいとする理由」を自分の頭の中に取り込むことができる。これまでなんとなくやっていたことが（これでいいんだな）と思えるようになるのは、精神衛生上とても良いことだと思う
• 区切りのいいところまで音読し、自由にディスカッションしている*1
• 気になった文章を取り出し「これはどういうことを言っているのか」「この技法の考え方は実際の開発の中だとどこで使われているのか」そこからさらに設計、実装方法にブレークダウンしたり、過去に見た（聞いた）不具合などを話している
• 結論を出したり章ごとにまとめるようなことはしていない（その場で話したことが全て）
• この本は技法だけでなく「ソフトウェアテストの7原則」「248日問題」など、知っておいてもよいことがさらっと書かれている。Aさんに聞いたら「知らない」というのでその場で簡単に紹介している*2
• Aさんとは開発してる製品が全く違うので、同じドメイン（医療機器）であっても原理的、構造的な違いから、似たような機能であっても気にするところが変わってくるのが面白い（自分の思考を広げるネタとして使えるので、こういう話を聞くのが好きです）
• １時間やるとかなり疲れるけど、週１回なので続けられそう

『ソフトウェアテストの練習帳』の感想

『ソフトウェアテストの練習帳』はソフトウェアシンポジウム 2019 東北に参加した際にお土産として頂いたものです。一般の書籍ではないので、以降の感想は練習帳を持っている方とこの練習帳の製作に尽力された方々向けになります。

これ #jassttohoku で頂きました
ソフトウェアテストの練習帳です！

・同値分割と境界値分析(11問)
・状態遷移テスト(9問)
・デシジョンテーブル(6問)
・組合せテスト(8問)
・総合問題(3問)

解答例だけでなく解説（どこに着目しどのように考えるのか）も載っていて素晴らしい pic.twitter.com/p1s21tdPRl

— miwa (@miwa719) 2019年6月1日

『ソフトウェアテスト技法ドリル』の第２章まで読み終えると、この練習帳の同値分割と境界値分析（１１問）が解けるようになります。さっそくやってみました！

• １時間で２問解きました（１問目：４０分、２問目：２０分）
• 問題を解く上で考えなくてよいこと（制約）が書かれているので、考える範囲が適度にしぼられ、その結果、対象にしている技法（今回は同値分割と境界値分析）に注目して解くことができました
• 問題が文章だけ（構成図や画面例がない）というもの同じで、書いてないことで有効な制約になっていると思いました*3
• あえて制約をつけないで問題を解いてみるという使い方もできそう
• 問題を解いてるときに解答例、解説が見えない（次のページになっている）のが良いです（自分で見えないようにするのは案外ストレスがかかるものです）
• 問題の横に書き込めるように？たっぷり余白があるのですが、何度も使いたいので練習帳には書き込まずホワイトボードを使いました
• この問題に対する答えはこうだろうというよりは、自分ならどんなテストをしてみたいか、なぜそれをしたいのかを自分の言葉で話すようにしています
• 自分で出した答えと解答例を比べて同じだと、やはり嬉しい気持ちになりますね
• １問目を解いたときに「代表値」について読書会ではそれほど触れなかったのに気づくことができました。そこで「都道府県を選ぶときの代表値」を例題にしてディスカッションしました
• 解答例だけでなく丁寧な解説もついているので、その答えにたどり着くまでの過程を自分の思考と照らし合わせて確認することができるのがよいですね
• １問目と２問目は同じような解説が載っています。対象が同値分割と境界値分析なのでそうなるんですけど、やりようによってはわざと見せ方（解き方）を変えることも可能だと思ったのですが*4、おそらく同じような解説の方が読み手が混乱せず、安心して問題を解くことができるので、正しいことを同じように繰り返すのは大事なことなんだと思い直しました*5
• 問題を解いていくことで「同値分割と境界値分析とはこういうもの」をより実感することができますね
• Aさんは本で学んだ通りのお手本になるような解答をしたあと、さらに実装方法をホワイトボードに書きながら、自分ならこの対象としている値の元になるデータはfloat型を使うかもしれない、そうなると値を求める時に差分をとって比較するようなことをすると思う。なぜ差分をとるのかは前に値をそのまま比較して失敗した（丸め誤差と桁落ち）ことがあるので…のような話をしてくれました*6
• このような話が出てくるきっかけになる練習帳の問題、素晴らしい！
• 老眼の人にも優しい組版だと思いました（フォントや文字の大きさや行間など）

同値分割と境界値分析の問題はあと９問あるので、次回の読書会からしばらく練習帳を使うことになると思います。この練習帳を作ってくださった方々のお顔を思い浮かべ感謝するとともに、これからも楽しみながら解いていきたいと思います。ありがとうございました。*7

note.mu

追記（2021.11.16）

『ソフトウェアテストの練習帳』は、JaSST配布版から加筆・校正され、一般書籍『ソフトウェアテスト技法練習帳 〜知識を経験に変える40問〜』として技術評論社より出版されました。

ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～

追記（2022.09.29）

来月『ソフトウェアテスト技法ドリル』第２版が発売されるそうです。赤ドリル！

表紙が赤くなりました。
赤ドリルと呼んでください。
クラシフィケーションツリーメソッドが追加され、GIHOZを紹介して、章末の問題を半分以上新しくしてリンク切れを直して、、、などなど。リニューアルしています。 https://t.co/Q6rs4GHIbF

— あきやま🌰 (@akiyama924) 2022年9月28日

*1:読書会ではなんでも話してほしいので、率先してわたしがなんでも話すようにしている。Aさんもなんでも話してくれるようになってきた。自分の仕事で解決できなくて困っていることとか。

*2:その後、Aさんは自分でボーイング787の248日問題、497日問題、36時間問題などを調べていた。

*3:うっかり画面例を書いたらいろいろ気になってしまい大変なことになった。

*4:思ったというか期待しちゃった…！JaSST Tohoku 実行委員のみなさんに対する期待値がものすごく高いんだわ。

*5:３問目以降の問題は見ないでこれを書いてます。

*6:こういう話が好きです。

*7:練習帳の表紙にもなっている仙台『蔵の庄』のごぼう天、美味しかったのでまた食べたいなあ。

「無効にする」という言葉は案外むずかしいのかもしれない

「無効にする」という仕様でプログラマーとテスターが違うものを想像した話です。開発中の些細な出来事ですがツイートするには長すぎるのでこっちにメモしました。

ある日のこと 

ある画面に表示しているスライダーコントロールを触っていたら、おかしな現象に気づきました。Trackの部分をマウスの中ボタン（ホイールボタン）でコロコロしたら、値の増減が正しく行われる時と行われない時があるんですね。

説明上、スライダーコントロールの部品の名称を載せたかったので docs.microsoft.com .NET.Framework の Slider Class の図を直接リンクしました（わたしたちが開発してる製品とは無関係です）

担当のプログラマーTさんとFさんにその現象を見せて、そのあとチームでどうするか話し「中ボタンは無効にする」ことになったのですが、翌日修正したものを触ったらなんかおかしい。

• Trackの部分を中ボタンでコロコロしても値は増減しない。無効になっているのでOK
• Trackの部分を左ボタンで長押しすると連動して値が増減する。元からあった仕様でこれもOK
• 左ボタンを長押ししたまま（マウスダウンしたまま）中ボタンをコロコロすると値が戻ってしまう。あれ？

例えば、値が１０の時プラス方向に長押しすると１１、１２、１３、１４と増えていきマウスボタンを離したときに増加が止まります。これは良いのですが、長押ししながら中ボタンをコロッとすると１０（長押しする前の値）に戻ってしまう。

中ボタンは無効にすることになったので、長押ししながら中ボタンをコロッとしても何もせずに無視するが、わたし（テスター）が期待した動作でした。直しきれてないコードがあって中ボタンのイベントが発火したのかなと思いました。…にしてもどう作るとこうなるんだろう。

さっそくプログラマーTさんとFさんにその現象を見せたら「そうなるように作ってます」と衝撃の言葉が！えっえっどういうこと？と聞いてみたら「中ボタンは無効にすることになったので、中ボタンが押されたら前の状態に戻してます」とのこと。無効＝取り消し＝それまでの操作を取り消す意味で捉えたのか！なるほどー。*1 

結局、中ボタンを押しても無視する（何もしない）ことになったのだけど「無効にする」という言葉は案外むずかしいのかもしれない。今後「無効にする」が出てきたら無効とはどういうことか、どう動くのか（どう動かないのか）を具体的に話そうと思います。

*1:前の状態に戻すにはある時点での状態をどこかに記録しておく必要があるので作るの大変だったのではなかろうか…

バグが報告されたときにわたし（テスター）がやってること

バグが報告されたときにベテランプログラマーSさんがやってること（コード修正以外）

①見つかったバグに関連するチケットAを探す
②チケットAで何をTestしたのか確認
③なぜそのときにバグを見つけられなかったのかを考える
④チケットAに不足していたTest（今回のバグを検出できるテスト）を追加

— miwa (@miwa719) 2019年5月8日

こちらのツイートですが、思いがけずたくさんの方に見ていただきソフトウェア開発（特にテスト駆動開発）への思いやご意見を伺うことができました。ありがとうございます。

この記事では「バグが報告されたときにベテランプログラマーSさんではなくわたし（テスター）がやってること」をメモしておこうと思います。

自分以外の誰か（以降、同僚）がバグを見つけたときにあなたは何をしていますか。個人的に大変興味深いテーマですが、バグを見つけるための手法やプロセス、バグを見つけたあとの報告の仕方（バグ票の書き方など）と比べて取り上げられることが少ないように思います。もしかしたら当たり前すぎて話題にならないのかもしれませんが『当たり前にやってることに価値がある』と聞いたことがあります（これを書くモチベーションにしよう！）。

バグが報告されたときにやってること

以下にざっと列挙しましたが（★）は自分でバグを見つけたときにもやってることでした。消すのもなんなので載せておきます。（だいぶ書いてから気がついた）

• どのようなバグなのかを知る（★）
• どうやってそのバグを見つけたのかを教えてもらう
• バグを再現させてみる
• 自分ならそのバグを見つけられたかどうかを考える
• どんな風に作るとそのバグが起きそうかを考える（★）
• そのバグが起きるなら…（他のバグを探しに行く）（★）
• バグを見つけた同僚を褒める

どのようなバグなのかを知る（★）

うちのチームは面白いバグや重大なバグが見つかるとザワつくことが多く（何かが起きたらしいぞ）を感知したプログラマーやテスターが発生源に集まってきます。そこで見つけたてのバグを再現方法も含めて披露してもらうのですが、バグそのものの現象を知るには一番早くて確実な方法ですね。

朝会の中で（昨日そんなバグが見つかったのかー）とはじめて知るものもあります。現象自体はなんとなく想像できるものが多いのですが、分からなかったらその場で聞いて教えてもらいます。嫌な現象は起きてないけど今の実装だとまずい（いつかアプリケーションがクラッシュする）というものも報告されます。

これらのバグを修正していく過程でどんどん明らかになっていく「バグの原因（どこをどう間違ったのか）」「何を実装したときにこのバグが入ってしまったのか」「どこをどのように直すのか」に耳を傾け、またそれに伴うディスカッション（その修正方法だとこういうケースでダメなのではないか etc ）も合わせ聞いたうえで、徐々に「こういうバグなんだな」が分かるようになります。*1

どうやってそのバグを見つけたのかを教えてもらう

これは操作手順のことではなく、なぜそんなことを試してみようと思ったのか、何を見ておかしいと思ったのかです。思考側（きっかけ、動機）ですね。

• 前に開発していた製品でこんなバグを見たことがあったので
• 画面の更新が一瞬遅くなったからあれ？と思った
• 処理が遅すぎて（退屈で）やることがないので押せるものを押してた
• チケットを ”クラッシュ” で全文検索して気になるものをやってみた
• いつも同じデータで試していて問題を見つけられなかったことがあったので
• 見た目はこんな画面構成だけど、内部的にはデータを二重管理しているから…

これを教えてもらうと、同僚が知っていることや経験してきたことや考えていることを（断片的ではありますが）自分のものにすることができます。例えば、これまで見てきたバグや自分自身の失敗談、いま何に注目し、何を心配しているのか、テストのやり方や得意なこと、こだわりや癖など。それを自身の開発（テスト）に活かすのです。これはオススメです。*2

毎朝、昨日見つけたバグやバグではないけど気になることを（チームを超えた）テスター同士で交換するのだけど、話を聞いたテスターがそれに関連するような（または似たような観点で）バグを見つけてくるのはおもしろい現象だなと思っています。一度や二度ではないから、偶然ではないと思っています。

— miwa (@miwa719) 2018年11月14日

ただ、実際に自分で経験したことではないので揮発性というか時間の経過と共に忘れてしまうことが多いです。そのことに気づいてからは専用のメモ帳に書いておき、ときどき読み返しては自分の脳にせっせと書き込んでいます。

バグを再現させてみる

先ほど ”朝会ではじめて知るバグも現象自体はなんとなく想像できるものが多い” と書きましたが、バグが直ったことを確認するときのために（このバグは自分の手で再現させて自分の目で見ておかなきゃ！）と思うものがあります。

• タイミングを狙うような操作が必要なもの
• 操作手順が複雑なもの
• 現象自体が分かりづらいもの

これらのバグは練習して確実に再現できるようにしておきます。例えば「この処理の一瞬の隙間を狙ってボタンを素早く二回押す」といった操作です。”現象自体が分かりづらいもの” というのは「動作がもっさりする」「画面がパシャパシャする」「ボタンが一瞬チカッとする」のようにオノマトペで表現されるものが多いです（うちのチームだけの特性かもしれませんが）。自分で再現させる前にバグを見つけた同僚に目の前で再現させてもらったり、どこがどうおかしいのか説明してもらうこともあります。パシャパシャとはこの現象を言ってるのだな、とかね。プログラマーが優秀で翌日にはバグが直ってしまうこともあるので（見ておかなきゃ！）と思ったらすぐやるようにしています。

自分ならそのバグを見つけられたかどうかを考える

同僚が見つけたバグを「自分なら見つけられたかどうか」を考えます。

• 自分ならその操作を試そうとしただろうか
• 自分ならその状況を思いついただろうか
• 目の前にそれ（バグ）が現れたときにおかしいと思えただろうか
• 設計や実装を想像できただろうか

遅かれ早かれ「自分でも見つけられたかな」と思うものはそれでよしとします*3。そうでないものは、そのバグを見つけられないのはなぜか、自分でも見つけられるようになるにはどうすればよいかを考えます。

• これから開発（テスト）するときに注目すべき点（観点）としてXXXを自分の中に取り入れよう
• バージョンごとにそんな複雑な仕様になってることを知らなかった → その仕様に詳しいNさんに教えてもらう
• この特殊な画像データを使うとおかしさに気がつきやすいのか！ → 使う
• 設計や実装を知らないとそこが怪しいなんて絶対想像できない → プログラマーSさんに説明してもらう*4

どんな風に作るとそのバグが起きそうかを考える（★）

これは自分でバグを見つけたときにもやってることなので省略します。

こんなバグ(現象)を見つけた！みたいなツイートを見ると、どんな風に作るとそのバグ(現象)が起きそうか考えてしまいます。

考えたことの当たり外れはどうでもよくて、あれこれ想像するのが楽しくて好き。

— miwa (@miwa719) 2018年6月21日

そのバグが起きるなら…（他のバグを探しに行く）（★）

これも自分でバグを見つけたときにもやってることなので省略します。

バグを見つけた同僚を褒める 

「これはいいバグ！」「よく見つけたなー」と思ったら褒めます。わたしも誰かに褒められたら嬉しいですもん。最近だと入社２年目のエンジニアKさんが「丁寧にテストしないと見つからないバグ」を報告していたので褒めました。Kさん「だんだん慣れてきたらこんなに（丁寧に）テストしなくなるかもしれません」と馬鹿正直に言うので「１０年後もその丁寧さを忘れないでーーーー」とお願いしました。

テスターNさんがとてもいいバグを見つけたのを朝会で聞いて嬉しくて「すごい！すごいわ〜」と言いながら思わず拍手してしまいました。拍手いいよね。気分が上がる。流行らせたい👏

彼女は半年前に隣のチームにJoinしたんだけど、最近めきめきと腕をあげてきてる。素晴らしいなあ。

— miwa (@miwa719) 2018年11月29日

同僚じゃなくても褒めてますね。

ある操作での画像の歪みを見つけるなんて @suginoy さんすごいな！

こういうのは気にしない人は気にしないと思う。画像としては分かるからね。だから気がつくのすごい。

— miwa (@miwa719) 2018年9月6日

おわりに

バグが報告されたときにわたし（テスター）がやってることをメモしました。同僚がバグを見つけたときって今の自分には無いものに気づいたり、足りないものを学習したり、他人の経験（暗黙知を含む）を自分のものとして取り入れることができる良い機会だと思っています。

テスト駆動開発

ソフトウェア・テストの技法 第2版

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト293の鉄則

新装版 達人プログラマー 職人から名匠への道

*1:分かったことが「本当に正しいかどうか」は気にしすぎないようにしてます。もちろん正しいのが理想なんですけど、自分で（こうなんだな）と思えればまずはよし。あとから分からないことが出てきたり疑問に思ったときにまた調べたり誰かに聞いたり、間違いに気がついたときにエラー訂正します。

*2:自分でバグを見つけたときも、なぜそんなことを試してみようと思ったのか、何を見ておかしいと思ったのかを話すようにしています。

*3:見つけられたとは思うけどそのバグはもうすこし早い段階で見つけたかったな…と思うものがあります。何かの順番が間違っているのでしょうね。

*4:Sさんにもどのようなバグを見つけられるようになりたいのかを伝えます。Sさんはそれを踏まえてどう作られているのかの種明かしや秘密を暴露してくれるはずです。

とちぎRuby会議08 食に関するメモ #toruby

6月29日に開催した『とちぎRuby会議08』でわたしが担当した『食』に関するメモです。

ランチセッションのお弁当

今回のお弁当は『石窯イタリアン アンジェロ』さんに作ってもらった。

５月にアンジェロさんと打ち合わせをした。お弁当のボリューム感について悩んでいそうだったので「参加者の８割くらいは男性で２、３０代くらいの方もわりと多いかな……」と言ったところ「唐揚げのようなガッツリしたものがいいでしょうか？」と聞かれたので、前回（一昨年）のとちぎRuby会議07の『からあげ弁当』の話をした。（ランチセッションで用意した『からあげ弁当』の影響でパーティーのお料理が大量に余ってしまう事案発生。詳しくはこちら）

…かと言って少なすぎるのも困るんですけど……いい感じにお願いします…！とおまかせ（丸投げ）した結果が、こちらのお弁当。

１品１品、丁寧に作ってあるのわかる。彩りも豊か。夕方からはじまるパーティーのお料理とかぶらないように作ってくれた。気にしていた量も（全体的に見て）少なすぎず多すぎずだったと思う。というのは、パーティーのお料理が不足することもなかったし、大量に余ることもなかったから。

コーヒーマシン

• アンジェロさんにお借りした。とても良かった！
• ダークチェリーという豆だった。飲みやすかった。
• 何人かの方からレンタル料金を聞かれた。お料理なども全部こみでお願いしたので単品の金額はわからない。
• 開場前に設置＆使い方を教えてもらった。前回と同じ機種だったのに使い方をすっかり忘れていた。
• 適宜、水とコーヒー豆を補充して、コーヒーかすを捨てれば良い。簡単だけど１年後はまた忘れてると思う。
• 挽きたてのコーヒーは香りもいいし美味しい。売れ行きもよかった。
• 講演の最中にガーーッと豆を挽く音が響くの非同期処理ぽくて、好き。

用意した飲み物

• ペットボトル（２リットル）２８本
• 前回（８月開催、参加者数は今回とだいたい同じ）「１８本用意してほとんど残らなくて、あと５、６本あってもよかった」→ 今回増やしてみたけど１０本くらい残った。足りないよりは良い！
• お持ち帰りしてくれたみなさん、ありがとうございます。
• ウィスキンソン ジンジャーエール（辛口） ２４本
• パーティー用に冷やしたものを持ってきてもらった。
• 未開封の３本は @arton さんに持っていってもらった。ありがとうございます。
• そうそう、アンジェロさんがクーラーボックスで大量の氷を持ってきてくれた。冷たいほうがいいでしょうからって。
• 氷を用意するのは思いつかなかった。アンジェロさんさすがアンジェロさん。

軽食つきのパーティー

• ケータリングも『石窯イタリアン アンジェロ』さんにお願いした。
• お料理の搬入などはスムーズで特に問題なし。３０分くらいでセッティング完了。
• 今回のお料理もとても美味しかった。見た目も美しいし、食べやすいように工夫してある。
• いつも写真を撮り忘れるんだけど今回は忘れなかった。

• 毎回お料理の名前が分からなくて（あの美味しかったあれ）みたいな感じになっていたので、今回はお願いしてメニューをつけてもらった。
• 名前が分かるとこんなツイートができるのだ。名前重要。

とちおとめのパンナコッタ、美味しかったなー（2回目）#toruby pic.twitter.com/d1XLcCKd7Y

— miwa (@miwa719) 2019年6月30日

• ワインのコルクがこんな風に使えるなんて！（きれいなコルクは捨てないで取っておくか）
• ワインは赤と白１本ずつ持ってきてもらった。
• 白ワインは氷で冷やしておけばよかった。クーラーボックスに残っていたんだよね。氷。いま気がついた。
• 前回のメモによると「赤ワインはわりと早いうちになくなった。白ワインがグラス１杯分残った」→ 今回はほとんど残ってた。@ardbeg1958 さんがいなかったからかな。面白いな。
• ワインは @emorima さん @youchan さんに持っていってもらった。ありがとうございます。
• アルコール類の準備はよく分からないので（飲まない人もいるし）今までどおり、飲みたい人が休み時間に買いに行くスタイルでよいと思う。
• @you_ssk さんが日本酒２本を差し入れしてくれた。ありがとうございます。
• アンジェロさんから『電気式石窯ピザ』使用のご提案があった（素晴らしい）
• 電源事情がクリアできれば挑戦したい…！焼きたてのピザはどう考えても美味しいに決まってる。

• 軽い気持ちで『電気式石窯ピザ』を調べてみたら１００万円くらいする。びっくりした。
  
  
  
• Lightning Talks は途中で短めの休憩時間を入れると良かったかもしれないね。お料理を取りに行ったり、コーヒーを淹れたりできるから。

その他

• テーブルにお土産のお菓子がたくさん並んでいた。ありがとうございます！
• お菓子の包装紙を使っていい感じに飾る方法を覚えた。@suginoy さんありがとうございます。セロハンテープの端っこを折り曲げておくとはがすとき楽になる小技も教えてもらった。

• @takkanm さんのお子ちゃまがかわいくて癒された。会場のうしろに並べた椅子でお昼寝してた。@m_seki のブランケットが大活躍！

• 閉会後の片付けをたくさんの方に手伝ってもらった。ありがとうございます。 

追記（2019-08-18）

当日の本会の様子が『るびま』に掲載されました。思い出し用に貼っておきます。

magazine.rubyist.net

うちのチームのプログラマーはなぜテストがうまいのか

うちのチームのプログラマーはテストが好きかどうかは分からないけど「これよく見つけたなー」と思うようなバグを見つけてくるからテストがうまいと思う。で、なんでうまいのか考えているのだけど「毎日１時間、システムレベルのテストをしている」のが、うまくなる要因の一つなんじゃないか。

— miwa (@miwa719) 2019年6月24日

医用機器（自社製品）のソフトウェア開発に従事して、あと数年で３０年になります。いろんなチームに所属し、多くの開発者と一緒に仕事してきましたが、現在所属しているチーム（うちのチーム）のプログラマーはテストがうまいです。プログラマー時代の自分と比較してもそう思いますし、『ソフトウェアテスト』という側面から製品開発を考えられるようになった今の自分から見てもそう思います。いいバグを見つけたなぁ…（素晴らしい）と思うことが多々あります。

うちのチームのプログラマーはなぜテストがうまいのか。いくつかの要因が思い浮かびましたが、その中でも「毎日１時間、システムレベルのテストをしている」のが大きいのではないかと考えました。この記事では、タイトルから期待される結論（なぜうまいのか）を書くつもりはないのですが（ごめんなさい）システムレベルのテストをすることで得られそうなことをメモしておこうと思います。プログラマーがこんなにテストしてるチームはこれまで見たことがありません。これを１５年以上もやってるってすごくないですか？*1

プログラマーが毎日システムレベルのテストをしている 

うちのチームのプログラマーは全員、毎日１時間「テストの時間」が割り当てられています。テストの時間は朝会終了後の10:00〜17:00まで。好きな時間に勝手にやるスタイルではなく予め決まっていて、時間割表（テストPC * 6時間）はびっしり埋まっています。プログラマーAさんは10:00〜11:00（テストPC-001）、プログラマーBさんは14:00〜15:00（テストPC-002）のように。プログラマーCさんがテストPC-003の前に座ったら、わざわざ時計を見なくても（ああ、もう16時か）と分かるくらいに常態化しています。

この記事での「システムレベルのテスト」は「テストPC（ほぼほぼ実機環境）の前に座り、お客さまが使うのと同じようにソフトウェアを触るテスト」のことです。JSTQB*2で定義されている「システムテスト」とはすこし違うかもしれません。

テストは『本日のおすすめテスト』*3に従って実施します。テストケースに書いてある通りに操作して期待する結果になるかどうかを確認し、テスト結果を登録します。時間がきたら（テストが途中でも）おしまいです。そんなにビックリするようなことはしていないと思います。

システムレベルのテストをすることで得られそうなこと

• 自分が開発していない製品、機能そのものを知ることができる
  わたしたちの製品はそこそこ大きいこともありソフトウェアに関する部分だけでも複数のチームで開発しています。ひとつのチームが複数の製品を同時に開発しているので、プログラマーがシステムレベルのテストをするということは、自分以外のプログラマーが作った製品、機能も当然触ることになります。

• お客さまがどのように使うのか（ワークフローなど）を知ることができる 
• 実機での処理速度感
• システムレベルで見たときのバックグラウンド処理（特に他のチームが開発しているもの）を知ることができる
• 実際の現場に近いユーザーデータ環境がどういうものかを知ることができる
  開発PCだと少なめのデータやお決まりのテストデータで試すことが多いのではないでしょうか。
• 意地悪テストの残骸を見ることができる
  テストPCはテスターも使っています。テストPCを触るということはテストの残骸（データや操作履歴など）を目にすることになるので、どのようないじめ方をしているのかを知ることができます。
• 開発履歴を知ることができる
  テストケースからその機能の開発履歴（開発日記）が簡単に辿れるようになっています。どのような経緯で開発（設計、実装）してきたのか、関わったプログラマーは誰で、いつどんな変更が入ったのか、過去にどのようなバグが検出されたのか、どのように修正したのか…などがわかります。実際、開発日記を読みながらテストしているプログラマーの姿をよく見かけます。 

テストケースに書いてないことも試している

先ほど「テストケースに書いてある通りに操作して期待する結果になるかどうかを確認し、テスト結果を登録します。」と書きました。でも「テストの時間」にプログラマーが検出したバグを見るとテストケースに書いてないことも試しています。テストケースを誤読して偶然見つけたものもありますが「これ、絶対バグを見つけにいってるでしょ」と思うものも多いです。どういう心境でテストしているのでしょうね。「テストの時間」はプログラマーの帽子を脱ぎ、テスターの帽子をかぶっているのでしょうか。

おわりに 

うちのチームのプログラマーはテストがうまい自慢と「システムレベルのテストをすることで得られそうなこと」をメモしました。毎日テストをしているからテストがうまくなる（訓練みたいなもの）とも思いましたが、それだけではないのも実は分かっていて、いつか言語化できたらいいなと思っています。

*1:中の人たちはこれがすごいことだと分かってないのもすごい。自分たちの開発にはこれが必要だと認識してやってる感じ。

*2:Japan Software Testing Qualifications Board

*3:膨大なテストケースの中から現在の開発の状況に応じていい感じにテストケースを選んでくれるレコメンドシステムがあります。@m_seki が作りました。