Blog on Ryuzee.com https://www.ryuzee.com/contents/blog Recent content in Blog on Ryuzee.com Hugo -- gohugo.io ja_JP Sat, 01 Jan 2000 09:00:00 +0900 アジャイル開発がうまくいっていない気がするというチームに確認すべきこと https://www.ryuzee.com/contents/blog/14588 Thu, 29 Feb 2024 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14588 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります(内容が具体的になっていればもう解決までそう遠くありません)。</p> <p>抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの?」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません(その場合は適宜用語を読み替えてください)。</p> <h2 id="確認ポイント">確認ポイント</h2> <p>いきなりほぼ結論です。</p> <p>このような相談を受けたときに、いちばん重要な確認ポイントは</p> <p><strong style="color:red">「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか?」</strong></p> <p>です。この確認をしないうちに「スクラムイベントは全部やっているか?」とか「プロダクトバックログがどうなっているか?」とか「インセプションデッキがどうたら」とか「最近○○というプラクティスが流行ってる」とか効率とかは無意味です。</p> <h2 id="なぜこれが重要なのか">なぜこれが重要なのか</h2> <p>アジャイル開発を適用するような性質(つまり不確実性が高い)の仕事では、<strong>リスクの制御は「動作するソフトウェア」でしか行えない</strong>からです。 大きなリスクとして挙げられるものとしては「作ったものが価値を生み出すか」「ビジネスにあった速度で作れるか」があります。</p> <p>まずは、「作ったものが価値を生み出すか」への対処についてです。 作ったものが価値を生み出すかどうかは、チームのなかだけでは決まりません。 <strong>プロダクトの価値は基本的に「チームの外側で決まる」</strong> のです。 そのため、作ったものは早い段階から定期的にチームの外側に披露し、評価を受け、フィードバックを貰わなければいけません。</p> <p>「完成度が低いものを外部に見せたくない」とよく言われます。気持ちはわかります。 でも完成度を上げてもリスクに対する制御にはなっていません。 時間をかけて作り込んで自分たちが満足できるものが作れたとしても、価値を生み出していなければ投資した時間は無駄になります。 また、見せない期間が長ければ長いほど、外部の人の期待値は上がります。その上がりきった期待値に応えるのはかなり大変です。</p> <p>次に「ビジネスにあった速度で作れるか」への対処です。 多くのプロダクト開発には予算や想定のリリース時期があります(もちろんうまくいったプロダクト開発はずっと続きますが、投資対効果は気にしますし、ざっくりとした計画を立てるのが普通です)。 これは最近流行りの「開発生産性」の観点ではありません。重要な関心事は、ビジネスの観点として妥当な速度で作れているのか、会社のさまざまな計画に適合できそうなのかです。つまりそれなりの確度で見通しが立てられるかです。 アジャイルで見通しを立てるときに基準になるのは、「動作するソフトウェア」です(アジャイルソフトウェア開発宣言に書いてあります)。 <strong>動作するソフトウェアがどれくらいの速度で作れるかが明らかになっていれば、計画やチーム構成を見直したり、プロダクトの機能の優先順位やロードマップを変えたりできます</strong>。 タスクをこなしているからといって「動作するソフトウェア」ができるとは限りません。したがってプロダクトバックログアイテムやタスクの達成率や消化個数を見てもあまり意味はありません。</p> <h2 id="なぜできないのか">なぜできないのか?</h2> <p>「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらう」ことができない理由はさまざまです。 経験上よく遭遇するものを4つ紹介します。もちろんこれ以外の理由もあります。</p> <h3 id="1-フィーチャーファクトリー">1. フィーチャーファクトリー</h3> <p>チームの外部で作るものが決められていて、社内受託開発のようになっているケースです(受託開発のコンテキストも同じです)。 この場合、チームには短い期間で区切って、動作するソフトウェアを見せ続けるインセンティブがありません。 つまり「作ったものに意味があるか」は二の次になります。</p> <p>チームにとってのリスクは「決められたことが期限内に終わらない」ことなので、それへの対処を最優先にします。 フィードバックをもらってそれを反映するのはチームにとってはマイナスだということです。</p> <h3 id="2-効率重視">2. 効率重視</h3> <p>先に答えがわかっているような仕事であれば、いかに効率的に終わらせるかが重要になります。 つまり、誰かがタスクをすべて用意し、それを効率的に終わらせるように分業するのが、合理的な選択になります。 これは一過性の仕事や、仕事が終わったらチームが解散するような状況だと特にです。</p> <p>この分業の考え方をプロダクト開発やアジャイル開発に持ち込むと残念な結果になります。 タスクをこなすという観点では、数多くこなせるかもしれませんが、スプリントの最後に動作するソフトウェアが手に入らない可能性が高くなります。 たとえば、結合の作業が最後にまとめて残ったり、結合はできたもののテストが終わっていないものが最後に残ったりします。</p> <p>実物で評価するのが何よりも重要であり、効率を追求するのはそのあとでなければいけませんが、そうなっていないのです。</p> <h3 id="3-不適切な作業分割">3. 不適切な作業分割</h3> <p>アジャイルでは、何か実現したいことがある場合、それをプロダクトバックログアイテムなどで表現します。 そしてアイテムが1回のスプリントやイテレーションで開発するには大きすぎるときには、分割します。 分割するときは、分割したものそれぞれが単体で意味があり、独立して評価可能にするのが基本ですが、慣れていないと「設計」「開発」「テスト」のように工程で分割してしまいます。 このように分けてしまうと、動作するソフトウェアとして評価できるようになるまでに3回のスプリントが必要になってしまいます。</p> <p>これはチーム全体が学習不足のときによく起こります。つまり、動作するソフトウェアの意味を理解していないということです。</p> <h3 id="4-技術力不足">4. 技術力不足</h3> <p>単にチームに技術力が不足していて、スプリントのなかで動作するソフトウェアを作れないこともあります。 チームの力量が低いと見積りの精度も低いため、完成しないことが常態化しやすいです。 早めにチームにテコ入れしたり、継続的に学習に投資したりすることで改善できる余地はあります。</p> <h2 id="対処">対処</h2> <p>内容が具体的であれば対処しやすい、と冒頭に書きました。 質問を通じて会話し、事実を明らかにできれば、対処の方法はいくらでも浮かんでくると思います。 100発100中の対処方法はないので、対処の案は実験ととらえて試していくといいでしょう。</p> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> 【資料公開】ベロシティ Deep Dive https://www.ryuzee.com/contents/blog/14587 Wed, 10 Jan 2024 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14587 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>2024年1月10日〜12日開催の<a href="https://2024.scrumgatheringtokyo.org/" target="_blank">Regional Scrum Gathering Tokyo 2024</a>の登壇資料を公開します。</p> <p>「ベロシティ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。</p> <ul> <li><a href="https://slide.meguro.ryuzee.com/slides/107" target="_blank">プロダクトバックログ Deep Dive</a></li> <li><a href="https://slide.meguro.ryuzee.com/slides/111" target="_blank">スプリントプランニング Deep Dive</a></li> <li><a href="https://slide.meguro.ryuzee.com/slides/114" target="_blank">スプリントレビュー Deep Dive</a></li> </ul> <p>セッション資料は以下になります。</p> <div id='slidehub-jsfd67bfbbe619309718f6952795641e3g'> <script src="https://slide.meguro.ryuzee.com/player/v2/119?prefix=jsfd67bfbbe619309718f6952795641e3g" async="async"></script> </div> <br /> <p>結論から言うと、<strong>「ベロシティなんかにDeep Diveせず、もっと重要なところに集中しろ」</strong>です。</p> <p>スクラムチームの状況を何らかの数値で表したいという考え自体は尊重しますし、それが役に立つこともあります。 ただし、数字遊びをしたところでプロダクトの価値を生み出せるわけではないので、ほどほどにしましょう。</p> <p>スクラムチームのパフォーマンスの計測については「<a href="/contents/blog/14585">スクラムチームのパフォーマンスを測定したいと思ったら</a>」もご参照ください。</p> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> 【資料公開】プロダクトマネージャーのしごと https://www.ryuzee.com/contents/blog/14586 Wed, 18 Oct 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14586 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>2023年10月17日に行われたオンラインイベント「<a href="https://forkwell.connpass.com/event/297231/" target="_blank">プロダクトマネージャーのしごと - Forkwell Library #33</a>」の登壇資料を公開します。</p> <p>内容は、新刊書籍『<a href="https://amzn.to/3QmgrHh" target="_blank">プロダクトマネージャーのしごと</a>』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。</p> <div id='slidehub-jsfd67bfbbe619309718f6952795641e3f'> <script src="https://slide.meguro.ryuzee.com/player/v2/118?prefix=jsfd67bfbbe619309718f6952795641e3f" async="async"></script> </div> <br /> <p>ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。</p> <p>職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか?」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびいただきます(なお、「プロダクトマネジメント」のところは「アジャイル」でも何でも好きな単語に変えても大丈夫です)。 でも、「ベストプラクティス」なるものを買ってきて、何も考えずにそのまま導入したところで、うまくいくかどうかは分かりません。</p> <p>成功させたければ、現実を直視し、ユーザーや顧客に価値を届けるための仕事にフォーカスし、関係者と協力しながら、検査と適応をしていくしかありません。 同じ話が職種にも当てはまります。 「プロダクトマネージャーとプロダクトオーナーの違いは何ですか」とか「プロダクトマネージャーとプロダクトオーナーはどう役割分担をするのがベストですか」のような話をするよりも、協力して進めることに集中すべきです(答えは組織によって大きく変わります)。</p> <p>これを本書では、「<strong>理想的なプロダクトマネジメントと実際のプロダクトマネジメントは大きく違います</strong>」とか「会社でプロダクトマネジメントを正しくやらせようとするのは放っておいて、<strong>仕事にベストを尽くすことに集中すべき</strong>だった」と表現しています。</p> <p>このような考え方に基づいて、それでもプロダクトマネジメントの仕事を前に進めるために役立つ考え方を紹介しているのが本書です。 プラクティスカタログ集ではなく、日々何をどう考えればいいかの指針を欲している方には役に立つ書籍なのではないかと思います。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4814400438?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41P6RbH+s6L._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4814400438?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Matt LeMay、 永瀬 美穂、 吉羽 龍太郎、 原田 騎郎、 高橋 一貴</li> <li><strong>出版社:</strong>オライリー・ジャパン</li> <li><strong>発売日:</strong>2023-09-05</li> <li><strong>単行本(ソフトカバー):</strong>312ページ</li> <li><strong>ISBN-13:</strong>9784814400430</li> <li><strong>ASIN:</strong>4814400438</li> </ul> </div> </div> </div> </div> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>スライドを見て興味を持たれた方は、ぜひ書籍『<a href="https://amzn.to/3QmgrHh" target="_blank">プロダクトマネージャーのしごと</a>』を読んでください。</p> <p>また、プロダクトマネジメントについては他にも翻訳書を出していますので、あわせてお勧めします。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> <p>それでは。</p> スクラムチームのパフォーマンスを測定したいと思ったら https://www.ryuzee.com/contents/blog/14585 Thu, 12 Oct 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14585 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>スクラムチームのパフォーマンスを測定したいとステークホルダーに言われて悩んでいるスクラムマスターは多いと思います。 今回は、スクラムチームのパフォーマンスはどうやって測ればいいのか、何を気をつけるといいのか考えてみましょう。 具体的なメトリクスについては、別の記事で触れる予定です。</p> <h2 id="測定には目的が必要">測定には目的が必要</h2> <p>ソフトウェア開発に限らず、何かを測定しようとするときには目的が必要です。 目的がないと、リソースがムダになったり、意思決定が難しくなったり、データをめぐって混乱が発生したりするリスクが高まります。 やりたいこと、やらなければいけないことは、だいたいやれる量よりも多いですが、そんな状況で限られた時間や資源を有効に活用するためには、測定が意図する目標とその結果の具体的な活用方法を明確に設定しなければいけません。</p> <p>「いや、でもいずれ使うかもしれないので、何でもデータを集めておいた方がいいのでは?」と言われることもありますが、それにはコスト(入力のコスト、ストレージの容量、それを見る時間などなど)がかかります。 大したことがないコストでも長期間に渡ると大きなコストになってしまうことを認識しておかなければいけません。</p> <p>言い換えると、目的を設定すると以下のような利点があります。</p> <ul> <li>目的に応じて必要なデータのみを集め、ムダを防ぐ</li> <li>測定結果をもとに、具体的な改善策やアクションを計画しやすくなる</li> <li>測定の目的と結果が明確であれば、チームメンバーやステークホルダーとのコミュニケーションがスムーズになる</li> </ul> <p>ということで、<strong>スクラムチームのパフォーマンスを測定したいのであれば、なぜそうしたいのか、集めたデータをどう使うのかという点を明確にしてください</strong>。 「ステークホルダーに言われたので」ということであれば、ステークホルダーと会話する時間を取る必要があります(そして、想像以上にステークホルダーが何も考えずに依頼していることがわかることもあります)。</p> <h2 id="単一の指標だけでは意味がない">単一の指標だけでは意味がない</h2> <p>ソフトウェア開発において、チームのパフォーマンスを評価する際に単一の指標だけを使用することは困難です。 これはアジャイルだろうがウォーターフォールだろうが同じです。 ソフトウェア開発は、さまざまなスキルやタスク、そして動的な要因が組み合わさった複雑なプロセスです。この再現性のない、一度限りの特性から、単一の指標だけでは、チームの多面的な能力や、その環境下での実際のパフォーマンスを正確に捉えることはできません。それぞれのプロダクト/プロジェクトとチームが独自の課題と目標を抱えているため、評価は複数の指標を用いて多角的に行うべきと言えます。</p> <p>また単一の指標の利用は別の問題もあります。単一の指標を使うと、他の重要なことを犠牲にしがちだということです。これは指標が評価や報酬、管理に使われる場合に顕著です。たとえば、ある特定の指標を最適化するプレッシャーがかかると、品質、長期的な成果、持続可能性などを損なう可能性があります。</p> <p>また「管理のために用いられる測定はすべて、信頼できない」というグッドハートの法則がここでもあてはまります。 つまり、測定され、報酬が与えられるものはすべて改ざんされます。改ざんは言い過ぎにしても、他を犠牲にしてでも数値を最適化するようにハックします。したがって数値には信頼性がなくなります(詳しく知りたい方は、書籍『<a href="https://amzn.to/3Qh7Plu" target="_blank">測りすぎ――なぜパフォーマンス評価は失敗するのか?</a>』を読むことをお勧めします)。</p> <p>これらを防ぐためにも、さまざまな角度から複数の指標を選ぶ必要があるわけです(一般的に、複数の指標のあいだには相関関係が存在し、一つの指標が不自然に改ざんやハックされた場合、他の指標にもその影響が現れます。そのため、1つの指標だけを操作しても、それが他の指標との一貫性を損ない、不自然な動きとして容易に検出可能です)。</p> <h2 id="測定すべき指標は変化する">測定すべき指標は変化する</h2> <p>ソフトウェア開発は動的であり、そのフェーズや目標、技術的な課題は常に変化します。したがって、測定する指標もプロダクト/プロジェクトの状況や目標に応じて柔軟に変更しなければいけません。</p> <p>初期フェーズで重要だった指標が、進行に伴ってその重要性を失ってしまいムダになることは多々あります。 例えば、開発中はコードの品質やテストカバレッジが重要かもしれませんが、開発とリリースを繰り返すフェーズ(そしてチームが十分に開発できるようになったあと)だとリードタイムやサイクルタイムの方が重要になるかもしれません。</p> <p>冒頭で説明したように「目的」に立ち返って、どの指標を見ると良いかを考えなければいけません。 往々にして、指標の収集がルールのようなものになってしまい、目的や背景を知らないまま測定を続けることになりがちです。そうならないようにある程度の期間ごとに目的や指標を見直すことをお勧めします。</p> <h2 id="定量的な指標だけを重視しない">定量的な指標だけを重視しない</h2> <p>人事評価にせよ何にせよ、(偉い人たちは)定量的にしろと言ってきます。もちろん定量的な指標は重要なのですが、それだけにしてしまうと大事なことを見落としがちです。そのため、定性的なデータもあわせて活用しましょう。 定量的なデータが「何が起こっているか」を示すのに対し、定性的なデータは「なぜそれが起こっているか」を理解する手助けになります。</p> <p>例えば、定量的なデータがバグの数やコードの開発生産性を示していても、それだけではそれが発生する背後の理由やコンテキストを完全には捉えられません(そもそも、それらの指標に問題があったとしても、原因がチームに由来しているかどうかすらわかりません)。定性的なデータ、特にチームメンバーの意見やフィードバックは、何らかの問題がある場合に、その原因や解決策を探る上で非常に役立ちます。</p> <p>定性的なデータは、チームのモチベーションやコミュニケーション、協力関係、組織文化など、数値で直接測定するのが困難な要素を評価するのに役立ちます。これらの要素は、チームの開発生産性や品質に大きな影響を与えるため、無視するわけにはいきません。 また、ユーザーや顧客のフィードバックや感想も定性的なデータです。プロダクトの満足度や使い勝手を深く理解するのにとても役立ちます。こういった情報があれば、チームはユーザーや顧客の期待に応えるための改善策を立てられます。</p> <h2 id="ここまでのまとめ">ここまでのまとめ</h2> <p>ここまでの話をまとめると以下になります。</p> <ul> <li>まずスクラムチームのパフォーマンスをなぜ測定したいのか、測定したものをどう使うのかを明らかにするとこと</li> <li>単一の指標だけで評価することはできないので、複数の指標を組み合わせる</li> <li>定量的な指標だけでなく、定性的なデータも重要</li> </ul> <p>これらを踏まえて、次回はどんな指標を収集すると良いか、具体的に考えてみる予定です。</p> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> プロダクトバックログリファインメントはいつ何をするのか https://www.ryuzee.com/contents/blog/14584 Fri, 11 Aug 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14584 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>プロダクトバックログリファインメントのやり方について立て続けに聞かれることがあったのでまとめておきます。長文ですが参考になれば幸いです。</p> <hr> <p>まずはスクラムガイド2020を確認しておきましょう。該当する箇所は3箇所です。</p> <p>スプリントでの説明(9ページ)</p> <blockquote> <p>スプリントでは、(中略)</p> <ul> <li>プロダクトバックログを必要に応じてリファインメントする。</li> </ul> </blockquote> <p>スプリントプランニングのトピック2での説明(10ページ)</p> <blockquote> <p>開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。 スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。 それによって、チームの理解と自信が高まる。</p> </blockquote> <p>プロダクトバックログでの説明(13ページ)</p> <blockquote> <p>1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。 スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。 プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。 これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。 多くの場合、属性は作業領域によって異なる。</p> </blockquote> <p>またスクラムガイド2017のなかでも記述があります。関係の深い箇所のみ紹介します。</p> <blockquote> <p>プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。 これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。 プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。 いつどのようにリファインメントをするかは、スクラムチームが決定する。 リファインメントは、開発チームの作業の10%以下にすることが多い。 ただし、プロダクトバックログアイテムはプロダクトオーナーの判断によって、いつでも更新できる。</p> </blockquote> <p>これを踏まえて、整理していきましょう。</p> <h2 id="プロダクトバックログリファインメントでは何をするのか">プロダクトバックログリファインメントでは何をするのか?</h2> <p>スクラムガイドの記述をまとめると、プロダクトバックログリファインメントでは以下のようなことを行うとあります。</p> <ul> <li>プロダクトバックログアイテムを新たに作る</li> <li>プロダクトバックログアイテムを分割する</li> <li>プロダクトバックログアイテムを詳細にする <ul> <li>プロダクトバックログアイテムの説明を追加・更新する</li> <li>プロダクトバックログアイテムの並び順を更新する</li> <li>プロダクトバックログアイテムのサイズを追加・更新する(見積もる)</li> </ul> </li> </ul> <p>ただし<strong>例によって例のごとくスクラムガイドには最低限のことしか書いていないので、この記述の背後にある考え方をもとにして、具体的にどんなことをするのかを考える必要があります</strong>。</p> <h3 id="プロダクトゴールを確認する">プロダクトゴールを確認する</h3> <p>プロダクトバックログアイテムはプロダクトゴールを達成するためのものなので、議論や作業の前提としてプロダクトゴールに着目する必要があります。スクラムチーム全体がプロダクトゴールに集中していないと、進む方向が定まらず意味のないプロダクトバックログアイテムに取り組んでしまうことにもなりかねません。そうならないよう、プロダクトオーナーは、プロダクトバックログリファインメントに限らず、<strong>さまざまなタイミングで繰り返しプロダクトゴールをスクラムチーム全体に定着させなければいけません</strong>。</p> <p>プロダクトゴールの観点では、以下のようなことをします。</p> <ul> <li>現在取り組んでいるプロダクトゴールを確認し、現在どのような状況なのか、プロダクトゴールがいつ頃達成できそうなのかを確認する</li> <li>必要であれば、プロダクトゴール自体をより洗練したり具体化したりする</li> <li>現在のプロダクトゴールが達成間近であれば、次のプロダクトゴールを検討する、もしくは検討するための準備をする</li> </ul> <h3 id="今後のスプリントゴールのアイデアを考える">今後のスプリントゴールのアイデアを考える</h3> <p>スクラムではプロダクトゴールを達成するために、スプリントごとにスプリントゴールを達成していきます。 したがって、スプリントプランニングでプロダクトオーナーがいきなりスプリントゴールのアイデアを持ち込んで、スクラムチームが初見でそれを議論するというような形は考えものです。 プロダクトオーナーとしては、数スプリント先くらいまではスプリントゴールのアイデアを持っておき、それはスクラムチームと共有して理解してもらい、フィードバックを受けるようにしましょう。 スプリントゴールのアイデアがあれば、プロダクトバックログアイテムの並び替えが容易になります。</p> <h3 id="プロダクトバックログ全体を手入れする">プロダクトバックログ全体を手入れする</h3> <p>スプリントゴールのアイデアが考えられていれば、プロダクトバックログアイテムはある程度それに沿って並び替えられるはずです。 プロダクトバックログ全体を見ながら、並び順が最新の情報に基づくものになっているかを確認し、そうなっていなければ並び替えましょう。 並び順が最新になっていない段階で、上位のプロダクトバックログアイテムの詳細を議論しても仕方ありません。</p> <p>また、プロダクトバックログアイテムはさまざまなきっかけて増えていきます。 たとえば、以下のようなきっかけです。</p> <ul> <li>スプリントレビュー</li> <li>サポートや営業へのリクエスト</li> <li>ペルソナの見直し</li> <li>ユーザーインタビューや観察</li> <li>メトリクスやログの分析</li> <li>開発者のペイン</li> <li>技術要素の変化(バージョンアップ、サポート切れ、セキュリティ対応……)</li> </ul> <p>これを放置しておくと、あっという間にプロダクトバックログが肥大化して、何をするにも時間のかかる手の負えない代物になってしまいます。</p> <p>こうならないように、プロダクトバックログ全体に目を通し、似たようなプロダクトバックログアイテムを統合したり、不要なプロダクトバックログアイテムを捨てたり、一旦アイスボックス(捨てる前に一時保管する場所)に移したりしなければいけません。</p> <p>そうやって、<strong>プロダクトバックログをいつも整理された状態に保つようにします</strong>。</p> <h3 id="上位のプロダクトバックログアイテムをreadyにする">上位のプロダクトバックログアイテムをReadyにする</h3> <p>スプリントプランニングで扱うためには、プロダクトバックログアイテムは1スプリント以内で完成できるサイズになっていなければいけません(間違っても1つのプロダクトバックログアイテムを複数スプリントに渡って開発しようとしないでください)。 そのため、大きな関心ごとは、プロダクトバックログの上位にあって、直近数スプリント以内に着手しそうなプロダクトバックログアイテムが、スプリントに持ち込めるくらいの状態(これをReadyと呼びます)になっているかどうかになります。</p> <p>スクラムチームによっては、プロダクトバックログアイテムがどのような状態になればReadyなのかを明文化することもあります。 たとえば、以下のようなものです。</p> <ul> <li>プロダクトバックログアイテムが用意されている</li> <li>プロダクトバックログアイテムの価値が明確である</li> <li>開発を進める上での大きな疑問や決定すべき事項がない</li> <li>開発者全員が何をつくればいいか理解できている</li> <li>受け入れ基準が明確である</li> <li>他のプロダクトバックログアイテムとの依存関係が明確である</li> <li>プロダクトバックログアイテムが見積もられている</li> <li>パフォーマンスなどの非機能要件が明確になっている</li> <li>デモの手順が明らかになっている</li> <li>……</li> </ul> <p>なお、今スプリント内のプロダクトバックログリファインメントで、次のスプリントで着手しそうなプロダクトバックログアイテムのリファインメントを慌ててやらないようにしてください(生煮えのまま時間切れとなり、見切り発車に繋がりやすいためです。自転車操業とも言います)。<strong>2〜3スプリント前くらいから準備しておく</strong>ことをお勧めします。</p> <h2 id="プロダクトバックログリファインメントの実施タイミング">プロダクトバックログリファインメントの実施タイミング</h2> <p>スクラムガイドの記述で明示されているのは、</p> <ul> <li>スプリントのなかで実施する</li> <li>スプリントプランニング中に実施することもある</li> <li>継続的な活動である</li> </ul> <p>です。スクラムでは5つのイベント(スプリント、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ)を定めていますが、プロダクトバックログリファインメントはスクラムイベントではありません。</p> <p><strong>スクラムイベントではないので実施のタイミングは特に決まっていませんし、回数も決まっていません</strong>。 自分たちに合うように実施のタイミング、実施の回数、やり方を考えてください。</p> <p>実施タイミングの例をいくつか挙げておきます。組み合わせ可能なものもあります。</p> <ul> <li>毎日デイリースクラムが終わったあとに最大30分で行う</li> <li>毎週金曜日の15:00-18:00に行う</li> <li>スプリントの中間日に2時間行い、スプリントレトロスペクティブが終わったあとに1時間行う</li> <li>スクラムチームが集まっているタイミングで随時必要に応じて行う</li> <li>1つのプロダクトゴールを達成したタイミングで、まとめて時間を取って行う</li> </ul> <p>どれくらいの時間をプロダクトバックログリファインメントに使うかは、スクラムガイド2020では記述はありませんが、スクラムガイド2017では「開発チームの作業の10%以下にすることが多い」とされています。 開発の時間を取るためにプロダクトバックログリファインメントの時間をなるべく減らしたい衝動に駆られるかもしれませんが、準備が不十分なプロダクトバックログアイテムをスプリントに投入すれば結局ムダが発生します。 スクラムチームとして、どのくらいの時間をプロダクトバックログリファインメントに使うと良さそうかは検査と適応の対象なので、色々と実験をしてみて自分たちに適切な時間配分を探すとよいでしょう。</p> <h2 id="プロダクトバックログリファインメントは誰がやるのか">プロダクトバックログリファインメントは誰がやるのか</h2> <p>スクラムガイド2020では「スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する」とあります。 スクラムガイド2017では「プロダクトオーナーと開発チームが協力して行う継続的なプロセスである」とあります。</p> <p>スクラムマスターの責任を念頭におくと、<strong>プロダクトバックログリファインメントは、プロダクトオーナーと開発者が協力して行う取り組みであり、必要に応じてスクラムマスターが支援する</strong>ことになります。 それぞれの責任がどんなことをするのかの例を以下で簡単に紹介します。なお、プロダクトオーナーはプロダクトバックログの管理に責任を持ちますが作業自体は委任できます。したがってチームによって作業内容は変わる可能性があります。</p> <ul> <li>プロダクトオーナー <ul> <li>プロダクトゴールを洗練する</li> <li>今後のスプリントゴールのアイデアを共有する</li> <li>新しいプロダクトバックログアイテムを作る</li> <li>不要なプロダクトバックログアイテムを削除する</li> <li>プロダクトバックログアイテムの並び順を決定する</li> <li>プロダクトバックログアイテムの内容や要求を明確にする</li> <li>ビジネスの価値やステークホルダーのニーズに関する情報を提供する</li> </ul> </li> <li>開発者 <ul> <li>新しいプロダクトバックログアイテムを作る</li> <li>プロダクトバックログアイテムの内容や要求を明確にする</li> <li>プロダクトバックログアイテムの詳細化や分割の提案をする</li> <li>プロダクトバックログアイテムを見積もる</li> <li>プロダクトバックログアイテムに対して技術的な観点からフィードバックを提供する</li> <li>プロダクトバックログアイテムの実装に関する疑問点や懸念を挙げる</li> <li>プロダクトバックログアイテムの並び順を提案する</li> <li>不要なプロダクトバックログアイテムを挙げる</li> </ul> </li> <li>スクラムマスター <ul> <li>プロダクトバックログリファインメントを効果的に進行する手助けをする</li> <li>必要に応じて、プロダクトオーナーと開発者とのコミュニケーションを促進する</li> <li>スクラムのプラクティスや価値観に沿うようにする</li> </ul> </li> </ul> <p>これは、<strong>プロダクトバックログリファインメントを常にプロダクトオーナーと開発者全員が揃って同期的にやらなければいけないというわけではありません</strong>。 スクラムチームとして協力して行う、つまりスクラムチーム全員がプロダクトバックログに注意を払い、最新に保つように必要な作業を行うことを意味します。</p> <p><strong>プロダクトオーナーはプロダクトバックログアイテム供給マシーンではありません</strong>。 プロダクトバックログリファインメントをすべてプロダクトオーナーにやってもらうことはできません(そもそも見積りは開発者しかできません)。</p> <p>またプロダクトオーナーと、開発者のうち一部の人たちだけでプロダクトバックログリファインメントをやるのも機能しない可能性があります。 時間効率を考えるとこのようなやり方をしたくなるかもしれませんが、残りの人たちに中身を伝える時間が結局必要になりますし、スプリントで着手してみたら一部の人にとってはReadyでないことがわかる可能性もあります。 <strong>スクラムチームとして、プロダクトバックログ全体に対する共通理解が重要です</strong>。</p> <h2 id="最後に">最後に</h2> <p>スクラムの3本柱は透明性、検査、適応です。自分たちのプロダクトバックログリファインメントのやり方を検査して、より良いやり方がないかを探してください。</p> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> 【資料公開】プロダクトオーナーアンチパターン https://www.ryuzee.com/contents/blog/14583 Wed, 21 Jun 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14583 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。</p> <div id='slidehub-js7493f8751920d5bf81136be0ffe7f10d'> <script src="https://slide.meguro.ryuzee.com/player/v2/117?prefix=js7493f8751920d5bf81136be0ffe7f10d" async="async"></script> </div> <br /> <p>今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。</p> <ul> <li><strong>顧客やユーザーの軽視</strong> <ul> <li>兆候 <ul> <li>社内のミーティングでスケジュールが埋まっている</li> <li>機能の必要性の根拠はユーザーからのフィードバックではなく仮説(というか妄想)にもとづいているものが多い</li> <li>ユーザーがプロダクトを触っているところを見たことがほとんどない</li> </ul> </li> </ul> </li> <li><strong>不十分なステークホルダーマネジメント</strong> <ul> <li>兆候 <ul> <li>ステークホルダーをスプリントレビューに招待していない</li> <li>ステークホルダーと個別にコミュニケーションしていない</li> <li>ステークホルダーに何か言われるとすぐに対応している</li> <li>「◯◯さんの指示なのでやらないといけない」のような口癖</li> </ul> </li> </ul> </li> <li><strong>不在がちなプロダクトオーナー</strong> <ul> <li>兆候 <ul> <li>イベントの時間帯が頻繁に変更される</li> <li>イベントの欠席が多い</li> <li>メールやチャットへの返信が遅い</li> </ul> </li> </ul> </li> <li><strong>プロダクトバックログのリファイン不足</strong> <ul> <li>兆候 <ul> <li>スプリントプランニングでスプリントゴールのアイデアが曖昧</li> <li>スプリントプランニングに時間がかかる</li> <li>スプリント中に開発者からプロダクトオーナーに多数の質問が出る</li> <li>完成を確認したときに認識の相違がよくある</li> </ul> </li> </ul> </li> <li><strong>プロダクトオーナーが開発者に発注する</strong> <ul> <li>兆候 <ul> <li>プロダクトオーナーが多くのプロダクトバックログアイテムの詳細を用意している</li> <li>実現したい価値よりも、機能の詳細や仕様の議論に時間を割いている</li> <li>スプリントプランニングやスプリントレビューがプロダクトオーナーの発言ばかり</li> </ul> </li> </ul> </li> <li><strong>プロダクトよりプロジェクト</strong> <ul> <li>兆候 <ul> <li>「このままだと間に合わない」といった言葉がよく登場する</li> <li>当初のスコープや機能の必達を目指している</li> <li>スクラムチームの学習や技術的負債への対応時間を取らない</li> <li>ゴールや価値に関する会話が少ない</li> <li>ベロシティの目標を設定している</li> </ul> </li> </ul> </li> </ul> <p>誤解のないように言っておくと、アンチパターンがこれしかないというわけではないですし、ここに挙げたものだけを避ければいいというものでもありません。 この6つは、経験上よく見かけるパターンとしての紹介です。 そもそもアンチパターンは網羅できるような性質のものではないので、根底にある価値観や原則を理解し、それをもとに自分たちの行動を検査して適応していくことが成功のために必要です。</p> <p>資料が何かのヒントになれば幸いです。</p> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> 意識の問題にしない https://www.ryuzee.com/contents/blog/14582 Sun, 14 May 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14582 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>今日はTwitter経由で頂いた<a href="https://peing.net/ja/q/42aee96b-e741-4879-8349-74d076259c59" target="_blank">質問</a>に回答したいと思います。 質問は以下になります。</p> <blockquote> <p>スプリントで『自分が最初に取り組むプロダクトバックログアイテム(PBI)を終わらせば自分の仕事は終わり』という意識のメンバーが多いです。そのため、PBI每に担当を決めて複数のPBIを並列で進めているのですが、インクリメントが0になる可能性があるのでできればやめたいと思っています。スプリントプランニングで決まったPBIすべてをチームで協力して終わらせるという意識に変えるためにはどうしたらよいでしょうか?</p> <p>例えば、AさんとBさんとCさんが最初にPBI-1をやる場合、スプリントでPBI-1を終わらせればよい、PBI-2とPBI-3は自分たちのタスクではないという意識になってしまっているという感じです。</p> </blockquote> <p>ということで考えていきましょう。</p> <h2 id="スプリントでの開発者の仕事は何か">スプリントでの開発者の仕事は何か?</h2> <p>スクラムガイド(2020)を見ると、以下のように書いてあります。</p> <blockquote> <p>スプリントゴールはスプリントの唯一の目的である。スプリントゴールは開発者が確約する(略) 開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。</p> </blockquote> <p>スクラムガイドにあるように、<strong>スプリントで目指すのは、スプリントゴールの達成です</strong>。 開発者はスプリントゴールを達成するために必要な作業を行います。</p> <p>つまり、スプリントでは選択したプロダクトバックログアイテムは必ずしもすべて完成しなくてもよいこともありますし、スプリントバックログに含めた個々のタスクもすべて実施しなくてもいいかもしれません(もちろん完成の定義は守らなければいけません)。</p> <p>明確なスプリントゴールを設定した上で、そのゴールを達成するための方法に柔軟性を持たせることで、達成の可能性が上がるわけです(つまり「選択したプロダクトバックログアイテムをすべて完成させる」というスプリントゴールは無意味です)。</p> <p>質問の状況において、1つだけ完成したプロダクトバックログアイテムによってスプリントゴールが達成できているならよいですが、そもそも「スプリントゴールを設定していない」可能性が高そうです。</p> <p>スプリントゴールの解説については、<a href="https://miholovesq.hatenablog.com/entry/2022/07/29/120418" target="_blank">こちらも参照</a>してください。</p> <h2 id="開発者はプロダクトバックログアイテム消化マシーンではない">開発者はプロダクトバックログアイテム消化マシーンではない</h2> <p>スプリントゴールもなく、たくさんのプロダクトバックログアイテムを作ることを開発者に求めるのは意味がありません。</p> <p>これはフィーチャーファクトリーと呼ばれるもので、なかには外部委託や海外オフショアの開発者を集めてこれを実現しようとするような分かっていない例もよく見かけます。</p> <p>プロダクトバックログアイテムを完成させても、次のプロダクトバックログアイテムがどんどん来るだけなので、何のために作っているのかが分からなければモチベーションが上がることはありません。</p> <p>スプリントレトロスペクティブで改善をしてもその分追加の仕事が来る、スプリントで早めにすべてが終わったらおかわりを要求される、という状況ではまずいわけです(夏休みの宿題を早めに終わらせたら追加の宿題が出るとしたら、みんなギリギリまでやらないか、適当にペースをコントロールしますよね)。</p> <h2 id="意識の問題にしない">意識の問題にしない</h2> <p><strong>「意識の問題でうまく進まない」と言いたくなる気持ちは分かるのですが、これは本当の問題を表していないことがほとんどです</strong>。 スクラムマスターとしては、どんな事実に起因しているのかを深堀りする必要があります。 それを抜きにアクションしても、本当の問題は解決せず、かえって問題を大きくしてしまう可能性もあります。</p> <p>今回の質問を例にすると「プロダクトバックログアイテムを1つ終わらせれば自分の仕事は終わりという意識」なので「プロダクトバックログアイテムを個人に割り当てればそれでもたくさん完成するはず」というロジックのようですが、深堀りすべきなのは「なぜ前者のように考えるのか」なのです。</p> <p>単純にスクラムに対する理解不足(スプリントで達成すべきことを分かっていない)であれば、スクラムチームでスクラムガイドの読み合わせをしたり、研修に参加したりすればよいでしょう。 経験上、基礎的な教育受けたり学習したりせずに、なんとなくスクラムを始めるチームがかなり多いです。しかし、この始め方をしてしまうとイベントや作成物、責任の有機的な関係性をまったく理解していないため、過去の経験や考え方をそのまま持ち込んでしまい、よくわからないことになってしまいます。知識や考え方のベースラインを揃えるのに時間を使っておけば将来の問題やムダを省けるので、ぜひ学習に時間を使いましょう。</p> <p>開発者が消化マシーンのように扱われているのが理由なのであれば、プロダクトオーナーやステークホルダーへの働きかけも必要です。つまり、実は<strong>開発者が問題でない可能性もある</strong>ということです。</p> <p>なお、理想的にはスプリントレトロスペクティブでこういう話ができるとよいですが、問題を表明しにくい環境の場合は、1on1などで開発者個別に話を聞いたほうがよいこともありますので、適宜使い分けてください。</p> <p>ほかに質問がありましたら、ぜひ<a href="https://querie.me/user/ryuzee">こちら</a>よりお気軽にどうぞ。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> 【資料公開】目標設定の基本 https://www.ryuzee.com/contents/blog/14581 Wed, 10 May 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14581 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>2023年5月9日に開催されたNTT Com Open TechLunch #7「<a href="https://nttcom.connpass.com/event/282173/" target="_blank">エンジニアリングマネージャーと目標設定</a>」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。</p> <p>多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなことになったりしがちです。 これは会社にとっても、個人にとっても不幸です。</p> <p>ということで、本セッションでは、目標設定の基本中の基本について簡単にまとめました。 20分という短いセッションだったので網羅性はまったくありませんが、何かのヒントになれば幸いです。</p> <p>忙しい方向けのまとめ</p> <ul> <li>定量的だけにフォーカスするな</li> <li>企業や組織の目的は、顧客との価値交換システムの構築・維持</li> <li>目標が目的とどう関係あるかを説明できなければいけない</li> <li>SMARTのなかで大事なのは、Related(関連性)</li> <li>関連性がないと、ビルドトラップ</li> <li>目標設定を管理に使うとチートを誘発</li> <li>多すぎる目標は意味がない</li> <li>目標は検査と適応せよ</li> <li>目標設定だけで人事評価などできない</li> </ul> <div id='slidehub-js1c4365833b892c3881132eb04ffd0c26'> <script src="https://slide.meguro.ryuzee.com/player/v2/116?prefix=js1c4365833b892c3881132eb04ffd0c26" async="async"></script> </div> <br /> <p>本セッションで参考にしている書籍や言及している書籍</p> <ul> <li><a href="https://amzn.to/3psvKU1" target="_blank">『マネジメント[エッセンシャル版] - 基本と原則』</a></li> <li><a href="https://amzn.to/3Ze5LMU" target="_blank">『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』</a></li> <li><a href="https://amzn.to/3KR0ztW" target="_blank">『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』</a></li> </ul> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> プロダクトバックログアイテムの粒度の考え方 https://www.ryuzee.com/contents/blog/14580 Sat, 29 Apr 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14580 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>今日はTwitter経由で頂いた質問に回答したいと思います。 質問は以下になります。</p> <blockquote> <p>プロダクトバックログアイテムの粒度について教えてください。</p> <p>ECサイトだとして、「購入者が販売商品を購入できる」というユースケースの場合、PBIに入れるユーザーストーリーとしては、「購入したい商品を検索し商品を確認できる」「購入したい商品を買い物カゴに入れる」「買い物カゴの商品を購入する」のような粒度で良いのでしょうか?</p> <p>それとももっと細かいレベルまで分割すべきでしょうか?「購入者は購入したい商品の値段を確認できる」とか「購入者は購入したい商品の名称を確認できる」みたいなレベル感でしょうか?</p> <p>複数画面をまたがり使用するデータベーステーブルはいつ決めてどうストーリーポイントを決めるのでしょうか?</p> </blockquote> <!-- プロダクトバックログアイテムの分割は慣れないうちはなかなか難しいですが、まず基本を押さえておきましょう。--> <p>それでは考えていきましょう。</p> <h2 id="1つのプロダクトバックログアイテムを複数のスプリントにまたがって開発することはない">1つのプロダクトバックログアイテムを複数のスプリントにまたがって開発することはない</h2> <p>スクラムガイド2020には以下の記述があります。</p> <blockquote> <p>Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.</p> </blockquote> <p>これは「<strong>スクラムチームが1スプリント内で完成できるプロダクトバックログアイテム</strong>は、スプリントプランニングで選択できる準備ができているとみなす」ということです。 つまり、1スプリントに収まらないサイズの場合、スプリントで選択するためには、リファインメントを行って、プロダクトバックログアイテムが指すスコープを小さくしたり、複数のプロダクトバックログアイテムに分割したりしなければいけません(なお、スプリントプランニングのなかでリファインメントをすることもありますが、頻度や量が多い場合は事前準備が不足しています)。</p> <h2 id="一方ですべてのプロダクトバックログアイテムが細かい粒度である必要はないやめろ">一方で、すべてのプロダクトバックログアイテムが細かい粒度である必要はない(やめろ)</h2> <p>プロダクトバックログアイテムは順番に並んでいて、上位のものほど着手するのが早くなります。すなわち下位になればなるほど着手時期が遅くなったり、そもそも着手すらしなかったりします。 当面やらないことをわざわざ小さいサイズに分割してしまうと、プロダクトバックログアイテムの数が膨大になってしまって、並べ替えもできません。そもそも作らないので分割するだけ時間のムダです。</p> <p>すなわち<strong>プロダクトバックログアイテムの粒度は上位ほど細かく、下位ほど粗くなります。</strong> そして、下位のものを上位に持っていく過程で、必要に応じてリファインします。 直近2~3スプリント分くらいまでは1スプリントで扱えるサイズになっているとやりやすいと思います。</p> <p>なお、スプリントで着手するプロダクトバックログアイテムは、1スプリントに収まるサイズになっていなければいけませんが、例えば、1スプリントに投入するプロダクトバックログアイテムが20個も30個もあるという場合はどうでしょうか? すなわちプロダクトバックログアイテムが極小サイズということですが、結論から言うと、これもよくありません。 スプリントゴールの焦点がぼやけている可能性が高いですし、スプリントレビューでインクリメントを見せてフィードバックを貰うのが難しいかもしれません。</p> <h2 id="スプリント期間の長短によってプロダクトバックログアイテムの大きさは変わる">スプリント期間の長短によってプロダクトバックログアイテムの大きさは変わる</h2> <p>これは「1スプリントに収まるサイズ」という前提から当然のことですが、スプリント期間が短ければ、その期間内で完成できるもののサイズは小さくなりますし、逆にスプリント期間が長ければ完成できるもののサイズは大きくなります。</p> <p>もちろんスクラムチームとして大きいプロダクトバックログアイテムを扱えるのか?という問題は別で残りますが、プロダクトバックログアイテムがスプリントの長さの影響を受けることは押さえておきましょう。</p> <h2 id="そもそもスクラムチームごとに能力は異なる">そもそもスクラムチームごとに能力は異なる</h2> <p>プロダクトバックログアイテムのサイズに大きく影響する要素の1つに、<strong>スクラムチームの能力</strong>があります。 洗練されたスクラムチームで技術力も十分あり、継続的に技術的負債を返済するような取り組みをしているようなチームであれば、1スプリントのなかで多くのインクリメントを作れます。 一方で、技術力に課題があったり、レガシーコードだったり、スクラムチームとしてあまり機能していなかったりすると、1スプリントで完成するインクリメントはごくわずかかもしれません。</p> <p>前者のチームであれば、相対的に少々大きいプロダクトバックログアイテムでもスプリント内で完成できるでしょうし、後者のチームであればプロダクトバックログアイテムをだいぶ小さくしないとスプリント内で完成しないかもしれません。</p> <h2 id="スクラムチームは成長する">スクラムチームは成長する</h2> <p>前述のとおりスクラムチームごとに能力は違いますが、スプリントレトロスペクティブなどを活用しながら改善したり、技術習得をしたりすることで、スクラムチームの能力は緩やかに上がっていくことがよくあります(成長の時間を取ってスクラムチームの成長にきちんと投資をしている場合)。</p> <p>その結果、<strong>ある時点ではそのスクラムチームで扱えなかった大きさのプロダクトバックログアイテムが、成長とともに扱えるようになります。</strong></p> <h2 id="スクラムでは何度も同じコードや同じテーブルに手を入れる">スクラムでは何度も同じコードや同じテーブルに手を入れる</h2> <p>従来の開発スタイルでは、最初に要件を全部かためて設計・実装し、動いている箇所は触らないというのが多かったですが、アジャイルな開発ではこれは通用しません。 つまりプロダクトバックログアイテムを実現するときに必要であれば、<strong>既存のコードやテーブルスキーマに何度も手を入れます。</strong> これらの作業はプロダクトバックログアイテムを実現するHowにすぎないので、テーブルスキーマの作成のような作業がプロダクトバックログアイテムになることはありません(つまり単体でテーブルスキーマを作ることに対して、ストーリーポイントで見積もることはありません)。</p> <p>アジャイルでのデータベース設計については、<a href="https://agilejourney.uzabase.com/entry/2022/07/28/103000">そーだいさんの記事</a>がお勧めです。</p> <h2 id="ということで質問に対する回答は">ということで質問に対する回答は?</h2> <p>そろそろ回答はおわかりかと思いますが、どの粒度で分割すべきかは状況次第です。 <strong>作ろうとしているプロダクトの内容だけでは、プロダクトバックログアイテムをどこまで分割すべきかは決まりません。</strong> <strong>スクラムの基本は透明性、検査、適応なので、プロダクトバックログアイテムをどう扱い、改善していくとよいかをスクラムチームで話し合って、より良い分割方法、より良い粒度を見つけてください。</strong></p> <h2 id="プロダクトバックログについて詳細に知りたければ">プロダクトバックログについて詳細に知りたければ</h2> <p>資料を公開しているのでぜひご覧ください。</p> <div id='slidehub-js7fe726a520da7e99f968758567b1fc47'> <script src="https://slide.meguro.ryuzee.com/player/v2/107?prefix=js7fe726a520da7e99f968758567b1fc47" async="async"></script> </div> <br /> <p>ほかに質問がありましたら、ぜひ<a href="https://querie.me/user/ryuzee">こちら</a>よりお気軽にどうぞ。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> 【資料公開】価値をすばやく届けるための改善 https://www.ryuzee.com/contents/blog/14579 Fri, 03 Mar 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14579 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>2023年3月3日に開催のイベント「<a href="https://forkwell.connpass.com/event/272596/" target="_blank">エンジニア文化祭 2023</a>」の登壇資料を公開します。</p> <p>改善というとすぐにプロセスの変更やツールの導入みたいな話になりがちですが、それだとまずいことが多いです。 ということで、本セッションでは、プロダクトで持続的に価値をすばやく届けるために改善をするときに、どんな切り口でどんなことを考えるとよいかをまとめました。 40分という短いセッションなので、細かいことまでは書ききれていませんが、考え方のヒントになれば幸いです。</p> <p>忙しい方向けのまとめ</p> <ul> <li>アウトカムに注目して改善する</li> <li>プロセス改善だけでは無意味</li> <li>複数の領域で改善していく(以下はあくまでも例) <ul> <li>問題設定力 <ul> <li>たくさん作ることを目的にしない、課題にフォーカス、仮説検証、計測、捨てる……</li> </ul> </li> <li>開発力 <ul> <li>技術に向き合う、練習、継続的なテスト、問題の兆候に継続的に対処、機能横断……</li> </ul> </li> <li>チーム力 <ul> <li>非難文化からの脱却、コミュニケーションの複雑性や認知負荷を抑える、ハイパフォーマンスチームを壊さない、本当に必要なら価値の流れに沿ったチームにする……</li> </ul> </li> </ul> </li> </ul> <div id='slidehub-js4002da2793bead104645982d5c2b25cd'> <script src="https://slide.meguro.ryuzee.com/player/v2/115?prefix=js4002da2793bead104645982d5c2b25cd" async="async"></script> </div> <br /> <p>本セッションで参考にしている書籍や言及している書籍</p> <ul> <li><a href="https://amzn.to/3Ze5LMU" target="_blank">『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』</a></li> <li><a href="https://amzn.to/3KR0ztW" target="_blank">『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』</a></li> <li><a href="https://amzn.to/41Iz23W" target="_blank">『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』</a></li> <li><a href="https://amzn.to/41JSxtc" target="_blank">『ベゾス・レター:アマゾンに学ぶ14ヵ条の成長原則』</a></li> <li><a href="https://amzn.to/3KOgUj5" target="_blank">『LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する』</a></li> <li><a href="https://amzn.to/3ZBAiEd" target="_blank">『Effective DevOps ―4本柱による持続可能な組織文化の育て方』</a></li> <li><a href="https://amzn.to/3SHoVse" target="_blank">『あなたのチームは、機能してますか?』</a></li> </ul> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> Scrum Guide Reordered(日本語版) https://www.ryuzee.com/contents/blog/14578 Fri, 20 Jan 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14578 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>スクラム実践者のバイブルとなるのがスクラムガイドです。</p> <p>本文は、日本語版の場合で12ページと分量は少ないですが、多くの人のフィードバックを受けて何度も改訂しているだけあって必要なことが凝縮されています。 チームで定期的に読み合わせをすると学びがあって良いのではないかと思います(安定の角さん翻訳で読みやすさも抜群です)。</p> <p>一方で、スクラムでは責任とイベントと作成物が密接な関係を持つため。どの順番に説明しようとしても、まだ説明していない他の要素に依存したり、説明が分散したりします。 これは構造上仕方がないことですが、初学者にとってはとっつきにくさもあるかもしれません。</p> <p>例えば、スプリントレビューの内容に関する記述は、スクラムガイド日本語版では、7ページ、10ページ〜11ページ、13ページに分散しています。 10ページから11ページがスプリントレビューそのものの説明ですが、ここだけを見ると完成しているインクリメントだけを提示するべきだというのは分からないかもしれません(7ページか13ページを見れば分かります)。</p> <p>そこで役に立つのが、スクラムガイドの文章をキーワード別に分類して並べ替えたこのドキュメントです。</p> <p>前述の「スプリントレビュー」の場合は、以下のようになっています。</p> <img src="/contents/blog/images/14578/SprintReview.png" class="img-responsive" /> <br /> <br /> <p>本書は、Ken Schwaber氏とJeff Sutherland氏が作成した『Scrum Guide(2020 年版)』をもとにStefan Wolpers氏が作成した『Scrum Guide&ndash; Reordered』を日本語化したものです。 スクラムガイドの日本語訳は、角征典さんが翻訳したスクラムガイド日本語版を利用しています。</p> <p>オリジナルのドキュメントはそれぞれ以下から入手できます。素晴らしいドキュメントを作成、翻訳した皆様に感謝いたします。</p> <ul> <li>スクラムガイド <a href="https://scrumguides.org" target="_blank"><a href="https://scrumguides.org">https://scrumguides.org</a></a></li> <li>スクラムガイド(日本語版) <a href="https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf" target="_blank"><a href="https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf">https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf</a></a></li> <li>Scrum Guide—Reordered <a href="https://age-of-product.com/scrum-guide-reordered/" target="_blank"><a href="https://age-of-product.com/scrum-guide-reordered/">https://age-of-product.com/scrum-guide-reordered/</a></a></li> </ul> <p>スクラムガイドがクリエイティブ・コモンズ 表示-継承 4.0 国際ライセンス(CC BY-SA 4.0)で提供されていますので、その派生物である本文書も同一のライセンスとなります。 <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.ja" target="_blank">ライセンス条項</a>を一読の上ご利用ください。<br /> <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.ja" target="_blank"><a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.ja">https://creativecommons.org/licenses/by-sa/4.0/legalcode.ja</a></a></p> <p><a href="/contents/blog/images/14578/ScrumGuide-Reordered-ja.pdf" class="btn btn-lg btn-danger">ダウンロード</a></p> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> 【資料公開】スプリントレビュー Deep Dive https://www.ryuzee.com/contents/blog/14577 Wed, 11 Jan 2023 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14577 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>2023年1月11日-13日に開催のイベント「<a href="https://2023.scrumgatheringtokyo.org" target="_blank">Regional Scrum Gathering Tokyo 2023</a>」の登壇資料を公開します。</p> <p>スプリントレビューは非常に重要なイベントです。 5つのイベントのなかでいちばん重要なイベントを選べと言われたら、僕はスプリントレビューを選びます。 スクラムはプロダクトを届けるためのものであり、プロダクトを成功させるにはプロダクト自体の検査と適応が必須だと思うからです。</p> <p>一方で、スプリントプランニングの精度を上げようと頑張る割にスプリントレビューが雑に扱われる例が多くて懸念していました。 ということで、本セッションでは、スプリントレビューの目的や参加者、進め方、コツなどを深掘りしてみました。 みなさんの参考になれば幸いです。</p> <p>忙しい方向けのまとめ</p> <ul> <li>スクラムチーム全員が参加しろ</li> <li>スクラムチームの外側のステークホルダーを呼べ</li> <li>スプリントゴールに応じて、どのステークホルダーを呼ぶかを選べ</li> <li>プロダクトの状況や進捗、今後の見通しを共有して議論しろ</li> <li>なにはともあれインクリメントを見せろ</li> <li>フィードバックを得られるインクリメントを用意しろ</li> <li>スプリントレビュー直前にインクリメントを変更するな</li> <li>デモはプロダクトオーナーと開発者全員ができるようにしておけ</li> <li>スプリントレビューのやり方を改善しろ</li> <li>スプリントレビューの会話のメモを取っておけ</li> <li>スプリントレビューで「次のスプリントで対応する」とかコミットするな</li> <li>そのスプリントで何も完成しなくても、スプリントレビューをスキップするな</li> <li>スプリントレビューから逆算してスプリントプランニングしろ</li> <li>とはいえ、とにもかくにもインクリメントを提示できるようにしろ</li> </ul> <div id='slidehub-js4a20c31b0e9db113aa929933c6a9ae95'> <script src="https://slide.meguro.ryuzee.com/player/v2/114?prefix=js4a20c31b0e9db113aa929933c6a9ae95" async="async"></script> </div> <br /> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> 【資料公開】マネージャーのしごと https://www.ryuzee.com/contents/blog/14576 Fri, 09 Dec 2022 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14576 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>2022年12月9日に行われたイベント「<a href="https://event.shoeisha.jp/devboost/20221209" target="_blank">Developers CAREER Boost</a>」の登壇資料を公開します。</p> <p>今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました(笑)。</p> <p>全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。</p> <div id='slidehub-js35b5f9a0730c20fc45887ae9f1387cd5'> <script src="https://slide.meguro.ryuzee.com/player/v2/113?prefix=js35b5f9a0730c20fc45887ae9f1387cd5" async="async"></script> </div> <br /> <p>本セッションで紹介した書籍は以下のとおりです。</p> <ul> <li><a href="https://amzn.to/3Blf4kj" target="_blank">エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</a></li> <li><a href="https://www.pmi-japan.shop/shopdetail/000000000028/" target="_blank">PMBOKガイド 第7版</a></li> <li><a href="https://amzn.to/3uzDGlo" target="_blank">INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント</a></li> <li><a href="https://amzn.to/3VYVDWo" target="_blank">プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで</a></li> <li><a href="https://amzn.to/3W1ZqCf" target="_blank">マネジメント[エッセンシャル版] - 基本と原則</a></li> <li><a href="https://amzn.to/3UJJAv7" target="_blank">HIGH OUTPUT MANAGEMENT</a></li> <li><a href="https://amzn.to/3FECEez" target="_blank">エラスティックリーダーシップ ―自己組織化チームの育て方</a></li> <li><a href="https://amzn.to/3PcMCqw" target="_blank">OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法</a></li> <li><a href="https://amzn.to/3hfe9ew" target="_blank">1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え</a></li> </ul> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> チームの状況を把握するための5つの質問 https://www.ryuzee.com/contents/blog/14575 Sat, 22 Oct 2022 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14575 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>アジャイルコーチでもスクラムマスターでもエンジニアリングマネージャーでも、新しいチームと一緒に働くことになった場合にまず必要なのが情報収集です。 チームの様子を観察したり、1on1で聞いてみたり、ドキュメントを読んでみたりとさまざまな方法があります。 そこで、今回は直接チームのみんなに話を聞いて情報収集する場合に、<strong>5個だけ質問できるとしたら</strong>何を聞けばよいか考えてみました。</p> <p>まず、初期の段階では、単に開発プロセスがうまく回っているかどうかだけを聞いてもあまり意味がありません。 そこでプロダクト、意思決定の方法、デリバリー、改善、チームのことを聞いてみようと考えてできたのが、以下の5つの質問です。</p> <hr> <ul> <li>プロダクトは顧客の課題解決に役立っていますか?役に立つかどうか、役に立っているかどうかをどうやって確かめていますか?</li> <li>いま開発している機能は誰にとってどう役に立ちますか?なぜ開発することになりましたか?</li> <li>どれくらい頻繁に顧客に対してリリースしていますか? その頻度はどうやって決まっていますか?</li> <li>自分たちの仕事のやり方を改善していますか?最近改善したいちばん大きな問題を教えてください</li> <li>チームは楽しく充実した仕事をしていますか?回答の根拠も教えてください</li> </ul> <hr> <p>それぞれについて順番に見ていきましょう。</p> <h2 id="プロダクトは顧客の課題解決に役立っていますか役に立つかどうか役に立っているかどうかをどうやって確かめていますか">プロダクトは顧客の課題解決に役立っていますか?役に立つかどうか、役に立っているかどうかをどうやって確かめていますか?</h2> <p>この質問はプロダクトに関する質問です。</p> <p><a href="https://amzn.to/3eSHj1L" target="_blank">『プロダクトマネジメント――ビルドトラップを避け顧客に価値を届ける』</a>によると、プロダクトは提供側と顧客の間の価値交換システムです。 顧客が自身の課題を解決する、もしくは自身の課題の解決に役立つと判断するからこそ、プロダクトに対してお金などの対価を払います。 これによってプロダクトの提供を持続できるようになります。</p> <p>「プロダクトは顧客の課題解決に役立っていますか?」という質問に対して、ノーという答えやわからないという答えが返ってきた場合は、プロダクトマネジメントが不十分である可能性を示唆しています。 また、単にステークホルダーからそのプロダクトを開発するように言われただけで、チームのプロダクトに対する関心が欠如しているということもありそうです。</p> <p>「役に立つかどうか、役に立っているかどうかをどうやって確かめていますか?」という質問に対して、顧客インタビュー、エスノグラフィー、実験、さまざまなエンゲージメント指標やノーススターメトリックなどの話が出てきた場合はよさそうです。一方でダウンロード数やユーザー数、ページビュー数などのいわゆる虚栄の指標が出てきた場合は深堀りしたほうがよいかもしれません。</p> <h2 id="いま開発している機能は誰にとってどう役に立ちますかなぜ開発することになりましたか">いま開発している機能は誰にとってどう役に立ちますか?なぜ開発することになりましたか?</h2> <p>この質問は意思決定に関する質問です。</p> <p>「いま開発している機能は誰にとってどう役に立ちますか?」という問いに明確に答えられない場合は、チームがフィーチャーファクトリー(誰かに言われるままに、ただたくさん作ることを要求されているチーム)になっているかもしれません。 「なぜ開発することになりましたか?」に対する答えが、プロダクトオーナーが決めたから、とか、チームの外側のステークホルダーの強い要望があったから、といった場合も同様です。</p> <p>反対に、プロダクトに対する顧客やユーザーからのフィードバックを受けて決定した、とか、プロダクトのノーススターメトリックやKGIを踏まえて、それらの値を改善するための実験の1つとして決定した、といった回答の場合は、自分たちである程度プロダクトに対する意思決定ができていることを示していそうです。</p> <h2 id="どれくらい頻繁に顧客に対してリリースしていますかその頻度はどうやって決まっていますか">どれくらい頻繁に顧客に対してリリースしていますか?その頻度はどうやって決まっていますか?</h2> <p>この質問はデリバリーに関する質問です。</p> <p>当然のことながら、すべてのプロダクトが日次で顧客にリリースされなければいけないわけではありません。プロダクトの性質によって適切なリリース頻度は変わります。 とはいえ、相当に安定しているプロダクトでなければ、3か月や半年に1回のリリースでは少ないかもしれません。 今のリリース頻度がプロダクトの性質を踏まえて決めているものなのか、チームの能力ゆえに決まっているものなのか(たとえば、テストを全部手動でやっているとか)、もしくは、会社のプロセス上の制約(たとえば、リリースには審査が必要でとても時間がかかるとか)によって決まっているのかを明らかにしておくことで、今後さらに深堀りすべき点が見つけられそうです。</p> <h2 id="自分たちの仕事のやり方を改善していますか最近改善したいちばん大きな問題を教えてください">自分たちの仕事のやり方を改善していますか?最近改善したいちばん大きな問題を教えてください</h2> <p>この質問は改善に関する質問です。</p> <p>「自分たちの仕事のやり方を改善していますか?」と聞いて、改善していないと答えるチームはほとんど見たことはありませんが、とはいえ実効性のある改善を継続的にできているチームはそれほど多くはありません。 ひどい例だと、ふりかえりで多数のアクションアイテムを洗い出して、個人にアサインし、次回のふりかえりで着手もできておらずにそのまま先送りにするといったケースを見かけたこともあります。 またチームで着手できそうな簡単で時間のかからない項目だけを改善して(これはこれで進めればよいのですが)、自分たちのパフォーマンスを阻害するような大きな問題は諦めて目をつぶっていることもあります。</p> <p>スクラムガイドの2020年版では、「スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する」と言っています。 「最近改善したいちばん大きな問題を教えてください」という質問によって、チームのパフォーマンスにインパクトを与えるような問題を放置せずに改善しているかどうかがわかりそうです。</p> <h2 id="チームは楽しく充実した仕事をしていますか回答の根拠も教えてください">チームは楽しく充実した仕事をしていますか?回答の根拠も教えてください</h2> <p>この質問はチームに関する質問です。</p> <p>「楽しく充実した仕事」とは何かというと難しいですが、日々自分の能力を発揮し、自分自身にとって、チームにとって、はたまたプロダクトや会社、社会にとって意義があると感じられるような仕事ではないかと思います。 人によってこの定義は変わっても構わないのですが、少なくとも「楽しくないし充実していない」という回答であれば、それで仕事の成果を上げることは難しいのではないでしょうか。 また、これはマネジメントを始めとした組織的機能不全を表していたり、人の離脱の可能性を示唆したりもしています。</p> <p><a href="https://amzn.to/3siGMJK" target="_blank">『スクラム―仕事が4倍速くなる&quot;世界標準&quot;のチーム戦術』</a>のなかでジェフ・サザーランドはこう書いています。 「どんな仕事でも、仕事を形にするのはチームの力だ。車を造るチーム、問い合わせの電話に応えるチーム、手術を執刀するチーム、コンピュータをプログラミングするチーム、 ニュースを伝えるチーム、 テロリストが占拠する建物に突入するチーム。もちろん、 一人で仕事をする職人や芸術家などもいるが、チームの力が世界を動かしているといっていい。スクラムのべースもチームにある」。</p> <p>チームが機能しないと複雑な環境下での競争には勝てませんが、この質問によってチームに深堀りすべき問題がありそうかどうかがわかります。</p> <hr> <p>自分はこんな質問をしている!とかもっと良い表現がある!とかがあればぜひ<a href="https://twitter.com/ryuzee">Twitter</a>で教えてください。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div> 【資料公開】エンジニアリングマネージャーのしごと https://www.ryuzee.com/contents/blog/14574 Wed, 07 Sep 2022 02:01:00 +0900 https://www.ryuzee.com/contents/blog/14574 <p>みなさんこんにちは。<a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a>です。<br /></p> <p>2022年9月6日に行われたオンラインイベント「<a href="https://forkwell.connpass.com/event/257329/" target="_blank">エンジニアリングマネージャーのしごと - Forkwell Library #5</a>」の登壇資料を公開します。</p> <p>内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、本書は18章、350ページからなる本であり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&amp;Aコーナーがあったのですが、その内容については、<a href="https://aki-m.hatenadiary.com/entry/2022/09/06/211134" target="_blank">aki.mさんのブログ記事</a>にまとまっていますので参考にしてください。</p> <div id='slidehub-js21d58a1841cc200d98564269e8494122'> <script src="https://slide.meguro.ryuzee.com/player/v2/112?prefix=js21d58a1841cc200d98564269e8494122" async="async"></script> </div> <br /> <p>内容に関するご意見やフィードバックは、Twitter: <a href="https://twitter.com/ryuzee" target="_blank">@ryuzee</a> までお知らせください。</p> <p>スライドを見て興味を持たれた方は、ぜひ<a href="https://amzn.to/3BefART" target="_blank">書籍『エンジニアリングマネージャーのしごと』</a>を読んでいただければと思います。</p> <p>それでは。</p> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t4IrnjicL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119944?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2022-08-26</li> <li><strong>単行本(ソフトカバー):</strong>376ページ</li> <li><strong>ISBN-13:</strong>9784873119946</li> <li><strong>ASIN:</strong>4873119944</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SL500_.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>日本能率協会マネジメントセンター</li> <li><strong>発売日:</strong>2021-12-01</li> <li><strong>単行本:</strong>280ページ</li> <li><strong>ISBN-13:</strong>9784820729631</li> <li><strong>ASIN:</strong>4820729632</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51PEs0Kbw8L.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4798163686?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>西村 直人、 永瀬 美穂、 吉羽 龍太郎</li> <li><strong>出版社:</strong>翔泳社</li> <li><strong>発売日:</strong>2020-05-20</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784798163680</li> <li><strong>ASIN:</strong>4798163686</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51om1Fw-bNL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119391?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>スクラム実践者が知るべき97のこと</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Gunther Verheyen、 吉羽 龍太郎、 原田 騎郎、 永瀬 美穂</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2021-03-23</li> <li><strong>単行本(ソフトカバー):</strong>288ページ</li> <li><strong>ISBN-13:</strong>9784873119397</li> <li><strong>ASIN:</strong>4873119391</li> </ul> </div> </div> </div> </div> <div class="panel panel-default recommended-book"> <div class="panel-body"> <div class="row"> <div class="col-md-4"> <a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41HyRB-w7hL.jpg" class="img-thumbnail2 img-responsive" /></a> </div> <div class="col-md-8"> <h4><a href="https://www.amazon.co.jp/dp/4873119251?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1"><strong>プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける</strong></a></h4> <ul> <li><strong>著者/訳者:</strong>Melissa Perri、 吉羽 龍太郎</li> <li><strong>出版社:</strong>オライリージャパン</li> <li><strong>発売日:</strong>2020-10-26</li> <li><strong>単行本(ソフトカバー):</strong>224ページ</li> <li><strong>ISBN-13:</strong>9784873119250</li> <li><strong>ASIN:</strong>4873119251</li> </ul> </div> </div> </div> </div>