本記事は、22卒1年目の成長シリーズ 10日目の記事です。

はじめに

はじめまして。2022年に新卒としてABEMAにジョインした四宮(@1125__rui)です。ABEMAのAndroidアプリケーション開発に携わっています。
本記事ではAbemaTVにジョインしてからの1年間を通して、成長した部分・直面した課題について振り返っていきます。

ABEMAについて

ABEMAの紹介画像
「ABEMA」はテレビのイノベーションを目指し”新しい未来のテレビ”として展開する動画配信事業。登録は不要で、国内唯一の24 時間編成のニュース専門チャンネルをはじめ、オリジナルのドラマや恋愛番組、アニメ、スポーツなど、多彩なジャンルの約20チャンネルを24時間365日放送しています。
また、オリジナルエピソード数は国内発の動画サービスで日本 No.1(※1)を誇り、総エピソード数は常時 約30,000 本以上を配信。ほかにも、注目の新作映画、国内外の人気ドラマ、話題のアニメなど豊富なラインナップの作品や、様々な音楽や舞台のオンラインライブも展開。テレビ、オンデマンドなど、時間に囚われることなくいつでも作品をお楽しみいただけるほか、スマートフォンや PC、タブレット、テレビデバイス、Nintendo Switchなどで、場所に囚われることなくライフスタイルに合わせて番組を視聴いただけます。
さらに、月額960円のABEMAプレミアムに登録すると、限定コンテンツの視聴や「動画ダウンロード機能」「見逃しコメント機能」など「ABEMA」の全ての機能が利用でき、「ABEMA」をよりお楽しみいただけます。
(※1)2022年1月時点、自社調べ

1年間の業務内容

1年間の業務内容
2022年は回遊体験の向上施策や新機能のABテストなどのアプリケーションのグロースに関わる部分を担当するサービスグロースチームに所属していました。
サービスグロースチームではコンテンツ視聴面の回遊体験向上施策や既存画面の新旧アーキテクチャ・API移行、「FIFA ワールドカップ カタール 2022」に関する開発などに携わっていました。

現在はプレミアム会員などの課金に関する部分とライブ配信に関する部分を担当するスポーツライブ・課金チームに所属しています。スポーツライブ・課金チームでは新規施策に対しての課金機能の設計・実装やAndroidTVの課金部分の実装に携わっています。

直面した課題

2023年の1月から課金とライブ配信をメインとして扱うチームに移動し、Androidエンジニア2名で新規施策に対しての課金体系の仕様策定~実装を行うことになりました。

新規施策としてプロダクトの中に課金機能を新しく組み込む際にはさまざまなケースを考慮する必要がありました。たとえば、購入中にアプリケーションが終了した場合やPlayStore側での決済には成功したが、アプリケーション内部でうまくアクティベートできなかった場合などです。

また、ABEMAのAndroidアプリケーションは現在CleanArchitectureをベースとした設計(※2)になっているのですが、課金領域のコードは古くFluxベースでの実装が行われているものでした。
さらにその中にはいずれ消えることが決まっているものもあるのでそこも加味し、新規実装を行う際に、Fluxベースの部分を全てリアーキテクチャし新しい設計へ沿わせるのか、削除する予定の部分を残し一時的に新旧のアーキテクチャが共存する形を作るのかを踏まえた上で設計・実装を行う必要がありました。

(※2)ABEMAのAndroidアプリケーションにおけるアーキテクチャは以下を参照ください

課題に対してどう向き合ったか

仕様策定段階に入る前の前調査として、2段階に分けて課金ドメインのキャッチアップと既存影響・エッジケースの洗い出しを行いました。

    1. 公式ドキュメント・サンプルを読んで試す

まずはGoogleが用意してくれている公式ドキュメントサンプルリポジトリを見ながら、自分なりに整理するところから始めました。ここでは「エッジケースを考慮しながら試す」というのを意識していました。

前述の通り、プロダクトに課金基盤を組み込むには考慮するべきエッジケースがたくさんあります。このエッジケースを事前に防ぐ仕組みや、起こってしまった際のフォールバックを整備する必要があり、ここを仕様策定のタイミングでPFを挟んで決める必要があります。

    1. 影響・懸念がありそうな部分を洗い出してまとめる

実際にABEMAのコードを読みながら依存関係とシーケンスをUMLで書き起こしました。新規実装する際に影響がありそうな場所、例えば課金の状態を利用している部分などに着目しながらシーケンスを追いつつ、ログを出している部分をマークしておくことでデバッグの時にチェックするべき場所をまとめました。

結果として、仕様策定の段階でAndroid観点から懸念や影響範囲、実際に起こり得るエラーケースや購入状態の復帰などについての意見を出すことができ、スムーズな仕様策定を行うことができました。
また、QAを通してのテスト時に発覚したバグの早期修正やCS対応の方針策定などにも寄与することができ、思わぬ副産物も得ることができ思った以上の効果が得られました。

まとめ

1年前と比べるとかなり視野が広がり、自分の立ち位置が見えてきたと感じています。1年目から持つ裁量が大きく、やりたいこと・興味があることには手を挙げれば関われる環境にとても満足しています。

2年目はAndroidから視野を広げてMobileエンジニアとしての振る舞いを目指しつつ、自身が所属するチームを代表するエンジニアとして名乗れるようになるという目標に向けて様々なチャレンジをしていきたいと思っています。