はてなブックマーク

みなさんこんにちは。@ryuzeeです。 2025年11月29日にBacklog World 2025で「生成AI時代のチーム設計―役割と協働の再構築」というテーマで登壇した際のスライドを公開します（下書きのまますっかり忘れていました……）。 もはや生成AIを使わないプロダクト開発組織やチームを見つけるほうが難しい状況です。 生成AIを使うようになると、プロセスはもちろんのことチーム構造にも大きな影響を及ぼします。 この講演では主にチームの観点での変化について解説しました。 お役に立てば幸いです。 以下は、スライドの内容のサマリーです。プロダクトの価値は、チームの外側で決まる生成AIの利用の有無に関係なく、私たちが目指すのはプロダクトの成功です。 そこで重要となる原則は以下です。 プロダクトの価値は、作り手ではなく、顧客やユーザーが決める どれだけ「頑張って作ったか」「高度な技術を使ったか

みなさんこんにちは。@ryuzeeです。 2025年11月14日にお客様先で「プロダクトの成長を支える生成AI時代のエンジニアリングプラクティス」というテーマで登壇した際のスライドを公開します。 なお、タイトルは若干釣りです。 開発作業で生成AIを使うのが当たり前になり、「今後3〜6カ月以内にソフトウェアエンジニアのコードの90％をAIが書くようになり、今後1年以内にはすべての行をAIが書くようになる」とか 「技術スキルのないPdMがVibe Codingで作れた！もうエンジニアはいらない」みたいな主語の大きな話を見かける機会が増えました。 たしかにプロトタイプやモック、検証コードなんかはそのとおりかもしれませんが、成長を始めたプロダクトになるとそうはいきません。 使われるソフトウェアには必ず変更が入るので、変更に耐えられる構造を実現して維持していくことが重要で、そのためには整頓やリファク

みなさんこんにちは。@ryuzeeです。 2025年10月17日に技術顧問先の社内イベントで「生成AIでスクラムによる開発はどう変わるか」というテーマで登壇しましたので、そのときの資料を公開します。 先日発表された「State of AI-assisted Software Development」にもあるように、開発現場でのAI導入は当たり前になりました。 これはすなわち、既存の開発プロセスをAIにあわせてチューニングしなければいけないことを意味します（そしてAI自体が非常に速い速度で変化しているので、それにあわせて継続的な調整が必要です）。 スクラムについても同様で、根底となる価値観や原則に変化はないものの、イベントや作成物などには大きな影響があります。 このセッションでは、複数の支援先を踏まえて、現時点で起こっている変化について説明しました。 参考になれば幸いです。 忙しい方向けのま

スクラムでは、スクラムマスターがパフォーマンスを管理するわけではありません。 スクラムチームは自己管理であり、誰が何をいつどうやってやるかはスクラムチーム自身が決めます。これが基本原則です。 また、責任の観点では、プロダクト自体の進捗（プロダクトゴールに向けた状況）であればプロダクトオーナーが説明責任を担い、スプリント中の開発の進捗であれば開発者自身が説明責任を担います。 これらを踏まえると、スクラムマスターが判断して個別対応するのではなく、まずは開発者同士で状況を話し合い、 …

みなさんこんにちは。@ryuzeeです。 2020年版のスクラムガイドで「プロダクトゴール」が登場してから5年近く経ちましたが、いまだにプロダクトゴールを設定していないチームや、うまく使えていないチームをたくさん見かけます。 ときには、「うちは目の前のスプリントに粛々と取り組むだけなので、あんまり関係ないです」と言われたりすることもあります。 しかし、スクラムは「ゴール指向のフレームワーク」です（2020年版の改訂でさらにそのトーンが強くなりました）。 ゴールがなければ、そこに至る道筋を計画することも、進捗を検査することもできません。 先日支援先の相談タイムでもプロダクトゴールが話題になったので、ちょっと整理したいと思います。 なお、この話の多くはスプリントゴールにも当てはまります。 プロダクトゴールとは？まずは、何はともあれスクラムガイドです。スクラムガイド2020で、プロダクトゴールと

みなさんこんにちは。@ryuzeeです。 2025年7月3日〜4日開催の開発生産性カンファレンス 2025 - Findyの登壇資料を公開します。 本セッションでは、「開発生産性」の意味が、プロダクト開発のステージやチーム構造によってどのように変化していくのかを説明しました。 すべてのチームが同じメトリクスを取得する意味はないですし、チームの置かれた状況によって取得するとよいメトリクス自体が変化します。 詳細は以下のセッション資料をご覧ください。 重要な点を簡単にまとめておくと以下のとおりです。 チームごとに何がいちばん重要かは異なり、開発生産性の意味も異なる仮説検証中のチームは「価値ある課題の発見」が重要スケーリング中のチームは「安定したデリバリー」が重要プラットフォームチームなら「他チームの負担軽減」や「プラットフォームの安定性」が重要指標もそれぞれ異なるプロダクト指標（利用率、継続率

みなさんこんにちは。@ryuzeeです。 「フィーチャーファクトリー」は、プロダクトマネジメントの専門家であるジョン・カトラー（John Cutler）1が2014年に使い出した単語です。日本語にすると機能工場となり、単に与えられた要求をひたすら作り続けたり、アウトカムやインパクトよりも、作った機能の量や出荷スピードだけに注目したりするチームや組織を指します。 複雑で変化が激しい環境においては、事前に考えたことがすべてそのとおりになることはありません。 端的に言うと、多くのものは外れます。外れることを前提にすると、成功するために数を打つこと、そして素早くそれを実行することはとても重要です。でも、それ「だけ」に注目するのは無意味です。 ジョン・カトラーは自身の記事「12 Signs You’re Working in a Feature Factory」のなかで、フィーチャーファクトリーで働

プロダクトバックログアイテムの数が多すぎると、チームに悪影響を及ぼします。 たとえば、以下のような問題が発生します。 プロダクトバックログアイテムが多すぎると、どこに何があるのかが分かりづらくなり、全体像を把握するのが難しくなります そのため、似たようなプロダクトバックログアイテムが重複して追加されたり、不要なプロダクトバックログアイテムが残ったままになったりします また、数が多いと1つ1つを確認する時間がないので、個々のプロダクトバックログアイテムの質が落ちていきます こ …

みなさんこんにちは。@ryuzeeです。 2025年2月21日開催のオンラインイベント「“Tidy First?” 翻訳者陣に聞く！Kent Beck氏の新刊で学ぶ、コード整頓術のススメ」の登壇資料を公開します。 昨年12月に発売されたケント・ベック氏の新刊『Tidy First?』の訳書はおかげさまで多くの人に読んでいただいてますが、「第3部 理論」の内容が難しいという感想を複数見かけました。 そこで今回は第3部の24章〜27章の話を改めて整理して説明しています。 みなさまの理解のお役に立てば幸いです。

みなさんこんにちは。@ryuzeeです。 2025年2月13日〜14日開催のDevelopers Summit 2025の登壇資料を公開します。 以前別のイベントで「30分で分かった気になるチームトポロジー」という話をしたのですが、今回さらに踏み込んだ話をしてほしいというリクエストをいただいたのが登壇のきっかけです。 本セッションでは、チームトポロジーの概要に始まり、プロダクト開発チームがどのように構造を変えていくかをよくある例をもとに解説し、最後に構造変更のときにチームトポロジーと組み合わせて使えるダイナミックリチーミングの5つのパターンを紹介しました。 詳細は以下のセッション資料をご覧ください。 重要な点を簡単にまとめておくと以下のとおりです。 速いフローを実現（維持）するという観点でチーム構造を考える。それに使えるのがチームトポロジーチームトポロジーは、コンウェイの戦略を活用した組織

みなさんこんにちは。@ryuzeeです。 2025年1月8日〜10日開催のRegional Scrum Gathering Tokyo 2025の登壇資料を公開します。 「スプリントレトロスペクティブ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。 プロダクトバックログ Deep Diveスプリントプランニング Deep Diveスプリントレビュー Deep Diveベロシティ Deep Diveセッション資料は以下になります。 重要な点を簡単にまとめておくと以下のとおりです。 「スプリントレトロスペクティブ」と「ふりかえり」は別のもの。既存の汎用的な用語で置き換えると誤解を招いたり、内容の希薄化につながったりするスプリントレトロスペクティブでは「品質と効果を高める」ことを目的としているが、

アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 KPT（Keep, Problem, Try）はシンプルで使いやすいフレームワークとして知られていますが、スクラムのスプリントレトロスペクティブで繰り返し（毎回のように）利用することはお勧めしません。 なお、KPT自体が有効でないと言っているわけではありません。スプリントレトロスペクティブで繰り返し利用することに対する問題提起です。 たとえば何らかの大きな取り組みの最後に行ったり、プロダクトゴールを達成したあとや四半期ごとに長めの時間をとって全体を見たりするときには有効なこともあります。 また、ずっと改善を繰り返してきて非常に練度や能力が高くなっているチームの場合も有効かもしれません

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 アジャイルを活用したプロダクト開発では、初期は1つの小規模なチームからスタートすることが一般的です。 この段階では迅速な仮説検証や市場適応が求められるため、ユーザーからのフィードバックを反映しやすい少人数の柔軟なチーム構成が理想的です（逆に言うと、仮説検証段階でチーム規模を大きくしてしまうと、何か仕事をしなければいけないと考えて、使わない機能を開発したり、余計な標準化などに時間を費やしたりしてしまう可能性があります）。 しかし、プロダクトが成長し、市場での成功の兆しが見えてくると、より多くの機能の開発や技術的な対応が必要になり、チーム規模の拡大（スケーリング）が必要になるの

原著はKent Beck氏の『Tidy First?: A Personal Exercise in Empirical Software Design』です。 翻訳はいつもの株式会社アトラクタのアジャイルコーチ3人で行いました（私自身は16冊目の翻訳です）。 みどころ何を紹介しようか迷ったのですが、どんな本なのかは訳者あとがきに書きました。 オライリー・ジャパン様のご厚意で、全文引用の許諾をいただきましたので以下に掲載します（出典『Tidy First?: 個人で実践する経験主義的ソフトウェア設計』125〜127ページ、オライリージャパン、2024年）。 本書は、Kent Beck著『Tidy First? A Personal Exercise in Empirical Software Design』（978-1098151249、O’Reilly Media、2023年）の全訳です

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラム初心者向けに理解度クイズを用意しました。 内容はスクラムガイド2020とアジャイルソフトウェア開発宣言をもとにしています。 問題は全部で30問です。正答率90%以上が合格ラインです。 （なお、この試験はScrum Alliance認定スクラムマスターの試験とは一切関係なく、レベル感を示すものでもなければ、合格を保証するものでもありません。あらかじめご承知おきください）

ブログryuzeeによるブログ記事。不定期更新Homeブログ短い間隔で動作するソフトウェアを見せようとするとすべてが改善される みなさんこんにちは。@ryuzeeです。 今回は、自称「アジャイル開発をしている」といいつつ、定期的に謎の進捗報告会をJiraで行ない、「効率がどうたら」と口癖のように言っている人たちへの説教です。 スクラムでもスクラムでないやり方でも何でも構わないのですが（その違いは大きな問題ではない）、動作するソフトウェアを定期的に披露しようとすると、さまざまな改善が芋づる式に進みます。 披露しようとすれば、一気通貫で動作し、目で見て分かり、評価可能ものを作ることになります。 部品だけを作っても見えないし分かりません。例えばUIモックだけを作っても実際の操作感は分かりません。 何より動かないものや触れないものは真剣に見ません（モックを事前に送付してコメントがさして無かったのに

アジャイルFAQアジャイルやスクラムに関するよくある質問HomeFAQ1つのプロダクトバックログアイテムが大きくて1スプリントでは作れませ⋯⋯

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） 最近「開発生産性」という言葉を耳にする機会がすごく増えたような気がしますし、自分でもあるメディアの取材で「開発生産性」という単語を使ったのですが、なんとなくスッキリしない感じを抱えていました。 僕自身は「生産性」という単語の不透明さをさけるべく「開発生産性」を使ったのですが、これでも不透明さは残ったままだったわけです。 ということで、「開発生産性」が何を指すのかを深堀りした上で、この単語とどう付き合っていくべきなのかを整理したのが、このセッションです。 スライド全部を読む時間のない方もいると思いますので、以下に結論を書いておきます。 「開発生産性」に関心を持つ理由も、「開発生産性」の定義もさまざま重要なのはコンテキ

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 2024年6月3日に行われたソニー主催、Forkwell共催の勉強会「TechLovers #2」の登壇資料を公開します。 プロダクト開発には、さまざまなステークホルダーが登場します。 プロダクトのフェーズや開発の状況によってステークホルダーの重要度は変わります。そしてステークホルダーごとに持っている権限の強さや権限が及ぶ範囲も違います。 これらを無視して開発を進めると、プロダクトに大きな影響を及ぼすようなことが起こりかねません（メテオフォールなるものもその1例です）。 つまり、戦略的にステークホルダーと付き合っていかなければいけません。 この資料では、フレームワークを活用

ブログryuzeeによるブログ記事。不定期更新Homeブログアジャイル開発がうまくいっていない気がするというチームに確認すべきこ⋯⋯ みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイントいきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に

みなさんこんにちは。@ryuzeeです。 2024年1月10日〜12日開催のRegional Scrum Gathering Tokyo 2024の登壇資料を公開します。 「ベロシティ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。 プロダクトバックログ Deep Diveスプリントプランニング Deep Diveスプリントレビュー Deep Diveセッション資料は以下になります。 結論から言うと、「ベロシティなんかにDeep Diveせず、もっと重要なところに集中しろ」です。 スクラムチームの状況を何らかの数値で表したいという考え自体は尊重しますし、それが役に立つこともあります。 ただし、数字遊びをしたところでプロダクトの価値を生み出せるわけではないので、ほどほどにしましょう。 スクラム

Q. スプリントレビューにステークホルダーが参加していますが、あまり反応やフィードバックがありません。どうしたらよいでしょうか？

みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか？」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい

ブログryuzeeによるブログ記事。不定期更新Homeブログスクラムチームのパフォーマンスを測定したいと思ったら みなさんこんにちは。@ryuzeeです。 スクラムチームのパフォーマンスを測定したいとステークホルダーに言われて悩んでいるスクラムマスターは多いと思います。 今回は、スクラムチームのパフォーマンスはどうやって測ればいいのか、何を気をつけるといいのか考えてみましょう。 具体的なメトリクスについては、別の記事で触れる予定です。 測定には目的が必要ソフトウェア開発に限らず、何かを測定しようとするときには目的が必要です。 目的がないと、リソースがムダになったり、意思決定が難しくなったり、データをめぐって混乱が発生したりするリスクが高まります。 やりたいこと、やらなければいけないことは、だいたいやれる量よりも多いですが、そんな状況で限られた時間や資源を有効に活用するためには、測定が意図す

ブログryuzeeによるブログ記事。不定期更新Homeブログプロダクトバックログリファインメントはいつ何をするのか みなさんこんにちは。@ryuzeeです。 プロダクトバックログリファインメントのやり方について立て続けに聞かれることがあったのでまとめておきます。長文ですが参考になれば幸いです。 まずはスクラムガイド2020を確認しておきましょう。該当する箇所は3箇所です。 スプリントでの説明（9ページ） スプリントでは、（中略） プロダクトバックログを必要に応じてリファインメントする。スプリントプランニングのトピック2での説明（10ページ） 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。 スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。 それによって、チームの理解と自

アジャイルFAQアジャイルやスクラムに関するよくある質問HomeFAQプロダクトバックログアイテムはいつ見積もればいいですか？

アジャイルFAQアジャイルやスクラムに関するよくある質問HomeFAQスクラムにおいて開発者を社外から集めるとどんな問題がありますか？