開発チームの生産性の高め方

freeeTechNight vol.1 でお話したときの資料です。
スライド内リンク集

開発環境をMacからEC2に移行した話 - http://kompiro.hatenablog.com/entry/switch_mac_to_ec2

QA基盤のはなし - https://speakerdeck.com/atk/sisutemutesutozi-dong-hua-kanhuarensu2018

新しいミッションについてのAdventCalendar - https://developers.freee.co.jp/entry/new-mission-fy2019

Transcript

1. 「開発チーム 生産性 高め方」 December 14th, 2018
2. @kompiro 近藤寛喜 freee株式会社 2 • 会計freee エンジニア • Civilization6 沼に落ちた( witch 版) • 甥 & 姪と遊んで腰を痛めた • 開発環境を ac から EC2 に移 行してみた話
3. @kompiro 近藤寛喜 freee株式会社 3 • なぜ生産性が問題になる か？ • 実際にやっていること • 生産性について 僕 考え 今日お話すること
4. 4 なぜ生産性が問題になる か？ 01 Section
5. 5 5 PRODUCTS
6. 6 進化 軌跡：プロダクトとチーム 創業6年半・7つ プロダクト・100名〜 エンジニアチーム 2012 2013 2014 2015 2016 2017 100 50 75 25 会計 会社設立 人事労務 マイナンバー 開業 申告 freeeカード 2018 プロダクト リリース エンジニア数（人） API公開 サービス 分割開始 マイクロ サービス化 基盤投資加 チーム制 導入 クラウドERP コンセプト発表
7. そ 結果作成された 数 どうなったか？ 7
8. 作成数
9. エンジニアが増えれ 作成される が増える 9
10. こうなると ailsが用意する 生産性向上施策だけで なんともならない 10
11. 今日 freee 生産性向上施策を紹介します 11
12. 12 実際にやったこと 02 Section
13. 作成数
14. これだけ が増えた中で どこが課題になった か？ 14
15. • C 詰まり • デプロイ前 確認 次点: 開発環境構築が大変 補欠: レビュー 指摘漏れ 15
16. 16 C 詰まり 2.1 Section
17. 1年前... 17
18. テスト 時間が 長すぎてC が詰まった 18
19. 当時 enkins 19
20. 最強 インスタンスサイズ EC2 インスタンス 4台 上で 20
21. pararell_test gem を使って並列実行 21
22. C 実行に30分 22
23. 1時間に消費できる リクエスト 8個 23
24. キューに積まれる リクエスト数 15/時間 24
25. そりゃ詰まる　 25
26. マージ C が通ってから レビュー後 待ちが長かった 26
27. そもそも30分て C 時間が長すぎやん？ 27
28. C 時間が長すぎ問題 要因 一つ ↓ そもそもでかい 28
29. →プロダクトを分割する みひゃえるさん 話で 29
30. 話を戻して 30
31. C 詰まりをなくしたい 31
32. 今 CircleC + erformance ricing lan 32
33. 30コンテナ 並列実行 33
34. そ 結果 C 時間 どうなったか？ 34
35. テスト時間: 8分 全実行時間: 15分 35 9:52
36. 詰まり なくなった　 36
37. CircleC に移行したことで 他にもC したいことが 簡単にできる 37
39. 例1: storybookをビルド 39
41. →storybook コンポーネント カタログとして重宝 41
42. 例2: asset:precompileし 3にアップロード 42
43. →lintが通っても ビルドできないこと ある 43
44. → 3に上げたassetを proxyすれ ビルドする必要がない (実験中) 44
45. 例3: db:create db:migrate した結 果をdump 45
46. → rakeを通すと時間かかる これら 操作も なら それほど時間がかからない 46
47. →(W )db:seedや テスト用 DBもdump 47
48. テスト時間: 8分 全実行時間: 15分 48 15:31
49. C 以外にも便利すぎな で 活用していきましょう 49
50. CircleC & k8s 運用 →いっちーさん お話で 50
51. 反面CircleC 分析機能が弱い 51
52. →実行した統計情報を AW Athena に格納し redashにダッシュボード 52
54. →実行が遅くなった や flakyなspecを追跡し、 遅くなってもすぐ対応 54
55. 55 デプロイ前 確認 2.2 Section
56. デプロイ前 確認と なにか をお話する前に、 ぼくら デプロイ手順を公開 56
57. 各々がコードをpush後、 をつくる 57
58. マージする前にレビュー必須 58
59. レビュー なら承認。C もチェック 59
60. 全部 だったら開発ブランチにマージ 60
61. そんな感じで各々 タイミングでマージ 61
62. デプロイ始めるよーと lackで言う 62
63. ステージングにデプロイ終わったらメンショ ン 63
64. 各々がステージングを確認し、 ならbot が 一覧にチェックをいれる 64
65. みんな になったらbotがリリース可能と判 定する 65
66. プロダクションへ公開 66
67. 2年前 67
68. 1回 デプロイで リリースされる 数 せいぜい10個 68
69. これで十分だった 69
70. 今 70
71. 1日にマージされる 数が たくさんになった 71
72. 一覧が １画面に収まらない 72
73. →まとめて確認することに 無理が出てきた 73
74. デプロイ開始から リリースまでに 少なくとも半日以上 かかる 74
75. 今週社内でデプロイ改善 eetupをやった 75
76. そ 時出たアイデアがこれ 76
77. デプロイ時 確認自体を なくそう 77
78. みんな 分 一覧を作って確認 →やめたい 78
79. マージボタンを押したら すぐにリリース前 環境で 確認 79
80. まとめて確認依頼すると 確認してほしい人が すぐ確認できないことがある 80
81. メンション飛 してもメンバーがいない ことがある 81
82. ミーティングだったり 体調不良だったり 82
83. 人が増えて 顔も知らない人が 作った機能だったり 83
84. そういう無理をなくしていく 84
85. マージボタンを押したら すぐにリリース前 環境で 確認 85
86. A用 環境を応用することで できそう https://speakerdeck.com/atk/sisutemutesutozi-dong-hua-kanhuarensu2018 86
87. やっていき　 87
88. 88 生産性について 僕 考え 03 Section
89. ぼく 生産性という 言葉 嫌いです 89
90. なぜなら 生産性と 何か わかりにくい 90
91. よくある話 91
93. 生産性が高まったとき 価値を評価できてない 93
94. 生産性が高まることで 得られるも 94
95. それ 創 性な活動に 費やせる時間 95
96. 以前 freee ミッション こういうも でした 96
97. スモールビジネスに携わるみんなが、 創 的な活動にフォーカスできるよう
98. 今日 発表 タイトルも 気分 こんな感じ 98
99. 「開発チーム みんなが創 的な活動に フォーカスできるよう」
100. 伝わらないと思った で やめました 100
101. 僕らが創 的な活動に フォーカスできている =生産性が高い 101
102. スモールビジネスを、 世界 主役に。
103. お客様を世界 主役に するために 創 的な活動に フォーカスしたい 新しいミッションについて こちら 103
104. 生産性を高める ３つ 視点 104
105. a. ムダを解消する 105
106. b.ムダに気づける 106
107. 直接的に時間が得られる視点 間接的に時間を得る視点 107
108. ムダに気づき、 ムダを解消する 108
109. これらをやる前にチームに 話してみる 109
111. するともっといい アイデアになる 111
112. マージボタンを押したら すぐにリリース前 環境で 確認 →デプロイ時 確認をなくす 112
113. ３つ ステップ 113
114. ムダに気づき、 ムダを評価し、 ムダを解消する 114
115. これが僕 生産性を高める 考え方です 115
116. ムダを評価せずに ガンガン回す 116
117. =ムダをなくす活動に ムダが多いかもしれません 117
118. ということで 118
119. やっていきましょう　 119
120. ムダに気づき、 ムダを評価し、 ムダを解消する 120
121. スモールビジネスを、 世界 主役に。