小規模チームでの開発管理とスクラム

まえがき

こちらは GAOGAO Advent Calendar 2022 ことしもGAOGAOまつりです の 4 日目の記事として公開されています。

3日目の記事は mass-min さんの Google Apps Script で日次のバッチ処理を手軽に作ろう でした。
GAS を用いて特定の日に API を叩き、スプレッドシートに情報をまとめ、Slack に通知する自動化の方法を記事化していただきました。面倒な作業はどんどん GAS を使って自動化していきたいですね！

申し遅れましたが、T と申します。
スタートアップスタジオ GAOGAO にてエンジニアをしております。

2, 3 名のプロジェクトでスクラムを取り入れて開発を行いました。
初めてスクラムを取り入れた開発であった為、簡単に振り返りとまとめの記事となります。
間違いや、アドバイス等があれば是非コメントでお願いいたします！

結論

2,3 名のチームであってもスクラム、GitHub Project での開発管理を取り入れることで、開発効率が上がることがわかりました。
今後開発を行う際には、規模に関わらずスクラムを取り入れて開発したいと思っています。

スクラムとは

従来、スクラムは「スプリント」という通常 2 週間程度の作業セッションで行われます。各スプリントの終わりまでに特定の成果物を作成する必要があります。そして、それに加えてスクラムにはさらに 2 つのイベントがあります。「デイリースタンドアップ」は、その名の通り毎日 1 回行われます。デイリースタンドアップではチームが 15 分間話し合い、毎日の活動を調整します。2 つめのイベント「スプリントの振り返り」は、スプリント終了時に行われます。スプリントの振り返りは、「スクラムマスター」が主導する、チームでスプリントを振り返り、次回以降のスプリントに向けて調整する機会です。
https://asana.com/ja/resources/what-is-scrum

私のプロジェクトでのスクラム

チーム構成

• エンジニア 2 名　（後半からベトナム人エンジニアが１名増加）
• PO 1 名（プロダクトオーナー）

1 スプリント期間

一般的な 2 週間。

イベント

• スプリントプランニング（各スプリントの 1 日目に行いました。）
  • PO（Product Owner） との会議で Figma でデザインを確認しつつ Miro に記載したユーザーフロー図を活用しユーザーストーリーを把握、必要な機能を開発チームで把握します。
  • エンジニアチームで詳細設計を行います。
  • 詳細設計をもとにストーリーポイントの変更を行います。（おおまかなストーリーポイントは全ての開発が始まる前におおまかに設定しましたので、ここでは微修正を行います）
• デイリースクラム
  • 開発チームで毎朝 10 分ほど Gather というオンライン MTG ツールで集まりコミュニケーションをとりました。
  • 「今日やること」「今困っていること」を毎朝共有することで、チーム内での助け合いが生まれました。
• スプリントレビュー（各スプリント終了の 3 日前）
  • PO へステージング環境にて当スプリントで開発した内容を共有します。
  • PO から Product での修正点を 「必須」「尚可」「低」 の優先度に分けてご共有いただきます。
  • エンジニアチームは「必須」および「尚可」タスクをスプリント最終日までにできる限り完成させます。
• レトロスペクティブ（各スプリント最終日）
  • エンジニアチームで振り返りを行います。
  • このイベントについては、軽く振り返るだけであまり効果を産むことがなかったので反省しています。

GitHub での管理方法

Repository

本プロジェクトは下記のリポジトリに分かれています。

• Management Repository
  • 1 機能ごとの大きめのタスクを作成する。親 Issue と呼んでいます。
  • 各 Issue には「ユーザーストーリー」を記入。「誰」の「何が」できる機能で、どんな「効果」をもたらすかをできる限り記載しました。
  • 海外メンバーもいるため、英語にて記載しました。
• Front Repository
  • 親 Issue に紐づく Frontend のタスクを細かく作成しました。
• Api Repository
  • 親 Issue に紐づく Api のタスクを細かく作成しました。
• Infra Repository
  • 親 Issue に紐づく Infra のタスクを細かく作成しました。

Label

作成した各 Issue に対して Label を設定することで一眼で状況を把握できるようにしました。

• Management Repository
  • 「1」「2」「3」「5」「8」「13」「21」 のストーリーポイントラベルを作成。仕様確認終了時点で想定される工数からストーリーポイントを設定しました。
  • 「Product backlog」ラベルを作成し、後述のカンバンボードでの視認性を高めました。
• Api Repository
  • 「api」 ラベルを作成し、視認性を高めました。
• Front Repository
  • 「frontend」ラベルを作成し、視認性を高めました。

GitHub Project

GitHub Organization 配下に、「Project」を作成しました。
参考。前述の Label を設定しておくことで、管理しやすくなりました。

Kanban では下記のステータスを用意し、タスクを管理しました。

• No Status
  • ステータスがないもの。生まれたタスクを一旦全てこちらに入れます。
• Pbs （〜 ${期限}）
  • 「期限」は毎スプリントごとに修正してください。
  • Management Repository のタスクの中で本スプリントに該当するものを入れます。
• Tasks（〜 ${期限}）
  • 各 Repositories のタスクの中で本スプリントに該当するものを入れます。
• In Progres
  • 各 Repositories のタスクの中で作業中に該当するものを入れます。
• Reviewing
  • 各 Repositories のタスクの中でレビュー中に該当するものを入れます。
• Done
  • 全ての Repositories のタスクで終了したものを入れます。

反省と今後

良かった点

• スクラムを取り入れることで、2 週間という枠組みの中でのゴールを設定することで、生産性が上がりました（と感じてました）
• ストーリーポイントを設定することで、各スプリントで私たちのチームが達成できる平均ポイント数が分かり、開発後半にかけて見積もりがうまくいくようになりました。
• GitHub Project を用いることで、タスク管理が簡単になりました。Asana 等外部サービスも検討したましたが、メンバーが頻繁に活用していた GitHub Project を利用することで、スムーズに開発を開始することができました。

反省点

• レトロスペクティブ
  • 開発チームでのみの実施となり、「いやぁ、本スプリントもお疲れ様でした！次のスプリントも大変ですが、やっていきましょう！」 という、反省ではなく労いの会になって、特に意味をなさなかったです。（これはこれで良いかもしれませんが...w）
  • PO を交えて、当スプリントでの 「修正点の数」 や、仕様の認識齟齬によって生まれた乖離を把握し、次のスプリントではそのような乖離がないようにする MTG にすることでもっと効果を持つレトロスペクティブになったのではないかと考えています。
• GitHub Kanban
  • Kanban 自動化がうまくいっておらず、Issue のステータスによるタスク移動がうまくいっていきませんでした。
  • 時間がないと自動化を後回しにしたが、Kanban を手で動かしていた時間を考えると高くついたと思うので、善は急げです。
• ストーリーポイント
  • これはスクラムや、開発管理に関する反省ではないが、初めの設計段階での「ユーザーストーリー」「MVP」の認識合わせはとても重要であると感じました。
  • 私たちの場合は、そこが甘かった為、初期段階での「ストーリーポイント」設定を誤り、スケジュール感算出が難しかったです。

今後

本開発は、チームメンバーに「スクラム開発」を行ったことがある方がいて、なんとか進めることができました。
今後は、私がその「スクラム開発」を行った経験のあるエンジニアとして、スムーズなプロジェクト管理を行うために下記についての理解を深めることが大切だと感じました。

• スクラムについての理解
  • SCRUM BOOT CAMP THE BOOK を読み進め理解を深めていきます！
• ユーザーストーリーへの理解
  • ユーザーストーリーマッピング（オライリー）を読み進め理解を深めていきます！
  • 幸いにも、弊社 GAOGAO ではユーザーストーリーマッピングの勉強会があり、10 名ほどで読み進めています！（モチベーション維持にありがたい！）

もちろん技術の勉強も必要ですが、どうチームで効率的な開発をするかのインプットも大切であると感じるプロジェクトでした。