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
チームを”群れ”として観察すれば、 アジャイル開発はもっとうまくいく / Swarming A...
Search
Masato Ishigaki / 石垣雅人
December 12, 2020
Technology
0
980
チームを”群れ”として観察すれば、 アジャイル開発はもっとうまくいく / Swarming Agile
2020/12/12 Developers Boost 登壇資料
Masato Ishigaki / 石垣雅人
December 12, 2020
Tweet
Share
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
2
160
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
4
570
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
7
1.6k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.4k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.4k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?
i35_267
29
21k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
11
2.8k
開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity
i35_267
69
27k
開発生産性の低下による、事業の失敗はなぜ起こるのか / ProductivityPitfalls
i35_267
6
1.6k
Other Decks in Technology
See All in Technology
新規プロダクト開発、AIでどう変わった? #デザインエンジニアMeetup
bengo4com
0
450
Create a Rails8 responsive app with Gemini and RubyLLM
palladius
0
110
Digitization部 紹介資料
sansan33
PRO
1
4.2k
Snowflake Intelligenceで実現できるノーコードAI活用
takumimukaiyama
1
210
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
220
DB 醬,嗨!哪泥嘎斯基?
line_developers_tw
PRO
0
150
「どこにある?」の解決。生成AI(RAG)で効率化するガバメントクラウド運用
toru_kubota
2
380
(非公式) AWS Summit Japan と 海浜幕張 の歩き方 2025年版
coosuke
PRO
1
230
Cloud Native Scalability for Internal Developer Platforms
hhiroshell
2
450
原則から考える保守しやすいComposable関数設計
moriatsushi
2
260
2025/6/21 日本学術会議公開シンポジウム発表資料
keisuke198619
0
200
Securing your Lambda 101
chillzprezi
0
260
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
14
1.5k
How to Ace a Technical Interview
jacobian
276
23k
Product Roadmaps are Hard
iamctodd
PRO
53
11k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Side Projects
sachag
454
42k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Transcript
チームを ”群れ” として観察すれば、 アジャイル開発はもっとうまくいく Developers Boost 2020 1 Masato Ishigaki
December 12 , 2020
2 Outline / Structure of the Talk ・組織を変化させる上でのプラクティス(手段)の罠 ・チームは、”群れながら” 開発している
・群知能(Swarm Intelligence)とアジャイルの群れる(Swarming) ・群れとして認識して、”観測”する ・リモート開発の時代
3 About me 石垣雅人 / Masato Ishigaki DMM.com 総合トップ開発部 部長
2015年度 エンジニア 新卒入社 2017年より、DMMにおける3000万のアカウント(ID)、認証(Auth) のバックエンド 周りのプロダクトオーナーを経て、 2018年7月にリードナーチャリング領域を強化す るチームの立ち上げを行う。 2020年より、DMMの総合トップなどを管轄する総合 トップ開発部の部長を務める。 現在はアプリプラットフォームのプロダクトオーナーにも 従事 @i35_267 i35-267 著 『DMMを支えるデータ駆動戦略』 https://www.amazon.co.jp/dp/4839970165/
4 - 何かを変えたいと思ったとき、人はプラクティスに頼ろうとする - アジャイル、スクラム、 etc…. - 本に書いてあった。カンファレンスでプラクティスを聞いた。 - 決して悪いことではなく、ある意味正解である。
- しかし、そのまま適応しようとするとたいてい失敗する - そこに存在している「個」はバラバラであり、事業環境も、組織環境も違う - 手法(プラクティス)は、型として理解する - これらの手法は決して "成功"を保証するものではない - ある種の「型」であり、このプロセスや方法論さえ守っていれば事業が必ず成長する、と いった銀の弾丸ではありません。 - プロセスや方法論は、手段であり目的ではありません。「型」を何も考えずに組織へ導入 すると思考停止になり導入自体が目的となりがちです。 - そのため、プラクティスと組織の間にある差分を意識する → 群れ方が違う プラクティスの罠 Photo by Markus Spiske on Unsplash
Photo by David Clode on Unsplash 5 “群れ” として捉える
6 “群れ” として捉える - 私たちは、”群れながら” 開発をしている - チーム開発が良い例。個人では限界があるため、人は複数人で作業をして、スケー ルさせている。 -
なぜか。不確実性が高い事業環境下、予算が尽きる前にできるだけ早く市場へ投 入して、イテレーティブな仮説検証を経て稼がなければ、事業が死んでしまう。 - 一方、自分たちを “群れている” と認識することは少ない - 色々な「個」と「個」の集まりがチームだとすると、個のメンタルモデルから来る “群れ 方” は違う。私たちがチーム開発する上での問題(出来事)は、 ”群れ方”の構造と行 動パターンに起因する - 氷山モデルを例とすると、そのチーム特有のメンタルモデル -> 構造 -> 行動パター ンがあって、はじめて出来事(事象)がある。 - 群れ方は、そこにいる人・構造・環境によって変わってくる Photo by Amir on Unsplash
7 群知能(Swarm Intelligence) Photo by Johnny Chen on Unsplash -
なぜ、動物(鳥や魚)は統率された行動ができるのか。 - 群れ = 自己組織化している(無意識に自律的な秩序を持つ) - 秩序の例。魚の大群。複雑系に見えて実はとてもシンプルな論理 - 1. 前の個体を追うこと - 2. 横の個体と速度を合わせること - 秩序の例。アリの群衆は、どうやって最短ルートで餌場にたどり着くの か。なぜアリの集団は、遅いルートを選ばないのか - マーキングによる行動の観察
8 なぜ、群れているのか理解する Photo by David Clode on Unsplash - なぜ、私たちは群れているのか
- 生物学的に見ても、強い敵や難しい課題が目の前に現れたとき単独で行動するより も、統一された集団行動によって、 1対1では敵わない敵に勝てるかもしれないというこ とを本能的に知っている。いわゆる、恐怖。 - どうやったら強い敵に勝てるかをフィードバックをもとに徐々に学習して理解していく。 - 群れている状態とは何か - “群れる"の本質は、何かの対象に対して集団が相互作用しながらも自然と同じ方向を 向いて、前に進んでいるということであり、個々がそのメリットを体系的に理解している こと。 - 本能的に「ひとりで進むよりも皆と協力して "群れ"ながら進んだ方が良い結果を生む」 と判断できることである。
9 アジャイル開発でいう “群れる” とは Photo by Hugo Rocha on Unsplash
- アジャイルは、”群れながら” 作ることを前提にしている - アジャイルには “Swarming” という概念がある。 - スクラムで言えば、ProductBacklog(作るべき対象)に対して、チームメンバーが “群 がり” ながら、一定の秩序をもち(イベント)優先度順にゴールに向けて作り上げていく。 - “群れ” = 自律的な秩序をもった自己組織化された集団でなければいけない。そうでな ければ破綻する(うまくいかない)し、コミュニケーションはうまくいかない。逆に群れて 作らなければ、それはアジャイルではない。 - “群がる” 粒度を考える - アイテム単位でペアプロ / モブプロするのが良いのか、 SprintBacklog単位で群がっ て作るのかは、組織 = 個と個、環境によって変えていく必要がある。 - 可観測性を高めながら、観測していく。
1 0 可観測性を高めながら、チームを観察していく Photo by Quino Al on Unsplash -
チームを観察し「暗黙知」はどこかを認識する - 暗黙知とは、言語化されていない感覚的で身体的な知識のこと。 - “群れる(Swarming)” というのは、“ 暗黙知 ” の最大化させるに近い - チームが何を大事にしていて、どんな価値観が大事かを観察する。 - 暗黙知を高めるためにアジャイルでは多くの「場」が用意されている - モブプロ / ペアプロや物理的なホワイトボードでのチケット管理、デイリースク ラム、振り返りなど。実際に距離が近い「場」が必要 - 暗黙知を観察するには「可観測性」を高め、抽出する - 透明性を高めて、チームを観察しやすいようにする。 - 抽出。パターン・ランゲージの文脈。その「チームっぽさ」を抽出していく。 - 暗黙知はチームによって変わる、型をチームに導入して差分を出していく。 - 「いまのチームはスプリントレビューはいらなさそうだね」 ,etc...
1 1 リモートでの ”群れる”の難しさ Photo by Avi Richards on Unsplash
- アジャイルは、オフラインが前提として作られていた。 - 物理的なホワイトボードでのチケット管理や、物理的な「場」の推進。 - アジャイルは「場」をうまく観察しながら、機能している部分が多い。 - リモートでの難しさ - 集団の中で自律的な秩序(プロセス)を新たに作るには、メンバーの納得感や意見の 吸い上げが必須になるが、リモートだとその難易度が異常に高い。 - 物理的な「場」の分断における「情報」の遮断。そこから来る「個」の隔離。 - 「この子は何か言いたそうだな」「なんとなく納得してないな」というのが、こちらから キャッチアップしずらいため、既存のマネジメントだと歯が立たなくなってきた。
12 リモートでも ”群れる” Photo by Kelly Sikkema on Unsplash -
「場」を多く設計し、作り出す - 一番の問題は、コミュニケーションの形骸化。 - 意図的に会話しながら、開発するような構造に設計する。 - Discord導入やリモートモブプロの促進、ディスカッション MTG - オフラインのことをオンラインツールにただ置き換えない - リモートチームになっても、そのチームのパターンを出していく。オフラインのことをオン ラインにただ置き換えるだけでは不十分。価値観を表出化 会議での相槌役 雑談責任 “エモさ” の表現 週1回の 顔出しランチ会 稼ぐ意識 Ex.
1 3 まとめ ・組織にベストプラクティスをただ導入してはいけない ・アジャイルは、”群れる” ことを作られている ・暗黙知を大事にしながら、Swarmingしていく ・しかし、リモートにそれが難しくなった ・「場」づくりとパターン抽出による価値観を認識する
1 4 ご清聴ありがとうございました