Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
今年できたチームの生産性を向上させたプラクティスの紹介 / Kaigi on Rails 2022
Search
AKAMATSU Yuki
October 22, 2022
Programming
4
4.9k
今年できたチームの生産性を向上させたプラクティスの紹介 / Kaigi on Rails 2022
AKAMATSU Yuki
October 22, 2022
Tweet
Share
More Decks by AKAMATSU Yuki
See All by AKAMATSU Yuki
Cookpad Tech Kitchen #24
ukstudio
0
730
Cookpad Summer Internship 2019 Day 1 Git
ukstudio
0
9.9k
Cookpad Summer Internship 2019 Day 1 Ruby TypeScript
ukstudio
0
9.9k
sdevtalks.org開発報告 / reporting that sdevtalks.org was launched
ukstudio
0
340
GraphQL on Rails
ukstudio
1
430
「なんでも」をしよう / 2018-12-19 s-dev talks LT
ukstudio
2
540
Rails Developers Meetup 2018 Extreme
ukstudio
0
3.2k
機能追加時における 仮説検証/s-dev-talks-01
ukstudio
0
960
Rails Developers Meetup
ukstudio
6
3.5k
Other Decks in Programming
See All in Programming
💎 My RubyKaigi Effect in 2025: Top Ruby Companies 🌐
yasulab
PRO
1
130
単体テストの始め方/作り方
toms74209200
0
410
Cloudflare Realtime と Workers でつくるサーバーレス WebRTC
nekoya3
0
370
Rails産でないDBを Railsに引っ越すHACK - Omotesando.rb #110
lnit
1
160
eBPFを用いたAIネットワーク監視システム論文の実装 / eBPF Japan Meetup #4
yuukit
3
730
カクヨムAndroidアプリのリブート
numeroanddev
0
390
KotlinConf 2025 現地で感じたServer-Side Kotlin
n_takehata
1
170
Parallel::Pipesの紹介
skaji
2
900
RubyKaigiで得られる10の価値 〜Ruby話を聞くことだけが RubyKaigiじゃない〜
tomohiko9090
0
130
ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化
knih
10
1.7k
型安全RESTで爆速プロトタイピング – Hono RPC実践
tacke_jp
0
110
Development of an App for Intuitive AI Learning - Blockly Summit 2025
teba_eleven
0
110
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Adopting Sorbet at Scale
ufuk
77
9.4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
106
19k
Building a Modern Day E-commerce SEO Strategy
aleyda
41
7.3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Building Applications with DynamoDB
mza
95
6.4k
Designing for Performance
lara
609
69k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
42
2.4k
Fireside Chat
paigeccino
37
3.5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
890
Transcript
© 2022 Cookpad Inc. 今年できたチームの生産性を向上させたプラ クティスの紹介 クックパッド株式会社 赤松 祐希 (
@ukstduio )
© 2022 Cookpad Inc. 2 • @ukstudio • クックパッド株式会社 レシピサービス開発部
• バックエンドエンジニアのテックリード • Splatoon 3、ダーツ • 最近はRailsアプリケーションにどう型を導入するか興味があ ります ◦ でも今日は型の話どころかコードも一切でません 自己紹介
© 2022 Cookpad Inc. 3 最初にチームが抱えていた問題を説明したあと これのプラクティスについて紹介していきます 今日紹介するプラクティス
設計を議論する チャンネルの 開設 ペアプロ 設計 ドキュメント
• 2週間のサイクルで開発を行なっているが、2週間のタスク完了率が50% • これが持続的に続き、また完了率の悪さからプロダクトの計画が不安定に © 2022 Cookpad Inc.
4 チームが抱えていた問題 ダウンしないバーンダウンチャート
© 2022 Cookpad Inc. 5 なにが大変? あまり触れたことのない アプリケーションの開発
マイクロサービス
© 2022 Cookpad Inc. 6 なぜこのような状況に陥ったのか • 大きめの組織体制の変更による人員の異動 ◦
流入が多め • 事業はフォーカスしたが、施策の実現粒度で見る と開発するアプリケーションの数が 増えた
© 2022 Cookpad Inc. 7 なぜこのような状況に陥ったのか • 大きめの組織体制の変更による人員の異動 ◦
流入が多め • 事業はフォーカスしたが、施策の実現粒度で見る と開発するアプリケーションの数が 増えた あまり触ったことのない 複数のアプリケーションを開発しなくてはいけない = 大変!!
• 開発がスムーズに行くように、チームのナレッジを増やす • 問題発覚が後の方ほど大変なので、より前に気づけるようにする
© 2022 Cookpad Inc. 8 どうする? もちろん技術的に改善しなくてはいけないこともあるがここではスコープ外。 技術的なところにも興味がある人は別途話しましょう。
© 2022 Cookpad Inc. 9 設計について相談するチャンネルの開設
• シンプル & コストがかからない • 手戻りを防ぐことができる • 自然とメンバーに知識が共有されていく •
気軽に意見していいんだという雰囲気が作られていく © 2022 Cookpad Inc. 10 専用の場所がある方が発言のハードルが下がるっぽい
• チャットでの議論や意思決定は流れていくうえに 参照しづらい • Issue や Pull Request、後述する設計ドキュメントに書くなど ストック情報に転記することをおすす め
© 2022 Cookpad Inc. 11 チャットはフロー情報であることを意識する フローからストックへ
• 最初は発言がないかもしれないので、 自分の設計や実装について質問をしていく • 誰かの質問がスルーされないように気をつけること ◦ 最初のうちは自身が積極的にコメントしていく ◦
わからない時はわからないみたいな返事をしても良い ◦ 誰か詳しそうな人が思い浮かぶならその人にメンションしてみるのも良い © 2022 Cookpad Inc. 12 過疎らないようにする
© 2022 Cookpad Inc. 13 ペアプログラミング
• 知識・経験のないアプリケーションの開発時に、経験のある人とペアを組む • ペアを組むことで問題が予防されるので 手戻りを防ぐことができる • 経験のある人とペアを組むことで、 知識が共有されていく
© 2022 Cookpad Inc. 14 ペアプログラミング 伝授 圧倒的成長 これはやらせで撮った写真
• 知識の伝達という観点では常時ペアでなくても良い ◦ チーム全体が慣れてきている領域はソロで開発してもあまり問題にならない ◦ 知識・経験の差が大きい領域にフォーカスする • 我々の場合
◦ 朝会でタスクを取る時に、経験が浅い領域を担当する場合ヘルプを求める ▪ もしくはまわりからペアプロを提案する • 意外と人は助けを求めるのがうまくないので提案するのおすすめ © 2022 Cookpad Inc. 15 導入にあたって
© 2022 Cookpad Inc. 16 設計ドキュメント
• 本人の設計スキルの向上やナレッジの獲得が期待できる • 実装より前の段階でドキュメントを書くことで 手戻りを防ぐ効果がある • 議論がオープンに行なわれ、過去の決定も参照できるので チームの知識も増えていく •
全体が俯瞰できるように書くことで、 チームが設計全体を理解しやすくなる © 2022 Cookpad Inc. 17 設計ドキュメント
• APIリクエストやパラメーター、レスポンスを 書く • APIがモバイルの都合に合うか • 既存のAPIや同時に作るAPI同士が整合性 が取れているか •
APIの実装に無理がなさそうか © 2022 Cookpad Inc. 18 なにを書いてるの? その1 API設計
• 全体のアーキテクチャやデータの流れを チームで理解できるよう図もあわせて書く • 前述のAPI設計とあわせて、各APIの設計・ 整合性に問題がないかをみる • データの流れや、各アプリケーションの責務
に問題がないか © 2022 Cookpad Inc. 19 なにを書いてるの?その2 システム間の連携
• 設計ドキュメントに書くことはチームやチームのフェーズによって違う • それなりに頻繁にドキュメントを書くのであまり重厚なドキュメントにはしない ◦ = 書くことの取捨選択が必要 •
例えば、我々はクラス図はかかないが(詳細すぎる)、モノリシックアプリケーションやビジネスロ ジックが複雑な場合は有効かもしれない • 手戻りの手間が無視できる程度の場合、コードを書いてしまう方がいいこともある © 2022 Cookpad Inc. 20 書く項目は自分たちでしっかりと考える
• 技術的な仕様・設計についてのドキュメント ◦ 施策・機能の要件などは別のところで( Issue、Figma ) • コミュニケーションにおいて必須な項目かつコード書くより前に擦り合せたいもの
◦ APIレスポンスなど • 設計全体を俯瞰できるようにする ◦ 特にデータの流れ、システム間連携は意識している • チームにとって未知なもの ◦ チームがあまり経験していなさそうなアーキテクチャやライブラリの採用 ◦ 開発経験の少ないアプリケーションとの連携 © 2022 Cookpad Inc. 21 書く内容で意識しているポイント
• ドキュメントを常に最新に保つのはかなり大変 • 設計ドキュメントは実装の足掛かり、当時の記録として扱う ◦ 実装の変更にずっと追従させていく必要はない ◦ 開発期間中はメンバーが混乱するので更新していく
© 2022 Cookpad Inc. 22 一時的なドキュメントとして割り切る 貯めこまれていく当時の記録
• 設計ドキュメントが後続のタスクのブロッカーになりがち なのでそこは意識しておく ◦ ドキュメント書く前にあつまってガッと設計するのもあり • 一緒に書き進める場合は Google Docs
が便利 ◦ 一方でドキュメントが死蔵しやすいので注意 • 自分たちは基本的に GitHub Enterprise に Markdown を保存している ◦ レビューしやすいが一緒に書くにはちょっと不便なので必要に応じてGoogle Docs を使って いる © 2022 Cookpad Inc. 23 書き進め方
• 書いたドキュメントが適切だったかはふり返ると良い ◦ 情報に過不足はなかったか ◦ 実装時にわかりにくい箇所はなかったか ◦ →
次の設計ドキュメントに活かしていく • 例えば ◦ 「アーキテクチャの全体やDWHとの連携がわからず、実装時に混乱した」 ◦ => 全体がわかる図を書くようになった © 2022 Cookpad Inc. 24 設計ドキュメントはふりかえるのが大事
• 「今」の問題に立ち向かうため、 チームのナレッジやコミュニケーションの向上に取り組んだ • 試してきた中で「設計相談するチャンネル」「ペアプロ」「設計ドキュメント」が有効だった • 一方で技術的に認知負荷が高い状況の改善には別途取り組んでまいります
© 2022 Cookpad Inc. 25 まとめ
© 2022 Cookpad Inc. 26