「実はDeployGateを一番活用しているのは、エンジニアではなくデザイナーなんですよ」

― まずはじめに、加藤様のご担当されている業務と、ご経歴を教えてください。

クックパッドのモバイル基盤グループでエンジニアとして働いています。 主な仕事は、弊社のアプリ開発者向けの基盤の開発や運用で、その一環として社内のCI(Continuous Integration)を管理する、いわゆる「Jenkinsおじさん」を担当しています。 卒業後、新卒としてSI企業に入社し、Androidの開発を担当するようになりました。 その後転職し、大手Web企業でのAndroidエンジニアとしての経験を経た上で、クックパッドの「ユーザーファースト」という考え方に共感して弊社に入社しました。 クックパッドはエンジニアの技術力が高いということにも興味を持ちました。 当初はAndroidエンジニアとして入社しましたが、必要があればiOSのレビューなどを担当することもあります。

― 御社ではDeployGate Enterpriseをご利用頂いているとお聞きしました。

DeployGateは2013年のリリース当初からアプリ開発に利用させてもらっています。 アプリ開発者としてSlackのチャンネルに参加しているのは、エンジニアやデザイナーなど含めて50名程度くらいです。コードを実際に書いて開発しているエンジニアは、AndroidとiOSがそれぞれ10名程度といったところでしょうか。 DeployGateを利用している人数は、エンジニアやディレクター、デザイナー以外にも、マネジメント層の人間なども積極的に利用していますので、総勢で80名程度になります。

― DeployGateをどのようにご利用いただいていますか？

実は弊社でDeployGateを一番活用しているのは、エンジニアではなくデザイナーなんです。Web開発と違い、デザイナーはアプリが実際にビルドされるまでは、実機上での仕上がりを確認することができません。自分がデザインしたアプリが意図したとおりに実装されているか？また、UXやアニメーションの動きは適切か？などを、DeployGateで配信される開発中のバイナリを元に逐一確認しています。 やはりデザイナーが手元でソースからバイナリをビルドするのはハードルが高いですからね。 実機で確認すると、実装上の都合で印象が変わることも多々あります。確認した上で「表示もう少し左にずらそう」みたいな微調整が入ることもあり、DeployGateを使ったスムーズなアプリ配信が役に立っているなと感じています。

JenkinsからDeployGateへの配信を完全自動化。
テストのサイズを3段階に定義し、日々の開発をより高速に。

― 業務上の開発フローにDeployGateはどのように組み込まれていますか？

弊社ではGithubを活用していますが、プロジェクトごとにプルリクエストを作成し、Masterにマージする運用になっています。その運用を支えるのが「Dokumi」というコードレビュー＆CI支援ツールで、GithubへのPush時に自動的にコードの静的解析や、Jenkinsによるテスト＆ビルドを行った上で、DeployGateへのアップロードまで全て自動で行ってくれます。 複数のプロジェクトが同時に走る場合は、DeployGateの過去バージョンの履歴機能を活用しています。DeployGateへのアップロード時に生成されるリビジョン番号を、Dokumiがプルリクエストにコメントとして付与してくれるので、テストする場合はそのリビジョン番号を元に、当該のバイナリを呼び出してインストールしています。

― クックパッドにおける自動テストや、社内でのベータテストについて教えてください

全てのテストを人で行っていると時間がかかってしまうので、弊社ではテストを「S」「M」「L」の３つのサイズに分けて行っています。簡易な修正レベルのものであれば速度重視で「S」サイズとなり、この場合はユニットテストのみを行います。 テストは１回５分程度なので、これがガンガン回っているというイメージです。リリース候補のブランチなどに変更が入る場合は「M」サイズとなり、「S」の内容に加えて、エミュレータを立ち上げて行うInstrumented Unit Testsというものを行います。 基本的にCIから実行されるテストはMサイズまでで、リリース候補のブランチをMasterにマージする前には、「L」サイズと呼ばれるエンドツーエンドテストを行います。 約1週間ほどの期間をかけてQAチェックなどを行い、リリース前の最終テストを実施します。 詳しくは、クックパッドの開発者ブログで「Android/iOSアプリのテストの区分戦略」記事を執筆しておりますので、ぜひ参考にして見てください！

また、フローとしてのテストとは別に「確認会」と呼ばれる新機能の社内向けお試し会のようなイベントを行っています。そこでは開発者が作ったベータ版のアプリをDeployGateの「配布ページ機能」を使って集まった人に配り、機能の確認や意見の交換を行ったりしています。

エンジニアが本来の仕事に集中できる環境を作り、
結果としてのプロダクトの質を向上させたい。

― DeployGateで気に入っている部分があればおしえてください

やはり、実際の端末での動作を、誰でも簡単に、すぐ確認してもらえるというのが良いですね。 先ほどの確認会でアプリを配る場合でも、エンジニアがひとりひとりにUSBケーブルでアプリをインストールして廻るような「心を込めた手作業(笑)」が無くなるのはとても良いです。エンジニアが本来のエンジニアリングだけに集中できるというのが、いちばん価値があるように思います。 また、問題が起きたときに古いバージョンにいつでも手元で戻せる履歴機能も重宝しています。 地味なTipsですが、DeployGateのリビジョンごとのコメントにGitのハッシュを付けておくと、何か問題があった時に、過去のバージョンをサクッと呼び出してインストールすることができるので、どういう状況が発生していたのかすぐに調べることができます。これ、意外と便利なんですよ！

― 今後のDeployGateに期待するものがあれば教えてください

弊社では「DeployGateなしでは業務が回らない！」という所まできているので、実は社内に「DeployGateさんへの要望を募るIssue」みたいなのがあるんです（笑） いちばん要望として強いのは、リビジョンごとにパーマリンクが発行できる機能ですね。先ほどの通り、複数のプロジェクトが同時で走る場合には、現状では過去のバージョン履歴から、手動で必要なバイナリを呼び出さなくてはなりません。もしAPI経由のアップロード時にパーマリンクが発行できれば、Dokumiと連携してよりスムーズな運用を実現できます。もしくは、アップロードごとにタグのようなものが付けられる機能でもいいかもしれません。

― 加藤様が開発において大切にしていきたい姿勢や、考えなどがあれば教えてください。

やはり「ユーザーファースト」という言葉に尽きます。「ユーザー」という言葉の意味は、クックパッドをご利用頂いている利用者の皆様はもちろんの事なのですが、私の場合は社内の開発者向けの基盤の開発や運用を行っているので、社内のエンジニアの人々も私にとっての大切な「ユーザー」の一部です。私の場合は基盤業務が好きで、クックパッドにも「基盤をやりたい！」という事で入社しました。エンジニアが、本来のエンジニアリングだけに集中できるような環境を作ることで、結果として生み出されるプロダクトの質が向上し、最終的にサービスを利用して頂いている方々へ価値を届けることができると思っています。そこに近づけるように、頑張っていきたいなと思っています。

― ありがとうございました。