「チームで育てるAndroidアプリ設計」発売に寄せて編集者の立場から。
おつかれさまです。mhidakaです。技術書典やDroidKaigiのオーガナイザーをしています。今回のストーリーはPEAKSという書籍クラウドファンディングから生まれた書籍のお話です。
書籍「チームで育てるAndroidアプリ設計」はアプリ開発をテーマにしたプログラミング解説書です。特にモバイルアプリの課題となりやすい設計に対してチーム開発という切り口で解説した類書のない一冊です。
今回、この書籍に編集者として携わった感想をメモしておこうと思います。本記事は3000文字ぐらいです。読み終わるまで5分程度です。
本書をより楽しむための背景っぽい何か。
mhidaka自身、Androidアプリの開発者として十余年、数多くのプロジェクトに関わってきました。アプリ開発の知見を溜めたり苦労したり、やれ毎年のAndroidバージョンアップや互換性維持が辛いといったり、ライブラリのアプデが多いだのあーだこーだ言いながら楽しんでいたわけですが、とある課題と折り合いをつけ続けた年月とも言えます。
それは「アーキテクチャとかは、なんでもいいよ！とにかく価値を提供していこう！」というやっていきと「よい設計を維持することがソフトウェアの生産性を高めるはずだ」というソフトウェアエンジニアリングの本能とのバランスです。
前者はサービスやプロジェクトの成功へのコミットメント、後者は継続的な生産性の向上というソフトウェア開発へのコミットメントという感じですね。言い換えればソフトウェア開発者として、どうやってプロジェクトに関与するのが正解なのか（＝ソフトウェア開発のゴールをどう定義するか）という課題でした。
理想状態では、これら２つのコミットメントは衝突せず両立が可能です。しかし実際は短期的には衝突するので、ここまで読んで「おかしいな？」とおもった読者がいれば正しい反応です。
基本的な物事は何らかの制約（締切・予算etc）があります。アプリ開発が経済活動に関与する以上、たとえば工数の不足などから優先順位の設定は避けられないはずです。「私の開発現場ではリリース優先でパツパツで設計がハチャメチャです」という状況をよく目にし、またそういう状況にならないような創意工夫に、アプリ開発の苦労と楽しさが詰まっているといえます。
とはいっても図のような微笑ましい開発現場（？）は可能な限り避けねばなりません。
本書の取り扱う問題の複雑さと想定読者
本書「チームで育てるAndroidアプリ設計」では、ここまで述べたようなアプリ開発の生産性にまつわるあれこれを取り上げています。ただし直接的にアーキテクチャを扱うわけではありません。筆者らの経験した設計・開発事例を中心にチーム開発へ焦点を合わせています。
すこし時系列が巻き戻る話をしますが本書発売に先駆けた2018年、拙作のAndroidアプリ設計パターンを刊行しています。これは「設計に関する議論の土台となる本を」という思いから執筆しました。
アプリ開発の設計や背景について知って議論に参加する基礎知識を揃えましょうという趣旨で、当時多くの出資者から賛同をいただき、今でもちょいちょい購入があるロングセラーとなっています。
「チームで育てるAndroidアプリ設計」では、そのタイトルのとおり、チームでアプリ開発にチャレンジした成果が惜しみなく記されています。
苦労のすえに編み出した著者の解決策や前に進むためのアーキテクチャ・手法の選択を読者が追体験できる構成です。議論のベースラインからまた1歩進み、自分たちの事業やプロジェクトに最適な設計・そのための合意形成、アプリ開発の目的を明確にし、設計力を育てるための一冊を目指しており、実際にそのように使って頂けるツールになったと考えています。
すでに確固とした自身のアーキテクチャ論や設計技法を確立している場合、具体的な方法論まで含んでいない本書ではアーキテクチャに関する知識を深めたい気持ちに応えられないので物足りなく感じると思います。次のような方を想定読者としています。
- チーム開発を良くしたい、技術的なチームビルディングに興味がある
- アーキテクチャとの付き合いかたに自らの物差しを持ちたい
- 個人・チーム開発問わず、アプリ開発での生産性に向き合いたい
「チームで育てるAndroidアプリ設計」の楽しみ方
PEAKSのWebサイト等で書かれている『生産性を最大化する「チームで育てるAndroidアプリ設計」！』というスローガン、著者の意気込みにも触れておきましょう。
昨今のソフトウェア開発ではソフトウェアエンジニアリング、特に生産性の改善もメインテーマの１つに数えられています。その背景は人手不足やアプリ開発（にかぎらず多くのソフトウェア開発）が複雑になりつつあるなどがあるようです。IPAなどの調査資料（2020年ソフトウェア開発分析データ集）からも生産性の低下は一時的な落ち込みではなく、この5~10年で観測できた変化であると示唆されています。
ぶっちゃけソフトウェア開発には変数が多すぎるので統計や特定プロジェクトの要因だけをみて会話するのは危険だと思いますが、mhidaka自身のアプリ開発の経験・感覚でも最近は生産性を維持するのに多くの労力を払う必要があると感じています。
本書の標語はそんな背景のもと「どれだけ大変でも合意を形成し、モバイル開発での生産性を最大化していくんだ」という著者の覚悟がにじみ出ている気がします。
発売に寄せて
「チームで育てるAndroidアプリ設計」は複雑化しているアプリ開発・モバイル開発への試行錯誤をまとめており、生産性の低下というどこでも発生しうるソフトウェア開発の課題に対してどのように抗うべきかを示しています。
チームビルディングなどの人的な要因、リリース目標といった事業背景、要件と使用技術スタックのアンマッチなど数々の課題に対して、ソフトウェアの生産性の向上、開発の継続的な改善などの試行錯誤を通じて、プロジェクトを強力に推進できます。
良質な（＝チームで合意のとれた生産性の高い）アプリ設計がサービスや事業の成功に繋がるのだと示しています。そのためチームと冠がついていますが開発者個人であっても得るものは多いはずです。もし今一人で開発してても大きくなれば誰かの手に委ねたり複数で作業するのかもしれません、著者の経験を通じて自分のスキルを伸ばす発見もできると思います。
「チームで育てるAndroidアプリ設計」絶賛発売中！
もしかしたら読んだら防げるトラブルが載ってるかもしれません。そういうときのために転ばぬ杖が合ってもいいよな、とも思います。この記事をみて、いいなとおもったら上のリンクから購入してください（60ページ弱にわたるサンプルも公開しているので買う前に確認もできます）。
著者らによる読書会も毎週火曜日に開催中です。1章から最終章の9章まで全9回、著者と一緒に読み進めることができます。内容を理解できるか心配という人や、ほっておくと積んでしまう・・という読者もいるかもと思います。この機会に参加ください。アーカイブも視聴できます。
感想のリンク集（タレコミお待ちしています！）
普通の書籍レビューが読みたい人向けに次の6本をおすすめします。こちらは依頼して感想ブログを投稿してもらいました。PR表記をお願いしていますが、各自の視点から率直なコメント、忖度のない感想を頂いてます。ありがとうございました！
- じょいさんのnote『チームで育てるAndroidアプリ設計』を読んで
- muumuumuumuuさんのブログ 「チームで育てるAndroidアプリ設計」を読んだ
- setohさんのブログ 「チームで育てるAndroidアプリ設計」を読んだ
- darumaさんのブログ「チームで育てるAndroidアプリ設計」を読んだ
- Mori Asushiさんのブログ 「チームで育てるAndroidアプリ設計」を読んで、アーキテクチャの育成について考える
- akatsuki174さんのnote 持続可能なAndroidアプリ開発をしたい人におすすめな本-『チームで育てるAndroidアプリ設計』-
感想ブログなども読みたいので見つけたら教えて下さい（タレコミをいただけると、ここからリンクしようとおもっています）。
次は、今回お話できなかった技術書クラウドファンディングPEAKSの面白い特徴とかも紹介できるといいなと思います。いろんな試行錯誤があるんですが、また次の記事でお会いしましょう！
この記事が気に入ったらサポートをしてみませんか？