QAもちゃんと技術力を付ける必要がある
てらら氏（以下、てらら）：次が、「QAエンジニアの技術力をどのように開発チームに融合していくか」という、なんかすごそうな話です。こちらもいったんゆもつよさんで大丈夫ですか？
湯本剛氏（以下、湯本）：では、最初は私で。先ほど言ったように、「こっちはQA、こっちはエンジニア」みたいな感じなのを、どうやって一緒にしていくか、融合していくかという話なんですよね。
1つのチームとして働いていくためには、技術力が違うとちょっと話にならないというか。ある程度は会話できるレベルが必要だし、得意不得意はあるんだけど合わせていくみたいな。要は「QAの人もちゃんと技術力を付けなさい」みたいなことを言いたいです。
中村洋氏（以下、中村）：その話でいうと、アジャイルのトレーニングとか、アジャイルの説明をした時に「アジャイルって難しいですよね？」ってたまに返ってくるんですが、「いや、ちゃうねん」「ソフトウェア開発が難しいねん」みたいな話で。プロダクト作りが難しいという話なんですよね。
何の話がいいかな。野球とかスポーツをやるにしても、スポーツにはルールがあります。野球のルールがあります。ルールを知らなかったらそもそも話にならんのは当たり前です。
けれども、ルールを知ったからって野球ができるのかといったら、やはりできないわけですよね。バッティングセンターに行って、どれだけバットに当てるかとか、ノックを受けてから初めてグラウンドに立てるかみたいな。グラウンドに立ったら立ったで、また当然失敗したりしてうまくなっていくという、このプロセスが必要で、最低ラインに達してへんのにグラウンドに立つと、たぶんそれはうまくいかんやろと思います。
湯本：そうそう。
中村：わりと厳しめな話はよくしますね。
「マニュアルがあれば誰でも同じことができる」わけではない
湯本：マニュアルがあると誰を連れてきてもできるみたいな、ちょっと昔の考え方があって。「マニュアルを整備して連れてくれば誰でもできる」と言う、すごい、偉いおじさんがいます。
「けど、それはできませんよね」と。「練習をしたことがない人は取れませんよ。『フライを取る』とマニュアルに書いてあってもできないですよ」と言ったことがあります。
中村：おぉー。いいですね。自分たちがやったことによって何か起きて、ここからどう解釈をして、それで何を学ぶかという話です。
先ほど「QAと一緒にやったほうがいいよ」と言ったのは、エンジニアの人はやはりエンジニアの関心事だったり、よく気がつくポイントがあったりするわけですよね。「こういうことに気が向きやすい」とか、もちろん個人によって違うんですが、わりとエンジニアリングが得意な人と、コードを書くのが得意な人と、品質を設計したり担保することが得意な人とでは、やはり見える場所がけっこう違っていたりするわけですよね。
そういったことはめちゃくちゃ大事で。「この方面から見たらこの角度しか見えないけど、反対側から見ると違う情報が見える」ということはいくらでもあることです。
そういうのもちゃんと言わないといけないこともあります。ただ、言うためにはお互いが「お前わかっているよね」というように、ある程度専門性をちゃんと尊敬し合った状態じゃないと、やはりできません。
グラウンドに立ったことがない人が「野球ってこうやるべきでしょ」と言っても、立っている人からすると「グラウンドに立ってから言えや」となるので、そのあたりの最低限の話ができる状態はやはりいるんとちゃうかなとよく言っています。
ペアプロやモブプロはどんどんやっていけばいい
湯本：まぁ、そんな中でも「じゃあ自分はあれなんじゃないか」みたいに引っ込み思案にならなくても良くて。
中村：そうですね。
湯本：ちょっと出っ張っているぐらいがちょうど良くて。出っ張っていても「ちょっと出っ張っているよ」と言ってもらえるぐらいな雰囲気というか場作りが必要で。あとは何ていうの？ 心理的安全性というんですか？
中村：そうですね。対人リスクを恐れないで言えるとかもあるし、先ほどエピソードを出しましたが、うまくいっているところは、やはりお互いのやっていることを知っているというのがけっこうあるんですね。
ふりかえりとかでよく出てくる言葉で、「QAの人が忙しそうやった」みたいなことが出てくるんですけど、「じゃあそのQAの人が何をやっているか知っている？」と聞いたら「それはわからん」となるわけです。「ただ単にチケットが終わっていくのを見てた」と普通に言っていて。
それだったら、QAの人がどんなふうにデプロイしたのか、どんなふうにテストをしているのかとか、どんなふうにドキュメントを書いているのかとかを見てみたらええやんと。
逆もそうなんですよね。QAの人が「エンジニアからなかなかテスト来えへん」と言っているけれど、「エンジニアの人が何しているかを知っているか」と言うと、やはり知らへんわけですよ。
それなら、隣の席に寄って、一緒に「どうやってるの？」って見て、「これはなんでやっているの？」とか「それはこうしたほうが速くなるよね」という話をどんどんしていったらええのになとはすごく思います。
だからペアプロとかモブプロとか、そういうのはどんどんやっていけばいいと思うし、ほとんどの現場で、自分のやっていることに関心を持たれるのは基本的にうれしいことだと思うんですよね。
「あぁ！ そうやっているんですね！ 知らんかったわ」と言われた時に、だいたいの人は「じゃあ、なんかもっと早く伝えたら良かった」と言うので、そういうのはどんどんやったらいいのになとは思ったりしますね。
役割に限らず必要なことは何でもしたらいい
中村：あと1個だけ言うとしたら、「フロントエンドエンジニアです」「QAです」とか言われると、「それはわかるんやけど、要はプロダクトを速く届けて良い物を作りたい人たちなんだから、必要なことは何でもしたらええやん」と。
「専門性としてはQAなのは理解するけれども、デプロイが止まってんねんやったら『自分のできることはなんかない？』と言いにいったらいいのにな」という話はよくしています。
湯本：そうそう。「デプロイされないから今は待っています」みたいなのはダメで。「デプロイすればいいだけだったらすればいいじゃん。『QAエンジニアだからやらない』じゃなくて」というだけの話ですよ。「データがないから今はできません」じゃなくて、「じゃあデータを入れればいいじゃん」みたいな。
中村：そうそう。できることで必ず1個あるのは、声を出すことなんですよね。「今デプロイで止まっていますよね？」となった時に、「自分はこれまでこのチームで仕事をしていて、デプロイコマンドはこれだとわかっているので、自分がやりますね」と言えばいいと思っています。
湯本：勝手にやっちゃいけないからね。一応一言を言うのは大事ですよね。
中村：そうですね。「やりますね」と言ってやって、それでうまくいけばいいし、うまくいかなかったら「みんな助けて」と言えばいいだけの話なので。声を出すことは誰でもできると思っているので、それはやればいいと思いますね。
てらら：いいですね。
ラベル付けをすることで関心事を狭めている
てらら：先ほどの野球の話に戻っちゃうんですが、「QAのエンジニアは野球で試合に入るために素振りをしろ」と言っていましたが、素振りは何をすればいいですか？
中村：本当はコードがどうできているかが大事なんですが、でももっとシンプルに、関心を持てばいいと思っています。そのためには先ほど言ったような「どういうふうに開発をしているの？」とか、あとはプロセスであれば「どうやったらテスト可能になるの？」みたいな話を、関心を持って質問していけばいいと思っていて、たぶんそこでわからん言葉とか、わからん概念が出てくると思うんですよね。
「実際にそれはどうやっているかわからん」というのもあると思っていて、そしたらその概念を調べるために本を読むとか、コードが書かれているものは自分でも作ってみるとかしたらいいと思います。
たぶんそれで「あぁ、そういうことか。だからこういうふうなのが嫌がられるのか」とか「苦い顔をされるんや」ということがわかれば、だいぶ変わってくるかなと思っています。
先ほども言ったように、歩み寄る人を拒否する人は、あまりいないと思っているんですよね。
湯本：ベースはエンジニアという話なんですよね。QAエンジニアとか、フロントエンドエンジニア、バックエンドエンジニア、〇〇エンジニアとかでいろいろなエンジニアがいると思うけれど、エンジニアなんですよね。
中村：エンジニアであってほしいなと思いますね。人間の特性として自分にラベル付けをする、例えば「QAエンジニア」と自分でラベル付けした瞬間に、自分のラベルとそれが一致するから、関心事がQAの世界にしかなくなります。
例えば、先ほどのデプロイの話で、（デプロイが）こけていても「自分はQAエンジニアやから」という、無意識なラベルで見なくなるとか、それはけっこうあるなと思っています。なので私たちがよく言っている「越境」というか、「必要だったらやればいいじゃん」ということは言ったりしますよね。
湯本：そういうことも自分で考えればいいんですよね。「ここでこうやったほうが絶対にいいはずだ」と思えばやったほうが良い。そういう気持ちで仕事ができると本当にいいよなと思います。
中村：たぶんそのほうがシンプルで、おもしろいと思いますよね。待っているよりも自分が良いと思うことを「やるで」と言って手を挙げていったほうが、たぶんおもしろいんちゃうかなと思います。
てらら：なるほど。
「テストでがんばればいいや」で声を上げないのはもったいない
てらら：ちなみにQAエンジニアの技術力が今のトークテーマになっていたんですが、先ほどの話を聞いていたり、freeeのQAエンジニアの様子を見ていると、QAエンジニアはけっこう工程を俯瞰して見れるようなスキルを持った方が多いんじゃないかなと思っています。
そういったかたちで、洋さんやゆもつよさん（がお話しされていた）みたいに越境していく。チームに声を上げたり、「リリースされていませんよ」みたいな話をしたり、そういったことが（できる人が）QAエンジニアに向いていたりするんですかね？
中村：そういう人もいると思います。そのQAの人も個性があるので、エッジケースを見つけることがめちゃくちゃ得意な人、経験や勘で見つけるのが得意な人もいるし、先ほど言っていたような、俯瞰して見て「あ、この要件ってなんかこのへんがやばそう」とか、みんなが自分の職務というかプロセスに集中した結果、「なんか全体を忘れているで」みたいなことに気づく人はわりと多い気がしますね。
それでもったいないのが、手を挙げられへんことはわりとあるなと思っていて。「最終的にテストでがんばればいいや」みたいになって、声を上げないことはすごくもったいないなと感じます。
てらら：なるほど。
湯本：最初の話に戻るかもしれないけど、「そういうテストケースを何件やるのが自分の仕事です」とか、そういうことじゃなくて、今できているものがお客さんに出していいものなのかと。変な話、例えばハッピーがあと20件残っているとして、でもそれを直す必要がないんじゃないかと思ったら、「今これを直す必要がないんじゃないか」と、QAが自ら言えばいいんですよね。
中村：そうそう。件数をゼロにすることが目的じゃなくて、アウトカム、ユーザーにとってちゃんと使えるものか、価値のあるものかに観点を置いてやれるといいですよね。
てらら：なるほど。ありがとうございます。ハッピーとは（freeeの社内用語で）バグのことで良かったですか？
湯本：ハッピーはバグです（笑）。
てらら：ありがとうございます。
てらら：私が割り込んでしまい申し訳ありませんが、「QAエンジニアの技術力をどう（開発チームに）融合していくか」というテーマはいったんここで終わりにして、次のテーマにいきたいなと思います。
（次回に続く）
