JamesCoplienの認定スクラムプロダクトオーナー研修を受けてみた
James Coplienの認定スクラムプロダクトオーナー研修を受けてみた。
認定プロダクトオーナー研修とは？
Scrum Alliance®の認定スクラムトレーナー（Certified Scrum Trainer®：CST®）による 「 スクラム をプロダクト開発の仮説検証のフレームワークとして活用する」ための研修
なんで参加したの？
- ScrumBootCampの書籍以上の事を学べると思ったのと、Scrumの研修はメンバーも受けた方がいい的な事をPodcastで言ってたのを思い出した
- プロダクトオーナーの役割を担った人は、どのような考えで動き、どのような視点でプロダクトやチームを見るのか、純粋に興味があった
- 会社で参加者募っててGooodタイミングだった
研修の内容
大分端折ってる部分もあるが、大枠的には次の構成で研修は進む。
体感的には座学（随時質疑応答のある参加型）がメインで、合間合間にワークショップが挟まれている感じだった。研修は2日行われ、参加人数は40人弱ぐらい。4-5人で一つのテーブルを囲む。
スクラム入門
The Scrum Values（勇気・集中・コミットメント・尊敬・オープン）
Scrumの価値について理解
- 特に「
尊敬」の部分が一番興味深かった。これはメンバーを信頼する事であり、これがないことによって余計な仕事が増えてしまう - 例えば、信頼できないからメトリックスを取って確認しよう。だとか、本当に合ってるかなどを質問によって確認しようとしたりだとか、信頼がないからこそ余計な仕事が増える。TeemGeekでもHRTの一部として尊敬・信頼が語られていたけど、凄く大切。
スクラムプロダクトオーナープロセス
プロダクトオーナーの視点から見た、プロセスの全体像理解
プロダクトバックログを示すのが、プロダクトオーナーの最大の仕事プロダクトバックログリファインメントという、直近のPBIのHOW（設計）を落とし込んでいく活動がある（言葉レベルで知らなかった）- プロダクトオーナーは、新しくプロダクトバックログに積むための
調査や顧客との協調（リサーチ）を、日々のスプリントと並行して行っている - プロダクトオーナーとは、プロダクトの
社長である。要は権限がちゃんとある。
自己組織化
ワークショップを経て、自己組織化したチームがどのようにワークするのかを理解。これが結構面白く、自分達の頭を使って考え、周りを観察しながら各々が調整することにより、自然に丸く収束するのを体験できた。細胞みたい。
- 自己組織化こそ
アジャイルの全て - お前がボスなんだ、出番を待つな、管理を望むな。もし失敗しても大丈夫だ。次のアイデアを試そう。ここにあるのは、
正しい事をする、賢くてモチベーションの高い人々への信教
アジャイルは後発的な要求に対処するためのもの
単純なものからカオスなものまで、色々なレベルの問題があるけども、単純＋煩雑（整理すれば単純）な問題は計画して実行すればいいよね。けど、複雑（何か変わると他も関連して変わるような）な問題は予測できないよね = 計画できない。これは確実性と後発性になるけど、アジャイルはこの後発性に対応するためのものなのだよ。という理解をした。正直問題のレベルとかは意識してなかったので、鱗落ちた。
プロマネやった事ある人？
自己組織化した開発チームと、プロダクトへの権限を持ったPOが居れば、管理するだけのプロマネは居なくても平気だなと理解。というより、必要なくなる。
- スクラムにプロジェクトはない。期間ではなくプロダクトに対してチームがあるから。
- デリバリーの順番をコントロールするのは
POで、開発のペースをコントロールするのはプロマネじゃなく開発チーム。プロダクトの世界を一番知っているのは開発チームだからだ。
プロダクトオーナーの仕事とは
戦略的なリーダー
スティーブ・ジョブスみたいな人が優秀なPO。ビジョンがあるからPOになるのだ。なるほどー、わかりやすい。
- POは
ビジョンと情熱を持っている - フォロワーがいる人（信頼される人）
プロダクトオーナーとは
ビジョンと情熱を持って、ステークホルダーに説明する責任を持つ人か。
- 上司が複数いるかもしれない。しかも
同じ目的を共有していないかも - プロダクトの
ビジョンや価値の説明に責任を持つ人は必要である。上の理由からも、ここは単一責任者=POとして置いた方が良い。
プロダクトオーナーの役割
以前参画していた所で、施策ごとにROIを計算して優先度をつけて、開発チームが作ってデリバリーしてくみたいな感じで回してたんだけど、あの施策出したりする人がPOだったのか。と改めて気づいた。あと、参加者（PO）の話を聞いてて、これはそれなりの権限（お金、人事権）を持っていない人がやると、よくあるマネージャになっちゃってPOとして上手く機能しなそうだなと思った。
価値（ROI）を最適化する- 価値はROI以外でも良い。
何を価値と置くかはプロダクトにより異なる - 明示的な終了（製品を殺す）基準を明確にする
バックログリファイメント
- 開発チームの時間は 5%-10% までに制限する
完了の定義
- 完了の定義は、
表面化（機能）しない部分も含める - 例えば、目に見える機能だけに集中して内部の実装やドキュメントを疎かにした場合、短期的に見るとスピードが上がったように見えるが、技術負債になり中長期的に見てチームは損をする。結果、スピードが下がる。
- なので、表面化していないものでも価値あるものは、完了の定義に含める必要がある。
スプリントレビュー
プロダクトの改善をする活動。話題としては、
スプリントレトロスペクティブ
プロセスの改善をする活動。1週間毎の振りかえりみたいなものだと理解。
プロダクトオーナーの落とし穴
- POが横からチラッと見た時に、開発チームの失敗に気づいてもPOはそれを
あえて教えない - Scrumは管理された環境下での失敗が可能な
訓練のためのツール- 気づき -> 反省 -> 改善に繋げる
- 学習（行動を変えていく）する
ロードマップ
どんなことでも、どこに向かってるかは必要だよね。
- 方向は変えるが、どこに向かっているかは必要
- ただ、6ヶ月を超える予定は夢
開発チームを雇う
プロダクトオーナーがプロダクトの社長とするならば、チームは一つの会社と見る事ができる。チームが会社ならば、必要なスキルを持ったメンバーは会社（チーム）にいるべきである。という考え方かな。
- DevOps、テストなどの横断チームを持たない。
開発チームが全てをこなす - 必要なスキルを持ったメンバーがいない場合は、採用 or バジェットを取って教育 する
プロダクトバックログについて
アイデアのライフサイクル
アイデアがどのように出荷可能な成果物になるのかを端的に表したもの。
- プロダクトバックログは
WHATを書く。「XXを作る」みたいなHOWはだめ - POは順位づけの最終決定権があり、
デリバリーの順番にPBIを並べる
バリューストリームの分岐
- 一つの製品のバックログが複数のバリューストリームを含む事がある
- 分岐しそうになったら、スピンオフしてプロダクトの機敏性を保つ
1つのPBIに群がる
普通にそれぞれが一つのPBIを担当していくものと思ってたので、この考え方はなるほどとなった。
- 良いチームは
一度に1つのPBIに群がる - 各メンバーが別々のPBIを担当すると、全て進捗80%みたいな感じで、
スプリントが終わったのに一つもPBIが完了していませんでした。というような事態になりかねない - トヨタの「一個流し」からヒントを得たらしい
- ちなみに、バーンダウンチャートはポイントの消化率ではなく、PBIの消化率で見た方がいい。ポイントの消化率で見ると、上のような進捗的には進んでるけどPBI完成してませんでした。的な事が起こり得る。
- 慣れてきたら、2PBIまでは並行してもOK
群がりやすくするために
ここら辺の話で面白かったのは、JIRAを使ってPBIを管理してはいけないという話。何故JIRAがダメなのかというと、詳細な記録が残せてしまうかららしい。それの何が問題になるのかというと、誰々がどのくらい機能を作っている。誰々はバグの埋込率が高い。みたいな詳細なログが追えてしまうので、それを使ってマネージャーが管理するとメンバーは個人の成果を追ってしまうことになり、チーム全体で・・という空気になりにくい。なので、付箋（エクセルも可）とかシンプルなやつで管理するぐらいがちょうどいいという話。
※ 通訳をうまく拾えてない部分があるので、解釈が違う可能性あり
- ヒーロー文化に争う
- クロスファンクショナルチームを持つ
- 個々の達成よりチーム全体に報いる
その他よかったこと
- テーブルの参加者が、コンサル・自社製品PO・受託開発PO・エンジニアと、それぞれやっている事が違うので、色々な話を聞けて刺激的だった
- スクラムマスターの役割に関する動画が笑えた
- マイクロサービスは死んだとか、TDDはXXとか、情報工学なんて科学にもとづいてない経験則だろ的な話も聞けた（通訳さんに追いつけずあまり理解できなかったけど
まとめ
- 凄くエモかった
- 膨大な熱量に感化された
- 凄く人間的な取り組みだなと思った（印象変わった
- よって、今まで以上にScrum好きになった
- POプレッシャーとかが大変そうだけど、面白そう
- チラッと出てきたユースケース実践ガイド―効果的なユースケースの書き方買った
