おでーぶでおでーぶ

いろいろ書く。いろいろ。

「チームで育てるAndroidアプリ設計」を読んだ

ダイレクトマーケティングです。(PR) アフィじゃないリンクは一番下に置いておきます。

peaks.cc

全体的な所感

アーキテクチャのモチベーションからアーキテクチャとチームの育成、将来を加味した運用方針について、非常に分かりやすく構成されています。新規プロジェクトへのアーキテクチャの導入、既存アーキテクチャの方向性の手直しや作り直し、既存アーキテクチャの思想読み込みといった よく必要とされる行為でありながら、あまり言語化されていないもの をどういったモチベーションや理念を持って実行するのか、そして どうすれば独りよがりにならず、チーム・組織として運用することができるのか を学べる良い本だと思います。

本書は順番に読み進めるとテンポよく進んでいく章立てになっています。その一方で気をつけなければならないこととして、本中で利用されるアーキテクチャは チームのスコープで使用する汎用的な設計方針 と第一章で定義されるなど、その曖昧な語句の意味は本中で順を追って定義されます。前半で定義し終わるようにうまく構成されているとはいえ、頭から読み進めることで共通認識を得ることに変わりはなく、用語定義表などがあるわけではないので斜め読みをすることはあまり推奨しません。どうしても斜め読みをする場合、他開発者(著者)にとってアーキテクチャはどういう立ち位置であるかを理解するために第一章と第二章は確実に読んでおくことをおすすめします。

また少しエモみの溢れる内容から、想定読者(?)は以下のように感じました。

  • ✅ 新たにアーキテクチャを導入したり、既存のアーキテクチャを補正・刷新するにあたって「アーキテクトとしての言語化の補助」「チームメンバー間でのアーキテクトに対する意識の統一」をするときに読むといい
  • ✅ アーキテクチャの選択や導入手順に悩んでいるときに読むといい
  • ✅ アーキテクトでもチームメンバーでもどっちであっても読むといい
  • ❌ 何かしらの具体的なアーキテクチャの実装例を求めて読むといい

意図的な構成を感じたので、具体的な実装例についてはきっと新しい本の執筆が進んでいることでしょう*1。

ちょっとずつ細かく

自分が本を読むとき、二周目移行に役立つよう章立てをガン無視してラベリングしたりするのでその構成でどんなときに読んでおくと良さそうか、を書きます。

アーキテクチャ導入を説明するときのモチベーションと運用方針

パート: 第一章、第三章、第四章

第一章では新規開発を例にとり、新規開発で求めたいものからアーキテクチャを用意することの必要性が語られます。とはいえ、新規開発でなくとも、現在のチームにその求めたい点が足りていないのであれば同様の考えを展開することは可能なので、自分たちのフェーズが新規開発でなくとも読んでおくと良さそうです。

第三章と第四章はアーキテクチャ例に関係なく読めました。アーキテクチャをチームにどうやって浸透させ運用していくか、それを大きな組織内で横展開するにはどうやればいいのか、著者の経験も含めて語られています。アーキテクチャを導入しても「将来的に腐る運用」であればそのアーキテクチャの寿命は短く、早晩に毒となりえます。自身の運用に自信がなくなったり、迷いが出てきたら非常に良い指針となる章でした。

選択などに悩んだとき用。既存アーキテクチャのまとめ

パート: 第二章

チームメンバーの学習強度といった外的要因から始まり、アーキテクトが大体ぶち当たるであろう、早期に抑えるべき点が列挙されています。また多層アーキテクチャなどの既知のアーキテクチャでカバーできることも丁寧にまとめてあるため、あとで選択に迷ったら読むと良さそうです。

アーキテクトの意思決定の理解の一助となるはずなので、チームメンバーにはぜひ読んでおいてもらいたいですね。

実運用フェーズで考慮すべきコードや運用のメタなポイント

パート: 第五章

Android チームだけではなく、バックエンド他のプラットフォームとの協調も考えなければいけない実例を元に話が進みます。一定の規模までプロダクトや企業が成長したら確実に遭遇するとまでは言いませんが、特に複数の協調するプロダクトを持つ会社ではありそうなパターンです。

その特徴から、開発効率性と堅牢性の双方を重要視するという話は非常に共感出来ます。ただそれを実現するのは非常に難しいので、どのように合意形成をしていくのかであったり、ドキュメント文化であったり、泥臭いことも含めて整備していくことの重要性ややり方が書かれています。

めっちゃ大変だったんだな、と想像しながら読みました(小並感)。

大きいプロダクトからかかる制約例 - モジュラモノリス

パート: 第六章

モジュラモノリスを新規開発段階で考える機会はそう多くはないと思いますが、参考になるのはもちろんのこと単純に面白いです。

多くの既存アプリや社内SDKと協調するプロダクトの開発経験に関する知見を得られます。これはアーキテクチャを主導する人だけではなく、参加する人にもかなり有益じゃないでしょうか? 単にプロダクトの大小に関する1軸ではなく、組織規模も含めた2軸以上を考慮したアーキテクチャはその複雑度や裏にある思想が多くなりがちです。それらをプロダクトに参加して即把握するなど超人以外には不可能なので、この章で知見を得ておくと将来役立つかと思います。

機能開発の効率増加やDX改善といったフィードバック運用方針

パート: 第七章、第八章

すごくエモい方法論の第七章と具体的なクラス特性を改善しつつ説明する第八章のセットです。アーキテクチャを運用していると確実にぶち当たる壁で、これを蔑ろにしているとそのアーキテクチャは腐ってしまいます。ここで紹介された運用手順を導入した場合でも、定期的に見返すことで運用の健全性を考えていくと良さそうですね。

退職と人事異動というコラムが最高だったのでぜひ買って読みましょう。

新規開発と大規模開発で意識する点まとめ

パート: 第九章

新規開発でいきなり複雑なアーキテクチャを導入する必要性はないように思うことも多いですし、逆に大規模開発では多様なレベルの関係者が増えることで制約を増やした方が全体的に健全になることもあります。そういった違いをぱっと見るにはこの章をあとで見返すことになると思います。

蛇足

個人的に本書で書かれたアーキテクチャ周りのモチベーションや思想はかなり近いものがあります。著者陣の二人と仕事をしたこともありますし、設計談義を良くするのですでに意見を知っているとは言え、改めて言語化されたことで再認識する点もありました。

執筆お疲れ様でした。

https://peaks.cc/books/architecture_with_team

*1:しらんけど