iOSアプリ開発にチームで取組むチャレンジ

http://vimeo.com/109624121

1 comment | 1 point | by WazanovaNews 約2年前 edited


Jshiike 約2年前 edited | ▲upvoteする | link

Michele Titoloについて取り上げるのは、

に続いて三回目ですが、今回はiOSアプリづくりにおけるチーム内の連携がテーマ。

彼女は現在、redditのiOSチームのリーダーをしながら、Objective-Cプロジェクトの依存関係の管理をしてくれるCocoaPodsの開発と、非営利団体 Women Who CodeのCEOを兼務しています。

redditはwebで大量のトラフィックとユーザを抱えてますが、スマホのアプリに注力しはじめ、切り口を変えた複数のreddit閲覧アプリづくりにチームで取組んでいます。最近では、Ask Me Anythingのアプリをローンチしたり、Alien Blueを買収したりと話題です。

コードの共有

  • 複数のアプリをチームでつくるには、開発手法の整合性を取る意味でも、どうコードを共有するのかというのは大事なポイント。巨大なコードベースを常にダウンロードさせるわけにはいかないので、必要な部分を共有できる仕組みが必要。
  • しかし、誰かが誰かのコードに知らないうちに依存してたり、バージョンの問題がでたり、放置されるライブラリがでてきたりという頭の痛い状況にはなりがち。
  • 社内ライブラリなどを利用することで、どの部分を共有する意図があるのか、チームメンバに明確に伝える。
  • もしくはオープンソースにすると、世の中に全体に共有するという明確な意思表示になるし、コンパクトにモジュール化されて、意図も伝わりやすい。
  • とにかく何でもバージョンをつけるのを徹底することで、混乱を防ぐとともに、問題がでたときに対応しやすくする。

サードパーティのライブラリ

  • 自分はcocoapodsに関わっていて、cocoapodsは大好きだが、それでも「ライブラリの選択は慎重に」と言いたい。
  • 2年後にiOSがアップデートされて、アプリがクラッシュするなんてことは、Appleのアップデートなら必ず起きる。もしそのときの原因が過去に選択したライブラリであっても、自分のユーザに影響がでているのだから、よく知らないコードベースでも、自分でどうにかしなくてはいけない事態にもなりうる。
  • ライブラリを選択するということは、このように将来に顕在化するかもしれない問題を継承しているということ。

コーディングのスタイルガイド

  • New York TimesのiOSチームが最近つくったスタイルガイドのようなものは是非用意すべき。
  • 自分たちのconventions(慣習)をつくりあげる、浸透させることで、つくりあげるものの整合性がとれ、新しいメンバの立ち上がりを助けることができる。

ユーザエクスペリエンス

  • ユーザは同じ会社のだすアプリは同じユーザエクスペリエンスを期待する。
  • FoursquareがSwarmをだしたときに、位置情報の確認ボタンの場所や、検索のやり方を変更したりしたのはいただけない。

エンジニア同士のコミュニケーション

  • Xcodeは複数のメンバで開発するにはベストなツールではない。6人で仕事をしていると、誰かが誰かの仕事に依存したり、Pivotal Trackerでスタートを押してなかったので同じXcodeのストーリーを選んでしまったり。
  • チームが大きくなれば、チーム内でのコミュニケーションでカバーする。自分のチームでは、ゴム製のダックを順番に各人の机の上において、それがある人だけがプロジェクトファイルを編集するようにしている。
  • 衝突ポイントをみつける努力も必要。APIリクエスト、ストーリーボード、コード/データマイグレーションなどでよく起きる。自分が何に取組んでいて、それが周りのメンバに何の影響を与えるかもしれないか明確に伝える。
  • ミーティングは嫌いでも、アーキテクチャの議論をして分担と段取りを明確にすれば、生産性は3倍違ってくるはず。
  • 気づいていない依存関係に気づくように働きかける。「このpodをアップデートしてるから、自分に何か起きないか確認して、何か起きたらすぐに言ってね。」と、コミュニケーションしすぎるくらい、したほうがよい。コミュニケーションが不十分で未発見の依存関係が残り、例えばローンチしてから2週間後という本当に大事な時期に、コードをマージして全てが壊れてしまうなどという事態は避けたいはず。

クラッシュ

  • バイラルでユーザ数が一気に増えるのは本当に気持ちよいが、クラッシュの影響度はでかくなる。
  • Crashlyticsなどのツールは必ず使うこと。
  • アナリティクスタグをつけてログを取得して原因を深堀りする癖をつけること。

カスタマーサポート

  • サービスが大きくなると、当然影響は大きくなり、同じ障害についての大量の報告がユーザから届く。ユーザは自分の意見を聞いてくれることを期待している。
  • バグかどうかの判別して、必要あらばすぐに修正するというのは、気が重くても必ず高い優先順位でやらなくてはいけない。

結論

  • サービスがスケールするのが悪いわけではない。成功している証。世の中にインパクトを与えている証。
  • これまで挙げたような問題は起こりうるが、究極的には自分たちにとっても良いことだと認識して取組むべき。

#ios #reddit


ワザノバTop200アクセスランキング


Back