今年できたチームの生産性を向上させたプラクティスの紹介 / Kaigi on Rails 2022

by AKAMATSU Yuki

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

● 知識の伝達という観点では常時ペアでなくても良い  ○ チーム全体が慣れてきている領域はソロで開発してもあまり問題にならない   ○ 知識・経験の差が大きい領域にフォーカスする   ● 我々の場合  ○ 朝会でタスクを取る時に、経験が浅い領域を担当する場合ヘルプを求める   ■ もしくはまわりからペアプロを提案する  ● 意外と人は助けを求めるのがうまくないので提案するのおすすめ       © 2022 Cookpad Inc. 15 導入にあたって 

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

● 設計ドキュメントに書くことはチームやチームのフェーズによって違う   ● それなりに頻繁にドキュメントを書くのであまり重厚なドキュメントにはしない   ○ = 書くことの取捨選択が必要  ● 例えば、我々はクラス図はかかないが(詳細すぎる)、モノリシックアプリケーションやビジネスロジックが複雑な場合は有効かもしれない   ● 手戻りの手間が無視できる程度の場合、コードを書いてしまう方がいいこともある             © 2022 Cookpad Inc. 20 書く項目は自分たちでしっかりと考える 

Slide 21

Slide 21 text

● 技術的な仕様・設計についてのドキュメント  ○ 施策・機能の要件などは別のところで( Issue、Figma )   ● コミュニケーションにおいて必須な項目かつコード書くより前に擦り合せたいもの   ○ APIレスポンスなど  ● 設計全体を俯瞰できるようにする  ○ 特にデータの流れ、システム間連携は意識している   ● チームにとって未知なもの  ○ チームがあまり経験していなさそうなアーキテクチャやライブラリの採用   ○ 開発経験の少ないアプリケーションとの連携         © 2022 Cookpad Inc. 21 書く内容で意識しているポイント 

Slide 22

Slide 22 text

Slide 23

Slide 23 text

● 設計ドキュメントが後続のタスクのブロッカーになりがちなのでそこは意識しておく  ○ ドキュメント書く前にあつまってガッと設計するのもあり   ● 一緒に書き進める場合は Google Docs が便利   ○ 一方でドキュメントが死蔵しやすいので注意   ● 自分たちは基本的に GitHub Enterprise に Markdown を保存している   ○ レビューしやすいが一緒に書くにはちょっと不便なので必要に応じてGoogle Docs を使っている          © 2022 Cookpad Inc. 23 書き進め方 

Slide 24

Slide 24 text

● 書いたドキュメントが適切だったかはふり返ると良い   ○ 情報に過不足はなかったか  ○ 実装時にわかりにくい箇所はなかったか   ○ → 次の設計ドキュメントに活かしていく  ● 例えば  ○ 「アーキテクチャの全体やDWHとの連携がわからず、実装時に混乱した」   ○ => 全体がわかる図を書くようになった           © 2022 Cookpad Inc. 24 設計ドキュメントはふりかえるのが大事 

Slide 25

Slide 25 text

Slide 26

Slide 26 text