認定スクラムプロダクトオーナーの資格を取得して考えたこと
こんにちは。HarborS表参道のコミュニティマネージャのしのけん(@kenjirp)です。運営会社である株式会社アンチパターンの取締役もやっています。
株式会社アンチパターン は、
「日本のソフトウェアエンジニアを憧れの職業へ」
というミッションを掲げて、事業を運営する創業2期目(2021年1月現在)のスタートアップ企業です。
公式ホームページはこちら↓
前回は『なぜ経営者としてスクラム開発に向き合い、認定スクラムプロダクトオーナーを取得したのか？』について書きました。お時間がある方は、こちらの記事も読んで頂けるととても嬉しいです。
我々のミッション達成に向けてソフトウェア開発を通してどのように世の中に高い価値を提供するかがとても大事だと思い、「認定スクラムプロダクトオーナー」を取得しました。
認定スクラムプロダクトオーナーとは？
2001年に設立された非営利団体であるScrum Alliance はスクラムに関するさまざまな認定を行っています。その中の一つに、認定スクラムプロダクトオーナー（Certified Scrum Product Owner®：CSPO® ）があります。
(スクラム開発そのものと、その中の役割であるプロダクトオーナーの概要については、前回の記事に記載してますのでそちらをご参照ください。)
(プロダクトオーナーの役割について非常にわかりやすい動画を発見しました。ヘンリック・クニバーグさんが15分で絵を書きながらまとめてくれています。)
いくつかの団体で、Scrum Allianceの認定トレーナーが講義を実施してくれます。私はその中のアギレルゴコンサルティング株式会社の研修を受けてきました。認定トレーナーJames Coplienさんによる、半日x4日間の講義でした。たくさんの事例や質疑応答により、とても理解が深まりました。
貴重な体験ができて、とても感謝しています。
Scrum Alliance以外のスクラム関連団体はこちら↓↓
研修のアジェンダは？
1. スクラム入門
2. プロダクトを管理する（だけではない）あなたの仕事
3. スプリント
4. ビジョンとスクラム組織の構築
5. プロダクトバックログの仕組み
6. スプリントでの生活
7. プロダクトバックログの活用
8. プロダクトバックログを使ったビジネスの運営
詳細は割愛しますが、このようなアジェンダで、16時間の講義が行われました。時間はたくさんあったのですが、集中していたこともあり、時間があっという間に過ぎてしまいました。充実した時間だったので、もう少し受けていたかったなという感想です。
研修を受けて特に印象に残った３つのこと
認定スクラムプロダクトオーナーの研修を受ける以前に、私自身もスクラム開発をいくつか経験したことがありました。その経験の中でプロダクトオーナーとは、スーパーマンのようなものだなと思っていました。
研修の中でたくさんの事を学びましたが、いろんな場所で体系的に整理された記事があるので、ここでは、僕が個人的に大きく印象に残った点について書きたいと思います。
1. プロダクトオーナーチームを作るという選択肢
2. スクラム開発ごっこをやってしまいがちだということ
3. 世界一優秀なスクラムチームがスクラムゴールを達成する確率1 . プロダクトオーナーチームを作るという選択肢
スクラムガイドには以下のように書かれています。
プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。
プロダクトオーナーは 1 人の人間であり、委員会ではない。
ガイドからも読み取れますが、プロダクトオーナーは非常に大きな責任を持ったロールなのです。
プロダクトオーナーは、価値の最大化に責任を持ちます。プロダクトのビジョンについてチームに説明する必要があり、無駄なものを開発チームに作らせてはなりません。また、チームへの投資を獲得してくる責任があります。それだけでなく、わかりやすいバックログを書いたり、ワイヤーフレームを作ったり、チームをなるべく長く維持することも考えなければいけません。
そして、プロダクトオーナーはそのプロダクトにおける全てにおいて、自らが意思決定をしなければならず、
「ビジョンと説明責任において単一責任者である」
と言われています。
どうでしょうか？これを一人の人間が全てやるのでしょうか？
そんな人がいたらまさしくスーパーマンですよね。
研修の中では、どうしてもその難易度の高さをどのように解決すべきかを見出したくて沢山の質問をしました。
僕の中で大きな学びだったのが
「プロダクトオーナーチームを作る」ということです。
どのようにチームを作るのかが気になったのですが、回答としては非常にシンプルで、"スクラムチームに、価値の最大化を達成してもらうためのプロダクトバックログを作るために必要な人数とメンバー構成にすれば良い"という話でした。
具体的に説明すると、アナリスト、マーケター、セールス、UX担当、プロトタイプモデル構築者などなど、そのプロダクトの特性に応じて参加するメンバー構成も人数も異なるのです。そのプロダクトにあった適切なチームを構成すれば良いのです。
「プロダクトオーナーチーム」を作ると単一責任者ではなくなるのではないかという疑問が浮かんだと思いますが、「Chief Product Owner」という役割を一人が担当し、意思決定の責任をこの役割の人が担えば良いのです。
プロダクトオーナーの負荷が高すぎて、開発チームの手が空いてしまうという話をよく聞きます。その問題を「適切にプロダクトオーナーチームを作る」ということで解決できるのです。
2. スクラム開発ごっこをやってしまいがちだということ
アジャイルやスクラム開発が注目されて「ドキュメントいらないらしい」「不確実なので計画は立てないらしい」「2週間ずつに期間を区切って開発をやるらしい」など言葉が先行してしまい、誤解を抱えながら進めている事例を多く見かけます。
会社の上層部の「スクラム開発をやりなさい」という号令を受けて、とりあえず、うまく理解できないけどやってみようという方も多いのではないかと思います。
また、開発チームがスクラム開発でやりたいと言うから、何が良いのかよくわからないけど、プロダクトオーナーをやらされているという人もいるのではないでしょうか？
そんなケースにおいては、残念ながら「スクラム開発ごっこ」になってしまうことが多くあるのではないでしょうか？
僕が初めて関わったアジャイル開発のプロジェクトでもまさにそれが起きました。
・要件リストが存在する
・要件は走りながら詰めていく
・2週間というスプリントの区切りで開発を進める
このように断片的に要素を取り入れただけで、スクラム開発の理解が浅いチームメンバーやクライアントで進めたこのプロジェクトは、スクラム開発のメリットを享受することができないまま、大変なプロジェクトとなりました。
後から振り返ると、それではやはり「スクラム開発ごっこ」にしかなり得ないなと思いました。
また、開発者主導でスクラム開発手法を導入する事が多いと思いますが、その際に、プロダクトオーナーの立場になるひとをしっかりと巻き込む事もとても重要だと考えています。
今回の研修は、ビジネスサイドの方が多く参加されていました。ソフトウェア開発において、プロダクト要件を出す側の人間もしっかりとスクラムやプロダクトオーナーの役割を理解しようとしている機運があるなと思いとても良い兆しだなと感じました。
講義の中でとても印象的だった点があります。多くの方が質問をされていたのですが、皆さんに共通していた点が「スクラムに正解を求める傾向にある」という事です。
James Coplienさんがしきりにおっしゃっていて印象的だったのですが、
「あなたはなぜその質問をするのですか？」
「答えを教えて欲しいのですか？」
「答えがわかればその通りにするのですか？」
Coplienさんが言いたかったのは、以下のようなことでした。
「スクラムは不確実性の高い時代において、ソフトウェアを活用したプロダクト開発で、"プロダクトの価値を最大化する"ためのフレームワークである。スクラムには細かい方法論は定義されておらず、スクラムの考え方に沿って、どうあるべきかをスクラムチームが考えて方針を出すのが重要」
これはとても印象的でした。「スクラムに答えを求める」と、結局知識の不足により「スクラムごっこ」をやってしまう事があると思います。ですので「スクラムのフレームワーク・コンセプト」を理解した上で、チームが価値の最大化に向けて結論を出すというやり方で、スクラムをうまく活用出来るのではないかと考えました。
3. 世界一優秀なスクラムチームがスクラムゴールを達成する確率
スクラムの本質を理解して、スクラム開発に向き合う事に価値があるという意見を述べましたが、ここでもその考え方に納得される出来事がありました。
講義の中で、Coplienさんから質問がありました。
「あなたは、世界一優秀なスクラムチームと働く事が出来ます。そのチームが毎スプリントにおいて、スクラムゴールを達成する可能性はどのくらいだと思いますか？」
この質問に対して僕は、
「世界一優秀なチームなら、具体的なパーセンテージまでは想像できないが、かなり高い確率で達成するのではないか？」
と考えました。
しかし、Coplienさんからは意外な回答が返ってきました。
「達成率は50%です。達成と未達成が半分ずつである」
これこそ、まさにスクラムの本質を理解できていないからこそ誤った回答を考えてしまった良い例だと思います。
スクラムは過去の経験に基づいて未来を予測しながら進めます。昨日の天気を元に今日の天気を予想するのと同じです。
つまり、過去スプリントの実績を元にそのチームの開発スピードを予測して、実力に近い形の「スプリントゴール」を設定します。ですので、チームが優秀であろうとなかろうと、スクラムの原則に従うと、スプリントゴールの達成率は50%となるのです。
しかし僕は優秀なスクラムチームだから、ものすごい達成率でスクラムが回っていくのではないかと、間違った期待を抱いてしまいました。
まとめ
ここでは、スクラムプロダクトオーナー研修を通して、学んだ事の中で特に印象に残った３つのお話をしました。
これらは一例でしかないのですが、講義全体を通して感じたことは、
「スクラム開発に関わる全員が、原理原則をよく理解して、常に自分たちで最善の方法を考える事がとても重要である。」
という事でした。
現に、スクラムのガイドラインとして準備されている、スクラムガイド2020は、19ページしかありません。ソフトウェア開発は様々な状況で行われるため、状況状況で出てくる課題については各スクラムチームしか正解を知り得ないのです。
また、スクラムガイドは2020年11月に改定が行われていますが、その中の改定のポイントの一つとして、具体的に書きすぎた細かな指示をなるべく排除しているそうです。ここからも、スクラムというフレームワークのコンセプトが感じとれるのではないでしょうか？
今回、認定スクラムプロダクトオーナーの資格を取得しましたが、これはあくまでも始まりに過ぎず、実プロジェクトでの経験こそがプロダクトオーナーとしての成長に繋がるものだと知る事ができました。
これらの事に気づかせてくれた講師のJames Coplienさんに深くお礼を申し上げます。またいつかどこかでお会いしたいです。
HarborS表参道でも今後、スクラム開発について理解を深めるためのイベントも開催していきたいと思います。是非、この記事を読んで頂いた方ともお会いできると嬉しいなと思います。
Twitterでもイベント情報等を発信してますので、よろしくお願いします。
HarborSでは毎週土曜日に開催のもくもく会をはじめとして様々なイベントを開催しております。2月の開催も準備中ですのでconnpassからぜひご確認ください！
コワーキングスペース会員としてHarborSにご参加いただける方ももちろん大歓迎です！HPはこちら！
勉強会の会場をお探しの方は、HarborSの会議室をご活用ください。予約はこちら
この記事が気に入ったらサポートをしてみませんか？