上流工程から“俯瞰して考える”ことを意識する LINEのプロダクトを支えるQAエンジニアのかたち
コメント
注目のコメント
イスラエル人に質問をすると質問で返ってくることは日常茶飯事だ。
「こちらの質問が曖昧な場合」「こちらが得たい答えが曖昧な場合」など様々であるが、こちらの必要とする回答に最適な回答をしてくれようしているのである。
記事中の上流工程の話も同じで、
「問題の本質は何か」
「問題の真因は何か」
を考えないと、その質問が（彼らにとって）適切でないので、質問で返ってくるのである。彼らとしては、曖昧な回答はしたくない国民性。
訓練でできるようになると思うが、最初は大変である。第一にチームで認識を合わせることに触れていることは、その通り、チームで認識（言葉の定義など、多くのもの）が合わないと、すべてズレてしまう。上流工程への課題がチームの課題と知り、その改善がチームの改善になる。
抽象と具体。
私たちのチームにはチャレンジングなマインドをもったメンバーが多くいます。そこに影響を受けたことと、LINE STYLEと呼ばれるLINEらしいやり方や考え方が記された行動規範のようなものの後押しもありましたが、私自身が未経験で入社したことも相まって、「QAはこうあるべきだ」というイメージを自分自身がもっていなかったことで、最初の一歩を踏み出しやすくここまで活動できたのではないかと感じています。
（記事内容引用）
上記については、現職で中途である私にも通づる部分であると思うので、良い意味での”素人感”を大切にフレッシュな目で市場へのアプローチができればと思います。あまり特別な事をしている感じは無かったのですが、どの部署にどの役割を持たせるかはある程度企業色があるなと思いました。私がプロマネという役割でやってた事の一部をLINEではQAがやってるんだなとか。
QAを入れて1チームにする事は良い事だと思います。私もゲーム開発・運用していてそういう結論に至りました。主に時間と内容の精度的な理由でどうしても企画チームで回せない事やシューティングできない物をQAに持って行ってお願いしたりしてました。最たる例が仕様書のレビューとか。
これはテスト項目は仕様に対して決まるという事とも合ってるのでお互いに都合が良いです。
UXデザインに関しては会社によってはカスタマーサポートの意見を聞く事もあるかなぁと。私が一人でゲームの開発・運用していたタイトルがあって、それはCSに相談してました。彼らはさすがたくさんの問い合わせを捌いているだけあって、ユーザから出そうな反応を的確に指摘してくれました。
QAと企画開発は本当に二人三脚でした。企画でチェックしきれない所を剥がしてQAにお願いしたり、数百回試行した結果の確率計算チェックや期待値チェックとかQAでやってられないのでそこは開発で自動テスト書いてQA向けにはJenkins経由でポチれるようにしたりとか、緊急で検証をねじ込んで貰ったりとか。もちろん打ち上げや定期飲みとかも一緒に。
ただちょっと、記事にある軽微な改修などで後回しになったり止まったりしている改修をフォローするというのはやらない方が良いんじゃないかなぁと。
というのが、そういった備忘録やbacklogに入ってるような物ってちょこちょこ気になって大量に出るのですが経験値的にその殆どが対処されないままずーっと放置されます。
それってやった方が良いのかもだけど、実は本質的にやらなくてもよい事だから放置されてると考えた方が良いんじゃないかなと。
ユーザの分析結果から解りやすく要らない物とかもあって、やる前提で動くのではなくて、やらなくて良い事を捨てていく方が重要なんじゃないかなぁと思います。
