DeNA QA Night #3（チュートリアル）参加レポート(その2)
■はじめに
2019年9月4日(水)に行われた「DeNA QA Night #3 （チュートリアル）」の参加レポートです。今回はメインイベント第2部の「パネルディスカッション」について記載します。
前回に引き続き記録・記憶違いにより内容に誤りがあるかもしれませんが、ご容赦ください。
■パネルディスカッション
テーマ：「QAエキスパートが喋り倒す夜」
【概要】
本セッションでは、会場からの質問をベースに、パネリスト２名のキャリアの変遷や境遇に照らし合わせながら、ディスカッションを進めていきます。
開始後簡単なイントロダクションはありますが、それ以降の時間は会場からの質問に対して議論を展開してきます。
(https://dena-qa-night.connpass.com/event/131229/ より引用)
チュートリアル終了後、メイン会場に合流となったのですが前回以上の人多さと熱気に驚きました。さすがDeNA QA Night !
良い感じであたたまった会場の中、河野さんの司会進行のもとにパネルディスカッションが開始されました。(パネリスト、司会者は以下のお三方)
【パネリスト】
湯本 剛さん （freee）
前川 健二さん（DeNA）
【司会】
河野 哲也さん（DeNA）
■自己紹介
モチベーションカーブ(人生曲線、モチベーショングラフ)を基に、経歴をご紹介いただきました
■Q&A
Sli.do に寄せられた質問、参加者の挙手による質問などに答える形で進行していきました。その一部を記載致します。
▼品質の定義とは？
・ムービングターゲットなので、うまく狙って打つものです。（湯本さん）
・品質はデライトです。安心・安全を保ってお客様に喜びを与えること（前川さん）
品質=デライト(喜び)。素晴らしいですね。
デライトと聞いたときに狩野モデルを思い出し、「当たり前品質」「一元的品質」「魅力品質」のどれにウエイトを置くのかが気になりました。
SIerだと私の経験上、「1.当たり前品質 2.一元的品質 あとは知らん」というプロジェクトが多い気がするのですが。
▼テストコンサルになるためにどのような勉強をしたか？(湯本さん回答)
ワインバーク、デマルコ。ヨードンなどの著書でソフトウェアエンジニアリングを勉強。
豆蔵でソフトウェアエンジニアリングの教育をした経験がとてもためになった。(良いコンサルにしごかれて成長した)
▼コンサルになったときにどのようにしていたか？(前川さん回答)
これまでの経験を活かしたコンサルをしていた。
品証の方法を知らない人たちに教える。立ち上げや炎上案件をよくやっていた。
コンサルは困っている人の手助けだから楽なものはない。
→コンサルは手を動かさないものと判っている客でないとキツイ。
コンサルの幸せはあなたはもう不要ですと言われること
自己研鑽をし、良き師匠に出会い、タフな現場や揉まれて経験を積んでいく。良き師匠との出会いって難しそう・・。
▼ヘボいプロジェクトの着地方法
・混乱してるので、やることをやる。（湯本さん）
* テスト計画がちゃんと立ってない。
* 基本的なセオリーに基づくアプローチ
* いろんな人が言ってくることに対してぶれない
* 原理原則を押さえておく
* 仲間を作る
* 「1」言ったら「10」分かってくれる人を増やす
・現場は無理がある。上を動かす（前川さん）
* 定量的に示す。
* コストがロスしてることを上に訴えることが大事
* PMと組む。
・いい品質かどうかはともかくこのレベルにはすると合意（湯本さん）
* できうる最善を尽くすために、できることをやる
・現場から変えようとする湯本さん
・上層から変えようとする前川さん
恐らく正解はなくて、プロジェクトの状況などを把握しながら其の場での最適解を導き出す。これがコンサルの難しさであり、楽しさなのかなと勝手に思いました。
▼業界のテストQAの水準に達しているかどうか不安
・テストの本とか読んでわかる。ならいいんじゃない（湯本さん）
* JSTQBのALとかわかるならいいんじゃない？
・人の書いたテストケースをレビューしてフィードバックできるといい（前川さん）
・こういうところに来てるから問題ない（河野さん）
* 懇親会にいけばOK
* WACATEにも行こう
* FLを置いて、シラバスのわからない章の実務を積めるように、上司を説得
* 全部わかったら、コンサル、アナリスト、マネージャなどに進む
要約すると・・・
JSTQBシラバスを感得して、テストケースをレビューできるようになる。
加えて、勉強会やWACATEに参加すれば問題なし！
▼旧態依然の開発体制から抜け出せない。新しい技法を浸透させたいが何かいい方法はないか
・現状の可視化。数値、定性（前川さん）
* 対策、成果をセットでぶつける
・できる範囲でやってみる。自分がかかわる範囲でテストしてみて、うまく言った経験を持つことが大事（湯本さん）
・振り返り（前川さん）
* 仲間を見つける。職場で
* 勉強会、輪読会。
▼日本では多くの場合（もちろん全てがそうではないが）開発者がQAを格下に見下す文化がある。それを覆す方法ないか？
・ジョブ定義が緩いからじゃない？（湯本さん）
・受け身になると軽んじられる。自分から攻めに行くのが大事（前川さん）
・海外だと納得いかない仕事だとすぐやめる
→だから自動化圧力が働いて正常化する
・人事制度まで見直すことになるので、転職しかない。
・若い会社はQAにぶち当たりがちなので活路あるかも
私はこのような文化があると思っています(QAというよりテストに関して)
所属企業、部署によってはQA/テストの技能が評価されないことがあるので、その場合は部署異動や転職を真剣に考えるべきなのかもしれませんね。
▼QA組織を作るために、最初にやることは
・標準化
・BTSの分析をして、今の現状を可視化する
・すげーと思わせるのが大事
・キーマンを見つけてぶん殴りに行く
・それぞれの人が腹落ちするポイントを殴る
・経営ならコスト、開発なら工学
・ベースがあるなら標準化、ないなら現状分析
■所感
個人の問題、組織の問題、様々な質問が飛び交っていたように思います。
私自身は組織の問題というより個人の問題を抱えていたので、今回のパネルディスカッションで個人にフォーカスを当てた議論がされたのは非常に有難かったです。自分の身の振り方も考える良い機会にもなりました。
参加させていただき、誠に有難うございました。