【資料公開】価値創造と開発生産性
みなさんこんにちは。@ryuzeeです。 2024年6月28-29日に開催の開発生産性Conference 2024で登壇しましたので、資料を公開します。 最近「開発生産性」という言葉を耳にする機会がすごく増えたような気がしますし、自分でもあるメディアの取材で「開発生産性」という単語を使ったのですが、なんとなくスッキリしない感じを抱えていました。 僕自身は「生産性」という単語の不透明さをさけるべく「開発生産性」を使ったのですが、これでも不透明さは残ったままだったわけです。 ということで、「開発生産性」が何を指すのかを深堀りした上で、この単語とどう付き合っていくべきなのかを整理したのが、このセッションです。 スライド全部を読む時間のない方もいると思いますので、以下に結論を書いておきます。 「開発生産性」に関心を持つ理由も、「開発生産性」の定義もさまざま 重要なのはコンテキスト 数字だけで全て
デイリースクラムの進め方
みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的 2. デイリースクラムの参加者 3. デイリースクラムのタイムボックス 4. デイリースクラムの事前準備 5. デイリースクラムのファシリテーション・進行 6. デイリースクラムのアンチパターン 1. デイリースクラムの目的 スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、
アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバック
【資料公開】プロダクトマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか？」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい
プロダクトバックログアイテムはいつ見積もればいいですか？
スクラムガイド2020には以下のように記述されています。 1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。 プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。 これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。 多くの場合、属性は作業領域によって異なる。 最初の文が意味するところは、以下のとおりです。 スプリントで選択するプロダクトバックログアイテムは1スプリント内で完成する大きさになっていなければいけない1スプリントに収まるサイズになっていれば、スプリントプランニングで選択の準備ができていると言える選択のための準備は、通常リファインメントの活動のなかで行うリファ
【資料公開】プロダクトオーナーアンチパターン
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
Scrum Guide Reordered（日本語版）
みなさんこんにちは。@ryuzeeです。 スクラム実践者のバイブルとなるのがスクラムガイドです。 本文は、日本語版の場合で12ページと分量は少ないですが、多くの人のフィードバックを受けて何度も改訂しているだけあって必要なことが凝縮されています。 チームで定期的に読み合わせをすると学びがあって良いのではないかと思います（安定の角さん翻訳で読みやすさも抜群です）。 一方で、スクラムでは責任とイベントと作成物が密接な関係を持つため。どの順番に説明しようとしても、まだ説明していない他の要素に依存したり、説明が分散したりします。 これは構造上仕方がないことですが、初学者にとってはとっつきにくさもあるかもしれません。 例えば、スプリントレビューの内容に関する記述は、スクラムガイド日本語版では、7ページ、10ページ〜11ページ、13ページに分散しています。 10ページから11ページがスプリントレビューそ
【資料公開】マネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年12月9日に行われたイベント「Developers CAREER Boost」の登壇資料を公開します。 今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました（笑）。 全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。 本セッションで紹介した書籍は以下のとおりです。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーに
【資料公開】エンジニアリングマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年9月6日に行われたオンラインイベント「エンジニアリングマネージャーのしごと - Forkwell Library #5」の登壇資料を公開します。 内容は、新刊書籍『エンジニアリングマネージャーのしごと』に関するものなのですが、本書は18章、350ページからなる本であり全部を網羅的に紹介するのは無理筋なので、今回は根底にある考え方にフォーカスを当てています。この発表のあとにQ&Aコーナーがあったのですが、その内容については、aki.mさんのブログ記事にまとまっていますので参考にしてください。 内容に関するご意見やフィードバックは、Twitter: @ryuzee までお知らせください。 スライドを見て興味を持たれた方は、ぜひ書籍『エンジニアリングマネージャーのしごと』を読んでいただければと思います。 それでは。 エンジニアリングマネージャー
【資料公開】スプリントプランニング Deep Dive
みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに
基礎からわかる内製化
みなさんこんにちは。@ryuzeeです。 2022年7月6-7日のGoogle Cloud 内製化 Dayの1日目で光栄にも特別講演をさせていただきました。 資料については、イベントページにすでに掲載されていますのでご案内します（このページにアクセスして、「公開資料」の下にある「特別講演」をクリックしてください）。 なぜ内製か？ 今の世の中はソフトウェアが企業の競争力の源泉になっていますが、そこで必要なのは、「素早く」「頻繁に」「安定的に」価値を届けること、つまり安定した「価値のフロー」の実現です。 ソフトウェアの構築は知的労働であり、実際の作り手はチームです（マネージャーや管理者、経営者ではありません）。 したがって、企業としては、安定した「価値のフロー」を実現できるチームを手にいれる必要があります。 安定したフローを実現するためには、専任が必要です。複数のプロダクトやプロジェクトを同時
【資料公開】アジャイルについてマネージャーが知るべき97のこと
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし
【資料公開】プロダクトバックログ Deep Dive
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 今年もスクラム実践者の祭典であるRegional Scrum Gathering Tokyoが、2022年1月5日〜7日までの3日間開催されました。 このイベントで「プロダクトバックログ Deep Dive」というタイトルで発表しましたので、資料を公開します。 スクラムガイドでも、プロダクトバックログという単語の登場回数は非常に多く、それだけ重要だということが分かります。 一方で網羅的にまとまっている資料が日本語ではあまり存在しなさそうなので、今回用意してみました。 内容については、過去にこのブログで説明している箇所も多数ありますが、1箇所にまとめたことに意義があるということでご了承ください。 みなさんのお役に立てば幸いです。 内容に関するご意見やフィードバックは、T
大規模アジャイルフレームワークの紹介
みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ
【翻訳】ハイパフォーマンスチームを作るためにプロダクトオーナーがすべき10のこと
みなさんこんにちは。@ryuzeeです。 スクラムにおいて、スクラムチーム全体のパフォーマンスをどのようにして上げていくかは難しいテーマですが、プロダクトオーナーの視点でこれを捉えた「10 things you must do to build high-performing Scrum Teams as a Product Owner」という記事が良い記事だったので、翻訳したものをご紹介します。 翻訳に際しては、著者のMaarten Dalmijnさんに快諾いただきました。 なお、著者のMaartenさんはほかにもプロダクトオーナーに関する有用な記事を書いているので、参考にするとよいかと思います。 プロダクトオーナーの開発チームへの関わり方は、開発チームのパフォーマンスにおいてとても重要です。ダメなプロダクトオーナーだと、ハイパフォーマンスチームを簡単に潰してしまう可能性があります。 私
【資料公開】マネジメント向けアジャイル開発概要
みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 （スライドはこちらからもご覧いただけます：https://slide.meguro.ryuzee.com/slides/101） 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし
【資料公開】レガシーコードからの脱却
みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
【翻訳】スクラムは抽象クラス
みなさんこんにちは。@ryuzeeです。 スクラムはフレームワークです。ロール、作成物、イベントが決められていますが、それを具体的にどうやってこなしていくのかは定義されておらず、それぞれの環境にあわせてやり方を考えていく必要があります。 それを分かりやすく説明したのが、Scrum is an abstruct classという記事です。 今回、記事を執筆したPaddy Corry氏に快諾いただきましたので、和訳にてご紹介します。 なお、誤解のないように言っておくと、スクラムはアジャイル開発を進める上での唯一のフレームワークでは決してありません。 つまりスクラムのフレームワークで既定されていることを止めた場合、それはスクラムではありませんが、だからといってアジャイルでなくなることとイコールなわけではありません。 自分たちにとって良いやり方があれば、それをやればいいのであって、スクラムに厳格に
【資料公開】Effective DevOps #devopsdaystokyo
みなさんこんにちは。@ryuzeeです。 2018年4月24-25日に実施されたDevOpsDays Tokyo 2018の登壇資料を公開します。 内容自体は、3月に発売になった同名の書籍をベースにしたものになります。ご興味がある方はぜひ書籍をご覧ください。 DevOpsという単語自体は見かけない日がないほど出回っていますが、一方でよくわからないものの代名詞のようなバズワードとも言えます。 DevOpsなるものを導入すれば、組織の課題や問題が全て解決するわけでは決してなく、本当に解決すべきものを自分たちで見つけて、それに取り組まなければいけません。 取り組む上では、チームが機能していることが必須で、そのあたりのことを説明しています。 それでは。 Effective DevOps ―4本柱による持続可能な組織文化の育て方著者／訳者：Jennifer Davis、Ryn Daniels、吉羽
【資料公開】Effective Retrospective (効果的なふりかえり)
みなさんこんにちは。@ryuzeeです。 2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。 登壇の時間が20分ですので基本的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年の本ですがまったく陳腐化していないので参考になると思います。 なにかご質問があればTwitterなどでお知らせください。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
