いいアプリを楽しく開発できる現場を作るために大切なこと

モバイルDevOps Advent Calendar 2015 1日目

アプリ開発者のみなさんこんにちは！モバイルDevOpsアドベントカレンダー始まりました！！

今回は初っぱなということで、モバイルのDevOpsって何というところから、現在のモバイルアプリ開発とその改善の方向性についての読み物を共有したいと思います。

主に継続的な運用を必要とするアプリ開発をされている方で、 アプリを作ってるんだけどもうちょっと効率よくしたい とか これからいろんなツールを使ってみたい という方の方針決めに役立つかと思います。具体的なツールやサービスの話まではここではカバーしてません。それについては、これからいろんな方がいっぱい書いてくれる（まだの人もきっとこれから参加してくれる）と期待してます！

みんな楽しくアプリ開発したくない？

早速ですが、あなたはアプリの開発に時間を最大限使えてますか？開発に集中できて、しかもいいアプリが作れると楽しいですよね。楽しいアプリ開発現場ってどんな感じでしょう。

プロダクトの本質的なコード書くのに集中してるだけで、
どんどん有用なフィードバックがやってきて
変化を明確に確認しながら改善できてアプリが成功する

やりがいが持てる理想的な開発体制はそんな感じでしょうか。これができてるなら どうしたっていいアプリしか作れない 環境が整っているといえるでしょう。

一方で、いま目の前にある現実。よく見てみると結構コードを書く以外のことに時間を浪費していませんか。

割り込み	所要時間
「新しいバージョンできたよ」「あ、この端末にインストールして！」	約5分/回
不具合起きたから端末お持ちしましたー → ログの回収	約10分/回
既に改修済みの不具合を報告される → ヒアリング＋アップデート	約15分/回
「なんか強制終了した！」報告対応	約20分/回
試してもらう人を探して連れてきて、インストールしてお渡しする	約15分/回
それぞれのコミュニケーション待ち時間、スイッチングコスト	約5〜15分/回

─ Android開発の効率を今日から確実に5%改善する方法

よくありますよね。ちなみに、一日の業務時間が8時間だとすると5分使うことでその1%が消費されています。一つ一つは造作もないことですが繰り返し起きると体感以上に効率が悪化しています。

そしてチームでの開発になると、ほんの些細なすれ違いがミスコミニュケーションに繋がり、空気が悪くなってさらに効率を悪化させてしまいます。そんなのただ辛いだけなので、なんとかして楽しい開発環境を手に入れたい！

開発効率化に期待すること

といった辺りから、なんとか自動化したりして手間を省きたいと考え始めます。それはとても素晴らしいのですが、そこでもう一歩踏み込んでみます。自動化したいという考えの背景に、私たちはどんな問題を抱えているのでしょうか。

私たちは常に人手が足りないという問題を抱えています。仕事でアプリを作っていると、経営陣のやりたいことが次々空から振ってきます。反対側からユーザーの要望が目の前に次々現れます。GoogleやAppleは輝かしい悩みの種を次々に登場させます。息をしているだけでタスクが増えていきます。

出てくる仕様はいつも変更を繰り返されます。言われたものを作ってそれが一発で完璧であることはほぼありません。できあがったものを見て初めて間違いに気づくことが多々あります。新しい価値を生み出すには完璧な仕様書を作るリソースより、自由に試行錯誤ができるプロセスが必要です。

人は間違います。いくらやっても不具合が修正できず悩んだ末よく見たら違うブランチで作業してたり、運用で問題を起こさないよう手順書をしっかり用意してチェックする機構を作っても結局漏れてしまったり、どうでもよい仕事を大量に作り出してスケジュールを圧迫してしまったり、大事なリリースの日に寝坊してしまったりします。継続的な開発には特定の誰かの知識や努力に頼らない仕組みが必要です。

たくさんの山を乗り越えながら、少ない人数で全力疾走するためには？

• 開発者の人数が少ないチームでも本質的な開発に集中し、
• スムーズにトライアンドエラーを繰り返し、
• ヒューマンエラーや暗黙知に縛られず開発できる環境を作るために、

全ての 人間に頼らず解決できる仕事 を生まれる前に消し去りたい。ゴールは定まりました。

DevOpsという「文化」

そういった自動化をはじめとして、こと組織における開発効率化に関する話は、近年 DevOps として多く語られるようになりました。現在の DevOps は、単純に Web 開発におけるアプリエンジニアとインフラエンジニアの間の認識の相違を埋めるという話ではなく、組織におけるコラボレーションや文化といったところまで広く改善していくことだと捉えられています。

たとえば、あるサービスのユーザーサポートのチームが毎日多数やってくるお問い合わせの初期対応時に情報が足りず、毎回ヒアリングが必要となり多くの時間を割かれているとします。この状況を改善するためにサポートのリーダーが改善を求めようとするのですが、本来の「機能要件」に含まれないこの類の改善開発は後回しとなりがちで、失敗を防ぐために数週間のミーティングを繰り返し、数ヶ月後のリリースとなるようなケースも珍しくありません。

一方、もしこれが DevOps な考え方が行き届いた組織であれば、そもそもサポートが詰まっている状況はチームに見える形で共有されており、開発者側から「こういう情報があると解決できるのでは」と5分できる ちょっとした 修正によって、サポートチームの対応コストが 50% 削減されるといった改善が起きたりします。そんな性急なリリースは予想外の副作用があるのではと心配かもしれませんが、開発者のコードはCIサーバによって自動でテストされ、リリースも社内から順に段階的にリリースされていく環境があり、何か問題が発生しても一瞬で元に戻せる環境が構築されていれば、よほどのことがない限り恐れることはありません。

これらを比較すると、単純に サポート対応速度の改善がサービスのユーザー満足度に貢献した という以上に、 数ヶ月分の人的リソースが解放されたことによるコスト削減 という、事業計画に影響するレベルの違いが生まれています。実際、 2014 年の Rackspace による 700 名の技術責任者への調査でも、 DevOps が何ら事業に計測可能な改善をもたらして いない と答えたのはわずか 3% で、残りの方は事業推進における何らかの価値を見いだしています。

DevOps exists to help the business win
─ Surprise! Broad Agreement on the Definition of DevOps

DevOps は事業を成功させるのを助けるために存在している ── 以上のような背景から、近年 DevOps は現場だけでなく、経営まで含む IT を中心とした 組織の文化形成のように捉えられています。 DevOps には、アジャイルやリーンといった考え方が根底にあり、そのためには組織全体が変化を受け入れる文化を作っていく必要があります。一朝一夕でできる話ではありませんが、やり始めることは誰でもできます。無駄なく、リーンに、最初は小さい改善から始めましょう。

モバイルアプリ開発の特殊なところ

DevOpsという言葉は2009年のVelocity ConferenceでのFlickrの発表から生まれたといわれていますが、もちろん現代のモバイルアプリ開発にも広く適用できる概念です。しかし、具体的に見ていくとモバイルアプリの開発には多くの新しい考え方が含まれており、ものによってはWebにおける考え方と真逆となる相容れない部分も出てきます。主な違いをいくつか挙げてみます。

Time to market が長い

完成してないけど、とにかくリリースして様子を見ながらリアルタイムに修正していこう。

今でこそ当たり前(?)のこの考え方ですが、これはWebによってもたらされたイノベーションの一つです。

開発者が書いたコードは、ユーザー(チームメンバーや社内の人も含みます)に見えるまでに、開発環境であれば最短 Ctrl+S すればすべて反映されるぐらい手軽にリリースできます。 Amazon では 1 時間に 1,000 回もデプロイしている なんて話はエクストリーム過ぎるにしても、現実的に数分以内の本番デプロイ環境を持つことが可能になってきました。そんな環境であれば、いくらでも試行錯誤することができます。

しかし、残念ながらアプリはそうではありません。

上の図は開発中の話ですが、実際のリリースはさらに審査や反映待ちの時間が挟まるのでもっと大変です。Webのリリースとアプリのリリースは異なる考え方を前提にする必要があります。

リリースしたものは、販売店の商品棚に並べられる

リリースされたアプリのユーザーに対しての見え方にも違いがあります。アプリは出した瞬間にお店の商品棚に並び、それを使うのは自分に合う商品を探しに来たお客さんです。 Apple Store に買い物に行って、棚に並んでるソフトウェアを見て選んで買うのと同じです。たとえ出す側が「作りかけ」と思って出していたとしても、受け取る側は常に「完璧」な商品と比較しています。

さらにそこには、一生消すことのできないレビューが一緒に用意されています。食べログで★3.5以上だったら「お、期待できるな」★2以下だったら「この店はちょっと近寄らないでおこう」と思っちゃいますよね。あなたのユーザーはそれと似た感覚の期待値を持った上でアプリに触れ始めてしまいます。

Webであれば「今来てる人を逃しても次を捕まえてくればいい」だったのですが、アプリの場合は「昔来た人が今来た人の期待値をコントロールしてしまう」ので、まずいモノを出してしまうとそれがそのままレピュテーションリスクとなってしまいます。★1だらけのレビュー画面で★5のレビューを投稿できる勇気のある人はそんなに多くありません。

自分の管理下にあるサーバではなく、ユーザーの手元で動く

リリースしたアプリは、ユーザーの手元で動き続きます。そのアプリの更新をリリースしたとしましょう。新しいアプリは一斉に適用されるのか。答えはNOです。毎回必ずといっていいほど更新されないままの古いバージョンが残り続け、複数のバージョンが同時に存在している状況になります。そんなバージョンの異なるアプリからアクセスされる API のエンドポイントはどのようにバージョニングされるべきか、あるいは古いバージョンからのアクセスを一斉遮断する仕組みを用意するのか、ユーザーに提供する価値によって求められる判断が変わりますが、どちらにしても専用の仕組みを考える必要があります。

また、リリースしたアプリの更新頻度が高すぎるのも問題になってきます。iOSもAndroidもアプリの自動アップデートが行われるようになりましたが、アップデートはユーザーが求めて行う行動ではないにもかかわらず、端末のリソース、つまりCPUであり、通信量であり、バッテリーを消費してしまいます。その上更新内容がわからない更新を続けられようもんなら、ユーザーは迷うことなく★1を付けていきます。

さらに、アプリの改善に必要なログも開発者の手元から遠く離れたところにあります。ストア側でアプリのクラッシュログは集めてくれますが、それ以外の詳細なログは何らかの仕組みを使わない限りは手元に来ることはありません。

プラットフォームの違いを抱えながら前進する

企業が提供するモバイルアプリで Android だけ、あるいは iOS だけ開発するというケースは希です。基本的に、両プラットフォームに対応することが求められます。それぞれのプラットフォームでそれぞれのルールがあり、プラットフォームそのものも日々新しい要素が追加されていきます。昨日までは OK だったルールが明日には駄目になることも珍しくありません。

とはいえ安定するまで枯れたバージョンで待つというわけにもいきません。新しいOSが出たらすぐに対応する必要があり、これが遅いとアプリのユーザー数と評価が減っていきます。特に iOS はユーザーが率先して OS のアップデートを適用したり新しい端末を手に入れていくため、迅速な改修を求められます。アプリ自体の改修がまったくなかったとしても、サービスの提供が続く限り新 OS への対応は必要になってきます。

改善のポイント

そんな違いのあるモバイルアプリ開発ですが、まず大枠として改善の中心となる考え方は変わりません。

1. どれだけ試行錯誤ができるか
2. どれだけコミュニケーションを円滑にできるか
3. どれだけ開発現場とユーザーのエンドツーエンドの追跡可能性があるか

1. どれだけ試行錯誤ができるか

これは、「自分自身が一日に何回試行錯誤できるか」という視点と、「自分以外の人が一日に何回気づきを得られるか」という視点が大事です。前者については、 Android はつい最近 Android Studio 2.0 Preview で Instant Run が登場 し圧倒的に試行錯誤の回数を増やすことができるようになりました。とにかくみんな使うべき。

後者は CI やテスト配布を日常にすることで、とにかく開発者以外の人の気づきを増やすことが重要です。Webは開発中からステージングサーバの内容が次々更新されるので、関係する人がそれを見ながら それぞれの視点で 新しい気づきを得ることができますが、アプリに関しては開発者の手元から外に出ないため、いろんな抜け漏れが発生しがちです。アプリのUI上の課題はたった 5 人に見てもらうだけで 80% が洗い出せるといわれています。日常で 5 人ぐらい見て突っ込んでくれる人がいる状況を作れると捗りますね。

2. どれだけコミュニケーションを円滑にできるか

コミュニケーションを円滑にするためには、まず発生している出来事が常にチーム内で自動的に共有される状況を作ることが大事です。例えばSlackにアプリの開発中のgit pushから、やってきたユーザーの問い合わせ、発生したクラッシュまですべての情報が流れるようにします。

人間、見えないことは常に不安要素です。普段それぞれが何をやっているのか、リリースされたアプリでは何が起きているのか、といった動きが見えないと、あらゆる場面でこれどうなってるの？仕事してる？といった種類の確認が頻発したり、結果起きてしまった認識の相違を修正するために本来不必要なやりとりが発生しがちです。正しい一次情報が見える場を共有することでこれらのやりとりを減らすことができ、また優先すべきことが明確になるため不要な仕事を減らすことができます。何かが起きているときに「何かが起きている」という気づきが得られる状況ができるだけでもメリットがあります。リリースがトラブって問題解決に躍起になっているタイミングに空気を読めず打ち上げの話で殴り込んでしまい最悪な空気に陥ってしまうような事故も防げます。

また、外からの情報も共有しましょう。例えば毎年6月頃にWWDCやGoogle I/Oといった開発者向けイベントでは、各プラットフォームの新しいOSや機能が発表されます。現地に赴くことが難しくても、まとめのブログやQiita記事がその頃にはたくさん出てくるので、そういった情報を得たらすぐにチャットに投げるようにしたり、Twitterをキーワードでクロールするbotを常駐させたりすると、自分はもちろん他の人から見た様々な視点での気づきがチームで共有されます。

3. どれだけ開発現場とユーザーのエンドツーエンドの追跡可能性があるか

追跡可能性は、クラッシュのようなアプリの不具合だけではなく、リリース後のアプリの動向を常に見えるようにすることと、ユーザーと開発者をお互いに見えるようにすることが大事です。野に放たれたアプリは予想外の環境で壮絶な死を迎えることがあります。すべての環境を自分たちの手元に用意することは困難ですが、知らない端末で起きるそういった不幸な状況をいち早くキャッチし、具体的な再現手段が得られ対策できることは、品質改善だけでなくユーザー満足度の向上にも役立ちます。また、ユーザーは文句を言う一番手軽な手段としてレビューを使う傾向があります。もっと簡単に声を上げられる方法がアプリ内にあればレビューでの低評価を抑えることができます。

そして何より、ユーザーからの建設的なフィードバックがやる気を生み出します。作ってるアプリには必ず使ってる人がいます。本気で作ってるアプリだったら、使ってる人からの声聞きたいですよね。これをきちんと受けられるような仕組みを用意することが大事です。

また、Webに比べると課題が多く見えるモバイルアプリ開発ですが、逆にそこを活用する流れも出てきました。たとえばアプリはローンチ後の改修は難しいですが、ローンチ前であればいくらでも改修できるので、リリース前にテスターを募集し改善を行う期間を持つことで、リリース前からユーザーの行動が分かり問題対策した上で本番に臨むことができます。これが品質改善だけであれば驚くことはないのですが、大事なのはこれが同時に強力なマーケティング手法に繋がるということです。テスト参加者は「自分がちょっと開発に協力したアプリ」という点でロイヤリティがあり、リリース後には率先してアプリを宣伝に協力してくれるため、最初から建設的な高評価のレビューが続く状況が生み出せています。昔からPC向けMMORPGで当たり前だった「クローズドベータテスト」ですが、最近はスマホゲーム界隈にも徐々に浸透し始めてきています。

おわりに: 少しずつ実践しよう

そんな感じで、モバイルアプリ開発をもっと楽しくするためにDevOpsしていこうなって話を書いてみました。Webとモバイルアプリの違うところは注意しながら、改善のポイントを抑えつつ、各種技術を取り入れていけるとよいですね。

すべての問題を洗い出して一気にやるというのは心が折れてしまいます。優先度としては、(1)いろんなものを流し込める情報共有の場を作る、(2)各種イベントが見えるように繋ぎこむ、(3)機械にできる繰り返し作業を自動化する、の順で、手を付けられるところから少しずつ射撃しつつ前進していくのが、起きる変化が見えやすいのでよいかと思います。

また、理想だけど今は手が出せないなー、と思って後回しにしてしまうのも勿体ないです。いま課題を解決するのにかかる時間はコストですが、将来にわたり同じ課題を抱え続けるのはリスクです。せっかく目の前になんとなく改善できそうな課題が見えてるなら、機会を作ってさっさと手を出してしまいましょう。うっかり改善できちゃったら儲けもの、ぐらいのノリから始めて実際手を動かすことで、何かの問題の本質を考えて解決するという何にでも応用が利く経験が得られます。

そんでもってどんどん知見を共有しましょう！モバイルDevOps Advent Calendar 2015はまだ参加者を募集してます！

参考文献

• NO, YOU ARE NOT A DEVOPS ENGINEER
  • DevOpsエンジニア なんて肩書きは存在しないという話
• 開発と運用の新しい関係、「DevOps」とは何か？
  • Flickrのセッションの概要など
• モバイル開発のためのDevOps
  • IBMのエンタープライズでの知見
• モバイル・アプリケーションでの DevOps の課題とベスト・プラクティス
  • こちらもエンタープライズでの10の知見だけど活かせるものが多い

本文中に出てくるスライド (DeployGateのやつなので若干宣伝ちっくですがご容赦ください )

• よりよいアプリを作るための開発効率化のすすめ
  • SaaS使って開発効率化して行こうって話
• DeployGateで実践！モチベーション高くヒットアプリを作る方法
  • リリース前にベータテストしてたらテスターが3000人超えてリリース1日後にレビュー236件平均★4.9だった話