読者です 読者をやめる 読者になる 読者になる

Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

CSPO 研修を受けてわたしたちのスクラムについて思うこと

アプレッソ開発部の佐々木です。

開発部のマネージャーをやりながら、アプレッソの主力プロダクトである DataSpider Servista のプロダクトオーナーを担当しています。

本記事は、Appresso Advent Calendar の 15 日目の記事です。

qiita.com

先月、Odd-e Japan の認定スクラムプロダクトオーナー研修を受講してきました。

研修は 3 日間で行われ、スクラムの概要やスクラムにおけるプロダクトオーナーの役割、然るべき振る舞いなどを学んできました。この研修の中で、DataSpider Servista の開発チームが実践しているスクラムに対して多くの気づきがあり、この記事ではその気づきを紹介していきたいと思います。

アプレッソが現在実践しているスクラムについては、Appresso Advent Calendar の 2 日目3 日目で詳しく紹介されていますので、そちらを読んでいただければと思います。

目次

スクラムにおけるプロダクトオーナーの役割

スクラムにおけるプロダクトオーナーは、プロダクトのビジョンを明確にし、チームの ROI を最大化させることに責任を持つ役割になります。

プロダクトのビジョンは、市場に対してプロダクトが目指す方向性のことで、その方向性をチームに示すためにプロダクトオーナーは首尾一貫した決断力と確かな情報収集力が必要だと思います。

チームの ROI はプロダクトのビジョンに従ってチームが具現化した価値とそれにかけたコストの割合のことで、その割合を最大化することがプロダクトオーナーの責任です。

プロダクトバックログ

プロダクトバックログとは、プロダクトの要件を一覧で見える化したものです。 プロダクトバックログはプロダクトオーナーとチームの持ち物ですが、プロダクトバックログアイテムを書いてそれぞれのアイテムに優先順位を付けるのはプロダクトオーナーの仕事です。

INVESTなプロダクトバックログアイテム

プロダクトバックログアイテムを書く上で意識していることが「INVEST」です。INVESTとは、良いとされるプロダクトバックログアイテムの特徴を表した以下の単語の頭文字です。

  • Independent (依存しない)
  • Negotiable (交渉可能)
  • Valuable (価値がある)
  • Estimatable (見積り可能)
  • Sized Right/Small (手頃なサイズ / 十分小さいサイズ)
  • Testable (テスト可能)

Independent

プロダクトバックログアイテムそれぞれが単独で成立している、つまり他のプロダクトバックログアイテムとの依存関係が排除されているということです。プロダクトバックログアイテムに依存関係があるとチームの見積りが難しくなるだけでなく、作業効率にも悪影響を及ぼします。

Negotiable

プロダクトバックログアイテムの内容に対してチームが交渉可能なことで、プロダクトオーナーが決めたことが絶対ではないということです。交渉の余地がないとチームにとって自由で柔軟な発想がしづらくなるでしょう。

Valuable

プロダクトがターゲットにしている市場に対して受け入れられること、つまりビジネス価値があるということです。プロダクトオーナーの妄想でビジネス価値の無いプロダクトバックログアイテムを作ることは、チームの成果を台無しにしてしまう裏切り行為と言えるでしょう。

Estimatable

プロダクトバックログアイテムの内容が見積り可能ということです。見積りが難しい内容になっていると、スプリントプランニングの際、チームがタスクを見積ることが困難になり、それだけ見積り作業に時間が取られることになります。見積りしやすいプロダクトバックログアイテムを作ることは、チームのコスト削減の観点からも重要です。

Sized Right/Small

プロダクトバックログアイテムがチームにとって手頃なサイズ (十分小さいサイズ) になっているということです。プロダクトバックログアイテムのサイズが大きいと、見積りが難しくなるだけではなく、不確実性やリスクが多く含まれている可能性がある状態になります。この状態だとチームはスプリントプランニングに多大な労力をかけることになり、ベロシティを上げることが困難になります。

Testable

テストが可能になっているということです。テストが可能になっているということは、チームにとって自分達の作業範囲や完了基準を明確にできるという点で重要です。

Independent と Sized Right/Small の関係性

ここで、Independent を重視して依存関係を排除した結果、Sized Right/Small が十分でなくなるケースが考えられます。このような場合は、小さく分割したプロダクトバックログを後からまとめることは簡単だけど分割するのは手間がかかるので、Sized Right/Small を重視してサイズは小さくしておくことが望ましいと考えます。

プロダクトバックログアイテムを書くスピードは 1 つにつき 1 分

上記の特徴を意識してプロダクトバックログアイテムを書く場合、現状の私だと数分から長いときだと数時間程度かかることがあります。 ただし、認定スクラムプロダクトオーナー研修の中で講師の江端さんが言っていたのが

プロダクトバックログアイテムを書くスピードは 1 つにつき 1 分

ということでした。

これを聞いたときは、できるイメージがまったく浮かばず呆然としてしまいましたが、現状プロダクトバックログアイテムを書く時間がかかっている理由を考えてみると、プロダクトバックログアイテムを書く際に既存機能の動作を確認したり、アイテムのサイズが想定よりも大きくなって分割したり、曖昧な表現を修正したりと、実に試行錯誤しながらやっていました。

情報収集の大事さ

そのような状況になる大きな要因として、「情報収集が足りない」ことが考えられます。

持っている情報が足りない状態で書こうとすると時間がかかるわけで、十分に情報を持ったうえでプロダクトのビジョンが明確に整理されていれば、それを文字に起こすのはそう時間はかからないはずです。

他にも

情報収集が足りないことがチームに対して良くない影響を与えるケースも考えられます。

それは、チームからプロダクトオーナーへの質問に対しての回答が遅くなるということです。スプリントの中で、プロダクトオーナーはチームから質問を受けることが良くあります。その際、プロダクトオーナーが持っている情報が不十分だと、誤った回答をしてしまう、その場で回答を探るような議論が展開されてしまう、プロダクトオーナーが持ち帰って回答までに時間を要してチームの作業が止まってしまう、というようなことが考えられます。

プロダクトオーナーはチームに対して満足のいく回答ができるよう十分な情報収集を行い、質問に対する回答までの時間を短くすることを意識する必要があります。さらにそこから発展させて、チームからの質問回数を減らしてチームが開発作業に集中できるようにすることも重要だと考えます。

プロダクトバックログはプロダクトオーナーの腕の見せどころ

プロダクトオーナーにとってプロダクトバックログとは腕の見せどころで、とにかく数多くプロダクトバックログアイテムを書くことで良くなっていくと講師の江端さんも言ってました。

チームにとって作業しやすい手頃なサイズであること、誰が読んでも同じように理解できる受け入れ条件になっていること、優先順位がつけられていること、これらの条件が揃った一貫性のあるプロダクトバックログを作ることによって、チームの ROI 最大化に貢献できると考えます。

プロダクトオーナーは誰よりも多くプロダクトを触る

プロダクトオーナーは誰よりもプロダクトを使い倒して、その良し悪しを把握している必要があると思います。

しかしながら、10年以上今のプロダクト開発に携わってきて現状プロダクトオーナーの立場である私は全てを把握できていません。その理由は、「プロダクトを触れていない」ことが大きいと思います。

スプリントの中で積極的にプロダクトを触る

スプリントを開始した当初は、プロダクトオーナーである私はプロダクトを触らずにプロダクトバックログアイテムに定義された受け入れ条件を確認していました。

プロダクトを動かさずにどうやって確認できるのか?
それは、スプリントレビューの場でチームによるデモで確認していました。

しかし、スプリントレビューは、スプリントの成果をチームが発表し、プロダクトを改善するためのフィードバックを得る場です。チームの成果が受け入れ条件を満たしているかどうかは、スプリントの中でチームが作業を完了したタイミングでやるべきです。そのタイミングでやることでチームは成果に対して素早いフィードバックを得ることができます。

スプリントレビューでチームにデモをやらせるのはプロダクトオーナーの怠慢で、スプリントレビューで本来やるべきことを阻害していることに気づきました。

プロダクトオーナーはスプリントの中でも積極的にプロダクトに触ることが重要で、その土台となるのは積極的にチームに関わっていくマインドを持つことだと思います。

「完了」の定義 (Done と Undone)

スクラムでは、作業の完了についてスクラムチーム全体で共通理解を持ち、透明性を確保するためにプロダクトのリリースまでに必要なすべての作業を一覧にして見える化します。これを「完了の定義」と言います。完了の定義は、チームが毎スプリント必ず担保する作業を「Done」、担保できない作業を「Undone」としてグループ分けします。

アプレッソのスクラムで Done に分類されているものは、例えば「コーディング規約に則っていることの確認」や「ユニットテストの作成および実施」があります。

一方、Undone に分類されているものは、「ヘルプドキュメントの作成」や「リリースノートの作成」があります。

Undone はプロジェクトが進むにつれて増えていく

Undone はいわば負債のようなもので、Undone を回収しないままプロジェクトを進めていくと Undone が増えていくことになります。

例えば、あるスプリントの中で一つの機能が実装されたとします。その機能のヘルプドキュメントを書くことはプロダクトをリリースする上では必要な作業ですが、Undone なのでスプリントの中では行いません。このような機能が毎スプリント実装されるとスプリントを重ねるごとにヘルプドキュメントの Undone が増えていくことになります。

スプリントが終わるまで Undone が回収されずに増えていくということは、つまりプロダクトのリリースに対してリスクが高まっていくことになります。

Undone は細かく回収する

Undone を増やさないためにプロダクトオーナーが打つ施策としては毎スプリントで「Undone は細かく回収する」ことになります。これは認定スクラムプロダクトオーナー研修で「呪文のように覚えろ」と言われた言葉で、今では私の耳から離れないフレーズになってます。

毎スプリント Undone を細かく回収するには Undone 自体がプロダクトバックログで管理されて、チームが見積り可能な状態になっている必要があります。Undone が残っていて、それをスプリントでどのように回収するかの責任はプロダクトオーナーにありますが、Undone を回収するのはチームです。

チームは生産性を向上させるという観点から、自律的に Undone の回収に取り組む思考が必要ですが、Undone の回収に取り組むためにも、まずはベロシティを安定させることが重要です。

プロダクトオーナーはそのようなチームの活動を支援するために、Undone をチームが扱いやすい状態で管理しておく必要があります。

終わりに

プロダクトオーナーという立場では、今回書いたことを踏まえてチームの成果を多くのお客様が価値として認めていただけるようなプロダクトを開発していきたいと思います。

一方で、開発部のマネージャーという立場では、組織の成長、プロダクトの成長の両方の軸から、プロダクトオーナーの育成や組織上の立場をどうするかなどについて、自分で何ができるか考えて行動していきたいと思います。このあたりの取り組みについては、今後記事として書いていけたらと思います。

最後に、昨日の記事にも書いてありましたが、Odd-e Japan の認定スクラムプロダクトオーナー研修はおすすめです。