VIPERの導入は、Sansan iOSアプリに何をもたらしたか？
次にお届けするのは、中川泰夫氏による「Sansan iOS アプリのリニューアルの舞台裏 -VIPER を導入し、単一責任の原則にのっとったモジュール化された構造を実現する」だ。
今年3月に開催されたSansan主催のビジネスカンファレンス「Sansan Innovation Project 2019」で、同社は「名刺管理から、ビジネスがはじまる」という「Sansan」の新たなプロダクトコンセプトを発表した。このコンセプトをプロダクトで体現するため、iOSアプリのリニューアルを行うこととなった。
リニューアルにおいては、アプリ内の名刺タブの追加や同僚タブの変更、Design Systemの導入などが実施された。それとあわせて導入されたアーキテクチャがVIPERである。
VIPERとは、アーキテクチャ内に登場するView、Interactor、Presenter、Entity、Routerという各要素の頭文字を組み合わせた用語だ。この設計を導入することで、単⼀責任の原則にのっとり、クリーンでモジュール化された構造を実現できる。では、アーキテクチャ内の各要素はどのような役割を果たすのか。中川氏は順に解説していった。
「Viewは、Interface Builderまたはコードで実装されたUIViewまたはUIViewControllerを指します。Viewが行うOutputは、ユーザーの操作をPresenterに伝えることです。ViewのInputは、Presenterから更新内容を受け取り、自身を更新することです。
Presenterは、VIPERにおける各要素間の橋渡し役として存在します。PresenterからのOutputは、Interactorに更新のためにデータを要求したり、Viewに更新内容を通知したり、Routerに画面遷移を依頼したりと多岐にわたります。PresenterのInputは、Viewからユーザーの操作を受け取ることと、Interactorから更新内容を受け取ることです。
Interactorは、データ操作とユースケースを定義します。InteractorからのOutputは、Presenterに更新内容を通知すること。InteractorのInputはPresenterから更新するためのデータの要求を受け取ることです。
Entityは各要素間でやり取りされるデータです。データアクセスレイヤには属さないという制約があります。そのためAPI通信はInteractorに書くことになります。Routerは画面遷移と依存性の注入を担当します。Outputはなしで、InputはPresenterから画面遷移の依頼を受け取ります」（中川氏）
すべてのロジックが適切に責務分離され、単体テストも容易に
リニューアル以前のSansan iOSアプリは、Fat View Controllerが多く、View Controller同士が密結合でコード変更の影響範囲が特定しづらいといった問題を抱えていた。これらの課題を解決するには、責務分離を適切に⾏い、モジュール単位で高凝集にして影響範囲を明確化する必要がある。この目的を達成するには、VIPERが適していたのだ。
具体的にどのようなリファクタリングを行ったか、中川氏はサンプルコードを示しながら解説していった。コードの詳細は登壇スライド内に記載されているため、興味のある方はぜひ参照していただきたい。最後に、中川氏はVIPER導入後の変化について述べた。
「VIPERを導入して良かった点は、もともとControllerに記載されていたすべてのロジックが適切に責務分離され、影響範囲調査が容易になったことです。また、これまで書けていなかったユニットテストが、VIPERで抽象に依存するようになったおかげで書けるようになりました。メンバーがアプリケーションの設計を意識するようになったのも良い点です。
一方で課題としては、UIKitのボイラープレートに加えてVIPERのボイラープレートも増えたため、ひとつの機能を実装するのにかかる時間が増えました。また、新しいメンバーが加わった際に、VIPERの知識がないと正しく責務分離できないことがあるため、レビューのコストも増えました。
この課題をふまえ、考えている改善点をご紹介します。ボイラープレートが多い問題に対しては、チーム内でテンプレートやスニペットを共有できる仕組みの導入を考えています。そして、メンバーが気軽に開発を試せるシンプルなVIPERデモプロジェクトを作成することで、設計について議論できる場を提供する予定です」（中川氏）
歴史の長いアプリケーションには常に「アーキテクチャをどう改善するか」という課題がつきまとう。ある時点においては最善のアーキテクチャだったとしても、時が経つにつれてそうではなくなる、というのは良くあることだ。「Sansan」のアーキテクチャ変遷は「いかなる設計方針に基づいて、アーキテクチャ改善を行うべきか」の知見を、私たちに与えてくれた。
写真：山平敦史
