やっぱりRemitAidにはチーム開発が合っていた-振り返り内容とカルチャーを添えて-
こんにちは!株式会社RemitAidのremitaid_wataruです。
RemitAidでは隔週で開発メンバーのみの振り返りを実施しています。
今回は、振り返りで議題に上がった内容を軸に、現時点でのRemitAidの開発方針やカルチャーを簡単にお伝えします。
振り返りの概要
隔週で30分程度の時間を設けて、開発メンバーのみで振り返りを実施しています。
議題は、開発メンバーが自由に持ち寄ります。
議題に対して議論を行い、改善に向けたネクストアクションを決めて実行します。
今回の議題
ここ最近1ヶ月、バックログに対してそれぞれのエンジニアが1人で黙々と開発を進めているが、果たしてRemitAidとしてベストな開発方針なのか、、、?
1つのバックログに対して全員で開発する方がよいのではないか?
議題提案の背景
上記議題について、個人的にもやもやしている点がいくつかありました。
- 一人で進めていると、期限には間に合うもののダラダラしちゃうな
- 細かい設計とか大丈夫かな
- なんかモチベーション落ちてきたな
- そういえば開発メンバー間の会話減った気がするな
- レビューの質と速度落ちてる気がするな
議論
上記提案の背景(かなり個人的な感情面)から議題を提案するに至りました。
しかし、個人的な感情をただただ話しても仕方ないので、客観的視点で理由を整理し以下のような図表にまとめ、議論の叩きとしました。
※赤字部分は特に共感を得られた部分
ポイントは以下です。
- 全員で1つのバックログを開発した方がリリースまでのリードタイムを短くできて、FBサイクルが早まる
- システムの品質向上が期待できる
- 属人化を防ぎ、ナレッジ化ができる
結論
議論の結果、開発メンバー全員からAgreeです!という言葉をいただけたので、現在仕掛かり中の開発から全員で1つのバックログを開発していくことになりました。
(次からではなく、今からすぐに実行に移せるRemitAid開発チームのアジリティが素敵)
もちろん会社の事業フェーズやカルチャーによって何が正解かは変わってくると思うので、継続的にチューニングしていこうと思っています。
...余談ですが、RemitAidにはカルチャーの礎ともいえる、以下の4つのバリューが存在しています。
- not “I” but “We”
- +α Value
- Fact Driven
- Giver
気になる方は会社HPを見ていただけたら幸いです。
改善の効果
全員で1つのバックログを開発してまだ2週間ですが、すでに以下のようなプラスの効果が出ているように感じます。
- 処理方針に対する議論が活発になった
- その結果
- システムの質が上がった
- メンバー全員のシステム理解度が向上した
- その結果
- 開発速度が格段に上がった
一方で課題としては、次のバックログへの移行をいかにスムーズにできるかがあります。
全員で開発に集中しすぎると次のバックログの着手までに、開発の待ち時間が発生してしまいます。
こちらについては、次のバックログのオーナーは、対応中のバックログが終盤になったタイミングで、次のバックログのPRD作成に着手することで、待ち時間を減らせるようにしています。
終わりに
今回は、個人的に感じてた感情面の違和感から、議題を提案し、開発方針の改善まで行いました。
個人的な感情から議題を提案するのは、好ましくないと思われるかもしれません。
ですが、まずはどうしてそのような感情になってしまったのかを正しく言語化することが大切です。
そしてそれを改善に繋げることが、チームとして会社として良い方向に進むのであれば、どんどん提案していくべきだと思います。
自分たちのチーム・会社は自らが良くしていくという気持ちが重要だと思うので、今後もわずかな感情の変化を敏感に感じ取り、適切に言語化して改善していくつもりです。
We Are Hiring!
RemitAid では一緒に働く仲間を募集しています。
興味がある方はこちらからどうぞ!
RemitAid とは...?
Discussion