Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Scrum Gaiyo 2
Search
Yasunobu Kawaguchi
PRO
September 08, 2021
Technology
1
640
Scrum Gaiyo 2
SQiP Tutorials
Yasunobu Kawaguchi
PRO
September 08, 2021
Tweet
Share
More Decks by Yasunobu Kawaguchi
See All by Yasunobu Kawaguchi
Creative Pair
kawaguti
PRO
1
150
Women in Agile
kawaguti
PRO
4
200
I could be Wrong!! - Learning from Agile Experts
kawaguti
PRO
7
4.3k
Replit Agent
kawaguti
PRO
2
660
Mobbing Practices
kawaguti
PRO
3
490
RSGT Walk Through
kawaguti
PRO
6
1.8k
XP matsuri 2024 - 銀河英雄伝説に学ぶ
kawaguti
PRO
3
920
1Q86
kawaguti
PRO
2
460
Shinagile 2024
kawaguti
PRO
3
200
Other Decks in Technology
See All in Technology
インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて
nwiizo
5
2.1k
第13回 Data-Centric AI勉強会, 画像認識におけるData-centric AI
ksaito_osx
0
360
PL900試験から学ぶ Power Platform 基礎知識講座
kumikeyy
0
110
AWSでRAGを実現する上で感じた3つの大事なこと
ymae
3
1k
Platform Engineeringは自由のめまい
nwiizo
4
1.9k
Fintech SREの挑戦 PCI DSS対応をスマートにこなすインフラ戦略/Fintech SRE’s Challenge: Smart Infrastructure Strategies for PCI DSS Compliance
maaaato
0
450
The 5 Obstacles to High-Performing Teams
mdalmijn
0
270
Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)
legalontechnologies
PRO
0
150
5分で紹介する生成AIエージェントとAmazon Bedrock Agents / 5-minutes introduction to generative AI agents and Amazon Bedrock Agents
hideakiaoyagi
0
220
日経電子版 x AIエージェントの可能性とAgentic RAGによって提案書生成を行う技術
masahiro_nishimi
1
290
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
1
1k
現場の種を事業の芽にする - エンジニア主導のイノベーションを事業戦略に装着する方法 -
kzkmaeda
2
1.5k
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Become a Pro
speakerdeck
PRO
26
5.1k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
It's Worth the Effort
3n
184
28k
Visualization
eitanlees
146
15k
Fireside Chat
paigeccino
34
3.2k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Building an army of robots
kneath
302
45k
Transcript
スクラム概要 がい よう
上位下達型の組織 チーム中心の組織
上位下達型の組織 教育リソースが限られている場合に、 必要なトップ層を中心に教育を行い、 部下の指導を通じてユニバーサル サービスを実現した。ルールを守って 適切に。目標達成と信賞必罰によって コントロール。 チーム中心の組織 実務者によって顧客やユーザーへの サービスが行われている、組織界面に
必要なリソースを集める組織。教育リ ソースが十分に行き渡っている専門家 を現場に。マネジメントは現場を支援 するためにある。
上位下達型の組織は歴史上の必然 通信手段も教育リソースも限られた中で、 いかに全体を組織として機能させるのか? 人類はここをずっと追い求めてきた。 世代を超えて、大規模な統治をするために、 人間本来の能力以上に、統治者として のシンボルが必要になった。 権威、武力、教義、秩序、規律、報酬などで コントロールを行った。
https://speakerdeck.com/kawaguti/hagechabin はげちゃびん = 技術のわからない 管理者や経営層 「マリー・ アントワネット問題」 と言い換えたい昨今。
https://speakerdeck.com/kawaguti/hagechabin
https://speakerdeck.com/kawaguti/hagechabin
上位下達型の組織 教育リソースが限られている場合に、 必要なトップ層を中心に教育を行い、 部下の指導を通じてユニバーサル サービスを実現した。ルールを守って 適切に。目標達成と信賞必罰によって コントロール。 チーム中心の組織 実務者によって顧客やユーザーへの サービスが行われている、組織界面に
必要なリソースを集める組織。教育リ ソースが十分に行き渡っている専門家 を現場に。マネジメントは現場を支援 するためにある。
しかし、もし私が一つの教訓を選ぶとしたら、 他の何よりも多くの組織が失敗していると思うことは、 グループサイズです。リチャード・ハックマンの言葉を 借りれば、チームが5,6,7,8人よりも大きくなり、 10人近くになると、物事が本当に悪くなるという 証拠がたくさんあります。 基本的には、10人、あるいは11人になると、 調整のための雑務に費やす時間が増え、 実際に仕事をする時間が減っていきます。 もう1つは、人間関係の問題が発生することです。
ディナーに行って10人、11人と会話をするのは 不可能に近いですよね。 ロバート・サットン スタンフォード大学経営学部教授
スクラムの源流 https://www.infoq.com/presentations/The-Roots-of-Scrum/
https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムの源流 • チームプロセス – シリコンバレーの起業家たち • 竹内・野中 – 日本の製造業
• 世界をもっとよい場所に – 内なるビジョン • オブジェクト技術とEasel社のSmallTalkプロダクト • オブジェクト指向アーキテクチャ 設計ツールの専門家、ベンダー、顧客 • 進化生物学と複雑適応系 • プロセスと生産性の研究 • ソフトウェア生産性の研究 • 外科手術チーム(人月の神話, IBM) • 邪悪な問題、正しい解決 • ボーランド Quattro Pro プロジェクト • iRobot -サブサンプション・アーキテクチャ
https://agilemanifesto.org/ アジャイルマニフェスト
https://agilemanifesto.org/ アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 https://agilemanifesto.org/iso/ja/manifesto.html
https://agilemanifesto.org/principles.html アジャイル宣言の背後にある原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げま す。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 https://agilemanifesto.org/iso/ja/principles.html
https://agilemanifesto.org/principles.html 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 https://agilemanifesto.org/iso/ja/principles.html
https://kawaguti.hateblo.jp/entry/20110213/1297531229 私たちはすぐに、 それぞれ推奨しているもの同士が とても似通っているのは偶然ではない、 という結論に至った。 そこには何か根底に流れる共通性があり、 それが何であるかを 見つける必要があると思われた。 なぜなら、日々や分単位のプロジェクトの進め方には、 食い違っている点があり、まだ解消していなかったからだ。
このような食い違いがあるにもかかわらず、 私たちには「私たち以外の人々とは違う」と言える、 とても強い共通性が存在した。
スクラム、 リーンは 日本の製造業から 影響を受けている
https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタウェイ : Learn by Doing 張富士夫 : 代表取締役社長 2002
• 私たちが一番重視するのは、実際に実践し、 行動すること アジャイル原則#1 • わかっていないことはたくさんある。だから 「とにかくまずやってみよう」アジャイル原則#3, #11 • 自分の知識の少なさに気づき、自分の失敗に 直面して、もう一度やり直し、2回目の試行で また別の失敗に気づく。そしてもう一度やり 直す。アジャイル原則#11, #12 • 絶え間ない改善によって、より高いレベルの 実践と知識に至る。アジャイル原則#3
竹内野中論文(1986)が示した マネジメントスタイル • Type A NASAのウォーターフォール型 • 要求、分析、設計、実装、試験と、 順に次の工程の部署に引き渡される •
Type B 富士ゼロックスのサシミ型 • 前工程と後工程が同席する • Type C ホンダのスクラム型 • 一時は全工程が同席する Jeff SutherlandはこのType Cから、 自らのフレームワークの名前を とった。 https://www.infoq.com/presentations/The-Roots-of-Scrum/
コマンド&コントロールを打ち破る • 旧来の企業では、戦略は中央で作られる • それぞれの現場で、創発的な戦略が自己 組織される • 分散化された認知とアクション • スクラムチームは、
自己組織化を許されなければならない • 自働的 Autonomous • 卓越的 Transcendent • 他家受粉 Cross-fertilization • チームは自らの仕事を選択する • それぞれの個人は自らの仕事を管理する • マネジメントを排除する 竹内野中 https://www.infoq.com/presentations/The-Roots-of-Scrum/
https://www.infoq.com/presentations/The-Roots-of-Scrum/ 多様な観点 • 職能横断チーム (クロスファンクショナル) • スクラムチームは(すべての職能を)持つ。 プロダクトの知識、業務分析、UIデザイ ン、ソフトウェアエンジニア、品質保証 •
さらに進んだスクラムではもっとステー クホルダーを巻き込む ー 経営陣、顧客、 インストール担当、サポート担当
https://www.infoq.com/presentations/The-Roots-of-Scrum/ プリウスプロジェクトチームは 「場」をマネジメントした • リーダーは偶然場を「見つけて」活用す ることができる • リーダーは話し合える空間を提供して 場を作れる •
会議室などの物理的な空間 • コンピュータネットワークなどの電脳空間 • 共通のゴールなどの心理的な空間 • 愛、いたわり、信頼、責任感※ が知識創造 の基礎を作る(自己組織化) • スクラムは、真実、透明性、責任感※ の上 に立つ ※Commitmentは、スクラムガイドでは 確約と訳されています。
プロダクト バックログ 顧客が求める機能の 優先順位付きリスト スプリントバックログ スプリント内で完成させる機能 機能をより小さなタスクに分解する 新しい機能 スプリントの 終わりにデモする
毎日15分のミーティン グを行う。 スクラムマスターは3 つの質問をする 1)昨日なにを達成しま したか? 2)ゴールを満たすため に障害になっているの は? 3)明日までになにをた 達成しますか? https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムスプリントサイクル
トヨタウェイは 冗長性と失敗を許容する • 生物の進化のような創発的プロセスでは、 失敗が生まれる • 早めに失敗し、頻繁に失敗して、 素早く学習し、急速に進化する • 創発的なソリューションに向けた、
合理的で効果的なアプローチは、 大事故を引き起こす https://www.infoq.com/presentations/The-Roots-of-Scrum/
不確実性が要求する 経験主義的プロセスコントロール • 入力 • 要件 • 技術 • チーム
• 制御 • プロセス • 出力 • 漸進的にプロダクトが変化 https://www.infoq.com/presentations/The-Roots-of-Scrum/
世界最初のスクラム – Easel社1993 • ガントチャート禁止 • 役職名禁止 • スクラムマスターを作る •
プロダクトオーナーを作る • 自己組織化を生み出すデイリーミーティン グ • スプリントの間は外部からチームを隔離 • スプリントプランニング、スプリントレ ビュー、レトロスペクティブ • どんな技術プラクティスを使う不明だった • 初期のXPの技術プラクティスを使った https://www.infoq.com/presentations/The-Roots-of-Scrum/
https://www.infoq.com/presentations/The-Roots-of-Scrum/ 主要な役割(ロール)と責務 • プロダクトオーナー • プロダクトの機能、リリース日と内容を定義する • プロダクトの収益性(ROI)に責任を持つ • 市場価値に即して機能の優先順位をつける
• 30日ごとに機能と優先順位を変更可能 • 仕事の結果を受け入れる/却下する • スクラムマスター • チームが機能し、生産的であるようにする • 役割や職能間で緊密に協力するようにし、障壁を取 り除く • 外部から入る邪魔からチームを守る • プロセスを守られていることを確認する。デイリー スクラム、レビュー、プランニングのミーティング に人々を招く • チーム • 職能横断的な、7±2人のメンバー • スプリントのゴールを選び、成果物の仕様を決める • スプリントのゴールを達成するために、プロジェクトのガ イドラインを守る限り、何でもやる権利がある。 • やり方と結果を自ら決める • プロダクトオーナーに成果をデモする
https://www.infoq.com/presentations/The-Roots-of-Scrum/ 主要な役割(ロール)と責務 プロダクトオーナー • プロダクトの機能、リリース日と内容を定義する • プロダクトの収益性(ROI)に責任を持つ • 市場価値に即して機能の優先順位をつける •
30日ごとに機能と優先順位を変更可能 • 仕事の結果を受け入れる/却下する
https://www.infoq.com/presentations/The-Roots-of-Scrum/ 主要な役割(ロール)と責務 スクラムマスター • チームが機能し、生産的であるようにする • 役割や職能間で緊密に協力するようにし、 障害を取り除く • 外部から入る邪魔からチームを守る
• プロセスを守られていることを確認する。 デイリースクラム、レビュー、プランニングの 各ミーティングに人々を招く
https://www.infoq.com/presentations/The-Roots-of-Scrum/ 主要な役割(ロール)と責務 チーム (開発者) • 職能横断的な、7±2人のメンバー • スプリントゴールを選び、成果物の仕様を決める • 同ゴールを達成するため、プロジェクトのガイド
ラインを守る限り、何でもやる権利がある。 • やり方と結果を自ら決める • プロダクトオーナーに成果をデモする
https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムを進化させる Type A, B, Cのスプリント • Type A スプリントで部分的なものしか
作れないかもしれない • Type B 徐々にオーバーラップさせる • Type C すべてを一つのチームで 自分たちのやり方を現地現物で見つめ、 自分たちで進化させていくのがスクラム。 自分で考えるメンバーを作り、守り、鍛えていく。
ハイキュー!! 14巻より • 烏野高校の精神的支柱であり、 守備の要(かなめ)である主将の 負傷退場の穴を埋める、 二年生のリーダー。 • スキルも経験も統率力も主将には 遠く及ばない、レギュラーでもない
ことを自認しながら、チームのために 尽くした。 • 基本を思い出すこと。練習の通りに やること。全員がベストを尽くすこと。 自分で考えること。 「バタバタしない。 良いジャンプは、良い助走から。」
上位下達型の組織 教育リソースが限られている場合に、 必要なトップ層を中心に教育を行い、 部下の指導を通じてユニバーサル サービスを実現した。ルールを守って 適切に。目標達成と信賞必罰によって コントロール。 チーム中心の組織 実務者によって顧客やユーザーへの サービスが行われている、組織界面に
必要なリソースを集める組織。教育リ ソースが十分に行き渡っている専門家 を現場に。マネジメントは現場を支援 するためにある。
https://scrumguides.org/ スクラムの定義のアップデート 『スクラムガイド』 • コミュニティの意見を採り入れて わかりにくい表現をなくしたり、 必須のルールのみを残して、 ベストプラクティスは外し、 ルールブックとして再定義 •
2020年版で主要なワードが大きく 変わったので、認定を受ける方や 最新の動向を確認したい人は 読んでみてください。
スクラムマスター プロダクトオーナー 開発者(たち)
プロダクトオーナー • プロダクトのビジョンを持ち、育てる。 • ビジョンを達成するためのロードマッ プを考え、提示する。 • 開発チームと協力して、着手可能な仕 様としてプロダクトバックログを作成 する。
• ステークホルダーやエンドユーザーと 話す。 • 予算を確保する。 • ROIが高くなるようプロダクトバック ログの優先順位をつける。
• 自己組織化して仕事を進める。 • 全員がプロダクトに貢献する。 • 必要な能力をチーム全体でカバーする。 • プロダクトバックログを理解し、 優先順位に従って出荷判断可能な プロダクトインクリメントを仕上げる。
• プロダクトバックログの各項目に サイズの見積もりをつける。 開発者(たち)
スクラムマスター • スクラムのプロセスがうまく機能する ように、あらゆる手を尽くす。 • チームの集中を妨げる妨害を排除する。 • チームの行く手を阻む障害を取り除く。 • チームに改善をそそのかす。
• チームの自己組織化を尊重する。 • プロダクトオーナーが機能していない ときは、指導する。 • 指示しないサーバントリーダー。
プランニング スプリント (作業時間) レビュー レトロスペ クティブ スプリント
プランニング • プロダクトバックログを理解する。 • バックログ項目はチームが見積もる。 • チームの実力(ベロシティ)からみて、 どこまで行けそうかを測る。 • 行けそうなところまでのバックログアイ
テムを完成させるために、チームがどう 動くかを考える。 • よく考えたらダメっぽいなら、もう ちょっと減らす。
スプリント (作業時間) • 集中して仕事をする。 • プロダクトバックログの順番通りに 完成させる。 • やり方はチームが考え、自律して進める。 •
なるべく多くのバックログアイテムを 出荷判断可能にする。 • どうやると終わるか(完成の定義)は だんだん拡張する。 • 毎日同期し、再計画する = デイリースクラム
レビュー • 動くソフトウェアを利害関係者に デモする。 • 利害関係者に意見をもらう。 • できなかったことがあれば報告する。 • 技術的負債について話す。
• ロードマップを俯瞰する。 • マーケットの状況を共有する。 • 追加バックログ項目があれば足す。 • この方向で進めることを合意する。
レトロスペ クティブ • なにをやったか話す。 • レビューでどんな意見が 返ってきたか話す。 • 技術的負債について話す。 •
よかったことや反省点を話す。 • どうしたらもっとよくなるか話す。 • 困ったことがないか聞く。 • アイデアがあれば出す。
ToDo WIP Done プロダクト バックログ スプリント バックログ 障害リスト
プロダクト バックログ • 優先順位付けされた機能や対応項目のリスト。 何を提供するか(What)。 • ROIが最も高まるように優先順位付けされ、 開発チームは上から順に届ける。 • 各項目の規模は開発チームが見積もる。
• スプリントで完成した項目の規模の合計が ベロシティ。次も同じくらいいけると考える。 • 開発チームはスプリントごとに、 どうやって実現するか(How)を考え、 スプリントバックログに落とし込む。
ToDo WIP Done スプリント バックログ • スプリントごとに、チームが作成し たタスクリスト。 • プロダクトバックログの上位の項目
を優先順位に従って届けるための、 開発チームの作業リスト。 • 完成の定義を守る。 技術的負債を溜めない。解消する。 • チームはタスクに群がって作業し、 アグレッシブに終わらせていく。
障害リスト • チームの進行を妨げる障害をリストにする。 スクラムマスターにとってのバックログ。 • デイリースクラム、レトロスペクティブ などで発見され、まずチームが解決する。 • だれにとってもオープン・正直に。 •
障害は誰のせいでもない。解決できそうな 課題だけを出すような忖度はしない。 • 障害を一歩一歩取り除いていく。 = 改善 • 解決できないときは組織の問題として 助けを求める必要があるかもしれない。
アジャイルな見積りと計画づくり スクラム普及の立役者の一人、 マイク・コーンのプランニングに 関する名著。 なぜ時間ではなくポイントで見積も るのか?なぜ私たちは計画に失敗す るのか?プロダクトバックログや、 プランニングポーカーに関して最も 詳しく論じられている。 スクラム
ジェフ・サザーランド博士がいかに してスクラムにたどり着いたのか、 詳細に語られた一冊。ジャーナリス ト出身の息子、JJサザーランドが 大きく貢献をしている。ビジネス書 としてスクラムを押さえるために重 要な一冊。野中・竹内論文にどのよ うに出会ったのかも、細かく書かれ ている。 スクラム現場ガイド スクラムアライアンスの初期の マネージングディレクターであ るケン・ルービンの包括的な スクラム解説書。分厚く、詳細 に書かれている。 エッセンシャルスクラム スクラム適用を長年行ってきた ミッチ・レイシーによる 現場で起こる問題に対応する 実戦的なガイドブック。 ScrumMaster the Book 薄い本だが、スクラムマスター の長い道のりを論じている。ま ずチームのコーチングやメンタ リングを行うこと。チーム運営 の罠はどこにあるか。チームを 越えた組織開発の必要性。