eureka techblog

iOS優勢な日本におけるAndroidエンジニアの生存戦略

2015.12.24

Android

by Yuya Kaido

ツイート

はじめに

エウレカ Advent Calendar の24日目です。

はじめまして。Couples事業部でAndroid版開発を担当している海藤と申します。エウレカには大学時代にインターンとしてジョインし、そのまま今年の新卒として入社しました。インターンとしてジョインしてから1ヶ月程はpairsのAndroid版開発を担当し、その後にCouplesの立ち上げとほぼ同時期にCouples事業部にジョインしました。今回はAndroidエンジニアから見たCouples事業部の開発体制の変遷を振り返ってみると同時に、チーム開発を行う上でAndroidエンジニアならではの苦労とそれに対する生存戦略についてまとめてみたいと思います。

開発体制の変遷と苦労

Androidエンジニアから見ると、Couplesの開発体制は以下のように変化しており、それぞれの段階でAndroidエンジニアならではの苦労がありました。

立ち上げ〜リリースまで：iOS版が仕様書時代

Android版の仕様書がない

リリース直後〜6ヶ月：iOSの追加仕様が共有されない暗黒の時代

仕様変更の横展開がない

6ヶ月〜：Androidの仕様書が出来始めた時代

Androidのデザインへの理解がない

まずはそれぞれの苦労について簡単にまとめてみます。

Android版の仕様書がない

CouplesのリリースはiOS版が2014年の5月初旬、Android版が同じ年の7月初旬です。Android版の開発期間は5月〜7月の実質2ヶ月間でした。当時はとにかく動くものを早くリリースすることを重視していたため、Android版はおろか、iOS版にも仕様書はありませんでした。幸い？Android版はiOS版がリリースされてから開発が始まったのでiOS版が実質的な仕様書状態でした。

当時は右も左も分からないインターンだったので仕様書（iOS版）をまったく疑うことなく、そっくりそのまま実装することをゴールとしていました。当たり前のことですが、AndroidでiOSのデザインを再現するのは、Androidに最適化されたものを再現するよりも時間がかかってしまいます。さらに時間がかかる割にAndroidユーザーにとっては使い勝手が悪いものになることがあります。何故かと言うと、Androidユーザーにとっては慣れていないデザインということになるからですね。iOS優勢の日本においてはiOS版が仕様書という状況は多いのではないでしょうか？

当時の開発の様子を再現した画像を作ってみました。Android Studioを使ってAndroidアプリを開発しているかと思いきや、そのデザインはiOS版にそっくりという、一体お前は何エンジニアなんだという状態でした。

仕様変更の横展開がない

iOS版はありがたいことにリリース直後から利用者が順調に伸び、Android版がリリースされる頃にはある程度のユーザー数がいるという状態になっていました。そんな中でiOS版は常に改善を続けていたため、口頭やチャットツールで関係者だけでクローズドにやり取りされた改善案がAndroidチームに共有されず、リリース前の社内テストにてそれらが発覚するということが何度も発生しました。Androidチームとしてはそもそも変更後の仕様を知らないのでやむなくリリースを延期するということもありました。

Androidのデザインへの理解がない

リリースから半年が経過したころにはAndroid版もある程度のユーザー数になり、Androidエンジニアからの必死の訴えもあり、Android版の仕様書も出来始めました。これで一件落着かと思いきや、まだまだ苦労は続きます。基本的にiOS優勢な日本ではデザイナーがiPhoneを使っていることが多く、弊社もそれに該当していたということもあり、Android版の仕様書がiOS版のそれに酷似しているという状況が多く発生しました。Android向けのデザインを十分に検討した上で、相応の理由があってiOS版に似たデザインにしているのであればいいのですが、そうではないことも事実としてあります。明確な理由なしにAndroidでiOSのデザインを採用することはAndroidエンジニアのモチベーション低下にも繋がりますし、何より前述の通りAndroidユーザーにとっては慣れていないデザインということになるので、UXの低下にも繋がりかねません。

Androidエンジニアの生存戦略

さて、Couplesの開発フローを例に考えてみましたが、どこの会社でもAndroidエンジニアは多かれ少なかれ以下のような苦労をしているのではないかと思います。

Android版の仕様書がない、Androidのデザインへの理解がない

仕様変更の横展開がない

「Android版の仕様書がない・Androidのデザインへの理解がない」問題に対する生存戦略

この問題の解決策として一番簡単に思いつくのはデザイナーに「Androidのデザインを理解した上でAndroid版の仕様書を作成してもらう」だと思いますが、一流のAndroidエンジニアであれば、日本ではiOS優勢という現状を受け止めた上でデザイナーと共にAndroid版のデザインを作り上げていかなければいけないと私は考えています。デザイナーのリソースは有限であり、慣れないAndroidのデザインには時間がかかるというのは容易に想像がつくはずです。Androidに関してはAndroidエンジニアが一番詳しいはずなので、デザイナーと共に「All for All」の精神でデザインを作り上げていける環境を作ることが大切です。

「仕様変更の横展開がない」問題に対する生存戦略

この問題の解決策として、Androidチームが頑張ってキャッチアップするといった根性論で解決するのは適切ではありません。根性論では結局漏れが発生しますし、何よりAndroidチームが辛いという状況は何一つ改善しません。Couples事業部の場合、根本原因は「それぞれのOSの仕様書を別々に管理していた」というところにあります。もともとデザイナーが両OS個別に仕様書を作成し、エンジニアはそれをPDFとして受け取っており、仕様変更がある度にPDFを作り直さなければいけないという状況でした。このように仕様変更の度に仕様書を作り直さなければいけないのはデザイナー側も辛いですし、仕様変更を知らされなかった側のエンジニアも辛いです。そこで、現在は両OSの仕様書を以下のようにGoogleスライドで管理しています。GoogleスライドはWeb上で編集出来るパワポのようなイメージで、編集内容がそのスライドを開いている全員にリアルタイム反映されます。このGoogleスライドで仕様書を作ることで、iOS側で仕様変更があった場合にも共通のスライドを変更するだけでAndroid側にも仕様変更が反映されることになります。

今回はたまたま「仕様変更の横展開がない」という問題を扱いましたが、何かの問題の解決策として根性論を持ち出すのは往々にしていい解決策とは言えません。しかし、何かしらの仕組みを導入した上で根性論に基づいた解決策も追加で講じるとより効果的です。今回の場合は「Googleスライドで両OS共通の仕様書を作る」という解決策の他に、Androidエンジニアがチャットツールや社内の会話に過剰なくらい反応し、Androidチームにも仕様を共有しなきゃという空気感を作るということもやっていました。

まとめ

技術ブログなのに随分ふわっとした内容になってしまいましたが、個人的にはユーザーに価値を提供するプロセス全体がエンジニアリングだと思っているので、直接技術には関係ない話題でしたが技術ブログに書かせていただきました。結論として、日本ではAndroidが冷遇されているからと言って、自分では何もしようとしないのはAndroidエンジニア失格です。Androidユーザーに届ける価値を最大化するためにデザイナーやディレクターなど周りを巻き込んでいくことがAndroidエンジニアの生存戦略だと私は考えています。

eureka Advent Calender 実施中です。Go言語関連を始めとして、大規模サービス特有の事例、Tipsを共有しています！

ツイート