WebのQAを5年間運営してみた

Copyright Since 1999 © GaiaX Co. Ltd. All rights reserved
WebのQAを5年間運営してみた
第5回Ques2014/11/11
GaiaX境野高義

Copyright Since 1999 2 © GaiaX Co. Ltd. All rights reserved.
第5回Quesでの登壇依頼がありました
株式会社ガイアックス：境野高義
グリー株式会社：山本健様

第5回Quesでの登壇依頼がありました
貫禄では完敗
＿|￣|○

貫禄以外のところで
頑張ります

agenda
1.イントロダクション(5分)
2.デジカメとWebのQAの違い(10分)
3.GXのQAチーム運営でやってきたこと(25分)
(以降、ガイアックスをGXと表記します)

agenda

自己紹介

趣味の話

楽器演奏が好きです FLYING PIGS BIG BAND バンドマスターやってます

カメラが好きです

もっぱら子供の写真ばかり

それ以上に
ハマっているのが

アイドル

http://www.momoclo.net/

http://dempagumi.dearstage.com/

http://www.lovelive-anime.jp/

http://babymetal.jp/schedule/

( ﾟдﾟ)
って顔しないでｗ

次に職歴の話

■遠い過去
・八百屋で電話営業
・アニメーションの制作進行
・JAVAプログラマー
■前職
・デジカメのQA6年間
■現職
・WebのQA6年目
職歴

前職：デジカメ(組込)のソフトウェアQA
QA 6年/ PM 1年

今のお仕事
•株式会社ガイアックス技術開発部QAマネージャー
•2009年入社、QAチーム立ち上げと運営
•チームメンバー7人
•私自身は非開発者

今日の話の前提情報として
GXの紹介

社員数:130人くらい
└開発：50人くらい
└営業+企画：70人くらい
平均年齢：31.7歳

運用
prj/事業
prj/事業
営業
企画
R&D
1事業が多くても25人位
小さくて数人
QAチーム
組織体制(2009年ごろ)

<ミッション>
“人と人をつなげる”
↑これ

そのための事業
Copyright Since 1999 © GaiaX Co. Ltd. All rights reserved.
airyフレッシャーズ
内定者フォローSNSCo-Blog
多店舗向けブログポータルASP
27

そのための事業
スクールガーディアン
学校裏サイト対策ソーシャルアプリサポート
サポート業務請負

全部で15くらいの事業
BtoBの会社です
若干の受託案件もやってます
使用言語: Perl / Ruby / PHP
・PCサイトがほとんど
・スマホサイトが少し
・スマホアプリはこれから

こんなこともやってます
http://gaiax-socialmedialab.jp/
Facebook、twitter、ソーシャルメディアに
関する研究機関

今日はこんな私が
・デジカメとWebの違い
・GXでのQAチーム運営
について話します。

agenda

デジカメとGXの比較の話

プロジェクト全体の規模感
比較軸
デジカメ
GX
コスト
3~5億円
数万～数百万円
稀に数千万円
人数
100人くらい
5～25人
期間
7～10ヶ月
数日～3ヶ月
企画や運用のフェーズは含まず(デジカメは2009年ごろ、Webは2014年境野調べ)

ソフトウェアの「開発＋QA」のこと
比較軸
デジカメ
GX
組織体制
開発部と品質保証部は対等
開発部の中にQAチーム
リリース判断
品質保証部
事業及び開発リーダー
人数
開発者30～50人
QA15～30人
開発者3～7人
QA0～4人
企画や運用のフェーズは含まず(デジカメは2009年ごろ、Webは2014年境野調べ)

プロセス
比較軸
デジカメ
GX
品質保証プロセス
ISO9001取得
組織体制、職務分掌が明確
「これまで」のやり方はあるけど
「決められた」やり方じゃない
開発プロセス
1機種6サイクルのテスト
毎サイクルがフルテスト
テスト中にコードが改変されていく
↑衝撃だった
実装部分+影響箇所のみテスト
(デジカメは2009年ごろ、Webは2014年境野調べ)

デジカメ、GXの違いはなんだろう？
デジカメ
GX
・市場不具合をその場で修正できない
・リコール怖い
・製造コストが高い
→設計・開発で失敗できない
→各過程ごとに期待通りかを検証する
・その場で修正可能
・少機能を短期間で開発+公開
→スピード重視
求められる品質が違う

デジカメのプロセスから学んだこと
[メリット] 人が増えるとプロセスが力を発揮する
•誰がやっても一定以上の成果が出せる
•工業製品の量産とか得意
[デメリット] プロセスを守る、が正義になりがち
•変化に弱い
•組織の硬直化
•気持ちの停滞

デジカメからWeb業界に
ジョブチェンジ

agenda

立ち上げ時の状況(2009年10月頃)
•テスト担当者がいたり、いなかったり
•当時は4人のテスト担当者(うち3人はアルバイト)
•知識・ノウハウが個人依存
•横のつながりが無い
•リリース後の不具合指摘あり、品質が問題視される
開発チームC
開発チームA
QA
開発チームB
QA

立ち上げ時の状況(2009年10月頃)
•新規開発はほとんど無い
•既存システムへの機能追加/不具合改修
•開発者3,4人が数日～2週間で開発
•QA1人が1日～1週間でテスト

課題と対策
•課題
•品質保証を組織に定着させたい
•品質問題を減らしたい
•開発者からのニーズ←ここポイント
•対策
•品質見てくれる人を採用しよう
→境野入社

まずやったこと：とにかく聞いてみる
•目的
•現状把握
•どんなふうに業務が回ってるのか知る
•やったこと
•テスト担当者との会話
•開発者との関係
•開発部以外の品質の考え

これ以降の出来事を

テストをあたり前に
テストからQAへ
新たなステージへ
2009~2010
2011～2013
2014～now
こんな感じでキレイに
説明しようと思った

全然うまくいかない
＿|￣|○

キレイに整理されてるわけじゃない
同じことをいろんな時期にやってる
↓
「やってきたこと」で整理してみよう

カテゴリ分けしてみた
•やってきたこと
•チームメイキング
•社内ポジションの確立
•知識、スキルの向上
•これからやりたいこと
•技術を使ったQA

チームメイキング
•目的は？
•チームとして一体感が欲しい
•各人の不安を取り除く、軽減する
•自分たちで動けるチームにしたい

チームメイキング実施例
•チームミーティング(週一)
•他案件の情報共有
•困ってること解決
•1on1 (隔週)
•境野と1対1で会話
•業務以外のことも大事

•マインドセット
•テスターからの脱却
•開発者のおまけじゃない
•開発者と同じ方向を向いてる

•チーム合宿
•ものさしを合わせる
•やりたいこと
•最強のテスト

合宿の資料

合宿風景:やりたいことって何？
上流工程から
参加
プロセス
プログラミング
スキル
テスト自体の
知識・スキル
仕事の
効率化
テスト実施環境
チームの体制
一体感
情報発信
品質の指標

合宿風景:最強のテストって？
←ここを軸にして
施策を決める

品質×効率×統計
がキーワードになる

社内ポジション確立
•目的は？
•開発者とのいい関係が必須
•社内からの「あのチーム何してるの？」
•信頼してもらえるチーム

•開発者との関係
•品質についてディスカッション
•QAがやりたいことを伝える
•必要な情報の量と質とタイミング
•BTSのフロー統一
•リリース前に「テスト完了」を必須
•全ケースの実施と、チケット処理の完了
→業務に近い部分の仕組みを固める

•社内全体にも認知してもらいたい
•全社会議での活動報告
•システムの品質だけじゃないよね？
→全社的に品質についての考えを広める
(品質で困ってる人は開発以外にもいる)

•メンバーの強化
•アルバイトメンバーの社員登用
•中途採用での即戦力採用
→会社、業務へのコミットが上がる
(現在は私含め7人全員が社員)

今はこんなメンバーです！(バックグラウンド)
Windows系BtoB
パッケージ製品テスト
接客
カーナビ品管
Web系テストエンジニア
鉄鋼メーカー(生産管理)
デジカメ(QA)
音響エンジニア
電話交換機エンジニア
Web系QA
NW系QA
大学(法学部)で挫折
卒業後ニート
バグチェッカーとして拾われる
CS・ユーザーサポート
Web系テスター
（ミュージシャン兼業）

知識、スキルの向上
•目的は？
•実務に直結してるところ。良くしたい
•QAエンジニアとしてここがキモだから
•ここを広げる、深めるのって楽しくない？

入社後まずやったこと
とにかく「テストケース」

なぜテストケース？
何をテストするのかを
抜けもれなく洗い出せるか

ケースのフォーマットを揃える
何を確認するかわかるようにした
(テスト技法とかは当時まだよく知らなかった)
2011年頃のケーステンプレが残ってた
表示要素
画面遷移
機能(正常系)
機能(異常系)

•教科書の設定
•現場の仕事がバリバリ進むソフトウェアテスト手法
•ソフトウェアテスト技法ドリル
•JSTQBFLの全員取得
•社内勉強会

•他サービスの「あたり前」を知っておく
•Facebook(ページ、アプリ)
•twitterと連動するシステム
•最新スマホ情報
•ツールの活用
•負荷テストしてくれるWebサービス
•リンク切れ自動チェックツール
•Firefoxアドオンいろいろ

•「テスティング以外」での貢献
•仕様・プロセスの改善提案
•サポートチームとの連携
•市場不具合の調査

•他社のQAチームとの交流会
•過去2回、他社のQA担当者と交流会を実施
•「WebなQA交流会」を実施
•2014年3月初めて自分で主催
•20人位集まった
•人脈・世界がものすごく広がった

技術を使ったQA
•目的は？
•開発とQAの距離を縮める
•プログラムできたほうが楽しくね？
•特にWebはコード書けてなんぼ(語弊あるな)

Dev
QA
ここ
DevとQAを繋ぐポジション
SWET?

技術に対する障壁は低い
デジカメ
GX
個人でデジカメ作れない
→QAが技術を理解するのは難しい
→開発技術を知らない状態でのQA
個人でもWebサービス作れる
→個人(非開発者でも)の技術習得は可能
→開発者と技術を通して話がしやすい

技術を使ったQA(始めていること)
•リグレッションテストの自動化
•SeleniumWebDriver+Rspec+Jenkins
•テスト環境の構築
•Vagrant
•開発者の手を借りずにやれること
•バッチ実行
•DBの中身

開発とQAが近づくという点では
•DevQUTってよさげ？
•Testing Casual Talks #1
•@snskさん、@YasuharuNishiさん
•Dev+QA+User+Tools
•軽量品質保証
•考え方はものすごく惹かれてる
•何やったらいいか悩んでるところ
http://www.slideshare.net/shinsk1/testing-casualtalks1-devqut-snsk-yasuharunishi

そんなこんなで

こんな取り組みを
してきました
していきます

5年間運営してみた結果
•テストするのがあたり前になってる
•品質に責任を負うチームとして認知されてる
•プロジェクトに貢献できてる感はある

5年間運営してみた結果
Test is Costって思われたり、
見積もりが大きくズレて怒られたり、
市場にイタイ不具合を出しちゃったりして
おちこんだりもしたけれど、私たちはげんきです

でも困ってることもあるので聞いて欲しい
(4つありますw)

困ってること１：属人化問題
•1案件を1人で担当する体制は変わってない
•A案件についてはAさんしかテストできない
•Aさんいなくなったら大変

困ってること１：属人化問題
•私なりの答え
•今は冗長化、標準化よりも属人化でいい(規模が小さいから)
•その人にしか出せない価値を発揮してもらう
•いなくなったら困る問題は解決できない
•いい解決方法があったら教えてほしい！

困ってること２：スキルアップの仕方
•QAとして何を身につけたらレベルが上がるのか？
•実務に活かせないと意味が無い← ここ重要

困ってること２
•体系的に、ってうまくいかない経験
•ピンポイントでもいいので実務に直結する「何か」
•あるいは「何か」から実務に直結させに行く
•キャリアパスとかも含めて他社事例を知りたい

困ってること3
•高齢化問題
•QAは全員中途採用
•全社平均が31.7歳のところ、QAは37歳くらい
•QAやってみたいという学生(新卒採用)はまずいない

困ってること3
•新卒でQAに興味を持ってる人がいないのは仕方ない
•新卒エンジニアへの啓蒙活動はしている
•ま、まぁ仕方ないのかなぁ、、、
•途中からQAになる、というパスがメインなんですかね？

最大の悩み
困ってること４

運用
prj/事業
prj/事業
営業
企画
R&D
QAチーム
組織体制(2009年ごろ)再掲

prj/事業
prj/事業
営業
企画
R&D
事業に紐付かない
QAメンバーがいる！
QAチーム
機能別から事業別へ移行していく
prj/事業
QAが事業所属になる

＿人人人人人人人人人人＿＞事業に紐付かない＜
＞QAメンバーがいる！＜￣^Y^Y^Y^Y^Y^Y^￣

困ってること４
事業に紐付かない
=テスト対象が無い
このメンバーはどうやって
バリューを発揮していくのか!?

最大の悩み
私なりの考え
「事業のQAを助ける何か」
「事業を助ける何か」
なんだけど、それってなんだろう
いいアイディアあったら教えてくださいm(__)m

本日のまとめに入ります

品質も好きだけど、
Web業界の雰囲気が好き

プロセス(再掲)
比較軸
デジカメ
GX
品質保証プロセス
ISO9001取得
組織体制、職務分掌が明確
「これまで」のやり方はあるけど
「決められた」やり方じゃない
開発プロセス
1機種で6サイクルのテストを実施
毎サイクルがフルテスト
テスト中にコードが改変されていく
↑衝撃だった
実装部分+影響がありそうな箇所のみテスト
(デジカメは2009年ごろ、Webは2014年境野調べ)
この文化

品質保証って、ルールを決めて、
それを変えない、守らせるもの、
かと思ってた
↓
「守り」のイメージ

ゴールは
「いいものを世に送り出す」

「いいもの」も変化している
QAも変化に対応していく
このダイナミックさが楽しい
↓
「攻め」のイメージ

会社・事業として
プロジェクトチームとして
QAチームとして
個人スキル×チームワーク

5年間運営してきても
ぶっちゃけ未成熟なチームです。
皆さんからアドバイスいただきたい！

オープンなWeb業界なんだから
QAチーム同士も、
強みも弱みも、
スキルもマインドもノウハウも、
課題も解決策も、
オープンにして
繋がっちゃえばいいんじゃないの？
(からの助け合い)

ご清聴ありがとうございました

WebのQAを5年間運営してみた

More Related Content

What's hot

Viewers also liked

Similar to WebのQAを5年間運営してみた

WebのQAを5年間運営してみた