最近やったDIYは、自室のオフィスチェアのキャスターで猫の足を巻き込みそうだったので、100均のプラタッパーを加工してカバーにしたことです。最初は使い捨てのテイクアウト容器を加工したものでしたが、加工が容易な分、壊れるのも早かったです。
こんにちは。 STORES 決済 でAndroidアプリエンジニアをしている Yamaton です。今回は、STORES 決済 のAndroidチームで取り組んでいる「とある施策」についてお話しします。
公式ドキュメントの読み合わせ会
出オチですが、現在AndroidチームではAndroid Developersに掲載されている公式ドキュメントの読み合わせ会を週に１回行っています。 発案は同僚の n-seki です。n-seki には始めるきっかけや狙いがあったかもしれないですが、チームにこの話が持ち込まれたときは「ドキュメントの読み合わせ会とかあったら嬉しいですか？」と言う軽い提案でした。私も、チームメンバーの mitchan もポジティブな反応をした覚えがあります。 最初は、基礎の基礎から試してみて感触をつかみたいということで、「アプリアーキテクチャガイド」を読むことにしました。
元々このページの存在を知っていたため、Android Developersのトップからたどるのではなく、検索で直接たどり着きました。実はよく似たブラッシュアップ版のページがあります。読み合わせ中「あれ？それどこに書いてあるの？」というやりとりがあってわかりました。Meetで画面を共有しつつ、読み上げる担当は自分の手元で開いたページを見ていたのでそのようなことが起きました。ブラッシュアップ版は下記のリンクになります。トップからたどる場合は ドキュメント > ガイド > アプリアーキテクチャ（2023-04-25現在）です。
やり方
- 全員が同じドキュメントを見ている
- Meetで誰かが対象ページを画面共有する
- 読み上げる人は手元で同じページを開く
- 持ち回りでドキュメントを読み上げる
- 適当にバトンタッチ
- 腹落ちしない、何か引っかかるときは声を出す
- 挙手ボタンや「ちょっといいですか」などは不要
- 「ん？」「え？」「どゆこと？」程度でOK
- そのまま疑問を解決するまで意見を言う
- 繰り返し読み直す
- 先行理解した者が助け舟を出す
- 最初に決めた時間内で終わり
現状は、このようなやり方をしています。簡易的な議事録として、何を読んだか、どこまで読んだか、次回は誰から読むか、程度は書き残しています。議事録にすべてを書き残すよりも、その場で理解が深まることを大事にしています。
やってみてどうだったか
上記で「理解が深まった」とかんたんに書きましたが、それだけでは足りない効果があったので詳しく書きます。
チームメンバーの知識やスキルがすべて一致していることはあり得ません。そんな中で仕事やタスクを通じて共通認識を作り上げていくのが常だと思います。既存のコードにあたらしいアーキテクチャやライブラリを導入した場合、同時に使い方の共有会が開かれたり、軽い内容であればプルリクエストのレビューで解決したりするでしょう。そういった流れで「見知った」ものは、使うことはできるかもしれません。ただ、「知識」や「スキル」になり得るかというと難しい気がしています。
よく例に出される「電子レンジ」の話をします。電子レンジの使い方は知っているが、その原理や仕組みは知らない。そこに差がある、というアレです。 （電子レンジの原理や仕組みは例として挙げただけなので正確性は求めないでください）
- 使い方を知っている
- 温めたいものを庫内に入れる、扉を閉める、時間を設定する、スタートする。中に入れたものが温まる
- 原理を知っている
- マイクロ波をあてた水分子の振動による摩擦熱で温まる。ということは突沸の危険があるものは入れられない。同様に電子が飛び出し火花が散る可能性のあるアルミホイルなどは入れられない。とわかる。
- 仕組みを知っている
公式ドキュメントに書かれている内容はすべてが平易な言葉で書かれているわけではありません。一度通読しただけでは理解が追いつかない箇所が何度も出てきます。しかし、そういった言葉で表現されるだけの内容が書かれている、ということでもあります。既存のコードに取り入れて何度か使っているうちに手に馴染んで書けるようになり、便利だなと実感している。その実感を与えてくれるアーキテクチャの成り立ちや思想、なぜそのようなコードで表現されているのか、が公式ドキュメントで解説されています。 取り入れたアーキテクチャで表現すると、しっくりこないような要件と出くわしても、公式ドキュメントの解説を理解していることで、解決方法にすぐたどり着けたり、その要件の場合には無理にアーキテクチャに合わせる必要がないということがわかったりします。また、こうしたことを理解していると、レビューの際にプルリクエストにどれだけの前提情報を記載すればよいかがわかるので、結果的に時間の短縮につながります。
まとめ
いろいろと書きましたが、まとめるとこのような効果がありました。
- チームの共通認識を作ることができる
- レビューの開発時間を短縮できる
- チームメンバー全員のレベル感の底上げつながる
- 問題の解決が迅速に行えるようになる
- コミュニケーションコストが下がる
コミュニケーションの一環としてもコスパの良い施策だと考えています。チームのレベルを底上げしながら、会話の機会がもうけられます。リモートがメインとなった現在、黙々と開発に集中できるのは良いですが、気付けば朝会以降、声を出して話してないな、なんてことはよくあります。そんなチームの一助になれば幸いです。
