はじめに
Amebaでネイティブエンジニアをしているshono（@BowyerApp）です。
本業では主にFlutterを書いています。
Amebaのネイティブチームは現在Android 9名、iOS 7名の体制で日々開発を行ってます。
昨年まではAndroidとiOSの人数差が大きく、OS間の機能差異を埋めるのが大変でした。
また、Amebaのアプリは約10年メンテナンスされているため、古いデザインが残っている画面もあります。
それらを解決するため、2021年からはKMMやFlutterなどのマルチプラットフォーム技術を用いたり、デザインシステムを導入することによってOS間の機能差異が出ないような仕組みづくりに取り組んできました。
この記事では、2021年にAmebaのネイティブチームが取り組んで来た課題と来年の展望について紹介させていただきます。
アクセシビリティ
課題
Amebaでは「100年愛されるメディアを創る」というビジョンを実現するため、誰もがいつでも、迷わず「書く」「読む」「応える」ができるサービスを目指しています。
これまで、
2020年、サイバーエージェントのアクセシビリティを振り返る
2021年、アメブロのアクセシビリティを振り返る
新卒配属後31件のアクセシビリティ改善をした話
といったアクセシビリティ改善を続けてきました。
アプリでは、「一部機能においてスクリーンリーダーを使用した時文字が適切に読み上げられない」などの基本的な課題や、施策として取り上げるべき課題などが存在しています。
私たちは、現状のAmebaのアプリのアクセシビリティに関する課題と向き合うために、アクセシビリティのチームを結成し日々取り組んでおります。
取り組んだこと
輪読会の実施
Amebaのネイティブチームはアクセシビリティについての基礎的な知識というものが足りておらず、何を持って理想状態とするかなどの土台がない状態でした。
そしてそれは同時にネイティブチームだけでなくデザイナー、Ameba外のエンジニアにも同様に言えることでした。
そのため、私たちはまずアクセシビリティの達成基準となり得るガイドラインから知識を得ることを決めました。
AmebaにはWebをベースとするアクセシビリティのガイドライン「Ameba Accessibility Guidelines」があります。これを隔週で開催される輪読にて読み合い、この内容はアプリではどのように適応できるのか、この内容はどのように実装に生かすことができるのかについて議論しました。
その様子や詳細についてはこちらの資料「Amebaアプリのアクセシビリティに関する取り組み」をご覧ください。
アプリでのガイドラインの適応
アプリにおけるアクセシビリティ実装の手助けをするために、Webのガイドラインをアプリ向けに落とし込む必要がありました。
Webのガイドラインの中で最も重要度の高いA基準の中でも、特にネイティブエンジニアに知っておいてほしい項目をフロントエンジニアと協力しピックアップしました。
その中でも、特にエンジニアに関連の深い項目については実装例を追記しました。
これらのアプリ向けの項目については、来年「Ameba Accessibility Guidelines」の方に追記される予定となっています。
ネイティブチームへのオンボーディング実施
Amebaのネイティブチームは、アクセシビリティの土台となる知識が足りていませんでした。
今回エンジニアに関連の深い項目についてのリストを元に、最低限知ってほしい知識としてネイティブチーム全体にオンボーディングを行いました。
オンボーディングの結果、アクセシビリティの最低限の知識を身につけられました。
今後PRのレビューにてアクセシビリティについての指摘を受けた時に項目について連想できる状態の土台を作ることが出来ました。
来年の展望
- 2022年3月：アクセシビリティチームよりレビューを行い、A基準において実装が定着する状態
- 2022年6月：アクセシビリティについてネイティブチーム内で自然とレビューされている状態
- 2022年9月：CIやテストなどによってアクセシビリティが自然と担保、改善される状態
デザインシステム
課題
- デザインシステムのアップデートに対して iOS/Android の実装が追従できていない
- デザインシステム導入前の古いデザインのComponentやColorを利用している箇所が大量に存在する
上記理由によりデザインシステムを実装に落とし込むワークフローを整え、デザインシステムの進行に対してアプリの実装状況を可視化する必要がありました。
取り組んだこと
ワークフローの整備
- チームでデザインシステムに追従するためのタスク消化が行える運用の整備
- 案件ごとに iOS / Android のエンジニアが最低１人ずつ張り付く体制
- チケット運用
- 定例で進捗やissueの吸い上げ
デザインシステムに追従する準備
- 現状のデザインシステムで定義されているComponentsの実装状況と実装優先度の選定
- PRレビュー時や実装時にデザインシステムに準拠できているのか判断できる材料の選定
- デザインシステムで定義した Color を token化し .xml, .swift で扱えるように整形
来年の展望
- 2022年3月: 実装優先度が高いComponentsを実装しプロダクトコードに反映する
- 2022年6月:人力で行えるようになる想定のPRレビュー時のデザインシステム準拠に準拠しているかの判断をLinterに落とし込む
- 2022年9月: デザインシステム導入前の古いデザインを一掃する
- 2022年12月: デザインシステムとアプリ実装が足並みを揃えて動ける状態とする
KMM
Amebaアプリは長年運用してきたサービスであるためOS間で仕様差異が生まれてしまっています。
その状況の打開も含め、以下のようなネイティブ開発における理想状態を考えました。
- Amebaアプリの開発に携わる中で技術的成長や挑戦ができている
- Android, iOSの垣根を超えた視野を持って業務に取り組むことができる
- ネイティブエンジニアのリソースを最大限発揮できる環境ができている
理想状態の実現に向けて、運用中のサービスへの適用が比較的容易なKMMでのロジックの共通化を目指しています。
取り組んだこと
- Androidの一部機能の置き換え
- GitHubPackage経由でAndroid用ライブラリを配信する機構の整備
- KMMリポジトリのブランチ運用ルールの策定
- 共通ロジックの開発手法の選定
- 置き換えロジックの整理
上記取り組みを行ってきました。まだ共通化に向けての環境整備などが主ですが、これから順次ロジックの置き換えを行っていく予定です。
来年の展望
- 2022年3月: Android, iOS共に一部機能がKMMで置き換わっている状態
- 2022年6月: ネイティブチーム全体への展開、開発フローに組み込まれている状態
- 2023年3月: ビジネスロジックが全てKMMで実装することができている
DevOps
課題
- チームやサービスのパフォーマンスレベルが定量的に把握できないため改善のサイクルを回したり、パフォーマンスの低下を検知することができない
- 継続的にパフォーマンス・品質を高めるための仕組みがない
上記理由によりチームやシステムのパフォーマンスを最大限に引き上げるための基盤・仕組みを作る必要がありました
取り組んだこと
DevOpsでは以下の３点を軸に取り組んできました
Firebase活用
Firebaseを活用し、様々な情報を収集しそれを可視化することでチームやサービスの状態を把握できるようにしました。
具体的にはチームパフォーマンスを図る指標（デプロイ頻度・リードタイム・MTTRなど）、サービスパフォーマンス（記事表示成功率・投稿成功率・メモリ使用量など）といった監視対象の指標を定義し、重要度の高いものから少しずつFirebaseにイベントとして送信し、そのデータを可視化しています。
そして毎月上記指標について振り返りを実施し、改善が必要な点についてチームに呼びかけています。
NoCrash検知
クラッシュする不具合はCrashlyticsで検知していましたが、クラッシュはしないもののアプリの体験上支障が出るような不具合を検知する仕組みがなかったため、そういった不具合に対しても即座に検知し対応できる仕組み作りを行ってきました。
その第一歩としてAPIエラーやライブラリエラーなどアプリでハンドリングしているエラーイベントを洗い出し、発生時にFirebaseに通知するようにしました。現在はまだ通知するだけですが、今後各イベントに対して閾値を設け、閾値を超えたらアラートを発報するといった仕組みも用意する予定です。
デグレ検知
リリースの際QAチームによるテストを１週間行っているものの、１週間の限られた期間の中で手動で確認できる範囲は限界があり想定外のデグレを見つけることが困難であったため自動試験による品質担保が出来ないか検証を進めています。
E2Eのテストコードを手動で組むのは導入・メンテナンスに膨大なコストがかかるため、ノーコードでE2Eテストを組めるサービスを活用することで低コストで運用できないかということでAutify for mobileのトライアルに参加しiOSについて先行で検証を開始しました。
来年の展望
- 2022年3月: 全指標の可視化が完了している状態
- 2022年6月:
- 指標の振り返り・改善のサイクルがチームに定着している状態
- NoCrashな不具合を即座に検知できる状態
- 2022年9月: iOSアプリのリグレッションシナリオが構築され運用が開始している状態
アプリ内課金
2021年10月にAmebaアプリにおける新機能として、ブログの読者がブロガーに対してメッセージを載せたチップ・投げ銭を送ることができる「応援」機能が実装されました。この応援機能ではブラウザ版ではクレジットカードを用いた決済を採用していますが、Android / iOSアプリ双方でスムーズな購入体験を可能にするため、Google Play Billing Library / StoreKitを用いて「Amebaアプリコイン」という新しいサービス内通貨を実装し、それを管理するウォレット機能を加えることで応援機能で行うアプリ内課金のフローを実現しました。サーバサイドについては弊社独自の決済基盤と接続している形で、各プラットフォームの課金情報を統括して管理するシステムになっています。
今後の課題・来年の展望
プラットフォーム課金機能のアップデートへの追従
Android向けのGoogle Play Billing Libraryは現在4.0がリリースされているように毎年Google I/Oのタイミングでメジャーアップデートの告知が行われ、iOS向けのStoreKitはWWDC 2021でStoreKit2が告知されるなど、プラットフォームが用意する課金機能はアップデートが頻繁に行われます。これらの機能に対しチームレベルでアンテナを張り続けることで柔軟に追従し、「忘れた頃に痛みを伴いながら数段飛ばしのアップデート作業をする」ようなことがないようにしていく必要があります。
「Amebaアプリコイン」の利用用途の増加
現状では「Amebaアプリコイン」は「応援」機能のためのサービス内通貨として機能しています。ですが、今後のAmebaの事業展開次第で「Amebaアプリコイン」の利用用途が発生することが考えられます。それに備え、機能面・実装面双方で利用のしやすい「Amebaアプリコイン」の実現を目指していきます。
本棚アプリリニューアル
現在Amebaのサービスの1つであるAmebaマンガのアプリをリニューアルしています。2022年1月にリリースを予定しております。
※Flutterに関して興味がある方は先日公開された9プロジェクトが同時に走る サイバーエージェントのクロスプラットフォームアプリ開発2021もご覧ください。
課題
- AmebaマンガはWebメインのサービスなのでWebの改善が先行していた
- 本棚アプリ開発のエンジニアメンバーが居なかった
上記理由により、Webとアプリの差分が激しくなってしまっていました。
取り組んだこと
今後のメンテナンス性を高めるため、既存のiOSとAndroidアプリをFlutterで書き直すことにしました。そうすることで、少ないエンジニアリソースでも開発に耐えられるようにしました。
リニューアルの体制
Android2名、iOS1名で開発しています。
アーキテクチャ
MVVM+Clean Architecture
本棚アプリリニューアルはAmebaのAndroidエンジニアで開発しています。
Android界隈では、2021/10/20時点でMVVMが推奨されており、AmebaアプリのAndroid版もMVVMを採用しています。
MVVMであれば、AmebaのAndroidエンジニアが新たにアーキテクチャを学習する必要がないので採用しました。
どうやって進めていったのか？
- モックづくり
- 初期メンバーはFlutter未経験だったため、flutter-architecture-blueprintsを参考に既存アプリのモックを実装していきました
- ドメインモデル、ER図設計
- 出来上がったデザインからドメインモデルに落とし込む作業を行いました
- 本実装
- エンジニアの体制づくり
- Flutterの基礎、採用したアーキテクチャなどをまとめたオンボーディング資料の作成
- 11月よりiOSエンジニアがジョインし開発を始めました
来年の展望
今後はOS関係なくAmebaのネイティブエンジニアがメンテナンス出来るような体制を整えていく予定です。
Amebaの採用に関する取り組み
課題
Amebaのカジュアル面談では
- カジュアル面談なのに面接っぽくなってしまっていた
- サービスが多く、担当者によっては他サービスの事に答えることが出来なかった
といった課題があり、貴重な時間を割いてカジュアル面談に来て下さった応募者に対して、弊社の良さを伝えきれていませんでした。
取り組んだこと
- 応募者に事前アンケートを送付し、カジュアル面談で弊社に聞きたいことをヒアリング
- 弊社が抱える各プロダクトの魅力をMiroにまとめ、面談中に画面共有する
といった施策を行いました。
Miroを使ったカジュアル面談を初めてからは、応募者の方から「各プロダクトについて分かりやすかった」「聞きたかったことが全て聞けた」といった反響を頂けております。
カジュアル面談をテコ入れ出来て、とても良かったなと感じております。
※2021年10月末よりAmebaでもMiroを活用したカジュアル面談を行っております。
カジュアル面談におけるMiroの活用は株式会社ZOZO様の手法をインスパイアさせていただきました。この場をお借りして改めてお礼申し上げます。
まとめ
2021年にAmebaのネイティブチームは、安定した状態でより早くアプリをリリースするための土台づくりが出来たかなと思っています。
2022年はこれらの土台を活かして安定したアプリ開発が出来ると信じています。
僕が所属するAmebaのネイティブチームの取り組みに、少しでも興味がありましたらぜひご応募ください。
Ameba Androidエンジニアの募集ページ
https://hrmos.co/pages/cyberagent-group/jobs/0000766
Ameba iOSエンジニアの募集ページ
https://hrmos.co/pages/cyberagent-group/jobs/0000765
カジュアル面談も行っていますので、ぜひ参加お願いします。