SCRUM BOOT CAMP 読書会の感想
katorie さんと chako さんと共に朝5時に起きて読書会をしました。久しぶりの5時起き頑張りました〜。
概要
公式のスクラムガイドを元にスクラムの基本とスクラムあるあるを漫画形式で知れる本。
読む前の気持ち
1,2週間に1回のスプリント、リリース、振り返り。仕事では当たり前になってたけど、アジャイルやスクラムの基本を勉強したことがなくフワッとした状態で実践していたので、うまく回っていないときにやり方を見直す指標がないというか、チームとしてどう仕組みを変えていったら良いのか目星が付かないなぁと漠然と悩んでる状態でした。
だからアジャイルやスクラムの基礎がわかる本を読もうと思ったんだよね！
読み終わったあと、いまの私、いまのチームを振り返る
PdM と PM の違い
今のチームでは PdM（プロダクトマネージャー）という役職の人がいて明らかに PM（プロジェクトマネージャー）との違いを表現してるんだけど、私の中では PdM でも PM でも「仕様どうなってますか？どうしますか？」って聞く相手であったり、ガントチャートを作って全体のスケジュール感を握ってる人的な認識だったので、違いを理解できませんでした。。
「プロダクトマネージャーとプロジェクトマネージャーの違い | AIdrops」では
プロダクトマネージャー
「何を」「なぜ作るのか」を担っているのがプロダクトマネージャーです。なぜ作るのかといえばそれは顧客の課題解決を図るためで、何を作るのかはすなわちビジネスモデルに直結します。プロジェクトマネージャー
「いつまでに」「どうやって作るのか」を担うのがプロジェクトマネージャーです。これはすなわち予算やスケジュールの管理に当たります。
この記事読んで、これまで PM が担ってた「どうやって作るのか」の部分をスクラムでは開発チームが担うことになるのかな。
プロダクトへのフィードバックができていない
今のチームは既に PdM とデザイナーが UI / UX を考えてくれるので、開発チームからプロダクトに対してのフィードバックをあまりしない状況。振り返りも開発者メンバー内で行うので開発者どうしのコミュニケーション問題だったり、コードの品質問題に終始している感じ（もちろんこの内容も大事だけど）。同じスクラムチームなのに開発者は PdM やデザイナーが抱えてる問題を認識できてないし逆も然り。振り返りする単位が改善できる範囲の限界な気がするので、やはり振り返りはスクラムチーム全員でやりたいよね・・。
来年に就職する会社では「どうやって作るのか？」を開発者が考えれるチームに入る予定なので、もっとこういう方が使いやすいとか（A/B テストとかして）そもそもこの機能は画面でやる必要がないかも？とか、UI / UX に対してフィードバックできる開発者になりたいな。そして katorie さんから教えてもらった コラボレーティブデザインも試してみたい。
振り返りが個人の反省になりがち
振り返りの内容が「自分の技術力が足りませんでした」的な個人の反省になりがちな現状。改善するには視点の転換が必要そう。この本では振り返りのことはほとんど触れられてなかったので別の本も読みたい。
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き | Esther Derby, Diana Larsen, 角 征典 |本 | 通販 | Amazon
紛争を避けがち
自分はこれが正しいと思う、こっちの方が良いと思うって意見言うの苦手で、正直そんなの当たり前じゃん！なんで分かってくれないの🤨って思ってストレス抱えちゃってる…。自分の意見に自信がないのもある…。
ただタックマンモデルでも「混乱期は必要なこと」と言われてるように、紛争はお互いの価値観や前提条件を合わせることだから。短期的に見たら相手に合わせておく方が楽なんだけど、長期的に見ると混乱期に手を抜いたり我慢したりしたら自分にとって最高のチーム（納得感を持って開発ができるチーム）は永遠に訪れないよなぁ…と思ったり。
紛争は悪じゃなくてより良いチームを作るために必要なんだ！という認識を持って前向きに取り組みたい。
チームビルディングでファシリテーターである私が初めに話すこと｜タックマンモデル | 今が最高のプレゼント Present is the best gift
やってみたい
インセプションデッキ（SCENE NO.2）
インセプションデッキはスクラムチームの向かう先の認識を合わせたいときに作りたいもの。一方的にプロダクトマネージャーから説明を受けるだけだと疑問や不安を抱えたままになってしまうので、プロダクトマネージャーが叩き台を作ってスクラムチーム全員で議論していくのが良い。
インセプションデッキを作ることでスクラムチームが自分たちに期待されていること、すなわちゴールやミッションを毎日意識して作業することができる。ただし、本質的にはインセプションデッキを作れば OK なのではなく、ゴールやミッションの認識を擦り合わせる場を作るためにインセプションデッキを作っているだけ。インセプションデッキがあればスクラムチーム全体に大事なことを浸透されていると思わないように。
chihiro さん曰く、チームメンバーが自分たちの作るものやそれが生み出す価値について興味があるかも重要と言ってて、そりゃそうだよなって思った。その温度感大事。
ユーザストーリー（SCENE NO.16）
プロダクトバックロでうまく開発者にプロダクトオーナーの意図が伝わらないときに試したいこと。
ユーザストーリーとは？
実現したいものを実際に使う人たちの立場で表現する伝え方。
なぜ必要？
プロダクトオーナーは何を実現したいかについて考えているし、開発チームはどうやって実現するかを考えている。各自が責任を持つ部分に集中できる利点がある一方で、考えている部分が違うので誤解を生みやすいから。
フォーマット
＜どういったユーザや顧客＞として
＜どんな機能や性能＞がほしい
それは＜どんなことが達成したい＞ためだ
大事なこと
フォーマット3行目の「どうして必要なのか？」という理由を伝えることがすごく大事。意図が書かれていることによって、スクラムチームは動きやすくなる。
たとえば、「営業担当として、自分宛てのメッセージを外出先で見られるようにしてほしい」だけでなく「それは移動中でも商談に関係する仕事上の重要な連絡を見逃さないためだ」という意図を開発チームが知っているとする。開発チームはユーザストーリーをを実現するときに、モバイル端末で見ることが多そうだからもっと大きい文字にしようとか、重要なメッセージは赤で目立つようにしようといったことが考えやすくなる。 そして、何かの項目をあきらめるときにも、こうした意図は大事な判断材料になる。
判断材料があると動きやすいの確かに🤔
ユーザストーリーはあえて短い
短く書くことでスクラムチームが話し合う機会を頻繁に持つようにしている。（そうなんだ😲）
何を作るかは開発者が決める
これは chihiro さんに聞いた話。
達成したいことが「アプリの利用状況を確認したい」だと、
誰が？（マーケティング部？開発わりとわかる人？）
どこまで（とりあえずログイン数なのか、〇〇機能を使っている人の数なのか・・）
なんのために？（上司に報告したい？マーケティングの調査に使いたい？）
とかで掘り下げる。そうすると開発チームはこれってそもそも画面必要なくて、定期的にCSVに吐き出したデータ渡せば良いのか？など、どうやってユーザストーリーを達成するか？（何を作るか？）の議論がしやすい。
何を作るか？を開発チームで議論するチームにいた経験がないのでユーザストーリーから考えていくスクラムチーム、プロダクト作ってる感あって楽しそう😎
最新のスクラムガイドをチェック
そもそもこの本を読んでスクラムガイドなるものを知ったのですが、スクラムガイドは定期的に更新されてるそうで。この本でも 2017 年時点のスクラムガイドを元に作られているのですが、2020 年にスクラムガイドが更新されたので気になった部分を取り上げます。
スクラムガイド2020のアップデートについて - Scrum Inc. Japan #TeamworkMakesTheDreamWork
朝会で話すことが変わった
「昨日やったこと」を話すことにあまり意味を感じてなかったので、朝会でどんなことを話すと良いのか？からチームで考えれるの良さそう。
開発チームはなくなり、スクラムチームだけに
いまでも開発チームと PO とデザイナーチームに分かれてしまっている現状なので…そもそも開発チームという線引きをなくしてしまうのは良さそう。
参考）
感想
読書会を通してこれまで向き合ってこなかったチームの在り方を考える良い機会になりました。ひとまず現状でもチームは回っているし、もう少し様子見しよう、と後に後に回してる改善っていっぱいあるなぁと思います。またその皺寄せが気付かないうちにコードやプロダクトに反映されてると思うと悲しいです😢自分のできることからチームに向き合っていきたいです。
