俺が! 俺たちが! androidチームだ!
TRANSCRIPT
自己紹介
名前: 鈴木 研吾 twitter: @kengoScal
2011~2014:セキュリティアナリスト 2014年11月: マネーフォワード入社 2014年11月~2015年01月: iOS開発 2015年02月~:Android開発
2
ちょっと最近思うこと
社員数が50人弱の時に入社した。少数精鋭って感じ。 あれよあれよと100人超に。 精鋭揃いだけど…という場面が多くなってきた。 Google I/Oをはじめとした色々な場所で、様々な人種と話して思ったことがあった。 参照: 弊社エンジニアブログ「世界のエンジニア達と話した結果www ‒ Google I/O in San Francisco」
チームとしての成長が必要。 その取り組みについてお話しします。
3
その中で今日お話しすること
自動化 CI環境構築
標準化 設計共有 & 設計レビュー 基底クラス作り リリース当番制度
継続的改善活動 Androidエンジニア座談会
連携 CSさんとの連携
委譲 セキュリティ診断
5
アジェンダ
自動化 -> コストを下げる CI環境構築
標準化 設計共有 & 設計レビュー 基底クラス作り リリース当番制度
継続的改善活動 Androidエンジニア座談会
連携 CSさんとの連携
委譲 セキュリティ診断
6
アジェンダ
自動化 CI環境構築
標準化 -> 誰でも一定の水準でできるようにする 設計共有 & 設計レビュー 標準化 -> 実装への理解を標準化する 基底クラス作り リリース当番制度
継続的改善活動 Androidエンジニア座談会
連携 CSさんとの連携
委譲 セキュリティ診断
13
アジェンダ
自動化 CI環境構築
標準化 -> 誰でも一定の水準でできるようにする 設計共有 & 設計レビュー 基底クラス作り -> コードを標準化する リリース当番制度
継続的改善活動 Androidエンジニア座談会
連携 CSさんとの連携
委譲 セキュリティ診断
17
アジェンダ
自動化 CI環境構築
標準化 -> 誰でも一定の水準でできるようにする 設計共有 & 設計レビュー 基底クラス作り リリース当番制度 -> 誰でもいつでもリリースできる体制を整える
継続的改善活動 Androidエンジニア座談会
連携 CSさんとの連携
委譲 セキュリティ診断
21
リリース当番制度
24
なうリリース当番 リリース毎にリリース担当をローテーションで回す フローを全員で理解することで、いつでもだれでもリリース出来るようにする 主な役割 リリースノートの作成 基本的な動作テスト ドキュメントの更新 APKファイルのアップロード CSさんへの連携
リリース当番制度
25
なうリリース当番 リリース毎にリリース担当をローテーションで回す フローを全員で理解することで、いつでもだれでもリリース出来るようにする 主な役割 リリースノートの作成 基本的な動作テスト ドキュメントの更新 APKファイルのアップロード CSさんへの連携
アジェンダ
自動化 CI環境構築
標準化 設計共有 & 設計レビュー 基底クラス作り リリース当番制度
継続的改善活動 Androidエンジニア座談会 -> KPT回し
連携 CSさんとの連携
委譲 セキュリティ診断
26
Androidエンジニア座談会
27
毎週金曜日 30minで、話したいことを話す 特にテーマは決まっていない
改善案でもおk 何か新しくためしてみたいことでもおk 新しく入社されたエンジニア向けの説明でもおk 今まで話したこと コーディング規約 リリース大臣制度 マージリクエストのフロー決め テスト自動化の進め方 <- New!
アジェンダ
自動化 CI環境構築
標準化 設計共有 & 設計レビュー 基底クラス作り リリース当番制度
継続的改善活動 Androidエンジニア座談会
連携 -> それぞれ思っている・伝えたいことの共有 CSさんとの連携
委譲 セキュリティ診断
28
CSさんとの連携
29
ユーザーの声を直接聞く人からのフィードバックを貰う 毎日決まった時間にエンジニア1人が、ユーザーフィードバックを聞きにいく。 最も新鮮なユーザーの声を共有できる 他のエンジニアはpolling対応しなくて良い。
新機能リリース時はある程度、形ができた時点でテストに参加してもらう bugを早い段階で発見・対応できる 外部仕様の共有ができる
アジェンダ
自動化 CI環境構築
標準化 設計共有 & 設計レビュー 基底クラス作り リリース当番制度
継続的改善活動 Androidエンジニア座談会
連携 CSさんとの連携
委譲 -> チームの手が届かない箇所を任せる セキュリティ診断
30
セキュリティ診断
31
年2回の診断を別の会社に依頼する セキュリティについては重要な開発要素であることが多い が、全員がその知識を有さないことが大体 それをそのまま出来る人にお願いすることで、水準をクリアする。 セキュリティに限らず委譲することで、良いチーム・良いプロダクトを生み出せる(こともあると思う)