POとして

紙粘土スクラムへの参加（2度目）

アジャイル札幌のスクラム体験イベント（紙粘土スクラム）に参加した。このイベントは紙粘土で動物を製作することをソフトウェア開発に見立ててスクラムを体験するもので、過去にスクラムマスターで参加したことがあったが、今回はプロダクトオーナー（PO）役として2度目の参加だった。

2019年4月に認定スクラムマスターを取得し、前回よりうまく振る舞えるだろうという目論見は大きく外れ、不本意ながら多くの学びを得ることになったので、記録しておく。

イベントの概要

紙粘土でつくるプロダクトは動物園（の動物たち）で、前回と変わらず。

イベントの大まかな流れは以下の通り。

・スクラムの解説
・役割を決める（立候補制）
・チームを分ける
・動物園のビジョン（プロジェクトのゴール）発表
・ユーザーストーリー出し
・プロダクトバックログ作成
・受入基準決め
・全体計画
・スプリント（計画→実装→レビュー→レトロスペクティブ）x 4

なお、スクラムチーム外のステークホルダー役は運営スタッフが担当した。

プロダクトバックログ作成にて

スクラムチームでそれぞれ3つずつユーザーストーリーを出し、1列に並べてプロダクトバックログを作る。ステークホルダーの意見に耳をかたむけつつ、チームの意見も取り入れてPOが中心となって優先順位をつける。

ここで僕は、チームの意見は聞いたものの、重要なステークホルダーの意見を聞かなかった。初っ端からPOとしてはありえない失態である。

受入基準決めにて

ユーザーストーリーからプロダクトバックログを作ったら、受入基準を決める。いわゆるDoD（Definition of Done, 完成の定義）である。

―――と思っていたのだが、あらためて調べたら受入基準と完成の定義は別ものだった。

完成の定義はスクラムガイドに明記されているが、受入基準は軽くふれられている程度である。それぞれの定義はおおよそ次の通り。

完成の定義：開発チームが定義する作業完了の基準
受入基準　：POが定義するプロダクトバックログ完了の基準

この時、受入基準は「何匹必要か」「大きさはどの程度か」くらいしか定義できておらず、透明性からは程遠いものだった。

全体計画にて

反省点はプロダクトバックログ作成と同じでステークホルダーの不在。

（スプリント）計画にて

開発チームから受入基準が厳しい（=必要数が多すぎる）という意見が出たが、POの僕はシンプルなプロダクトをイメージしていたので、「できるはず」と突っぱねた。前述の通り、受入基準の精度が悪かったため、この時点で開発チームとスプリントのゴールの認識がずれていたはずである。

案の定、開発チームは僕の期待する以上の品質でつくり込み、また曖昧な要件を自分なりに補いながら実装することになった。

レビューにて

スプリントのレビューはPOが受入基準にのっとって行うものであるという誤った認識から、実装中に受け入れを済ませていなかった。

あらためて、スクラムガイドによるスプリントレビューの概要は以下の通り。

・インクリメント（プロダクトのこと）の検査
・必要であればプロダクトバックログの適応
・スクラムチーム＋ステークホルダーが行う
・価値を最適化するために次に何ができるかを参加者全員で話し合う
・フィードバックや協力を引き出すことが目的

ステークホルダーに受け入れてもらおうとしていた時点で間違っていた。

レトロスペクティブにて

いわゆる「振り返り」で、話題の中心は開発チームによる実装方法（How）だった。いかに効率よく実装するかがチームの関心事だと思っていた。

しかし4回のスプリント終了後に開発チームから実装を"やらされてる感"があったことを感想としてシェアされた。僕はステークホルダーの意見を参考にバラエティに富んだ動物園をめざしてバックログを動かしていたのだが、開発チームには伝わって（伝えて）おらず、結果としてスクラムチームとして同じ目的を共有できていなかった。

レトロスペクティブで毎回のようにプロジェクトの目的（Why）を再確認すればよかったという反省がある。

役割の関係性を整理

スクラムチーム（開発チーム、スクラムマスター、プロダクトオーナー）と、ステークホルダー、そしてユーザーの関係性をあらためて整理しておく。

■スクラムチーム
開発チーム　　　　：自分たちで開発/リリースする責任を持つ
スクラムマスター　：スクラムの促進と支援をする責任を持つ
プロダクトオーナー：プロダクトの価値を最大化する責任を持つ

■スクラムチーム外
ステークホルダー：プロジェクトの利害関係者
ユーザー　　　　：プロダクトの利用者。今回は動物園への来園者

いずれも理解した気になっていたが、スプリント中にその役割への正しい期待、その役割としてのあるべき振る舞いができていなかった。

ステークホルダーとは何者だったのか

これまで業務システムの開発しか経験のない僕には、この時のステークホルダーの実像がうまくイメージできていない。

業務システムにおいては、現場の業務が事実としてあるので、その事実をヒアリングし、要求を引き出しつつ、整理・構造化して開発対象の合意を得ることを考える。

今回の動物園のように一般のユーザーが使うサービスの場合、ステークホルダーは当然ながら答えを持たない。しかしプロジェクトのオーナー（の一人）という位置づけだろうから、当然無視するわけにもいかない。

「親子で楽しめる動物園」というプロダクトビジョンを満たしていれば、ステークホルダーの意見や要望はあと回しにすることもあり得そうだが、いまだにどう接するべきだったかがわからない。

POとして

スクラムはフレームワークであるので、まずはその型にはまってみることが大事だと思う。

しかし今回のイベントでの自分の行動を振り返ってみると、実装を手伝ってみたり、スクラムマスター的にふるまってしまったり、POの役割外の言動が多く、その分POとしての役割を十分に果たせていなかったと反省する。

唯一、バックログをユーザーへ最大の価値を提供する視点で管理できたことだけ、今後もKeepしたいと思う。