Hello Globee! abceed iOS開発事情

自己紹介

こんにちは、5月から正式にGlobeeにjoinしました。アプリエンジニアをやっています、鈴木　俊裕です。今のところiOSをやっていますが、Androidもそのうちやることになりそうです。

アプリエンジニアの経歴としては、SIerで少人数チームの受託開発から始まり、自社サービスの大人数チームでの開発経験があります。しかし振り返ると少人数x自社サービスを経験したことがなかったため、今回事業分野はそこまでこだわらず転職活動しました。

入社動機を簡潔にあげると、「メンバーの人柄」「事業が伸びている」「自社サービスのスモールチーム」です。すごく個人的な印象なのですが、メンバーは塾の先生っぽい人が多いかもしれません。学生の頃、塾で勉強することは結構楽しかったタイプなので、そういう部分でも合っているのかもしれません。

さて今回は技術者として入社して感じたことを通して、abceed（エービーシード）のiOSアプリ開発の様子をお伝えできればと思います。

技術者目線での事業の特徴

ユーザー文化

事業のことで一番驚いたのは、ユーザー文化です。

ユーザーの方は大半が「勉強しよう！」という前向きなモチベーションで来ていただいてるので、落ち着いている方が多い印象です。アプリ内にバグや誤植の問い合わせ機能があるのですが、問い合わせ内容も丁寧なものが多いです。「修正よろしくお願いいたします」「いつも助かってます！」といった声をいただきます。

やはりそういう良好な関係ですと、作る側としても全力でいいものを提供したいという気持ちになれるような気がします。「私が入ったからには、ぜひユーザーの皆さんの期待を裏切らないよう頑張っていきたい」と勝手に意気込んでおります。

技術ドリブンの顧客目線

これも驚いたのですが、私が入った時点ではビジネス職は人事だけでした。他は全員技術者です。Globeeは技術の会社なのです。社長もデザイン業務をやっていると面接で聞いていたのですが、本当でした。よく作り込まれているSketchのデザイン定義がありました。すごい。

私自身が機能の要件に関わっていくのはこれからかなと思いますが、技術者が責任を持って主導して行ける環境だと思います。

コードベースの印象、設計

選考の段階で課題感など色々と伺って想像はするわけですが、実際のコードベースとご対面するとやはりいい意味で色々と驚くこともありました。色々と包み隠さず書いてみたいと思います！

4年間で蓄積された10万行のコードベース（多機能！）

まずはコード量に圧倒されました。abceedアプリは既にかなり多機能です。教材がバラエティに富んでいるのでいろんな種類の学習画面がありますし、さらに一つの教材についても様々な学習スタイルを選択できます。

こんなアプリをAndroidも含めてほとんどCTOひとりで作ってきたというのが信じられません。凄すぎ。

テストゼロ！

スタートアップあるあるかもしれませんが、現状テストコードは一切ありません。
正確には2ファイルだけあったのですが、ターゲット自体のビルドが通らないまま半年以上放置されていました。
原因はPodfileの定義の仕方とかそういう部分だったのですが、Xcodeのビルド設定って慣れてる人でもハマりがちなので、致し方ない部分だと思います。

Clean Architecture

「10万行でテストがないのヤバそう」って思いましたか？私も思いました。しかし実際に開発をしてみると、意外と開発するときの負担が少ないです。

アプリの設計としてClean Architectureを採用しているので、実際コードの分け方がクリーンになります。ViewControllerがFatになっている部分もありますが、それでも重要なロジックはUseCaseクラスにまとまっているので、読みやすいです。

テスタブルにしなくても、適切な設計ポリシーを決めておくことで開発効率は担保していけるんだという学びを得ました。

CTOの過去の英断に感謝しかありません。

ただ品質のことも考えると、もう少しちゃんとテストを書いていかないとねという話をCTOとしています。幸い上述の通りコードは分かりやすくまとまっているので、protocol化をしてDIするだけで割と簡単にテスタブルにできそうだなと思っています。

ちなみにこの辺りのProof of Conceptとして作ったプロジェクトがありますので、興味ある方は覗いてみてください。コーディング試験の時に作って、今でもたまにちょっとした検証を追加したりしています。最終的にはこんな風にできたらいいなーとか妄想してます。
https://github.com/toshi0383/abceed

Flutterどうですか？

画面数が多いとはいえ、シンプルな画面構成も多いので、FlutterやReactNativeの導入は検討しないのか？と面接の時に聞いた記憶があります。

私自身Flutterには可能性感じてますし好きなので野望はあるのですが、10万行のコードベースを一気に移行するのは現実的ではないかなと感じてます。ただ他のメンバーもそういう新しい技術には前向きな人が多い印象ですし、CTOとも「ハイブリッドで一部画面で導入等は今後あり得そうですね」という話にはなって、実際に検証の時間をもらっています。

今後もしかしたらそういった試みもご紹介できるかもしれません！

開発フロー

GitHub Issue駆動開発

開発フローに関しては、ちょうどGitHub Issue駆動開発の立ち上げをしているところです。開発Issue専用リポジトリを設けて、Android,iOS,Web,Serverといった全てのIssueをそこに集める形にしようかという話をしています。

これは個人的にflutter/flutterのIssue管理を参考にさせてもらってます。Flutterの場合はProjectも100以上、ラベルも200以上あり規模が全然違うのですが、クロスプラットフォームでの課題管理という面ではとても参考になります。

この辺りはまた重要な知見があれば記事にしたいと思います。

masterベース開発

ブランチはtrunkベース開発ライクな方式です。`master`はいつでもリリース可能な状態を保ち、PRは基本全て`master`か`feature/*`に向けます。リリースも`master`で行い`tag`を打つので、hotfixをする場合はそこから始めることができます。

自分はだいたいこの方式に落ち着いてしまうのですが、個人的にはブランチの数が少なくてハッピーだと思っています。

リリースの自動化

リリースはこれまでCTOがXcodeを使って毎回手作業でやっていたのですが、流石に負荷が大きいので自動化を進めています。

iOSアプリのリリースフローは毎回悩むのですが、一般的には以下のような課題に悩まされると思います。

- リリース文言の更新が自動化しづらい(担当がビジネス職だったり)
- 並行して異なるバージョンを申請準備できない
- アップロード後の検証処理が終わるまでバイナリの操作ができない

この辺りのいろいろな条件に対しても柔軟にフィットするソリューションが求められていると思います。

一旦、バイナリのアップや新しいバージョンの作成などは自動化しましたが、今後時間をかけて、組織に最適なワークフローを模索していければと思っています。

まとめ

以上、abceedのiOSアプリの開発について簡単にまとめてみました。
今後も継続的に開発環境を改善していきたいと思っています！

そういえばこの状況ですので、3月の面接以来一度も出社していません。開発マシンのiMacも自宅に送ってもらいました。リモート入社は初めてだったのでやはり最初慣れるまでは心細い部分がありましたが、今ではすっかり慣れてしまいました。3歳の娘がいるので家の中は騒がしいですが、一応書斎があるのでなんとか集中する時間を長めに確保できていると思います。

以下、募集になります。ご興味あれば気軽に声かけてください！よろしくお願いします。