webのqaを5年間運営してみた

Copyright Since 1999 © GaiaX Co. Ltd. All rights reserved

WebのQAを5年間運営してみた第5回 Ques 2014/11/11

GaiaX 境野高義

Copyright Since 1999 © GaiaX Co. Ltd. All rights reserved.2

第5回Quesでの登壇依頼がありました

株式会社ガイアックス：境野高義

グリー株式会社：山本健様


第5回Quesでの登壇依頼がありました

貫禄では完敗＿|￣|○


貫禄以外のところで

頑張ります

agenda

1. イントロダクション (5分)

2. デジカメとWebのQAの違い(10分)

3. GXのQAチーム運営でやってきたこと(25分)

(以降、ガイアックスをGXと表記します)


agenda






自己紹介


趣味の話


楽器演奏が好きですFLYING PIGS BIG BAND

バンドマスターやってます


カメラが好きです


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


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


アイドル


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


次に職歴の話

■遠い過去・八百屋で電話営業・アニメーションの制作進行・JAVAプログラマー

■前職・デジカメのQA 6年間

■現職・WebのQA 6年目


職歴

前職：デジカメ(組込)のソフトウェア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フレッシャーズ内定者フォローSNS

Co-Blog多店舗向けブログポータルASP

27

そのための事業


スクールガーディアン学校裏サイト対策

ソーシャルアプリサポートサポート業務請負


全部で15くらいの事業

BtoBの会社です若干の受託案件もやってます

使用言語: Perl / Ruby / PHP

・PCサイトがほとんど

・スマホサイトが少し

・スマホアプリはこれから

こんなこともやってます

Copyright Since 1999 © GaiaX Co. Ltd. All rights reserved.30 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人QA 15～30人

開発者 3～7人QA 0～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週間で開発

• QA 1人が 1日～1週間でテスト


課題と対策


• 課題

• 品質保証を組織に定着させたい

• 品質問題を減らしたい

• 開発者からのニーズ ←ここポイント

• 対策

• 品質見てくれる人を採用しよう

→境野入社

まずやったこと：とにかく聞いてみる

• 目的

• 現状把握

• どんなふうに業務が回ってるのか知る

• やったこと

• テスト担当者との会話

• 開発者との関係

• 開発部以外の品質の考え



これ以降の出来事を


テストをあたり前にテストからQAへ新たなステージへ

2009~2010 2011～2013 2014～now

こんな感じでキレイに

説明しようと思った


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

キレイに整理されてるわけじゃない

同じことをいろんな時期にやってる

↓

「やってきたこと」で整理してみよう


カテゴリ分けしてみた

• やってきたこと

• チームメイキング

• 社内ポジションの確立

• 知識、スキルの向上

• これからやりたいこと

• 技術を使ったQA


チームメイキング

• 目的は？

• チームとして一体感が欲しい

• 各人の不安を取り除く、軽減する

• 自分たちで動けるチームにしたい


チームメイキング実施例

• チームミーティング (週一)

• 他案件の情報共有

• 困ってること解決

• 1on1 (隔週)

• 境野と1対1で会話

• 業務以外のことも大事



• マインドセット

• テスターからの脱却

• 開発者のおまけじゃない

• 開発者と同じ方向を向いてる



• チーム合宿

• ものさしを合わせる

• やりたいこと

• 最強のテスト


合宿の資料


合宿風景:やりたいことって何？


上流工程から参加プロセス

プログラミングスキル

テスト自体の知識・スキル

仕事の効率化テスト実施環境

チームの体制一体感情報発信

品質の指標

合宿風景:最強のテストって？


←ここを軸にして施策を決める

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


社内ポジション確立

• 目的は？

• 開発者とのいい関係が必須

• 社内からの「あのチーム何してるの？」

• 信頼してもらえるチーム



• 開発者との関係

• 品質についてディスカッション

• QAがやりたいことを伝える

• 必要な情報の量と質とタイミング

• BTSのフロー統一

• リリース前に「テスト完了」を必須• 全ケースの実施と、チケット処理の完了

→業務に近い部分の仕組みを固める



• 社内全体にも認知してもらいたい

• 全社会議での活動報告

• システムの品質だけじゃないよね？

→全社的に品質についての考えを広める

(品質で困ってる人は開発以外にもいる)



• メンバーの強化

• アルバイトメンバーの社員登用

• 中途採用での即戦力採用

→会社、業務へのコミットが上がる

(現在は私含め7人全員が社員)


今はこんなメンバーです！(バックグラウンド)


Windows系BtoBパッケージ製品テスト

接客カーナビ品管Web系テストエンジニア

鉄鋼メーカー(生産管理)デジカメ(QA)

音響エンジニア電話交換機エンジニアWeb系QANW系QA

大学(法学部)で挫折卒業後ニートバグチェッカーとして拾われる

CS・ユーザーサポートWeb系テスター（ミュージシャン兼業）

知識、スキルの向上

• 目的は？

• 実務に直結してるところ。良くしたい

• QAエンジニアとしてここがキモだから

• ここを広げる、深めるのって楽しくない？




入社後まずやったこと

とにかく「テストケース」

なぜテストケース？


何をテストするのかを

抜けもれなく洗い出せるか


ケースのフォーマットを揃える何を確認するかわかるようにした

(テスト技法とかは当時まだよく知らなかった)

2011年頃のケーステンプレが残ってた

表示要素

画面遷移

機能(正常系)

機能(異常系)


• 教科書の設定

• 現場の仕事がバリバリ進むソフトウェアテスト手法

• ソフトウェアテスト技法ドリル

• JSTQB FLの全員取得

• 社内勉強会



• 他サービスの「あたり前」を知っておく

• 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年間運営してみた

Leadership & Management