開催概要

• connpass
  • 並行してテスト設計の演習を行う チュートリアル も開催されていましたが、私はメインイベントの方に行きました。
• 近日一般公開予定のテスト観点リストの内容紹介と、QAエキスパートが来場者の質問に答えるパネルディスカッションという二部構成でした。

事前に読んだもの

これまで登壇者についてあまり事前に調べるということをやっていなかったのですが、
登壇される方がどのような取り組みをしてどのような思考で活動されているのかを把握しておくと、より当日の理解に繋がると思い今回はちょっと準備しました。

• DeNAの品質管理部がビジネスに踏み込める理由とは？ 振り返り資料に品質分析レポートなど方法を一部公開
  • 前川さん、柏倉さんの対談です。
  • 「品質管理部がビジネスに踏み込む」という点について具体的に紹介されています。
• DeNA品質管理部が語る、テストプロセスの標準化 - Part1
  • DeNA QA Night #1 のレポートです。
  • 標準化への熱い思いが感じられる内容で、今回のテスト観点リスト公開の話にも繋がっていきますね。
• パネルディスカッション「QAの過去から現在・現在から未来」（前編） #DeNA_QA_Night
  • 「口が悪い回だった(笑)」と当日会場で言われていた DeNA QA Night #2 のレポートです。
  • 会場の雰囲気が掴みやすく面白いまとめで、後編 含め何回も目を通しました。

テスト観点に関する取り組み事例

• 登壇者: 柏倉 直樹さん (DeNA)

• 資料: テスト観点に関する取り組み事例

• 要約

  • Webサービス、モバイルアプリを対象としたテスト観点リストを一般公開する予定
    • 社外Web識者からもフィードバックをいただいているところ
  • なぜテスト観点リストを作成・公開するか
    • テスト経験豊富なテストエンジニアをアサインしたい
      • キックオフ(開発からQAへ仕様展開する説明会)の内容をもとにテスト計画を立てている
      • テスト計画では観点をもれなく抽出することが重要
    • 経験者の確保という点で限界がきた
      • Webサービスやモバイルアプリは新しいドメインなので、そもそも経験者が少ない
      • 人材の流動性が高いので、経験者の中長期のアサインが難しい
    • 標準化の取り組みへ
      • 過去のテストをリバースモデリングし、標準となるテスト観点を組み立てた
        • 資料
          • リバースモデリングを用いたテスト観点標準化の取り組み
          • Webサービス・モバイルアプリケーション開発におけるテスト設計を支援するための標準テスト観点の整備
      • 業界貢献のため、オープン化を決めた

  • テスト観点リストの内容紹介

    • 対象
      • 利用する人物像
        • テスト設計は習熟しているけどドメイン知識が不十分な人
      • 対象ドメイン
        • Webサービス
        • モバイルアプリ
    • テスト設計の段階でドメインスキル・テスト設計スキルの両方が必要になる

    • リストは3つのビューと3階層の観点とで構成されている

      • ビュー

      	機能	部品	観点
      例	ログイン機能	メールアドレス入力	OS

      • ビューはどれかひとつとは限らない
        • 機能かつ部品、というテストもある
      • 観点の階層は今の所 Lv.3 までにしているが、公開後のフィードバック次第で増えるかもしれない

  • テスト観点リストは既にDeNA社内では一定の効果が出ている

    • 「作成時」は効果があった
    • レビュー時の利用についてはまだ実績がない(効果はあると考えられる)

パネルディスカッション

• テーマ：「QAエキスパートが喋り倒す夜」
• パネリスト
  • 湯本 剛さん (freee)
  • 前川 健二さん (DeNA)
• 司会
  • 河野 哲也さん (DeNA)
• 概要
  • 最初にパネリストのバックグラウンドの紹介も兼ねてモチベーションカーブの説明
  • その後 Sli.do に寄せられた質問に回答していく形式でした。
• Q & A (一部)
  • Q: 湯本さんがコンサルタントと開発現場を行き来しているのは意図的なものですか？
    • 今は意図的に行なっている。エンジニアができないとコンサルもできない。
  • Q: テストの何が面白いですか？
    • (湯本さん) テストの面白さは時期によって変わる
      • 最初: バグ見つける楽しさ、開発のダメなところを指摘する気持ちよさ
      • 現在: 良いものをリリースしたという達成感
    • (前川さん) テストはつまらない、QAは面白い
      • テスト: フィードバックして感謝されるという点に喜びを感じる
      • QA: 開発と一緒に良いものを作っていく喜び、いろんなサービスに携われる楽しみがある
  • Q: 2人にとって品質とは？
    • (湯本さん) ムービングターゲット
      • 動いているものをつかまえる力（状況、モノ）
    • (前川さん) 品質は delight
      • お客様が使って安心・安全を感じられるもの
  • Q: コンサルタントになった時どんな勉強をしましたか？
    • (湯本さん) ソフトウェアエンジニアリングの本
      • デマルコ、ワインバーグなど
      • エンジニアリング、コンサルタント、両方の学習が必要
      • 最初コンサルが何なのかわからなかった
        • 自分の中で納得感を得るまでに時間がかかった
      • (QAがコンサルになりたい時は独学かコンサルファームへの入社かという追加質問を受けて)
        • どちらでも。師匠を見つけてついていくのがベスト。
    • (前川さん) 経験を生かしたコンサルティングを。
      • 既に炎上していたり、品質保証を知らない現場に行くことが多かった
      • 学ぶというより経験をもとに動く
      • コンサルは「もういらない」と言われるまでがコンサル
  • Q. 中長期的なキャリアや今後の進みたい方向など
    • (湯本さん) エスカレーター式に管理職になるのが嫌だった
    • (前川さん) テストだけというところから抜け出したかった
    • (湯本さん) 繰り返し似たようなバグを出さない現場を作りたい
      • かっこいいバグを出したいよね！
    • (前川さん) 組織を作っていきたい
      • 組織としてQAが開発に携われるようにしたい。
      • QAの立ち位置を上げていきたい。
    • (湯本さん) イマドキのマイクロサービスで開発プロセスが変わってきた
      • 変化に対応できるQAへ
  • Q. ヘボいプロジェクトを着地させるようにできるようになった話をききたいです
    • (湯本さん) ヘボいプロジェクトは混乱している
      • 計画を立て直すところからやらせる
      • 周りが何か言っても強い心を持つ
      • 自分の考えを理解してくれる仲間も必要
    • (前川さん) ヘボいプロジェクトは現場だけでは解決しない。だから上に働きかける。
      • コストを定量化して提示する (数字を出す)
      • PMが計画通りに見られていないことが多いので、まずはここを改善する
    • (湯本さん) 着地させるというのは、お客様とどのポイントで合意するかということ。
  • Q: 自分の技量がテスト技術者として通用するか不安です
    • (湯本さん) テスト技法のテキストの内容がわかれば大丈夫じゃない？
      • JSTQBをただ暗記しました、ではなく。
    • (前川さん) 他の人のテストをレビューできるようになっていることが大事。
    • 井の中の蛙から抜け出すには交流！
      • この後の交流会に参加しよう(笑)
      • WACATE に行こう
    • JSTQBのシラバスでわかるところ、わからないところを切り分けよう
      • わからないところ = 経験してないところ
      • 経験してないところが経験できるよう相談してみよう
  • Q: 開発者が何をテストして、QAが何をテストするのかをどうやって決めていますか？
    • (前川さん) テスト計画の時点で決めている
      • どちらがどれを担当した方が早いかはプロダクトによる
      • 最初に分担するのがとにかく大事
    • (湯本さん) 分担もテスト計画のひとつ！
    • (そもそも大企業ってこういう議論しないよね？という話も。)
  • Q: 旧態依然の開発体制からなかなか抜け出せません。社内に新しいQA技法等を浸透させたいのですが、何か良いなどありますか？
    • 新しいQA技法ってそもそも何？
    • 浸透させたいと言ってるあなたは今どれくらいのレベルなのか
    • (前川さん) 現状の可視化を！
      • 定量的、定性的に分析。
      • 分析結果に加えて、これからどうしたいかをセットで提案しよう。
    • (湯本さん) 自分のチームだけで色々チャレンジして、仲間を増やしていこう
      • まずアウトプットが無いと自分の中でも腹落ちできないのでは？
    • (前川さん) 振り返りをしよう
      • まず1人で。
      • それから一緒に振り返りをする人を増やしていく。
        • ちょっとずつ輪を広げる
    • (前回もこの質問出ましたね？という話へ。)
      • 勉強会で同じ志を持つ人を探すのも大事かな
      • まず「自分でやってみる」→ それから「人に共有してみる」
  • Q: 日本では多くの場合（もちろん全てがそうではないが）開発者がQAを格下に見下す文化があると感じます。海外ではあまりそうではないように思えるのですが、どこに違いがあり、日本のそれを覆すにはどうしたらいいでしょうか
    • (そもそも海外のケースはどこで知ったの？とツッコミつつ)
    • (湯本さん) QAだからではなくて、個人のジョブグレードが低いからでは？
    • (前川さん) 受け身だから見下されるのでは？
      • 言うべきことは言う
      • 開発者、事業部の相談役になろう(受け身だと相談役にはなれない)
    • 別に格下に見られてもいいんじゃない？
      • 個人の悩みを業界の悩みに置き換えるのは違う
    • 「創造的な仕事をやる開発者にテストをやらせるのは悪いから、そこは安い人材に任せよう」という考え方が出発点？
      • テスト自動化の動きもそういう面がある
    • 人事制度まで突っ込まなきゃいけない問題でもあるから、悩むくらいなら転職！
      • スタートアップでスペシャリストになるとか
  • Q: 今後のQA活動で注力したいこと
    • (前川さん) QAより後の工程の人が関与できる体制にしたい
      • 後の工程・・・ カスタマーサービス(CS)
      • CSが企画フェーズに入っていけるようにしたい
      • QAとCSがタッグを組めるように体制整備中
  • Q: QAの仕組み作り、QA立ち上げをするとしたらまず何をやりますか？
    • (前川さん) 標準化から。
    • (ここで立ち上げ経験者として突然回答者にアサインされる くにおさん)
      • ベンチャーだと標準化は難しい
      • まずやること
        • テスト内容を整える
        • 製品の弱点を整理する
        • といったコンサル的な役割を担って、こいつすげぇ！と思わせる
      • 開発者目線、経営者目線も持って、それぞれに腹落ちさせるような方向へ
  • Q: プロアクティブな品質活動 (Shift Left) をしていくために
    • (前川さん) プロジェクトの早い段階から携わること
      • QAが仕様書にフィードバックを300件出した
      • 開発が予定より2ヶ月前倒しで終わった
        • その分他のプロジェクトにリソースを割けるようになった
    • (湯本さん) 失敗はケースバイケース、でも成功事例には何らかの共通点がある
      • 反面教師ではなく成功事例の方を聞こう

所感

• Agile QA Night!! の時に質問が全然出せなかったという反省から、今回は事前にWeb記事などを読んでから参加しました。
  • 事前準備、思った以上に大事でした。回答の意図を把握するためにも、的外れな質問で時間を無駄にしないためにも。
• テスト観点リスト公開、すごく楽しみです！！
  • ちなみに普段は Qbookのテスト観点 を参考にしてます。
• CSさんとの連携が重要と日頃感じていたので、その点について触れられていたのが良かったです。
• 質問内容に対し、問題意識が個人的なものなのか組織的なものなのか切り分けられていない、という指摘が多かったです。個々のテストにせよ自身のキャリアにせよ、問題の掘り下げ・分析ができれば前向きな取り組みができるのかもしれませんね。