テストや開発環境における自動化に関して議論したICST2017 unofficial meetup

技術部品質向上グループの松尾(@Kazu_cocoa)です。

2017年3月13日〜2017年3月17日の間に、東京にてICST2017という国際学会が開かれました。 その学会に基調講演としてGoogleの方などが来日しました。そのさい、非公式ながらミートアップを開いたのでその時の学びを共有したいと思います。

ICST2017とは

ICST2017とは、2017年に開催された第10回 IEEE International Conference on Software Testing, Verification and Validationの略です。Webサイトはこちら。 そこではソフトウェアテストや開発環境、品質に関する研究や事例が発表され、議論されました。 今年は10周年である上に、この会が始まって以来、初めて日本で開催されたようです。

学会と聞くと学術的すぎると思うかもしれませんが、比較的実務に近い話や産業界で実際に活動している人も参加者に多かったです。 例えば、会の中にありましたパーティーでは、様々な国の産業界で働いている多くの方と会話することもできました。

ミートアップ開催のきっかけ

このICST2017のkeynote speakerの1人としてGoogleからJohn Miccoさんが登壇しました。 とあるご縁から彼と直接やりとりを行うきっかけを作ることができたので、ICST2017に絡めてその日程付近で彼や彼の同僚の人とmeetupを開けないか誘ってみました。 好感触の返事をもらえたので、国内のテスト、品質、CI/CD周りに従事している幾人かの知人に声をかけ、今回のmeetupを開きました。

ゲストや知人のほか、一般参加者も募るため、以下の通りmeetup.comにも募集を開き少数ではありますが参加者を募りました。 基本的には英語による議論になるため、募集はmeetup.comに絞りました。

https://www.meetup.com/Tokyo-Software-Test-Quality-Meetup/events/238376025/

開催にあたり

実際に声をかけて発表者を募り、最終的に以下の人たちに話してもらいました。

  • Cookpad
  • DeNA
  • Mercari
  • Rakuten

スライドは一番下に参考資料として添付しています。

また、ICSTのために日本に来日している人もいましたので、日本料理も幾つか楽しんでもらうことができるよう、寿司(板前さん付き)や日本酒も用意しました。フードスポンサーとして以下の企業様方に協賛していただきました。

f:id:kazucocoa:20170404135813p:plain

meetupの前に

スケジュールの都合上、イベント前に時間の余裕があったのでJohnさんにクックパッドオフィスを案内しました。 途中からBaoさん(Johnさんの同僚の方で、ICST2017ではパネルディスカッションのセッションで登壇された)も加わり、3人でオフィスを回りました。

そこの中で、ビルド環境としてのBazelの話や、翻訳タスクのGoogleの現状の話、クックパッドの海外事業部の取り組みの話を主にしました。

また、弊社における日本/海外事業部における現在ある開発環境や取り組みの差などの話もしました。 例えばGoogleが1つのリポジトリで全て管理していることに対して、クックパッドではチーム/事業部など単位はありますが様々なリポジトリが独立して存在していることに触れることもありました。 それに対してJohnさんは複数チーム、事業部などでコードを共有したりしないのか？というような疑問を投げかけてきました。 クックパッドの文脈では、現状は海外事業部と国内を主とする事業部でサービスの長さに差があり、現状はこうなっているというような話、モバイルアプリといったところではライブラリを共通化していきたいと言った話もでている、と言った時代的な背景などを共有しながら、リポジトリ管理に関して意見を交わしたりしました。

meetupにおいて

実際のmeetupでは、先ほど挙げた4社のスライドを約10~15分間隔で発表しながら、聴講者が適宜質問を行ったり議論したりしながら進行しました。 中には、Johnさんが発表者にかわって回答する場面もあり、白熱した議論が展開されました。

幾つかのスライドの中で共通に存在していた課題は、やはりどうスケールするか、でした。 つまり、組織やサービス、関わる人といった様々な要素の規模が大きくなるにつれて問題になる、分断された環境や情報をどう共有し、集約していくかという問題でした。

この場にいた人の多くは実際にソフトウェアエンジニアとしてテスト、開発環境、様々な自動化にとりくんでいる人たちです。 そのため、ある程度の知識をあらかじめ保有している状態で議論ができたことも大きいのかもしれません。

meetupを終え、その先へ

GTAC2017

今回の発表の中には、GTAC2017へ是非とも応募してほしい！というものもありました。 GTACとは、Google Test Automation Conferenceの略で、2006年から毎年行われ続けている歴史のある自動化カンファレンスです。 今年はおそらくロンドンであるそうです。

参加者にも是非とも参加しなよ！とあったので、興味のある人はまずは応募してみてはいかがでしょうか！？（現地に行くことができるかは抽選です）

ICST2018

最後に、忘れてはダメなものとしてICST2018があります。 次回はスウェーデンのようです。 是非とも産業分野、学術分野で応募して採択、もしくは一般参加者として参加して自動化周りの先を見てみませんか？

最後に

今回、幾つかのご縁が重なりこのように濃いmeetupを開くことができました。 ご協力いただいた方々、本当にありがとうございました。

英語を主体としてソフトウェアテストやその周辺のことを対面で議論できる場所は日本ではおそらく少なく、そのためこのような場所が参加者、または参加者の所属する企業などへ広がると幸いです。

資料(発表順)

Cookpad

DeNA

Mercari

Rakuten

Consumer-Driven Contract testing in Cookpad

こんにちは、技術部の taiki45 です。3月17日に ICST 2017 の参加者などを招いたミートアップがあり、そこでクックパッドの開発とテストへの取り組みについてお話をしました。この記事では資料とセッション中に行われた質疑応答を元に、発表についての補足をしたいと思います。このミートアップについては、後日開催報告記事が出る予定です。

今回はクックパッドをご存知ない方に向けて、クックパッドでのテスト領域での取り組みについて紹介しました。そのため、前半部分では後半への橋渡しとして、クックパッドがどういうことに取り組んでいるか、またクックパッドでのソフトウェア開発の規模や様子について俯瞰した視点でお話しました。

特に今回の話では、分散型アーキテクチャを選択した際に起きる問題が主題だったので、チーム構成とシステム構成の面を説明しました。具体的には、事業領域に沿ってチームが分割されていること、システムもチームの分割に沿うように分けられていて、システム同士が協調して動作する構成になっています。

プロダクトの規模について紹介をしている場面で、月次利用者数とともに “プロダクトとしての Cookpad” だけでのテストケース数をお話した際には、「そのケース数は自動テストのみを数えているのか？」「自動テストのみです」といったテストエンジニアの集まりらしいやりとりをしました。また、その数のテストケースを実行している仕組みについて質問があったので、分散テスト実行システムである RRRSpec について説明をはさみました。

「ビルドとリリース」については、コードレビュー後のマージによって自動テストジョブがキックされ、その後の Docker イメージのビルド、開発環境サーバーへのデプロイ、本番環境同等のカナリアサーバーへのデプロイが自動で行われています。カナリアサーバーへのデプロイ後は、カナリアサーバーに対してスモークテストが自動で実行され、さらに必要に応じて開発者による動作確認が行われます。本番環境へのデプロイは細かい粒度で行われています。リリース対象の機能やバグ修正に責任を持つ開発者が明確になっているので、開発者の責任でデプロイ後の動作確認をしています。問題があれば開発者がロールバックを行います。

テストに関する取り組みについては、「実践 Pact:マイクロサービス時代のテストツール」で紹介したことと同じく、Consumer-Driven Contract testing パターンを適用したことについて紹介しました。Pact の仕組みについては特にデータセットアップに関する質問が多く、質疑応答や後の懇親会等で「本番環境は使用せずテスト環境で Provider 側のテストを実行すること」や「"Provider States" という仕組みでデータセットアップ処理に名前をつけて Provider 側でテスト時にデータを用意すること」を補足しました。

モバイルアプリ開発における思いと工夫

こんにちは、技術部品質向上グループの茂呂一子(@)です。

3月18日にProductivity Engineering − Forkwell Meetup #4において、「クックパッドにおけるモバイルアプリ開発の工夫」というタイトルで発表しました。その内容を補完しつつ、最近のモバイルアプリ開発の取り組みについて紹介します。 (発表資料はこちら)

開発体制とスケジュール

クックパッドでは、Web/モバイルアプリなどのプラットフォームに依らず、機能ごとにチームを組んで開発を行っています。 例えば、検索機能、投稿機能といったサービス内の機能ごとにチームがあり、その中にデザイナーとエンジニアが所属しています。

モバイルアプリの開発という視点から見たときには、機能ごとのチームを横断し、より基盤的な業務を担うメンバーを含めて、iOS/Androidのモバイルアプリの開発を目的とするコミュニティがあります。(会社の組織編成と対応しない枠のため、ここではコミュニティと呼びます。) このコミュニティには、機能ごとのチームからディレクター、デザイナー、エンジニアが参加します。 ほかにも基盤的な業務を担うメンバーとして、モバイル基盤グループと品質向上グループのメンバーも参加しています。

アプリのリリースは、通常2週間から1ヶ月に1回行っています。リリーススケジュールを調整することはあるものの、スケジュールにあわせて機能を入れるかどうかを決める方法をとっています。 リリースに関わるエンジニアは、Android/iOSのリリースでそれぞれ10人程度です。

サービス開発で大切にしていること

私たちが開発で大切にしていることを、サービスを提供する立場と、ユーザー体験の2つの面から述べます。

まず、サービスを提供する立場からの視点です。

私たちのサービスでは、「毎日の料理を楽しみにする」ことに貢献するかどうかを重視します。 そのために「○○によって、毎日の料理が楽しみになる」といった仮説をたて、その正しさを明らかにする必要があります。 仮説は、サービスの変更や機能追加を含む施策として実装されます。 ユーザーさんに使われる様子をデータなどから検証することで、その施策に効果があったのか/なかったのかを明かにし、ひいては仮説の正しさを明らかにします。

施策の効果を計測するには、それが仮説どおりに実装されている前提で、その効果を計測します。 そもそも仮説どおりに実装されていなければ、効果の計測に意味がありません。 仮説どおりに実装されたときでも、例えば、実装された機能に到達できないことがあれば効果を計測できません。アプリの外側で、APIサーバーに問題があるなどして機能を提供できなければ、これもまた計測ができません。

したがって、施策を仮説どおりに実装していること、その効果を計測できる状態を維持することが大切になります。

次に、ユーザー体験の面から見てみましょう。

クックパッドはコミュニティサービスなので、ユーザーが離れていってしまうことはサービスにとっての損失になります。ユーザーが離れていってしまう体験とはどんなものでしょうか。 ユーザーにとって残念な体験が続くと、離れていってしまうことが考えられます。 例えば、操作性を損ってしまうクラッシュの問題があります。 他にも、施策の意図にないが、これまでできていた(当たり前になっていた)ことができなくなった。画面ごとにいろいろな操作があって、覚えづらく、操作に慣れることができない。といったことにも、私たちは注意しています。これらは、ご意見やレビューといったユーザーの反応をもとに、施策として意図しないネガティブな反応が増えることを「ユーザーにとって残念」と捉えているためです。

このようなことから、私たちは、体験の一貫性というものを大切にしています。

リリースフローにあわせたチェックポイント

私たちのモバイルアプリ開発ではリリースフローを定めて運用しています。 このリリースフローを、必要に応じて変更しながら運用しています。現在は、以前の記事では触れていなかった、チェックポイントとなるイベントをいくつか置いています。

今回は、リリースフローに定めたイベントの中から、2つを紹介します。 先に述べた開発において大切にしていることを損なわないための、キックオフと確認会です。

キックオフ

キックオフは情報共有の場としてはじまりました。

以前は、毎日、始業後に10分程度の時間をとって、その日のタスクを共有していました。 顔をあわせ、タスクを共有し、開発の状況を把握するための会です。これを朝会と呼んでいました。 しかし、朝会参加者が増えてきたことと、全社的なフルフレックスへの移行に伴って時間をあわせるコストが増したことから、チャットツールであるSlack上で行うようになりました。

朝会チャットは、専用のチャンネル(部屋)を用意し、毎日、各自のタスクを書き込む形式をとっています。 チャットというツールの性質上、非同期に行われます。そのため、議論に発展した場合も朝会自体の流れを阻害しないというメリットがあります。 一方で、目的が「今日のタスクを共有する」というところに絞られる傾向があり、大元の施策のはなしや、ちょっと未来のはなしといった関連情報を共有することが減ってきました。また、非同期であるがゆえに、他者の書き込みへの関心が薄れやすい傾向にあるようです。 他にも、顔をあわせることで得ていた、顔色や声色から調子の悪さを知る、ということがむつかしくなりました。

全体的に他チームの施策への関心が薄くなった結果、ひとつの問題が発生しました。

ひとつの画面に、異なるチームから複数の施策が実装されました。その結果、同時に表示されたことにより表示がくずれ、効果の計測ができない状態になってしまったのです。

情報の共有ができていなかった、実装前にこの事例のような競合は把握したい、という反省のもと、キックオフがはじまりました。

キックオフは、そのリリースに関係するディレクター、デザイナー、エンジニアすべて(最近では20人程度)が参加します。(参加は任意なので、毎回全員が参加するわけではありません。)

画面や操作に大きな変更がある施策を共有し、必要であればその調整を行います。すべての変更を共有するのではなく、大きな変更があるものを選んで共有を行っています。

施策を共有し、事前調整をすることで、先のような失敗は起きなくなりました。 また、実装前に他チームの施策を知ることで、それへの懸念を伝える機会となっています。仕様の未定義が見つかることもあり、うまく機能しているといえるでしょう。

確認会

確認会は、そのリリースに関わるディレクター、デザイナー、エンジニアすべてが参加します。 すべての変更をマージしたアプリをインストールし、変更内容を確認しながら操作します。

ここでは、全体の一貫性が保たれているか、意図どおりに実装できているかを確認します。 いわゆるリグレッションテストとは違い、過去の実装範囲への影響よりは、新たに実装したものに注目して確認を行います。

確認回は、ユーザーインターフェース(以下UI)とユーザーエクスペリエンス(以下UX)の一貫性を保ちたい、という要求からはじまりました。これは、各チームが独立して施策を実装するので、アプリ全体をみたときにUI/UXの一貫性を失いやすいためです。

あわせて、確認回では、検証端末を持ち寄り、開発中より多くの種類の端末で操作を行うようにしています。これは、開発中に動作を確認する端末が偏りやすいことから、端末依存の問題の検出を目的にしています。

これらの取り組みにより、UI/UXのばらつき、特定端末での問題といったものが見つけやすくなりました。 また、開発中には気づかなかった違和感を見つけることもあります。 見つかった問題は、重要度に応じて修正を行います。ものによっては、次のリリースで対応する場合もあります。

確認会を設定した目的は達成されつつありますが、それだけで開発がうまくいくわけではありません。

例えば、特定の種類のユーザーでしか起きない問題が、確認会以降で見つかるという問題があります。 実はクックパッドのユーザーは状態の種類が多く、無料ユーザー/課金ユーザーというわかりやすい物の他にもいくつか存在します。これらはサーバー側でユーザーを用意するだけでは、網羅することがむつかしく、状態の変化も含めて確認すべきバリエーションが多いという状態です。 状態の掛け合わせで起きるような問題ではない、特定条件のユーザーを模倣すると比較的簡単に見つけることができる問題なので、もっと早く見つけられるようになりたいと思っています。

まとめ

モバイルアプリ開発をうまく回すための、私たちの工夫の一部として、キックオフと確認会について紹介しました。

クックパッドではこのような取り組みを共に実施し、より良いサービスを提供し続ける為にエンジニアを募集しています。ご興味のある方は、是非とも覗いてみてください。