開発中の実装も、レビュー前からプロダクションに入れています。
DeployGateはドッグフーディングに最適ですね！

― はじめに、Drivemodeの概要と、現在の状況について教えてください。

Drivemodeは車のドライバー向けのアプリで、運転中でもスマートフォンの操作をより安全に、より簡単に行うことができるようなUIを提供しています。 ドライバーは前を向いて運転に集中したまま、安全にナビゲーションや音楽再生などの操作を行うことができます。 また、Drivemodeは独自のUIだけではなく、様々なアプリや情報、モノと連携できるのも特徴です。 今後はバックカメラや、ハンドルから手を離さずに操作できる様々なコントローラ、HUD(ヘッド・アップ・ディスプレイ)などとの連携も視野に入れて開発を進めています。

現在、一般公開してから1年と少しですが、ダウンロード数は100万を突破、利用国数も180カ国を超えました。 特に利用者が多いのはアメリカとインドで、その他にも熱狂的に使われている地域が幾つかあります。 最近ではイタリアやスペインでの利用も目立ってきました。20ヶ国語に対応しており、現在も多言語化に力を入れています。 実は翻訳なども私達が行うのではなく、世界中にいる実際のDrivemodeユーザの方々にお願いしています。 新しい言語に対応してほしい、という要望が来るので「じゃあ協力をお願いします！」という感じで（笑）

― 現在の開発体制や、Joãoさんが実際にDrivemodeの開発に携わるようになった経歴を教えてください。

開発チームのエンジニアは現在5名です。それにデザイナーが1名、プロダクトマネージャが1名といった構成です。 CEOを合わせた全社員でも10名に満たないスモールチームです。 全員Androidエンジニアですが、サーバサイドの開発や、Androidの中でも低レイヤの実装を行う必要があるので、フルスタックというかジェネラリストが多いですね。

クライアントサイドの開発は主にJavaで、retrolambdaを入れて”読みやすいJava”を心がけています。サーバサイドはScalaで、一部の機能はGoで実装されています。 ソースコードはGithubで管理し、CIはwerckerを使っています。 werckerのいいところは、サービス内で自分のDockerコンテナを定義することができ、ビルドの条件や設定をステップという単位に分解して、それをつなぎ合わせた「ビルドフロー」を作ることができるという点です。何かしらのトリガーが発生したときに、条件にあわせてビルド内容を切り替えたり、つなぎ合わせたりする事がとても容易です。

私がDrivemodeに感じている魅力は、何より作っているプロダクトが、ドライバーの日常生活を確実に向上させているなという実感があることと、グローバルで優秀なチームです。 米国拠点のスタートアップなので、頻繁にシリコンバレーと日本を行ったり来たりしているのですが、これもエンジニアにとっては良い刺激になりますね！ 弊社での社内コミュニケーションも、すべて英語です。 その他、もともと個人的に車が好きという事もありますし、アプリの性質上、かなりAndroidの深い部分をハックしなければいけないので、ハッカー魂がくすぐられるという点も魅力的でした。

全てのコミットを自動ビルドで全社員に配布。
CEOが勝手にアプリの表示を書き換えちゃう事も？！

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

開発初期のプロトタイプ時代から使っています。CIは色々変わりましたけど、DeployGateは変わらず使い続けていますね。 GitのコミットごとにCIでビルドが自動的に走り、ビルドが成功したらDeployGateを通して最新版がチーム全員に配信されます。 多い時は1日20回くらい最新版が配信されていますよ。

最近はGitを使わなくてもGithub上からコードを直接修正できたりするので、日本の開発チームが寝てる間にCEOが勝手にアプリの文言を書き換えて、最新版をDeployGate経由でインストールしてニヤニヤしてるなんて事もよくあります。 目が覚めたら見たことない文言にアプリが書き換えられていたこともありますね。たまに修正に失敗して派手にコードを破壊してくれますけど！（苦笑）
ともあれ、CIとDeployGateを組み合わせればエンジニアじゃなくてもAndroidアプリを修正してビルドできる環境を実現できるということです。これは本当に凄い。

機能や改善が気になるのか、昼夜を問わずバイナリをアップデートしているログが上がってきます。 弊社の場合は拠点が米国と日本にあるので、コミュニケーションにどうしても時差が生じてしまうのですが、 日本の夜中にアメリカのメンバーの起動ログが届いたりするので「あ、みんな今働いてるんだな」って感じたり、逆に、アメリカのメンバーにしてみれば 夜中に最新版の通知が届くので「あ、日本の開発メンバーちゃんと生きてるな」みたいな死活監視のように機能しているらしいです（笑） スタートアップならではの速度というか濃密さという感じですが、良いコミュニケーションになっています。

開発ブランチは1つのみ！
機能はすべて「アクティベーション・フラグ」で出し分ける。

― ワーキングブランチの運用はどのようになっていますか？

実は弊社では開発ブランチを1つにして、各人のワーキングブランチを作るのをやめました（笑） レビュー前の実装も含めて、すべて基本的には1つのデベロップメント・ブランチで管理しています。 最初はGithub Flowに則った開発をしていた時期もあったのですが「もっと速度がほしいよね」という事で今みたいな形になりました。 1つのブランチがどんどん更新されていくので、それがエンジニア間で良い刺激になり、開発が加速している印象です。
開発フローがシンプルになったおかげで、CEOやビジネスメンバーも開発に参加できるようになるなど、嬉しい副作用も生まれています。やはり非エンジニアにとってブランチ運用は大変なので。

とは言え、全ての機能が全部表に出ちゃうと大変なので、弊社では「アクティベーション・フラグ」という仕組みを作り、運用しています。 「アクティベーション・フラグ」は同じバイナリの中であっても、利用者によって使える機能を制御できる仕組みです。 この仕組みをつかって、Drivemodeではユーザー・セグメントによって新機能を段階的にリリースするという事を行っています。

アクティベーション・フラグで管理されるセグメントは全部で3つあり、1つは「Experiment」という早期アクセスのベータ版です。 これは、一般ユーザでもDrivemodeアプリの中から設定でONすることができます。 まだ機能は不安定だし、リリースするかどうか正式に決まっていないけど、それを理解した上で機能を利用し、フィードバックなどを通して誰でも開発に参加することができます。 もう1つは「社内限定リリース」です。これはビジネスのメンバーを含めて社内の人間が全員利用することができます。 社内であれば少々クラッシュしたり不具合が発生してもいいので、結構アグレッシブに機能を追加しています。 最後に「デベロッパー限定リリース」というのがあり、これはエンジニア以外は誰も利用することができません。 なので、まだアイデア段階だったり、開発中でまともに動かない実装も、CEOの目を気にせずどんどんリリースしています（笑）

もちろん、場合によってはmasterにすぐに変更を入れることができない場合もあります。 影響範囲の大きな開発や、パートナー企業と一緒に進めている案件などは、別のブランチにソースを分けて開発しています。 例えばGoogle Play Servicesやサポート・ライブラリのアップデートは事前に別ブランチで試してから、masterにマージすることが多いです。

ちなみに、このアクティベーションフラグは、DeployGate SDKのユーザー認証機能を使って実現しています。 DeployGate SDKを使うと、アプリを現在利用しているのがどのDeployGateユーザーなのか、またはユーザーでないのかという事が簡単に取得できるので、 そのユーザー情報を元に「アクティベーション・フラグ」を適用するセグメントを切り分けています。 こういったユーザー認証や権限の管理は独自に作ったり管理すると面倒な事も多いですが、実装不要でDeployGateに全てまとめることができるのでとても便利です。

「アクティベーション・フラグ」で管理されている機能も含めて、全て同じバイナリがストアにも上がっています。 なので、クリティカルなものを除いては、まだコードレビューやQAが終わる前の機能もどんどんリリースされています。 DeployGateのおかげで、ドッグフーディングを安全に、とても簡単に行うことが出来ていると思います。

配布ページをGitブランチごとに自動生成。
パートナー企業への特別版の配布も安心＆簡単に。

― その他に、DeployGateで活用している機能などはありますか？

配布ページをGitとインテグレーションして自動生成させているのですが、これがとても便利ですね！ 弊社ではパートナー企業に対して特別なバージョンのDrivemodeを配布することがあるのですが、このときにDeployGateの配布ページ機能を使っています。 配布ページは特に自分たちで操作して作るわけではなく、パートナー向けのワーキングブランチをGit上で作ってPushしたら、APIで自動的にDeployGateの配布ページが作られるようにしています。 やることはブランチを切ってGithubにPushするだけです（笑）

もちろんコードを修正して対象のブランチにPushすれば、自動ビルドが行われ、ブランチ名から対象の配布ページを経由してパートナー企業に最新版のアプリが届けられます。 バイナリを1度配布するだけで終わりであれば配布ページを作るまでもないのですが、ほとんどの場合は配布した後に改善や修正でアップデートを行う必要があるので、 パートナー企業が複数存在する場合のアプリのバージョン管理は想像を絶するほど大変です。 DeployGateを利用すると、こういった一連のフローがとても簡単で管理しやすくなるので重宝しています。 DeployGateのAPIインテグレーションと言っても、ビルドプロセスの最後にcurlを1行書いているだけなので、DeployGateは何よりシンプルに使えるのが良いですね。

― 今後のDeployGateに期待する機能や要望などがあれば教えてください

技術的に難しい部分もあるとは思うのですが、全自動アップデートを何らかの形でできるようにしてほしいです。 rootedな端末だけとかでもいいので、自分でインストールしなくても常に最新版を使えるみたいな感じになると、とても便利です。 あとは、DeployGateクライアントからのコールバックを自分たちでも自由に定義して追加できるようになると便利ですね。 先程お話した「アクティベーション・フラグ」も、もしDeployGateクライアントからのCallbackを見てすべて判断できるようになれば、プログラム側で何もユーザーごとの機能制御の管理を行う必要がなくなるので。セグメントごとの配布ページを作るだけで、機能のアクティベーションできるようになると最高です。 あとは過去のバイナリの履歴が全部ほしい！あ、でもこれEnterpriseプランにはあるんでしたっけ？じゃあスタートアップフレンドリーなプランがほしいかな（笑）

― 最後に、今後の開発においてDrivemodeで大切にしていきたい事などあればお聞かせください。

とにかく、様々な意味で「速度」を大切にして、最大化していきたいと思っています。 できるだけ早く色んなことに取り組み、いろんな事を試したい。開発の速度もそうだし、それをテストする速度も、リリース後の効果を測定する速度も。 そういった意味でも、DeployGateを使って社内でスピーディーにDrivemodeを検証しながら開発し、とにかく早くユーザーに価値を届けたいと思っています。

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