鳥嶋氏の自己紹介

鳥嶋晃次氏:それでは始めます。(タイトルは)「サロンアプリの技術的負債解消への取り組み」です。

(まずは)自己紹介から。鳥嶋晃次と申します。DMM.com イノベーション本部オンラインサロン事業部プロダクト開発チームに所属しています。2022年にDMMに中途入社して、半年経ちました。よろしくお願いします。

(スライドを示して)本日のアジェンダはこちらです。オンラインサロンアプリにおける技術的負債、これまでの取り組み、負債と向き合うための取り組み、現在の取り組みと未来の話、まとめとなっています。

オンラインサロンアプリにおける技術的負債の状況

まず始めに、オンラインサロンアプリにおける技術的負債の説明をします。現状、オンラインサロンアプリの大きな技術的負債となっているのは、ReactNativeによるものとなっています。

歴史的背景によってReactNativeを採用して開発を行っていましたが、現状のチームではReactNativeで開発するメリットが少ないことや、今後もReactNativeで開発を継続していくと、ビジネス面、開発面、採用面などへのデメリットが大きくなってしまうという状況でした。スライドにも書いてあるのですが、決してReactNativeが悪いとかではないです。

過去のスライドはこちらに(リンクを)張ってあります。具体的にどのような選択をしたとか、ReactNativeを採用した背景などが詳しく書いてあるので、興味のある方はご覧ください。

ReactNativeからSwiftへの移行

次にこれまでの取り組みです。(現在)ReactNativeからSwiftに移行を進めています。

(まず、)Swiftで開発できるようにするための開発環境を構築しています。具体的にはビルド環境の整備、ReactNative側の整備などです。次に、Swift化を進める上での基盤を構築しています。アーキテクチャの選定を行い、DMM社内推奨アーキテクチャであるVIPERを採用しています。また、マルチモジュール化をし、ReactNativeとSwift間でのやりとりができる基盤を構築しました。

さらに、段階的にSwift化を進めています。Swift化は影響範囲が少ない末端の画面から進めていて、新規機能の実装時にはSwiftで実装をしています。こちらの内容に関しても先ほど紹介した過去のスライドで詳しく説明しているので、ぜひご覧ください。

直近の取り組み

次は直近の取り組みです。直近ではSwiftUIの積極的な採用を行っていて、Viewやコンポーネントの構築、新規機能における画面などを、積極的にSwiftUIで実装しています。

Swift化の初期段階で生んでしまった負債のリファクタリングも行っています。ViewControllerに責務を置いてしまったViewの振る舞いに関するコードをSwiftUIに寄せたり、ライブラリアップデートや、Cocoapodsを脱却して、Swift Package Managerに移行することを進めています。なかなか手を付けられていなかった開発環境に関する細かなメンテナンスや、CIのメンテナンスなども行っています。

負債と向き合うための開発チームとiOSメンバーそれぞれの取り組み

次は、負債と向き合うための取り組みです。まず開発チームでの取り組みとして、Human Interface Guidelinesの輪読会を実施しました。iOS開発に関わるメンバーでの共通認識を持ち、Swift化を進めていく上で、よりiOSアプリらしいUI/UXを提供できるような取り組みとして実施しました。輪読会を行ったことによって、デザインレビュー時に、エンジニア・デザイナー間で共通の言語で根拠のある議論をしやすくなりました。こちらの実施は非常に効果的だったと思っています。

次にiOSメンバーでの取り組みです。iOSメンバーでは隔週でミーティングを実施して、技術的にどのような課題があるか、他社の事例や競合・類似アプリの調査など、積極的に改善策を挙げてチームでの意識を高める取り組みを行っています。

また、事業部全体への展開も行っています。開発チーム内だけでなく事業部全体にスプリントレビューで共有をして、現在どんなことをやっているかなどを事業部全体に展開しています。改善系のタスクは成果が見えにくいところがあるので、開発者側から積極的に共有していくことを意識して取り組んでいます。

現在の取り組み

次に、現在の取り組みと未来の話をします。まず現在の取り組みとして、Swift化の取り組みを引き続き進めています。ReactNativeのコードが存在しない、プロダクトアプリとは別の、Swift製リファレンスアプリを作成しています。

具体的にはSwift Concurrencyの対応、Swift Package Managerでの管理ですね。あとはOSのサポートをiOS16以上を前提として、SwiftUIベースのアーキテクチャを選定しています。よりスピーディに機能をデリバリーできるようにするための、UI構築基盤の設計も行っています。

分析などでは、GA4をフル活用できるようにするためのデータ分析基盤設計を進めています。改善タスクでは、既存機能で改修が必要な箇所の洗い出しや、UIの見直しなどに加えて、仕様の再定義も行っています。

負債が解消されれば明るい未来が待ってる

未来は、技術的負債が解消されることによってReactNativeがプロダクトコードからなくなり、iOSエンジニアの本領が発揮できる環境になり、爆速開発ができるようになります。さらに、負債が解消されることで継続的に安定した品質を保ち、アプリ開発ができる基盤が形成されます。

アプリのデータ分析基盤が構築されて、よりデータに基づいた施策が実施できるようになります。新規機能がより開発しやすくなり、今まで以上に事業施策にコミットできるようになります。また、テストコードの充実や、採用面ではiOSネイティブなエンジニアを採用しやすい環境となります。(このように、)負債が解消されれば明るい未来が待っています。

チームで共通認識を持つこと、組織と情報共有することは大事

まとめます。技術的負債への向き合い方はいろいろありますが、チームで共通認識を持つことは非常に大事です。ReactNativeという技術は決して負債ではありません。負債はその時その時の状況で変わるので、柔軟に対応するべきです。

また、組織と共有することは非常に大切です。(みんなに)負債や負債に対する取り組みなどを知ってもらうために、技術者から積極的に発信をしていきましょう。楽しんでやったほうが、より良いものづくりになります。

以上です。ご清聴ありがとうございました。