【資料公開】ステークホルダーとの付き合い方を考える
みなさんこんにちは。@ryuzeeです。 2024年6月3日に行われたソニー主催、Forkwell共催の勉強会「TechLovers #2」の登壇資料を公開します。 プロダクト開発には、さまざまなステークホルダーが登場します。 プロダクトのフェーズや開発の状況によってステークホルダーの重要度は変わります。そしてステークホルダーごとに持っている権限の強さや権限が及ぶ範囲も違います。 これらを無視して開発を進めると、プロダクトに大きな影響を及ぼすようなことが起こりかねません（メテオフォールなるものもその1例です）。 つまり、戦略的にステークホルダーと付き合っていかなければいけません。 この資料では、フレームワークを活用してステークホルダーを分類し、分類に応じた接し方を紹介しています。 プロダクト開発においては、常にやりたいことややらなければいけないことがたくさんあり、時間や人は足りません。 そ
プロダクトバックログアイテムの分割方法
みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。 必ず、1スプリントで完成できる大きさになっている必要があります。 これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。 そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。 最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。 こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変え
【資料公開】プロダクトバックログ Deep Dive
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 今年もスクラム実践者の祭典であるRegional Scrum Gathering Tokyoが、2022年1月5日〜7日までの3日間開催されました。 このイベントで「プロダクトバックログ Deep Dive」というタイトルで発表しましたので、資料を公開します。 スクラムガイドでも、プロダクトバックログという単語の登場回数は非常に多く、それだけ重要だということが分かります。 一方で網羅的にまとまっている資料が日本語ではあまり存在しなさそうなので、今回用意してみました。 内容については、過去にこのブログで説明している箇所も多数ありますが、1箇所にまとめたことに意義があるということでご了承ください。 みなさんのお役に立てば幸いです。 内容に関するご意見やフィードバックは、T
スクラムチーム用セルフチェックリスト
みなさんこんにちは。@ryuzeeです。 スクラムに限らず開発プロセスそのものは目的を達成するための手段に過ぎないので、定義されたプロセスやプラクティスを単に守れば良いというわけではありません。 根底にある価値観や原則を理解することが重要です。 とはいえ、自分たちのプロセスが定義されたもの、一般的なものとどれだけ違うかを知ることは、改善のキッカケにもなります。 今回、スクラムチームが、自分たちの仕事のやり方を改善する際に参考にできるような、セルフアセスメントのチェックリストを作ったので共有します。 現時点では単なる試作品なので、ご利用は自己責任でお願いします（この記事に限らず当サイトの記事を参考にする場合も同様です）。 使えそうなら適宜更新していく予定です。 観点はスクラムの主要要素（3-5-3）にしています。フィードバックなどがありましたら、@ryuzeeまでお知らせください。 使い方使
【翻訳】あなたのスクラムチームの成熟度は？
みなさんこんにちは。@ryuzeeです。 3月23日に『スクラム実践者が知るべき97のこと』が発売になりますのでよろしくお願いします。 さて、スクラムチームがどれくらいの成熟しているかは、とくにスクラムを始めてまだ長時間たっていない場合には気になるところだと思います。 そこで今回はスクラムチームの成熟度を自己評価して、改善に結びつけるための資料を共有します。 この資料はScrum.orgのトレーナーであるRon Eringa氏がブログで公開しているものです。 このモデルでは、スクラムマスター、プロダクトオーナー、開発チーム（スクラムガイド2020で開発者に改められています）のそれぞれで成熟度を明らかにします。 そして、全体でいちばん低い数字がスクラムチームとしての成熟度になるとされています。 使い方ですが、人事評価や他チームとの比較に使うのではなく、チームとしてどう成長していくべきか、どこ
SI案件でアジャイル開発を進めるときの勘所
みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可能性があるので、案件開始前に教育すべしステークホルダーマネジメントは重要。これはウォーターフ
新規事業とアジャイル
みなさんこんにちは。@ryuzeeです。 新刊『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』が10月26日に発売になりますので、よろしくお願いします。 先日、プライベートで新規事業とアジャイルに関する短いセッションをしましたので、そのときの資料を共有します （本当は1時間かかるものをかなり縮めたダイジェスト版です）。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）何が分からないのかすら分からないこともある。過度に詳細な計画にしない適切な問題を扱っているか、顧客はいるかが重要顧客が関心を持つのは、自分の課題の解決であり、ソリューションそのものではない仮説と検証の繰り返し急いでたくさん作らない。機能の多さは成功につながらない投資モデルを変える(100打数10安打1ホームランなら上等)アジャイルとはフィードバックサイクルの集合体最初から人が多すぎると
【資料公開】レガシーコードからの脱却
みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
これからプロダクトオーナーになる人へ
みなさんこんにちは。@ryuzeeです。 これからスクラムで初めてプロダクトオーナーをやる方に向けてのポエムです。 何はともあれ時間を確保しようプロダクトオーナーは非常に忙しい役割です。片手間でできる仕事ではありません。 例えば、プロダクトオーナーが開発チームのために週1日しか開発チームと一緒の時間をすごせず、後はメールやSlackなどのオンラインツールで非同期かつ遅延のあるコミュニケーションを取る場合を考えてみましょう。そこで起こるのは、開発のリードタイムの増加と手戻りの増加です。細かい確認をすべてオンラインでやることはできないので、開発チームは想像で物事を進めてしまい、後で認識の違いが分かり使った時間を無駄にするか、次回対面で話せるまで結論を先送りにするかのいずれかになります。 プロダクトオーナーは、プロダクトにつき1人です。サポート役をつけることはできますが、最終意思決定者が1人とい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
