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

Transcript

1. © 2022 Cookpad Inc. 今年できたチームの生産性を向上させたプラ クティスの紹介
 クックパッド株式会社 赤松 祐希 ( @ukstduio )
2. © 2022 Cookpad Inc. 2 • @ukstudio
 • クックパッド株式会社 レシピサービス開発部 
 • バックエンドエンジニアのテックリード 
 • Splatoon 3、ダーツ
 • 最近はRailsアプリケーションにどう型を導入するか興味があ ります
 ◦ でも今日は型の話どころかコードも一切でません 
 自己紹介

3. © 2022 Cookpad Inc. 3 最初にチームが抱えていた問題を説明したあと 
 これのプラクティスについて紹介していきます 
 今日紹介するプラクティス
 設計を議論する
 チャンネルの
 開設
 ペアプロ
 設計
 ドキュメント

4. • 2週間のサイクルで開発を行なっているが、2週間のタスク完了率が50% 
 • これが持続的に続き、また完了率の悪さからプロダクトの計画が不安定に 
 © 2022 Cookpad Inc. 4 チームが抱えていた問題
 ダウンしないバーンダウンチャート

5. © 2022 Cookpad Inc. 5 なにが大変？
 あまり触れたことのない 
 アプリケーションの開発 
 マイクロサービス

6. © 2022 Cookpad Inc. 6 なぜこのような状況に陥ったのか
 • 大きめの組織体制の変更による人員の異動 
 ◦ 流入が多め
 • 事業はフォーカスしたが、施策の実現粒度で見る と開発するアプリケーションの数が 
 増えた
 

7. © 2022 Cookpad Inc. 7 なぜこのような状況に陥ったのか
 • 大きめの組織体制の変更による人員の異動 
 ◦ 流入が多め
 • 事業はフォーカスしたが、施策の実現粒度で見る と開発するアプリケーションの数が 
 増えた
 
 あまり触ったことのない 複数のアプリケーションを開発しなくてはいけない = 大変！！
8. • 開発がスムーズに行くように、チームのナレッジを増やす 
 • 問題発覚が後の方ほど大変なので、より前に気づけるようにする 
 
 
 
 
 © 2022 Cookpad Inc. 8 どうする？
 もちろん技術的に改善しなくてはいけないこともあるがここではスコープ外。 
 技術的なところにも興味がある人は別途話しましょう。 
 

9. © 2022 Cookpad Inc. 9 設計について相談するチャンネルの開設

10. • シンプル & コストがかからない
 • 手戻りを防ぐことができる
 • 自然とメンバーに知識が共有されていく 
 • 気軽に意見していいんだという雰囲気が作られていく 
 
 © 2022 Cookpad Inc. 10 専用の場所がある方が発言のハードルが下がるっぽい

11. • チャットでの議論や意思決定は流れていくうえに 参照しづらい
 • Issue や Pull Request、後述する設計ドキュメントに書くなど ストック情報に転記することをおすす め
 
 © 2022 Cookpad Inc. 11 チャットはフロー情報であることを意識する
 フローからストックへ 

12. • 最初は発言がないかもしれないので、 自分の設計や実装について質問をしていく 
 • 誰かの質問がスルーされないように気をつけること 
 ◦ 最初のうちは自身が積極的にコメントしていく
 ◦ わからない時はわからないみたいな返事をしても良い 
 ◦ 誰か詳しそうな人が思い浮かぶならその人にメンションしてみるのも良い 
 
 © 2022 Cookpad Inc. 12 過疎らないようにする

13. © 2022 Cookpad Inc. 13 ペアプログラミング

14. • 知識・経験のないアプリケーションの開発時に、経験のある人とペアを組む 
 • ペアを組むことで問題が予防されるので 手戻りを防ぐことができる
 • 経験のある人とペアを組むことで、 知識が共有されていく
 
 
 © 2022 Cookpad Inc. 14 ペアプログラミング
 伝授
 圧倒的成長
 これはやらせで撮った写真

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

16. © 2022 Cookpad Inc. 16 設計ドキュメント

17. • 本人の設計スキルの向上やナレッジの獲得が期待できる 
 • 実装より前の段階でドキュメントを書くことで 手戻りを防ぐ効果がある
 • 議論がオープンに行なわれ、過去の決定も参照できるので チームの知識も増えていく
 • 全体が俯瞰できるように書くことで、 チームが設計全体を理解しやすくなる 
 
 
 © 2022 Cookpad Inc. 17 設計ドキュメント

18. • APIリクエストやパラメーター、レスポンスを 書く
 
 • APIがモバイルの都合に合うか
 • 既存のAPIや同時に作るAPI同士が整合性 が取れているか
 • APIの実装に無理がなさそうか
 
 © 2022 Cookpad Inc. 18 なにを書いてるの？ その1 API設計

19. • 全体のアーキテクチャやデータの流れを チームで理解できるよう図もあわせて書く 
 
 • 前述のAPI設計とあわせて、各APIの設計・ 整合性に問題がないかをみる
 • データの流れや、各アプリケーションの責務 に問題がないか
 
 © 2022 Cookpad Inc. 19 なにを書いてるの？その2 システム間の連携

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

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

22. • ドキュメントを常に最新に保つのはかなり大変 
 • 設計ドキュメントは実装の足掛かり、当時の記録として扱う
 ◦ 実装の変更にずっと追従させていく必要はない
 ◦ 開発期間中はメンバーが混乱するので更新していく 
 
 
 
 
 © 2022 Cookpad Inc. 22 一時的なドキュメントとして割り切る
 貯めこまれていく当時の記録 

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

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

25. • 「今」の問題に立ち向かうため、 チームのナレッジやコミュニケーションの向上に取り組んだ 
 • 試してきた中で「設計相談するチャンネル」「ペアプロ」「設計ドキュメント」が有効だった 
 • 一方で技術的に認知負荷が高い状況の改善には別途取り組んでまいります 
 
 
 © 2022 Cookpad Inc. 25 まとめ

26. © 2022 Cookpad Inc. 26