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
1.1k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
チームを”群れ”として観察すれば、 アジャイル開発はもっとうまくいく / Swarming Agile
2020/12/12 Developers Boost 登壇資料
Masato Ishigaki / 石垣雅人
December 12, 2020
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
プロダクトマネージャーが押さえておくべき、ソフトウェア資産とAIエージェント投資効果 / pmconf2025
i35_267
2
2.1k
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
5
480
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
8
1.3k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
9
25k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
6
2.4k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
4
440
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
6
810
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
9
2.2k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.7k
Other Decks in Technology
See All in Technology
Oracle AI Database@Azure:サービス概要のご紹介
oracle4engineer
PRO
6
2k
AIネイティブな開発のサプライチェーンリスク対策 〜激動の開発現場でリスクに立ち向かう〜【ZennFes】
cscengineer
PRO
2
140
Kubernetesにおける学習基盤とLLMOpsの概要
ry
1
320
作って終わりにしない タイミーのセマンティックレイヤー育成の現在地
chanyou0311
4
2.5k
小さく始める AI 活用推進 ― 日経電子版 Web チームの事例/nikkei-tech-talk47
nikkei_engineer_recruiting
0
300
On-behalf-of Token exchange with AgentCore Identity
hironobuiga
2
240
2026 TECHFRESH 畢業分享會 - 開發日常大解密!從領域驅動到企業級上線
line_developers_tw
PRO
0
1.2k
2026TECHFRESH畢業分享會 - 原生還是跨平台? App 開發踩坑實錄
line_developers_tw
PRO
0
1.2k
Chainlitで作るお手軽チャットUI
ynt0485
0
270
10年間のブログ発信を振り返って見えたWebアプリケーションエンジニアとしての軌跡
stefafafan
0
140
生成 AI 実践ガイド (概略版) AIガバナンス編
asei
0
100
マルチアカウント環境での コーディングエージェントを使った障害調査が大変なので AIエージェントにReadOnly権限を付与してみた / ReadOnly AI Agents for Multi-Account AWS Incident Response
yamaguchitk333
2
110
Featured
See All Featured
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
170
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
3.5k
Done Done
chrislema
186
16k
How to Ace a Technical Interview
jacobian
281
24k
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
1.4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
1
200
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
210
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
210
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
460
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 ご清聴ありがとうございました