ちいとぽに学ぶ チームのアジリティの高め方 （認知負荷編） 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

まとめ

スモールチームで 価値を出せているのが大前提

認知負荷に合わせた 境界（節理面）の設計が肝

だけど難しい

チームで議論し、試し 良い境界を探っていってください

そして、 僕や吉羽さん（技術顧問） も無邪気に相談や雑談で呼んでね