【Retty x アカツキゲームス x atama plus】LeSS導入の最前線、リアルとこれからに参加した

ちょっと前の勉強会の感想が溜まってきてしまっているので色々自分の中の知識の整理をしていきます。

前半部分LeSSの導入してみてというところだけ聞いている感じです。（後半のパネルディスカッションについては諸事情により聞いていません）

勉強会URL

【Retty x アカツキゲームス x atama plus】LeSS導入の最前線、リアルとこれから - connpass

ハッシュタグ検索

https://twitter.com/search?q=%23LeSS%E6%9C%80%E5%89%8D%E7%B7%9A

メモ

前から書いていっていますが、割と雑多にまとめているので、どこのどの発表だったかは記憶が曖昧です。

なぜスクラム、LeSSを導入するのか？
- マネージャーの上手さ＝プロジェクトの成功、プロダクトの成長となるような属人性を排除するため
  - ただしプロダクトの開発速度の維持のため、一時的には許容して、その後属人化を剥がしていく動き（各社ともありそうな感じだった、プロダクトのリリースと属人化を避けたフローに完全にしていくというバランスを考えると仕方なし）
- 更にLeSSを導入する理由としては、各スクラムチームがサイロ化して最適化されることを防ぐため
  - そこだけ改善されても、全体が改善されなければプロダクトとしてのアウトカムを生みにくい
トラベラー
- （知らなかったワードの一つ）
- 調整と統合 - Large Scale Scrum (LeSS) あたりに乗っている
- 一時的に他のチームからスクラムのメンバーとして参加し、ノウハウを共有する役割の人
  - 例えばフロント、バックエンド療法を作ることができるメンバーがいるとしても濃淡があるので、特に専門性の高い人に参加してもらうなど。あるいはドメイン知識が豊富なメンバーに入ってもらうなど。
- スクラムマスターが複数チームのスクラムイベントに参加して、ノウハウやドメインの共有を行うというやり方もできる
- それとは別に横断的にスキルセットで相談できるような仕組みも用意する
LeSSはチームビルディングに役立つ？
- チーム内でのレビューに切り替えることにより、レビュー速度の向上とフィードバックの増加傾向が見られた
  - バザー形式のスプリントレビュー - tuneの日記
- フロー効率とリソース効率について思うこと - タマネギプログラマーの雑記
  - 大きなタスクをフロー効率なやり方で分解するよりも、リソース効率なやり方で分解し、機能を小さく早く出す仕組みづくり
- 勉強会
  - スクラムや技術的な各トピック
  - 新しく入った人が見られるように動画に撮っておくと尚良
    - （同管理してるんだろうっていう疑問はあったけど回答されたか記憶がない）
- POが要望だけ考えて、詳細な実現方法は開発チームで行うなどというアイディアもある
オーバーオールレトロスペクティブ
- （この辺はLeSS特有の言葉っぽいのでまた調べる）

前述したとおりパネルディスカッションには出ていないので、これ以上はメモがないです。

そしてよく見たら資料公開されてました（Connpassにリンクされていました）

まとめ

一応LeSSは下記の本で読みましたが、実例を聞くと現実的なリリースやプロダクトの状況に合わせたカスタマイズが必要という印象です（スクラムも結局チーム構成としてあるべき形を模索した結果、適用を考える必要があるのでそれはそうという感じ）

大規模スクラム Large-Scale Scrum(LeSS)

Amazon

しかし全体を最適化するという観点だと、システムの一部分だけでスクラムをしていても仕方がない気がしてきます（やるなら全体でスクラムに取り組んで、LeSSやLeSS Hugeにいくのがありそう）。プロダクト視点で見てもどう開発していくか考えていく必要がありそうですし（LeSSを導入するしない、スクラムするしない、アジャイルするしない）、いろいろな示唆を得られた勉強会でとても良かったなと思っています。