目黒の雅叙園で開催された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日）を伝え、店をでる。
