Web Service QA Meeting June-2018に参加してきました #WebQA

2018/6/8のWeb Service QA Meeting June-2018 – connpassに参加してきました。

JaSST’18 Tokyoでも行われたようなパネルディスカッションを、

• 事前のお題３つ
• 参加者からの投稿でいいねが多かったお題

について行われました。

（※注：本記事中のメモ部分は私が書いたものなので、モデレータ・パネリストの方の発言と異なる可能性があります。）

お題1「0からQAチームを立ち上げるまで」

モデレータは米山さん。

パネリストは山本健さんと鶴岡さん。

自分も完全ゼロからはほぼ経験がないので、QAチームの立ち上げに関してはとても興味がありました。

立ち上げ時に苦労した話として、「そもそもQAが居なかったので文化がない、まず周りに価値を認めてもらうところからのスタート」というのが大きかったようです。

ただ一方で、お二人とも

• 「QAってこういう働きをするものなんですよ！」と、逆に文化がないことを利用する
• 自分の描く理想のQA像を実現していく

など、苦労しそうな状況をうまく利用？してQAとしての立場を固めていった、というお話が印象的でした。

QAとしてどんどん情報を仕入れつつ、周りに貢献することで立場を得ていくというのはあるべき姿ですね・・・。こういった動き方をするには「QA・テスターのしごとはここまでです」といった線引きをしてしまわずに、貢献できるところはどんどんやっていく、という姿勢が必要だなと改めて感じました。

立ち上げは苦労も多いけれども、その分勉強にもなるし楽しみもある。

かっこいい・・・。

メモ

• 何から着手したか（苦労話）
  • 鶴岡さん
    • 開発などプロセス全体の把握
    • 改善点探し
    • QAってこういうお仕事なんだよ、こういう状態を目指したいよを話した
      • かゆいところに手がとどくQAです！とか。
    • チケット単位でリリースしていた
      • やりづらかったのでマージして定期リリースにした
    • 要求分析していなかった
      • 上流から入っていった
      • まわりがQAの働き方を知らなかったので、「QAはこんなもんですよ！」と言って入っていった
      • 会議に割り込んでいった
  • 山本さん
    • 既存のプロセスに入って、肩代わりした。
    • そのあとで、どう改善するかのアイディアを出した。
    • QAがいない状態で入る＝文化がない状態
      • 何をしてほしいのかをとらえる。
      • 立ち上げのときには要求されることがコロコロかわる
      • そこを調整したり、ついていったりに気をつけた。苦労した。
      • 手を変え品を変え。
• 立ち上げ時に意識するべきこと
  • 山本さん
    • 良くないQAに足ひっぱられた経験がある人がいたりする
    • 触ってほしくないところに触らない
    • フレンドリーな人の役にまず立つ
      • そこから存在感を高めていく
    • 社長のやること肩代わりしまくった（ｗ）
    • 米山さん
      • ローンチする前に入った？QAが入ることによってスピードが遅くなった状況と戦うことがあるのでは
    • Web系だと遅らせちゃうことは悪なので、多少残業してでもなんとかした
    • 反感買っちゃう。遅らせると。
  • 鶴岡さん
    • 困っている人を見つけて、なるべく率先してあげる
    • 米山さん：二人目にどんな人を選んだか
    • 自分と真逆の人がほしかったので選んだ。
    • 米山さん：それなりにストレス？
    • そんなことはなかった。自動化とかもやってくれて助かった。
  • 山本さん
    • スキルをばらして集めたほうがいい。が、態度のところ、献身的にやってくれる人を探す。
• 立ち上げが好き？立ち上げたら次に行きたくなる？立ち上げ中毒？
  • 山本さん
    • 立ち上げが好きというよりは、いろんな悲劇に襲われて転々としている
    • 立ち上げってすごく面白いと思う。最初に文化を作る。
    • 自分がいいとおもったことができる。
  • 鶴岡さん
    • そのぶん勉強しないといけない。のはプレッシャー。
    • 疲れちゃったりもする。でも面白い。
    • 自分の理想としているようなQAが実現できる。
• Q:100人規模の組織でQAをゼロから立ち上げるときに意識すべきこと
  • QA役をやってる人がいるはず
  • ディレクターのそばに言って「やります」っていう
  • この規模になってやっと、ということは偉い人がQAの価値をわかってない可能性
    • 鶴岡さんだったら行きたくないカンジ
    • 社内事情がつらそう（山本さん）
• Q:グローバルな組織・チームでの立ち上げで特に意識したほうがいいこと
  • お互いマイペースでやろうね、的な結論になったことはあった（山本さん）
  • 遠く離れちゃうとやりづらいですよね
    • ひとつの基準で作りましょうとか言うと絶対炎上する
• 最後にアドバイス
  • 鶴岡さん
    • 公の場で言えなかったりするので、飲み行きましょう
  • 山本さん
    • リフレッシュする趣味を持ったほうがいい
    • 自分はとんかつ
    • リセットボタンを持ちましょう

お題2「キャリアプランとビジョンについて」

• モデレータ：米山さん
• パネリスト
  • 山本（久）さん
  • 柿崎さん
  • 山本（健）さん

「エモい話だ！」と語彙力少なめでのめり込んで聞いてました。

キャリアパスどうしていこう・・・と思うかもしれないけれども、そもそもWebの世界で決まったキャリアパスなんてない、と。むしろそこを自分で切り開いていくから楽しいんじゃないか！と。

そのとおりですねほんと。道がない分どこにでもいける、というところに面白さを見いだせるようになると、Webの世界を楽しんで生きていけそです。

メモ

• QAエンジニアのキャリアパスはどういうものがある？テスター→QAリーダー→品質保証マネージャー→そのあとは？日本ではCQOはまだ浸透していないように見えます
  • 山本（久）さん
    • マネージャと一緒にCTO育てようとしている
    • QAエンジニアで、プラットフォーム作れるひと、QAのスペシャリストを育成しようとしている
    • 今会社に存在しない人物
    • エンジニアリング寄り
    • ISTQBだといろんなドメインに特化しているのでそういうのもあるとおもう
  • 山本（健）さん
    • 僕も悩んでいる
    • ふつうのテスターから見て位が上がったところで
    • 最近自動化のトピックが流行ってるし募集が多い
    • マネージャが一段落してる
    • いろんなポジション楽しめるマインドでいたほうが幸せ
  • 柿崎さん
    • ボクすでにCQO的な立場で仕事してる
    • この中でWeb系じゃない人
    • そもそもWeb系に来たんだったらキャリアパスとか関係ないでしょ。てめーでつくれよ。
    • 影響範囲がどんどん広がっていく。スタートから。
      • ひとつのキャリアパスの形でもある
      • それってマネジメント寄りの話。ビジネス寄りの話し。
      • QAエンジニアを名乗るのであれば、技術でそうなるのでは
      • たとえば新しいテストのフレームワークを生み出すとか、メソッドを生み出すとか、テストの世界を変えていく
        • これがWeb業界における新しいキャリアの積み方なんじゃないの？
• 今のキャリアを想像していましたか？今後のキャリアプランは？
  • 山本（久）さん
    • 若い頃は想像していなかった。
    • 今後は、自分が行ってなにかお役に立てるところがあれば行きます、というスタンス。
  • 山本（健）さん
    • 40過ぎて生きてると思ってなかった
    • もともと美術系の大学にいって、画家になろうと思ってた
    • 子供の頃PC好きで、たまたまこっちに戻ってきた感じ
    • こんな楽しく仕事できるとは
    • 想像しなくても生きていける
    • キャリアプランとしてきちっとしたものはないけど、面白いものに関われたらいいなぁ
      • その中でなにかの役に立てればいいなぁ
  • 柿崎さん
    • 月並だけど、全然想像していなかった
    • 「自由にやっていいんだ」というのを教えてくれた人たちがいる
    • 今日ここに誘ってくれた人たちにも会うことができた
    • 出会いの中でできたものでキャリアが形作られた
    • 計画的偶発性理論
      • キャリアに対する考え方
      • ８割は偶然起きたことの結果
      • ３年先、１０年先という考え方もあるが、「今を大事にする」という考え方もある
      • 好奇心を持つ、新しい機会を実現できるように動く
      • その分野に強い人に遠慮なく会いに行ってみる
      • マネジメントに自信が持ててきたので、中小企業買って再建するとかもやってみたい
• キャリアパスに正解はないと思うがどんなふうにメンバーに見せたらいいか悩んでいる
  • 山本（久）さん
    • 無理はしない。個人の幸せが一番大事。
    • ストレスを感じるようなら次にいったほうがいいし、やりきったら次にいったほうがいい。
    • 楽しく仕事をする。が一番。
    • 納得する
  • 山本（健）さん
    • Webの世界面白すぎて悩む必要ない
    • Webなんかやりたい放題
    • いろいろ楽しんでほしい
  • 柿崎さん
    • Web業界の中でもエンジニアってなるとプログラミングでゴリゴリ、という感じがあるが、実はプログラミングとかによらない動き方をしちゃうと、キャリアがぼんやりする。
    • これはWebディレクターとかにも同じ悩みがある。
    • テクニカルな解決方法を教えることでキャリアパスやスキルアップをする指導もできる
    • そのうち内発的な動機が生まれてくれば自由に動ける
    • 一緒に悩む。俺ならこうするけど君の道は違うかもしれない。といった魅せ方。
    • あとは俺の背中を見ろ！ですね。
  • 山本（久）さん
    • 来た人には教える。来ない人にはやらない。
    • それが一番ROIがいいと思っている。（言い方悪いけど）
    • みんなを救う気がない。でもやる気がある人を救いたい。
  • 柿崎さん
    • 今のところ運良く部下がみんな強い動機をもって話を聞いてくれる。昔は違ったけど。
• エンジニアからマネジメント側にうつった際、大変でしたか？
  • 柿崎さん
    • これらは全く別のスキルセット
    • 裏で陰口いってるやつとも話ししないといけない
    • モチベーション上げるとかわかんねーよ！というきもち
    • でも学習していくとわかったりもする
  • 山本（健）さん
    • 部下を抱えるなら、部下の評価をできる権限をもらってください
    • ここが無いと、褒めたのに評価あがらなかった的なズレが生じてよくない
• キャリアに対して悩める武士へ一言
  • 山本（健）さん
    • 悩んじゃいけない！
  • 柿崎さん
    • 全く同意
    • いろんなものや人に興味持って会いに行ってみろ！

お題3「テストの生産性について」

• モデレータ：小山さん
• パネリスト
  • 柿崎さん
  • 菅原さん
  • 中野さん

テストの生産性について、は特にパネリスト間で大盛り上がりでした。

私も結構、テストするプロダクトやサービスごとに「これどうやって測ったものかな」と悩んだりします。特にWebの場合はプロダクトのリリースの速さを重視することも多く、テストによってリリースが遅れる＝ビジネスにおける損失になってしまいます。

QAとして、いかにスピードを落とさずにテストを行っていくか、生産性を測るかについて、他のドメインのQAよりもビジネス（儲け・企業成長）のほうに考えがよっているなぁという印象です。

メモ

• テストの生産性ってどう見てるの？
  • コヤマンさんは「イケてる質問」だと思った
  • Web系はスピードを求められる。その中でテストがイケてるかどうかを考えようとすると、旧来の方法だと重くなる
  • お前スピード殺すんじゃねぇよって言われてしまう
  • 中野さん
    • コヤマンさんを納得させればいいのね？
    • 基本計測
      • 障害件数
      • 自動テストがきちんと要件を満たした状態で動き続けられているか
    • QAの役割
      • テストを丸受けするようなスタイルではない
      • 求められる品質に対して不足するところを補う
      • テストの支援
      • 技術指導
    • ビジネスアウトカムのところをQAの成果だとすると、儲かるプロダクトに関わりたい。
      • それってあんまりしっくりこない
    • 生産性指標は誰のためにあるか
      • 自分たち
      • 経営層
      • ということは、全員が腹落ちしている必要がある。
      • →ビジネスアウトカムと遠い
    • 金額は直接見ていない
  • 柿崎さん
    • お金を見ている
    • テストにどのくらいの工数をさいてどのくらいのお金がかかっているのか
    • 単体でどのくらい使っているからいい悪いではなく、プロダクトのコンディションがどうなのかを見るために見ている
    • サイバードはもともとゲームなのでゲームのテストはずっとやっていたが、お金をどのくらい使っていて売上にどのくらいインパクトがあるかは全然みてなかった。だから今見ている。
    • 結果の検出率は大事だと思っている。
    • テストのメトリクスも見てる。
    • ありとあらゆるものを指標化してみている。
    • どう解釈するかはあとからの頭の使いよう。
    • バグの検出率の先には、信頼度成長曲線などを使って経営陣に説明したりした
    • サイバードの売上が落ちた時期＝品質が落ちた時期
      • ゲームのメンテとかで、ポシャっちゃった
    • 絶対値より変化を見たい
• 売上上がったって、それゲームが面白かったからじゃん！って言われがちだけど、テストが貢献したというのは、どうやって示す？
  • 柿崎さん
    • 純粋に、自分がガバナンスを効かせたら不具合収まった
    • バグの重要度やリスクに応じてコントロールした
    • メトリクスはシンプルな指標を継続的に取る必要がある
  • 菅原さん
    • AutomationQAチーム
      • E2Eのテストオートメーションのコード書いたり
      • システムテストのインフラ部分だったり
      • QAも
    • 特に生産性をはかる、とかはやってない
    • 生産性をはかる行為自体が生産性を落としているよね
    • マネージャのための仕事が一番嫌
  • 柿崎さんからの本気のダメ出し〜
    • テストの生産性はプロダクトのライフサイクル全体で見ないと
    • お客さんに何刺さるかわからないけど何かし続けないといけない、という状態では
    • スクラムのベロシティとかは見ているのでは？
  • 菅原さん
    • 今関わっている範囲ではやってない
  • 柿崎さん
    • やれよー

第２部

ここから先は事前募集＆会場から希望が多かったもの。

プロジェクタで質問を映して「答えたい人！」でパネリスト・モデレータが出てきて答えるパターンで進みました。

個人的には日高さんが前でしゃべってるのが見られてよかった←

開発が出来ない/知らないQAのに未来は無いと思いますか？

聞く前は「未来無いでしょ・・・」と思ったものの、実際に皆さんの話しを聞いて、小山さんのがしっくりきました。

開発について教養レベルでも知らないのはまずい、未来ない、と思います。開発者と話せない、というのが一つと、あとはソフトウェアテスト界隈で会う皆さんは開発についても知ってる（やってなくても）し、あとに出てくるチームビルディングなども含めて、２本３本の柱を持っている人が多いです。

そんな中で、基礎となるソフトウェア開発も知らない状態でずっと年齢を重ねたら、そもそもお呼びでないだろうなぁと思います。だってもっといろいろ出来る人が他にいるわけですし。

以下メモ。

• 柿崎さん
  • 知らないのはちょっと駄目かと
  • CS系の話しはちょっと知ってないと
  • QAの想像
    • 人と人との間をつなぐ仕事
    • 自分でバリバリコード書きますとかバリバリ設計できますという人以外でも、才能を発揮している
    • ソフトウェア＝知的生産物
• 山本（久）さん
  • 未来あると思います
  • 開発のこと知らなくても、品質管理のことは知っててほしい
  • マネジメントなのか、品質管理なのか、など
  • 得意なことがあればコードがかけなくても未来があるとおもう
• 中野さん
  • くにおさんと同じ
  • 勉強すべきだと思う。どっちが良いQAかを考えたら。
• コヤマンさん
  • できないQAに未来はある
  • しらないQAに未来はない
• 菅原さん
  • 未来はある、が、求められているスピード感の中でよりよいものを作る、コミュニケーションミスを減らす上で、知識としてあったほうがいい
  • マーケッターだったり、ビジネスの抱えている問題も知らないといけない
  • 開発に限らずいろいろなロールの悩み・大事にしていることを勉強してください

全てのテストを開発者が自動化した場合でもQAは必要だと思いますか

要るでしょ・・・。

以下メモ。

• コヤマンさん
  • すべてがないよね
  • 自動化したテストはUXまで見られますか？価値はわかりますか？
  • 全部をコードで判断できるんだったらいいよ
• 山本（久）さん
  • 必要
  • すべてのテストがカバレッジ100%だと仮定してもバグは出る
  • トータルで各テストレベルで見る、バランス、整合性
• 中野さん
  • セキュリティ、今はわからないけど、自動化される可能性が高いと思っている
  • UXが評価できないよねーは、チームにデザイナが居れば解消されそう
    • 開発の中で完結する可能性はある

チームビルディングの工夫

最近うまくいってないので気になるポイントです。

隊長みたいな名付けは個人が主役として意識を持ってもらうのに良さそう。

• 山本（久）さん
  • すべての人に＊＊隊長と名付けて、責任感を持ってもらう。ひとりひとりが主役。
• 山本（健）さん
  • ７人の侍に当てはめる
• 日高さん
  • 具体的にどんな役割を？
    • ベテラン
    • リーダー
    • 新人
    • サブリーダー
    • 風来坊など

QAが提供する価値とはなんでしょうか？

気になる・・・！最近の私は「文化づくり」を推してます。

• コヤマンさん
  • テストをなんでしたいの？
    • 今の状況を知るため
    • カメラや写真のメタファ
    • 今イケてるの？駄目なの？
    • QAが提供する価値＝今の品質状態がどうなのかを知ること自体
• 山本（久）さん
  • 会社の利益を最大化する
• masuharaさん
  • 品質を保証している感じがしない
  • いいものを届けるために必要な情報を集める
• つるおかさん
  • プロダクトに対しての品質を作り込む
  • 保証以外にもやれることはある
• 柿崎さん
  • 正しく学習できること、を提供するのが価値
  • 企画考えた人とかがよかれと思って立てた設計・仕様が、バグによって「実際良かったんだっけ？」ってなっちゃう
• 山本（健）さん
  • 成功する確率を上げる人

会社の偉い人たちにQAの価値を伝えるにはどうすればいいですか？

切実だ・・・。

• 山本（久）さん
  • 不具合１件外に出さないとしたらどのくらいか
  • リリース前に不具合１件見つけたらどのくらいか
  • 件数、デフォルトでリリース前にどのくらい見つけたか
  • 上流に入りつついかに減ったか
    • １件につき、開発者の工数が＊時間かかる
    • 何人日減ったか
    • をQA効果として出す
• 山本（健）さん
  • 偉い人はお金のことを考えている
  • 細かいバグ見つけて喜んじゃうボクらの一方、彼らは事業に影響あるようなことを気にしている
  • 同じ価値観で話す
• 中野さん
  • 決めにかからないほうがいいと思う
  • Web、朝考えて昼作って夕方リリースする
    • もっと圧縮したい
  • 自分が何に価値を感じるかを相手に伝える。話す。
• コヤマンさん
  • 結局、知った情報を誰が使うか
  • 知ったことを教える。情報提供。
• 柿崎さん
  • マネージメントのための仕事はヤダ、って言われた。
    • これ間違ったところがある
    • マネージメントは管理じゃない
    • マネージメントは「なんとかすること」
  • なんとかしてください
• 山本（健）さん
  • 誠実に
• 菅原さん
  • 同意見！

まとめ

特にQAが立ち上げとキャリアパスに関する話しがグっときました。

どちらも、自分で足場を固めて道を切り開いていくようなマインドで向かっていくと、大変ではあるものの楽しく進んでいけるという点が共通していると思います。

今回モデレータ・パネリストをされていた皆さんはまさにそういう道を歩んでいる方々なので、自分も通る道は違えど同じような切り開き方をしていきたい・・・！と、最近ゼロになっていたモチベーションを取り戻せました。