はじめに
こんにちは！5月中旬から5月末までの3週間(水木金の間)、FANBASE事業部でFlutterモバイルエンジニアとしてインターンシップに参加しました、赤星光誓(Wantedly, Github)です。現在は大学4年生として都内にある仏教系の大学で仏教学を勉強しています。
学業では、仏教学を勉強しています。実家が寺院ということもあり、お坊さんコースを進んでいます。エンジニアとは全くの対偶の境遇・環境であり、スイッチの切り替えに混乱してコードの中にお経を書いてしまったりすることもあります。
エンジニアとして普段は、別のスタートアップでモバイルエンジニアとして働いています。Flutterの実務歴としては2年程となりますが、スタートアップのような少数での開発とは別にサイバーエージェントのような大規模な会社では、どのように開発をしているのか気になったのがきっかけで、今回のインターンシップに参加しました。
インターンシップのスケジュール
5月はゴールデンウィークで1週目がなく、さらに週3の就業という限られた時間でしたが以下のように活動しました
- 1週間目の活動
様々な手続きや環境構築
既存コードのアーキテクチャ変更リファクタリング
- 2週間目の活動
Flutter 3.10.x対応
- 3週間目の活動
loggerの導入 既存Crashlyticsとの統合
与えられたタスクと成果
・既存コードのアーキテクチャ変更リファクタリング
リファクタリング中のプロジェクトということもあり、大きく分けて3つのアーキテクチャが混ざり合っているようなコードになっていて
対応が済んでいないページのリファクタリングを行いました。
アーキテクチャのリファクタリングでは、各々のアーキテクチャを正しく理解していない状態では修正も何もないので、コードリーディングに多く時間を割きました。現状コードの3つのアーキテクチャは、どれも自身が触ったことのないものでしたが、新しい記述部分・共通部分・不要な部分を適切に理解し、ロジック・UIに差異が出ないように対応させることができました。
また、初見でアーキテクチャを見た時、「果たしてこんなに複雑にする必要があるのか？」という風に思ったのが素直な個人的感想でした。
ですが、リファクタリングを通してアーキテクチャを理解していく中で、複雑性を持っているからこそ対応することができる部分があったり、DIのしやすさなどが考えられているコードだなと思う部分が何度もありました。それらを通して感じたこととして、複雑なのには適切な理由があると強く感じました。
・Flutter 3.10.x対応
私がインターンシップに入った、ほとんどちょうどのタイミングでDartの言語機能が向上するアップデートとFlutterに新しいレンダリングエンジンが入るアップデートという、かなり大きめな出来事がありました。
安定性も含めてサイバーエージェント内での別Flutterチームでは、今回のアップデートに追従するのは、少し先だろうという状況がありました。ですが、だからこそ先陣を切って自チームでやろうと話がまとまり、そのタスクを私が担当することになりました。
詳しくは割愛しますが
- 新バージョンに伴いアップデートした各パッケージの動作確認
- 非推奨となった記述の修正
- 言語機能アップデートに伴い追加された新しい記述法の部分的導入
- 新レンダリングエンジン「Impeller」の調査
- 全体の動作チェック
などなど、関連する全タスクを網羅的に担当させていただきました。
結果として、インターンシップ期間中にPRのmergeまで持っていくことができました。
スタートアップでは比較的簡単に新バージョンへの追従はできましたが
今チームにおいて、「大丈夫な気がする」のような状態ではリリースすることができないので
アップデートにまつわる多くの考慮点を適切に対応し、安心できるレベルまで検証・修正をするのが苦労した点です。それらを通して、大きな会社として、どのようなアップデートに対応していくのかを学びました。
・loggerの導入 既存Crashlyticsとの統合
FANBASEの開発チームでは、主要な機能に集中して実装していたため、必要とまではギリギリ言えない機能の整備が遅れていました。具体的な例として、ログ出力機能（logger）やクラッシュレポートツール（Crashlytics）の実装が不十分でした。チーム内では、この要望は以前からあったものの、優先度の低さから対応が難しい状況でした。私はSRE的な面にも興味があり、この問題に対応したいと提案し、その結果、タスクとして引き受けることができました。
具体的に行ったことは以下のとおりです
- logger表示のために必要なパッケージ選定
- 既存のlogger的システムとの互換性を保たせたlogger実装
- loggerを通してCrashlyticsへのError送信実装
- Flutter外のエラー監視ツールにログ送信実装
- DIを意識したエラー監視ツール連携実装
などなど広く実装をしました。
パッケージ選定は普段はなんとなく上位にでる物を使って、ダメだったら変えるということをしがちです。ですが今回は、各パッケージを慎重に比べ、今回のユースケースやチームとして何が適切かを明確に考え選定をするという業務を行いました。
まとめ
・チームマネジメントの重要性
インターンシップとして経験した中で、チームマネジメントが面白いと感じました。特にスクラムを使ったチーム運営が印象的でした。最初はスクラムやアジャイルについてあまり理解がなかったのですが、「スクラムほどのルールが必要なのか」と疑問に思っていました。
しかし、実際にスクラムを経験してみると、なぜ多くの人がスクラムを重視するのか少し理解できるようになりました。特に週1回のレトロスペクティブ（振り返り）が良かったです。チームの人数が増えると、各メンバーの役割や貢献が分かりにくくなり、チーム全体の結束力や関係性が弱まることがあります。その結果、個々のモチベーションや仕事の進捗にも影響が出る可能性があります。 レトロスペクティブでは、各チームの成果を報告し、お互いに褒め合う機会があります。仕事に関することだけでなく、他のことについても共有します。このようなプロセスを経て、チームが団結し、高い結束力を保つことができると感じました。
・3週間の成果と学び
合計で10営業日という短い期間ですがサイバーエージェントの開発を体験し、様々なことを感じ・学びました。今までスタートアップという規模で開発を続けてきた中では、出会わなかった要素・問題に何度もぶち当たることができました。
特に感じたこととして「サイバーエージェントは怖くない！」と感じました。
短いインターンシップでしたが、FANBASEチームやインターンシップ参加までお世話になった人事の方々、ランチなどなどで関わった方々、皆さん本当にありがとうございました！
サイバーエージェントという会社に怯えている学生の皆さんに「怖くないよ！」と残してこの記事を終わりにしたいと思います。