Androidアプリをチームで開発しているあなたに「チームで育てるAndroidアプリ設計」を

こんにちは、@kgmyshin です。

この度、「チームで育てるAndroidアプリ設計」という本を、@KeithYokoma さんとの二人の共著で執筆いたしました。また @mhidaka さんの編集も入っております。

本日（2021年4月26日）より、一般販売が開始しました。

チームで育てるAndroidアプリ設計

この記事では、この本についての紹介をさせてください。どういった背景があって、この本を読むことで何が得られるの？そういったことについて記していきます。

軽く自己紹介

@kgmyshin です。Androidエンジニアをしています。新規事業の立ち上げから、いわゆる1 -> 10 のフェーズや 10 -> 100 のフェーズにおいて、テックリードやエンジニアリングマネージャーなどを経験してきました。

今は横断組織に所属しており、さまざまなフェーズの事業に支援に入ったり、推奨アーキテクチャの整備などなどもろもろをやっております。これについては下記にもう少し詳しく書いてます。

開発組織にコミットする

そういう事情もあって、アーキテクチャとチームについてはいろいろと考えては実際に試してきました。今まで外部向けに発表した内容をみても、そういったテーマの発表が多くなっております。

2017年 DroidKaigi 未熟なチーム開発
2018年 DroidKaigi マルチモジュールのすゝめ
2018年技術書典4 大きめのAndroidアプリでの設計を考えてみる~pocket~
2019年 DroidKaigi マルチモジュールプロジェクトでのDagger2を用いたDependency Inejction
2019年 DMM Android勉強会新規チームで新規開発を始める時にやること

と、このような背景を抱えたAndroidエンジニアでございます。

背景または課題感

2018年ごろ、Androidアプリ界隈ではアーキテクチャパターンについての話が盛んにされていました。それこそ PEAKS から下記の書籍が出版されたのもその頃です。

参考 Android アプリ設計パターン入門peaks.cc

そこからは新しいアーキテクチャパターンは確かにあったものの、数は減っていきました。また、アーキテクチャパターンの話題から変わってマルチモジュールの話題にフォーカスが当たる時期もありましたが、今となってはこちらも収束しているように感じています。

収束したということは、各現場ではすでにそれらのアーキテクチャパターンが導入されており、またアーキテクチャパターンを取り入れることで得られるはずの恩恵を享受できているということでしょうか。

新規事業に関わることが多い仕事柄、多くの現場を見て回る機会がありました。

結論としては、テックリード級のエンジニアが揃っている現場をのぞいて、どの現場も当時語られていたアーキテクチャパターンの導入ができていない、もしくは、導入したつもりだけど、得られるはずの恩恵を全く享受できていないという状況になっています。

アーキテクチャがワークしていない

ある程度キャッチアップしているエンジニアであれば、いくつかのアーキテクチャパターンを知っていることがほとんどです。しかし、チームにフィットしない、なんか浸透しない、適用したけど正直これで何かが良くなった気がしない…という状況のチームがほとんどです。

よくあるのが、「中途半端に導入してしまってはその当事者がいなくなってしまう」という事象を何度か繰り返してしまい、見る場所ごとに書き方が異なり、時間が経つにつれてそれらの書き方が混ざっていき、収集がつかなくなってしまっているというケースです。

Point

アーキテクチャパターンを知ってるが、うまく使えていない

一方で、一回だけですがこういう現場も見かけたことがあります。モダンと言われるアーキテクチャからはかけ離れているものの、統一性がとれていて、見通しが良く、アーキテクチャがチームの生産性に貢献しているという現場です。

モダンなアーキテクチャが解決してきた課題は抱えているとしても、アーキテクチャがワークしないという課題に比べると微々たるものです。

Point

モダンなアーキテクチャではなくても、アーキテクチャがワークしている場合もある

ただし、アーキテクチャがワークしている場合でも注意は必要です。時間とともに、チームメンバーが入れ替わったり、モダンなアーキテクチャの適用を試みるタイミングで、徐々に統一性が失われてしまい、アーキテクチャが崩れてワークしなくなるということも多々発生しています。

Point

ワークしているアーキテクチャが徐々にワークしなくなることがある

どういう本か

「チームで育てるAndroidアプリ設計」は上記のような課題にどう対処するかという本です。

例えば「MVVMを選んで、○○クラスとXXクラスを作って、△△をしましょう」という内容の本ではありません。

どういうアーキテクチャパターンをどういう観点で選ぶか。どこまでなにを決めて、なにをすればワークするアーキテクチャ足りえるのか。そういうった本です。

本は大きくは２部に分かれています。１部では新規開発フェーズにおいて、どうやって簡単には崩れないワークするアーキテクチャを構築するのかについて説明しました。ここが私の担当でした。２部では、打って変わって大規模開発フェーズについて説明しています。ここは @KeithYokoma さんが実体験に基づいた説明をしてくれています。

自分が書いた１部について、もう少しだけかいつまんで説明しておきます。

先の「背景や課題感」で書いたように、アーキテクチャパターンはただ適用すればいいものではありません。単純に適用することだけを考えてしまっては、ワークしないアーキテクチャになってしまうでしょう。そこには例えば次のような抑えるべきポイントがあります。

アーキテクチャパターン
コンテキスト分割
多層アーキテクチャでの分割
データフロー
非同期
永続化
エラーハンドリング

本では、実例を交えながら、各視点についてどう考えるべきかを説明しました。

また、アーキテクチャがある程度完成したら、それをどうやってチームに浸透させるのかも重要になってきます。

どういうドキュメントを残すかについても触れてますが、ほかにも自分が実際によく行っている「クラス図レビュー」などにも触れました。実際に実装に入る前に、クラス図を書いてレビューする機会を設けることで、アーキテクチャとのズレをなくすことができるというものです。実装後にレビューするだけでは、アーキテクチャとの大きなズレがあると、指摘する方もされる方も心的に大きなストレスになってしまいます。実装前にクラス図のレビューをすることで、設計方針にフォーカスした理解が進むだけでなく、そういったストレスを軽減することもできます。本では、もう少し詳しく説明しているので、気になる方はぜひ読んでみてください。

その他にも、次のようなことを書きました。