認定スクラムプロダクトオーナーになりました
こんにちは。
先日アギレルゴコンサルティング様が提供しているCSPO研修を受講し、無事CSPOになれました。パチパチパチ。
講師は組織パターンの著者でもあるJames Coplienさんです。本は読んでません、Copeさんごめんなさい。
8つのモジュールを４日かけて履修しますのでだいぶ集中力が必要です。
スクラム入門
プロダクトを管理する（だけではない）あなたの仕事
スプリント
プロダクトゴールと組織
プロダクトバックログを機能させる
スプリントでの生活
プロダクトバックログの活用
プロダクトバックログを使ったビジネスの運営
なぜ受けようと思ったのか
きっかけは、最近アジャイル開発について受ける相談の中で「POとして何をしていけばよいかわからない」という内容が増えていると感じたことでした。スクラムを実践する中で、「POとして何をやればいいか」「POとしての責務を果たせているか」ということの悩みは尽きないもので、裏を返せば継続的な支援が必要な部分だということです。
このような事実にスクラムマスターとしての自分のキャリアを重ねてみた時、自分のキャリアは開発チームの支援に偏っているなと感じました。私は良いスクラムマスターの条件の１つはスクラムチームを包括的に支援できることだと思っています。まだまだ良いスクラムマスターになるために学ぶことがあると感じました。
会社に受講を相談したところ秒でOKをもらいました。本当に感謝しかありません。どうもありがとうございます。
特に印象的なことをいくつか
具体的な受講内容を書くのはNGだと思うので、個人的に勉強になった点や感想など書いていきます。
が、きれいにまとまってない点はすみません。
アジャイルは後発的な要求のあるシステムのための開発プロセス。後発的な要求というのは、実装技術、マーケット、組織、そして私達も含まれる。それらの後発的な要求に対応するためには、短い時間で小さく遂行しフィードバックを早く得ることを促進する。最初に要求をガッチリ決めた後ほぼ変更が発生しないのあればアジャイルじゃなくても良いので後発的要求がどのくらいありそうなのか、後発的要求がプロダクトの価値に大きく寄与するのか、とかを考えることが大切だと思った。
プロダクトオーナーの使命はプロダクトの価値を長期的に最大化すること。極端な表現をするとこの４日間、ずっとこの話しかしてなかったと思う。プロダクトを開発していく中でずっとかんがえ続けなきゃならないことだし、全然簡単じゃないと思った。できる気がしないとさえ思った（がんばれ）。
戦略的リーダーシップ。POはプロダクトゴールを実現するために開発者を導く。あなたはプロダクトとPBLを管理し、あなたについていく人は自分自身を管理する。この言葉はPOとDevがもつリーダーシップの境界が少し明確になった気がする。
PBLは「POが提示するもの」ではなく、「チームで共通認識を得るためのもの」。作るのはPOだけど見積もるのは開発者だし、その間には当然やり取りが発生するはず。むしろそういったやりとりこそが大切でPBLはそのきっかけ作りに過ぎないという理解をしました。
PBLはユーザーストーリーでも要件定義でもなく、仕様の固まり。（これはCopeさんの考えです）。ユーザーストーリーは語るもので書くものではない。PBIには何を作るか(What),いつまでに欲しいか(When)を書き、どう作るか(How)は書かない。シンプルで理にかなっててわかりやすいと思いました。前述したチームの共通認識のためにも開発者が理解できる内容で書かれている必要があります。ユースケースとか良い。
PBIには依存関係がある（少ないほうが良いけど）。なので優先順位を決める時は依存関係「も」考慮する。「も」というのは依存関係以外にもビジネスバリュー、ROI、ストーリーポイントなど（他にもあるかも）、様々な要素を考慮して決める必要がある。様々な要素が何かというのはマーケターや顧客や開発者などと協力してあらゆる視点で判断する。なのでPOはPOチームを組むのがいいって思った。デザインマトリクスとか良い。
見積もりには時間をかけない。見積もりは必要な作業だからやるけど見積もり自体は何も価値を生まない。だから時間をかけない。これはすごく勉強になった。見積もりはこの後の作業を"やりやすく"する程度のおおまかな指標であれば充分に役目を果たしている。正確さを求めたり時間をかけるのはナンセンス。
スプリントゴールはSBLの実装を通じて満たすことができるスプリントの目標。スプリントゴールはPOが掲げるけどここもやはりチームと合意が必要。チームと会話するときにはどう作るかではなく「どんな価値に貢献するのか」「それで何を達成できるか？」という視点で語る。PBIはなに(What)で、スプリントゴールは(Why)。
Jiraダメ。
スウォーミングが大切。集まって話すことの良さはフィードバックの早さと熱意によるイノベーションが起こること。最近は「集まるよりもテキストでやり取りしたほうが他人の時間を奪わず効率良いのでは？」という話もあるが、そのやり取りに素早いフィードバックやイノベーションの創出を求めているかどうか？というのが１つ判断基準になると思った。これは自分が質問したんだけど、すごく良い回答がもらえたので他の人にも伝えていきたい。
防火壁。この話を聞いていて防火壁になっているつもりのPOとSMが、実はチームに放火していることは多いのかもしれないと思ってゾワっとした。少なくとも自分は放火した記憶があります。反省。
デイリースクラムにはいま３つの質問は定義されていない。デイリースクラムは作業の経過報告の場ではない、デイリースクラムはスプリントゴール達成に会話を向けるため。
楽しかったこと
ワークでチーフPOであるCopeさんの要求をうまく引き出せたのが最高に嬉しかった！それとグループワークで、スウォーミングしながらアイディアを出し合い、この成果に繋げられたのが最高でした。
研修での学び
直接Copeさんや川口さんに質問できる機会があったので、みなさん質問していました。一番多かったのは「自分の現場ではこうなんですが・・・」というリアルで起きている（いた）ことについての問いかけでした。
ここについてとても興味深かったのはたいていの答えは「チームを見ていないのでなんとも言えませんが、」「適切な粒度はチームできめましょう」「場合によります」のような答え方から始まることが多かったことです。
このやり取りから、現場の答えは現場にあるということを改めて強く感じました。Copeさんも川口さんも自分の経験や参考値としてのアドバイスはしてくれますが、それがチームにとっての正解なのか、チームが求める答えなのかということは結局チームにしかわからないしチーム自身が判断することです。
プロダクトの価値を最大化するために、またチームにとっての最適な答えを自ら見つけられるように、POは材料を惜しみなく、かつわかりやすく提供し、問いかけ、共通理解を得ることに尽力するのだなと思いました。
そういう意味で、やはりこの４日間は「プロダクトオーナーの使命はプロダクトの価値を長期的に最大化すること」の話をずっとしていたんだと思います。
（完全に余談ですがCSPO研修に認定試験がないのは、なにが正解なのかがプロダクトやチームに依存するために、問題の一般的な正解として定義しにくいからなのかなって想像してました。）
後日談
４日間の研修では理解が追いつかないこともあったので、同じ日に参加していた方と後日感想戦をやりました。感想戦によってお互いの理解を補足しあったり新しい気づきがありました。
そして自分の理解をこうやって文字にしてみることでその日に理解できなかったことがだいぶ咀嚼できてきたと思います。
全体を通して
Copeさんの研修は４日間の間に「なるほど、PO完全理解した！」とはならないのですが（自分が理解はゆっくり派というのもありますが）、咀嚼を続けていくうちに後から１つ１つの言葉の意味が繋がってくるような、深みのある研修だと感じました。
資料もCopeさんの言葉を思い出しながら改めて読み直してみると、その場でわからなかったことでも、今はしっかりとした意味をもっていることが理解できました。
Copeさん、アギレルゴコンサルティングさん、そして４日間ずっと私達のために素晴らしい通訳をしてくださったSeth Reamesさん、本当にありがとうございました。
