スクラムガイドを読み直す（新米プロダクトオーナーの目線で）

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

経験主義という言葉を知らなかったが内容は納得。ググってみるとスクラムの話しか出てこないのでスクラムの言葉なんだろう。
リーン思考に関しても知らないし、多分ここで一言で説明できるほど単純なものじゃない雰囲気はひしひしと感じるので後ほど調べよう

透明性

創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。スクラムにおける重要な意思決定は、3 つの正式な作成物を認知する状態に基づいている。
透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。

PO の活動をする上で PBI の作成やプロダクトバックログの並べ替えをする機会は頻繁にあって、それら活動の中で自分はとにかく言語化することを重視しているのと符合しそう。
各 PBI をやる意義や、バックログの並び順がなぜそうなるのか、スプリントゴールを何故そう設定したいのかなど、言葉にして整理し開発チームに伝える努力を最大限しようと考えている。
これは元々の自分の気質というのもあるし、POをやる上でそこは大事にしようとまず初めに思った部分でもある。

というのも、そもそも何か特定の役割を担うにあたって、自分の考えていることを伝えず（中途半端に隠して）伝えようとした場合には、他の役割の人から「（よくわからないけど、多分いい感じにしてくれるから）お任せして良さそう」という”信頼”、”尊重”をされがちだと思っている。
考えていることが本当に専門知識の場合には何もかも伝えてしまうのは得策ではないと思う^[1]が、POが考えたことのほとんどは自分たちのチームや製品が置かれている状況を俯瞰して整理した結果だと思っているので、そういったものは全てチームに伝えてしまって良い、伝えるべきだと考えている。その伝える手段として、単なる言語化もそうだし、POの場合にはバックログがある。

「透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。」とあるので、自分はバックログ作成の透明性を言語化により担保して、チームの意思決定のリスクを軽減したいと思っているのかもしれない、などと自己認識を深めた。

脚注

1. 伝えなくていいということではなく、伝えるなら情報の取捨選択を丁寧にやる必要があるという認識 ↩︎

検査

スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければ
ならない。これは、潜在的に望ましくない変化や問題を検知するためである。

適応

プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果となるプロダクトが受け⼊れられなかったりしたときは、適⽤しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなければならない。

この辺り改めて感度を高めておきたい。

１つはデイリースクラムで行われる「スプリントゴールを達成できるのか？」という検査とそれに対する適応。時にはスコープ調整が発生するわけだが、POという役割になったことで今までと違う考え方や意思決定が求められる場面がある。そのスプリントの状況を正しく把握し、より正しい意思決定をできるようにしたい。（”意思決定は観察に基づく”とはこういうことだろうか）

もう１つは PO の活動そのものについて。↑の投稿でも書いたように、バックログの並べ替えやPBIの作成に関しての言語化を丁寧に行うことでそれらの透明性を確保し、スクラムチーム全体で検査と適応がしやすい状態にしておきたい。
自分が言語化に注力したい理由はここにもあり、言語化を怠って自分の中だけで考えをすすめすぎると、勘違いや認識違いが起きた際にそのことが発覚しにくくなり、発覚するまでに大きな間違いに成長しやすい。
その対象がバックログというチーム全体に影響するものであるならば、やはりなおさら丁寧な透明性の確保と検査・適応に努めたい。

スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）

これらの価値基準は、スクラムチームの作業・⾏動・振る舞いの⽅向性を⽰している。下される意思決定、実⾏される⼿順、スクラムの使⽤⽅法は、これらの価値基準を減少や弱体化させるものではなく、強化させるものでなければならない。

なんとなく大事な要素だなーとは思ってたけど、「これらの価値基準を減少や弱体化させるものではなく、強化させるものでなければならない」ほどの意識はなかったかも。

スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。

少なくとも自分は「価値を⽣み出すために必要なすべてのスキルを備えている」チームに所属したことがなく、運用方面やデザイン方面などは社内の専門組織・チームに頼ることになるパターンが常だった。
その点は依頼ベースで待ちが発生してしまうので、「依頼する」PBIを投入 → 他チームの対応待ち → 完了次第「取り込む」PBIを投入、という風に分けるなどのパターンが多いかも。
つまりは「誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。」をやはり完全には実践できてないわけだが、その辺りは現実との折り合いという感じだろうか。

開発者

開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。

• スプリントの計画（スプリントバックログ）を作成する。
• 完成の定義を忠実に守ることにより品質を作り込む。
• スプリントゴールに向けて毎⽇計画を適応させる。
• 専⾨家としてお互いに責任を持つ。

この辺り（悪い意味で）慣れてくると、スプリントバックログ作成がおろそかになったり完成の定義を曖昧に運用するようになったりしてメンバー間でPBIに対する認識違いが生まれがちになる印象。気をつけたい。
対して、スプリントゴールに向けた計画の適応は最近自チームでかなり積極的にやっているので良さそう。

プロダクトオーナー

プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、

• プロダクトゴールを策定し、明⽰的に伝える。
• プロダクトバックログアイテムを作成し、明確に伝える。
• プロダクトバックログアイテムを並び替える。
• プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。

２〜４つ目は「透明性」で書いた通り自分としても大事にしたいポイント。
１つ目はそこには書かなかったが、この点に関しても、バックログやスプリントゴールを言語化していく中で、プロダクトゴールとの関係性がどうなっているのかを都度確認するように努めている。
日々のスプリントの実施に追われるとどうしてもプロダクトゴールに向かっているのか？という大局的な視点は失われがちだし、最初にプロダクトゴールを策定した段階では抽象度が高くその全容を捉え切るのも困難なので、スプリントごとにスプリントゴールとプロダクトゴールの紐付けを確認して、自分たちは確かに大きなゴールに向かっているんだなという感覚を得たり、抽象度の高いゴールを具体的なPBIレベルの解像度から観測できるようにして、スプリントごとにチームとして理解が深まるような状態にしておきたい。

上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。

自チームでも、プロダクトゴールの作成やPBIの作成はスクラムチーム全員で取り組んでいて、その方が天下り感がなくて良い気がする。ただ「最終的な責任はプロダクトオーナーが持つ。」とあるので、自分が責任を持つべきところまで頼りすぎたり委ねすぎたりはしないよう役割のラインは意識しておきたい。

スクラムマスター

スクラムマスターは、さまざまな形でスクラムチームを⽀援する。

• ⾃⼰管理型で機能横断型のチームメンバーをコーチする。
• スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できるよう⽀援する。
• スクラムチームの進捗を妨げる障害物を排除するように働きかける。
• すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックスの制限が守られるようにする。

最後はPOとしても気をつけたい部分。
というのも、POのようなチームの方向性を指し示す役割の人物がネガティブな雰囲気を出してしまうとチーム全体に伝染しやすいと思っているので、理解が困難な問題やゴールが達成できなさそうな状況にぶつかった際にも、それらの認識自体はしっかりした上で、その状況からできることを常に考えてチームが前に進めるようにしておきたい。^[1]
あと、言語化に集中しすぎるとタイムボックスを超えることはとてもよくあるので、その点の時間の使い方もこのタイミングで整理する必要があると感じている。

スクラムマスターは、さまざまな形でプロダクトオーナーを⽀援する。

• 効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀援する。
• 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
• 複雑な環境での経験的なプロダクト計画の策定を⽀援する。
• 必要に応じてステークホルダーとのコラボレーションを促進する。

これら以外の部分に関しても、自チームのSMにはお世話になりまくっているなあなどと。ありがたい限りです。

脚注

1. この言説は「PO のメンタルはその程度には強い」ことを前提としているので、こうは言いつつもあまり背負い込みすぎて潰れないようにお仕事をやっていく必要があるなあ、などとメタ的に感じた。無理するな自分。 ↩︎

スプリント

⼀貫性を保つため、スプリントは 1 か⽉以内の決まった⻑さとする。前のスプリントが終わり次第、新しいスプリントが始まる。

（スクラムトレーニングなどを除けば）１週間スプリントのスクラムしかやったことないなあ、などと回想。

スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり、予測可能性が⾼まる。スプリントの期間が⻑すぎると、スプリントゴールが役に⽴たなくなり、複雑さが増し、リスクが⾼まる可能性がある。スプリントの期間を短くすれば、より多くの学習サイクルを⽣み出し、コストや労⼒のリスクを短い時間枠に収めることができる。

スプリントを短くする効果として「予測可能性が⾼まる。」「コストや労⼒のリスクを短い時間枠に収めることができる。」と同時に「より多くの学習サイクルを⽣み出し」という”多く”なる効果があることは、よく考えれば当たり前だが（自分にとっては）忘れがちな視点なので心に留めておきたい。

進捗の⾒通しを⽴てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。これらの有⽤性は証明されているが、経験主義の重要性を置き換えるものではない。複雑な環境下では、何が起きるかわからない。すでに発⽣したことだけが、将来を⾒据えた意思決定に使⽤できる。

「すでに発⽣したことだけが、将来を⾒据えた意思決定に使⽤できる。」は、大事な考え方だなと思いつつ「やってみないとわからんからとりあえずやってみようぜ！」をやりすぎないようにも注意したい。すでに経験したことをちゃんと尊重してるか（すでに得られている情報から分かるはずなのに分析がおろそかになってないか）という点には常に気を張っておこう的な。

スプリントプランニング

プロダクトオーナーは、プロダクトの価値と有⽤性を今回のスプリントでどのように⾼めることができるかを提案する。

この点は、自分が今いるのが技術刷新プロジェクトというのもあり「プロダクトの価値」の考え方に少し癖がある。というのも、機能追加することは基本的にはないため、ユーザー向けへの価値という観点では短期的には何も変化がない。^[1]
将来の機能追加の加速に貢献するという意味では最終的にはユーザーに価値が届くが、それよりも、例えば実際に技術刷新されたコードに新機能を追加する開発者に向けた価値に着眼点をおくなど、刷新プロジェクトならではの「プロダクトの価値」の見方があると考えてる。
最終的にユーザーの体験を幸せなものにするまでのあらゆる過程がプロダクトであり、そのシステム内に存在するステークホルダーへの価値提供という観点で「プロダクトの価値」を広く捉える視野は大事にしたい。

次に、スクラムチーム全体が協⼒して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。

自チームでもスプリントゴールはチーム全体で策定しているが、POとしてはここでもやはり言語化を大事にするよう心がけている。前スプリントまでの開発で何を得られたか、プロダクトゴールに向かって今どのあたりまで進んでいるか、今スプリントはもちろん、次のスプリントやその先でどういう方向に向かって進んでいくと良いと考えているのか、といったスプリントゴールを策定するのに必要な情報は可能な限り言語化して伝えるのがPOの責務を果たす上で肝要と考えている。

開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。

今までの経験上、結局「ベロシティの予測から見積もりにしたがって実施するPBIを選んで、そこからスプリントゴールを決める」という流れになりがちで、中々「スプリントゴールを達成する PBI を選ぶ」という風に運用するのは難しく感じる。そして実際今のチームでもそうなっている。
この運用だと「元に投入したPBIが消化できないとゴール未達」とPBIベースで左右されてしまいやはり柔軟性に欠けてしまう。スプリントゴールの策定やPBIの作成・分割でまだまだ工夫できる部分はあると思われるので、学習しながらチームにとってのより理想的な運用をこれからも探求していきたい。

スプリントが 1 か⽉の場合、スプリントプランニングのタイムボックスは最⼤で 8 時間である。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。

１週間スプリントであれば、単純計算で２時間？
今のチームの運用だとギリギリ納まるか否かくらいかで運用できていそうなので特に変える必要はなさそう。

脚注

1. 実際には避けることのできない挙動差異等は生まれ得る ↩︎