短い間隔で動作するソフトウェアを見せようとするとすべてが改善される
みなさんこんにちは。@ryuzeeです。 今回は、自称「アジャイル開発をしている」といいつつ、定期的に謎の進捗報告会をJiraで行ない、「効率がどうたら」と口癖のように言っている人たちへの説教です。 スクラムでもスクラムでないやり方でも何でも構わないのですが（その違いは大きな問題ではない）、動作するソフトウェアを定期的に披露しようとすると、さまざまな改善が芋づる式に進みます。 披露しようとすれば、一気通貫で動作し、目で見て分かり、評価可能ものを作ることになります。 部品だけを作っても見えないし分かりません。例えばUIモックだけを作っても実際の操作感は分かりません。 何より動かないものや触れないものは真剣に見ません（モックを事前に送付してコメントがさして無かったのに、実物を見せたら大量にあーだこーだ言われた経験を持つ人は多いでしょう）。 一気通貫で見えるものを提示しようとすれば、短い期間で色
【資料公開】価値創造と開発生産性
みなさんこんにちは。@ryuzeeです。 2024年6月28-29日に開催の開発生産性Conference 2024で登壇しましたので、資料を公開します。 最近「開発生産性」という言葉を耳にする機会がすごく増えたような気がしますし、自分でもあるメディアの取材で「開発生産性」という単語を使ったのですが、なんとなくスッキリしない感じを抱えていました。 僕自身は「生産性」という単語の不透明さをさけるべく「開発生産性」を使ったのですが、これでも不透明さは残ったままだったわけです。 ということで、「開発生産性」が何を指すのかを深堀りした上で、この単語とどう付き合っていくべきなのかを整理したのが、このセッションです。 スライド全部を読む時間のない方もいると思いますので、以下に結論を書いておきます。 「開発生産性」に関心を持つ理由も、「開発生産性」の定義もさまざま 重要なのはコンテキスト 数字だけで全て
【資料公開】ステークホルダーとの付き合い方を考える
みなさんこんにちは。@ryuzeeです。 2024年6月3日に行われたソニー主催、Forkwell共催の勉強会「TechLovers #2」の登壇資料を公開します。 プロダクト開発には、さまざまなステークホルダーが登場します。 プロダクトのフェーズや開発の状況によってステークホルダーの重要度は変わります。そしてステークホルダーごとに持っている権限の強さや権限が及ぶ範囲も違います。 これらを無視して開発を進めると、プロダクトに大きな影響を及ぼすようなことが起こりかねません（メテオフォールなるものもその1例です）。 つまり、戦略的にステークホルダーと付き合っていかなければいけません。 この資料では、フレームワークを活用してステークホルダーを分類し、分類に応じた接し方を紹介しています。 プロダクト開発においては、常にやりたいことややらなければいけないことがたくさんあり、時間や人は足りません。 そ
アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバック
【資料公開】ベロシティ Deep Dive
みなさんこんにちは。@ryuzeeです。 2024年1月10日〜12日開催のRegional Scrum Gathering Tokyo 2024の登壇資料を公開します。 「ベロシティ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。 プロダクトバックログ Deep Dive スプリントプランニング Deep Dive スプリントレビュー Deep Dive セッション資料は以下になります。 結論から言うと、「ベロシティなんかにDeep Diveせず、もっと重要なところに集中しろ」です。 スクラムチームの状況を何らかの数値で表したいという考え自体は尊重しますし、それが役に立つこともあります。 ただし、数字遊びをしたところでプロダクトの価値を生み出せるわけではないので、ほどほどにしましょう。 ス
スクラムにおいて開発者を社外から集めるとどんな問題がありますか？
開発者を社外から集めるというのは大きく分けると2つです。 開発をまるごと別の会社にやってもらう（別の会社に発注する）さまざまな会社から派遣やSESで来てもらったりフリーランスの方にチームに入ってもらったりするどちらの形態なのかによって多少の違いはありますが、以下のような問題が起こりやすいです。 開発のノウハウや暗黙知が永続しない（暗黙知をすべて形式知化することはできないので、どこかで失われてしまう）外部から参画しているメンバーは必ずしもプロダクトの成功に対するインセンティブがない。そのためプロダクトのアイデアや改善のアイデアがあまり出ないこともある（もちろんメンバーによる。ただし全員がコミットすることを期待するのは無理）発注者がプロダクトオーナーをすると、プロダクトオーナーが考えたことを開発者に伝え、開発者は言われたとおりのものを作るだけという構図になりがち新規に開発を始めるたびにチームビ
【資料公開】プロダクトオーナーアンチパターン
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
【資料公開】価値をすばやく届けるための改善
みなさんこんにちは。@ryuzeeです。 2023年3月3日に開催のイベント「エンジニア文化祭 2023」の登壇資料を公開します。 改善というとすぐにプロセスの変更やツールの導入みたいな話になりがちですが、それだとまずいことが多いです。 ということで、本セッションでは、プロダクトで持続的に価値をすばやく届けるために改善をするときに、どんな切り口でどんなことを考えるとよいかをまとめました。 40分という短いセッションなので、細かいことまでは書ききれていませんが、考え方のヒントになれば幸いです。 忙しい方向けのまとめ アウトカムに注目して改善する プロセス改善だけでは無意味 複数の領域で改善していく（以下はあくまでも例） 問題設定力 たくさん作ることを目的にしない、課題にフォーカス、仮説検証、計測、捨てる…… 開発力 技術に向き合う、練習、継続的なテスト、問題の兆候に継続的に対処、機能横断……
意識の問題にしない
みなさんこんにちは。@ryuzeeです。 今日はTwitter経由で頂いた質問に回答したいと思います。 質問は以下になります。 スプリントで『自分が最初に取り組むプロダクトバックログアイテム（PBI）を終わらせば自分の仕事は終わり』という意識のメンバーが多いです。そのため、PBI每に担当を決めて複数のPBIを並列で進めているのですが、インクリメントが0になる可能性があるのでできればやめたいと思っています。スプリントプランニングで決まったPBIすべてをチームで協力して終わらせるという意識に変えるためにはどうしたらよいでしょうか？ 例えば、AさんとBさんとCさんが最初にPBI-1をやる場合、スプリントでPBI-1を終わらせればよい、PBI-2とPBI-3は自分たちのタスクではないという意識になってしまっているという感じです。 ということで考えていきましょう。 スプリントでの開発者の仕事は何か？
【資料公開】目標設定の基本
みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと
プロダクトバックログアイテムの粒度の考え方
みなさんこんにちは。@ryuzeeです。 今日はTwitter経由で頂いた質問に回答したいと思います。 質問は以下になります。 プロダクトバックログアイテムの粒度について教えてください。 ECサイトだとして、「購入者が販売商品を購入できる」というユースケースの場合、PBIに入れるユーザーストーリーとしては、「購入したい商品を検索し商品を確認できる」「購入したい商品を買い物カゴに入れる」「買い物カゴの商品を購入する」のような粒度で良いのでしょうか？ それとももっと細かいレベルまで分割すべきでしょうか？「購入者は購入したい商品の値段を確認できる」とか「購入者は購入したい商品の名称を確認できる」みたいなレベル感でしょうか？ 複数画面をまたがり使用するデータベーステーブルはいつ決めてどうストーリーポイントを決めるのでしょうか？ それでは考えていきましょう。 1つのプロダクトバックログアイテムを複数
【資料公開】スプリントレビュー Deep Dive
みなさんこんにちは。@ryuzeeです。 2023年1月11日-13日に開催のイベント「Regional Scrum Gathering Tokyo 2023」の登壇資料を公開します。 スプリントレビューは非常に重要なイベントです。 5つのイベントのなかでいちばん重要なイベントを選べと言われたら、僕はスプリントレビューを選びます。 スクラムはプロダクトを届けるためのものであり、プロダクトを成功させるにはプロダクト自体の検査と適応が必須だと思うからです。 一方で、スプリントプランニングの精度を上げようと頑張る割にスプリントレビューが雑に扱われる例が多くて懸念していました。 ということで、本セッションでは、スプリントレビューの目的や参加者、進め方、コツなどを深掘りしてみました。 みなさんの参考になれば幸いです。 忙しい方向けのまとめ スクラムチーム全員が参加しろスクラムチームの外側のステークホ
【資料公開】マネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年12月9日に行われたイベント「Developers CAREER Boost」の登壇資料を公開します。 今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました（笑）。 全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。
チームの状況を把握するための5つの質問
みなさんこんにちは。@ryuzeeです。 アジャイルコーチでもスクラムマスターでもエンジニアリングマネージャーでも、新しいチームと一緒に働くことになった場合にまず必要なのが情報収集です。 チームの様子を観察したり、1on1で聞いてみたり、ドキュメントを読んでみたりとさまざまな方法があります。 そこで、今回は直接チームのみんなに話を聞いて情報収集する場合に、5個だけ質問できるとしたら何を聞けばよいか考えてみました。 まず、初期の段階では、単に開発プロセスがうまく回っているかどうかだけを聞いてもあまり意味がありません。 そこでプロダクト、意思決定の方法、デリバリー、改善、チームのことを聞いてみようと考えてできたのが、以下の5つの質問です。 プロダクトは顧客の課題解決に役立っていますか？役に立つかどうか、役に立っているかどうかをどうやって確かめていますか？いま開発している機能は誰にとってどう役に
【資料公開】エンジニアリングマネージャーのしごと
みなさんこんにちは。@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年8月26日に、新刊『エンジニアリングマネージャーのしごと チームが必要とするマネージャーになる方法』が発売になります。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法著者／訳者：James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙出版社：オライリージャパン発売日：2022-08-26単行本（ソフトカバー）：376ページISBN-13：9784873119946ASIN：4873119944 原著はDr. James Stanier氏の『Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Need
【翻訳】あなたのスクラムチームの成熟度は？
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 3月23日に『スクラム実践者が知るべき97のこと』が発売になりますのでよろしくお願いします。 さて、スクラムチームがどれくらいの成熟しているかは、とくにスクラムを始めてまだ長時間たっていない場合には気になるところだと思います。 そこで今回はスクラムチームの成熟度を自己評価して、改善に結びつけるための資料を共有します。 この資料はScrum.orgのトレーナーであるRon Eringa氏がブログで公開しているものです。 このモデルでは、スクラムマスター、プロダクトオーナー、開発チーム（スクラムガイド2020で開発者に改められています）のそれぞれで成熟度を明らかにします。 そして、全体で
アジャイルコーチはObsidianをどのように使っているか
みなさんこんにちは。@ryuzeeです。 2022年6月2日に行われたイベント「#Obsidian 使っているんでちょっと話します」で、最強のノートアプリであるObsidianについてちょっとだけ話をしてきたので、資料を公開しておきます。 以下は話の内容です。スライドと同じ内容なので忙しい方はスライドだけどうぞ（ここから先にアジャイルの話はありません）。 仕事の内容ぼくはアジャイル関連のコーチングやトレーニングの提供、顧問業を仕事にしています。 開発の仕事やコンサルティングファームの仕事とは違って、複数のお客様に対して同時並行（おおよそ週1回くらい）でサービスを提供するような形です。 内容は多岐に渡っていて、個別チームのコーチングを継続的に行うこともあれば、アジャイル関連のよろず相談を受けることもあれば、1on1を行うこともあります。 これに加えて、認定スクラムマスター研修や、その他の研修
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
