CAT GETTING OUT OF A BAG

What the tester is thinking.

バグの原因にすぐにたどり着かないのは悪いことばかりでもない

※ この記事は『テストラジオ 第201回』(約30分)を視聴してから読むとより理解できます。

youtu.be

いつの間にか『テストラジオ』が放送200回を超えてました。おめでとうございます!*1

『テストラジオ』は特にバグに関する回が好きです。パーソナリティのなそさんやよしたけさんが開発(テスト)してる製品と、わたしが開発してる製品はだいぶ異なりますが、お二人が話してくれるシステムのおかしな挙動からバグの原因を予想するのが面白いですし、自分たちの製品で似たようなバグが起きるとしたらどのようなものだろう?と想像しながら聴いています。

バグの原因にすぐにたどり着かないのは悪いことばかりでもない

第201回はブラウザ依存バグのお話でした。よしたけさんとsaeさんがおかしな挙動を見つけたとき、すぐに「ブラウザ依存かもしれない」と思えなかったこと、想起できなかったことを、よしたけさんが悔やんでいるような印象を受けました。

わたしはすぐにたどり着かなかったことで良かったこともあると思いました。もしすぐに「ブラウザ依存かも」と思えたら、それで終わりになっていたんじゃないかな。それで終わりというのは「ワークスペースを作成したユーザーだけおかしな挙動になるんじゃない?」が表に出てこなかったのではないか、ということです。今回それが話題になったことでチームの人たちの脳内には「そういう条件のバグがあるかもしれない(だとしたらちょっと厄介な問題だ)」が一瞬でも記憶されたと思います。記録ではなく記憶なので数値で表すことはできませんが、これから開発(テスト)するときに、きっとこの記憶が活きてくると思います。

もちろんバグの挙動を見たときにその原因に直結するような条件にすぐにたどり着くのは素晴らしい能力です。調査時間もバグの混入時間も短くて済みますし、なによりすぐにたどり着いた自分が気持ちいい(笑)。

バグの原因や条件や再現手順を見つけるために考えたり試行錯誤した時間は無駄ではなく、それがそのまま自分の思考の引き出しを増やしたり、おかしさにたいする瞬発力を鍛えたり、自分たちが開発しているシステムや製品をより深く理解することにつながります。わたしたちが憧れる優秀なプログラマーやテスターもそのようなことをたくさん経験して、いまに至っているのではないでしょうか。*2

自分が一度信じたものをなかなか手放すことができない

今回のお話をちょっとちがう視点(認知バイアス)で捉えてみると「自分が一度信じたものをなかなか手放すことができない」が浮かび上がってきます。きっとこうに違いない!と思ってしまったことに囚われすぎて「あること」がすっぽり抜けてしまう。そのような人間としての特徴が自分には備わっているのだから、開発(テスト)するときに自分で自分の意識をどのようにコントロールしたらよさそうか、なんてことも『テストラジオ』は気づかせてくれます。

"自分が一度信じたものをなかなか手放すことができない" は上記の書籍(論理学系バイアス19『信念の保守主義』)からの引用です。

*1:どうでもいい情報ですが、うちのチームは先週872イテレーションでした。この数値に特別な意味はなく(単なる週番号で「あの辺」や「あの頃」を示す番地やポインタでしかない)キリ番で盛り上がったりお祝いしたりすることもないのですが、個人的には1,000イテレーションになったときのチケットシステムの挙動が気になります。まあ、プロの無職 @m_seki お手製のRWikiシステムなので、なにごともなくふつうに動いてそうですが...

*2:よしたけさんやなそさんはわたしに言われなくてももうそんなことはわかっていると思うけど、200回突破記念のお祝い? に言語化してみた!

『ユニコーン企業のひみつ』読書会をしました

www.oreilly.co.jp

どのような読書会だったのか

参加者はわたしたちのチーム(咳チーム)の4名(プログラマー、テスター、プロの無職)と上層部2名*1の計6名。週1回1時間の開催(オンライン)を基本とした。上層部が忙しすぎて開催できない週もあった。日程の調整はわたしがやったんだけど、上層部の人たちの予定表は朝から晩まで会議でびっしり埋まっていて、はじめの頃は「読書会なんていれていいのか…」と躊躇するほどだった。

昨年5月のGW明けから読みはじめて、読み終えたのが12月末。延べ8か月。月平均3回開催として24回。本文が約180ページだから1回につき7.5ページ。うん。だいたい感覚と合ってるな。

読書会は仲間内でこれまでも何度かやっていて、今回も同じようなスタイルでやるつもりだったけど、上層部が「読書会というものにはじめて参加します」という感じだったので、初回にこの読書会をどのように進めていきたいのか、やり方も含めて意識あわせをする時間をとった。

「わたしが音読しますね。きりのいいところまで読んだらいったんストップして、みんなでディスカッションします。読んだところに関してみなさんが思ったことを話してほしい。わたしはそれが聞きたいです。前の話題に戻ってもいいし、ぜんぜん関係ないことを話してもいいですよ」

「本を最後まで読むことを読書会の目的にはしません。本に書いてある内容をきちんと理解するというよりは、そこから自分が何を思い、何を考えたのか。自分たちのチームはどうなのか、組織は、会社は、のような話をする場にしたいです。読み急がないので、読み終わるまで数か月かかると思います」

たぶんこんなことを話して、みんなが「そうだね。そういうのがいいね」という雰囲気になったのを覚えている。

じつは、上層部のTさん*2を読書会に誘ったとき「まずはお試しで1回参加させてもらいます」と言っていて(そりゃそうだよな、わけのわからん読書会だもんな)と思っていたけど、初回の読書会の終わり際に「すごく面白かった!次回も参加します!」と言ってくれたのがとても嬉しかった。

読書会は毎回面白かったしなんらかの刺激と学びがあった。話した内容はここには書けないけど本当にいろんなことを話した。上質な時間だった。そして読書会の終盤には夢のようなことが実現した。訳者の島田さんと角谷さんに社内読書会にリモート参加してもらったのだ。しかも2回も!

お二人からは訳者ならではの広く深く積み重なった知識と洞察とご自身の経験を織りまぜた貴重なコメントがレスポンスよく返ってきて、これは世界最高レベルの読書会なのでは……と思ったし、もう、素晴らしすぎて言葉が出ません……。それはそれとして、社内の人たちに島田さんと角谷さんを見せびらかすことができて大変満足した。

ちょっといろいろ思い出してテンションがおかしくなってきたので、どのような読書会だったのかはこれくらいにする。ああ、そうそう、仲間内(たとえば、開発者同士)でやる読書会も面白いけど、自分とは立ち位置のちがう人(今回は上層部)と一緒にやる読書会もとてもよかった。同じゴールを目指していても立ち位置がちがうと気にするベクトルが変わる。それは一緒に同じ製品を開発しているプログラマーとテスターを見ていてもそうだし、上層部とわたしたちだってそうだろうと分かっていたけど、何がちがうのか、それがどういうことかを直接その人の言葉で聞き、何をどんな角度で見ていて、なぜそれを大切にしているのかを知ると、自分の思考の中に新しい道ができる。その道に立つと見える景色が変わり、これまで考えもしなかったことが考えられるようになる。

立場のちがう人が集まって読書会をする場合に、特に向いてる本というものがあるかもしれない。『ユニコーン企業のひみつ』は相当向いている。前回の読書会で使った『熊とワルツを リスクを愉しむプロジェクト管理』もよいかも。普段は面と向かってできないような話のきっかけを与えてくれると思う。

 

最後に自分でもまだよくわかっていない「文化の伝承」について書いておく。

文化は伝えることはできても再現できないんじゃないか

ユニコーン企業のひみつ』の中で「文化」という言葉は何度も出てきたし、次の読書会の候補になってる『Googleのソフトウェアエンジニアリング』でも「文化」はテーマのひとつになっている。

咳チームにも「文化」はたしかに存在するけど、それはチームの中にしかないと思っている。どんなにうまく言語化できたとしても文化そのものではない。読書会でも「咳チームの文化を伝承するにはどうしたらいいんだろうね」と何度か話題になり、わたしもこの課題を先延ばしにできない年齢になってしまっているので「文化の伝承」について最近よく考える。

これまでも、咳チームのようなチームになりたい!作りたい!と思っている人たちや、咳マニア、咳チームに興味のある人たちに向けて、いくつかの外向け用のコンテンツを用意してきた。咳チームの「開発のやり方」「大切にしていることや考え方の癖」「喜ばれるふるまい」「よく使うフレーズ」などを紹介し、チームの「感じ」を一緒に体験してもらうことで、咳チームのエッセンスを伝えようとした。コンテンツを通して何かひとつでも受け取ってもらえたら嬉しいし、それでいいと思っている。

でも、自分の会社や組織向けだとそれでいいって思えないんだよね。何がちがうんだろう。だいたい同じか? とも思うんだけど「伝承」という言葉が重いんだろうなぁ。単に伝えるだけでは足りない感じがするし、うまく伝えられたとしても「縄文文化を知っていても縄文文化は再現できなそう」とか思ってしまう。咳チームの文化を社内にどのように伝承していけばいいのかよくわからない。*3

伝承という言葉に囚われないで、どうなったらうれしいのか具体的なイメージを持てるといいのかもしれないね。結局「文化の伝承がうまくいったらどうなるの?」に立ち戻るのだな。*4

伝承(でんしょう、: folklore、: tradition populaire)は、ある集団のなかで古くからある慣習風俗信仰伝説技術知識などを受け継いで後世に伝えていくこと、もしくは、そのように伝えられた事柄や物を指す。歴史学民俗学にとって、重要な資料となる。

www.oreilly.co.jp

*1:まあまあ上層部とすごく上層部

*2:すごく上層部

*3:咳チーム自体の伝承については何もしなくても大丈夫だと思う。うまく説明できないけどそう感じる。あとに続く若者たちで繋いでいけると思う。

*4:「うまくいったらどうなるの?」は咳チームの代表的なフレーズです。

バグにあったらどうするか

Calendar for ソフトウェアテストの小ネタ | Advent Calendar 2021 - Qiita 12日目の記事です。

はじめに

アイヌ民族最後の狩人 姉崎 等(あねざき ひとし)さんを語り手として、編集、構成された書籍『クマにあったらどうするか』を、読んだことはありますか?

私は、クマを自分の師匠だと本気で思っています。なぜクマが師匠かというと、クマの足跡を見つけたときにクマを一生懸命追って歩く、そうやって追っていくうちに、山の歩き方やクマの行動などをすべて学んだからなのです。

こんな書き出しではじまり、姉崎さんの生い立ち、どうやってクマ撃ちになったのか、12歳から65年間、山に入ってクマを観察し続けた者にしか感じることのできないクマの生態や性質や習性、そこから導き出された知見や示唆に富んだ洞察が余すところなくインタビュー形式で収録されています。

「クマと遭遇したとき、人間は生き延びるために何をすればいいのか」

その問いに対する答えだけでなく、アイヌの教え、クマを知るということはどういうことか、人間がクマや自然と共生していくにはどうしたらよいか。それらに対する姉崎さんの考え方や向き合い方、心持ちにも触れることができます。多くのことが学べる、考えるきっかけを与えてくれる本です。

また「クマ」を「バグ」に置き換えて読むと、バグハンターとしての共通点を感じるでしょう。狩猟とソフトウェア開発。異業種ではありますが、その道のプロフェッショナルが語る言葉に耳をかたむけ、自分の仕事や日々の言動を見つめなおす ー そんな読み方、楽しみ方もできる本です。

とつぜん目の前にクマがあらわれたらどうするか。本書には姉崎さんおすすめの10か条がまとめられていますが、この記事では製品開発中に『バグにあったらどうするか』をテーマに思うことを書いてみます。

わたしについて

医療機器(自社製品)を開発しています。eXtremeなチーム(咳チーム)*1に所属する開発者です。この記事をお読みのみなさんや、みなさんの大切な人の役に立つ製品を丁寧につくっていきたい。そんな思いで日々勤しんでおります。

バグにあったらどうするか

あなたがテスターならバグの原因を解明するための情報を集めるのではないでしょうか。バグ発生直後のスクリーンショットや各種ログファイルを収集しながら、PCの端っこに表示されているシステム時刻(バグ発生時刻)に目をやります。壁掛けの電波時計のような実世界の時刻がログ解析には役に立たないのを知っているからです。バグ発生時刻というのは、正しくは「自分がバグに気づいた時刻」です。問題はもっと前から起きていたのかもしれません。バグの現象と過去の経験からプロセッサ毎のCPU使用率やメモリ使用量といったリソース状況も確認します。

あなたは収集したものを共有フォルダに保存しながら、バグに気づく直前までに自分がやっていたことをできるだけ詳細に思い出そうとするでしょう。数秒前、数十秒前に操作していたことは短期記憶に保持されていますが、それも時間の経過とともに曖昧になっていきます。試験仕様書に記載のテストケースを忠実に実行するようなスクリプトテストではなく、テストの結果や手応えに応じて変容していくテスト(Testing、探索的テストをイメージしてください)は、どうしても手数が多くなり詳細に思い出すのがむずかしくなります。なるべく取りこぼさないように “やったこと” に加えて “なにを見たのか” “なぜその操作をしようと思ったのか” にも意識を向けて記憶しなおしていきます。

あなたは再構築した記憶を元に再現テストを試みます。すぐにバグは再現しました。ひとあんしんです。そしてこの手順(10ステップ)は冗長かもしれないと思いました。操作をすこしずつ省きながら最短手順を探します。その結果、6ステップで再現できるようになりました。最短手順を探す過程でパラメータを変えながら試したので、3ステップ目でパラメータSを選んだときだけバグが発生することもわかりました。

念のため、この現象が「そういう仕様ではない」こともドキュメントを読んで確認します。以前、報告したバグが調査の結果「そういう仕様」でプログラマーに迷惑をかけたのです。

そんなことをしていたら、すこし前の記憶がよみがえってきました。先週も似たようなところを触っていたはずなのに、このバグに気づかなかったな…。気になるので試験環境を先週の状態に戻して試します。バグは再現しませんでした。最近の変更で壊れてしまったようです。先週見つかるはずのバグを見逃したわけではなかったので、内心ほっとしました。これでバグを報告するための情報が揃いました。あなたはBTS*2のチケット登録ボタンを押しました。

チームが変われば価値観も変わる

あるテスターがバグにあってからチケットを登録するまでの様子を書いてみました。実は10年くらい前にわたしが実際にやっていたことがベースになっています。ひとつひとつの行動に対してやる理由(やらない理由)があり、当時のわたしはこれが「良いふるまい」と思っていました。

現在の咳チームにJoinした直後、当然のようにそれまで信じて疑わなかった「良いふるまい」をしようとします。しかし1行目の「バグの原因を解明するための情報を集める」から嫌がられてしまいます。わたしは混乱しました。さらに追いうちをかけるように、これまでなら「良くないふるまい」だった行動を求めてきます。

それがバグかどうかはどうでもいいから、おかしいと思ったら何よりも先に誰かに言って!

これをやるには作業中のプログラマーたちの間にズカズカと割り込んでいかなければなりません。とても苦痛でした。

『郷に入っては郷に従え』ということわざがあります。物理的な居住地だけでなく職場やグループなど所属する組織や集団にもその考え方は当てはまり、チームが変われば開発のやり方も価値観もちがう。それはそうだろうと頭ではわかるのに気持ちが追いついていかない。身体が拒否してしまうんですね。咳チームにやっと順応できたかなと実感するまで3か月くらいかかりました。チームが大切にしていることや考え方が「ああ、こういうことなのか」と理解できたのもこの頃です。そのためには何を犠牲にするのかも明確でした。咳チームの価値観と期待される行動は見事に一致していました。

バグにあったらどうするか

咳チームのプログラマーやテスターがバグにあったらどうするか。その瞬間のふるまいやどのように考えるのか(思考の癖)を紹介します。バグの原因を調査して、設計を見直して、プログラムを修正するといった手順の話ではありません。あなたが山の中でクマにあったときのことを想像してみてください。クマにあってしまった原因を調査したり、レポートを書いたりしないでしょう。 

毎日チームのみんなの言動をそばで見ていて「こうなんだよな」と感じるものを言語化しました。バグにあったときに(当たり前のことかもしれませんが)こんなふうに脊髄反射できるのが素晴らしいと思っています。*3

なお、ここで対象にするバグは明らかな不具合だけでなく、ちょっとしたおかしさや違和感のようなものも含みます。*4

あれはクマ!?

あなたはなにかに気づきました。

  • 気のせいとは思わない(気配を大切にする)
    • 「クマがいるような気配がするけど、気のせいかな?」(00:00.02)
    • 「いやいるよ!」(00:00.21)
    • 「いるつもりで!(行動しよう)」(00:00.72)
    • あなたの感じたそれは気のせいではないです。なにかのメッセージです。
    • 気のせいは揮発性なので忘れてしまいます。すぐに同僚に伝えましょう。
    • 同僚と一緒に気のせいの正体を探りましょう。
    • それともなに? 気のせいにしたらクマはいなくなるの?
    • 補足
      • あなたの気のせいを真面目に受け止める同僚がいます。
      • 同僚の気のせいを真面目に受け止めるあなたがいます。
      • バグかどうかが完全にわかってから何かをするのではなく「バグがあったかも!バグがあるつもりで!(みんなで解こう)」

チーム(パーティ)で立ち向かう

  • 何よりも先に同僚に伝える
    • おかしいと思ったらすぐに同僚に伝えましょう。非同期ではなく、同期コミュニケーションで!(00.01.59)
    • バグか仕様かテストの誤りかいろいろ気になるかもしれませんが、調べるのはちょっと我慢してください。
    • おかしいと思った直後のシステムの状態をプログラマーに見せましょう。
    • チケットを登録するのはプログラマーに見せてからにしてください。
    • それを見るのに最適なプログラマーを集めましょう
    • 騒ぎに気づいた同僚たちがあなたのまわりに集まってきます。
    • どのような操作をしていたのか話しながら実演してみましょう。
    • 深刻な問題(クラッシュするようなバグ)や、今日みんなが簡単に踏んでしまいそうな問題なら全員に知らせましょう。同じ問題を踏んでしまうのをなるべく避けるためです。システムを再起動する時間がもったいないので。
    • テスターは「そこを通るテストは明日にしよう」と思うかもしれません。
    • 騒ぎを知らずに同じ問題を踏んでも大丈夫です。まわりの同僚に伝えればさっきのあの問題だとすぐに教えてくれます。
    • 補足
      • 自分の作業より誰かからの割り込みが最優先です。
      • みんなは問題(おかしさを含む)を1秒でも早く知りたがっています。
      • みんなは問題(おかしさを含む)に興味があります。
      • 問題が起きたのに伝わらなければ、問題が起きてないのと同じです。

最悪の事態を考えるんだ!

  • 検出された意味を考える
    • なぜそれが検出されたのかに興味を持ちます。(00:04.97)
    • バグかどうかはどうでもいいのです。
    • 同僚はなにを思ってそんなことをしたのか想像します。きっと同僚は話してくれますが、あなたはもう想像しています。
    • 仕様がわかりづらいのかもしれません。だとしたら当然、お客さまもわかりづらいと思うにちがいありません。
    • 前からそういう仕様だったとしても、今もそれでよいかどうかはわかりません。
    • 「前からそういう仕様だった」ではなく、その仕様がどんなに素晴らしいのかについて話しましょう。
    • 操作ミスはメッセージです。操作ミスを誘うような作りになっているのです。
    • 勘違いもメッセージです。同僚がなぜ勘違いをしたのかを考えましょう。
    • テストケースになにか問題があったのかもしれません。
    • 仕様が陳腐化してテストを更新する時がきたのかもしれません。
  • 一番嫌なことを想像する
    • 報告した現象、報告された現象にとらわれないようにしましょう。
    • 見かけの現象ではなく、その動作の原因(仕組み)から最悪なことを想像します。(00:05.64)
    • お客さまの健康や生命が脅かされるくらいならクラッシュしたほうがよいときもあります。
    • 起きてほしくないことは起きます。
    • 嫌なことは重なります。
    • 起きないことを祈るのではなく、それがなぜ起きないのかを理詰めで解きましょう。
    • 「動作は問題ありません。単に表示の問題です」本当にそうかな?
    • 軽微に見えるバグを軽視しがちなのを自覚しています。
    • 軽微に見えるバグでも見方を変えれば重大な問題になります。
    • 軽微かどうかは見かけの現象でなく、その原因とそこから想像される一番嫌なことで決まります。
    • 補足
      • 咳チームでは、不具合の仕組みがわかるまで調べ、そこから直すかどうかを決めます。基本的にバグはすべて直します。

繰り返しますが、ここに書いたのは「咳チームのプログラマーやテスターがバグにあったらどうするか。その瞬間のふるまいやどのように考えるのか(思考の癖)」です。こんな思考癖のあるチーム(プログラマー集団)を見たことがなかったので、えらく感動したのを覚えています。

咳チームが大切にしてることや考え方

先ほど「咳チームの価値観と期待される行動は見事に一致していました」と書きました。価値観とはチームに漂う暗黙知のようなもので、言葉にするのが非常にむずかしいのですが、咳チームが大切にしてることや考え方はこのようなものだと思っています。

  • 昨日よりも良い製品にしたいから
    • 問題や課題をできるだけ早く見つけたい
    • 問題や課題をできるだけ早く知りたい
    • 問題や課題をできるだけ早く直したい
    • システム全体で結合した状態でできるだけ早く試したい
    • システム全体で結合した状態でできるだけたくさん試したい
  • 問題や課題はメンバーではなくチームにある
  • 無理をしない
  • わたしたちは間違える

とてもシンプル!

おわりに

製品開発中に『バグにあったらどうするか』をテーマに思うことを書いてみました。アドベントカレンダーに登録したとき(1か月くらい前)は、もうすこしテストっぽい話を書くつもりだったのに、気づいたらいつものように咳チーム自慢になってしまいました。プログラマーもテスターもプロの無職もみんな素晴らしいので仕方ない。

わたしが咳チームにJoinした頃の話、チームが変われば開発のやり方や価値観が変わるというのは「まあそうだよね」と思うのに、それを受け入れるには苦痛がともない、順応するまでに時間がかかったエピソードをお伝えしました。

それから、10年くらい前に「良いふるまいである」と信じて疑わなかったものが、果たして本当にそうだったのか、いまでは疑問に思っていることもお伝えしておきます。きちんとやっている実感もあったんですよね。*5 だからなおさらこわいですし「いまだって…もしかしたら…」と思う気持ちもどこかにはあります。わたしたちは間違えるからね。*6

バグにあったらどうするか。ひとりひとりがどうふるまうのか。それはチームの価値観が反映された結果の行動でしょうし、ひとりひとりのある瞬間の些細なふるまいがチームの価値観を醸成しているとも言えます。

みなさんはバグにあったらどうしますか?

おまけ

本記事を執筆中に食べていたお菓子です。美味しい!

 

*1:世界一長生きのXPチーム。@m_seki がプロの無職をロールプレイしている。

*2:Bug Tracking System:障害管理システム

*3:実際の咳チームのメンバーはここに書いてある言葉から受ける「感じ」よりはもっと淡々としてます。もしかしたら @m_seki の「だって仕事でしょ?」が伝搬しているのかもしれません。この台詞について詳しく知りたい方は、書籍『プログラマが知るべき97のこと』に収録されている 関 将俊(せき まさとし)さんのエッセイ『ロールプレイングゲーム』、またはここからも読むことができます。

*4:文中の表記揺れが気になる方がいたらごめんなさい。バグ、不具合、問題など、特に区別なくわたしの気分で記載してます。

*5:要因として思い浮かぶのは「チームの中でしか物事を考えてなかった」あたりかな。あの頃は見ている世界がとても狭かったと思います。

*6:そう!間違えるからルールにしません。ルールだからやる、はよくない。ルールにすると間違いに気づけなくなります。

言いにくいことを言うには練習が必要

先日行われた某チームのAAR(と名のついた違う催し物、品質活動)の結果の対策のひとつが「命名規則をちゃんと周知させる」でした。チーム開発は他人が書いたソースコードを読んで理解するのが仕事、みたいなところがあるので(長命な製品開発になると特にそうだよね)みんなが誤解しにくい名前をつけるのは大切です。書籍『プログラマが知るべき97のこと』でRubyのパパこと、まつもとゆきひろさんも『名前重要』というタイトルでエッセイを寄稿されてますね。

名前が大切であることは疑いの余地がなく、自分でも納得しているのに「命名規則をちゃんと周知させる」を聞いたときに「なんだそれは…」と思ってしまいました。それでこう言いました。

次は "命名規則に則った名前だったけど中身が思っていたのとちょっと違いました" とかになるんだから、中身を見ないとだめだよね

実はこれ、とても言いづらくて、なぜならわたしは仕事ではコードを1バイトも書かない。当然中身も見ない。中身を見ない人に「中身を見ないとだめだよね」と言われたらどう思うかってことですよ。でもその一方で「命名規則のせいにして…」「はっきり言わないと分からない人がいるかもしれない…」が、あたまの中をぐるんぐるんする。

テストもそうだけど「ここは大丈夫」と思っても0.1mmでも不安があるなら試すでしょう。大抵はちゃんと動くんだけどね。だから、わたしがわざわざそんなことを言わなくても、みんなは分かってる。と思うんだけど、やっぱり不安がゼロにはならなくて言っちゃった。

さっき「名前が重要であることは疑いの余地がなく、自分でも納得しているのに」と書いたけど、こういう正しいこと(正しそうなこと、耳あたりのよい言葉)に対して「んん?」と斜に構えてしまうのはなんなんだろうな。年々そういう傾向が強くなってるような気がします。

言いにくいことを言うには練習が必要

わたしが言いにくいことが言えるようになったのは、書籍『エラスティックリーダーシップ ―自己組織化チームの育て方』で、プロの無職 @m_seki が『リードについて』を書いてくれたからなんだよね。

本エッセイでは「リード」とは変化を促す「言いにくいこと」を発信することではないかと仮定してお話を続けます。

今回の「言いにくいこと」が変化を促したかどうかはさておき、言いにくいことを言うには練習が必要です。エッセイを読んだからって突然言えるようになるわけではない。すくなくともわたしはそうでした。

だから、これは言いにくいなって思ったら、まずは「言いにくいことを言う練習だな」と思ってやるといいのではないでしょうか。

正しい日付を入力してるのにエラーになるときがある

今年に入ってから二つの異なるソフトウェア(iOSアプリと組み込み系)で「正しい日付を入力してるのにエラーになるときがある」というバグに遭遇しました。おかしさっぷりが似ていて、きっとこれは「よくある不具合」なんだろうなと思いました。

軽い気持ちでお題風にツイートした

軽い気持ちでお題風にツイートしたら「ソフトウェア開発で日付を扱うときに気にしたほうがいいこと」が、たくさん集まりました。うれしかったです。

「1. どのようなことが起きていると思いますか?」では、失敗しそうなシチュエーションや疑わしいところ、確認したい事柄など、多種多様なコメントが寄せられました。これらをベースに実践的なテストケースが導き出せますね。「2. どんなテストをしてみますか?」では、具体的なTestingのテクニックや、この状況でのテストの考え方、攻め方について言及してくださった方もいました。

また「正しいとはなにか」「おかしいのは日付ではないのではないか」のような切り口から考えてくださった方もいました。どれもユニークで素晴らしい回答だと思います。たいへん勉強になりました。ありがとうございました。

togetter.com

Togetterのコメント欄にも知見が寄せられています。興味のある方は読んでみてくださいね。

この知見の楽しみかた

みなさんからいただいた貴重な知見を、分類してチェックリストにするとか、重複しないように整理してマッピングするとか、そういう野暮もったいないことはいたしません。そんなことをしたら大切なものを取りこぼしてしまいます。

ツイートをひとつひとつじっくり読み、この方はなぜそう思うのか、なぜこういうテストをしようと考えるのか、わざわざなんでこれを書いてきたのか(笑)とか、行間にも想いを馳せます。そこから浮かびあがる思考の背後にある、みなさんの開発(これまでに遭遇してきたであろうバグや開発に関する問題など)を感じ、想像(妄想?)するのです。そしてそれを自分の脳内に疑似体験として保存する。大切なことはね、たいてい書いてないのです。

どのような不具合だったのか

これを当ててもらうためにツイートしたわけではないのですが、どんな不具合だったんだろうって気になる方もいるかもしれないのでメモしておきます。

再現手順

  1. 登録画面を表示する
  2. 日が不正な日付を入力する(例 "19650332")
  3. 入力チェックでエラーになる(OK)
  4. 入力した日付を全て消す
  5. 正しい日付(例 "19650325")を入力する
  6. 入力チェックでエラーになる(NG)

なぜエラーになったのか

日付欄(見た目)は"19650325"と表示されていたが、入力チェック用の日付変数には"  19650325"と入っていた。先頭にスペースが2つ入っていた。日付のフォーマット(YYYYMMDD)と合わないためエラーと判断された。入力チェックの過程で使用する中間バッファにある条件下で不要なスペースが残ってしまうような実装になっていた。*1

まあ、簡単に見つかると思う

不正な日付を入力したあとに正しい日付を入れ直すような操作をすれば見つかる不具合です。実際はもうすこし複雑で年(YYYY)が不正だとこの現象は起きません。また日付のフォーマットによりおかしさの挙動が変わります。まあでも、このブログをお読みのみなさんはすぐに見つけることができると思います。

この不具合のヤバさ

日付欄に入ってる(目に見える)値で日付のチェックをしてると思ってたのに、そうじゃなかったのがかなりヤバい!!!! たまたまうまく動いてる(ように見える)やつもあるんじゃないの!!「よし!」と思っていたところも、急に疑わしくなってきますな。大切なことはね、たいてい目に見えないのです。

*1:どうでもいい話ですが、1965年3月25日は Sarah Jessica Parker さん(米国の女優、プロデューサー)の誕生日です。たまたま週末にアマプラでみた映画にSarahが出演していて、なんとなくテストデータとして使用しました。この不具合は「サラの呪い」と名づけられています。

新型コロナワクチン接種(2回目)の体験記

新型コロナワクチン接種(1回目)の副反応は、接種部位周辺の痛みと、1週間後に出現したモデルナアームくらいでぜんぜん余裕だったが、2回目はつらかったので記録しておこうと思う。

うちの会社の職域接種は1回目、2回目とも10日間の日程で実施した。私はあとのほうだったから、先に接種した同僚たちが2回目の接種後(翌日から翌々日にかけて)ばたばたと休んでいるのをみて、日に日に恐怖感を募らせていった。一方で自分の身にこれから起きる何かに若干のスリリングを感じていた。*1

接種日の5日前、私は蕁麻疹を発症した。5年前にも同様の蕁麻疹を発症し、このときは様子を見すぎて意識消失からの救急搬送となり、医者から「次回はすぐに来て。様子を見ていると死亡します」と宣告されている。そんなわけで「これはやばい!このテスト(仕事)してたら死んでしまう!」と、急いで病院に電話したら「外来は受け入れられない」とのこと。地域医療の中核をになっている救急指定病院(三次救急)だし、情勢からみてまあそうなるかもな…と予想はしていたが、医療が逼迫して救える命も救えないってこういうことなんだなと実感した。*2 その後、紹介された町の開業医に診ていただき、薬を処方してもらう。薬を服用してとりあえず蕁麻疹はおさまった。よかった。

ワクチン接種は16時。接種後の待機時間が蕁麻疹のこともあり通常15分のところ30分になった。前の人の椅子の背もたれに貼ってあった 厚生労働省からのお知らせ『新型コロナワクチンを受けた後の注意点』を読んだり、総務や健康支援センターのスタッフの働く様子を見ていた。

30分後、何も異変なく(よかった)職場に戻り、夕会に参加して当日の業務は終了。1回目のときも思ったけど、注射時の痛みが軽減されているなとあらためて思った。針を腕に刺すときは痛いけど、インフルエンザの予防接種のように薬液が入るときのズーンという、あの嫌な痛みをそれほど感じない。インフルエンザと比べて薬液の量が少ないからなのか?

帰宅後、熱を測ったら36.3℃。特に体調に変化なし。夕ご飯を食べたあとすこし胃が痛くなって、ソファで横になっていた。接種してから5時間たった21時頃、接種部位周辺がじんじんと痛くなってきた。経過の詳細を下表に記す。(スマートフォンだと見づらいかもしれない。ごめんなさい。)

結局、ワクチン接種の翌日と翌々日は仕事ができる状態ではなかったので休んだ。モデルナ(武田薬品)ワクチンの副反応としてあげられている症状のうち、発熱、接種部位の痛みと腫れ(表では腕の痛みと記載)、疲労(表では倦怠感と記載)、吐き気があった。また副反応としてあげられていない胃痛もあったが、これは気分的なもの(ワクチン接種と副反応に対するストレス)かもしれない。

体温は38.0℃まで上がったが、これが新感覚だった。風邪をひいて発熱するのとはまったく違う。寒気(悪寒)もなければ、頭痛や関節痛もない。喉も痛くないし、くしゃみ、鼻水も出ない。熱というパラメータがひとりで勝手に上昇した感じ。体温計の38.0の数字を見たときは「これからもっと上がるのかな」と思ったが、1時間後には36.8℃に下がり、数時間後にまた上がったりと不安定だった。測り方がおかしかったのかもしれない。計測器としての体温計の正確性を気にしたことがなかったな、と気づく。

一番つらかったのは吐き気だ。腕の痛みは接種した左腕に圧を与えなければ何とかなる。倦怠感もとりあえず横になっていればどうにかしのげる。でも吐き気だけはだめだ。なにをしても吐き気から逃れられない。普通におなかは空くので食べたいのに気持ち悪くて食べられない。こんなにつらいことがあるか?…と書いてはみたが、表を見ると「食べてる」ので説得力がない。食事を美味しく食べられないのが本当につらかったんだ。わかってくれ。

日付 時刻 体温 コメント 腕の痛み 倦怠感 吐き気 胃痛
8/17 16:00 36.2 ワクチン接種        
  18:00 36.3 帰宅        
  19:00   ちょっと胃が痛い      
  21:00 36.3 腕が痛くなってきた  
      ちょっと気持ち悪い  
8/18 02:00 36.3 目が覚めて水分補給  
  06:00   腕がめっちゃ痛い  
  07:00 36.8 身体が重い
      ヨーグルトを食べる
  08:00 37.0 EVE頭痛薬を飲む
  09:00 37.2 何もやる気が起きない
  11:00 38.0 気持ち悪い
  12:00 36.7 冷麺を食べる ◉   
  14:00   だるくて何もできない ◉   
  15:00 37.6 気持ち悪い ◉   
  16:00 37.3 とにかく気持ち悪い ◉   
  18:00 37.6 お茶漬けを食べる ◉   
      EVE頭痛薬を飲む ◉   
  19:00   すぐ横になってしまう ◉   
  20:00   めっちゃ身体が熱い  
      エアコンをつける ◉   
  23:00 36.6 大量の汗をかいた ◉   
      シャワーする  
8/19 06:00 36.6 昨日よりは楽なのか?  
  07:00 37.6 だめだ、気持ち悪い  
      休暇連絡する  
      ヨーグルトを食べる  
  11:00 37.0 ちょっと気持ち悪い  
  12:00 37.6 かた焼きそばを食べる  
  13:00 37.1 近くで火事が発生  
  16:00 37.1 やっぱり気持ち悪い  
  18:00 37.3 しらす粥を食べる  
      ハーゲンダッツを食べる   
  20:00 37.0    
8/20 07:00 36.4 寝過ぎて腰が痛い      
      気持ち悪くない!      
      今日は仕事できるわ      
  18:00 36.1 腕も痛くない!        

追記(2021.08.28)

接種から10日たったけど、1回目のときのようなモデルナアームにならなかった。 

追記(2021.08.29)

高級なシャンプーとコンディショナーを買ってしまった。副反応だと思う。

 

*1:このあたりがサディステックと思わせる所以なのか? 参考文献:サディステックミワテスト

*2:実際にはいろんなやりとりがあった。5年前のカルテと照合しながらの現況の聞き取り。もう一度受け入れ状況を確認してみるからと短時間に2回も電話をかけ直してくれた。受け入れできないとなったあとも、木曜日の午後(休診が多いのだ)でも受診可能な開業医をいくつか紹介してくれた。午後の診察まで1時間半待たなければならないことを気にしてくれて「もしその間に急変したら救急車を呼んでほしい。急変する前は全身の血管が広がるから寒気を感じることが多い。とにかくいつもと違う感じがしたらすぐに救急車を呼んでください」とアドバイスしてくれた。地域住民からこのような電話がひっきりなしにかかってくるのだろう。丁寧に応対してもらい本当に有り難かった。

JaSST Online Clover に参加しました #JaSSTOnline

JaSST Online Clover に参加しました。 

www.jasst.jp

今回のテーマは「アウトプット(技術の発信)」でした。講演者の御三方(あきやまさん、カズさん、まつさん)は、特に好んで読んでいるブログの発信者で、このような機会がなければ知り得ない「アウトプットの舞台裏」を垣間見ることができました。たいへん貴重なお話をありがとうございました。OST(Open Space Technology)も含めてですが、自分自身のアウトプット活動やそのスタンス、モチベーションなど、普段あまり意識していないことを考える時間にもなりました。

この記事は『私がブログを書くときに大切にしている"たった1つ"のこと』を書きます。そう、あきやまさんのLTのオマージュです。

私がブログを書くときに大切にしている"たった1つ"のこと

私が大切にしていることは「読者はだれか」です。読者と言っても世の中のプログラマーとかテスターとかスクラムマスターとか不特定多数のだれかではなく、具体的な「だれか」を思い浮かべて書いてます。

たとえば、前回のJaSST Online Bergamot に参加したときの記事の読者は

  • シンポジウムに参加した人たち(実行委員を含む)
  • セッション1「探索的テスト」のゲスト:ねもとさん
  • OSTオーナー:しろもとさん
  • OSTオーナー:とろさん

先月のJaSST北海道に参加したときの記事の読者は

  • シンポジウムに参加した人たち(実行委員を含む)
  • 事例セッション『役割分担して行うペアテスト』の講演者:よしたけさん、saeさん

です。

今回シンポジウムに参加して、みなさんのお悩み(なかなかアウトプットできない…など)を聞いて思ったのは「私はひとつひとつの記事に対する想定読者がものすごく狭いから、そんなに苦労しないのかな?」ということでした。仮に QA(品質保証)に関わる人たちに対して何か書こうとしたら「うーむ」となりそうです。

具体的な「だれか」に向けて書くとフィードバックをもらいやすいのも良いところかもしれません。FavやRT(読んだよー)してもらえたら、もうそれだけで満足です。さらにメンションやダイレクトメッセージをいただいたら「私のためだけに人生の数分間を使ってくれた…(尊い)」の気持ち。本当に嬉しいです。

想定読者以外の方に読んでもらえるのも、もちろん嬉しいのですが、想定読者が狭すぎの弊害もあります。たとえば、今回のタイトルを見て「どんなシンポジウムだったのか知りたいなー」と思って開いてしまうと、なにもわかりません。ごめんなさい。#JaSSTOnline でツイート検索すると、参加ブログがたくさんアウトプットされていますので、読んでみてくださいね。

そうそう「読者はだれか」は「じぶん」のときもあります。*1

おまけ1: 書籍『数学文章作法』

参加中に、ふと、あたまに浮かんだのが『数学文章作法』です。正確で読みやすい文章を書く心がけの原則とは「読者のことを考える」であり、その原則を具現化したものが本書です。とても丁寧にわかりやすく解説してあり「読者のことを考える」とは、こういうことなのか!と感動するほどです。

なお、私が大切にしている「読者はだれか」は「読者のことを考える」と言葉は似ていますが、ここに書かれているのとは、まったくの別物です(二冊とも読んだのに身についていないのであった)。

おまけ2:「うまくいったらどうなるの?」

わたしたちのチームでよく使うフレーズに「うまくいったらどうなるの?」があります。私が今回のシンポジウムの主催者ならまちがいなく「多くの参加ブログがアウトプットされる」と定義づけるでしょう。結果は見てのとおりですね。素晴らしいです!

*1:CAT GETTING OUT OF A BAG 読者のみなさま、このブログを読むために貴重なお時間を使っていただき、ありがとうございます。2021.08.04 現在 120名の方に読者登録してもらっています。正確には119名かな。1名は自分なので(自分で自分のブログの読者になれるのかを試したことがあって、そのままになっている)。読者登録してもらったときのリアクション(うれしい!とか)をどうやればいいのかわからなくてなにもしてないのですが、私の書く文章や内容に興味を持っていただけたのかな?と、とてもうれしい気持ちでいます。ありがとうございます。