こんにちは！2023年4月に新卒入社したtatsubeeと申します。現在はpixiv事業本部アプリエンジニアリングチームでpixivのiOSアプリを開発しています。
9月に完全招待制のカンファレンス「PIXIV MEETUP 2023」が開催され、その中でライトニングトークとして「pixiv-iosを破壊したい」というお話をしてきました。
この記事ではスライドだけでは伝わらない、トークに乗せた思いを綴っていきます！ぜひスライドと併せてご覧ください！
pixivのモバイルアプリについて
pixivはWebサービスだけでなく、モバイルアプリケーションもiOS/Androidともに公開されています。
pixivのiOSアプリは2009年12月9日に、Androidアプリは2010年7月9日にver1.0がリリースされました。もう10年以上運用されている歴史あるアプリです。
しかし10年以上運営されているとはいえ、まだまだ「完成されたアプリ」ではありません。
新卒1年目だからこそ、いちユーザーとしてpixiv-iosには改善してほしいと感じる機能がありますし、アプリエンジニアリングチームとしても、今後実装すべき機能、改善すべき体験は多々あり、またモバイルアプリだからこそ実現可能なpixivの体験を追及する必要があると考えています。
pixiv-iosの課題
上で述べたようにpixiv-iosには今後実装したい機能・改善したい体験がいくつかあります。
モバイルアプリとして最適化できていない体験の具体的な例として、投稿作品の編集機能が挙げられます。作品の投稿画面はネイティブなUIで作られていますが、編集機能はWebが表示されます。
このように、統一感がないなどの問題に対し「致し方なくこうなっている」という仕様がいくつかあります。
これらの課題に対して迅速に取り込んでいく意向はありますが、アプリの内部品質に関する課題のために開発効率が落ち、実装・改修に時間がかかってしまう状況となってしまっています。
開発の障害となる内部品質に関する主な課題点は以下の3つとなります。
- 密結合で、変更の影響範囲が大きくなりやすい
- メンテナンスされていないライブラリに依存している
- 独自実装が複雑化し、コードの可読性が低下している
これらの課題のうち、「密結合で、変更の影響範囲が大きくなりやすい」課題について解説します。
密結合で、変更の影響範囲が大きくなりやすい
iOSアプリに使われるアーキテクチャとしてよく見られるものにMVVM・Clean Architecture・The Composable Architecture等ありますが、pixiv-iosではアーキテクチャが明確に定まっていません。そういった要因もあり、UIとロジックの結合度が高くなっている、XXManagerのような多機能なクラスがプロジェクト内の様々な場所に散見されるなど、関心の分離ができていません。
そのため、一機能の改修を目的としたコードの変更であっても、その影響範囲が想定以上に広がってしまうということが見受けられます。
このように機能開発・内部品質の課題を解消できていない背景として、pixiv-iosの開発を担当するiOSエンジニアが不足している現状があります。
ピクシブはpixiv・pixiv Sketch・pixivコミック・Palcy・VRoid等の様々なプロダクトを持っており、それぞれのプロダクトに分散して所属しているため、一つのプロダクトあたりのiOSエンジニアは少数になってしまいます。
人数の課題を解決するためのわかりやすい手段として新しいiOSエンジニアを採用することが考えられますが、内部品質の課題で取り上げたようにpixiv-iosの中身が複雑になってしまっているため、このコードを読み解いた上で改修することのできる高い技術力を持つエンジニアを求めざるを得ません。
それゆえiOSエンジニアが足りない状況からなかなか脱却できていません。
これらのネックとなっているのはやはりpixivアプリの内部品質です。悪循環を断ち切るためには設計や複雑化した独自実装といった負債を抱えたpixiv-iosを破壊しなくてはいけません。
課題解決のための施策
破壊すべき課題を今一度確認しましょう。
- 密結合で、変更の影響範囲が大きくなりやすい
- メンテナンスされていないライブラリに依存している
- 独自実装が複雑化し、コードの可読性が低下している
ここからは、これらの課題を解決するために今進めている施策について語っていきます。
内部品質改善の日
まず毎週木曜日を内部品質改善の日としました。事業としてみるとコード改善は新規機能実装に比べ、チーム的にも個人のモチベーション的にも優先度が比較的落ちてしまいます。そのため、必ず内部品質改善のための作業を行う曜日を設定しました。
SwiftPackageManagerマルチモジュール化
密結合の問題を解消するための手段として、SwiftPackageManagerを用いた機能単位でのモジュール化を進めています。
モジュール化そのものが密結合を自動的に解消してくれる訳ではありませんが、各モジュールの依存関係を明確に定義する必要があるため、このプロセスを通じて、機能ごとにモジュールを細分化しながら依存関係を見直し、アーキテクチャの再構築を行います。
MagicPodを使ったUIテスト自動化
モジュール化等のリファクタリングを進める際にはその影響範囲が大きくなり、既存機能へのデグレが発生することが懸念されます。このような場合にはMagicPodを活用します。
MagicPodとはWebアプリやモバイルアプリのテスト自動化プラットフォームです。
MagicPodを使わなくてもテストを作成することはもちろんできますが、利用することでテストコードの実装・シナリオの構築等のテストの作成そのものにかかる時間を削減することができます。
テストを作成して人間の手による検証・レビューの手間を減らし、内部品質改善をより迅速に進めていきましょう。
公式・サードパーティ製のライブラリの採用
可読性の低い独自実装に対してはApple公式もしくは信頼できるサードパーティ製のライブラリへの置換を進めています。
独自実装そのものについては現在のpixivに最適化された、高性能なコードなのですが、最適化されているがゆえに拡張性に乏しく、またメンテナンスが困難という実態があります。そのため、独自実装の持つ課題を解消し、拡張性とメンテナンス性を向上させる目的で、既存のライブラリを活用する方向にシフトしています。
メンテナンスしやすい疎結合な設計
信頼できるサードパーティ製ライブラリや公式ライブラリであっても、永続的なメンテナンスが保証される訳ではなく、またRxSwift→Swift Concurrencyのようにライブラリやコードそのものに問題は無くても時代の進化によって再設計が必要となることが将来的に必ず訪れます。
そのような場合でも新しい形への移行が容易となるように、極力、結合が疎となりメンテナンスしやすい構成を意識しつつ進めていきます。
最後に
ここまで書いたようにpixiv-iosには解決すべき様々な課題がありますが、自分が好きで毎日のように使っているpixivアプリを自らの手でモダンな構成にリプレースしていくというのはとてもやりがいがあり、楽しくやっています。
tatsubeeはまだまだ未熟ですが、10年以上作り上げられたpixiv-iosを受け継ぎ、より良い体験を作り上げるべく精進していきます！
カジュアルな面談も実施中です。pixivアプリが好きな方や、ダイナミックな変更を伴う開発に挑戦したい方は以下のURLからぜひエントリーしてみてください。 心よりお待ちしております！
