🌊

SaaSを支える開発戦略・マネジメント/GraphQL、Flutter、大規模チーム開発、スクラム

1 min read

概要

2021/08/04に開催された下記勉強会のメモです

https://rakus.connpass.com/event/217886/

セッション

ラクスの技術スタックを新陳代謝し開発を加速させる取り組み

  • 技術力に関する危機感から新技術を調査・検証する専門の組織を立ち上げた
    • 技術推進課(4名)
  • 危機感を解決するための取り組み
    • 技術ロードマップを作成
      • 5年後までに開発部が必要とする技術をまとめる
      • 毎年更新
    • 技術推進PJ
      • 週5hの稼働で半年間(業務時間として取り組み)
      • 調査・検証・成果発表を実施
        • 事例としてはGraphQLやFlutterなど
        • 下記ブログ参照

https://tech-blog.rakus.co.jp/archive/category/かみせん

若手育成と機能開発を両立する開発戦略〜新機能開発を若手チームに任せてみた〜

  • 若手だけのチームに開発案件を任せてみる
    • 課題
      • 品質、納期
    • 対策
      • シニアメンバーのフォロー
      • 開発期間の確保
    • 段階を踏んで権限を移譲
      • プロジェクト管理や品質面はシニアエンジニア->シニアエンジニアは支援のみ
  • 見守れ、なんとかなる

スクラム開発チームをLessでスケールさせた話

  • 1スクラムチームだったが人数が増えたきたため大規模スクラムを導入した
  • Lessの採用
    • 1チームスクラムとの差分が少ない
    • 単純明快
      • ↓が秀逸

https://less.works/jp/less/framework/coordination-and-integration
  • 不公平感が出ないようにチームを分割
    • ○○さんチームや○○機能チーム名は避ける
  • 2チーム一緒に朝会をやっているが15分程度ですんでいる
    • 他チームへ偵察するプラクティスを取り入れたが、全員参加で良いとなった
  • 振り返りのファシリテーターは持ち回りで手法もお任せ
    • 他チームへ感謝を伝える時間を入れている
  • デモの担当も当番制
  • 運用は当番制、担当する人もローテーション
  • 情報の受け渡しなどのオーバーヘッドは増えたが必要なコストの範囲

Discussion

ログインするとコメントできます