こんにちは、dely の Android チームで施策をやりながらアプリ改善に取り組んでいる tummy です。 以下記事を書いてからもう 2 ヶ月が経過し、Android チームも 1 人増えて 4 人になりました。この 3 ヶ月でメンバーの数が倍になっています(すごい)
この 3 ヶ月間主に阿吽の呼吸でまかなえていたことを掘り起こして文章化し、チームの共通認識を作るところに注力していました。今回はその取り組みについて紹介できればと思います。
リリースマネージャーのような役割になってみる
Android チームは 1 人 1 つ何かしらの施策を担当しており、同時並行で進んでいます。2〜3 人の時期は、bot のレオくんが水曜日になるとそろそろリリースしない?とお知らせしてくれるので、それをみたときにリリースするかどうか決めていました。
しかし 3 人中 2 人が大きめの施策を担当しているのもあり、なかなかリリースしようという雰囲気になることが少なかったです。そして、4 人目がジョインした今月、細かい施策が爆速で進むようになった結果、1 週間経った時点でマージされているプルリクが 10 を超えるようになりました。
さすがにこれはコンスタントにリリースしていかないとやばいと思い、リリースマネージャーのようなことをするようになりました。とはいってもそこまで形式張ったことはやっておらず、主に以下のようなことをしています。
- リリースサイクルの策定(次に詳細を書きます)
- リリース作業、及びその効率化
以下の記事で書かれているように、弊社の Android CI は bot が大変活躍してくれているので、より多くの過程を bot にまかせられるように実装 & 調整中です。
リリースサイクルの策定
やりました。経緯は上記に書いたとおりです。プロダクトレビューという文化が弊社にはあるため、そのレビュー結果への対応期間も考慮しつつも、基本的には水曜日にコードフリーズ & デバッグ、何もなければ木曜日リリースというフローを踏んでいます。
リリースノートの自動化など、このサイクル内でもまだ自動化できそうな箇所があるので、引き続き模索していきます。
設計について議論したりする場所が爆誕
クラシル Android は 4 年もののアプリで、設計も複数パターンあったりしてとても複雑になっています。メンバーが 3 人になり、こういった箇所にもだんだん手を入れられるようになってきたことと、過去の事情によって実装されている箇所などを質問する場として Android エンジニア MTG が生まれました。
4 人になった現在は設計をこれからどうしていくか、コードスタイルについてどれを採用していくかなど、古くからあった懸念への対応方針について議論することが多くなり、改善方面にも力を入れられているのでとても活発になっています。(次回で 6 回目まで来ました 🙆)
議事録や仕様書の共同編集化
プロダクトレビュー等を通してガンガン仕様が変わる弊社ですが、仕様書が過去のまま更新されず、最新状態がわからないという問題がありました。また、それに伴い仕様の認識のズレが起きてしまっていました。 そこで、Qiita に共同編集にしたほうがいいものとしなくてもいいものを画像つきで記事にしてみました。
この記事がきっかけになったのか、積極的に共同編集にしてくれる方が増えてきててとても嬉しいです。 まだ問題は残っていますが、解決の一歩になったのではないかと思っています。
プロダクトレビューについての内容の明確化
プロダクトレビューは CXO の坪田さん発信で始まったものですが、なぜ?何をみてるの?という観点が明確ではありませんでした。そのせいか、せっかくのレビューの機会でぎくしゃくした雰囲気になることがありました。 そこで、自分が集められる情報を Qiita にまとめて坪田さんに共有、ヒアリングすることで足りない箇所をアップデートしました。坪田さんにとてもわかりやすい資料も作成いただいて、全体に共有されました。これからどんどんこの考えが浸透していくといいなと思いますし、自分も意識したいなと思います。
全員参加型のチームを作りたい願いを込めたオンボーディング資料の一部 pic.twitter.com/ryUZCu1rgE
— 坪田 朋 / クラシル (@tsubotax) 2020年2月5日
まとめ
ざーっと今までやってきた取り組みをご紹介しました。まだまだやれることはたくさんあるので、引き続きやっていきます。 また新しい取り組みを始めた際にはブログでお知らせできればと思います!
dely では様々なポジションのエンジニアを積極採用中です!興味がある方はぜひご連絡ください!