実際のスプリントに見る、質と速さを両立するスクラム開発
スプリント1週間の中身
開発チームが取り組むスクラム開発のスプリントの中身についてご紹介します。上記は一回のスプリント（1週間）の中で行われる出来事を簡単な図へ起こしたものです。細かい内容は振り返りなどを経て小さなレベルで変化していますが、大きな枠組みとしては開発開始当初からは変わっていません。図内にも記載しています、以下の内容についてもう少し詳細にご説明します。
- プランニング
- 開発フェーズ
- プランニング前の事前調査
- QA実施のためのテスト設計レビュー
- レビュー＆振り返り
- リリース
不安を解消するためのプランニング
スプリントのはじめは、バックログに積まれたユーザーストーリーのどれを進めるか、スプリント内でどこまで行うことができるのかをプランニングとして開発チームメンバー全員で決定します。
機能要件に対しどのような実装を行うことになるのかという相談と大まかな作業ベースをタスクとして書き出していくのですが、ここでは「このあと進行していくタスクの内容に対し不安はないか」を第一に考えて進めていきました。時にはより詳細な設計〜実装面の話にまで至ってしまうこともあるのですが、不安を解消し納得できるのであればそれも良しとし、2、3 時間ほどかけてしっかりと話し合いを行っていきます。
タスク化ができれば最後にそのボリュームの見積もりを「プランニングポーカー」で行います。その見積もりによってスプリント内で収まる内容なのかどうかを見極めるというのが目的ですが、参加メンバー各々が挙げるポイントの揺らぎを見てみることで、タスクの内容、認識の不一致を炙り出したりするなど着手前の再認識を行う効果もありました。また、1タスクで丸一日かからない粒度となるよう、ポイントがあまりにも大きくなるようなものであれば細分化させるなどもあわせて行っていきました。タスク粒度を小さくするのは、フロー効率を高めることで、毎日の開発進捗を細かく認識、再確認することができるようするためです。
プランニングポーカーカードによる見積もり。フルリモート環境ではGoogleスプレッドシートの同時編集で行っています。
プランニング内で話し合い、決定した内容が重要な意味を持つことになるため、それが可能な限り失われないよう、ドキュメントに書き出すだけでなくビデオ会議の録画機能を使って映像として残すようにもしました。開発開始当初から複数拠点をビデオ会議で繋ぐ形でミーティングなどを行っていたためこういった手段（ツール）が問題なく採用できたのはチームにとってもラッキーな点でした。
レビューとフローを両立する開発フェーズ
開発フェーズでは、プランニングでタスク化したものを順々に消化していきます。前述のとおりタスクの粒度は小さくするようにしていますので、実装ができ次第他のメンバーにレビューをお願いしてどんどんマージしていきます。レビューをする人も何かしらのタスクを進行させているはずなので作業が重複してしまうことになるのですが、フロー効率の向上（開発チームのタスク進捗を優先させる）を目的に可能な限りレビューを優先するというルールを定めました。
順調にタスクを進めることができる場合は良いのですが、タスク内容について不安な点がある、あるいは誰かと相談しながら進めたいといった場合はすぐにペア作業で進めようにもしました。ペアで進めることで、タスクそのものが止まらないようにすることが目的です。ペア作業で行った実装分についてはそのままレビューまで進める場面も多く、こちらもフロー効率をあげるうえで価値あるアプローチの1つでした。また、逆に自身が詳細を決めたうえで進めている内容について他の人にレクチャーしたい際にもペア作業を採用し情報共有の手段として用いることもありました。
時にはプランニング前の事前調査を行うことも
開発フェーズで進めている内容と並行して、先のスプリントで進めることになるであろう機能開発について、その実現性を検証するための事前調査をあわせて進めることもありました。これはプランニングの際にバックログに並ぶ内容を見て、実際に進めるうえで障害となりうる事象（比較検討や技術的課題）に対し、それを調査するタスクをスプリント計画に入れて実施します。
このタスクの成果としては、確認や検討事項をドキュメントとして整理したものや技術実証のための仮実装コードになります。しっかりとアウトプットしておくことで、これらを元に本実装に着手して進める際に、スムーズに、そして誰でも進行可能になりました。
QA実施のためのテスト設計レビュー
今回のプロジェクト管理freeeの開発では、QAの実施がスクラムのスプリントそのものへ組み込まれ、機能開発とQAの実施が密接に進められる形となりました。それを進めていくにあたりスプリント内で重要となったものがテスト設計レビューです。
下記の図は、スプリント内におけるテスト設計レビューの実施とQAの流れを紹介したものです。ある1機能の開発について見ると、スプリント中に実装とテスト計画およびレビューを行い、次のスプリントで QA の実施が行われることになります。
- 開発チームは本スプリントの開発するユーザーストーリーを決定し、計画に載せる
- 決定したユーザーストーリーを QA チームに報告する（＝このスプリントにより何ができるようになるのかの確認）
- スプリント中に、進行中ユーザーストーリーの「テスト設計レビュー」を実施する
- スプリント終了後、QAチームは計画通り開発が終了した機能のQAを開始する
従来の機能開発では、リリース計画の中で機能開発期間とQA実施の期間を明確に分けたうえで、まず開発期間中に予定している機能群の実装をほとんど済ませたあと、それらを「まとめてQAチームにお渡しする」というものでした。
開発チームから見て、これまでと大きく変わったのは、今まさに実装真っ只中な機能を対象に、QA チームからの観点に基づくテスト目的や課題、あるいは疑問点などが得られるようになったということでした。このリアルタイム性の効果はとても大きく、単純に今実装中の関心ごとについて話をスムーズに行うことができるようになりましたし、異なる観点から挙げられたフィードバックで実装の過不足に気付き、実装段階で手直しすることが何度かありました。中には、受け入れ条件外の曖昧さより今どんな実装で進めようとしているのかと指摘され急いでプロダクトオーナーに確認したこともありました。こうして常に QA チームとの連携を行ったことで、単純な不具合だけではなく、ユーザーにとって使いやすいプロダクトという観点でも、品質が向上したと考えています。
スプリントレビューと振り返り
スプリント最後に行われるスプリントイベントでは、エンジニアがプロダクトに関わる方々に向けてスプリント開発成果を発表します。成果の多くはバックログに記載された受け入れ条件を達成した動くソフトウェアです。動くようになった機能を前にして、その内容の妥当性の確認、および意図の再認識や今後の展望について話し合います。
スプリント終了後は毎回しっかりと振り返りを実施します。この時間では、継続させたいポジティブな結果および改善を要するネガティブな課題を挙げて、次のスプリントに生かされるようにします。エンジニアからはスプリント時の具体的な活動内容を挙げつつ、活動のしにくさや煩わしい作業の発生があったこと、さらには後にトラブルに繋がりそうな失敗談をケースとして取り上げ、改善方法を出し合うなど、成果に対する執着を最も表に出していた瞬間だったように思えます。
成果とはプログラムの品質だけでなく、プロダクトを生み出す体制も関係しています。例えばレビューが滞ってしまうとチーム全体のアウトプットが低下してしまうので、レビューは来たらすぐ見たり、リリースタイミングで認識のズレをなくすため、リリース管理表を作成し、設計書や本番作業手順書を一箇所にまとめ、朝会で認識のすりあわせを行ったりすることで、確実に機能をリリースできる体制となりました。
リリースもスムーズに行うために
スプリントレビューを経た機能については、その次のスプリントで行われるQA、そして速やかなリリースを行えるようにするため、仕組みやルールを準備しました。
開発する機能に対しては、必ず機能リリースの有無を示すフラグパラメータを設けます。この状態を操作するだけで、機能リリースが完了するという体制となります。これにあわせて、実装したプログラムコードは、下記の各種環境へほぼ毎日反映するようにしました。
- 共通の開発環境
- リリース前の検証環境
- 本番環境
QAを実施するのは共通の開発環境です。QAを実施するためには開発した機能が使える状態である必要がありますので、この環境においてはQA開始直後に機能フラグパラメータはONとなります。つまり、スプリントで開発された1つの機能は、最短でスプリント完了直後に即時リリースに至ったとみることができます。
それぞれの環境の違いは稼働するサーバーの空間とリソース量だけであり、それ以上の区別はありません。開発や検証環境で行われていたリリースに問題がなければ、本番環境におけるリリースも問題なく行えるであろうという見通しが立ちます。実際サービスそのものの正式リリースを行う際も、前日の時点で手順をしっかりと整理しておいて、当日にフラグパラメータ1つを操作するだけで何のトラブルもなく完了するほどスムーズに行うことができました。
