チームで育てるAndroidアプリ設計
こんにちは、kgmyshinです。 このブログではお久しぶりです。 今回Peaksさんにて、Androidの設計関連の出版プロジェクトに参加することになりました。
敬愛する横幕さんと私（釘宮）の二人で頑張る予定です。今回は設計の横幕と釘宮ということでお願いします。
設計の釘宮、hide apiの横幕
— 将来的な変更に対する強度を保ってください (@k0matatsu) 2018年8月22日
（初回のmtgで、おや横幕さんと自分しかいないな？なるほど？？？？？となったのはここだけの話）
思いみたいなものは、プロジェクト概要に書いたのですが、こちらでもざっくり書いていきたいと思います。
思い
最近はAndroidの設計の話はだいぶ落ち着いたかなと思います。 カンファレンスでもみかけはするものの一時期よりも枠は少ないでし、PeaksのAndroidアプリ設計パターン入門から数年もたっているわけです。
落ち着いたし、ある程度各現場での導入は完了したのかと思えます。 導入できれば、ある程度の品質や生産性の向上が見込めそうです。 が、自分の観測範囲では実際はそうはなっておりません。
導入しようにもどうしたらいいかわからず、またチームにうまく説明できずに導入時点で挫折したケース。 なんとなく導入したけど、導入者含めたメンバーの誰も何が良いのかよく分かっておらず悶々としている現場など、さまざまです。
今回、成立した場合に書く本では設計のことについて話しますが、これが唯一の正解のアーキテクチャだという話はしません。
というか、正直自分は抑えるべきポイントを抑えていればアーキテクチャなんてぶっちゃけなんでも良いと思っています。
完成形がどうこうではなくて、その抑えるべきポイントについて書くつもりです。 それはチームだったり、作るものによっても変わってきます。 そしてさらに、抑えるべきポイントを抑えたら、どうチームに浸透させていくか。 そんなことを書けていけたらと思っています。
わかりにくいかもしれない比喩
少し伝わりにくい比喩になるかもしれませんが、例えばチームで一冊の本を書くとします。
何も考えずにそれぞれが書くと、各章の構成はバラバラになってしまいます。 とある人は 「1節 , 2節, 3節」と書くのに、ほかの人は「Ⅰ、Ⅱ、Ⅲ」と書いたり。
「ですます調」で書いてる人もいれば、「だ・である調」で書いてる人もいたり。 そういった本では内容に集中できません。
プログラムをチームで書く場合にも同じようなことが起こります。 そしてそうなってしまうと、コードを読む場合も書く場合も、プロダクトに集中することはできません。
そういうことです（わかりづらいな、これ。。。）
最後に
自分は、今まで新規開発時にテックリードを担当することが多くありました。 加えて、強い人というよりも新卒だったり、普段はAndroidを書いていない人がチームメンバーだったりすることがほとんどでした。 そういった中でどうすればみんなが生産性高くなるか、実力差はあってもコード品質差をいかに少なくできるか、いかにみんながプロダクトに集中できるかを考えてきました。 最近では副業で外部からアドバイスさせてもらう機会も増えてきましたし、現職では横断組織としてより汎用的な何かを考えたり、各事業部に支援に行くことも多いです。
これらの経験を通して得ることができた自分の知見を今回の本に惜しみなくフル投入していくつもりであります。
なにとぞ、応援よろしくお願いします。
興味あればぜひ買ってくださいませ！！！
