年末でゆっくり普段の業務を振り返ることができたため、普段の開発ではどんなことを意識して、どんなことを実践して、どんな課題があるのかと言語化したくなったたので記事にしました。
スクラム開発
普段の業務ではアジャイルのフレームワークであるスクラムを採用して開発をしています。スクラム自体の解説は様々な記事や書物で溢れかえっていると思いますが、結局のところプロダクトを継続して作っていくための行動や問題をキチンと可視化して岩を取り除いて進み続けるためのフレームワークだと認識しています。自分にとってスクラムは優れています。優れているなと思う基準としては、当たり前のことを当たり前のようにできることができる機構であるかどうかです。そのため、この記事に記すことは当たり前過ぎることを書いてあるように感じられるかもしれませんが、当たり前なことができなくなる状況は往々にしてあるのが人間や集団の定めのような気がするので、当たり前であることがとても素晴らしいと感じています。
これ以降はスクラムのセレモニーになぞらえて業務を振り返っていきます。
Sprint Planning
開発者や顧客その他の人たちにとっての課題(Product Backlog Item、以降 PBI)を実際のタスク(Sprint Backlog Item)に落としていきます。30分のタスクに分割することが好ましいとされていますが、キチンと計測はしておらず(みんな時間の計測が苦手)なんとなくのタスクに落としています。PBIとタスクは付箋化してホワイトボードに貼り付けて、誰が何をしているか 何が終わっていてレビュー可能かどうかを可視化できるようにしています。PBIにタスクがぶら下がる形になります。なんとなく習慣でフロントとサーバで一貫性がないですw(フロントとバックもしくは、サーバとクライアントになってません)。
| PBI 123 (3) | フロントタスク | フロントタスク | サーバタスク | インフラタスク | インフラタスク | テスト |
|---|---|---|---|---|---|---|
| ユーザは、ログインできない | UIつくる | ログインAPIたたく | ログインAPIつくる | DBマイグレーションする | ダミーデータつくる | 検証環境でテスト |
PBIにはストーリーポイントと呼ばれる複雑度が記載されます((3)のように)。スプリントを続けていくと基本的なタスクの内容はパターン分けすることができ、見積もりの精度が上がっていきます。これは、こうするべきなどのベストプラクティスは無く、チームの得意・不得意や働き方によって決まります。PBIを作る上でとてもチームで注意していることとしては、今いるメンバーで一度も経験したことがない未知のタスクを炙り出す必要があるということです。未知のタスクには、以下のようなタスクが該当します。
- 使用したことのないUIコンポーネントを使用する必要がある
- バリデーションライブラリにデフォルトで用意されていないバリデーションをする
- 使用したことのないインフラリソースを利用する
- 想定し得ない影響範囲が出てきた
このような未知のタスクが出てきた場合は、スパイクという調査タスクを別途スプリント中に挿入します。これはPBIに紐づくブロッカーで、スパイクが終えるまでPBIに着手できません。スパイクのゴールは基本的にはPBIからタスクの洗い出しができる状態になっていること。となります。そのため緊急ではない場合、PBIは次のスプリントに見送りになります。この工程を踏まずにPBIの消化を強行した場合、大抵の場合 時間が掛かりすぎ本来想定した以下のPBIしか消化できずに平均の消化具合(ベロシティ)は低下します。そのためSprint Planningは、時間が掛かりすぎて作業時間が減ったとしても慎重に行う必要があります。
Daily Scrum
Daily Scrumは毎日行います。朝は(特に僕が)来れないことが多く集まれる率が低いためランチ後の13:30におこなうことになりました。Daily Scrumで行うことは、ホワイトボードに貼られた付箋(PBIとタスク)を見ながら前回のDaily Scrumから今までに消化したタスクと今日消化予定のタスク、予定通りに進んでいるかどうか、問題はないかを話し合います。問題がある場合には対策を考えたりPBIの優先順位を決めるプロダクトオーナーに現状を報告したりします。
作業時間
masterブランチからPBIブランチ(featureブランチ)作業を開始します(GitHubフロー)。同じPBIのタスクをメンバーと同時並行でやる場合には、PBIブランチからさらに子ブランチを生やす場合があります。良きタイミングでPRレビューを行います。細かくレビューを依頼したり、軽い場合はまとめて依頼したり結構その場のノリです。UIに関する変更がある場合にはスクリーンショットを必ず乗っけるようにしています(たまにサボる、がやる絶対)。フロントは副作用がない部分、サーバはControllerに関して、ほぼテストを書くようにしています(働き方のルール)。PRレビューの場合は、テストの方針があっているかコードのお作法・設計方針はどうかに関してレビューをする形になっています。
レビューが通ればmasterブランチにマージします。masterブランチにマージされると検証環境に差分がデプロイされます。デプロイされたら本番とほぼ同じ構成の検証環境で、受け入れテストをします。受入基準(Acceptance Criteria)はPBIに紐付きます。また、これは気になるぞというところは、なるべくSprint Planningで炙り出しておいて、あとは実装者が気になる部分をテストします。最近は実装者以外の開発者もテストをすることが流行りです。今は手でぽちぽち検証環境をいじっていますが、E2Eをしてテストファーストでやりたい欲がメンバーの中で熱くcypressを勉強しながら検討中です。あとは別途、後追いでQAさんがテストケースを作り開発者がレビューをしテストを1スプリント後にやるというフローになっています。
検証環境でのテストが終わればプロダクトオーナーにSlackを飛ばし、レビューをしてもらいます。ACを満たして気になる部分が無ければリリース許可を得ます。リリース時にはバージョンを規則に沿って採番しお好みのゲンスルー画像を貼ってリリースします。本番環境も軽く触りキチンとリリースされているかを確認します。
リリースには、他にも技術品質基準(Definition of Done)を満たしている必要があります。例を挙げると、CIが通っているか(単体テスト)、未知のエラーログが解消されているかPBI化されているか、ライブラリに脆弱性はないか、などになります。この品質基準が高い状態を維持し続けている状態でベロシティが安定していれば生産性の高いプロダクト・チームだと言えます。現状ではリリースは1日に2回ほどが平均値です。
このような作業のほかに、基本的に全ての開発者が検証環境・本番環境のWarning・ErrorのログやDatadogの監視をしています。クリティカルな問題が発生した場合には分担を決めて対策に取り掛かります。未知のエラーはトリアージして再発防止に努めます。
Product Backlog Refinement
プロダクトオーナーや開発者が見つけた課題をベースにPBIを作ります。PBIを作るという行為は、受け入れ基準を決める、ストーリーポイントを決めるということです。まだまだ議論が下手でストーリーポイントを決めるために不要な議論(Sprint Planningですべき話)をしてしまい時間を食ってしまいます。ここでストーリーポイントが決まっているPBIが少ないとSprint Planning時にする必要が出てきてしまい、非常に疲れます。目標は1PBI8分としています。
PBI作り以外には、中長期を見据えた大きな課題に対する議論をプロダクトオーナーやデザイナと交えてします。必ず開発者やユーザ目線が必要で、より良い価値になるように磨き上げます。ここで上手く進めれると本来やる必要がないことが炙り出せたり、もっと良い価値の提供の仕方を考えれたりして、一番生産効率を上げれるチャンスと感じています。
Sprint Review
今スプリント達成したPBIを発表していきます。基本的には作業中にプロダクトオーナーにレビューしてもらいリリースはしているので、ステークホルダとなるカスタマーサクセスの方に見せて褒めてもらったり意見をもらったりします。意見をもとに新たな課題ができたり運よく課題を消化できたりします。できれば実際のユーザを連れてレビューが行えれば完璧です。
Sprint Retrospective
一週間の振り返りをします。振り返り方はそのときそのときで様々です。開発者の環境や活動を改善し「目標実現の確率」を最大かする責任を持つ人(Scrum Master)が、基本的には振り返り方を提案してくれます(いずれは自分たちで、最適な振り返り手法をその都度、決定したい)。今まで使用した方法は、KTP・KPTA・YWTなどなどです。基本的には今スプリントやったことを分析し、問題点を挙げ、次のスプリントでできるトライを決めます。
上記は短期的な振り返りですが、たまに中長期を見据えたトライを出すこともあります(僕が課題を持ち提案しました)。これは普段、なんとなく今までの流れでやっている習慣や手法を見直す必要があると感じたためです。プロダクトの成果物(コード)や文化や開発内容は複雑度が増し普通にそのまま進めては生産性が確実に下がります。それを防ぐために新たな試みはできないか、何か打てる手はないかを考える必要があります。一番の技術的負債・チームの負債はここに眠っていて、必ず解決しなければならないと思っています。逆にこれを頻繁にやってしまうと、問題とはなっていない問題を解決しようとしたりできないことをしようとしてしまうためかえって生産性を損なう場合があります。そのため普段は普段のやっている+αぐらいの実現可能な改善で生産性を向上すべきだと思います。この活動がチーム開発の難所であり醍醐味と感じています。
まとめ
普段一生懸命に働いていると、なかなか現状が見えずに改善することができなくなってしまいます。そのため年末のお休みを利用することで言語化し、あわよくば第三者からフィードバックを得られると嬉しいなと思います。また、チーム開発に悩んでいる方々の参考になればとも思います。最初に述べた通りスクラムは当たり前なことを当たり前にするためのフレームワークです。スクラムを導入してから1年以上、今のチームでは9ヶ月の実績を持って初めてスクラムをすることが目的ではなく、プロダクトの成長をするためにスクラムを利用しているのだ、という実感を持って日々を過ごせるようになってきました。ここで改めてスクラムの目的や理念を再勉強することで新たに見えてくるものがあったりして楽しいです。軌道に乗るまでは、かなり難しいフレームワークですが、それは開発という行為の複雑さに真正面からぶつかるということだと認識しています。また来年もがんばっていきましょう！