こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。(若干遅れての参加だったので冒頭にあった話は聞き取ることができていません)
苦情
P33で苦情が来たのはP33でリリースした機能のせいだと思いこんでいるという前提はまずありそうだよね、という話がありました。
また、苦情の内容としても映像品質がよくないことに関する苦情だったんだろうけれど、これって映像品質をよくすることが解決策になったんだろうか？という話も出ていました。
yoshitakeさんやmiwaさん的には、映像品質が甘かったこととユーザーストーリーが完了したかどうかの基準が「ライブラリがアップデートされたかどうか？」だったのもあまりよくなかったのかもしれないということです。
テストをするときにはメリットよりもなんで役に立つか？を考える
はじめは、「なんのメリットがあるんだっけ？なんの役に立つんだっけ？」ではなく「なんでこれがいるんだっけ？」と考えたくなるという話がありました。
sekiさんからも、最初はユニットテストではなくて本当にこの機能いるの？から始まることが多いということです。
「なんでこれがいるんだっけ？」とかは自動テストがしにくいので、プログラマー視点だと作る部分にフォーカスするので、なかなかフォーカスが効かないとかはあるかもしれないという話も出ていました。
また、miwaさんから、現場であまり話題にならないときは、わざとらしく話題にするところからはじめるのがいいのかな、というコメントも出ていました。
自分の言葉で説明してくれるエンジニア
エンジニアの中でテストが上手い/下手の軸とは別に、自分自身が選んだ解決策に対して自分の言葉でしっかりと説明できるかどうかという軸はあって、自分自身が選んだ解決策を説明してくれる人はいいよね、という話がありました。
また、miwaとsekiさんのチームだと、そういった人がもし解決策を間違っている場合は、どういう部分がおかしいかという話を徹底的に容赦なく言う*1ということです。
ただ、これは指摘をされたときに盲信されない前提があるからというのはあるよね、というお話がyoshitakeさんからあり、例えば指摘されたらそれに対応されてしまうのが絶対だと感じてしまうような新人に関しては、意図的に指摘を複数書いたりこの指摘があっているとは限らない旨を細かく補足したりといった工夫をするということでした。*2
全体を通した感想
今回は共感できる会話が非常に多く、「そうだよねー」と思いながら終始会話を聞いていました。
また、今回の内容に関しては、miwaさんたちは反対のことをやってそれを論文にしようという取り組みもしているというコメントもあり、論文がAcceptされて発表されるのが非常に楽しみです。
