Edited at

iOSアプリ開発の現場で訊いてみた!ユビレジ編

More than 1 year has passed since last update.

自分が他社のiOSアプリ開発者と話す時にいつも同じことを聞いていたのでそれをQiitaにまとめていましたが、実際に他社の開発の現場でインタビューをしてくるというシリーズになりました。

記念すべき1社目はユビレジ社!


ユビレジとはなにか

私の分かる範囲でユビレジというものについてすごく平たく説明すると、iPadを利用したお店のレジとそれを管理するウェブ上のシステムみたいな感じだと思います。そもそもお店のレジスターっていうものは単純な売上の計算のためだけのものと、商品や顧客情報をひもづけるPOSレジ(POSはPoint of sale)と呼ばれるものがあって、このPOSレジをiPadとウェブで実現するぜ!ということでしょう。


訊いてきたこと

ユビレジ社ではiOSアプリ開発をしている人で知らない人はいないという@kishikawakatsumiさんと、インターネットで有名な@laisoさんを中心にお話を伺いました。

@laisoさんについては最近だと「ソーシャルリクルーティングサービスWantedlyを活用した就活日記」を読んだ方も多いのでは。実にさわやかな好青年でしたよ

初めて@laisoさんにお会いしました!iOSやっててよかった


Q.バージョン管理システムは何を使ってる?

GitHubを使ってる。GitHub Enterpriseは使っていない。


Q.コードレビューをどのように行ってる?

コードレビューのタイミングはプルリクされた時。

基本的にはプルリクで問題ないと判断されればプルリクを送った人がマージする。

レビュー担当は適当。

[WIP]と書かれたプルリクエストは「即masterにマージしても良いか」という視点ではレビューしない。

プルリクエストにするということは何かしら見てほしいということのはずなので、そのプルリクエストが送られた背景に沿ってレビューなり意見を書くなりする。


Q.ブランチの運用はどのようにやってる?

中央リポジトリに対して個人リポジトリからプルリクエストを出す。

ブランチはgit-flow的なdevelopというブランチはなくて、トピックブランチからmasterにプルリクエストをしている。

トピックに収まらない機能が重いブランチもあって、並行して開発される。

その場合はmasterにマージするときに差が大きくなってしまうのを避けるために、ちょいちょいmasterの更新をマージしてきている。


Q.Storyboardやプロジェクトファイルなどでコンフリクトが起こらないように工夫してる?

もともとは一般的なStoryboardの使い方と同じようにプロジェクト内で1つか2つのStoryboardを使っていたが、今は1つの画面(ViewController)に対して1つのStoryboardを使っている。

メリットとして、関係ない画面の変更でのコンフリクトがおきないということがあってデメリットしてSegueは使えないが、コンフリクトが置きないことに比べると大きなデメリットではない、とのこと。

これについてはkishikawakatsumiさんのブログでさらに詳しく説明されています

また、@laiso さん的には一般的なStoryboardを使ったViewControllerのデータ受け渡しにはpublicプロパティにデータを入れる形になるがそれが肌に合わないとのこと(ちなみに私はViewControllerの.hを見て他のViewControllerから受け渡されるデータを把握するので興味深かった)。


Q.アジャイル開発はどの程度取りいれてる?

厳密なスタイルはないけどいろいろ試している。

最近はアジャイルレトロスペクティブズ (http://www.amazon.co.jp/dp/4274066983)の「ふりかえり」をやっている。

月曜に先週の「ふりかえり」をして、今週やることを話しあって決める。

デイリースクラムとしてのミーティングは夕方。

チームでのタスクはぺたぺたと看板に貼っている。

リリースに関しては一度のリリースで変更を大きくせず、短い周期で2週間から1ヶ月でリリースしてる。ユーザーに細かくアップデートしてもらうために「目玉のバージョンアップ」のようなものは含んでいることが多い。


Q.「開発環境の改善とかコミュニケーション改善で自慢したいところ」とかある?

改善した点としては@kishikawakatsumiさんがQiita Teamを導入した。

QiitaTeamの利点として


  • ソースコードの引用がやりやすい

  • GitHubのWikiはプロジェクトごとになるので社内開発チームや全体に周知したい場合には向いていない

他のコードレベルでの改善点としては、「初見殺しなコード」を排除することで、自分たちが継続的に保守/機能追加がしやすいコードにしているとのこと。

自慢したい所としては福利厚生のデリバリーランチ。

オイシックスのサラダランチ。

http://shopping-tribe.com/news/6747/

ARMSのバーガー

http://www.arms-burger.com/about

特にARMSのバーガーは絶賛されていたので原宿代々木の近くにいる人は行ってみるといいかもしれません。


Q.現状の開発に関する不満点やさらに改善したい点などある?

TravisCIを使っているが、いろいろなパターンのテストを実施しているので総ビルド時間長く、プルリクエスト後にテストが通ったらTestFlightにアップロードするというのを自働化しているが、実際のアップロードまでの時間がかかってしまう(30分ぐらい)。あと時々TravisCI上でだけ発生する意味不明な現象でテストが失敗する。しかしJenkinsを使っていた頃よりは快適になったらしい。

ちなみに、GitHubにpush後にTravisCIがビルドを失敗するとHipchatに通知するようになっている。

他の不満点としては、iOSアプリのクラッシュレポート通知集計システムにCrtiercismを使っているがCrashlyticsに乗り換えたいとのこと。Crtiercismはクラッシュの一覧ソート順が新しいものから並んでしまうが、Crashlyticsは頻度の高いものから並ぶなどUIが優れている点が良い。


その他


机が広く、今のところ一人あたりのスペースが広い

個人の机自体も広いスペースなんですが、机と机の間が広いのが印象的でした。


コミットメッセージは英語?

gitへのコミットメッセージは英語縛りはないが@laisoさんは@kishikawakatsumiさんから英語で頑張れって言われたので、英語を使っていたが、実は社内ルールじゃなかったとのことでした。


使っているライブラリ

Podfile.lock から引用

PODS:

- AFHTTPRequestOperationLogger (1.0.0):
- AFNetworking (~> 1.0)
- AFNetworking (1.3.3)
- CrittercismSDK (4.3.4)
- FastCoding (2.1.9)
- FXImageView (1.3.3)
- GCDWebServer (1.4)
- Helpshift (4.5.0)
- JLRoutes (1.5.1)
- NLCoreData (0.5.3)
- NSRunLoop+PerformBlock (0.2.0)
- OCHamcrest (4.0.0)
- OCMock (3.0.2)
- OHHTTPStubs (3.1.2)
- PEPhotoCropEditor (1.3.1)
- PSTCollectionView (1.2.1)
- SDWebImage (3.6):
- SDWebImage/Core
- SDWebImage/Core (3.6)
- SEJSONViewController (0.2.0)
- UICKeyChainStore (1.0.5)
- UrbanAirship-iOS-SDK (4.0.0)
- UUIDShortener (1.0.1)
- YLProgressBar (3.1.1)
- zipzap (7.0)


さいごに。オレはこう思ったっす

iOSアプリというのはソーシャルゲームや日常的に使うウェブサービスのiOSアプリ、他にも受託開発で色々なiOSアプリ開発があり、POSレジのアプリというのはまだまだ少ないわけですが、ユビレジ社のiOSアプリ開発者は現在4名。それぞれiPhoneアプリの初期から現在まで様々なアウトプットをされている方たちなので、そういうiOSおじさんたちの指導を受けつつ仕事をしていくというのは若くて吸収力のある人にとってはかなり刺激的で貴重な体験になると思ったっす。

ほかにもTravisCIやCrtiercismなど、外部サービスを使って自分たちのアプリの向上につなげる場合、各種サービスとの比較検討を重ねているので、老害という人たちとは程遠い世界線にいるということを感じました。

外部サービスといえば、開発の現場での採用話として「うちは転職してきてくれた人からもどんどん新しいものを取り入れたいので何かあればガンガン言ってくださいよ」的な話を聞くんですが、そういうのって転職してきた人が充分慣れていない時にとても力を使わないといけない印象を受けます。気持ちは分かるのですが転職してくる人がその現場の改善を行うというのはとても力を必要としますし、そんな事をしないに越したことはないんですよね。そのため、自分たちがどのように日々検討し改善しているかというのを説明するという事のほうが、改善を望んでいるにしてもよっぽど効果的だなっていうことも気付かされました。

さーて、次はどこへ行っちゃおうかなー!


関連のインタビュー