SCRUM BOOT CAMP 書評 / プロダクトオーナー(仮)兼開発者が読んで気づいたこと

|

「SCRUM BOOT CAMP」の本を読みました。

書籍の内容を紹介しつつ、その中で気づいたことや、現場開発で試してみたいことについてメモります。

ざっくりどんな本なの？

  • 漫画ベースでスクラムの実践的なやり方、考え方を教えてくれる。読みやすい。
  • [主人公がスクラムマスター、開発から営業部に異動した同僚女性がプロダクトオーナー]というシチュエーション。

前提: 山根は今どんなスクラムやってるの？

  • 1スプリント2週間
  • チーム5人〜9人
  • 発足から2年以上経過したチーム
  • 1プロダクトの中でモジュールが複数あり、そのうちの1つを担当する
  • スプリント開始時にプランニングをする。（最長4時間）
    • 山根が「このスプリントではざっくりこの辺を達成するべきだと思うよー」を言う
    • チームメンバー全員でタスク細分化、それぞれ見積もる
    • 山根が「OK、それで行きましょう」を言う
  • スプリントの終わりにはチームで振り返りをする

本を読んでの気づき

役割とその期待値はちゃんと定義するのがベター

今いる現場では、「プロダクトオーナーが誰々」「スクラムマスターが誰々」みたいなことを明確に決めていません。
（個人的には、「肩書きが決まってそれを名乗る」ってなんとなくこっ恥ずかしく、、なあなあにしていました）

ただ、書籍の「基礎編」と「実践編 SCENE 01 プロダクトオーナーは誰だ！？」を読んで、役割はちゃんと決めておかないとなーということに気づきました。

ちゃんと役割と期待値を決めておけば、その期待値に沿った形で人が動くようになると思った故です。すぐ100%の動きができるようになるとは思いませんが、ちょっとずつ行動が変わっていく土台ができるんじゃないかな。。

自分の今のロールは「プロダクトオーナー」兼「開発者」である

前述の通り役割を明確に定義していない中で、敢えて定義するとするならば、自分の今の動き方は「プロダクトオーナー」兼「開発者」だな〜ということに気づきました。

書籍の中で「プロダクトオーナー」の定義について以下のように書かれていました。

  • プロダクトのWhatを担当
  • プロダクトの価値を最大化する
  • プロダクトの責任者（結果責任）で、プロダクトに一人必ず必要
  • プロダクトバックログの管理者
  • プロダクトバックログ項目の並び順に最終決定権限を持つ
  • プロダクトバックログ項目が完成しているかを確認
  • 開発に相談できるが干渉はできない
  • ステークホルダーとの協業
SCRUM BOOT CAMP 基礎編より

足りてない部分はありつつも、チームとしてやることの最終決定責任を持っている（=プロダクトのWhatを担当）のは自分だったり、外部チームとの調整（ステークホルダーとの協業）のも自分だったりするので、ここは山根が担当するべき項目なんだろうなと…

ただ…

ユーザ目線、事業目線をもっと取り入れないといけない

今は「開発者チームだけでスクラムをやっている」状態。社の体制変更等のなんや感やでそうなっているだけなのですが、あるべき姿ではない気がしてきました。動くものを共有しながら、今プロダクトがどんな状況で次どうなるべきかを意見し合える土壌が必要な気がしてきました。。

「自分が顧客目線を持ちにいく」動きは当然やるべきなのですが、山根の顧客理解が完璧になる機会をチンタラ待っている時間は開発現場にはないので、今時点で顧客目線を持っている人をスクラムチームに巻き込む動きが必要になるんじゃないかと思いました。

似たような状況になってて課題を感じているチームも結構ありそうですね。

https://offers.jp/qa/question/ULuoUbM4nh

やってみたいこと（中長期）

  • 「プロダクトバックログ」を管理する
  • PdMメンバーもスクラムイベントに巻き込む
    • プランニングに入ってもらう（最後の30分だけでも）
    • スプリントレビュー的な何かをやる

やってみたいこと（短期）

直近の重要イベント（特にリリース予定）をタスク管理ツール上で可視化する

ぶっちゃけ何を目的としてチームが仕事しているかというと、「良い機能をリリースしてお客さんに使ってもらうこと」。

そのための一旦のGoalが「リリース予定」

リリース予定が迫ると普段の機能開発以外の作業も色々発生してくるので、想定外の仕事が発生する確率も高くなります。そういったリスクを予期するためにも、対顧客のリリース予定はみんなで可視化できると良いなと思いました

保守、リリース作業を人に渡せるようにする、可視化する

  • リリースに伴い必要な、過去データに対するパッチSQLを準備する
  • リリース作業をしてもらうチームと認識を合わせる
  • 対PdM説明やドキュメント整備
  • そのほか調整ごと…

などなど、普段の開発以外のタスクについてもスクラムチームがやらないといけないタスクが盛りだくさんなので、それもチームで管理できるようにしていきたい。。