CAT GETTING OUT OF A BAG

What the tester is thinking.

読書会の設計について #50QuickideasTests

5年前に入手して雰囲気で読んでいた Fifty Quick Ideas To Improve Your Tests (English Edition) の待望の日本語版『ソフトウェアテストをカイゼンする50のアイデア』が出版されました。

この日本語版を使って2022年11月からオンライン読書会を行っています。本記事ではこの読書会の設計について記載します。

読書会の設計

はじめに考えること「読書会で何を得たいか」

オンライン読書会を主催するのは今回がはじめてですが、社内では何回か主催したことがあり、読書会の設計はそこでの経験をベースにしています。いつもはじめに考えるのは「読書会で何を得たいか」です。今回は自分が言い出しっぺなので考えるまでもないのですが、社内だと同僚や後輩から受ける相談から「◯◯の本を使って、読書会をしてみようか」となる場合もあります。読書会の初回には必ず「何を得たいか」をみんなで話します。*1

たとえば、話題の新刊をみんなで読もうぜ!となったときも「何を得たいか」を言葉にしておくと、読むことが目的にならず、得たいものを得ようとする読み方、時間の過ごし方になるのでおすすめです。何を得たいかを全員で一致させる必要はないですが、あの人の「こんなことを得たい」を知ってしまうと、それにつながるような何かを教えてあげたくなりますよね。*2

どういう読書会にしたいかを共有する

読書会の初回(0回目)に主催者3名で、どういう読書会にしたいかを話しました。こうしたい、こうなったらいいな!だけでなく、やりたくないことや、こうなったら困る、嫌だ、も話します。このイメージが共有できると、読書会の最中にそこから外れたり、迷走したりしても、誰かが気づいて本線に戻りやすくなります。事前に防ぐという強制力はあまり期待してません。諦めているわけではないけど、そうなってしまうときはそうなってしまうので、なるべくコストをかけないで戻れるようにしておくのがいいと思ってます。

読書会ではなく読書会を聴く会というスタイル

今回はおしゃべりがメインなので主催者3名で読書会をやることにしました。延長なしの1時間で音読もして全員にパスを回すには5名が限界かなと話していたのですが、毎回2名を募集するのはいろいろ面倒なのでやめました。読書会を公開するか非公開にするかは、わりと早いうちから公開する方向で話していました。ただ、自分たちは本の中身に集中したいから、それ以外のことに気を配る余裕はないよね。でも参加してくれた人たちを感じたいし、すこしは交流もしたいな、というわがままな願いを叶えてくれたのが「読書会を聴く会」というスタイルでした。インタラクティブさがほどよく低くて、今のところとてもよいです。

リスナーに読書会のイメージをどう伝えたか

オンライン読書会といえばそうなのですが「オンライン読書会」の言葉から想像するものは人によって異なります。この読書会のイメージに賛同してもらえる人に聴きにきてもらいたい。そのイメージをどう伝えればいいのだろうと悩みました。試しに一度だけ聴いてもらえればわかるのですが、そのためにわざわざ時間を調整してもらい、その結果「自分には合わないな」となったら申し訳ないし、がっかりされるのも嫌だったのです。

そこで、connpassで参加者(リスナー)を募集するときに「読書会をやろうと思ったきっかけ」を載せることにしました。ここに読書会のイメージも書きました。

読書会をやろうと思ったきっかけ(connpassに載せているものを転載)

日曜日の昼下がり、日々の開発風景を思い浮かべながら、手に入れたばかりの『ソフトウェアテストカイゼンする50のアイデア』を読んでいました。翌日の朝、#テストラジオ でパーソナリティのなそさん(@hiroyuki3gou)と、よしたけさん(@yoshitake_1201)がたまたま(偶然!)本書の感想を話していて「ああ、こういうのいいな!」と思いました。同じ本を読んだ開発者が何を思い、何を考えたのかを知ることは、自分が経験したことのない開発や、自分には無い考え方や捉え方や読み方に出会えるチャンスだからです。

数名で読書会が開催できればそれでよいので非公開でもよかったのですが、わたしと同じように「自分以外の開発者が何を思い、何を考えたのかを知りたい」と思う人にとっては多少なりとも価値があると思い、公開することにしました。チャット欄を用意しますので、自分はこう読んだよとか、思ったことや考えたこと、実際にやっていることなど、ぜひ書き込んでください。わたしが喜びます。聴き専(耳だけの参加)でもまったく問題ありません。

おしゃべりがメインなので、早く読み終えたい方や書いてあることを正しく理解したい方や正解を知りたい方には向きません。うすうす感づいてる方もいるかもしれませんが、何かを解決してすっきりするような感じにもならなそうです。楽しみ方や面白がり方は参加者のみなさんに委ねたいと思います。

2022年の新語として「タイパ(タイムパフォーマンスの略語)」が話題になりましたね。これを読めば、タイパ重視の人がうっかり参加してしまうことはないと思います。

読書会のすすめかた

本番の読書会のはじめからおわりまでイメージしながらひとつひとつ決めました。全体をとおして意識したのは「無理をしない」です。ずっと同じペースで物事を楽しむための原則です。

無理をしない

読書会の形式として『読書会という幸福 (岩波新書)』では、①おすすめの本を紹介し合う読書会、②朗読を採り入れた読書会、③輪読形式の読書会、④同じ本を読んできて話し合う読書会、の4つが紹介されています。①③④は予習が必要な読書会です。

今回の読書会は(無理をしないので)予習は無しにしました。宿題(読書会で話した内容をブログに書くなど)もありません。だから読書会の本番の1時間に集中できます。*3 

隔週開催にしたのもそうです。毎週やるとなると「ちょっとしんどいな…」と思うときもありそうですよね。1週間ってあっという間だから。読書対象をChapter 1(13アイデア)に絞ったのもそうです。本書はタイトルのとおり50のアイデア*4が掲載されてます。隔週開催となると1回1アイデアを読んでも2年はかかります。うわー、2年かー、2年やるのはちょっと自信ないな、となって、まずはChapter 1(13アイデア)だけやってみることにしました。まだはじまってないのに、どうやっておわりにするかをみんなで考えていました(笑)。

すすめかたの要点もconnpassに載せました。

すすめかた(connpassに載せているものを転載)
  • 書籍『ソフトウェアテストカイゼンする50のアイデア』は各自用意する
  • 本書、本文は画面共有しない(映さない)
  • 読書対象:まえがき、本書について、Chapter 1(13アイデア
  • 開催は木曜日 20:00-21:00(隔週)
  • 祝日はやらない
  • Discordのボイスチャンネル、テキストチャンネルを使用する
  • ボイスチャンネルはマイクミュートで参加してもらう
  • 数段落を音読→おしゃべり を繰り返す
  • 気になる書き込みは読んで紹介したい
  • まとめない(おしゃべりしたことがすべて)
  • 読み急がない(1回1アイデア読了を目指さない)
  • 読み進めることを目的にしない
  • 録画、録音はしない
  • ツイートやブログはOK
  • ハッシュタグ #50QuickideasTests

読書会中にBGMを流しているのも「無理をしない」に関係してます。本を読みながら自分の頭で考える読書会なので、全員で「うーん」と考えていると沈黙の時間を配信してしまいます。このときに無理をして話そうとしなくてもいいように、余計なプレッシャーを自分たちが感じなくて済むように、お手製のBGM*5を流しています。

また、connpassの参加募集のタイトルに連番(第n回)をいれるかいれないか、のような細かいことも話し合いました。連番をいれると何がお得か?タイトルで何を知りたいのか?連番でなくむしろ日付をいれたほうがいいのか?みたいな話を真面目にやりました。連番をいれると新しいリスナーの参入をさまたげるのではないか?とかね。最終的には連番にはあまり意味はなく、毎回カウントアップするのは手間だし、きっといつか間違えるよね、となって連番なしになりました。

アンチハラスメントポリシー

CC-BY-4.0で公開されている「TokyoGirls.rb アンチハラスメントポリシー」を元にこの読書会のアンチハラスメントポリシーを作成してconnpassに載せています。何もないところから作るのは大変なので助かりました。ありがとうございます。

設計を見直してより良くしていく

読書会を数回行った状態でこの記事を書いているのですが、イメージしていた読書会ができていると感じます。参加者のみなさんがそうなるように行動してくれているからだと思います。ありがとうございます。

読書会を開催するにあたり、ここに書いてないことも含めて設計してきましたが、あることをしたおかげで、設計の見直しが無理なくできるようになりました。それは connpassに「読書会をやろうと思ったきっかけ」と「すすめかた」を載せたことです。もともとは参加するかしないかを判断してもらうために載せたのですが、新しい参加募集をconnpassで作って内容を確認するときに、自然にそれが目に入るので隔週で読み直しています。設計を見直すためにわざわざアクセスしに行くのではなく、やることに組み込まれているから、とても楽だし気分がいいです。

さっそく見直しました

前回(2023年1月26日)の読書会で「ここだけの話」をしました。感想ブログをUpしてくださった方がいい感じに書いてくれて何も問題はないのですが「ここだけの話」の判断を聞き手に押し付けているなと感じました。"ここだけの話ですけどー" という前置きを聞き逃す可能性だってあります。読書会で話したことをツイートしたりブログに書くことはOKにしているので、今後は外に出せない話はしないようにします。書きたいなと思ったときに安心して書いてもらえるように。

このようにちょくちょく見直しながら、全員が気持ちのよい時間を過ごせるよう、より良くしていきたいと思います。

*1:訓練されているブログ読者は「うまくいったらどうなるの」を想起しましたね。正解です。

*2:今回わたしはこれを発動しています。

*3:今回の読書会は②に近いのかなと思いきや、本文の説明を読むとぜんぜん違います。世の中にはいろんな読書会があるのだなぁ。

*4:日本語版には訳者の山口鉄平さんによる特別寄稿の4アイデアも収録されています。

*5:あとで書く

わたしがテスターとして恐れる「慣れ」について

ソフトウェアテスト Advent Calendar 2022 - Qiita 19日目の記事です。

はじめに

 「慣れ」の違和感に鈍感になっているな、と思うときがあります。失敗の言い訳に「慣れのせい」と思ったり、誰かがそう言うのを聞いたりすると、なんとなく釈然としない気持ちになります。こういった種類の違和感をいちいち表明するのもなんだか面倒になって……というより、仕事中はもっと具体的な問題や課題を大切にしてしまいがちで、つい「まあいいか」となってしまうのです。これはよくないよね。

慣れの違和感の正体

 より良い製品をつくるために製品や開発に関する知識や失敗を含む経験は不可欠です。知っていることが増えれば増えるほど、調査や試行錯誤にかかる時間、ゴールに到達するまでの時間を減らせます。製品の細部にまで自分たちの知見(あたたかい血)を巡らせることができます。これはプログラマもテスターもみんなそうです。開発者が製品に慣れることは自分たちにとっても、最終的にはお客さまにとっても良いことです。

 慣れているから朝会や夕会でスクロールされるチケットのコードからミリ秒でバグを見つけられますし、1つのテストで2つの深刻な問題をあぶり出し、加えて近い将来バグとなって現れるであろう設計や実装の危うさをも提起する、なんてことがスッとできてしまうのです。

 たまに(製品に慣れてない)専門家のほうが多くのバグを出せると言われ、返答に困ることがあります。ほんとうにそうでしょうか? もしそうだとしたら、それは単に自分たちがうまくないだけです。とことん製品を知り尽くすべきだし、圧倒的に慣れたほうがいいのです。

”言われてみれば「たしかにそうだ」とわかるのに、いつも見ているあの画面のおかしさや、使いづらさを感じなくなっていました。”

”ちょっとした応答の遅れを感じたのに「ここはハードウェアとやりとりしてるところだから、こんなものかな…」と流してしまったのです。今まさに新しい問題が起きているというのに!”

 一度でもこのような体験をしたテスターならわかるでしょう。問題を見逃したことにも相当落ちこみますが、「慣れ」をコントロールできなかった事実に恐ろしさを感じたと思います。でもそれって本当に慣れたからなのでしょうか?

トッププログラマは慣れでミスをするか

日本のトッププログラマ*1のひとり @m_seki に聞いてみました。

miwaちょっとおかしいと思っていたコードがあったとして、見慣れるうちにおかしいって思わなくなったりする?

咳「えー。おかしいコードは、見慣れてもおかしいよ?」

miwaそうだよね。じゃあ、ツールや言語に慣れたらプログラミングでミスする?

咳「そんなことありえない。慣れでミスしない。(自分の場合は)下手くそだからミスすることが多いかな。むしろ慣れが足りない。

 予想どおりの回答です。おかしいコードをずっと見ていたら、おかしくないコードに見えるでしょうか。いいえ、おかしいコードはいつ見てもやっぱりおかしいと感じるはずです。そのロジックでいくと、製品に慣れていてもおかしいものを見たら、毎回おかしいと思わないとおかしいのです。

 先にも書いたように「慣れ」自体は悪いことではないので「慣れすぎて」というのは、聞こえのいい言い訳やなぐさめのようにも思えてきます。人間は認知バイアスによって思いこみや慣れや経験により間違った判断をする場合があります。だから、そうなってしまうこと自体はある程度仕方ないと、自分の感情をうやむやにして言葉をのみこんでしまう。これらの総和が違和感の正体かもしれません。

信じられないものを信じる練習をしている

「クリフォードは、定員いっぱいの乗客を乗せて出航しようとする移民船の船主を例にあげた。この船主は、船が古くて状態が悪く、そもそも造りがあまりよくないことを心配していた。もう一度無事に航海できるかどうかは疑問だと真剣に考えていた。しかし、船主はなんとか疑問を打ち消し、あと一度だけ航海したからといって、たいした危険はないと自分に思い込ませた。この船はかつて何度も嵐にさらされたが 、いつもどうにか港へ戻ってきたではないか。もう一度できない理由はあるまい。船は出航し、乗客、乗組員もろとも沈没した。」

ー『熊とワルツを リスクを愉しむプロジェクト管理』トム デマルコ,  ティモシー リスター著

 おかしいものを見てもおかしいと思わなくなっているとしたら、それは「慣れ」ではなく、この船主のように、信じられないものを信じる練習●●●●●●●●●●●●●●をしてしまっているのかもしれません。まずはそれを解除しましょう。仕事をはじめる前に「自分は信じられないものを信じる練習をしているのかもしれない」と思うと、物事を感じる周波数をすこし変えることができます。昨日となにも変わらない見慣れた風景なのに「本当にこれでいいんだっけ?」と気になってくるはずです。

 次のようなことを試してみるのもよいでしょう。

  • 現象だけに注目するのではなく、なぜそうなるのかに意識を向けます。それが許容できるかどうかだけでなく、どのような仕組みでそのようなふるまいになるのか疑問を持ちましょう。
  • これで良いはずだと信じるなら、信じるに至る理由や根拠をあげてみましょう。◯◯さんがそう言ったからとか仕様だからは理由や根拠になりません。「これはほんとに素晴らしい仕様だろうか?」と自分に(みんなに)問いかけてみましょう。
  • 中長期にわたる製品シリーズの開発では「ずっと前からそうなっている」を免罪符にしてしまうことがあります。なぜその仕様やデザインが今も●●素晴らしいと言えるのかを自分の言葉で説明してみましょう。
  • "見送り"、"暫定"、"様子見"、"とりあえず"、”次バージョン以降で対応” のような、あなたのチームで使われている特別なキーワード、方言、フレーズでチケットを検索してみましょう。信じる練習済みのイケてない仕様や設計、当時の対応に出会えるかもしれません。
  • おかしさや違和感や異常を感知しなくても、自分の意識下にある前提や目の前の当たり前をひとつひとつ疑う癖をつけましょう。

おわりに

 わたしがテスターとして恐れる「慣れ」について思うことを言葉にしてみました。「慣れ」ではなく「慣れのせいにする状況」を恐れるのが良さそうですね。これなら自分でコントロールできるから恐れなくてもいいのかも。

 昨日よりも今日、今日よりも明日の自分の思考や言動が、まわりの人たちに良い影響を与えられるよう、日々研鑽*2を重ねていきたいと思います。

あわせて読みたい

書籍『熊とワルツを リスクを愉しむプロジェクト管理』のKindle版のサンプル(無料)をダウンロードすると引用した部分を含めた「プロローグ」全文を読むことができます。示唆に富む内容で読むたびに「ふふっ」となります。全文良すぎて今回どの部分を切り取るか悩みました。お時間のあるかたはぜひ本記事とあわせて読んでみてください。

この記事を書くにあたり、書籍『ソフトウェアテスト293の鉄則』を読み返しました。本記事と関連しそうな鉄則をあげておきます。わたしにとってバイブル的な書籍の1冊です。

  • 鉄則018「認知心理学も駆使する」
  • 鉄則039「思い込みから逃れられなくても、上手く付き合うことはできる」
  • 鉄則040「騙されやすいと自覚することが騙されない秘訣」
  • 鉄則043「慣れは見落としの素、新鮮な眼をいつも絶やさずに」

druby.hatenablog.com

いつものやつを貼っておきます。文中の"プログラマ"をご自分のロールに置き換えて読んでみてね。

*1:書籍『プログラマが知るべき97のこと』の帯に"トッププログラマ"と書いてある

*2:とちぎRubyの勉強会で 書籍『研鑽Rubyプログラミング β版 – 技術書出版と販売のラムダノート』を読んでいて"研鑽"という言葉がマイブーム ←死語?

わたしの周りにいる女性の技術者たち

今から53年前の1969年7月20日(日本時間21日)。アポロ11号の飛行士が人類で初めて月に降り立ちました。自分の誕生日(1969年7月19日)と近いこともあり、アポロ計画、宇宙開発に関するドキュメンタリーを好んで読んだり観たりしています。

A Galaxy of Her Own: Amazing Stories of Women in Space

これは宇宙で活躍する50人の女性の物語が描かれた絵本です。自分が生まれるずっと前から、宇宙開発の現場で活躍していた女性のプログラマーや数学者がいたこと、世界中に何千人もの女性(多種多様な業種、職種)が宇宙飛行に関して重要な役割を果たしてきたことは、同じ技術者としてとても嬉しく、誇らしい気持ちになります。わたしもまだまだやるぞ!と勇気づけられます。そう、53才になっても心が浮き立ってしまうのです。

わたしの周りにいる女性の技術者たち

製品開発(ソフトウェア開発)の仕事に就いて30年以上になりますが、わたしの周りにいる女性の技術者たちも、ひとりひとりにきらめく個性があり、面白くて、柔軟で、優れています。仕事をとおして発せられる彼女たちの言葉、物事に対する細やかさ、注意深さ、緻密さ、発想の豊かさ、鋭さ、大胆さ。それらを目の当たりにしては「素敵だな」「◯◯さんのそういうところが素晴らしいな」と思います。道のりは違うかもしれないけれど、それぞれのミッションに向かって彼女たちと働けることが嬉しいのです。

先月、となりのチームに女性の新入社員が配属され、自分でもよくわからない「特別感のある嬉しさ」を感じました。どんな技術者になってもらいたいかをテーマにお話したとき、彼女に希望をたずねたら「いまはなんでもやってみたいです」と力強い言葉が返ってきたのです。「ああ、とても良いなあ、こんな技術者の卵と一緒に仕事ができるなんて幸せだ」と思いました。

この感情は3年前に別のチームに女性の新入社員が配属されたときも感じました。彼女の場合はプログラマーとしてやっていけるかな…と心配しましたが、今ではすっかりプログラマーです。うまく動いているのに腑に落ちないところがあると、そのままにしないで先輩に教えを乞うのです。一通り教えてもらったけど、それでもまだわからないときに、わかったふりをしない。簡単にはあきらめません。それが彼女の良いところです。

今は育児休暇中の女性の技術者もきっといつか職場に戻ってくると思います。そんな日が来るのを心待ちにしています。彼女は言葉数は少ないですが、周りに流されず、自分の頭でしっかりと考え、ちょっと変わった視点で物事を見ることができます。「あれ?」と疑問に思う力を自然に発揮して、また活躍してくれるはずです。

 

周囲を見渡すと多分に漏れず男性が多い職場ですが(女性比率は10%未満です)入社したときから「これが普通」と違和感もなく何十年も過ごしてきました。でも、わたしが女性の技術者に対して「特別な感情」を持ってしまうのは、もしかしたらどこかで「少数派であるわたしたち」を感じているから、なのかもしれませんね。

わたしはこれまでもこれからも、これをお読みの皆さんや、皆さんの大切な方の役に立つ製品を丁寧に作っていきたい。この1年も無理をしないで自分らしくやっていこうと思います。

ー 53才の誕生日に寄せて ー

 Remember, find your passion in life, whatever it might be. Never lose sight of it and don’t be afraid to tell anyone what it is. Seek out opportunities and grab them wholeheartedly. Don’t shy away from making difficult decisions, and never be scared to ask. You can do anything you set your mind to. Above all, have fun and enjoy all you do, life is too short for anything else.

A Galaxy of Her Own: Amazing Stories of Women in Space (English Edition)Libby Jackson

あわせて読みたい

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

JaSST Online Daisy に参加しました。 

www.jasst.jp

今回のテーマは「バグバッシュ」でした。

実際に運用されているプロダクトをお借りして、参加者全員が自ら手を動かしバグを探していきます。プロダクトの要件や仕様を学習しながら自身の経験や考えをベースにテストする、つまりは探索的テストに近いことを実践するという会です。しかし、それだけではわざわざ集まって同時刻に行う必要がありません。Daisyで行うのは、複数人で行うモブ探索的テストになります。まったく分野の異なる業界の人、異なる世代の人、探索的テストの経験がある人ない人と、多様なメンバーで構成されたグループで、テストを共に行います。(JaSST Online Daisy 開催要項から一部抜粋)

"バグバッシュ"や"モブ探索的テスト"という言葉は知ってましたが、実際にやったことがなく一度体験してみたかったのと、他社製品をテストするためにお金を払うんですから(しかも土曜日だよ?)相当変態おかしな種族が集まるに違いないと、すぐに申し込みました。当日は全国から相当変態おかしな種族が30数名集まり、9チーム(1チームが3、4名)にわかれて、実際に運用されているプロダクト(Webアプリケーション)を使ってバグバッシュしました。

この記事では、Daisyで「よいテストができた」と実感したので「なぜそう感じたのか」につながるいくつかの要素を、自分のこれまでの経験や考えかたを織りまぜて言葉にしておこうと思います。なお「バグバッシュをするとよいテストができる」という内容ではありません。

テストのテーマが自然に決まった

わたしたちのチーム(3名:よしたけさん、まこっちゃん、miwa)は自己紹介の時点で

  • テスト対象プロダクトを触ったことがない(見たこともない)
  • プロダクトの要となるコア機能をテストするには知識が足りない

ことがわかりました。*1これから短時間でテストしなきゃならないので条件としてはわりと最悪ですが、テストのテーマ(方向性)を決める上で重要な情報です。早々にコア機能はテーマから外しました。開発者と同等の幅広い知識がなければ、そのふるまいが正しいのかそうでないのかは判断できないからです。

バグバッシュ4ターン(1ターン20分)のうち、はじめのターンはテーマを決める時間にしました。テスト対象プロダクトを動かしながらどのようなことができるアプリケーションなのか、それぞれが理解したことをおしゃべりしていく中で、こんな会話がありました。

「プロダクトとして起きたら困ること、嫌なことはなんだろうね」

「開発者(テスター)が確認しづらいところはどこかな」

「どんなバグを見つけたい?」

さらに、今回のテスト形態(3名が各リモート拠点でテスト対象プロダクトを同時に操作している)も相まって、テーマ「競合状態」が自然に決まりました。自分たちの身の丈にあった無理のないテーマ選定ができたと思います。

時間が制限されている

バグバッシュのタイムテーブルが詳細に決められていたので*2それに従ってやるしかないのですが、時間が制限されているのはいいことです。これしか時間がない!となれば、その時間を一番うまく使うにはどうすればよいかを自然に考えるし、チームや自分にとっていま一番価値の高いもの、高そうなものを選べます。というより選ぶしかなくなります。テストも同じ。時間もちょっと足りないくらいがいいんだろうなと思います。今回のバグバッシュはちょっとどころか全然足りなかったです(だからたぶんいい)。左脳でバグの姿を思い描きながら、複数の拠点で同時に同じ操作をしたり、関連すると思われる処理やデータを競合させるつもりで動かしました。わたしとまこっちゃんは熱中しがちで*3よしたけさんがタイムキーパー係りをしてくれなかったら大変なことになっていたと思います。

休憩時間も本当はプロダクトを触っていたかったけど、テストの時間に一番いい状態(全身全霊を使って集中できる状態)に持っていくには、休憩時間は休憩するのが一番価値が高い行動です。そう自分に言い聞かせて頭や身体を休めました。

バグが見つかる、見つからないはあまり関係ない

これは普段の開発(仕事)でもそうなので「ああやっぱりわたしはそうなんだな」と確信することができました。バグが見つからなくても「いまのはよいテストだったな」と思うことはよくあります。頭の中にある「こんな風に動いてほしい」「こんな問題が起きたら嫌だな」を元にテストにするわけですから、バグが見つからなかったということはうまく動いたってことなんですよね。「うおーーー!こんなにひどいことをしたのに、ちゃんと動いてる!すごーい!すばらしい!!」と嬉しくてたまらなくなります。一方でたまたま通りがかって見つけたようなバグは「今日見つかってよかった」とは思いますが「よいテストができたな」とは思わない。なんとなくわかりますか?*4

今回のバグバッシュでもチームで見つけたい具体的な問題がありました。

「◯◯がおかしくなるバグを見つけたい!めっちゃ見つけたいんだけど!」

「それを見つけるためにはどんなことを試せばいいと思う?」

みんなで知恵を出し合い、具体的なテストに変換して実行しました。プロダクトのふるまいの様子を観察しながら、どのように設計、実装されているかを予想し、操作のタイミングや条件を変化させながら時間ぎりぎりまでテストし続けました。

結局「◯◯がおかしくなるバグ」は見つからなかったのですが、それはテスト対象プロダクトが期待したとおりに動いているということです。「おお〜!ここは矛盾しないようにちゃんとできてる!すばらしいね!」と、わたしはいつものように騒いでいたのではないでしょうか。*5

テスト対象プロダクトの開発者(テスター)になりきる

なりきらなくてもよいテストはできると思いますが、わたしに関してはなりきったほうが「よいテスト」ができるような気がするので、今回のバグバッシュもそうしました。胡散臭い言葉を使うと「当事者意識」というものですが、意識とかはどうでもよくて、そのプロダクトの開発者(テスター)になりきるんです。当然よしたけさんとまこっちゃんは同じチームの同僚という設定です。お二人はどう思っていたかわかりませんが、わたしははじめからそういうつもりで接していました。だから困ったことがあればすぐに「わかんないんだけど!」と助けを求めましたし、こうしたほうがいいなと思ったことは躊躇しないで言いました。プロダクトに直接関係ないことも「ぜんぜん関係ないことなんだけど話していい?」と聞き、なんでも話しました。

これに関しては(たぶんわたしだけが)感動したエピソードがあります。

本会の終盤に「見つけたバグを他のチームに共有するセッション」がありました。何をどのように発表するか事前に話し合ったのですが

miwa「テーマを競合状態にしたのはそうだけど、コア機能をテストするには自分たちは知識が足りなかったことは言ったほうがいいと思う(コア機能に未知の問題が潜んでいたら単なるバグではなく会社自体の信用を落とすことにつながるので、そこを狙うという作戦もありといえばありだった。でもできなかった)」

と言ったら、まこっちゃんが困った感じになったんですね。全員カメラオフだったので顔は見えないのですが、微妙な空気感と話してくれた内容や口調ですぐわかりました。ここで感動したのです。ああ、ちゃんと自分の気持ちをそのまま伝えてくれてるんだなって。言いづらいこともお互いに言い合えてるな。とても自然だな、と。それが嬉しかったのです。

miwa「うん。まこっちゃんが発表者だから、まこっちゃんが言いづらいならそれは言わなくていいことにしよう」

雑にまとめると、4時間しか一緒にいられなかったけど自然体でいられるいいチームになれてたよね、ということです。*6

開発者が見つけてもらいたいと思える課題や問題にフォーカスできた

バグバッシュが終わった時点で「よいテストができた」と感じていたので、これは後付けですが、いい話なので書き残しておきます。

本会の最後に表彰式がありました。テスト対象プロダクトの開発者(本物)がバグバッシュで検出したバグの中から最優秀バグを選んでくださいました。ちがうチームのバグが選ばれましたが、内容を聞いてびっくり。わたしたちも見つけていて話していた現象だったのです。

そんなわけで、表彰式そっちのけで(すみません)チーム専用チャットRoomで盛り上がってしまいました。まこっちゃんは悔しがって表彰されたがっているわで(副賞がほしかったみたい)あーもーーだから表彰なんてしなくていいのにーーと思いながらも、そのおかげで「テストの狙いどころとしては悪くなかったんだな」がわかってしまい、みんなで「よいテストができたね」と喜び、お互いを称え合いました。こういうのはテスター冥利に尽きますね。

おわりに

Daisyで感じた「よいテストができた」をそのままにしないで「なぜそう感じたのか」につながるいくつかの要素を、自分のこれまでの経験や考えかたを織りまぜて言葉にしてみました。

前述したように、本気のテストをはじめる条件としてはわりと最悪でした。(実際の製品開発ならありえない)

  • テスト対象プロダクトを触ったことがない(見たこともない)
  • プロダクトの要となるコア機能をテストするには知識が足りない
  • そんな3名が揃ったテストチームがたったいま誕生した

それでも「よいテストができた」と感じられたのは奇跡かもしれません。*7

この記事を書きながら「自然に」「自然体」という言葉を何度も使っていることに気づきました。わたしは何かが自然にできる状態の中からよいテストができる(できやすい)のを無意識に感じていそうです。だとしたら「無理なく自然にできる状態を作ること」から何かヒントが見つかるかもしれませんね。

*1:初対面の人に「できません」「わかりません」を表明するのは勇気がいると思う。真摯だな。

*2:バグバッシュ特有の役割(ドライバー、ナビゲーター、バグ起票担当)ローテーションの時間管理はポモドーロテクニックを使っているのかな。休憩時間や小さなふりかえりも入っていました。

*3:まこっちゃん、普段の開発(仕事)でも競合状態を攻めてるだろっ!て感じでした。やること見てるとそういうのがわかるよね。

*4:何をやってもすごいバグを見つけてしまう特別な日があります。そんな日は「ゾーンに入ってる」と思うんですが、これまでに数回しかないので偶然かも。

*5:熱中しててあまり覚えていない…

*6:ここまで書いておいてなんですが、実はよしたけさんのことは以前から知っていたので、チームとしてのベースは半分くらいはできていた。

*7:メンバーに恵まれました。よしたけさんとまこっちゃんのおかげです。ありがとうございました。特によしたけさんはバグバッシュの役割云々を超越したところから、プロダクトも含めてチーム全体を自然に見てくれていて助かりました。よしたけさんの話す内容から、わたしとまこっちゃんが見えてないことを見ているのがわかったので、早いうちから安心してテストしてました。あと、わたしのバグ起票担当を押しつけてすまんかった。でもあんな風に書けないから仕方ないんだ…

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

※ この記事は『テストラジオ 第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:そう!間違えるからルールにしません。ルールだからやる、はよくない。ルールにすると間違いに気づけなくなります。