🀄

チーム開発の変遷と現在地

2024/12/08に公開

この記事は、ビットキー Developer Advent Calendar 2024の8日目です!

1. はじめに

2023年1月に入社しこの2年間でチームの営みが少しづつ改善していると感じているので、今回は弊社のアドベントカレンダー用の記事という枠でもありますので、現在のチームと日々の取り組みを紹介したいと思います

bitkeyで、homehubプロダクトの主にWebアプリケーションおよびサーバーサイドの開発をしているチームでマネージャーをしていますysmtです

この記事を通して、私たちのチームがどのようにプロダクトの開発に取り組んでいるのかを知っていただければ幸いです

2. チームを取り巻く環境

homehubはbitkeyが提供する「暮らし」をターゲットにしたプロダクトです

『「暮らし」は、もっと便利にできる』をテーマに
自宅のカギや宅配ボックスの操作、クリーニングや家事代行の手配もたったひとつのアプリから。「暮らし」のあらゆる体験をオールインワンで支援します。

Bitkey Recruiting Book

エンジニアチームは、モバイルチームとWebチームがあり、私が所属するWebチームでは主にtoC, toB向けのWebのアプリケーションおよびサーバーサイドアプリケーションの開発を担当しています

2024.12現在、6名のメンバーが在籍しておりフロントエンド、バックエンドの垣根なしに開発に取り組んでいます

(2023年加入: 3名 / 2024年加入: 3名)

記載の通りチームメンバーは2年以内に入社したメンバーで構成されているのですが、

それ以前から賃貸、分譲をはじめとした、暮らしにまつわる広い領域の機能群、サービス群を提供しておりそれらの保守と機能開発を担う必要があり日々、施作と改善を繰り返しています

2週間サイクルで開発、リリースを行なっており、
大まかに1週目は開発、2週目に評価、FB対応、リリースという流れで進めています

3. チームの取り組みの変化

3-1. モブプロの導入

チームとして2023年後半からモブプロを導入しています

モブプロを採用する目的はいくつかありますが、例えば以下のようなものが挙げられます

  • 属人性の高さや、ドメイン知識の広さ、複雑さに対抗したい
  • 各自がそれぞれのチケットを個別に対応することで、上記と相まってレビューコストが高くついていたことを解消したい

▼ 広いドメインについてご興味のある方はhomehub事業の変遷について

[第一弾] IoTスタートアップの事業の変遷とドメインの進化 - Qiita

結果的に

  • レビューコストは低減され
  • 手戻りは小さくなり
  • (合わせて)滞留するPRの数も減った
  • 属人性も緩和され、誰でもFB対応ができるようになった

などの効果をもたらしてくれました

また、当初はすべてのチケットをチーム全員でモブプロを行い対応していましたが、当然ながら効率悪くなってしまう部分もあるので、現在は以下を目安に使い分けています

  • 全員でのモブプロ … チームの半分以上が開発したことがない機能
  • ペアプロ、全員ではないモブプロ … チームの半分以上が開発したことがある機能
  • 個人 … 全員が開発をしたことがある機能 or 戦略的にしばらく開発予定がない

など

リリース後の振り返りを通して試行錯誤しています

▼ より詳しいモブプロの取り組み背景などについて

モブプロ始めてみた 〜導入から3ヶ月で見えてきたメリットと課題〜 - Qiita

また輝く瞳を取り戻すために / To get your eyes shining again.

3-2. スプリントタスクとその他の活動の変化

新しいスプリントが開始される際「今回はいいプランニングができたなぁ」などと、

思ってはいたもののスプリントに関わる活動の阻害要因は度々発生するものです

もちろん、スプリントよりも優先するものもありますが全てがそれに当てはまるわけでもないので2024年前半に日々の活動の基本の指針として以下のように定めました

主にスプリントに関わる活動を安定的におこなえるように、日々の活動を大まかに、1日の半分を「スプリント活動」、もう半分を以下のような「その他」の活動に割り当てる

  • MTG、スクラムイベント
  • 市場で起きている不具合やその他要望等への対応
  • スパイクなど次以降のスプリントの準備

など

その他の中でも特に、「市場で起きている不具合やその他要望等への対応」については場合によってはスプリントよりも優先する必要があるためいくつかのルールのもと優先度判断し

  • 毎日、緊急性等から優先度をつけて順に担当者をアサインし対応
  • インシデントについては週次で、ポストモーテムの枠を設けて実施

するようにしています

上記の対応も以前は、スプリントごとに担当者を1名つけて対応にあたっていましたが

これも属人性につながる部分だったのでチーム全員で見るようにした上で

(緊急性にもよりますが)対象領域のドメイン知識が少ないメンバーにアサインしたり、ペア作業したりすることでなるべく属人性の緩和にも繋げるようにしています

結果として、

  • スプリント活動に使えている時間の見える化に寄与
  • 市場で起きている問題の解決が安定的に行える

などの効果がありました

▼ インシデントマネジメントについてはWaroomというツールを用いてます

Waroomを使って ハードウェアからソフトウェアまで 領域横断してインシデントマネジメント始めてみた /I started incident management using Waroom across domains from hardware to software.

3-3. 見積もりの改善

チームでは2週間スプリントでのスクラムを用いた開発をしており、ストーリーポイントの見積もりには2023年の後半頃からプランニングポーカーを用いています

はじめた当初は開発チームだけでリファインメントを実施しており、

各自にアサインされたストーリーについてスプリントタスク以外の時間で調査してきた内容の共有、共有を受けての見積もりを実施するという形で、頻度は毎朝15分+プランニング前日に1時間というものだったのですが

調査する時間が取れずにリスケとしてしまうことも多くプランニング直前に解像度の低い状態で急いで見積もり、結果として考慮漏れなどで想定以上に開発工数が跳ねるなど散見されていました

また、プランニングポーカーの際には、投票した根拠についての理由を求められた際に、解像度があまり高くないので、

(恐る恐る)「2と3で迷ったんですが…かくかくしかじか」

のような票が集まっているところに便宜を図る戦法が横行していましたw

詳細は割愛しますが、プロダクトバックログ運用・リファインメントの見直しにより

  • 「共有」「明確化」「見積もり」のステップを設けることで段階的に解像度を上げていけるようになった
  • リファインメントへの開発チーム以外のステークホルダー参加による実現したい価値や優先度根拠の理解促進ができるようになった

など

また「3-2. スプリントタスクとその他の活動の変化」でも述べた時間確保、ドメイン知識の底上げも相まって、見積もり精度は徐々に向上していると感じます

※ 精度の向上は、見積もり時と開発後で実際ストーリーポイントどうだった?を振り返り記録しています

3-4. リリース後

2週間の開発を終え、無事リリースを完了した後は、お疲れ様会を実施しています!

こちらは、チームで輪読したゾンビスクラムサバイバルガイドの「お祝いケーキを焼く」から着想を得て実施するようになった活動でして、私たちのチームでは大抵、雀荘に麻雀を打ちに行きます!(もちろん、健康麻雀です)

ゾンビスクラムサバイバルガイド - 丸善出版 理工・医学・人文社会科学の専門書出版社

以下は、現時点での今年の最高打点となります!(来年はダブル役満を出したい)

3. おわりに

ここまで長文にお付き合いいただきありがとうございました!

それぞれの取り組みの詳細については今回の記事では割愛させていただきましたが、どこかで深ぼれたらと思っております…

同じような課題を抱えるチームのヒントになったり、

弊社のことや弊チームに興味を持っていただけたら大変嬉しく思います

9日目の 株式会社ビットキー Advent Calendar 2024安達 が担当します。

Bitkey Developers

Discussion