中野氏（モデレータ）：今日のパネリストの方々は現場でテストをリードしている方々です。その現場で取り組んでいる内容や品質管理について、過去、現在、未来を議論していただければと思います。まずは現在の組織やプロセスについて、ご紹介ください。

ミクシィはウォーターフォールで開発していた

柿崎氏（ミクシィ）：ミクシィのサービスはSNSmixiだけではなくて、最近は「モンスターストライク」などのスマホゲームや、ビューティーアプリ「ミニモ」、「FindJob」など、いろんなサービスを提供しています。これらのサービスに合わせてテスト戦略や体制を都度作っていくのが重要になっています。

　ここでは、SNSの「mixi」のQA組織がどう変異したかを説明します。

　もともとmixiのQA組織はカスタマサポートから端を発していまして、昔のmixiは週末に落ちてたりすることがあったのですが、それは負荷の問題だけでなく、テストせずに新機能をリリースするといった体制にも原因がありました。それでカスタマサポートへの問い合わせも多くなっていったので、カスタマサポートからQA組織が分化して、mixiの成長に合わせてQAの人数も増えていったと。これがだいたい5～6年前の体制です。

　当時は企画と開発とデザインとQAが分かれていて、大型のウォーターフォールで開発されていました。

　しかし大規模になると開発スピードが落ちてきてしまい、当時のCTOがチームを分けてスクラム開発に切り替えました。そのチームごとにQA担当を入れていたのが3～4年前の状況です。

　しかしその後、すべてのチームにQA担当を置くのはやめました。人数が増えてコストが掛かってしまうためです。このときに怪我の功名というか、各チームのQAがいなくなったことで、それぞれのチームが自分たちでテストするということに開発者やディレクタが目覚めたと。いつまでもQA担当がいてくれるわけじゃないんだということで、各スクラムチームでテストする気持ちが芽生えた感じです。

　いまの状況ですが、例えば課金が絡むような重要なフェーズにはQA担当を配置してテストサイクルを回しています。

　なのでmixiにはいま、チームとしてQAチームが存在しているわけではありません。複数存在するスクラムチームの一部にQAの役割を持つメンバーがいる。

　現在のmixiの企画開発は、ちゃんとユーザーの声を聞きながら小さい開発を進めて改善していこうという意識が強くなっています。それを裏付けるために、一部のユーザーだけに新機能を見せるといった仕組みもあり、バグがあっても影響を小さくし、すぐに修正できるようになっています。

　自分の役割は、サービスごとにQAチームを立ち上げたり縮小したり、テストプロセスも変わるのでそういうのをスタッフに促したり、といったものです。

開発のキックオフからQAが入るネクスト

藤澤氏（ネクスト）：私の会社は「HOME'S」という不動産・住宅情報サイトを運営しています。サービスの内容としては、物件情報を住まいを探している方々に提供するもので、物件数が現在530万件を超え、国内最多となっています。ビジネスモデルはBtoBtoCで、不動産会社に入稿いただいた情報を検索できるようにして、お客様から問い合わせがあったときに課金するというもの。

　開発体制は小さくてクロスファンクショナルな体制です。HOME'Sの企画開発系スタッフは200～300人いて、QAチームはその外側にいるかたちです。開発スタイルは、いわゆる反復型。スクラムかというと、もうちょっとかちっとしています。

　通常は企画、開発、テストまでは開発チームが行っています。QAはリスクに応じて入りますが、入り方としては、キックオフ、チェックリスト、最後にQAテストですね。


　キックオフミーティングでは開発とQAでの情報交換とか、QAテストの有無も検討します。 チェックリストは開発や運用のためのチェックリスト。QAテストはリスクに応じてテストをしますが、網羅的または探索的なテストでバグをつぶしていきます。


　当社はビジョンを大事にする会社で、QAチームにもビジョンがあります。それは「より良い物作りの仕組みを作ることで、挑戦する人々を守り立てる」というものです。そしてミッションとして品質保証、テスト自動化、プロセス改善があります。

【次ページ】 ロールバックに力を入れることで効率を上げているクックパッド