Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
ちいとぽに学ぶチームのアジリティの高め方(認知負荷編)
mizuman
April 28, 2022
Business
0
1k
ちいとぽに学ぶチームのアジリティの高め方(認知負荷編)
書籍「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」で考え方のベースとなっている認知負荷。
この認知負荷という切り口から、チームのアジリティの高め方を考えます。
mizuman
April 28, 2022
Tweet
Share
Other Decks in Business
See All in Business
recruit
dxyz
0
520
モブとソロを織り交ぜてハイアウトプットなチーム開発 / High output with swarming and solo work
nao_mk2
1
970
アルプ株式会社 会社紹介資料 / Alp, Inc. Company Deck
alpinc
0
1k
Leaf Ring Introduction_2022
leafring
0
530
Webinar 23.06.2022 - Análisis práctico del mecanismo de tope al gas
neuroenergia
0
160
VUCAワールドから紐解く組織や評価制度の変遷と再設計
matsumoto_r
PRO
2
140
Digital Platform Regulation and Practices in Japan
hakusansai
0
250
SimpleForm会社説明資料
simpleform
0
2.3k
株式会社ラジコード 会社説明資料
radicode
0
670
VRSNSを始めて情報発信してたらお仕事もらえた話 #xRAM81
kiyomaryu
0
250
【会社紹介資料】Attack株式会社(2022年6月)
attack
0
230
Tangerine会社紹介資料/We are hiring
3yasuda
4
1.4k
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
237
19k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
39
13k
Large-scale JavaScript Application Architecture
addyosmani
499
110k
jQuery: Nuts, Bolts and Bling
dougneiner
56
6.4k
Stop Working from a Prison Cell
hatefulcrawdad
261
17k
The Power of CSS Pseudo Elements
geoffreycrofte
47
3.9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
119
28k
A Philosophy of Restraint
colly
192
15k
Typedesign – Prime Four
hannesfritz
34
1.4k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
37
3.3k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
224
49k
Visualization
eitanlees
125
11k
Transcript
ちいとぽに学ぶ チームのアジリティの高め方 (認知負荷編) NTTCom PM LT大会 “Dash #1” NTT Communications
PS本 SkyWay推進室 水嶋 彬貴
自己紹介 SkyWay PM(2015〜2019年) SkyWayは推進室になり、動きやすくなったよ 社内も社外も、一緒に戦ってくれる仲間を募集中! 社内のPM伴走支援 / 育成(2019年〜) 軽い雑談や相談も大歓迎 🎉
壁打ち相手に使ってください pmconf実行委員 pmconf 2022も企画中。お楽しみに! 水嶋 彬貴 @mizuman @mizuman_
話すこと 書籍「チームトポロジー」に記載されている内容の 考え方の土台、共通点となっている 認知負荷について紹介します 書籍「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」 https://www.amazon.co.jp/dp/4820729632
話さないこと • チームトポロジーの詳細について ◦ 特に各チームタイプとインタラクションモード QRC Team Topologies-ja https://scrapbox.io/iki-iki/QRC_Team_Topologies-ja
• チームトポロジーの詳細について ◦ 特に各チームタイプとインタラクションモード ◦ 翻訳者である吉羽さんと永瀬さんの説明が端的で分かりやすいのでそっちを聞いた方が良い 話さないこと 【資料公開】30分で分かった気に なるチームトポロジー https://www.ryuzee.com/conte
nts/blog/14566 チームトポロジーを成功させる 実践方法の探求 - Team Topologies Study https://www.youtube.com/wat ch?v=uJL3M7R8MLc 69. チームトポロジー(前編) w/ miholovesq fukabori.fm https://fukabori.fm/episode/69 https://fukabori.fm/episode/70
ゴール チームの開発や価値の提供が遅いと感じているが 何が問題かわからない人が、 チームのアジリティを高める糸口が見つかる そして、 チームトポロジーに興味が湧き、 GWに書籍を読む際に理解しやすくなっている Photo by Rohan
Makhecha on Unsplash
本題
アジェンダ • 求められるアジリティとは • 認知負荷とは • 認知負荷から考えるチームのアジリティの高め方
VUCAな時代に 求められるアジリティ
VUCAな時代に求められるアジリティ 予測が難しい 理解が難しい Uncertainty 不確実性 Complexity 複雑性 Ambiguity 曖昧性 Volatility
変動性 いかに早く理解し、素早く反応できるか 環境 課題 対応
忙しくて顧客を理解する 余裕がないんだけど…
間違ったものを 爆速で届けても意味がない
理解だけ。反応だけ。 ダメ🙅
Photo by Philippa Rose-Tite on Unsplash 1つの生き物のように 1つのチームで 素早い理解と反応を両立させる
実現のヒントとなる (かもしれない) のが認知負荷
認知負荷
認知負荷(cognitive load)とは ”認知負荷とは、ワーキングメモリに対してかかる負荷のことです。ワーキングメ モリの容量は大きくなく、認知負荷が増えすぎると情報を処理しきれなくなりま す。” 認知負荷とは何か?認知負荷を考慮し学習効果を高める方法を解説 https://study-labo.com/Report/10.html
提供価値 メンバーの成長 顧客理解 偉い人の意向 社内調整 責 任 複 雑 な
社 内 プ ロ セ ス 食い違う目標 サ イ ロ 担当者の異動 進まない合議 MTGで埋まる1日 リーダー不在 兼 務 雑なまとめ 脳が処理できる量には限界があり 負荷が高いとパフォーマンスが落ち 学習や理解が止まる 忖 度 指示待ち UX ミ ッ シ ョ ン 分 析 心理的安全性 仮 説 検 証
ひっくり返すと 余計な負荷を減らすことで 有限な思考力(注意力、判断力) を 価値提供に集中する そんな組織を設計しよう メンバーの成長 顧客理解 UX ミ
ッ シ ョ ン 分 析 心理的安全性 仮 説 検 証 提供価値
認知負荷から考える チームのアジリティの高め方
認知負荷を下げて、チームのアジリティを高める 1. チーム 2. 境界線 3. チーム間コミュニケーション
スモールチーム(2 pizza rule) • 少人数のチームで成果を出す ◦ 5-8名 ▪ 人数が増えるとコミュニケーションの オーバーヘッドが増える
◦ 全ての基礎 • 職能横断で、他のチームに依存しない ◦ 価値の提供に必要な能力一式をチームが持っている (価値探索から開発や本番運用の学びまで) ◦ 他チームの作業待ちや引継ぎがなく、独立している → 自他ともに、気にしなくてよい状態を作る • チームで学び、チームで活かす ◦ 企画と開発の両方が1つのチームに揃っている ◦ フィードバックループを高速に回す • 機能しているチームを維持し、壊さない Photo by shaian ramesht on Unsplash
適切な境界(節理面) • 適切なチームの境界が認知負荷を下げる ◦ 節理面:岩などの自然な割れ目 ◦ 情報が多い状態は認知負荷が高い。 ◦ 境界によって、その先を知らなくてよくなる。 →
共有するコンテキストを減らす ◦ 自分の提供価値や責任範囲が明確になる。 → オーナーシップやモチベーション向上に繋がる • チームの認知負荷に合わせて、適切な境界、 責任範囲を設計する ◦ 認知負荷の許容量は人やチームによって許容量は違う ◦ 学習や難易度の変化でも認知負荷は変化する Photo by Kristopher Roller on Unsplash
【資料公開】30分で分かった気になるチームトポロジー https://www.ryuzee.com/contents/blog/14566
不要なコミュニケーションの制限 • チームAPIを設計する ◦ 相手が必要な情報を、受け取りやすい手段で提供する ▪ 他チームにとってのユーザビリティを考える 「他のチームが依存なく価値を提供できるか?」 ◦ チームのインタラクション、関わり方を明確にする
▪ APIがわかっていれば連携できる状態 「自分たちと仕事をする方法は明確か?」 ▪ チームAPIの例 • コード、ドキュメント、チームの価値観、 コミュニケーション方法など ◦ チームがスケールしても、アジリティが落ちない Photo by Travis on Unsplash
まとめ
スモールチームで 価値を出せているのが大前提
認知負荷に合わせた 境界(節理面)の設計が肝
だけど難しい
チームで議論し、試し 良い境界を探っていってください
そして、 僕や吉羽さん(技術顧問) も無邪気に相談や雑談で呼んでね