はじめに
iOSエンジニアの尾林です。Sansan iOSアプリを開発しています。
今回は1/27にJapanTaxi社とZOZOテクノロジーズ社からスピーカーを迎えて開催した「iOS開発チームの特徴と開発方法を公開！」勉強会に参加してきましたので、その様子をレポート記事としてお伝えします。
sansan.connpass.com
弊社からはSansan iOSチームのLead Engineerである中川が登壇することになりましたので、その応援も兼ねて参加してまいりました！
今回の勉強会は、「各社のiOS開発チームの特徴を踏まえながらその開発手法を紹介する」をコンセプトとして開催されました。
今入庸介 氏 / JapanTaxi株式会社
トップバッターはJapanTaxi社でiOSエンジニアをされている今入庸介さんの発表です。
JapanTaxi社のアプリ開発では Server-iOS-Android を横断する形で2チーム構成になっており、各チームが並列でプロジェクトを回す体制を取っているようです。
そんな各チームが並列で開発を進める中で、継続的かつ安定してリリースする手法についてご紹介いただきました。
まずはコードの品質を保つための手法についてです。
JapanTaxi社ではその手法の一つとしてSwiftLintを採用しており、無効化したルールに対してはその理由をしっかり記載するといった規則が印象的でした。
また、テストコードに関してはテストを書く際の心理障壁を下げるためにUnit Testのテンプレート化やモックを自動生成する手法を導入しているようです。
テストを書く心理障壁の高さは私としてもまだ自覚があります。先日同僚から「既存機能のパフォーマンス改善をした際に、テストコードがあったのでとてもやり易かった」という話を耳にしました。このようにテストコードがあることによって開発の効率が上がる体験を重ねることも、テストを書く心理障壁を下げる要素の一つになりますね。
続いてチーム開発におけるコードレビューの効率化について取り上げられました。
JapanTaxi社ではPull PandaによってPull Requestのアサインを自動化/レビュー負荷の均一化を図り、更にレビューの達成度を週次で確認しているとのことでした。
弊社でも同じ目的でPull Pandaを導入していますが、JapanTaxi社ではもう一歩踏み込みレビューの達成度合いを共有することで、レビューが滞っている週があればその原因を追究し次の改善に繋げることができるので、素晴らしい取り組みだと思いました。
最後にリリースサイクルについての事例です。
JapanTaxi社では定期リリースの手法を採用しており、これにより安定してユーザに価値を届ける仕組みを実現されていました。
曜日を固定化することで他部署との調整がしやすくなる他、予定に間に合わない場合は来週のリリースに持ち越すことが出来る等、無理なくリリースできるサイクルが回り、それが日々の安定したリリースに繋がっているようです。このような取り組みの結果、2019年の合計リリース回数は41回だったとのことです。*1
@banjun 氏 / 株式会社ZOZOテクノロジーズ
続いてはZOZOテクノロジーズ社でZOZOTOWNのiOSアプリ開発を担当されているばんじゅんさんの発表です。
なんといってもZOZOTOWNのiOSチームで特徴的なのは、チーム内で「案件開発」と「本質改善」との2ユニットに分けて構成されていることです。
複数人で真っ当に開発をしていれば、その殆どのチームが直面する「コードの質やレビューの仕組み等に対して改善を回しながらユーザに価値を提供しなければならない」という課題に対して真摯に向き合った故のこの構成という話は大変興味深いものでした。
ちなみに本質改善側の人はずっと改善のみのタスクをこなしているのかといえばそういうことではなく、適宜役割を交換しながら進めているようでした。
ZOZOTOWN iOSアプリの歴史は2010年から始まっています。
その長い歴史の中でメンバーも度々入れ替わり、歴史的経緯からくるドメイン知識の不足やレガシーなコードスタイルが多く存在していることが課題として挙げられました。今回の発表では、それらに対する解決策として取り組まれている事例についてご紹介いただきました。
まずはドメイン知識の不足に対するアプローチとして挙げられた事例が「多人数によるPull Requestレビュー」です。限られたメンバーのみではなく、できるだけ多くのメンバーによってPull Requestレビューを実施します。
これによりコード品質を保つだけでなく、新規案件や改修によって発生した新たなドメイン知識をチームメンバー全体で学習することを可能にしています。
また、そこから得られたドメイン知識をソースコードのコメントや「ZOZOTOWN用語集」成るものに残し、新規メンバーへのノウハウ共有にもご活用されているようです。
続いてレガシーなコードに対するアプローチとしてすべてを一気に片付けないことを挙げられていたのが非常に印象的でした。レガシーなコードを綺麗に整える作業は、そのアプリの規模や年数に比例して膨大になっていきます。今年で10歳を迎えるZOZOTOWNアプリのすべてを綺麗にする作業量は計り知れません。そこで彼らが採用したアプローチは対象を分割して影響範囲を調整可能にすることでした。コードのある箇所を変更しても周りに影響を及ぼさないように、ロジックの切断を考えることから始めるのです。この切断作業を終えた上で、可読性を上げるリファクタリングやパフォーマンス改善のような修正に取り組みます。こうすることで影響範囲を自らコントロールすることができ、芋づる式にデグレが発生するような事態を防ぐことができます。
中川 泰夫 / Sansan株式会社
最後は弊社のiOS Lead Engineerである中川の発表です。
Sansan iOSアプリチームの規模は事業成長に伴い、ここ1年程で急拡大しました。
今回の発表では、チーム規模の拡大に伴って効率的なアプリ開発や新規メンバーの受け入れを実施していく上で取り入れたエピソードを中心に紹介させていただきました。
まずはアプリ開発を進める上での設計パターンの方針策定です。
Sansan iOSアプリではVIPERアーキテクチャを採用しています。これによって解決したい課題は一般的なもので、「いわゆるFat ViewControllerからの脱却」「責務分割を明確にすることによるテスタブルな実装」を実現するためです。
詳しい内容は中川が別イベントで登壇した際の資料がありますのでこちらをどうぞ。
speakerdeck.com
その他にも新規メンバーの立ち上がりを加速させるための環境構築スクリプトの用意や本質的ではない箇所のコードレビューを自動化するSiderの導入、Deliver Botによるリリース作業の自動化等、この1年間で多岐に渡って環境の整備が行われてきました。
今回の発表の中で、Sansanの取り組みとして特徴的だったものとしては Bug Fix Day があります。
Bug Fix Dayとは、月に1回その日のプロジェクトの進行は取り止め、チーム全員で丸一日BugFix作業に挑む日のことです。
日々の開発の中で発見した(hotfix級でもない)バグをGitHubのissueとして書き残しておき、それらのissueをひたすら消化する形式で進めます。
Bug Fix Day当日の進捗管理はGitHub Projectsで行います。
GitHub Projectsではissueをカンバン管理のカードとして扱うことができるので
- 現在、誰がどのissueを作業しているのか
- 現在、コードレビューに上がっているissueはどれか
- どのissueが完了されたのか
カンバンのカラムからこれらを一目で把握できるのでとても便利なツールです。
おわりに
いかがだったでしょうか。
各社の開発プロセスの中で生じる課題に対してしっかりと向き合い、これからの成長を見据えた素晴らしい改善例だったと思います。また、各社の事例をより抽象的に捉えると、その殆どがiOSに限らず他のプラットフォームに対しても適用できる思想だと感じました。
これらの発表をまとめるにあたって、ばんじゅんさんが最後にお話しくださった内容が本質を突いていると感じましたのでその言葉をお借りします。
それはあくまで「改善はゴールではなくプロセス」ということです。
業務においてプロダクトを開発する本来の目的は企業のMissionを達成することや売上拡大です。その目的を達成するために開発という仕事が存在し、その速度を落とすこと無く継続して続けるための仕組みやサポートが必要となってくるわけです。
当たり前のことではありますが、正直耳が痛く感じることもありました。
今取り組んでいる開発や改善作業の目的を常々意識して取り組まねばと再認識するきっかけとなる良い勉強会になりました。
今回の勉強会で素晴らしい事例をご紹介いただいた今入さん、ばんじゅんさん、そして弊社中川も、本当に登壇お疲れさまでした！
buildersbox.corp-sansan.com
buildersbox.corp-sansan.com
buildersbox.corp-sansan.com
*1:ちなみにSansan iOSアプリの2019年の合計リリース回数は17回でした。Sansanでも今年から定期リリースを試みているので、そのリリース回数は増加すると思われます。
