CAT GETTING OUT OF A BAG

What the tester is thinking.

ベテランプログラマーとバグの調査をしたときのこと


これ、ツイートではさらっと書いてますけど、とても複雑な状況だったんですよ。非常に多くの入力項目があり、さらにROI*1 も設定できる。わたし自身、どの操作（入力）が引き金になったのか、予想もつきませんでした。すぐに、隣のチームのベテランプログラマーSさんを呼んで、現象を見てもらいました。*2 

プログラマーに状況を説明する

おかしな状態になる前に、どんな操作（入力）をしていたのか。たまたま、関係しそうな画面を４枚ほどキャプチャーしていたので、それを１枚ずつ見せながら、Sさんに説明しました。

miwa「次にこの画面ですけど、Aの値は、デフォルトの値が XX だったんですが、YY に変更しました。で、Bの値は、Aを変えたことで自動的に ZZ になったので、それを 1.4 に変更して、、
Sさん「うわあああ、ここに 1.4（小数点の値）を入れたんですね
miwa「入れました。小数点の値、嫌なんですか？
Sさん「嫌かも、というか、小数点の値はあまり試してません…


その後も

「きゃーーー、やめてーーー
「こわい、こわい、こわい
「これは、何が起きるかわからない


Sさんのリアクションは、控え目に言って最高でした。こういうのって（テスターにとって）ものすごく有難いんですよ。

  • プログラマーが「やって欲しくないこと、嫌なこと」を知ることができる
    わたしの脳内：ここは大したことしてないと思っていたんだけど、内部の処理は、想像以上に複雑なのかも。もしかしたら、Sさんもまだ不安なところがあるのかもしれないな。もう少し時間をとって、テストしたほうが良さそう。
  • プログラマーが「まだ試してないこと、試しづらいこと」を知ることができる
    こんなことを聞いたら（テスターだったら）とりあえず、すべての入力項目に、小数点の値を入れてみようと思いますよね。それから 1.4 以外の値は大丈夫なのか、数値を丸めているのだとしたら、どのような丸め処理をしているのか、有効桁数はいくつなのか、いろいろ気になってきます。

このような情報は、当然、設計ドキュメントには載ってない。だから大変貴重です。*3

どの操作が引き金になっているのかを探る

わたしがやったことを一通り話した後に、どの操作が引き金になっているのかを探りました。*4いま思うと、もうこの時点で「この現象が起きるのなら、どの操作（入力）が関係しているのか」が、Sさんにはある程度わかっていたんだと思います。話を聞きながら、Sさんの頭の中には、プログラム（コード）が浮かんでいたのでしょうね。


今度はSさんの話を聞きながら、わたしが手を動かします。ペアテストに似ていますね。

「まず、ここは関係ないはずなので、ここの設定は全部オフにしてみましょう
（カチャカチャ、ターン）
「はい、再現しますね（想定どおり）
「では、ここも関係ないと思うので、ここもオフにしましょう
（カチャカチャ、ターン）
「はい、再現しますね（想定どおり）
「この現象が出るのは、◉◉の値がおかしくなっている、ということなんです
「◉◉の値は、AとB、あとCの値が関係してるんですよ
「ということで、AとBとCの値を変えてやってみましょう
（カチャカチャ、カチャカチャ、ターン）
「再現しなくなりましたね。ということは…


すこしずつ条件を変えながら「これだ！」という操作（入力）に迫っていきます。いくつかのパターンを試しました。引き金になる操作を特定したのは、それから１０分後くらい。やっぱり早いわー。

今回のケースは、入力値だけでなく、操作順も関係していたので、再現手順を見つけるのが大変なバグでした。同じ値を設定しているのに、再現するときと、再現しないときがあるのです。こういうのは難しいですね。Sさんのナビゲーションがなければ、１時間かけても、たどり着かないかも…。*5

「実は、AとBに値を入れた後に、ある計算をしていて、ほら画面にも計算結果を表示してますけど、これ以外にもいろいろ計算してるんですよ。表には見えないんですけどね。裏でものすごい計算が走ってる。特にBね。だから、Bに値を入れた直後に、おかしなことになっているのかもしれないな。


わたしの脳内に「Bはヤバい、Bに注意」が刻まれました。こういう情報も、テスターにとっては貴重です。

Sさんの予想どおり、Bにある値を入れた直後に処理を実行すると、再現しました。Bにある値を入れた後に、違う項目（例えば C）に値を入れてから処理を実行すると、再現しませんでした。

こんなのを目の前で見せられると、プログラマーすごいなあ、これは真似できない、と思いますね。鮮やかでした。素晴らしかった！

ベテランプログラマーに共通する、ある行動

確信はないのだけど、前々から（もしかしてそうなのかな？）と思っていることがあります。それは「ベテランプログラマーほど、不安なところを包み隠さず、丁寧に教えてくれる」（傾向がある）ということなんですけど、今回のことで、うちのチームだけではなく、隣のチームでも観測することができたので（やはり、そうなのかもしれない）と思っている、今日この頃です。*6

おまけ

今回の「再現手順を見つけるのが大変なバグ」を説明するのに、簡単な画面を作りました。でも、文章で伝わりそうだから、いらなかったですね。せっかく作ったので、貼っておきます。（ラベルの枠のコーナーを丸くするやり方を覚えました！）

f:id:miwa719:20180805204133j:plain

プログラマーとお仕事をするということ

プログラマーとお仕事をするということ

 

*1:Region of Interest：操作の対象として選ぶ領域（関心領域）のことで、画像処理などで使われる用語です。

*2:ここのところ、隣のチームで絶賛開発中の「ある機能」をテストしている。

*3:この情報は、同僚のテスターや、隣のチームのテスターにも伝えます。

*4:Sさんがいちいち悲鳴をあげるので、観客が２名もついた。

*5:まあ、その前にうちのチームの誰かが、わたしの異変に気がついて、１時間もやらせてもらえないと思うけど。

*6:観測範囲がものすごく狭いので、気のせいかもしれません。書籍『プログラマーとお仕事をするということ』にも、そんなことは書いてなかった。

テスターと内部設計情報

大層なタイトルをつけてしまいましたが、先日 Twitter に連投したことをブログに残しておきたいだけのエントリーです。（すこしだけ、補足しました）  

 

 

 

 

 

 

 

 

今回ツイートしたのは「画面に表示する項目と内部変数の関係」ですが、このように「内部設計情報」を知ることで、心配事が変わる（テストが変わる）のは、わりとよくあります。（だからと言って、なんでもかんでも知りたい、という感じでもないのですが…）

どんなところの「内部設計情報」を知りたいと思うのか。すこし考えてみたのですけど、一つ言えるのは、テストが大変そうなところ（似たような項目が多いとか、何かの種類が多いとか、状態がたくさんあるとか）は、特に知りたいです。*1また、知りたいと思ったときは、すでにその時点で、２種類くらいのやり方を予測*2していることが多いように思います。

ただこれは、プログラマーがどのように設計したのか、を当てることを目的とした予測ではありません。ですので「内部設計情報」を知ることができないときでも、システムやソフトウェアを動かして得られる結果から、それを予測し、テストに活用します。*3

これは、テスターによく見られる習性なのでしょうか？
いつも使っているお気に入りのアプリでも、こんなことをしていますね。（以下のツイートを参照）

 

Amazon社のエンジニアに「内部設計情報」を聞くことはできませんので、動かして得られた結果から「内部設計」を予測しています。（これ、Safariでもうまく動かなかったのですが、そのうまく動かないっぷりがiPhoneアプリと同じだったので、ほっとしました。）

 

そうそう、秋山さんからこんなコメントをいただいたので、いつかお返事したい。

 

*1:例えば、接続デバイスが返してくるエラーの種類が５０種類あったとして、その５０種類のエラーコードをプログラムでどのように処理しているのか、とか。

*2:プログラマーがするようなガチなソフトウェア設計ではないが、それとセットで、こんな風に作っていたら、こんな確認をしておかないと、とやりたいテストのイメージも浮かんでいる。

*3:わたしたちは、非常に多くの組織、チームで製品開発をしているため、他の組織、チームが開発している部分の詳細については、知らないことも多いのです。

テストする順番を気にする

以前、ある方から「普段、当たり前にやっていることって何ですか？」と質問があり、その場では即答できなかったのですが、最近になって（これ、当たり前にやってることかも）と思うことがあったので、紹介します。

わたしは、テスターとして組み込み系製品の開発に従事しています。ですので、この記事は、その「テスト」に関して「当たり前にやっていること」のひとつになります。

f:id:miwa719:20180715141033j:plain

テストする順番を気にする

わたしは、１日の大半をテストに費やしているのですが「テストする順番」を、かなり（無意識に）気にしてるようです。ただ、急ぎでやらなければならないもの（緊急性の高いもの）は、先にやるので、ここでは除きますね。

どのように順番を決めているのか。その順番にしている理由、順番を決めるときの材料やシグナルなども織り込みながら、１日を３つに分けて紹介します。

  • 午前中
  • 午後１時〜２時
  • 午後２時〜６時 

午前中

問題が出たら嫌なところ、複雑なところをテストします。もうすこし具体的に書くと、こんな感じです。

  • 問題を見逃すと生命、自然環境に関わるようなところ
  • 問題を見逃すとお客様の業務に支障が生じるところ
  • 製品化の中でも特に重要な機能
  • 複数の機能が絡み合ってそうなところ
  • 過去に不具合が多く出ているところ
  • 他のチームにも影響がありそうなところ
  • 開発中に設計や実装が二転三転したところ
  • 担当プログラマーの顔が不安そうなところ
  • 担当プログラマーの顔は普通なのに、他のみんなが不安そうにしてるところ

朝会で脳内をウォーミングアップ

わたしたちのチームは、朝会（９時１５分〜１０時）で、チケットの読み合わせをしています。これをやることで、テスターのわたしも、今、開発してるものが、どんな状況にあるのか（どこが、なぜ、うまくいってないのか、昨日困っていたあれはどうなったのか、内部の設計や実装など）を知ることができます。同時に、今日からテストできるもの（昨日コミットされたチケット）もわかります。プログラマーひとりひとりの表情を見ながら、その言葉に耳を傾け、場合によっては質問し、テスト可能なチケットを整理しながら「テストする順番」を決めます。ソフトウェアは毎日変化しているので、それに合わせてテストも毎日調整します。

午前中に「問題が出たら嫌なところ、複雑なところをテスト」をするのは、いち早く重大な問題を見つけて、チームのみんなにお知らせしたい、のも理由の一つなのですが、それよりも（これは多くの方がそうだと思いますが）朝会の後のこの時間が、１日の中で最も脳内がスッキリしていて、冴えているからです。おかしさを見つけられる感度が、就業時間の中で最高のはず。おそらく身体能力も相当高い。*1

気分が乗らなくて後回しにしたテスト

その他にも午前中にテストするものがあります。それは、前日までに一度はトライしようとしたけど、挫折してやめてしまったテストです。

  • 思っていた以上に時間がかかり、途中で集中力が切れてしまった
  • テストするための準備が何となく面倒
  • テストする場所が極寒で風邪引きそう／徒歩で５分もかかる（しかも雨降ってる）

などなど。理由はいろいろありますが、要は、気分が乗らなくて後回しにしたテストです。人間だからそんな日もあるよね。

これは、もう自分で分かっていますからね、午前中にやらないとダメですね。今日も午後に回したら、また挫折します。これはもう仕事だから仕方ない、今日こそはやるぞ！と思ってやります。*2

午後１時〜２時

それほど頭を使わなくてもできるテストに充てます。例えば、画面に表示する文字（ラベル）の位置、色、メッセージなどの変更、アイコン（絵）の貼り替えとか。まあ、そんなところでも、あとから問題が見つかって（そんな作りになっていたとは！）となることもあるんですけどね。この時間帯は、どうしても集中力が低下してしまうので、自分自身のテストのミス（見逃し）も多くなります。人間だから仕方ない。だから、頭を使うような難しいテストや、混み入ったことは、極力やらないようにしています。

午後２時〜６時

上記に書いたもの以外をテストします。午前中の続きをやることも多いです。また頭が冴えてきますからね。乗ってきて過集中になるのも、大抵この時間帯ですね。そうそう、集中して物事に取り組むのは良いことですが、集中してること以外（外側）は「散漫」になっているんですって。それを聞いたときに（確かに、そうだわ）と思って、ちょっとゾッとしました。だから、集中しすぎないために１時間ごとに休憩するよう、心がけています。*3
また、午後５時以降に取りかかったチケットは（大丈夫だろう）と思っても close しないことにしています。これも「疲れ」から誘発されるかもしれないミスを防ぐためです。翌日にもう一度、軽く確認してから close します。（週末の夜にコミットしないのと、似てるかもしれませんね。）

全体的に気にすること

わたしたちは、複数の製品（バージョン）を同時に並行開発しているので、スケジュール（締め切り）を気にします。締め切りが早いものは、できるだけ先にテストできるように調整します。締め切りが遅いものは、重要な機能であっても後回しです。（例外はありますが）

それから、担当プログラマーが今日いるかどうかも気にします。例えば、テストできる状態にはなっているけど、今日は休暇でいないような場合は（内容にもよりますが）優先順は下がります。これは、もしテストしてクラッシュするようなバグが見つかっても、その場ですぐに見てもらえないからです。明日来るんだから、わざわざ今日テストしなくてもいいか、みたいな感じですね。

さいごに

普段、わたしが「当たり前にやっていること」のひとつ「テストする順番を気にする」を紹介しました。

いつも無意識にやっていることを、改めて見つめ直し、言語化したら、これまで見えてなかった「何か」が浮かび上がってくるのかな…と、淡い期待もあったのですが、そうでもなかったですね。本当に当たり前のことだったわ。*4

 

*1:視力とか、腕力とか、聴力とか。

*2:それでも、どうしてもダメなときは、同僚のテスターに「何時から一緒にやろう！」とお願いしている。もう逃げることはできないので、午後でも大丈夫。

*3:Apple Watchが教えてくれるので、少しは改善している。

*4:公開するのも躊躇うレベルですが、せっかく書いたので放流します。

テスターから見た「テストの合間にプログラミングする」

druby.hatenablog.com

この記事を読んだときに、この「テストの合間にプログラミングする」という感覚が、はたして読み手に伝わるのかしら、、と思いまして、テスターの立ち位置で、いくつかツイートしました。
今回はそれを引用して、さらに補足します。

2009年にも言ってたみたい。というかずっと言ってたけど記録が残ってるのは珍しい。


元の記事にも書いてあるように、咳マニアとか、咳フリークと言われる（または自覚がある）人たちにとっては、わりとおなじみのフレーズなのかもしれませんね。「テストの合間にプログラミングする」って、どのような風景を思い浮かべているのでしょうか。とても興味があります。 

バグを見つけたら、スッと立ち上がり、そのストーリーの担当プログラマーを探します。（うちのチームは『全員同席』なので、大抵すぐに見つかる）

miwa719.hatenablog.com

そのときのプログラマーのシチュエーションは、こんな感じです。

  • コードを書いてる（ひとりで）
  • ペアプロしてる（２、３名で）
  • 数人のプログラマーが集まって、小さなホワイトボードに何かを書きながら話してる
  • テストしてる（プログラマーも１日１時間、テストの時間があります）
  • すでに誰かに割り込まれてる

バグを見つけたら、と書いたけれど、ちょっと違和感があるようなとき（例えば、この操作をしたときだけ、反応が少し遅い）や、質問や相談ごと（こういうテストをしてみたいのだけど、どうやったらその状態が作れますか？）も、プログラマーに話しに行きます。

miwa719.hatenablog.com


「テストの合間にプログラミングする」の「テストの時間」は、誰かのテストで見つかった問題、疑問、相談について、割り込まれて作業するのも「テストの時間」であり、１日１時間のテストの時間だけが、プログラマーにとっての「テストの時間」ではありません。

そのような「テストの時間」が、１日にどれくらいあるのかは、人それぞれですが、うちのチームのエースプログラマーを見ていると、１日のほとんどが「テストの時間」なんじゃないかな。でも、プログラミングもしてる（ストーリーが仕上がってくるからね）。この辺は、元の記事にも書いてありますね。

（速い人ほど）多くの時間テストに関わっていることになる。


わたしは、これまでいくつかの組織、チームに所属してきましたが、こんなにテストに時間を使っているプログラマーがいるチームは、見たことがありません。

 

さて、今回この記事を書くにあたって、久しぶりに過去の記事を読み返しているのですが、こんなのも見つけました。プログラマーを褒めるためにも、割り込んでる！

miwa719.hatenablog.com

テスターなので、普段からかなり意地悪なことをするんですけど、それでも壊れない、不安定さを感じない、これは頑丈に作られているなと、テストしていて（これは、素晴らしい・・・）と、思う瞬間があるんですね。プログラマーが、様々なユースケースを想定した上で、丁寧に設計、実装してきたのが、分かるんですよ。そんなシステム、ソフトウェアの動きを目の当たりすると、これはもう、一言言わずにはいられない。ストーリーを担当したプログラマーのところに行って「こんな（ひどい）ことしたんだけど、ちゃんと動いてた！すごい！感動しました！」て、割り込むんですね。

「割り込む」という言葉は「無理に押し割って入ること」「横入り」のように、どちらかというと、悪いイメージや印象を持つことが、多いかもしれないですね。でも、うちのチームは「これ」が推奨されています。（とは言っても、他人の作業に割り込むのは、練習しないと出来ません。わたしも出来るようになるまで、数ヶ月かかりました。）

割り込まれたプログラマーは、コードを書く手を止めます。ペアプロも、設計レビューも中断します。うちのチームで「割り込み」は、優先度が高いものとして扱われているので、コンピュータの世界での、割り込み（インターラプト）「実行中の処理を中断して、優先度の高い別の処理をする仕組み」に、似ていますね。


そうそう、プログラマーだけでなく、テスター同士でも、お互いのテスト中に割り込んで、いろんなことを話します。

  • 昨日コミットされた◯◯だけど、さっきこんなバグを見つけたよ（目の前で見せる）
  • おおお
  • それが出るなら、これはどうかな（おもむろにペアテストがはじまる）
  • うーん（深く）触るのは、このバグを修正してからの方がいいかもね

  • ◉◉のテスト、シミュレータ環境では動いたけど、これ、実機環境でも確認したい
  • うんうん、ハードウェアの制御も絡んでくるし、タイミングが微妙に変わってくるかもしれないよね
  • じゃあ、午後、テストベイで一緒にテストしようか
  • OK


もちろん、テスターも（テスト中に）プログラマーに割り込まれます。

  • 昨日のバグが再現しないので、一緒にテストして欲しいです
  • ◯◯について、テストの作戦を立てたいんだけど、今からちょっといいですか？
  • ＊＊の件、直してみたんですけど、こんな感じでどうですか？（コミットする前に、プログラマーの開発環境で見せてもらい、動作確認することもある）

そう考えると、プログラマーにとっては「テストの合間にプログラミングする」だけど、テスターにとっては「テストの合間にテストする」ですね。（わかりづらい！）

 

「テストの合間にプログラミングする」を、テスターの目線で補足しました。うちのチームの開発風景と「テストの合間にプログラミングする」この感覚が、すこしでも伝わりましたら、うれしいです。

 

間違えたことを大切にする


これはバグだと思ったけど、調べたらそういう仕様だったとき、あなたはどうしてる？


f:id:miwa719:20171223135220p:plain

つい二、三日前にそんなことがあって、仕様だと分かったのは、Bugチケットを発行した後だったのだけど『そっ閉じ』しないで、チームのみんなに見てもらったよ。

"そういう仕様で作ったから、そうふるまうのは正しいよね"

と、認識を合わせた上で

"バグだと思ってしまったのは何故なのか？"

に、論点（興味）が移るのが、うちのチームの素晴らしいところ。（今回の記事はチームの自慢が目的ではないので、ああ、そうなんだね、くらいに読んでね。）

  • たしかに、この操作でこれが出来ないのは、分かりづらいかもね
  • なんでこうしたんだっけ？
  • ここは、◯◯のふるまいも気にして決めたんだよね
  • ちょっと無理があるのかな
  • そもそも、●●の制約を入れた時点で負けじゃない？
  • もう一度（全体的な仕様を）考えてみようか
  • じゃあ、続きは二次会で


f:id:miwa719:20171223135220p:plain


何かを「間違える」のは、どちらかと言うとネガティブなイメージが強いから、間違えたことを恥ずかしく思ったり、隠したい気持ちになるんだけど、単に自身の勉強不足や注意散漫、だけでは済まされないコトが「間違える」には含まれている。


だから、あなたが何かを間違えたら『そっ閉じ』しないで、まずは、あなたの周りの人に話してみるといいと思います。

これは、開発現場だけの話ではなく、日常生活の中で起きる「間違い」全般に言えることなんだけど、わたしは（組み込みシステムの）テスターなので、冒頭のような例を出して説明しました。

「間違える」は、とても分かりやすくて、じぶんで気がつくことができる便利なシグナルだから、ぜひ、今日から練習してみてね。


じぶんの間違いを大切にできるようになると、周りの人の間違いも大切にできるようになるよ。

f:id:miwa719:20171223100219j:plain

とちぎRuby会議07 ふりかえり #toruby

とちぎRuby会議07で、主にわたしが担当した『食』を中心に、ひとりふりかえりをしました。

ランチセッションの「からあげ弁当」

  • 量が異常。
  • Twitterのタイムラインが「からあげ」だった。

 

  • ちなみに、からあげ弁当は３６個購入したので、参加者の７割の方が食べた。
  • 異常だったのは量だけで、からあげ弁当自体は、おおむね好評だった。
  • 今後は値段に騙されないようにする。（小盛り４５０円であの量は想像できなかった。テスターなのに！）
  • 月１の勉強会で試食して、事前にお弁当の量を確認する。
  • ランチセッションとパーティーを組み合わせるときは、お弁当の量に気をつける。（今回は全く気にしてなかった）
  • お弁当を渡すとき、無料と有料の列を分ければよかった。
  • 講演者は無料だったのに、お金を貰っちゃった人がいるかも。ごめんなさい。
  • 次回以降の #toruby イベントで使える『お弁当無料券』を発行することで、対応したい。

コーヒーマシン

  • アンジェリカさんにお借りした。とても良かった！
  • 挽きたてのコーヒーは、香りもいいし、美味しい。売れ行きもよかった。
  • 前回はパーティーのときに、大きなコーヒーマシンを持ってきてもらったのだけど、操作が難しくてうまく使えなかった。今回は操作が簡単なものを、開場前に設置してもらい、使い方を教えてもらった。
  • 操作は、水とコーヒー豆を補充して、コーヒーかすを捨てれば良い。楽だった。
  • コーヒーマシンが人間に何をして欲しいかは、ディスプレイに表示される。分かりやすかった。
  • 時々チェックしてたんだけど、@youchan さんにコーヒーかすを捨ててもらったりして、助かった。他にも気付いてやってくださった方がいるかもしれない。ありがとうございます！

他に用意した飲み物

  • ペットボトル（２リットル）１８本
  • ウィスキンソン ジンジャーエール（辛口） ２４本
  • あたたかい飲み物（緑茶、紅茶、ココア）電気ポットはホールのものを使用。
  • ペットボトルはほとんど残らなかった。この時期なら、あと５、６本あってもよかったかも。

パーティー（Deli & Dolce リトルアンジェリカ）

  • お料理の搬入などはスムーズで特に問題なかった。
  • ホールの搬入口は開いていたけど、施錠してあるときもあるみたい。搬入時間近くになったら、開錠してあるかどうか見にいったほうが良い。（今回は午前中から、わたしたちが使っていて、単に開けっ放しだったという可能性もある…）
  • 前回、同じ規模でやったときに、ピザやご飯モノがあっという間に売り切れてしまったことから、今回は前菜ぽいもの（グリーンサラダやカポナータのようなもの）を少なめにして、その代わりに「お腹にたまるもの」を多めにしてもらったのだが、それが裏目に出てしまった。
  • みんな、からあげ弁当のせい。
  • 今回もアンジェリカさんのお料理は、ひとつひとつ丁寧に作ってあって、とても美味しかった。並べ方も大変きれいだったのに、写真を撮るのを忘れた。
  • ドルチェも本格的なものを２種類作ってもらった。甘さ控えめのエスプレッソのプリンとパウンドケーキ。
  • ワインを赤と白１本ずつ持ってきてもらった。赤ワインはわりと早いうちになくなった。白ワインがグラス１杯分残ったくらい。
  • アルコール類の準備はよく分からないので（飲まない人もいるし）今までどおり、飲みたい人が休み時間に買いに行くスタイルでよいと思った。

  • 急遽、テイクアウトにも対応してもらった。
  • アンジェリカさんが「ラップとかアルミホイル、お店から持ってきましょうか？」て言ってくださったんだけど、（たくさん余ってしまったのは、絶対からあげ弁当のせいなので）申し訳なくてあるもので対応した。あるものって、アンジェリカさんが持ってきた紙皿なんだけど、それを大量に使わせてもらった。本当に申し訳なかった。

  • いつまでも、みんなのこころに残る、アンジェリカさんのごちそう。

 

 

その他

  • 特にお菓子類は用意しなかったんだけど、テーブルにお土産のお菓子がたくさん並んでいた。ありがとうございます！

  • はじめから会場のうしろに、椅子を５つくらいフリーで並べておけばよかった。
  • 並べた後、少ししたら大場さんちのお子ちゃまが寝た。眠かったんだよね。気が付くのが遅くてごめんね。
  • 子供用ベッド？にするには椅子が３つ必要。落ちないようにもう１つくらい要る。長座布団があるとなおよい。
  • 大人が座ってもいいし、次回ははじめから多めに並べておこう。
  • #toruby 初参加の方には、LTのときに一言しゃべってもらって、プレゼントを持っていってもらえばよかったかもしれないね。
  • 酒匂さんの扱いが雑だった。ごめんなさいごめんなさい。

  • そういう扱いは 本当に偉い人 に対してはOKらしい。知らなかった。

 

  • 閉会後の片付けをたくさんの方に手伝ってもらった。ありがとうございます。
  • アンジェリカさんのお料理をたくさんの方にテイクアウトしてもらった。ありがとうございます。

参加率は９４％くらい

  • 今回は前払いだったから入場チェックはしなかったんだけど、勉強会のときに数えたら（数え間違いがなければ）５１名だった。
  • 参加申込みが５０名、招待講演が３名、急遽 @chomado さんに呼び出された！マイクロソフトの @okazuki さんもいれて、全員参加で５４名。
  • なので、参加率は９４%くらい。
  • だいたいいつもと同じだった。

 

ひとりふりかえりは、こんな感じです。続きは９月の #toruby 勉強会で！

 

正しそうなことを疑うこと（統一感を例に）

f:id:miwa719:20170312093225p:plain

システムを組み合わせた状態でテストしていると、自ずと「システム全体として統一感がとれているか？」のような視点でも確認しますよね。わたしの場合は ”わざわざ確認する” というよりは、テスト対象を触っていて、統一感がとれていない事象に遭遇したとき、それが違和感となって現れることが多いです。なんとなく気持ち悪かったり、不安になったり、混乱したり、意図しない挙動を見たり、操作を間違えたりするんですね。

ユーザーインターフェースの見た目や操作感、画面遷移、使われる用語やメッセージの文言、データの取り扱いなど、統一感をキーに注目するところは沢山あると思います。

そういえば昨日も1箇所直してもらったなー。数値と単位の間に隙間(半角スペース)がある画面とない画面がありまして、動作には全く影響しないのだけど。（そういった些細なところにもわたしたちは気を配って日々モノを作っている）


さてさて、統一感があることは良いことなのですが、いつでも、どんなときも、それが当てはまるわけではない、というのがちょっと難しい。統一感がある＝良い！と思ってしまい、問題に気づけないことがありそうで、これがこわいのです。

例えば、あるシステムではコマンドボタンにフォーカスがあるときにreturnキーを押しても実行できるようになっていたとします。

システム内のすべてのコマンドボタンを触りreturnキーを押して実行できれば、その操作方法は「統一感がある」ということになります。

もし、あるコマンドボタンだけreturnキーを押しても実行できなかったとしたら（あれ？イベント処理を書くのが漏れたかな？）と思い、担当のプログラマーに報告するのでしょうね。


確かに漏れた場合もあるのですが、このコマンドボタンが「X線の曝射ボタン」だとしたらどうでしょうか？（あくまでも例です。ライフラインや人体に危険を及ぼす可能性のあるボタンを想像してください。）

そう、ここではユーザーが”間違って”曝射ボタンを押さないように、わざとreturnキーでは実行できないようにしています。ここに操作の統一感はありません。

それでは、逆に考えてみます。

「X線の曝射ボタン」がreturnキーで実行できたとして、果たして（これだと、まずいのでは…）と思えるのか。

曝射ボタンの場合は（あくまでも例）もう分かったのでいいのですが、まだ見つかっていない問題に、わたしは気づけるのでしょうか。

それに気づくためには、 一般的に正しいと言われていること（今回の場合は、統一感がとれていること）にさえも、惑わされてはいけないのだなぁと思います。

本当に正しいのかな？
それは自身の価値観や固定観念を疑うことでもあります。