クックパッド、ミクシィ、グリー、ネクストの品質管理マネージャが本音で語る。ソフトウェアテストの課題とこれからの可能性（前編）。JaSST'15 Tokyo

2015年3月16日

ソフトウェアテスト分野で国内最大のシンポジウム「JaSST'15 Tokyo」が2月20日、21日の2日間、東洋大学で開催されました。

そこで行われたセッションの1つ「Web.JaSST ～ウェブ開発のテスト～」」では、ミクシィ、ネクスト、クックパッド、グリーの品質管理（QA：Quality Assuarance）マネージャが登壇し、Web開発やモバイル開発分野の品質やテストにおいて、これまで乗り越えてきた課題、現状、そしてこれからの可能性について語りました。

本記事ではその内容をダイジェストで紹介します。

左から、ミクシィ柿崎憲氏、ネクスト藤澤正通氏、クックパッド松尾和昭氏、グリー山本健氏。モデレータはネクストの中野直樹氏

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

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

柿崎氏（ミクシィ）　ミクシィのサービスは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チームにもビジョンがあります。それは「より良い物作りの仕組みを作ることで、挑戦する人々を守り立てる」というものです。そしてミッションとして品質保証、テスト自動化、プロセス改善があります。

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

松尾氏（クックパッド）　「Cookpad」はレシピをWebで共有したり閲覧したり、最近では特売情報などの提供サービスなどもあります。また、Webだけではなくモバイルのネイティブアプリにも力を入れ始めました。

クックパッドの開発体制は、サービスごとにそれぞれ独立した部署があって、それとは別に基盤的なことを運用する横断的な部署があってサービスを作り上げています。

縦の部署は自分たちに合った開発スタイルをそれぞれが採用していて、横の部署は助言や技術的な提供やヘルプで入る、といったことをします。私が属しているのはこの技術基盤のところです。

これはWebのパイプラインです。いちばん左がデベロップメント、いちばん右がプロダクション。プロダクションの手前にプロダクションテストがあって、そこで開発者が目で見て確認をするというのはありますが、QA期間を設けたトラディショナルな開発はしていません。

というのも、QAでテストをする理由とは、リリースされたものがユーザーの体験を損なったり会社に悪影響を与える、というリスクを下げるためです。では、このユーザー体験を損なったりする期間が1秒、2秒というような短い期間だったらどうでしょう。損なう期間が非常に短く保てるのであれば、QA期間を設けるより効率のよい開発できるのではないか、という考えがあります。

そこで私たちはロールバックに力を入れていて、ものの数分でデプロイしたものをロールバックできるようにしています。相当量の自動回帰テストを通したうえでデプロイして、万が一だめだったらロールバックするという形で運用しています。なので、がっつりしたQA期間は設けないスタイルで開発をしています。

ここでQAチームがどう関わっているかというと、組織的には改善があったら全社で共有するという活動なんかをしていて、それをFailure Teaches Successというのですが、障害をまとめて共有することや、KPTを回す体制を支援します。私はいまモバイルのテストに関わっていますが、そのときに開発者から相談を受けたり手動テストや自動テストの促進などをして手を動かすこともしています。

高品質な製品作りを支援するグリーのテストチーム

山本氏（グリー）　グリーはゲームを出している会社として有名ですが、ほかにもベビーシッターをWebで予約したりホテルを予約できるサイトなど、多岐にわたっているので、それに合わせてQAも進めています。

Quality Assuarance部があって70名くらい在籍しています。その中に大きく4つのチームがあって、僕が所属しているのはTest Engineering Teamです。僕のチームは一般的に、テストの自動化やエンジニアリングの導入、コストを下げてリソースを再配分して高品質なテストを実現していく、といったことをしています。

QAチームが乗り越えてきた課題とは？

中野氏（モデレータ）　みなさんに現状の紹介をしていただきましたが、こうなるまでにどんな課題を乗り越えてきたのか、それを教えていただきます。

柿崎氏（ミクシィ）　組織を何度も変化させてきたのですが、それはその都度の課題があったためです。大規模ウォーターフォールをやっていたときは、いわゆる大企業病的な状況もあって、QAはとにかく優れたテストができればいい、バグがたくさん見つかればいい、というような。プロダクトに集中できていない状況でした。

それで複数のチームに分化したわけですが、こんどは体制の問題ではなくコストの課題がでてきて、QAに潤沢にリソースを振り分けられなくなると。

そこでいまはチームごとに、QA担当がいないチームでも自分たちでテストするんだという意識のもとにやっているので、いまはmixiの開発体制は良好な状態だと思います。課題と言えば、スクラムマスターが足りない、という感じですね。

藤澤氏（ネクスト）　過去にあった課題の1つはリソースの問題で、QAチーム発足当時の人数は2人と、開発チームに比べて圧倒的に少なかった。これではテストの対応のしようがなかったので、何をしたかというと過去の障害パターンを把握することと、障害が起きたらとにかく情報を教えてくださいと言いました。

これによって障害の情報が最初に入ってきますし、するとその後の分析もしやすくなります。そうして障害のパターンをちゃんと把握する、ということをしました。

それから当時はデグレードが一定の割合で発生していたので回帰テストをちゃんと自動化しよう、ということもやりました。

うちの開発チームはテストは自分たちでやるもんだと思っていますが、とはいえ自分で作ったものなので、バグが出ると怖いものや重要なところにはQAチームが参加しますと。

こういうことで品質が高まってきたかなと。

それからそもそもテストじゃなくてその前の段階で検知したいよね、ということでキックオフの時点でQAチームが参加することや、チェックリストなども作りました。

障害ってアプリケーション以外にインフラ系にもあるので、これですべての品質に対応できたわけではないですが、でも多くの課題に対応してきたかなと思います。

≫後編に続きます。後編では、QAの未来と、各社がこれから取り組みたい課題などについて議論します。