Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
スクラムチームと認知負荷 - ニフティのスクラムトーク Vol2. / NIFTY Tech ...
Search
ニフティ株式会社
PRO
March 29, 2024
Video
Resources
Programming
350
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
スクラムチームと認知負荷 - ニフティのスクラムトーク Vol2. / NIFTY Tech Talk #18
ニフティ株式会社
PRO
March 29, 2024
Video
Resources
スクラムマスターによるチーム改善LT! ニフティのスクラムトーク vol 2
https://nifty.connpass.com/event/313136/
More Decks by ニフティ株式会社
See All by ニフティ株式会社
microCMS移行をいまならAIでどう進めるか - microCMS Meetup 2026
niftycorp
PRO
0
490
Embedded SREと共に達成した会員管理システムのAWS移行 - SRE NEXT 2026 ランチスポンサーセッション
niftycorp
PRO
1
4.1k
ニフティ株式会社 エンジニア向け Company Deck 2026年版
niftycorp
PRO
0
1.2k
「なぜそう決めたのか」を残し続ける仕組み ― Notion AI カスタムエージェント × Slack連携による設計判断の自動記録 - NIKKEI Tech Talk #47
niftycorp
PRO
0
380
CS教育のDX AIによる育成の効率化
niftycorp
PRO
0
420
AI 開発合宿を通して得た学び
niftycorp
PRO
0
420
なぜISPでオリジナルカードゲームを作ったのか?制作者と対談 - NIFTY Tech Talk #25
niftycorp
PRO
0
140
「なぜかネットが遅い」を“見える化”する 〜マイ ニフティが繋ぐサポートと暮らし〜 - NIKKEI Tech Talk #39
niftycorp
PRO
0
690
InnerSource Summit 2025 Three points that promoted innersource activities
niftycorp
PRO
0
360
Other Decks in Programming
See All in Programming
難しいけど、読めた。- OSSの入口に立った話。
sts11142
0
110
Intent as Code
shoppingjaws
6
1.1k
大喜利で理解するLLM as a Judge / Understanding LLM-as-a-Judge through Ogiri
rockname
0
150
一人だけ、Kiroが静止する日
hideg
0
120
WebRTC映像をAirPlayに対応させる挑戦.pdf
monolithic_adam
0
290
モデルのリファクタリングが難しいと思ったら、そもそも複雑だったのはビジネス仕様だった ? / is-the-business-domain-the-real-complexity
hatsu38
0
380
ハーネス設計入門 〜 基礎知識の整理から実務へのステップアップ 〜
kinopeee
12
10k
アクセシビリティから考える情報設計
high_g_engineer
0
380
MVNOの申込からeSIM開通までをiOSアプリでつなぐ- 本人確認・MNP・通信事業者基盤をまたぐ実装
satotakeshi
0
460
そのリトライ、死んだコネクションを使い回していませんか ── GoのHTTPクライアントとHTTP/2を実プロダクト障害から学び直す
myus4a
0
210
Streamlitで実現する自然言語データアプリ開発
ayumu_yamaguchi
1
310
What We Talk About When We Talk About XP
m_seki
2
670
Featured
See All Featured
Tell your own story through comics
letsgokoyo
1
1.1k
Odyssey Design
rkendrick25
PRO
2
810
Believing is Seeing
oripsolob
1
220
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
340
New Earth Scene 8
popppiees
4
2.6k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.2k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
330
A Soul's Torment
seathinner
8
3.6k
Agile that works and the tools we love
rasmusluckow
331
22k
Paper Plane
katiecoart
PRO
4
53k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Transcript
Copyright © NIFTY Corporation All Rights Reserved. スクラムチームと認知負荷 Team
Topologies から認知負荷への向き合い方について考える
Copyright © NIFTY Corporation All Rights Reserved. 2 自己紹介
職種と企業を飛び越えたNTT Comとの新規ビジネス共創【NIFTY Tech Day 2023】 https://www.youtube.com/watch?v=qU3DT5C3BsU NIFTY Tech Talk #4 レガシーシステムからの脱却 https://www.youtube.com/watch?v=Ttium-UNEEU 清水 利音 Shimizu Rion 顧客管理システムやシングルサインオンシステムなど 会員基盤系を担当するチームの SM を担当 ニフティ株式会社 基幹システムグループ 過去の登壇
Copyright © NIFTY Corporation All Rights Reserved. 1. 組織構造は暗黙的に現行のマネージャーと専門家の役職
や権限が変わらないように最適化されています。 2. 1の影響により、変化を起こす提案は、元の状態が再定 義される、もしくは新しい用語が乱用されることにな り、結果的に元々の状態と変わらない状態になります。 クレイグ・ラーマンの法則 (抜粋) https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior 3 https://scrummaster.jp/larmans-laws-jp/
Copyright © NIFTY Corporation All Rights Reserved. • 1つのプロダクトに1つのスクラムチーム
• プロダクトのビジョンに責任を担う PO • スクラムチームの環境整備を行う SM • 機能横断的で自己管理されているチーム 教科書どおりのスクラムを実践できていますか? 4
Copyright © NIFTY Corporation All Rights Reserved. • 1つのチームが複数のプロダクトを兼任している
◦ 複数人の PO、ないしは PO が不在のプロダクト ◦ バックログの衝突、渋滞 • SM がマネージャーやリーダーロールを兼任している • 絶対的な締め切りや外からの圧力により、 チームの開発に対する権限が失われている よくありそうなケース 5
Copyright © NIFTY Corporation All Rights Reserved. • もっと上のレイヤー、組織的な問題が多そう?
◦ 既存の組織のままスクラムを導入した ◦ チームが生み出す価値とはいうが、評価は個人単位 だし・・・ • とはいえボトムアップで変えるためにはどうすれば ・・・? チーム内の状態がどうこうというより・・・ 6
Copyright © NIFTY Corporation All Rights Reserved. 7 Team
Topologies からヒントを得たい
Copyright © NIFTY Corporation All Rights Reserved. 8 Team
Topologies とは? • Dev/Ops 組織について、組織設計やチームの 相互作用についてのモデルをした 体制構築手法 • 4つのチーム形態、3つのコラボレーションと コンパクトに整理されている Team Topologies: Organizing Business and Technology Teams for Fast Flow Matthew Skelton, Manuel Pais 2019 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 2021
Copyright © NIFTY Corporation All Rights Reserved. 9 Team
Topologies とは? アジャイル・リーン・Dev/Ops といったムーブメントは、 ビジネスのフローに沿った小規模のチームに対して大きな 価値があることを実証したが・・・ • 従来型の組織の多くはその組織モデルゆえにこれらのメリット を十分に享受できていない • 場当たり的な文化や組織面での変化
Copyright © NIFTY Corporation All Rights Reserved. 10 Team
Topologies とは? • チームトポロジーが重点を置いているもの ◦ コンウェイの法則 ◦ 認知負荷の制限 ◦ チームファースト思考 いくつかの中心となるアイデアの中から 今回は「認知負荷の制限」について考えてみたい
Copyright © NIFTY Corporation All Rights Reserved. 11 認知負荷
(Cognitive Load) について • 人間のワーキングメモリのリソースを圧迫する負荷 という意味合いで使われることが多い • もともとは心理学で用いられていた • 現在のイメージで使われるようになったのは、1988年 心理学者のジョン・スウェラーによるものとされる ◦ 論文の中で3つの認知負荷を定義 https://www.sciencedirect.com/science/article/abs/pii/0364021388900237
Copyright © NIFTY Corporation All Rights Reserved. 12 課題内在的負荷
• 問題に対する教育的なタスクに関連するもの • プログラミング言語の勉強など 課題外在的負荷 • タスクを実行する上で本質的ではない、環境に関連 するもの • 環境構築など 学習関連負荷 • 学習を進めたりコアな問題を解決するために、特別な注 意が必要なタスクに関連するもの • ビジネス課題を解決するためのロジックなど • ここに注力できるようにしたい 3つの認知負荷
Copyright © NIFTY Corporation All Rights Reserved. 13 チームが抱えている認知負荷を考える
• リリース済みプロダクトの問い合わせ、運用、バグ、 トラブル対応 • 緊急の割り込み作業 • タスクの切り替え • プロダクト外のミーティングや案件 • etc…
Copyright © NIFTY Corporation All Rights Reserved. 14 チームが抱えている認知負荷を考える
• チームサイズを制限する • チームが扱うソフトウェアのサイズを制限する • チームが扱うドメインの種類を制限する チームトポロジーにおける認知負荷へのアプローチ
Copyright © NIFTY Corporation All Rights Reserved. 15 チームサイズを制限する
ダンバー数 (グループの認知と信頼に関係する進化上の限界数) を考慮すると、5~8人 https://robertoferraro.substack.com/p/dunbars-number-and-team-size-the • これはスクラムチームのサイズ としても言われている • コミュニケーションパスは 人数によって増大する • オーバーしている場合は、 思い切って分割も考慮する
Copyright © NIFTY Corporation All Rights Reserved. 16 チームが扱うソフトウェアのサイズを制限する
チームが扱うドメインの種類を制限する • シンプル ◦ ほとんどの仕事は明確な作業手順がある • 煩雑 ◦ 変更の分析が必要で、適切な ソリューションの提供には数回の 繰り返しが必要 • 複雑 ◦ ソリューションの提供には 多くの実験、探索が必要 ドメインを基準に制限・分割する
Copyright © NIFTY Corporation All Rights Reserved. 17 まずは、チームの認知負荷状態を知る
たとえば、スプリント以外の活動時間 スプリント以外の活動時間 スプリントに充てられる時間 Aさん 39h20m 35h30m Bさん 45h 29h50m Cさん 38h 36h50m Dさん 49h 25h50m
Copyright © NIFTY Corporation All Rights Reserved. 18 これからやりたい
• ドメインごとに費やされている時間の計測 • ドメインの切り分け ◦ DDD によるサービスの切り分け ◦ イベントストーミング • プロダクトの棚卸し
Copyright © NIFTY Corporation All Rights Reserved. 19 まとめ
• スクラムがうまく機能していないのは、組織体制との アンマッチが考えられる • ボトムアップで変えていくために、認知負荷という 観点からチームを整理する • まずはチームの認知負荷の状態を知るところから
Copyright © NIFTY Corporation All Rights Reserved.