CAT GETTING OUT OF A BAG

What the tester is thinking.

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

今から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:そう!間違えるからルールにしません。ルールだからやる、はよくない。ルールにすると間違いに気づけなくなります。

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

先日行われた某チームの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が出演していて、なんとなくテストデータとして使用しました。この不具合は「サラの呪い」と名づけられています。