【資料公開】価値創造と開発生産性
みなさんこんにちは。@ryuzeeです。 2024年6月28-29日に開催の開発生産性Conference 2024で登壇しましたので、資料を公開します。 最近「開発生産性」という言葉を耳にする機会がすごく増えたような気がしますし、自分でもあるメディアの取材で「開発生産性」という単語を使ったのですが、なんとなくスッキリしない感じを抱えていました。 僕自身は「生産性」という単語の不透明さをさけるべく「開発生産性」を使ったのですが、これでも不透明さは残ったままだったわけです。 ということで、「開発生産性」が何を指すのかを深堀りした上で、この単語とどう付き合っていくべきなのかを整理したのが、このセッションです。 スライド全部を読む時間のない方もいると思いますので、以下に結論を書いておきます。 「開発生産性」に関心を持つ理由も、「開発生産性」の定義もさまざま 重要なのはコンテキスト 数字だけで全て
デイリースクラムのTIPS (2016年版)
みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的 2. デイリースクラムの参加者 3. デイリースクラムのタイムボックス 4. デイリースクラムの事前準備 5. デイリースクラムのファシリテーション・進行 6. デイリースクラムのアンチパターン 1. デイリースクラムの目的 スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、
DevOpsトポロジー
みなさんこんにちは。@ryuzeeです。 2021年12月1日に発売した『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』ですが、おかげさまで多くの方に読んでいただき感謝しています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632 今日はこの「チームトポロジー」の元となったDevOpsトポロジーについて紹介します。 このアイデアは2013年に著者の1人であるマシュー・スケルトンが自身のブログに書いた記事をまとめたものです。 2013年頃といえばDevOpsが流行しはじめた時期だと思いますが、こ
【資料公開】スプリントプランニング Deep Dive
みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに
【資料公開】プロダクトオーナーアンチパターン
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
ベロシティの活用方法を教えてください
ベロシティを生産性指標として扱おうとする組織やチームは多いですが、これは間違った考え方です。 生産性には2種類あり、1つが「物的生産性」、もう1つが「付加価値生産性」です。 ベロシティは単位時間あたりのおおよその生産量を示しており、これは前者の「物的生産性」になります。 一方で、スクラムやアジャイルが目指しているのはプロダクトによる成果であり、重視するのは付加価値です。 スクラムにおいて「付加価値生産性」は「プロダクトによる効果 ÷ 投入資源」となり、これは生産量とは関係ありません。 これを踏まえると、ベロシティはスクラムチーム自身が、現状を把握し、今後の見通しや作業計画を考えるために使うことになります。 例えば、以下の用途に使います。 今回のスプリントで、どれくらいのプロダクトバックログアイテムを完成できそうかを予測する残りのスプリント回数を踏まえると、どのくらいのプロダクトバックログア
【資料公開】30分で分かった気になるチームトポロジー
みなさんこんにちは。@ryuzeeです。 2022年3月16日に「チームトポロジーを成功させる実践方法の探求」というイベントで登壇した際の資料を公開します。 セッション内容は、書籍の内容をかいつまんでまとめたものになっており、とりあえずチーム内や社内でチームトポロジーの概要をさくっと押さえるのに使える資料になっていると思います。 スライドを見て興味を持った場合は、是非書籍をご覧ください。紙とKindle版の双方が発売されています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632
【資料公開】目標設定の基本
みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと
【資料公開】価値をすばやく届けるための改善
みなさんこんにちは。@ryuzeeです。 2023年3月3日に開催のイベント「エンジニア文化祭 2023」の登壇資料を公開します。 改善というとすぐにプロセスの変更やツールの導入みたいな話になりがちですが、それだとまずいことが多いです。 ということで、本セッションでは、プロダクトで持続的に価値をすばやく届けるために改善をするときに、どんな切り口でどんなことを考えるとよいかをまとめました。 40分という短いセッションなので、細かいことまでは書ききれていませんが、考え方のヒントになれば幸いです。 忙しい方向けのまとめ アウトカムに注目して改善する プロセス改善だけでは無意味 複数の領域で改善していく（以下はあくまでも例） 問題設定力 たくさん作ることを目的にしない、課題にフォーカス、仮説検証、計測、捨てる…… 開発力 技術に向き合う、練習、継続的なテスト、問題の兆候に継続的に対処、機能横断……
【資料公開】マネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年12月9日に行われたイベント「Developers CAREER Boost」の登壇資料を公開します。 今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました（笑）。 全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。
スクラムチームの開発者は複数チームを兼務してもいいですか？
組織によっては、スクラムチームの開発者が複数チームを兼務することがあります。たとえばAのプロダクトに半分、Bのプロダクトに半分といった具合です。 スクラムではこのような兼務を明示的には禁止していません。 ただしスクラムガイドは「やってはいけないこと」をすべて定めるようなものではなく、最低限の原則と守るべきことを述べたものに過ぎません。 したがって兼務にお墨付きを与えるものではないと理解してください。 その上で、スクラムの5つの価値基準のうちの1つである「集中」を踏まえると、複数チームの兼務は集中を阻害する要因になります。 またスクラムが土台とする「リーン思考」はフローを重視しており、兼務によってフローが阻害されることは間違いありません。 スクラムの理論以外だと、ジェラルド・ワインバーグ氏によると、2つを兼務すると20%のオーバーヘッドが生まれ、3つ兼務すると40%のオーバーヘッドが生まれる
なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか
みなさんこんにちは。@ryuzeeです。 よく受ける相談の1つに、「スクラムチームの開発者は複数のチームやプロダクト、プロジェクトを兼任してもよいのか」というのがあります。コーチ業をしている人ならみんな受けたことがあるものだと思いますが、詳しく見ていきます。 まず最初に結論ですが、タイトルにもあるとおり、「スクラムチームの開発者は複数チームを兼任しないほうがよい」です（スクラムガイドには書いていないですが、スクラムガイドは全てを詳細に記したハウツーではありません。あくまでゲームのルールです）。 理由を順番に見ていきましょう。 1. 開発に使える時間がかなり少ないスクラムチームの開発者はスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントと、プロダクトバックログリファインメントのような活動に一定の時間を使います。 チームによって時間は変わ
ふりかえりをうまくやるコツ
チームはスプリントの間ベストを尽くしたと信じよう最初にファクトデータを集めよう議論するのではなくて、ファシリテーションのテクニックを使ってファクトデータを集めようまずは良い雰囲気を作ろうふりかえりの内容を承認しようこの先改善するためにできることを見つけるためのブレストのセッションを設けよう未来に焦点を当てよう。チームが改善すべき問題とスクラムマスターが改善すべき問題を分離しよう 大事なのは、スプリントの結果はチームとしての結果なのだから、特定個人の問題を追及し（すぎ）ないことです。 チームとしての問題を個人の問題に付け替えてしまうと、個人は問題の隠蔽を始めてしまうケースがあります。 アジャイルの基本理念の1つに「オープンであること」がありますが、それがなくなると、チームとしての力が結集できなくなります。 またふりかえりのファシリテーター役は、チームを非難しないことも大事です。 スクラムマス
新規事業とアジャイル
みなさんこんにちは。@ryuzeeです。 新刊『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』が10月26日に発売になりますので、よろしくお願いします。 先日、プライベートで新規事業とアジャイルに関する短いセッションをしましたので、そのときの資料を共有します （本当は1時間かかるものをかなり縮めたダイジェスト版です）。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）何が分からないのかすら分からないこともある。過度に詳細な計画にしない適切な問題を扱っているか、顧客はいるかが重要顧客が関心を持つのは、自分の課題の解決であり、ソリューションそのものではない仮説と検証の繰り返し急いでたくさん作らない。機能の多さは成功につながらない投資モデルを変える(100打数10安打1ホームランなら上等)アジャイルとはフィードバックサイクルの集合体最初から人が多すぎると
【翻訳】ハイパフォーマンスチームを作るためにプロダクトオーナーがすべき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） 本資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし
スプリント1を始める前にどんな準備をするか
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在するところがスタ
スクラムを1枚で説明する資料7選（2019年版）
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムの全体像を表す絵は多数出回っています。コーチングやトレーニングを生業にしている人であればだいたい何度も作ったことがあるのではないかと思います。 今日はスクラムの全体像を表す絵のうち、比較的新しいものをいくつか集めてみたので紹介します。 見出しの行か画像をクリックすると、それぞれオリジナルを公開しているページにアクセスできます。 The Scrum Framework Poster | Scrum.org ケン・シュエイバーが設立したScrum.orgのサイトで公開されているもの極めてシンプルなので汎用性は高い一方で、スクラムマスター、プロダクトオーナー、開発チームの記述がでて
スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた
みなさんこんにちは。@ryuzeeです。 以前書いたスクラムマスターを雇う時に聞いてみるとよい38個の質問という記事に対して、自分も答えてみましたので、以下で紹介します。 なお、既に38個答えた勇者がいるのでこちらも併せて読んでみるとよいと思います。 「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えた@katzchang/回答-スクラムマスターを雇う時に聞いてみるとよい38個の質問それでは、行ってみましょう。 スクラムマスターの役割についてアジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？スクラムマスターの関与の度合いはチームの力量や規律の有無、外部との関係性などによって変わります。 チームが自分で解決できない大きな問題をかかえていたり、チームとして機能していなかった
【資料公開】スクラムチームは改善する問題を正しく選んでいますか？
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 2019/2/22-23に行われたSCRUM FEST Osakaの登壇資料を公開します。 プロダクトを作るのは、一般的には、儲けるためであることがほとんどです。 つまり、「うまく作る・たくさん作る」ことよりも「成果を出す」ことにフォーカスするのが良いと考えています。 成果を形にするには、開発力が必要で、開発力をあげようと思ったら、継続的な投資と学習が必要になります。 社会学的な話も重要ですが、現状では言い訳としても使われていることも多いため、いまいちど本当の問題が何なのかを考えてみることをお勧めします。 それでは。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
