半年間アジャイル開発に参画してみて学んだこと

こんにちは、フォースタートアップス株式会社のエンジニアの李です！今年の4月に新卒で入社後、STARTUP DB（スタートアップデータベース)（以降SDB）の開発チームに参画し、半年経ちました。早いものですね。

（入社直後にこんな記事を書いています！もしよろしければ合わせてご覧ください！）

tech.forstartups.com

今回のテックブログでは、入社してからの半年間で体験したSDBチームのアジャイル開発についてまとめていきます。

SDBチームの雰囲気はどんな感じ？
アジャイル開発をどのように進めている？

本稿を通じて、これらの疑問が少しでも解消されれば幸いです！

技術的な振り返り：主にFindy Team+というツールを活用しています。中でも、サイクルタイム分析といってプロセス別の開発リードタイムを時系列で可視化しできる便利な機能があります。それらを用いてボトルネックを洗い出したり、タスクの進め方を見直します。

レトロスペクティブ（振り返り）：スプリントの進め方の改善点やチームポリシーを見直します。振り返りの手法は「スピードカー」「闇鍋」「KPT」などを取り入れ、楽しみながら進行しています。（参考）

チームポリシーと入っても必ず守らねばいけない、堅いようなものではありません。もちろん特別に理由なければチームでルールを守りますが、変更が必要ならばその都度変更するといった非常に柔軟性あるチームの取り決めです。

2. 行われる改善プロセス

SDBチームでは、どのようなアジャイル開発の改善プロセスが行われるのか、私が経験した失敗と合わせて紹介していきます。

出来事

実務に参画してからおよそ4か月が経った頃、私が原因でスプリントゴールが未達成になってしまったことがありました。

SDBはElasticsearchという全文検索エンジンを使用していますが、当初私はキャッチアップの難しさから関連タスクを敬遠していました。あるスプリントプランニングで、Elasticsearchの検索ロジックを作成するタスクがゴールに設定され、私は「挑戦してみよう」と意気込んでこのタスクを取りました。

実際に取り組んでみると、予想以上に難しく、参考コードがあるとはいえ、理解するのに丸二日を費やしてしまいました。それでも「急げばまだ間に合うかも」と考え、チームメンバーと相談せずそのまま進めてしまいました。結果、プルリクエストを出せたのはスプリント最終日の終業時刻3時間前でした。

その後チームメンバーが集まってその場でレビューをしていただけましたが、タスクの要件を満たせていないことと、大量の修正箇所が見つかりました。間に合わないことを上長に報告し、スプリント未達成となりました。

個人の振り返り

振り返ると、早い段階で「間に合わない」と共有できなかった原因は以下のような理由からです。

足を引っ張りたくない：スプリントゴールはチームで決めた「約束」です。それを守れないと、エンジニアチームだけでなく他の部署にも迷惑がかかると感じました。
もしかしたら間に合うかも：経験がない領域にも関わらず、「希望的観測」に頼ってしまいました。これは心理的な現象で「楽観バイアス」と呼ばれています。心理的な負荷がかかった際に、安定のため自分に都合の良い結果を無意識に期待してしまう傾向があるそうです。

チームメンバーからのフィードバックと改善策

振り返りでは以下のアドバイスをいただきました。

スプリントゴールはチームで決めた約束だが、早い段階で『間に合わない』と共有できればヘルプに入れるし、ゴール達成が可能になる。
タスクをやりきる責任も重要だが、「間に合わない」ことを担当者個人だけの失敗として抱え込まないでほしい。
私たちは開発チームだけでなく、営業チームやデータベース運営チームと一体となってユーザーに価値を届けている。そのため、チーム全体の成功を目指して行動してほしい。

この振り返りを受けて、以下のようなTRYが挙げられました。

1日目にPR（プルリクエスト）を出す見通しを立てる
2日目にPRが出ていなければヘルプを要請する
PRが出ていない場合はチームメンバーが声をかける
進捗状況をSlackの専用チャンネルにて共有する

チームは「誰がやっても同じ結果が出せる安定した仕組み」を目指し、改善策の議論を進めてくれたのです。このTRYを意識することで、今ではスプリントを安定して達成できるようになりました。

このように、課題があってもチーム全体で解決に取り組み、成果を出せる環境が整っています。失敗を次の改善につなげる仕組みが定着したことで、個人の成長だけでなく、チーム全体の信頼感も高まっています。

3. チームポリシーの構築

「1. SDBチームのアジャイル開発の進め方」にて紹介した5日目（スプリント最終日）：振り返りについて紹介しようと思います。 SDBチームでは、振り返りを行うたびに、チームポリシーを更新しています。実際に使われている下記の例をご覧ください。

Problem1: レビューと修正の往復でApproveまでが長い

背景：担当者やレビュワーがそれぞれのタイミングで作業を進める運用をしていました。そのため、コード修正や修正点の確認が迅速に行えず、作業が翌日に持ち越されることが頻発していました。

Action：スプリント2日目にレビュー会を開催

Findyのサイクルタイム分析を元にした技術的な振り返りを経て、チームポリシーとしてスプリント2日目に1時間のレビュー会を設けました。レビュー会では、レビュワーがチケット担当に対し口頭で修正箇所を伝え、チケット担当者はその場で修正を行います。

結果：レビュー＋修正の往復が短縮されただけでなく、進捗が遅れているタスクも早期に発見できるようになりました。

Problem2: 進捗共有が不足

背景：タスクの進捗状況をその日の終わりに専用チャンネルにて共有する習慣はありました。しかし、内容が確認されず放置されがちでした。

Action：朝会で進捗確認の時間を設ける

結果：メンバー全員がどのタスクで詰まっているか、誰が手が空いているかを把握しやすくなり、助け合いが促進されました。

非常にシンプルですが、problemが書いてあることによって、なぜこのチームポリシーを守った方がいいのかが明確なため、実行に移しやすいです。

チームポリシーが形骸化しないために

毎週新しいルールを追加し続けると、それを守ること自体が負担となり、ポリシーが形骸化する恐れがあります。そのため、チームでは各ポリシーに対して「継続」「定着」「廃止」のstatusを設け、ルールの実効性を確認しながら運用しています。

継続：Actionに記載された取り組みを試行している段階
定着：ルールがチーム文化として定着し、意識せずとも守られる段階
廃止：他に良い方法が見つかった、または試行したものの課題解決に至らなかった場合

振り返りでは現行の各ポリシーのステータスが適切かを定期的に話し合う時間を設け、必要に応じて見直しています。この仕組みにより、ポリシーが形式的なものに留まらず、チームの実状に応じた内容へと最適化し続けることができます。

また、ポリシーごとの現状を把握し、チームで定期的に話し合う場を設けることで、各自の意見や提案も取り入れやすくなります。これにより、メンバー一人ひとりが主体的にポリシー運用に関わる意識が育ち、形骸化することなく、実際に機能するポリシーとして活かされています。

4. まとめ

SDBチームのアジャイル開発には、単に効率的な進行だけでなく、メンバー個々の成長やチーム全体の連携を促すための多くの工夫が盛り込まれています。

高速なトライ＆エラー

1週間という短いスプリントサイクルでの開発は、成功と失敗のフィードバックが速く、次に繋げやすい環境です。失敗から学び、それをすぐに改善に結びつける姿勢が、私たちのチーム文化に根付いています。これによって、個々のエンジニアが日々成長できる場が提供されていると感じています。

助け合いとチームワーク

アジャイル開発では、メンバー全員が目標に向かって協力する姿勢が求められます。日々の進捗共有や振り返りを通じて一体感が生まれ、各自が互いに支え合う信頼関係が築かれています。

成長しやすい環境

振り返りやポリシーの見直しは、チームの成長を促す上で重要な役割を果たしています。改善プロセスを実践し続けることで、個人のスキルアップだけでなく、チームのパフォーマンス全体も向上しています。形骸化せずに柔軟に変化を続けるポリシー運用のおかげで、アジャイル開発が実際の業務に密着したものとして機能している点も特徴です。

このように、SDBチームは一人ひとりが挑戦と成長を続けられる環境です。半年間で培った経験を活かし、さらなる高みを目指して、日々の取り組みを積み重ねていきます。

当社では、エンジニアを募集しています。アジャイル開発に興味がある方、成長意欲のある方、ぜひ私たちと一緒に挑戦してみませんか？

herp.careers

P.S

最近オフィスが麻布台ヒルズ森JPタワー 31Fに移転しました！