プロダクトマネージャーの鈴木 @kecholです。今日は「Assured」でのチーム開発の様子をお伝えしたいと思います。
チームの体制
「Assured」の開発チームは小規模な1チームです。PM1名（私）、エンジニア4名（うち業務委託1名）、デザイナー1名というチーム構成となっています。また、これ以外に、副業で開発を手伝ってくださっているメンバーが数人います。
「Assured」では現在（2022年5月）、基本的に週3リモートワークという形で仕事をしていますが、業務委託や副業のメンバーはフルリモートのため、基本的にミーティングはオンラインを前提として行っています。最近、会社から高性能イヤホンの Shokz が配布されたのですが、これを利用し出社しながらも全員が自席からミーティングに出席するくらいにはオンラインでの進行が当たり前になっています。
ゆるスクラム
「Assured」では二週間スプリントのゆるいスクラムを実施しています。二週間ごとに Planning、Review、Retrospective を実施しています。Sprint Planning は開発チームで行い、Sprint Review には営業メンバーやCSメンバーも含めたほぼ全員が参加しています。
「ゆるい」と書いたのは、現状「Assured」では Sprint Backlog となる開発アイテム（チケット/Issue）の厳密な見積もりを行っていないからです。開発チームのベロシティについては各 Sprint で消化した Issue 数を記録し、振り返ることとしています。また、Daily Scrum や Refinement といった日々の進捗確認やタスクの再調整は週1-2回実施する形で収まっています。今のところこれくらいのスクラム運用でも開発はうまく回っていると思います。チームとしても会話した上で、そうしたMTGや運用の厳密さよりも、各々が自律的に開発タスクを進めコードを書く時間を捻出することに重きを置いた働き方をしています。
タスク管理
実際の開発タスクは、GitHub Projects (beta) を利用して管理しています。GitHub を利用しているのは、実際のコード/commit と Issue が双方向にリンクされ、後からその変更のコンテキストを追いやすいからです。普段は Sprint 内の開発ステータスをカンバン上で閲覧することが多いです。
Projects (beta) では、レイアウトをテーブルとボードで切り替えたり、Issue にイテレーションやマイルストーンを設定したりできます。現在は見積もりをしていないと前述しましたが、見積もりポイントをIssueごとに入力することも可能です。まだ beta が取れていませんが、 GitHub ヘルプを覗くとインサイトの可視化や自動化ワークフローの設定など、私達のアカウントではまだ使えない機能も紹介されており、今後にも期待できるツールだと感じています。
開発タスクは機能ごとに Issue を作成しています。Issue 単位でタスクのアサインがされるので、エンジニアはバックエンドとフロントエンド、ときにはインフラを横断して機能の実装を行っています。
リリース
本番へのリリースも Sprint に合わせて二週間に一度としています。コードは、リリース前に検証環境で HappyPath（正常系の業務フロー）の QA テストを行ったうえで、リリースブランチへのマージをフックとして GCP の CloudBuild からデプロイされます。
デプロイ頻度はどんどん上げていきたいと考えており、最近は Autify の導入により HappyPath を毎日流せる環境を整えたり、GitOps によるデプロイフロー構築のためにインフラを整えるといったことにも取り組んでいます。
また、まだ開発/検証中の大きな機能は Feature Flag/Darklaunch の機構を利用して main ブランチに早めにマージすることで、漸進的に開発を進められるよう工夫しています。早く Feature Flag を公開できないかと、うずうずしながら開発に取り組んでいます。
リリースされる機能については、Sprint Review の際にデモするほか、Notion にもまとめて「Assured」のメンバー全員に公開しています。
マイルストーン
「Assured」では事業部全体で3ヶ月ごとの OKR を設定しており、開発チームではそれに合わせて3ヶ月ごとの開発マイルストーンを設定しています。まだ運用が始まったばかりなので安定していないところもあるのですが、ビジネスと足並みを揃えた目標設定とプロダクトによる事業貢献によって、事業部全体でサービスを良くしていけているという雰囲気を作っていけたらと思いそのように運用しています。
また、運用してみると大きな機能開発がこうしたマイルストーンとして設定しやすいのですが、お客様からの小さな機能要望への対応や負債を作らないための改善も重要だと考えており、実際の開発の中ではマイルストーンの開発と改善のための開発をバランス良くタスク化することを心がけています。大きな機能開発はフィードバックサイクルが長くなってしまい、チームとして何をしているか外から見えにくい状態やお客様とのコミュニケーション頻度が少なくなってしまうような状態に陥りやすいため、チームのモメンタムのためにもそうしたバランスを維持していきたいと考えています。
普段の開発の様子
「Assured」では、それぞれメンバーが特定の言語に強かったり、ドメイン知識を持っていたりする場合があるので、ペアプロをすることもよくあります。ペアプロを通して知識を共有することで開発効率が上がったという声も多く、これからも積極的に実施していきたいと考えています。
アーキテクチャやチーム運営上の提案は週1のエンジニア定例で実施しています。特にアーキテクチャについての提案は Architectural Decision Records (ADR) を Notion 上に作成し、議論の記録が残るように意識しています。
ADR テンプレートはこんな感じです。
# （タイトル）
## 提案背景
### 現状の課題と期待する効果
-
### 議論の前提
-
### 参考情報
---
## 提案内容
### 提案したいオプション
Aを導入する
- Pros
- ここがいいところ
- Cons
- ここが悪いところ
**補足**
**参考情報**
### その他のオプション（1）
Bを導入する
- Pros
- ここがいいところ
- Cons
- ここが悪いところ
**補足**
**参考情報**
---
## 決定事項
**結論**
**運用上のルール**
-
---
## 結果
- 期待した効果が得られたか得られなかったか
- 今後の採用に向けての注意点
---
## 議事録
-
ちなみに Notion には、それ以外にもオンボーディング資料やシステム課題のリスト、ポストモーテムのリストなど様々な開発ドキュメントをまとめています。
というわけで、「Assured」でのプロダクト開発の様子をお届けしました。
今回の記事を通して「面白そう！」「自分ならこうするかも」などありましたら、「Assured」を通して世の中の変化を加速させていく仲間を絶賛募集中ですので、ぜひカジュアルにお話してみませんか？お待ちしております。 forms.gle
