Babylon社の思い出

Yasuhiro Inami / @inamiy

前回の日記の続き。

先週の契約打ち切りの通達から1週間。
抱えている残タスクの引き継ぎを済ませ、最後の別れの挨拶をもって12月27日付でBabylon社を退職した。
割とあっけなく会社からフェードアウトした気がする。
このクリスマス時期、イギリスやEU圏の人々は、年始まで休暇をまとめて取る人が多く、最終日のSlackには、チーム全体の半数程度しか参加していなかった。
そのため、全員にきちんと挨拶回りができなかったことが心残りであった。
が、それでも少なからずの同僚が、私の退職を名残惜しんでメッセージをくれて、それが何よりも嬉しかった。
後日談によると、どうやら私の同僚からの評判が悪いとか、仕事ぶりに問題があったわけではなく、エンジニアよりも上層部からNOが出たらしい。
（詳細な理由はここでは省くとして）ひとまず私個人の技術力不足が原因ではなさそうという結論に、少しばかり安堵した。

しかし、この10ヶ月間のBabylonでの充実したiOS開発生活を振り返ってみると、やはり後ろ髪を引かれる思いは強い。
取り扱っている技術スタック、開発文化、組織体制など、どれを取っても学ぶことが多かった。
以下では、（インターネット上に公開されている範囲内で）その取り組みを簡単にまとめてみる。

技術スタック

- ReactiveSwift (FRP)
- Bento (Virtual View)
- ReactiveFeedback (Automaton)

Babylonで使われている代表的なフレームワークは、主にこれらの3つ。
いずれも、自社またはコアコントリビューションしているレポジトリである。
基本構成は、FRP + Virtual View + Automaton の MVVM で、さらに Flow Controller を加えた画面遷移が設計されている。

参考： Babylon iOS Architecture

この辺りの設計は、最近流行りの兆しが見え始めている(?) SwiftUI + Composable Reducers (Elm + Optics) の先駆けとも言え、私が以前 iOSDC で発表した内容にも近い。
しかし当時の私は、扱いが厄介なUIKitを利用しながらVirtual Viewを実装する発想がなかったため、プロダクションレベルできちんと動作するBentoを見たときは、いたく感心してしまった。
このように、サードパーティ製に頼らずとも自作して問題解決ができるエンジニアたちに囲まれながら切磋琢磨できたことは、とても貴重な経験であった。

他にも、Unit Test + UITest + SnapshotTest を完備していたり、SDKフレームワークの切り出しや国別アプリといった複雑なモジュール依存を管理・疎結合化するプラクティスを学ぶことができ、今後の糧になった。

開発文化

とにかく透明性の高い開発チームだった。
前述の ios-playbook レポジトリがあるように、特にiOSチームは、「社内秘でない技術情報・提案は積極的にオープンにする」カルチャーがあったため、社内Wikiをほとんど使わず、共有したい情報のほぼ全てをGitHub上に載せて、レビューを重ねながら内容を徐々に充実させていった。
ここで、「GitHub上で資料のレビューをする」という方式が思いのほか大きく、使い慣れたインターフェース上で差分に対して適宜フィードバックを送ることは、何もソースコードに限った話ではなく、ドキュメンテーションの管理と更新においても大いに役に立つ。
なお、レビューには最低2人の承認が必須というルールがあり、資料を書いた本人以外にも情報が伝わって、サイロ化が防げる点も良い。
また、一度書いた古い文章は、他のエンジニアの手で修正されることが多い。
このオープンな Playbook 文化は、どこの会社が最初に始めたのか定かではないが、OSS文化が好きな私にとって、非常に面白い試みであった。
日常の業務風景の一部をそのまま切り取るように、気軽に文章を書いてはフィードバックを受けながら改善していく。
このスタイルは、サービスの継続的開発の手法にも似ていて、書き手の心理的安全性が担保される良い取り組みだと思う。

他にも、4〜5人でグループを組み、お互いのPull RequestをZoom上で口頭レビューし合う時間や、雑談タイムを設けてコミュニーケーションを促進するなどの小さな工夫があり、リモートワークで心細くなるような心配は全くと言っていいほどなかった。
つい先日まで、現地の同僚とZoomの壁紙でバカ遊びしていたくらいである。
今となっては遠い昔の出来事のようで、懐かしくさえ思える。


組織体制

いわゆる Spotify 風のアジャイル開発スタイル (Squad, Tribe, Chapter) を会社全体で採用している。
合計15種の Squad から成り、1 Squadあたり 1〜5人のiOSエンジニアが所属。
テーブルもフロアも異なる場所で、各自がSquad内で協働し、担当業務にフォーカスする。
iOSエンジニア全員が集まって話せる場所は、基本的にSlackやZoomといったオンラインのみ。
ちなみに、私が最後の方に所属していたPlatform（インフラ基盤）チームでは、主にモジュール細分化とビルド改善のリファクタリングを担当していたので、いちSquadというより、各Squadに点在したiOSエンジニアの業務全体を見渡して設計提案をするChapter的な位置づけだったように思う。

このアジャイル方式で良かった点としては、

1. プロダクトオーナーとの距離が近くなるため、Sprint計画や振り返り (Retro) を含めたコミュニケーションが円滑に進む
2. 少人数でミーティングができる
3. 他分野のエンジニア (Android, Web, Server-side) との技術的交流が増える

また、リモートワーカーにとってフロア等の物理距離は関係ないため、アジャイル開発とはとても相性が良かった。

終わりに

以上、取り留めの無いまとめではあったが、今後は、彼ら以上の設計技術やサービス開発に取り組んでいけるかどうかを、当面の目標にしていきたい。
一時は、十分満喫したエンジニア生活から離れて、全く違う路線に進んでみようかという気持ちになったが、やはり目標を定めると次の方向性が見えてくる。

この記事が気に入ったらサポートをしてみませんか？