この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の6日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

本記事ではデイリースクラムとプロダクトインクリメントの定義と自分たちのプロジェクトでの運用を紹介します。

デイリースクラム

デイリースクラムの定義

デイリースクラムはスクラムチーム全員が定期的に集まる場であり、朝会やスタンドアップミーティングと呼ばれることもあります。自分たちのチームでは毎日11:45から12:00までの15分間実施していました。みんな朝会と呼んでいたので以下では朝会と書きます。

朝会は一般的に進捗報告の場と考えられています。「昨日やったこと」「今日やること」を朝会で共有しているチームは多いでしょう。しかし、スクラムガイドによるとデイリースクラム（朝会）の主な目的は検査と適応です。では、その検査と適応とは具体的に何を指すのでしょうか。

デイリースクラムの目的1: 検査

朝会の検査とは進捗のチェックをすることです。自分たちのチームで進捗のチェックはバーンダウンチャートを使って行っていました。朝会実施時点で未消化のアイテムのポイントを合計し、前日より減っているか、変わらないか、増えているかを確認します。バーンダウンチャートについては「スプリント」の項目で説明をしたので詳細は省きます。スプリントで設定したバーンダウンチャートを朝会で更新するのです。

アイテムの消化が順調に進めばポイントは減る一方です。しかし、仮にスプリント3日目でポイントが18に増えていればメンバーの誰の目から見ても何かがおかしいことがわかります。するとスプリントプランニング時に想定していなかったことが明らかになったのだろうとメンバー誰もが気づけます。

ポイントが増えた場合、作業が終わりきらないためスプリントゴールを達成できなくなる可能性が高まります。もしゴールを達成できなくても誰かを責める必要はありません。その時は大きいアイテムを次のスプリントに持ち越したり、アイテムの中の一部のタスクの優先順位をさらに下げてリリース後に対応するなどの意思決定をします。

スプリントを実施すると毎日状況が変化します。この変化した状況の最新情報を朝会でチーム全員に共有するのです。これがデイリースクラムの検査です。

デイリースクラムの目的2: 適応

適応とは、デイリースクラムの検査で判明した新情報を元に意思決定をすることです。例えば、アイテムのポイントが見積もりより大幅に増えるとわかった場合にアイテムの優先順位を変更することを決めることです。また、アイテムが大雑把に書かれていることがわかったらきちんと定義してメンバー全員で認識を合わせるリファインメントを実施することを決めることも適応です。なお、リファインメントはデイリースクラムとは別の時間で午後に30分時間をとって開発者全員で実施していました。

主な適応はスプリントバックログに手を入れることです。チーム開発に不慣れな人は全員が見るスプリントバックログを自分が変更してもいいのだろうかと遠慮するかもしれません。しかし、一番やってはいけないことはスプリントバックログに最新状況を反映しないことです。

例えば「ある実装タスクを3ポイントとして当初見積もっていた。作業を進めていくうちに既存のコードのリファクタリングが必要であることがわかり、作業量は5ポイント相当と判明しました。しかし、リリースを遅らせたくないから自分が頑張って作業をするのでポイントは3のままで行きます」という態度です。

デイリースクラムは適応の場なので、ポイントが3から5に変わったとわかったらそれをバックログに反映させます。アイテムのポイントの増加はネガティブなことばかりではありません。タスクの着手によって、着手前より多くの情報を手にしたため不確実性が減ったのです。ポイントの増加にばかり目を奪われるのではなく、このことをこそチームで歓迎するべきなのです。現実は変えられないため、現実をベースにして次の手を考えていきましょう。

このように、デイリースクラムは他の人の進捗報告を聞くだけの場ではありません。デイリースクラムとは、スプリント実施中にアイテムにまつわる最新情報を共有して（検査）、次の意思決定をする（適応）という積極的なイベントなのです。

進捗報告の形骸化を打破する

自分たちのチームも当初は朝会を進捗報告と不安要素を共有する場だと考えていました。

朝会では前日の自分の仕事の内容とその日に着手することを各メンバーが順番に話していました。しかし、自分たちのチームではペア・モブプログラミングを採用していため、6人いる開発者のうちの半分は「ペアの人と同じことをやります」と話していました。また、開発者は全員Gatherを使って常にオンラインで集まっており、不安要素があればタイムリーに他のメンバーと相談をしていました。開発者同士は密にコミュニーションを取れているため、どのペアが現在何に着手しており何に詰まっているかお互いに知っていました。このため朝会は実質的にプロダクトオーナーとスクラムマスターに対する報告がメインになっていたのです。

すると他の開発者の進捗報告は「自分が知ってる内容なので聞き流してもいいかな」という雰囲気が蔓延し、何週間かそのような状況が続いていました。しかし、スクラム開発を始めて数スプリントたった頃のスプリントレトロスペクティブ（振り返り）であるメンバーがこう言いました。「スプリントバックログを見ればアイテムの進捗状況は一目瞭然だ。だから進捗確認はみんなでカンバン形式のバックログをサッと見るだけに留め、口頭での朝会の進捗共有を無くしたい」と提案しました。その提案はすぐに受け入れられ、チームは早速翌日の朝会から適応することにしました。

確かにFigJam上のスプリントバックログのアイテムには、それぞれ「Done（アイテムの完了）」「Check（タスクの完了）」「WIP」のステッカーが貼られています。さらに、各アイテムと各タスクには担当者のFigJamアイコンのスタンプが押されていたり、スプリント中に新しく追加したタスクには「New」のステッカーが貼られていました。

（画像を貼る）

アイテムの進捗を示すマークをつけるタイミングは朝会でした。口頭で進捗を共有しながらステッカーを貼っていたのです。しかし口頭での進捗共有をなくしたため、各メンバーは朝会まで待たずにアイテムやタスクが完了したタイミングでFigJamをタイムリーに更新するようになりました。その結果、口頭での進捗共有という形骸的な儀式を無くして朝会の時間を短縮できた上に、スプリントバックログが常に最新の状況を反映するようになったのです。

この時はスクラムを始めて3ヶ月しか経っていませんでしたが、あらゆるスクラムイベントの中で最初の時点と比べて朝会（デイリースクラム）が一番ブラッシュアップされました。ここでは一番大きな変化だった進捗の共有方法のみを紹介し、他の有意義な変化はスプリントレトロスペクティブの項目で紹介します。

プロダクトインクリメント

プロダクトインクリメントの定義

プロダクトインクリメントとはスプリントの成果物を指します。具体的にはスプリントの中で完了したアイテムとプロダクトの進化した部分のことです。あるスプリントの成果物を前回スプリントの成果物に追加することで、成果物が増えてプロダクトは成長します。

インクリメント（increment）は増加という意味の英単語です。プログラミングでは特に「値を1増やす」という意味で、0を1に、1を2にというように値を一つずつ増やすことを指します。スプリントが完了するたび着実に成果物が一つずつ増えていくことを表現するためにプロダクトインクリメントという言葉が選ばれたのでしょう。

プロダクトインクリメントの運用

具体的なインクリメントはスプリント中に完了したアイテムであると述べました。プロダクトバックログのアイテムは誰が何をできるようになるというユーザーストーリーの形で記述します。自分たちのチームでは、アイテムの作成と同時にアイテムの完了条件をあらかじめ決めました。アイテムの完了条件を決めるのはプロダクトオーナーの役割です。完了条件を先に決めることで、そのアイテムの完了、未完了を適切に判断できます。

自分のいるチームでは、この完了条件に細かい仕様や挙動を記述していました。例えば、XXX というユーザーストーリーのアイテムがあるとき、完了条件は1.YYY、2.ZZZとするというように。

開発者が機能を追加するだけではアイテムの完了とはいえません。開発環境にデプロイをしてプロダクトオーナーが実際に動作確認をできるようにします。自分たちはプロダクトオーナーによる動作確認を受け入れテストと呼んでいました。この受け入れテストをパスしたら本番環境にデプロイをします。本番環境でも問題が発生しなければアイテムのステータスを完了としました。

なお、スプリントが終わった時点で完了条件を達成できなかったアイテムはプロダクトバックログに戻します。その後リファインメントで他のアイテムと優先順位を比較し、改めて次のスプリントで着手を続けるかプロダクトオーナーが判断をします。

スプリントバックログアイテムとスプリントレビューはプロダクトインクリメントと密接な関係を持ちます。開発の観点からは、プロダクトに新しいインクリメントを追加するにあたって過去のインクリメントを壊していないこと、つまりデグレが起きていないことが重要です。スプリントレビューでは、これまでに達成した全てのインクリメントをステークホルダーに披露するからです。前回のスプリント終了時点で出来なかったことが今回のスプリントで出来るようになることは当たり前です。しかし、前回出来たことが今回出来なければステークホルダーは失望するでしょう。このため、自動テストを書いてCI環境を整備してデグレが起きたら素早く見つけられるようにします。

良いスクラムチームは出来ないことを出来るとは言いません。スプリントレビューでは、あるアイテムの調査や開発が完了しておらずインクリメントとして扱えないときには「ここは完了していません」とステークホルダーに伝えましょう。そして出来なかった合理的な理由をステークホルダーに説明できればきっと納得してくれます。誇大広告的に10のものを100だと言わず、10のものは10以上でも10以下でもないとステークホルダーに伝え続けましょう。するとチーム外部のステークホルダーの人たちに、このチームは嘘をつかないし隠し事をしないと思って貰えます。結果的に、スクラムチームとステークホルダーの間で長期的な信頼関係を築くことができるのです。

開発者にとってプロダクトの内部品質の維持は重要です。スプリントレビューに間に合わせるためコードを汚く書いてさっと動くものを作ってアイテムを完了させて、それをインクリメントとした場合があるとする。早く綺麗なコードを書くことが実は一番早いと言われているが、事情が許さずどうしても一時的に汚く書かざるを得ない時はあるでしょう。そのような場合はプロダクトオーナーに掛け合って次のスプリントをリファクタリングから始めるのが良いでしょう。そうでないと質の悪いコードが足を引っ張るはめになり、長期的にはベロシティの悪化に繋がってしまう。質とスピードは両立するのです。

次回はスプリントレビューついて説明します。

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の5日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

本記事ではスプリントプランニング、スプリントバックログ、スプリントの定義と自分たちのプロジェクトでの運用を紹介します。

スプリントプランニング

スプリントプランニングの定義

スプリントプランニングは、次のスプリントで実施することをプロダクトオーナーとエンジニアが話し合って決める活動です。着手するアイテムやタスクはプロダクトバックログ上から選択をします。プロダクトバックログは常に優先順位でアイテムが並べられているためです。

次のスプリントで着手するアイテムの量は過去の実績に基づいて決めます。直近2回のスプリントで消化したポイントの平均（速度という意味のベロシティと呼ばれます）と同程度にすることが一般的です。仮にベロシティが20ポイントであればプロダクトバックログアイテムを上から順にポイントの合計が20前後になるまで選択します。次のスプリントで実施するアイテムを集めたものをスプリントバックログと呼びます。自分たちのチームではアイテムを選択することを「（スプリントバックログに）アイテムを積む」と呼んでいました。

スプリントプランニングでは、チームの目線を揃えるために次のスプリントで達成するべきことをまとめたスプリントゴールをいくつか作成します。スプリントゴールを作ることで「このスプリントはこの分野に注力する」という意識をチームで共有できます。

もしプランニングの際にアイテムのポイントが適切ではないと不安に感じたら、一度戻ってリファインメントを実施しましょう。またポイントを振り直したり、アイテムをスパイクと実装タスクに分割した後にプランニングを再開すればスプリント開始後に「思ったよりポイントが大きくて完了しきれない」と焦ることはありません。

スプリントプランニングの運用

スプリントゴールの設定

スプリントプランニングでは、そのスプリント中に達成するアイテムをプロダクトバックログから優先度順に選択します。自分たちのチームではアイテムを選択した後にスプリントゴールを3つか4つほど設定していました。

本来はスプリントゴールを先に決めてからアイテムを選択するのかもしれません。しかし、アイテムを先に選択することでどこまでやれるのか見通しが立つためこのやり方に落ち着きました。

（スプリントゴールの画像）

スプリントバックログを見ればそのスプリントで何に着手するか明確だから、スプリントゴールの設定は不要だと考える人もいるかもしれません。しかし、スプリントゴールを設定しないと「チームでゴールを達成する」という意識が薄れてしまい、助け合いの精神が希薄になってしまいます。開発者が「自分がアサインされたタスクを終わらせればそれでいいのだ」という考え方になってしまうのです。

自分たちのチームではスプリントゴールにも優先順位をつけました。すると思わぬ効果がありました。一番優先順位の高いゴールに関係するアイテムを誰か1人ではスプリント内で達成できないと気づいた時、それより優先順位の低いアイテムに着手していた別のメンバーが「自分のアイテムは優先順位が低いので一旦着手を中止して、一番優先順位が高いゴールのアイテムを自分もやります」と救いの手を差し伸べたのです。

チームでゴールを達成する意識を全員が持ち、アイテムの着手順を自律的に組み替える意思決定をスムーズに行う体制を作れることがスプリントゴールの効果なのです。

バーンダウンチャートの設定

アイテムの消化ペースが順調かどうかを確認するために、自分たちのチームではスプリントプランニングの中でバーンダウンチャートを作成しました。バーンダウンチャートとは右肩下がりのチャートです。スプリント内で消化するポイント数を初期値として、日が経つごとにポイント数が減るチャートを作りました。

（バーンダウンチャートの画像を持ってくる）

例えば、次のスプリントの消化予定のポイントが20だとします。2週間のスプリントで営業日が10日あれば1日の消化予定ポイントは2です。初日は20ポイント、翌日は18、その翌日は16、そしてスプリント最終日2、スプリントが終わったら0とします。これを予測ポイント数と呼びます。

デイリースクラムの最後にそれまで消化したポイント数を計算し、バーンダウンチャートを更新して予測消化ポイント数と比較します。乖離が大きければその理由をみんなで探します。自分たちはスプリントが順調に進んでいるかどうかを判断する材料としてバーンダウンチャートを活用していました。

リリース直前のスプリントプランニング

リリース1ヶ月前ごろから、リリースまでにやることとリリース後にやることを振り分けました。リリースまでに終えなければならないアイテムのポイント数を合計して過去のベロシティを元にリリース日を算出し、チーム外の人にリリース予測日を共有していました。

スプリントバックログ

スプリントバックログの定義

スクラムにおいて、スプリントバックログは作成物です。スクラムにおける作成物とは、スクラムイベントを実施すると出来上がっている物です。スプリントバックログはスプリントプランニングの中で、プロダクトバックログから選んだアイテムをまとめたものです。プランニングの完了と同時にスプリントバックログの作成が完了します。

スプリントバックログの運用

スプリントバックログには、スプリント中にチームが取り組むアイテムが並んでいます。自分たちのチームでは、Figjamでプロダクトバックログアイテムもスプリントバックログアイテムも作成していました（今だとGitHub Project上に作ると思います）。このため、チーム外の人が見ても次のイテレーションでどのような成果物が出てくるかが一目瞭然でした。スクラムの三本柱である透明性が担保されていたのです。

スプリントバックログはデイリースクラムで全員が毎日チェックします。

（スプリントバックログの画像）

スプリントの実施

スプリントの定義

スプリントは1~4週間の周期（イテレーション）で実施するものとスクラムガイドに定義されています。スプリントプランニングを終えてスプリントバックログを作成してからスプリントを開始します。スプリントはあくまで入れ物であり、何をするかはチームや開発フェーズに応じて柔軟に変えていきます。

スプリントのイテレーション

自分たちのチームでは1週間のイテレーションと2週間のイテレーションを使い分けていました。

2週間スプリントはプロダクトオーナーと開発者の目線が揃ってエンジニアが着手するアイテムの内容に迷いがなく、調査と開発に集中できる中盤で実施しました。

1週間スプリントは作業を前に進めるより、コミュニケーション齟齬を防止するフェーズで実施していました。それは仕様があまり定まらない最初期と、考慮漏れを潰さなければならず細かいタスクばかりになりがちなリリース直前の時期です。このように変化が多く、不確実性が高い時期ほどフィードバックサイクルを短くすると良いと学びました。

この時はリファインメントとスプリントプランニングで半日ほどかかっていたため、2週間のイテレーションであれば実働は8営業日でした。

スプリントとスプリントレビューの予定を押さえる

スプリントの開始時点で、そのスプリントのレビュー会に参加して欲しい人の予定をカレンダーで押さえました。レビュー時にレビューをして欲しい人がいないという事態を避けるためです。

例えば水曜日にスプリントが始まる場合、2週間イテレーションなら翌々週の火曜日がスプリントレビューです。これを何スプリントか繰り返していくと、チーム外の人に火曜日はスプリントレビューがあるから予定を空けておこうと思ってもらうことができます。

良いスプリントはスプリントごとに不確実性が下がるもの

リリース日がいつかと聞かれても、開発当初は粗い見積りしか出せません。開発とリリース日の関係はアジャイルサムライの「荒ぶる四天王」の考え方を参考にしていました。

荒ぶる四天王とは、予算・品質・スコープ・期限です。これらのうち品質を下げることはできません。また予算が増えて新しい人がチームに入ったからといってリリースが早くなるという確証もありません（いわゆる「人月の神話」）。そして四半期決算と年度決算を区切りとするのがビジネスであるため、期限日は大きくずらせません。よって開発のスコープを調整することがベストなのです。

どの現場でも「最低限の機能をスピーディにリリースしよう」と号令がかかります。このときプロダクトオーナーと開発者にできるのはこの最低限、つまり開発スコープを調整することだけなのです。

残念なことに最低限の機能だけでリリース日の見積もりをしても、リリース予測日は往々にして遅れる方で外れます。最低限の機能に絞っても、開発を始めると想定外のことが発生するからです。そして、リリースを遅らせる想定外の出来事はあらかじめ予測はできず実際に経験しないとわからないのです。

そこでスクラム開発では、想定外の出来事が発生することを事前に考慮に入れます。何が想定外の足枷になるかはわからないけど、想定外の事態が発生しても適切に対処する方法を用意しているのです。それは想定外の出来事を見つけたら素早くチームに共有し、議論し、意思決定を行うという基本的なことです。この地道な活動を積み重ねることでプロジェクト全体の不確実性が減っていくのです。

スクラムでは開発全体において不測の事態があればスプリントで対応し、スプリント中に予想外のことがあればデイリースクラムで対応するのです。

スプリントを繰り返していくうちに開発は進みます。機能が揃い始めてユーザーのできることが着実に増えていきます。スプリントを経るごとに想定外の出来事が減ると同時に不確実性が減ります。するとリリース日の予測精度も上がります。2週間のイテレーションでスクラムを実施しているのであれば、あと2スプリントでストーリーポイントを全て消化できるというタイミングで予想したリリース日にほとんど誤差はなくなるのです。

開発を前に進めることで時間が経つにつれて不確実性が低減することは、一般的に不確実性コーンという図で説明されます。

（不確実性コーン）の画像

スプリントの実施は不確実性を減らすことに直結するのです。

次回はデイリースクラムとプロダクトインクリメントついて説明します。

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の4日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

本記事ではプロダクトバックログリファインメントの定義と自分たちのプロジェクトでの運用を紹介します。

プロダクトバックログリファインメントの定義

プロダクトバックログリファインメント（以下、リファインメント）は、チーム内のコミュニケーションの核となるイベントです。リファインメントは英語のrefinementで洗練することという意味です。日常では馴染みのない言葉ですが、改良する、ブラッシュアップするという意味で使われます。

ではリファインメントでは何をブラッシュアップするのでしょうか。その対象はプロダクト開発をするにあたりチームで取り組むべきことです。開発の現場では開発者がやるべきことはストーリーやタスクと呼ばれますが、そのやるべきことをここではアイテムと呼びます。アイテムをエピック、フィーチャー、ストーリー、タスクに分類する方法もあるものの、アイテムの説明をすれば十分であるためここでは触れません。

アイテムは「ユーザーはXのためにYができるようにする」というユーザーストーリーで記述されることが一般的です。プロダクトオーナーがユーザーストーリーの形でアイテムを記述し、開発チームがそのアイテムを実現するのがスクラムチームです。時にはプロダクトオーナーと開発チームが一緒になってアイテムを考えることもあるでしょう。

しかし、機能開発はわからないことだらけです。このようにきちんとアイテムを作成しても「では開発者は具体的に何をすればいいのか」は誰も答えてくれません。また良いエンジニアとは言われたものを言われた通りに作るのではなく、なぜそれを作るのかという背景を知った上でどうやって作るのがベストかという設計、実装を自分でハンドリングする人たちです。

そこでリファインメントを実施するのです。あるアイテムを選んで具体的にどう実装するのか、不明点があればどのような調査が必要なのかを明らかにします。メンバーは自分たちの持てる知識と経験を総動員してフラットに議論します。メンバー間の認識齟齬がなくなり、迷いなく作業が開始できる状態になればリファインメントは完了です。

リファインメントとは洗練やブラッシュアップの意味だと書きました。リファインメントは私にとって細分化というイメージが近いです。アイテムという未知の塊を取り上げ、リファインメントを通じて何が不明なもので何をすれば実現できるかを明らかにするプロセスだと捉えています。

機能開発をするにあたり、アイテムは10や20など複数作られます。これらのアイテムを格納したものはプロダクトバックログと呼ばれます。プロダクトバックログ内の各アイテムはプロダクトオーナーが決定した優先度順に並べられているため、開発チームは一番上からアイテムを選んで作業を進めます。

自分たちのプロジェクトでのリファインメントの運用法

次に、自分たちのプロジェクトでのリファインメントの運用方法を紹介します。

このプロジェクトではAという社内機能を作ります。この機能を実現するために仮に15のアイテムが必要だとします。リファインメントでは、プロダクトオーナーが次に実現してほしいアイテムをピックアップします。そのアイテムを開発チームが着手可能な状態にするためにリファインメントを実施します。すると実装タスクだけではなく、不明点があるために調査タスクも必要なことが頻繁にあります。アイテムを着手可能なものに分割したものをタスクと呼び、特に調査タスクをスパイクと呼びます。

自分たちのチームではスパイクをプロダクトオーナーが着手するものとエンジニアが調査するものに分けました。

前者のスパイクは主にユーザーとして機能を使う社内チームや法務、セキュリティチームなどの他チームへの確認です。またエンジニアの質問から決まっていない仕様があることがわかれば、これもプロダクトオーナーのスパイクとしてタスク化していました。開発者向けのスパイクは、既存のコードの調査やコード、データベースの設計、また実現可能性を調べる技術的な調査、SRE・インフラチームとの相談、確認がメインです。

スパイクの完了は調査が終わって実装タスクを作成できるとわかった時点としました。

実装タスクはエンジニアにとって主にコードを書くことです。しかし、コードを書き終えたら完了としたわけではありません。開発者同士のコードレビューに加えて、開発環境でプロダクトオーナーに受け入れテスト（動作確認）を実施してもらいました。この受け入れテストが完了し、マージ、デプロイをした後に完了としました。

スパイクか実装タスクかに関わらず、どちらもこれができれば完了だとする完成の基準をプロダクトオーナーが事前に決めています。エンジニアが作成したスパイクであればエンジニアが完了基準を決めることもあります。経験上、事前に完了基準を決めていないスパイクは完了したと思っても実装タスクの着手時点でどうするべきかまだ迷ってしまったり、あれもこれもと調査が続いてしまっていつまでも完了しないという事態がよく発生します。

アイテムに紐づくタスクが全て完了すればアイテムを完了扱いとします。スクラムでは完了したアイテムをプロダクトインクリメントと呼びます。プロダクトインクリメントについては別の記事で詳述します。

ストーリーポイントでタスクの大きさを見積もる

自分たちのプロジェクトでは各タスクに対して工数の見積もりをし、アイテムの大きさは各タスクの工数を合計したものとしました。タスクの見積もりはストーリーポイントという手法を用いることが一般的です。

ストーリーポイントの見積もりではプランニングポーカーをしました。プランニングポーカーには以下のような特徴があります。まず、スクラムチーム全員が参加することです。非エンジニアの方で具体的な実装について知らない方も含めて全員が参加します。次に、あるタスクを選んで「このタスクは自分なら何ポイントかかると思う」と心の中で見積もりをして、そのポイント数をメンバー全員が一斉に開示することです。

一番小さいポイントを挙げた人と一番大きいポイントを出した人に見積もりの理由を聞き、全員で議論をして再見積もりをします。そこで全員の意見が一致すれば見積もりは完了です。この見積もりを自分たちは「ポイントを振る」と呼んでいました。

一番小さいポイントを振る人は簡単に実装する方法が見えていることがあります。また、一番大きいポイントを振る人は他の人が考慮外のことを避けられてないこととして挙げてくれます。ポイントを降り始めた頃はメンバー間でポイントの大小がなかなか揃いませんでした。このため、スプリントを1度実施していくつかのタスクを完了させることで、ポイントの基準となるアイテムを選んで、これは1ポイントくらい、これは2ポイント、3ポイントとメンバー間でポイントあたりのタスクの大きさの認識を合わせることができた。また自分たちのプロジェクトでは文言の変更だけなど一瞬で終わるタスクは0ポイントとしました。

なお、ポイントは時間で算出するものではありません。1つのタスクを2人のペアで取り組んでも1人で取り組んでもポイントが増減したりはしません。「自分がやるならこれくらいかかる」と想像してプランニングポーカーでポイントを提示し、みんなの議論で認識を合わせて再度見積もりをします。チーム内で認識が揃っていたらそれで十分なのです。社内の人から「結局リリースはいつになるの」と聞かれることがあれば、その際は直近2スプリントで消化したポイント数合計を2で割ったもの（ベロシティ）と残りの全てのアイテムのポイント数を合計したものから予想リリース日を算出して「この日前後です」と伝えます。

この時注意するべきことは、リリース日の予想精度は高くないとも伝えておくことです。不測の事態があればポイントが増えてしまうからです。残念なことにアイテムが減ってポイント数が大きく減ることはなく、したがってリリースが予想より大幅に前倒しになることはありません。アジャイルの教科書的には後回しにできることはリリース日の後にやるのがベストです。これを「スコープを削る」といいます。しかし、開発現場やビジネスの現場にアジャイルの考え方が浸透した現在では、最初から「最小限の機能でリリース」が求められるためスコープがほぼ固定されて削れるところがなかなかないからです。

開発全体を通してのポイントは増えたり減ったりするため、毎スプリントの終わりごとにリリース予測日をチームで確認していました。

リファインメントの意義とその効果

リファインメントはアイテムの内容と実現方法についてチームメンバー全員で認識をすり合わせる時間です。この取り組みを通して、「Aさんはaだと思っていたけど、Bさんはbだと思っていた」というスレ違いを減らしていきます。メンバー同士で徹底的に議論をする必要があるため、かなりタフな作業でした。変に気を遣ったり忖度して言うべきことをその場で言わないと認識齟齬により後から手戻りが発生してしまうため、しっかり話し切ることが重要なのです。この時はスクラムマスターのアドバイスのもとで2スプリント先のアイテムまでリファインメントをしていたため、アイテムとタスク数が多いことも拍車をかけていました。リファインメントが終わった後はみんなぐったりしていた記憶があります。

人によっては「会議が長い」と感じることでしょう。実際自分たちのプロジェクトでは3時間から5時間ほどかかっていました（今ならもっと短くできる自信はありますが、この時は全員がスクラム初心者だったため特に時間がかかってしまいました）。しかし、一たびスプリントが始まれば認識合わせの会議はほとんど必要ありません。リファインメントで事前に些細な疑問を解消したりや不明点を洗い出していたからです。リファインメントは不確実性の低減に確実に寄与しています。議論の場でやるべきことを判断できる情報がチーム内にあれば、その場で次の決断ができます。チーム内に判断材料がなければ、他チームに聞いたりドキュメントを読んだり実装やデータベースを調べるアイテムを作成するという決断ができます。別チームにちょっと聞くくらいの確認が必要なのであれば、「Slackで聞く」というタスクに分解する（次のアイテムのリファインメント中に裏でSlackでパッと聞いてしまうということもしていました）。これにより、タスクの着手忘れと、コードや他の成果物が出てきたからみんなが思っていたものと違うからやり直すという手戻りを防止できるのです。

この段階で開発者がプロダクトオーナーに仕様や方針、背景を確認することでスプリント中迷わずに作業を進めることができます。「スクラムは会議が多い」という批判は確かにあるものの、オンラインでもオフラインでも同じ場所に集まってで徹底的に細かい点まで話し合うことで認識違いを避けるという側面もあります。作業を進めるうちに不明点が出てきて話し合いが必要になれば、Slackに質問を投稿したりGatherでパッと聞きに行ったり（今ではGatherは使わずハドルでさっと集まっています）デイリースクラムで質問すれば良いのです。すると結果的に他の会議が減るのです。

リファインメントはスプリント開始前に実施するものとスプリント中に実施するものがあります。スプリントプランニング前のリファインメントではプロダクトオーナーを含めたメンバー全員が集まって実施します。一方スプリント途中のリファインメントは技術的な内容が多いです。このため、後者は不明点が出てきたらまず開発者だけでサッと集まって話し合い、仕様面等でわからないことがあれば適宜プロダクトオーナーに質問するというやり方を採用していました。

ただし、以下のようなケースではスプリント内のリファインメントであってもプロダクトオーナーも含めた全員が集まって実施していました。

スパイクのアイテムの後に実装のアイテムがあるとします。スパイクが完了した後、実装が想定より複雑であることが判明したとします。実装のアイテムのストーリーポイントを振り直したり、スプリントを跨いだりリリースが遅れるほど影響があれば、さらなる調査や実装の優先順位を変えるといった判断が必要になる。つまり、不確実性が低いから後回しにしていたけれど実際はわからないことだらけだったので早めに着手して不安を解消したいというケースです。自分たちのプロジェクトではプロダクトオーナーが開発者を信頼してくれていたため、開発者のアドバイスをもとにアイテムの優先順位を入れ替えてくれていました。

リファインメントにはチーム全員が協力して認識を合わせるというコミュニケーションとコラボレーション、また不確実性が大きいとわかったら着手する優先順位を入れ替えるという変化に対する柔軟な対応というアジャイル開発の重要な精神が詰まっているのです。

次回はスプリントプランニング、スプリントバックログ、スプリントの実施について説明します。

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の 3 日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

スクラム開発の概観

本記事ではスクラム開発について概観します。

スクラム開発（以下、スクラム）はアジャイルなソフトウェア開発の手法として知られています。スクラムはスクラムイベントと言われている各種の会議やアクティビティが有名です。このため、スクラム開発の手法を導入すると必ずチームがアジャイルに開発を進められると勘違いされてしまうことが多々あります。しかし、スクラムに含まれるものはスクラムイベントだけではありません。スクラムガイド2020年版からスクラムの定義を引用します。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。 「スクラムガイド2020年版」 p.4

では、スクラム開発とは具体的にどのような開発手法なのでしょうか。最初にスクラムが重要視する価値について触れておきましょう。

スクラムの5つの価値

スクラムは「価値・原則・プラクティス（実践）」の3つで構成されています。スクラムが追求する価値は以下の5つです。

• 確約（Commitment）: やり切ることを約束すること
• 集中（Focus）: やるべきことに集中すること
• 公開（Openness）: チームの情報の透明性を確保すること
• 尊敬（Respect）: 相手に対してリスペクトの念を持つこと
• 勇気（Courage）: 不確実性の高いことに対して勇気を出して一歩踏み出すこと

良いチームというものを想像した時に、これらの特徴をいくつも兼ね備えていることは想像に難くありません。スクラムの原則とプラクティスは、これら5つの価値を実現するための手段なのです。

スクラムイベントのようなプラクティスだけを取り入れても必ずしも成功するとは限らない理由がここにあります。プラクティスを実施してもこれらの価値がチームで体現できていなければ形骸化し、本当に意義があるかわからないけどとりあえず実施するだけの「儀式」と揶揄されてしまうのです。

スクラムの原則

エッセンシャルスクラムによると、スクラムの原則は「変動性と不確実性」「予見と適応」「検証による学び」「仕掛かり中の作業（WIP）」「進捗」「作業効率」とされています。これらの原則はさらに分解され、心構えやアドバイスとして文章化されています。これらを簡単にまとめると以下のようになるでしょう。

• 変動性と不確実性: 変化を受け入れつつ不確実性を低減させること
• 予見と適応: 将来を見越した上で現実的な方法を取り入れること
• 検証による学び: 重要だけど不確実性の高い箇所を優先し、手を動かして新しい知識を得て次の行動に活かすこと
• 仕掛かり中の作業（WIP）: タスクの管理を効率的に行うこと
• 進捗: 動くものを基準にして計画を見直し続けること
• 作業効率: 品質の高いものを焦らずに、しかし素早く作ること

これらの原則は全てスクラムの5つの価値のいずれかに基づいたものです。例えば、検証による学びは不確実性に立ち向かう「勇気」や優先順位の高いことに「集中」して取り組むことだとも言えます。

スクラムのプラクティス

スクラムのプラクティスは「役割」「アクティビティ」「作成物」に分けられます（「エッセンシャルスクラム」による）。さらに細分化すると以下です。なお、「ルール」にはここでは触れません。

• 役割
  • プロダクトオーナー
  • スクラムマスター
  • 開発チーム
• アクティビティ
  • スプリント
  • スプリントプランニング
  • デイリースクラム
  • スプリントの実施
  • スプリントレビュー
  • スプリントレトロスペクティブ
  • プロダクトバックログリファインメント
• 作成物
  • プロダクトバックログ
  • スプリントバックログ
  • 出荷判断可能なプロダクトインクリメント

この記事ではアクティビティをスクラムイベントと呼ぶことにします。スクラムイベントと作成物は関係しあっています。その関係図は以下のようなもので、ループを形成しています。

役割について触れると、スクラムチームは1人のプロダクトオーナー、1人のスクラムマスター、複数人の開発メンバーで構成されるとスクラムガイドにあることを反映しています。アクティビティと作成物については別の記事で詳述します。

価値、原則、プラクティスを貫くスクラムの理論

ここまでスクラムの価値、原則、プラクティスを紹介しました。チームメンバーのあるべき姿や指針、実践するべきことはここまでで示されました。しかし、スクラムは何らかの思想に裏打ちされたものなのでしょうか。その問いはスクラムガイドの「スクラムの理論」で答えられています。

スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。 「スクラムガイド2020年版」 p.4

さらに経験主義を採用しているスクラムの三本柱は「透明性」「検査」「適応」と述べられています。これらを簡単に説明すると以下のようになります。

• 透明性（transparency）: 作業プロセスや作成物を隠さずに公開すること
• 検査（inspection）: 作成物や進捗状況のチェックをしてフィードバックを得ること
• 適応（adaptation）: 検査で得たフィードバックに基づき、課題を解決するアクションを起こすこと

特に「検査」と「適応」は、この後スクラムイベントを解説する中で繰り返し登場する重要な考え方です。

スクラムは全てを実施する

スクラムは全てを実施することで本領を発揮するフレームワークです。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。 「スクラムガイド2020年版」 p.4

スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。 すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。 「スクラムガイド2020年版」p. 14

全てのプラクティスを実施するのは大変そうだから重要な一部だけを取り入れようという態度は明確なアンチパターンです。プラクティスや作成物全てに意味があり、相互に関係しあっているからです。

これだけ多くのことを実施するスクラムは、なぜ自分自身を「軽量級フレームワーク」と自称するのでしょうか。スクラムイベントや作成物の定義や方針スクラムガイドで語られるものの、実際にどのツールを使えばいいとか何曜日の何時から何時間実施するといったような細かい指定はないからです。日本語版のスクラムガイドが目次を含めて14ページしかないことがその証拠です。

スクラムは軽量級フレームワークであり、スクラムガイドはその定義や方針を定めたものです。しかし、それだけではスクラムをどう実施するのか見当がつきません。だからといって全部で413ページあるエッセンシャルスクラムという手厚いながらも分厚い本を読破するのも大変です。このアドベントカレンダーは3ヶ月間スクラムを実施した実録を通して、両者の橋渡しをすることが一つの目的でもあります。

スクラムが軽量級フレームワークであることはエッセンシャルスクラムでも述べられています。

スクラムは標準化されたプロセスではない。（中略）スクラムは作業をまとめ上げ、管理するためのフレームワークだ。このスクラムフレームワークは価値、原則、プラクティスに基づいている。 それらを基礎として、組織にあったエンジニアリングプラクティスや、スクラムのプラクティスを実践するための具体的なアプローチを追加できる。その結果として現れるのは、あなた独自のスクラムである。 「エッセンシャルスクラム」 p.14

スクラムの具体的な実践の仕方はチームによって異なります。何か一つの正しいスクラムのやり方があって自分たちはそれに沿っているか外れているかなどとは考えずに、チームメンバーが最大のパフォーマンスを発揮できる形でスクラムを運用していくことが望ましいのです。

自分たちのスクラム運用

自分たちのプロジェクトで実施したスクラムの運用例を紹介します。まず、スクラムガイドをチームメンバー全員で輪読しました。また会社の書籍購入制度を利用して全員がエッセンシャルスクラムを購入しました。

スクラムイベントの司会はスクラムマスターが担当していました。スクラムマスターはEMでもあるのでプロジェクトの進捗に責任を負っています。しかし、開発メンバーに対して「先にこのタスクをやった方がいい」などの具体的な指示は出していませんでした。チームがどう動くかを一歩引いて観察し、困った時に助言をくれるコーチとして振る舞ってくれました。

チームメンバーが「この場合、スクラムではどう考えるのか」という疑問を持った時、スクラムマスターは口頭で回答していました。その後、Slackでエッセンシャルスクラムやブログ記事からより詳しい考え方を引用して、何ページを参照のことという形でしっかり答えてくれました。

認定スクラムマスターの方が答えてくれるという安心感とチームメンバーの疑問に対して一緒になって考えてくれる上に、口頭と出典ありの二段構えで誠実に答えてくれる姿勢によってチームメンバーからスクラムマスターに対する信頼はとても厚かったです。

スクラムマスターの回答は特にエッセンシャルスクラムからの引用が多かったため、スクラムイベント中にチームメンバーがスクラムマスターに質問した時、自分は裏で即座に手元のエッセンシャルスクラムの目次を開いて該当箇所を探し、その疑問と答えが書かれていそうな箇所を読むようにしていました。これを何度か繰り返すうちに、エッセンシャルスクラムの中にスクラムでよく起きることがほとんど解説されていることに気づき、自分の疑問も自分で解消できるようになりました。

スクラムマスターのファシリテーションは1ヶ月ほど続きました。チームメンバーがスクラムイベントのやり方を理解し始めた2ヶ月目から、プロダクトオーナーと開発メンバーがランダムで司会をすることになった。スクラムイベントは全て一枠50分で設定されていたので司会は一枠ごとの交代制でした。

しかし、必ずしもこれを真似る必要はありません。実際にチームの習熟度に応じてリファインメントの時間を減らしたり、スプリントの期間を変えたりと時期によって柔軟に変化していたからです。これはあくまでも一例なのです。

（プロジェクト中盤のスクラムイベントのカレンダー）

スクラムのループ図で見たように、スクラムはプロダクトバックログリファインメントから始まりスプリントレビューで終わります。次回からはこの順番で各スクラムイベントの定義と自分たちのプロジェクトでの運用法を詳述します。

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の2日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

（本内容は2022年4-6月時点の情報であり、一部古い情報が含まれている可能性があります。ご了承ください）

本記事では、開発内容やプロジェクトの体制、開発の進め方を概観します。

私たちが担当したプロジェクトとは

2022年4月上旬、担当していた機能の開発が一段落した頃にマネージャーから次の開発をアサインされました。それはビジネスをより大きくするための社内のメンバーが利用する機能開発です。社内ツールとはいえ顧客の個人情報を扱ったり、これから新しい業務を始めるため仕様が全然決まっていなかったりと難易度は低くないと感じました。

しかもなぜかリリース目標の期限が決められていました。それは5月のゴールデンウィーク明け。1ヶ月しかありません。達成するしないに関わらず、期限を決められているのはエンジニアが最も嫌がることです。自分は率直に「期限が最初から決められているのはアジャイルではない」とエンジニアリングマネージャーに伝えました。彼も同じ思いだったのですが、とにかくまず見積もりをしようという話になりました。今から思うと彼自身ビジネスの人に流石に無理だと伝えることはできたものの、自分たちエンジニアの出方をある種試していたのかもしれません。

とにかくタイトなスケジュールと仕様が何も決まっていないという不確実性への対応が求められました。最終的にやはりゴールデンウィークには間に合わなかったものの、結果的に誰も疲弊することなく6月末にリリースを実現しました。しかもスクラムをうまく活用したためビジネスの方からは「遅れている」と急かされるどころか、開発が着実に進んでいることがわかり安心感があると言ってもらえました。この体験はステークホルダーと適切に関わった成功例だったと考えています。

プロジェクトメンバーの紹介

プロジェクトメンバーは、入社して1年ほどたったフルスタックエンジニアの自分、入社して2,3ヶ月目の二名（前職でゲーム開発をしていた方とDDDを実践していた方）、ISUCONの上位入賞チームのメンバーと業務委託の方が1名、またフロントエンドエンジニアが1名でした。

私はフロントエンドエンジニアとして入社して、このプロジェクトでもフロントエンドの開発でアサインされました。しかし元々バックエンドエンジニアとしてキャリアを始めていたこと、このプロジェクトではフロントエンドのタスクが少ないことが早々に分かったため、自分はバックエンドのコードを書くことにしました。

私たちのチームはバックエンドエンジニア5名、フロントエンドエンジニア1名、プロダクトオーナー1名、エンジニアリングマネージャー1名が所属していました。このように多様なバックグラウンドを持つメンバーでチームが構成されていたことで、チームの柔軟性と問題解決能力が高まる結果に繋がったと考えています。

スクラムマスターの下でスクラムを実践する

同じチームのエンジニアリングマネージャーは認定スクラムマスターでもありました。スクラム開発をチームに取り入れたいということで、私たちはまずスクラムガイドを輪読しました。

私は前職でスクラム開発が好きという方と同じチームになり、その方からスクラムの考え方を学んでチームでスクラムイベントをいくつか実施していました。しかしスクラム開発によって劇的にチームの状況が改善したと感じることができなかったため、当時はスクラム開発に対して懐疑的でした。ただし、スクラム開発の真髄に触れたあるきっかけから自分はスクラム開発の積極的な推進者になります。

4月はイテレーションを1週間に設定しました。仕様が決まっておらず着手できる開発タスクがほとんどなく、調査と仕様策定の会議が多かったためです。仕様が決まり始めたらエンジニア陣は開発に着手できます。するとレトロスペクティブ（振り返り）で「スクラムイベントのミーティングが多すぎる」といったフィードバックが出たため、5月からはスプリント期間を2週間に変更しました。

また、各種スクラムイベント（デイリースクラム、スプリントレビュー、レトロスペクティブ）を活用し、チーム内外のメンバーと密にコミュニケーションを取りました。特にレトロスペクティブでは振り返りの手法をKPTから「思ったこと、問題点、Next Action」に変えるなどチームで対話をして一つのやり方に固執せず柔軟に進めました。

各スクラムイベントや成果物の表現にどのようなツールを使い、どのように実践していたかは次回以降の記事で紹介します。

XP（エクストリームプログラミング）を導入する

XP（エクストリームプログラミング）はTDD（テスト駆動開発）で有名なケント・ベックが考案したソフトウェア開発手法です。私はTDDとペアプロが好きで前職から実践を続けており、ケント・ベックのXPもいつか腰を据えて実践したいと考えていました。そこでこのチームは社歴の浅いメンバーもいるため、チームビルディングも兼ねてペア・モブプログラミングを取り入れることを提案しました。

PHPStormのコードを共同で編集できる機能であるCode With Meを活用したペア・モブプログラミングを皮切りに、必要最小限の設計を行った後に実装を進める「インクリメンタルな設計」や、「リファクタリング」をスプリントの初めに実施して品質向上を図ったり、オンラインコミュニケーションツールであるGatherを活用して「全員同席」を実現するなど、XPのプラクティスを導入していきました。

XPは技術プラクティスだけと思われがちです。しかし、実際そうではありません。またかつては「アジャイル開発といえばXPかスクラム」という位置付けだったそうですが、スクラムとも対立するどころか被るところも少なくありません。

例えば、「情報満載のワークスペース」はスプリントバックログアイテムやバーンダウンチャートを表現したFigJamがそれに当たります。「計画のストーリー」はストーリーポイントでの見積もりであり¹、「週次サイクル」はスプリントそのもの、「本当の顧客参加」はスプリントレビューで実現されるものです。

このように、スクラムとXPを組み合わせることは何らおかしなことではないのです。アジャイル開発を実現するためにエンジニアリングマネージャーがプロジェクト管理の側面が強いスクラムを推進する一方、エンジニアである自分はXPをチーム全体に導入したのは自然な流れでもあります。

様々なツールの活用

このプロジェクトでは、いくつかのツールを組み合わせて使っていました。現在では社内でNotionやGoogle Meetsが活用されているため、ここにはもう使っていないツールも含まれています。

タスク管理には最初Asanaを使っていましたが、後にFigJamに移行しました。カンバンを作って作業状況の可視化を促進するためです。コラボレーションツールにはGatherを活用しており、業務開始から退勤するまでみんなGatherに集まって通話を繋いでいました。この時はコロナでリモートワークが始まって1年目が経った頃だったので、フルリモート下でのコミュニケーションの重要性が強調されていたからです。

「話した方が早い」という場面ではすぐにGatherで集まる運用を定着させました（ただし、今ではGatherではなくSlackのhuddleを活用しています）。

Four Keys - DevOpsのメトリクス

Four Keysについても触れておかねばなりません。Four Keysの4つの指標はそれぞれ「デプロイの頻度」「変更のリードタイム」「変更失敗率」「平均復旧時間」です。しかし今回の開発は新規開発が9割で既存機能の改修が1割であり、社内メンバーだけが使えるシステムに機能を追加するものだったため平均復旧時間と変更失敗率は特にトラッキングしませんでした。

DevOpsのFour KeysといえどもOpsではなくDevの指標のみに注目していたことになります。今回のプロジェクトでは、24のケイパビリティの中から特にトランクベース開発を意識して導入しました。これによりデプロイ頻度が向上してリードタイムを短縮でき、以下の成果を得ることができました。なお、指標の期間はキックオフからリリースまでです。

デプロイ頻度

デプロイ頻度について、仕様策定が多かった4月を除くと5,6月の営業日では実に95%の日でデプロイをしています。5月は毎日デプロイをしました。デプロイ頻度を上げることで、着実に前に進んでいるという実感がチーム全体に広がっていきました。

1日あたりのデプロイの数は1日1回が多いものの、1日に4回デプロイできた日は「自分たちは開発を大きく進めた」ということでチームメンバー全員の士気が大幅に上昇したことを覚えています。

変更のリードタイム

変更のリードタイムはファーストコミットの時刻からマージした時刻を集計するとチームで決めていました。マージまでにかかった日数とプルリクエストの数を見ると、なんとコミットからマージまで翌日に持ち越さなかったプルリクエストは27件、1日しか溜めなかったものは34件で前プルリクエスト数の大半を占めます。

さらに、マージまで6日かかったプルリクエストの2件は開発初期にしか発生していません。ゴールデンウィークが明けた5月6日以降は2日の例外を除いて、全て最大プルリクエスト保持期間が2日以内に収まっています。

しかも5月30日以降は1日を除いて全てのプルリクエストを翌日以内にマージしています。全体を通してみてもプルリクエストの保持期間が短くなっていることが顕著にわかります。

1つのプルリクエストを小さくする意識が浸透したことから、時間が経つにつれてプルリクエストのコメント数が減少していることがわかります。チームでペアプロ・モブプロが浸透したりコミュニケーションを密に取った結果、レビューコストが軽減されたことを見て取ることができます。

このように、各種指標からも時間と共に開発が効率化できたことがわかります。それに伴ってチーム外からは効率的で信頼性の高いチームだと認識され、チーム内でもレビュー待ちやレビューコメントが減少してメンバー同士の信頼関係が醸成されていきました。

では、私たちはアジャイル開発のプラクティスをどのように運用したのでしょうか。次回からは7記事に渡って私たちが実施したスクラム開発の実施方法を詳説します。

Footnotes

1. そもそもストーリーやストーリーポイント自体がスクラムではなくXPのアイデアであると、XPの考案者の一人である Ron Jeffries 氏は自身のブログStory Points Revisitedで語っています。 ↩