JaSSTソフトウェアテストシンポジウム-JaSST'15 Tokyo より
自己紹介
登壇者
- 柿崎憲(株式会社ミクシィ)
- 藤澤正通(株式会社ネクスト)
- 松尾和昭(株式会社クックパッド)
- 山本健(グリー株式会社)
モデレータ
- 中野直樹(株式会社ネクスト)
このセッションのテーマ
複数のウェブサービス開発のQAからテストの現在と未来を考える
現状の組織や開発プロセスについて
柿崎
- QA組織の変化例(mixiのQA組織の場合)
QA組織発足前
- 週末に落ちてる
- 負荷の問題
- テストせずにリリースしてた
大規模ウォーターフォール（mixiが一番盛り上がっていた頃）
- 400人規模
- 企画・開発・デザイン・QAで組織が完全に分かれていた
複数のチームに分化（3,4年前）
- スクラム開発
- 全てのチームにQAを配置
QAチーム分化（赤字になっていた頃）
- QAチーム・人員にコストを支払えなかった
現在
組織が変化していった結果
- 最適化
- コンパクトな開発環境
- バグによる影響を小さく抑えることができる仕組み
- 昔…とにかくデカい花火を打ち上げよう！
- 今…ユーザの要望を聞く。まずは一部のユーザに見せる仕組み。
QA組織が変化していって良かったこと
- 各チームが「自分たちでテストしなくちゃならない」と意識を持ってくれた
藤澤
チーム体制
- 開発チーム（プランナー、デザイナー、開発者）、マネージャ、QA
- 数百人の開発チームに対して、QAチームは7人
開発方法と特徴
QAチームが行うこと
- Kickoff、チェックリスト、QAテストは企画によって入る
- Kickoffミーティング…情報交換、QAテストの有無検討
QAチームのテーマ
- より良いものづくりの仕組みを創ることで挑戦する人々を守り立てる
松尾
- クックパッドの大きなサービスの中に多くの小さなサービスがある
- 昨年は全社的にモバイルに力を入れた
- のべ月間利用者数5042万人。
- その半数以上がスマートフォン
開発体制
- 技術基盤/インフラは全サービス共通
- それぞれのサービス開発は独立している
- ただ、サービス間は連携している
リリースまでの流れ
- クックパッドのパイプライン
- Development
- Source Code Review
- Continuous Integration
- Production Test
- Production
- 詳しくは2014jasst東北の招待講演のp37参照
- お客様に不利益があっても、すぐに戻せるなら良いのではないか
- ロールバックは約3分で完了する
- そのため、Webについてはテスト期間がほぼ存在しない
- アプリに関しては、一度リリースすると修正が大変なため、検証のフェーズが存在する
QAチームの仕事内容
- 改善活動をしている
- Failure Teaches Success
- KPT
- テストをしている
- 手動テスト
- 自動テストの促進
山本
- ゲームで収益を得ている
- 他にもコマース・ライフスタイル事業
開発体制
- QAチームは70名ぐらい
- Test Engineering Teamは8名
- ベンダーさんにテストをお願いしていく
- それ以外に、テストの自動化を目指して行っている
チームのこれまでについて
柿崎
- 大規模ウォーターフォール＝大企業病になっていた
- 最初は、QAチームは「開発チームがスケジュール遅れやがって」「できるだけ多くのバグを見つけるんだ」という意識だった
- 全てのチームにQAを配置→高コストになった
- QAチーム分化→「QAやってよ！」「いや、人が足りなくて…」という状態に。
- 全社的にお金がやばかった→コスト意識→自分たちでテストしよう！
- 今はスクラムマスターが足りない
藤澤
グループ発足当時
- 開発チームいっぱい、障害もいっぱい
- QAチームは2人だけ
最初に着手したこと
- QAテストを開始した→テストチーム辛い。リリース情報を見てからじゃないとわからない→Kickoffとチェックリストを行った
松尾
QAチームの体制
- 2014年1月時点のQAチーム所属者は0名（パートタイムは1名）
- 2014年1月で1名になった（松尾さんが入社）
- 2014年11月で松尾さんを含めて2名（1名はバイト）
モバイルアプリ開発体制の再構築
- JaSST'14 Hokkaidoでの事例発表を参照
- WEB≠モバイル
- リリースした後に戻せない。障害がずっと残る
- 以下の点を意識した
- 何が違うのか
- どう改善できるのか
- 改善は組織に適しているのか
- DevとTestで追うべき責任に差がある
ソフトウェアを作る上での考え
- ユーザファースト
- 隣の人を幸せにできますか
- リリースした後にバグがあると心が痛む
山本
QA組織の変遷
- 最初はQA組織が無かった
- 2011年8月に発足（CSの部署の「お問い合わせが多すぎる」という思いから誕生）
- 発足当時の雰囲気は「開発のあらを探せ」
開発手法
- ゲーム系の場合はVモデルにはならない
- プロデューサーがやり直し指示などがある
質疑応答
CSからQA立ち上げだと、どういう人を引っ張ってきたのか（松尾）
柿崎
- 企画ディレクターが開発スキルを持っていなかったりした。
- CSの中からQAスタッフが現れて、企画者に伝えていた（最初は）
- 少しずつ話の分かる人を集めていって話し合った
- たんぽぽグループがいて、そういう人たちがテストの隙間を埋めてくれた
山本
- GREEもだいたい同じ。
- CSのマネージャがQAの経験があったりした。
- テスト経験者が沢山いたので歩み寄っていった。
mixiは立ち上げては潰すような運営をしていた。その際に立ち上げるたびにQAチームを集めることが多いが、そういうことはあるのか？（柿崎）
藤澤
- あまりない。基本的に開発チームがやる。特にスタートアップは。逆に声がかからないのが問題だった。
- 案を出して、小規模でモックを作ることが多い。そのため、QAチームが最初から入ることがある
- むしろ、QAが入るタイミングはいつが良いのか聞いてみたい。
松尾
- 大きなリリースが決まったら、開発マネージャから聞いて入ることはある。
山本
- 新規事業は予算がないので、製品の魅力に振りたい。
- ミッションクリティカルなら別だが、市場に出して価値が出るまでQAは出さない。
- QAチームが開発チームに「お金出せるの？」と聞いている
- 業務外でやるか、お金を出してもらう
QAの未来これから取り組みたい課題
柿崎
- モンスターストライク海外版の立ち上げの組織作りをやっている
- まだ、大規模ウォーターフォールモデルの状態になっている
- 教訓：ちゃんとプロダクトに集中しよう
- テストは一つの手段でしかない
- モンスターストライクのQAチームはちゃんとテストをやるのではなく、ちゃんと海外に受け入れられてもらうようにすることが目的
藤澤
- 追求すべき品質の種類を知る（狩野モデル）
- 開発のサイクルタイムを追求する
- QAはユーザよりも先に、まず最初に問題に気づける立場
- 累積フロー図を示して、改善していく
松尾
- 拡大と分散が課題
- 組織/人員/国内外
- サービス
- アーキテクチャ
- これらを踏まえたテストとは
- アーキテクチャの例としてmicroservicesがある。
- 部分的に不具合が発生した時の特定が難しくなる
- 部分的にテストが上手く行っても、全体的にテストが上手く行かなかった時の対処が難しい
山本
- ウェブやゲームの領域でも品質保証を魅力的な職種として確立したい
- アルバイトを雇って、ゲームで壁にガンガンぶつかるテストをしている状態を無くしたい
- 開発側はDBに詳しい人、オープンソースに詳しい人がいるように、QAでもスターが出てきてほしい
質問
現実は怒涛のような業務量に追われると思う。そういうことはあるのか（柿崎）
藤澤
- 「大変ですよね。」
- 全てのプロダクトでプロセスがうまく回っているわけではない。
- 品質管理グループに求められる要望がすごく多い。
- テストだけではない。
- どこも対処できないことが最終的に回ってくることがある
松尾
- あります
- 仲間が増えてほしい。
- モバイルアプリ以外にも組織も見ている。
- WEB側も見れるようにしてほしい。
- 辛いですが、前を向いて歩きたい
山本
- 月初（課金制御解除のタイミング）はお祭りになる。
- 普通に辛いです。
テストエンジニアの採用に難しさを感じていますか？また、探し方のコツなどがあれば教えて下さい（藤澤）
柿崎
- 難しいです。
- 自分も困っていました。
- 給料積めば来るかも。
- テストエンジニアの需要がすごい高いかも。
松尾
- 気が合う同い年ぐらいのテストエンジニアがほしい
山本
- アメリカの方が職種が細かいのでつかまりやすい
- 社内のエンジニアのコンバートの方が速いかも
- マニュアルでテストをやっていた人は難しいかも
- 「品質って素敵だよね」と訴えている
会場にアンケート
会場からの意見
組み込みからWEBへ転職した身としては、WEBのテストがあることすら知らない
