判断に迷うときは「NG」にする

普段、わたしが心がけていることの１つに『判断に迷うときは「NG」にする』があります。目の前のふるまいが正しいのか間違っているのか判断に迷うとき、いったん「NG」にしてチームのみんなに問うのです。*1

例えば「これまで何年間もそのテストはPassし続けてるけど、いま触ってみたらなんとなくおかしい感じがする（でもずっとPassしてるんだよな…）」とか「すこし気になるけど、こう動くのはおそらく正しいのだろうなぁ」とか「こんな操作、お客さまは絶対にしないのは自分でもわかってる。わかってるけどわかったうえでこんなにひどいことをしました、とプログラマーに告白するのはいささか気が引けるな（どうしよう）」のようなもの。頭の中に「おそらく」「きっと」「多分」「〜だろう」のような確実さの度合いをあらわす副詞が浮かんだら、正しいほうではなく間違っているほうに倒します。

また、判断に迷う以前の行動として「いま自分は間違っている理由ではなく正しい理由を探そうとしている」ことに気づいたら（ちょっと気をつけなさいよ）と自分に言い聞かせます。あとこれはわたしだけかもしれませんが、脳が疲れてくると「正しいことにしたい気持ち」が若干強くなるような気がするので、疲れを感じたら休むか、そのときはあえて判断しないようにしています。

今ではこうすることに慣れてしまったのですが、NGにしたものがNGでなかったとき（正しいふるまいだったとき*2）は、自分のせいでチームの人たちに迷惑をかけてしまった、みんなの貴重な時間を奪ってしまったと申し訳なく思う気持ちと、自分が無知であることをひけらかしてしまって恥ずかしい気持ちが入り混じりなんとも辛いんですよね。

でもこのときこそ自身の学習の絶好の機会でもあるし*3、あとから問題が発覚して「ああ、あのときのあれはやっぱり間違っていたんだ…」と思うよりずっといいです。

こうすることにしたきっかけはあれかな。数年前、隣のチームのテスターと一緒に（７、８名いた）より良いテストのやりかたについて座談会をしたときに、困っていることや悩みごとを話す中でみんなで決めたんです。判断に迷ったときは「NG」にしようって。

正しいかもしれないことをNGにするのは今でも躊躇するけど、こんな風に「きまり」になっているとぐじぐじしないで「きまりだから言うかー」と思えるのがよいです。気分的にとても楽。みんなで決めたいくつかの「きまり」は小さなカードに印刷して*4事務机の上に置きいつも視界に入るようにしています。

*1:同僚のテスターやプログラマーに話したり、Bugチケットをあげて全員に見てもらうこともあります。

*2:偽陽性とも言いますね

*3:同僚が提起したNGから学習することも多いです。そんなときは「わたしも知らなかったから勉強になったよー、ありがとう」と言います。自分も同僚にそう言われて救われたし、お礼を言ってもらえて嬉しかったから。

*4:パウチしてある。パウチ知らないか…

ふりだしに戻る

うちのチームのチケットには開発日記が書かれています。その日に起きたことやこれから試そうと思っていること、気になっている部分のコードの断片や「誰それがこう言ったから（仕方なく）こうした」など、内容はさまざまです。毎朝同じ時間に同じ場所でこれらをみんなで読み合わせ、質疑応答を繰り返していきます。わたしはそこで思いついたテストのアイデアを話しながら、ここに書いてない+αの情報を脳内に配線していきます。

プログラマーがコミットしたあと、わたしは新たな気持ちでこの開発日記を読み直し、そこでまたなんらかの着想を得ながらテストしています。さっきも書きましたが、開発日記には設計／実装中に起きたこと、やったことの全てが書いてあるわけではないので、朝会や普段の会話から知り得たことやそれまでの経験から行間を補完します。その結果、出力されたわたしの思考や行動やテストが明後日の方向に行ってしまうことがあるのです。

たとえば、人間がやる（手動）テストとしては相応しくない（うまく狙えたのかどうかはわからない）。そこを保証したいのならコードを見て理詰めでやるべきだ。あなたの心配しているそれはもっと上位の仕組みでカバーされている（しかも長い間問題なく動いていて「枯れて」いる）…とかね。「まあどうしてもやりたいならやってもいいけどバグは出ないと思うよ」と言われたりします。

疑ってもあまり意味がないことに時間とエネルギーはかけたくないので、どうにかしたいなと思うのですが、明後日の方向に行っているかどうかはその出力が表沙汰にならないとわからない。となれば出来るだけ早いうちに表面化すればよさそう。なんですが、明後日の方向に行ってしまったおかげで見つけることができた価値のある課題や問題もあるのですよね。これがわりと少なくなくて捨てがたい。よって「しばらくこのままでいいか！」となり、ふりだしに戻るのを何回も繰り返しています。*1

*1:うちのチームはソフトウェアのバグだけではなく人間の行動バグもかなり早いうちに検出していると思うのですが、自分の中で（ああこの３０分はもったいなかったな、どうにかしたいな）という気持ちがこの記事の元になっています。

チームが「サイロ化」しないための仕掛け

テスターのくせに Janet Gregory さんと Lisa Crispin さんの書籍『Agile Testing』『More Agile Testing』を読まずに今日まできてしまったのですが、この二冊を凝縮（Condensed）した『Agile Testing Condensed』（日本語訳）くらいは目を通しておかないとね！ということで読みはじめました。

leanpub.com

この記事は本書に書かれていたある問題を取り出し、それに対してわたしたちのチームが普段やっていることをわたしの目線で紹介したものです。ツイートするには長いのでこちらに書きました。

チームが「サイロ化」する問題

複数のチームがすべて同じプロダクトで作業している大規模な組織でよく見られる問題の1つは、チームが「サイロ化」する傾向があることです。依存関係を解決するために他のチームと話すことを忘れています。（第3章：アジャイルにおけるテスト計画）

サイロ化とは：企業のある部門が、他の部門と情報共有や連携などをせずに独自（単独）に業務を遂行し、孤立してしまう状態のこと。

たしかにそうなりがちかもしれませんね。わたしたちが開発してるプロダクトもまあまあ大きいのですが、なるべくそうならないようにするためにいくつかの仕掛けがあります。仕掛けと言っても、普段なんとなくやり続けていることがサイロ化しないための行動やふるまいだったんだなと思うわけで、はじめに「仕掛け」があったわけではないのですけど。*1

以下に隣のチームとの仕掛けのいくつかを紹介します。隣のチームはプロダクトを構成するシステム（ソフトウェア）の構造的にもわりと近い存在です。それぞれのチームの規模は小学校の1、2クラスを想像してください。*2

毎朝10分、隣のチームと会話する

• 毎朝10分（8:45〜8:55）同じ場所に集まり、話をしています。
• 参加者：隣のチームリーダー（2名）、うちのチームリーダー、テスター（2名）、@m_seki（プロの無職）*3
• 開発状況に合わせて期間限定で特定のプログラマーが参加することもあります。
• 話す内容はいろいろ（一例）
• 昨日見つけた問題についての補足（チームを超えてチケットをあげている）
• チケットにあげてないが気になっていること、心配していることは何か
• 昨日の話した問題や課題がどうなっているか（現在の状況を同期）
• お互いのチームでホットな話題についての情報交換
• 一緒にやってほしい、教えてほしい、助けてほしいことの軽い予約
• いまはどこの何にどれくらいの割合で注力すべきか（複数バージョンを並行開発してるため日々の調整を大事にしている。スケジュールや各プロジェクトの状況や問題の種類や大きさやそれに対するインパクトは常に変わっていくので。）

10分しかないのでお互いのチームが関係しそうでより重要と思うことから話します。自ずとみんながそうなります。いつもだいたい時間切れで終わるのですが、たった10分でも得られる情報は多いです。多いというより中身が凝縮されている感じ。自分のチームしか見ていないと外側の小さな変化（のちに自分のチームやシステム全体に影響を及ぼす何か）に気づくのが遅れがちですが、そういうことにも気づきやすくなります。

ここで得たことを元に隣のチーム（システム、ソフトウェア）とのつなぎ目とその周辺に気を配りながら、同僚のテスターとその日のテストを柔軟に変えていきます。

隣のチームのチケットを覗く

お互いのチケットは別管理ですが誰でも自由に見ることや書くことができます。チケットはわたし（テスター）にとってはお宝みたいなもので、毎日読むのが日課になっています。

• 毎朝10分の会話のあと、話題になったアイテムを索引にしてチケットを覗きにいきます。そこにはもうすこし詳しい内容（開発日記）が書かれています。読んで理解を深めたり、分からないことがあれば隣のチームの誰かに聞きに行きます。
• 午前中のうちに現在のイテレーションのチケットを一通り目を通します。特に自分で見つけたバグについては注意深く読みます。バグの原因はなんだったのか、どのように直そうとしているのか、プログラマーはどのようなテストをするつもりなのか、スムーズに修正作業が進んでいるのかに興味があります。これらは修正後の確認で何を試したらよいかを考えたり、プログラマーに質問、相談するための材料になります。

チームの外側も気にしてテストする

自分のチームがいくらうまくできても製品としてダメなら全然ダメという意識が多分ものすごく強いです。境界値にバグが存在するのと同じようにチームとチームの境界にも問題が潜みがちで、より気づきにくい特徴があるように思います。そのことは経験的にわかっているので要件定義の段階からプロダクト全体として何がどう変わるのか、変わったら何が嬉しいのかをみんなが気にしていて、たびたび話題にもなります。

同様にテストも薄くなりがちなので自分のチームを超え隣のチームの範疇にガツガツ入りこんで積極的に触っています。このときに『毎朝10分、隣のチームと会話する』や『隣のチームのチケットを覗く』で得た知識やノウハウや人脈を使います。あまり変なふうに触らないで…と思っているプログラマーもいるようですが（実際にそう言われたことがあります）お客さまが変なふうに触るかもしれないので、気にしないようにしています。なお、チームの外側をテストするのはテスターだけではありません。プログラマーもテストしています。

問題を見つけたら隣のチームへ話しに行く

この見出しだけ読むとはじめに引用した部分「他のチームと話すことを忘れている」に対する仕掛けがこれか、、、となるのですが、何がなんでも伝えたい！と思うことがないから話すことを忘れてしまうのではないか（仮説）を提起しておきます。問題を見つけたらと書きましたが『チームの外側も気にしてテストする』ので問題が見つかるとも言えますね。結局のところすべての行動やふるまいは全部どこかでつながっていて、これらの仕掛けの何もかもが単に「サイロ化」を防ぐためだけでなく、製品開発におけるさまざまな課題や問題に対してじわじわと効いてくるのだと実感しています。

おまけ

わたしたちのチームのNGワードに「合意する」「共有する」があります。あとメールを出しておしまい（あとはずっと返事待ち）は喜ばれないふるまいです。*4

おわりに

チームが「サイロ化」する問題について、隣のチームとの具体的な仕掛けや行動やふるまいをわたしの目線で紹介しました。途中で、隣のチームのことを書いているのか、自分のチームのことを書いているのか分からなくなるときがあったので、混乱された方がいたかもしれません。それくらいチームとチームの境界が曖昧になっているのですが、今から5年前のことを思い起こすとチーム間の結びつきはずっと薄かったように思います。

書きそびれましたが『隣のチームとの夕会』もあります（週4回、30分/回）。とりあえずやればうまくいくというものでもないので、何か秘密があるのだろうなあ。同じチームの @m_seki や @vestige_ に聞いたらまた違った視点での仕掛けが出てきそうです。もしかしたら『Agile Testing』や『More Agile Testing』にもサイロ化しないためのヒントやプラクティスが書いてあるのかもしれませんね。

Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley Signature Series (Cohn)) (English Edition)

More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley Signature Series (Cohn)) (English Edition)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

nihonbuson.hatenadiary.jp

kawaguti.hateblo.jp

追記：チームとは何か

むしろ一人で1チームと思っていい。隙間は全員の間にあるので。

— seki at druby.org (@m_seki) 2020年5月27日

チームがーっていうと人ごとになる。どちらかというとあのチームのAさんBさんとこのテーマを解かなくちゃ、みたいな状況なので、番地としてのチーム名だったりする。と思う。

— seki at druby.org (@m_seki) 2020年5月27日

*1:そういう風に動くように仕掛けられていたのかもしれないとは思う。

*2:4、5人ではないし、2、300人でもない。

*3:個人名を書くわけにもいかないのでチームリーダーと書いておきますが、明示的なリーダーは多分いません。みんながそれぞれリーダー。テスターもリーダーだよ。

*4:@m_seki は一時期メールボックスを満杯にしてメールを受信できないようにしていた。

「よし！」と思ったあとのもうひと手間（テスト）が大事

今朝、Amazonのほしい物リストに愛用している替え芯を追加しました。商品名のほかにも必要な個数や持っている個数などを入力することができます。

最大何個まで指定できるんだろう？とソフトウェア開発者（特にテスター）ならあるあるな思考で大きな数字を入れてみました。どうやら最大値は 99999 のようです。（そういう風に動いているだけで、欲しかったものがそうだったのかはわかりません）

100000 を入力した時の ! 正しい数字を入力してください はすこし不親切だなと思いました。

「最大値のチェック」を確認したあと「最大値が保存できる」ことを試しました。保存先の入れ物のサイズが小さいと保存に失敗することがあります。保存後、ほしい物リストに戻り 99999 が表示されることを確認しました。念のためAmazonアプリを再起動し、ほしい物リストを開き 99999 が表示されることを確認しました。

「必要」のとなりにある「持つ」は編集画面とあわせて「持っている」のほうがいいね。

次に気になるのは「持っている」の個数ですが、こちらも最大値は 99999 みたい。「必要」と「持っている」の両方に 99999 を設定して保存しました。このあとほしい物リストはどうなると思いますか？

ほしい物リストから「替え芯」が消えます。

必要な個数と持っている個数が同じになると、あなたの希望は叶えられた！となり自動的に消えるようです。なるほど。ただ、替え芯のような消耗品だと持っていても使えば減るので、このふるまいはちょっとどうなの？と気になりました。そして、自分がこのアプリの開発者なら「リストに登録された商品を削除する機会を増やしたい」と思うかもしれないな、とも。

一通り触って大丈夫かな（大丈夫かなって誰にも頼まれてないけど…）「よし！」

このあとわたしはもう一度、同じ替え芯をほしい物リストに追加します。ほしい物リストはどうなると思いますか？

最大値の 99999 を突破してしまいました。

普段の開発でも「よし！」*1と思ったあとのもうひと手間で、問題や課題が見つかることがあるのよねと思いながら、この記事を書きました。*2

そうそう「よし！」はテストするときだけでなくバグを見つけたあとにも応用できます。例えば、それほど大きな問題にはならなそうなバグ（A）だけど、それを踏んでしまうと、そのあとの操作でお客さまにインパクトのある問題（B）が発生しやすくなることがあります。こんなときうちのチームのベテランテスターはすかさず（B）まで報告してきます。きっと（A）を見つけた時点で「よし！」と安心せずに、もうひと手間かけてテストしてくるのだろうな。

「よし！」はテストに限ったことではありません。わたしがテスターなのでどうしてもテスト寄りの話になってしまいますけど。

*1:最近は「よし！」と思うとき、黄色いヘルメットをかぶった『現場猫』のイラストが浮かんでしまう病気にかかっていて、その度に「ヨシ！」じゃないほうの「よし！」と脳内でいちいち訂正してる。それはそれとして、わたしは工場勤務なので『現場猫』のネタがすごくわかるときがあって「くくく」と笑っています。この記事のアイキャッチ画像も『現場猫』にしたかったのですが、著作権がよくわからなくて断念しました。

*2:明日もう一度触ってみようと思うこともあるし、もうひと手間かけられるくらいのちょっとした余裕がないとむずかしいのかもしれない。そのちょっとした余裕は（時間というよりは）自分が支配してそう。

デブサミに行ってきた（２）

目黒の雅叙園で開催されたDevelopers Summit 2020（デブサミ）に行ってきた。今回も大盛況で満員のセッションが多く、人気のセッションでは壁沿いに立ち見も出ていた。どの会場も入場待ちの長い列ができていて大変そうだったが、わたしはお金の力（個人スポンサー）で解決したので快適だった。二日間でいくつかのセッションを聴講した。特に良かったものを数回にわけて書き記しておく。前回の記事はこちら。

『質とスピード』和田 卓人さん（タワーズ・クエスト株式会社）

今回のデブサミで楽しみにしていたセッションの一つだ。昨年の『技術選定の審美眼』もよかったなぁ。久しぶりにスライドを見てみようと調べたら一昨年のデブサミだった。いろいろ思い出したぞ。講演後 Ask the Speaker で「審美眼の美はどこにあったのか？」としょうもないことを聞いたらギクリとしていた。数時間後に別の講演会場で会ったとき「あのあとすぐにスライドを見直したら何ページのどこそこのXXXXXというフレーズにかろうじて美が入ってました。よかった…」と教えてくれた。つられて「よかったねぇ」と言ってしまったが、そうじゃないだろう。和田さん（以降 @t_wada）だってはじめから知っていたはずだよ？

本当にいつもすみません。

@t_wada の講演はいつでもどこでも大人気なので個人スポンサーでものんびりしてられない。ランチセッション聴講後、急ぎ足で会場に向かう。入り口でネームパス（バーコード）をピッとしてもらい前のほうへ歩いていく。壇上の横のすこし暗いスペースにおそらく緊張して吐きそうになっている @t_wada の姿が見えた。

speakerdeck.com

@t_wada の話は「今回も良かったね」だけでは終わらないところが良いところだと同行者の @m_seki と本人がいないところで褒め合う。聴講後はこんなことを考えていた。

テストしていて急かされたことがほとんどない

テスターのわたしがそう感じるということは、うちのチームのプログラマーもあらかたそうなのではないかと予想する。だってわたしがテストする時点でテストに耐えられるレベルのモノができている、ということだからね。急いで何かをしなきゃならない状態にならないようにする力学が働いているように思う。まあ、たまにそうならないときもあって、そんなときは誰かが暴れる。

おそらくこれと関連してチームでいつも意識してるのは「がんばらない」ことだ。自分たちの穏やかな"いつもの時間"を守るために日々「がんばらない」をがんばっている。何を言っているのかわからないかもしれないが「がんばればできそう」「もうすこしやれそう」「むしろやりたい！」ときも時間がきたら我慢して帰る。定時すぎにモニターを覗き込んでいると「もう17時過ぎましたよ、帰らないんですか？（帰ってくださいの意）」と声をかけられる。わたしは（テストに関しては）時間を忘れて熱中しがちなので目をつけられているのだ。

若者が朝会でうっかり「がんばります！」などと言うと「がんばらなくていいから普通にやって」と言われる。がんばらないとできないものは何かが間違っているとのこと。@m_seki が言ってた。

ベテランだって急かしちゃダメだ

講演の中で「うまい人はうまいしヘタな人はヘタ」のようなスライドがあった。

技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。

逆に、技術力が高くない人が時間をかけて作ったとしてもその人の技術力以上の品質のコードは書けない。

これはTesting*1にも当てはまると思う。ベテランが10分もさわれば見つけられるバグを初心者が3日かけても見つけることはできないのと同じだ。その人の技術力以上のTestingはできない。これは良い悪いの話ではなくそういうものだという話。

ただ、ベテランでも急かしちゃダメだと思う。さっき"ベテランが10分もさわれば見つけられる"と書いたが、テストするのに10分間しか与えなかったらそのバグは見つけられない可能性が高くなる。でも1時間与えたらはじめの10分で見つけられるような気がする。これは「ヤーキーズ・ドットソンの法則」（多少のストレスがあると注意力が高まるためパフォーマンスも高まるが、ストレスが強すぎると低下してしまう）に当てはまる事例だと思っている。試したことはないんだけど。*2

うちのチームでスピードを求められるとき

普段、急かされることはないがスピードを強く求められるときがある。それは何かおかしな挙動（期待との差）を見つけたときだ。テスターならスクリーンショットやログをとったあとにこんなことがしたくなるのではないかな。少なくともわたしはそうだ。

• いまやったことをもう一度やってみて、再現手順を確かなものにする
• おかしくなるときとおかしくならないときの手順や条件の違いを見つける
• 一番シンプルな再現手順を見つける
• 類似する不具合を見つけにいこうとする
• 不具合かどうかわからないときはそれが仕様（期待しているふるまい）かどうかを調べる

うちのチームではこれはやってはならない。なによりも先にプログラマーにいま何が起きたのかを話し、新鮮な状態を見せなければならない。見せたあとならやってもよいが

• これはコードを追って原因を見つけます（だから再現させなくていいよ）
• ここの条件はこのバグとは関係ないっすね、むしろこっちがあやしいな

と設計や実装のポンチ絵を描いてもらったり、再現手順を探るときのヒントを教えてもらうことがある。そのままプログラマーと一緒にテストして、ものすごい速さで再現手順にたどりつくのは何度も経験している。テスト環境が原因だったこともある。

プログラマーに新鮮な状態を見せるとその場ですぐに問題の原因が明らかになったり、問題の原因を特定するための最短方法がわかるのはメリットの一つだ。

「おかしさに気づいてからプログラマーに伝わるまでの時間」という品質指標があるのかないのかわからないけど、とにかくうちのチームではこのスピードが求められている。

あとは何かわからないことがあるときに「わからない」を表明するまでの時間かな。チームの誰かに聞けば大抵のことはわかるし、わからなくてもどうにかなる。だから悩んで時間を使ってしまうのは嫌がられる。時間は自分ひとりのものではなくチームの時間だ。聞けばわかるかどうかは聞いてみないとわからない。だから聞くしかないのだ。

これらは練習しないとできるようにならない。

こんなふうにに普段やっている"普通のこと"をあらためて認識できたのは @t_wada のおかげ。ありがとうございます。

これは聴講しながら書いた自分用のメモ（記念に貼っておく）

珈琲専門 猫廼舎

この日は夕食をすませたあと新宿区荒木町にある 珈琲専門 猫廼舎 に行く。ドアのガラス窓から見える店内はほぼほぼ満席で店に入るのを一瞬躊躇ってしまった。すごいな。

店主の荻野さん @ogijun に簡単な挨拶をしながらカウンター席に座る。夜にお邪魔するのは初めてなので大人になったような気分だがカウント的にはじゅうぶん大人だ。メニューを見せてもらう。バランスの取れたブレンド「イエネコ」にしよう。豆とお湯の量を5種類の中から選ぶシステムになっている。わたしは普通のコーヒーが好きなので3番の「はじめての方へのおすすめ」にした。

それからしばらくネルドリップの一瞬一瞬をとらえるような繊細な所作を眺めていた。贅沢な時間だ。

コーヒーカップはすべて有田焼。数十種類の中から荻野さんが選んでくれる。

猫廼舎には通販部がある。わたしはおまかせコーヒー豆の定期便を購入して職場で飲んでいる。淹れ方もだんだん上手くなって「今日のは最高にうまくはいったな」とか思っていたんだけど、あれはすべて勘違いだった。プロが丁寧に淹れたコーヒーは素晴らしく美味しかった。ごちそうさまでした。

『とちぎRuby会議 09』の開催日（9月12日）を伝え、店をでる。

*1:Testing：未知の問題を見つけるテスト

*2:参考書籍 インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針 「089 ストレスを感じているときには間違いを犯しやすい」

デブサミに行ってきた（１）

目黒の雅叙園で開催されたDevelopers Summit 2020（デブサミ）に行ってきた。今回も大盛況で満員のセッションが多く、人気のセッションでは壁沿いに立ち見も出ていた。どの会場も入場待ちの長い列ができていて大変そうだったが、わたしはお金の力（個人スポンサー）で解決したので快適だった。二日間でいくつかのセッションを聴講した。特に良かったものを数回にわけて書き記しておく。

『起業家的？！エンジニアのススメ』玉川 憲さん（株式会社ソラコム）

玉川さんの講演を聴くのは二回目で、調べたら前回は2016年のデブサミ（SORACOM立ち上げ格闘記）だった。あれから4年たつのか。プロダクトが素晴らしいのは言うまでもないが、多岐の分野において実にさまざまなユースケースが生まれ、モノと繋がり新しいIoTシステムとして人々の役に立っているのが本当に素晴らしい。昨年11月に福岡空港の『ふくや』でご家庭の明太子が無くなる前に自動的にお届けする『ふくやIoT』の動画広告をみて「福岡すごいなwww」と思っていたのだが、これもSORACOMの仕業だったのを知る。

わたしたちが開発してる製品もかなりとても素晴らしいのだが、そういえばSORACOMに感じる「壮大なロマン」のような感情をもってないことに気づく。少なくともいまのわたしの中には無い。いいなあ、羨ましいなと思う。今回の講演のキーワードのひとつは『パッション』だった。玉川さんのそれは「テクノロジーの民主化」とのこと。わたしはなんだろうな。開発しているモノ（医療機器）を通して「ひとりでも多くの人たちが健やかで幸せな人生を送れるよう手助けすること」だろうか。普段の開発では具体的な問題を解いていることが多く「世界中の人々の健康と幸せのためにテストしてバグを見つけるのだ！」と燃えあがるような感じでもないんだけど、根底にあるのはそれだと思った。

スピーカーラウンジ（控室）にて

最初の講演からとても良くて頭が疲れてしまったので休むことにした。個人スポンサーはスピーカーラウンジ（控室）が利用できるのだ。美味しいコーヒーとお菓子と電源とWiFiが付いてる。最高である。ジャガード織りのカバーのついた椅子に腰かけてぼーっとしていたら、斜め前のほうに玉川さんが座っているのを見つける。同行者の @m_seki に小声で「玉川さんがいるよ」と伝え、二人で話しに行く。聴講しながらiPadでメモしたものを見せたら喜んでくれた。「どこかに公開するんですか？もし公開したら教えてください。きれいに書いてあるから見たい！」と名刺を差し出す玉川さん。とても嬉しかったのに、自分の描いた絵を見せびらかしている子供のようだ（しかも初対面の人に）と思ったら急に恥ずかしくなった。「たいしたこと書いてないので…」ともじもじしてしまったが、そこに書いてあるのは玉川さんがさっき話した内容である。そういう意味ではないのだが、たいへん誤解をまねく表現だ。これからは気をつけよう。

玉川さんにはこんなことを聞いてみた。「普段仕事しているといろんなことがあって、例えば、嫌なことがあったときはどんな風に気持ちを切り替えるんですか？」

パッションだけでは乗り越えられないときってないのだろうか（きっとあるに違いない）と思ったのだが「ない」みたいだった。もうね、なんて言うかパッションがすごいのだよ、パッションが。それくらいでないと世界を変えることなんてできないのだと納得した。そしてちゃんとわたしのレベルに合わせて「睡眠の時間を十分にとったり、食事もちゃんとして、ストレスを受けにくいようにはしてますよ」とも話してくれた。なんて良い人なんだ…と感激した。

そしてこれが「たいしたこと書いてないので…」のやつである。

デブサミ「起業家的?!エンジニアのススメ」の講演資料です！
パッションをもち、自ら人生を切り開いていくような起業家精神を纏ったエンジニアが、日本で一人でも増えますように！協力いただいたソラコムのエンジニアの皆さん、多謝！！#devsumi #soracom https://t.co/5W615fdiHw

— Ken Tamagawa 玉川憲 (@KenTamagawa) 2020年2月13日

ソフトウェア技術者のためのバグ検出ドリル（問題6：ミケランジェロの呪いー入退室セキュリティ・システムの不可解なバグ）

この記事は『ソフトウェア技術者のためのバグ検出ドリル』についての思考メモです。本書で問題を解いたことのある人、これから解いてみようかなと思っている人向けです。当然ドリルの問題は載せられないので消化不良を誘発する内容になっています。*1

ソフトウェア技術者のためのバグ検出ドリル

要求仕様フェーズの問題が解きおわり今日から設計フェーズです。問題6の制限時間はなんと4時間。手強い問題なのかな？とやる気満々で問題文を読みはじめたのですが、、、

そのものずばりの解答が１行目に書いてあって、うっかり視界に入ってしまった…。ううう。これから解く人は注意してくださいね。わたしは再発を防ぐために解答を隠す用の便箋を挟みました。*2

答えは分かってしまったのですが、このバグから普段の開発でどのようなことに注意すると良さそうかを考えたいと思います。気が向いたら追記しますが、まずは注意喚起でした。

*1:勘の鋭いエンジニアなら問題を逆引きできそう

*2:電子書籍リーダーで見たくない部分をさっと隠す機能ってあるのかな。幸い？本ドリルの電子書籍版は今のところないようです。