この記事はうるる Advent Calendar 2019 10日目の記事です。
※発言は個人の見解であり、所属する組織の公式見解ではありません。
はじめに
自己紹介
社会人歴は干支1周を余裕で超え、もうすぐ世に言うアラフォーになります。
10代の頃に思い描いたアラフォーとはかけ離れた精神年齢です。絶望です。でもエンジョイしてます。
これまで、エンジニアを軸に兼任としてバックオフィスから営業まで多くの職域を経験しておりまして、大切にしていることは**"チームで、楽しく、結果を出すこと"**です。
今年の３月に株式会社うるるへジョインし、組織のマネージャーと複数プロジェクトのスクラムマスターを兼任という状態におります。
この記事に書かれていること
この記事では、中期経営計画の中核の一つとなっている、自社プロダクトのフルリニューアルプロジェクトにおいて、オリジナルのスクラムフレームワークFeSSを作り、挑戦した（している）話です。
背景
開発チームの形成期
２０１９年の4月中旬から開発準備をスタートし、新しいプロダクトのコンセプト設定、現行プロダクトの技術的課題の洗い出しを始める。
当時、リニューアルプロジェクトアサインが決まっている開発メンバーは4名。
ルール・文化を形成することや、要件の明確化のため、２０１９年の５月中旬から、開発プロジェクトをスタートしました。
開発チームの混乱期から統一期へ
人員計画と大きな乖離もなく、プロジェクトメンバーが増え始めた状況で、それまでの開発チームの中心となっていたエンジニアの退職という大きな壁を乗り越えつつも、チームは出来上がり始めた状況でした。
また、チームの考え方や風土として、社員が決めて、業務委託と派遣は言われた通り実装するといった悶々とするような開発チームではなく、雇用形態に左右されず全員が当事者意識を持ってプロダクトに向き合うチームになれてきていました。
一方、様々なバックボーンを持つエンジニア間で、学習量や知識・経験の差など、いわゆるスキル勾配・スキル傾斜をはじめとする、チーム全体に対する課題感は見え隠れし始めていました。
開発チームの拡大により直面した課題
- マイルストーンに対しての漠然とした不安、焦り
- チームの拡大に伴い、意思決定速度の鈍化
- チームの拡大に伴い、情報連携のコスト増加
- エンジニア間でのスキル勾配
- ジョインタイミングの差による、発言者の偏り
- 雇用形態的に離脱リスクの高い業務委託、派遣の皆さんに依存したメンバー構成
では、どうするか？
スクラムの適した人数を上回る人数となったのでチームを分割することは早々に決めていたのですが、次に課題となったのは、どう分けるか？という点でした。
分け方で検討したこと
- ユーザー側と管理側の"作るもの"で分ける
- インフラ・サーバーサイド・フロントの"職域"で分ける
- 先発隊と後発隊の"役割"で分ける
- 完全にランダムで分ける
進め方で検討したこと
- スクラムオブスクラム
- LeSS
- SAFe
- DAD
- Nexus
検討して思ったこと
- 分け方って、状況に応じて求められるものが変わるんじゃない？
- 固定のチームって、チーム生産性は見えやすくなるけど、スキル勾配解消がしづらくない？
- 世の中に出ているフレームワークって、めちゃくちゃ理想のメンバー構成をベースにしているから、どのフレームワークでもそのままFitするか分からなくない？
- やり始めると、Fitしないツラミばかり見えてきそうで、モチベーション低下しそう・・・
決め手となったのは、行動指針に掲げた、失敗を称え、失敗に学べという考え方でした。
新しい挑戦してみたくない？
そういう、ポジティブな発想から、LeSSやスクラムオブスクラムの良い部分を活用し、新しいフレームワークを作り挑戦する決定をしました。
作ったフレームワーク
FeSSの詳細については、こちらを御覧ください。
やってみた感想
フレームワーク作るって難しい！！！笑
でも、都度見直したり、改善したりしながら育てていきたい！
（もしかしたら、改善し続けたら世に出ているフレームワークになっちゃうかもしれないけど。。。）
##最後に
チームで大小さまざまな課題に立ち向かっています。
もし、チームやプロダクトにご興味をお持ち頂けましたら、お声がけくださいませ。
是非ディスカッションさせて頂ければと思います。
Advent Calendar 10日目でした。
明日11日目は 若松和憲 さんによる記事を乞うご期待！
https://adventar.org/calendars/4548