Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

AKAMATSU Yuki

October 22, 2022
Tweet

More Decks by AKAMATSU Yuki

Other Decks in Programming

Transcript

  1. © 2022 Cookpad Inc. 2 • @ukstudio
 • クックパッド株式会社 レシピサービス開発部

    
 • バックエンドエンジニアのテックリード 
 • Splatoon 3、ダーツ
 • 最近はRailsアプリケーションにどう型を導入するか興味があ ります
 ◦ でも今日は型の話どころかコードも一切でません 
 自己紹介

  2. © 2022 Cookpad Inc. 6 なぜこのような状況に陥ったのか
 • 大きめの組織体制の変更による人員の異動 
 ◦

    流入が多め
 • 事業はフォーカスしたが、施策の実現粒度で見る と開発するアプリケーションの数が 
 増えた
 

  3. © 2022 Cookpad Inc. 7 なぜこのような状況に陥ったのか
 • 大きめの組織体制の変更による人員の異動 
 ◦

    流入が多め
 • 事業はフォーカスしたが、施策の実現粒度で見る と開発するアプリケーションの数が 
 増えた
 
 あまり触ったことのない 複数のアプリケーションを開発しなくてはいけない = 大変!!
  4. • 開発がスムーズに行くように、チームのナレッジを増やす 
 • 問題発覚が後の方ほど大変なので、より前に気づけるようにする 
 
 
 
 


    © 2022 Cookpad Inc. 8 どうする?
 もちろん技術的に改善しなくてはいけないこともあるがここではスコープ外。 
 技術的なところにも興味がある人は別途話しましょう。 
 

  5. • シンプル & コストがかからない
 • 手戻りを防ぐことができる
 • 自然とメンバーに知識が共有されていく 
 •

    気軽に意見していいんだという雰囲気が作られていく 
 
 © 2022 Cookpad Inc. 10 専用の場所がある方が発言のハードルが下がるっぽい

  6. • 最初は発言がないかもしれないので、 自分の設計や実装について質問をしていく 
 • 誰かの質問がスルーされないように気をつけること 
 ◦ 最初のうちは自身が積極的にコメントしていく
 ◦

    わからない時はわからないみたいな返事をしても良い 
 ◦ 誰か詳しそうな人が思い浮かぶならその人にメンションしてみるのも良い 
 
 © 2022 Cookpad Inc. 12 過疎らないようにする

  7. • 知識の伝達という観点では常時ペアでなくても良い
 ◦ チーム全体が慣れてきている領域はソロで開発してもあまり問題にならない 
 ◦ 知識・経験の差が大きい領域にフォーカスする 
 • 我々の場合


    ◦ 朝会でタスクを取る時に、経験が浅い領域を担当する場合ヘルプを求める 
 ▪ もしくはまわりからペアプロを提案する
 • 意外と人は助けを求めるのがうまくないので提案するのおすすめ 
 
 
 © 2022 Cookpad Inc. 15 導入にあたって

  8. • 設計ドキュメントに書くことはチームやチームのフェーズによって違う 
 • それなりに頻繁にドキュメントを書くのであまり重厚なドキュメントにはしない 
 ◦ = 書くことの取捨選択が必要
 •

    例えば、我々はクラス図はかかないが(詳細すぎる)、モノリシックアプリケーションやビジネスロ ジックが複雑な場合は有効かもしれない 
 • 手戻りの手間が無視できる程度の場合、コードを書いてしまう方がいいこともある 
 
 
 
 
 
 © 2022 Cookpad Inc. 20 書く項目は自分たちでしっかりと考える

  9. • 技術的な仕様・設計についてのドキュメント
 ◦ 施策・機能の要件などは別のところで( Issue、Figma ) 
 • コミュニケーションにおいて必須な項目かつコード書くより前に擦り合せたいもの 


    ◦ APIレスポンスなど
 • 設計全体を俯瞰できるようにする
 ◦ 特にデータの流れ、システム間連携は意識している 
 • チームにとって未知なもの
 ◦ チームがあまり経験していなさそうなアーキテクチャやライブラリの採用 
 ◦ 開発経験の少ないアプリケーションとの連携 
 
 
 
 © 2022 Cookpad Inc. 21 書く内容で意識しているポイント

  10. • 設計ドキュメントが後続のタスクのブロッカーになりがち なのでそこは意識しておく
 ◦ ドキュメント書く前にあつまってガッと設計するのもあり 
 • 一緒に書き進める場合は Google Docs

    が便利 
 ◦ 一方でドキュメントが死蔵しやすいので注意 
 • 自分たちは基本的に GitHub Enterprise に Markdown を保存している 
 ◦ レビューしやすいが一緒に書くにはちょっと不便なので必要に応じてGoogle Docs を使って いる
 
 
 
 
 © 2022 Cookpad Inc. 23 書き進め方

  11. • 書いたドキュメントが適切だったかはふり返ると良い 
 ◦ 情報に過不足はなかったか
 ◦ 実装時にわかりにくい箇所はなかったか 
 ◦ →

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