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
組織構造の力学を操作して、アプリ開発プロセスを最大化させる / organizationa...
Search
Masato Ishigaki / 石垣雅人
September 10, 2020
Technology
2
750
組織構造の力学を操作して、アプリ開発プロセスを最大化させる / organizational structure to maximize the development process
2020/09/21 「iOSDC Japan 2020」登壇資料
Masato Ishigaki / 石垣雅人
September 10, 2020
Tweet
Share
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
4
170
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
7
890
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
8
19k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
6
2.1k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
3
260
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
6
630
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
9
1.7k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.4k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.6k
Other Decks in Technology
See All in Technology
Product Management Conference -AI時代に進化するPdM-
kojima111
0
270
JuniorからSeniorまで: DevOpsエンジニアの成長ロードマップ
yuriemori
2
330
Grafana Meetup Japan Vol. 6
kaedemalu
1
180
microCMS 最新リリース情報(microCMS Meetup 2025)
microcms
0
340
実践アプリケーション設計 ①データモデルとドメインモデル
recruitengineers
PRO
5
1.3k
Jaws-ug名古屋_LT資料_20250829
azoo2024
3
190
Kubernetes における cgroup v2 でのOut-Of-Memory 問題の解決
pfn
PRO
0
420
新規案件の立ち上げ専門チームから見たAI駆動開発の始め方
shuyakinjo
0
600
「魔法少女まどか☆マギカ Magia Exedra」のグローバル展開を支える、開発チームと翻訳チームの「意識しない協創」を実現するローカライズシステム
gree_tech
PRO
0
340
実践アプリケーション設計 ②トランザクションスクリプトへの対応
recruitengineers
PRO
4
1.1k
ヘブンバーンズレッドのレンダリングパイプライン刷新
gree_tech
PRO
0
350
スプリントレトロスペクティブはチーム観察の宝庫? 〜チームの衝突レベルに合わせたアプローチ仮説!〜
electricsatie
1
130
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Into the Great Unknown - MozCon
thekraken
40
2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.6k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Practical Orchestrator
shlominoach
190
11k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
Unsuck your backbone
ammeep
671
58k
4 Signs Your Business is Dying
shpigford
184
22k
What's in a price? How to price your products and services
michaelherold
246
12k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Transcript
組織構造の力学を操作して アプリ開発プロセスを最大化させる iOSDC Japan 2020 September 21, 2020 1
2 Outline / Structure of the Talk ・iOSにおける新規事業開発をベースにお話します ・リードタイムを削減しながらも、良いものを市場へ投入したい ・組織とプロセスを操作することでバリューストリームを設計する
・組織構造の力学 / 生産性の可視化・バランス / 意思決定のプロセス
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/
事業 40以上の事業を 20以上のグループ会社で運営 規模の大小、ジャンル関係なく 未来を感じるビジネスに投資し 領域とわず、なんでもやります。
数字でみるDMM ※ ) 、 証券、 、 ,他連結( 月期) ※ )
サービスの会員数( 月期) 売上 会員数 事業数 グループ会社 設立 従業員数 ※ ※ 億円 万人 事業以 上 以 上 社 年目 名
6 DMM PointClub DMMの新しいプラットフォームアプリ
7 Client BFF Backends For Frontends API API SDK API
Software Development Kit Application Programming Interface Database iOS ・言語 : Swift ・設計:VIPER+FlowController(マルチモジュール) ・利用技術:SwiftUI+Combine ・CI : Bitrise ・デザインツール: Figma BFF / Backend APIs ・言語 : Go ・設計:DDD(ドメイン駆動設計) ・環境:AWS ECS(Fargate),etc... ・DB : Aurora ・CI : CircleCI ・API定義:OpenAPI (Swagger) ・・ ・ Microservices Tracking ・Firebase→BigQuery→DWH ・AppsFlyer ・AppAnnie Architecture
8 事業責任者 (プロダクトオーナー) 開発チーム UI / UX Designer iOS +
Android Engineer Backend Engineer Growth / Marketing Team 計13 ~ 14名
9 Client BFF Backends For Frontends API API SDK API
Software Development Kit Application Programming Interface Database iOS ・言語 : Swift ・設計:VIPER+FlowController(マルチモジュール) ・利用技術:SwiftUI+Combine ・CI : Bitrise ・デザインツール: Figma Backend APIs ・言語 : Go ・設計:DDD(ドメイン駆動設計) ・環境:AWS ECS(Fargate),etc... ・DB : Aurora ・CI : CircleCI ・API定義:OpenAPI (Swagger) ・・ ・ Microservices Tracking ・Firebase→BigQuery→DWH ・AppsFlyer ・AppAnnie という状況下の中でプロダクトを作るときに意識する部分 「リードタイムを最大限短縮する」 不確実性が高い事業環境下、 予算が尽きる前にできるだけ早く市場へ投入して、 イテレーティブな仮説検証を経て、 稼がなければ、事業が死んでしまう
10 リードタイムを「1/3」に短縮できれば、 1年間で4回リリースを12回 (3倍) にすることができる ※ 2年間だったら、8回 → 24回 ※3年間だったら、12回
→ 36回 ....
11 Client BFF Backends For Frontends API API SDK API
Software Development Kit Application Programming Interface Database iOS ・言語 : Swift ・設計:VIPER+FlowController(マルチモジュール) ・利用技術:SwiftUI+Combine ・CI : Bitrise ・デザインツール: Figma Backend APIs ・言語 : Go ・設計:DDD(ドメイン駆動設計) ・環境:AWS ECS(Fargate),etc... ・DB : Aurora ・CI : CircleCI ・API定義:OpenAPI (Swagger) ・・ ・ Microservices Tracking ・Firebase→BigQuery→DWH ・AppsFlyer ・AppAnnie 考えるべきことは2つ ・どういう組織構造で作っていくか ・どういうプロセスで作っていくか 個々のスキルにプロダクト開発のリードタイムが左右されてないように 構造(仕組み)から生まれる力学を意識してバリューストリームを作っていく。 生産性の再現性を作る
12 サービス iOS / Android UIデザイン バックエンド Pattern.1 専門レイヤーにチームを分ける モバイルチーム
バックエンドチーム スモールチームをどう分けていくか Pattern.2 ドメインチーム体制 サービス iOS / Android UIデザイン バックエンド ドメインチーム
13 サービス iOS / Android UIデザイン バックエンド モバイルチーム バックエンドチーム Pros
/ Cons ・人数 + 0→1フェーズということを考慮した上で、専門性を 持って一気に構築を進める専門レイヤーごとのチームを採 用 ・それぞれのチームでイテレーションを回すことで会話のプ ロトコルを合わせる ・スクラムチームでいう「LeSS」の体制 ・懸念点は、1つのプロダクトを作るにあたって、モバイルと バックエンドのコミュニケーションが必ず必要になること。 オーバーヘッドが高くなる。 Pattern.1 専門レイヤーにチームを分ける スモールチームをどう分けていくか
14 「リードタイム削減 : その1」 全員のプロダクトイメージを完全に一致させる 特に初期の頃は、皆が同じものをイメージしていないと 議論が散らばって、時間だけが過ぎていく これを防ぐ解決策が必要
15 「0→1を組織でスタートを切るための3つの構築」 1. ユーザーストーリーマッピング 構築 2. プロダクトバックログ 構築 3. 開発プロセス
構築 Photo by Martin Katler on Unsplash
16 1. 1. ユーザーストーリーマッピング 構築 ↓ 「Scope」 2. プロダクトバックログ 構築
↓ 「Priority」 3. 開発プロセス 構築 ↓ 「Process」
17 「0→1を組織でスタートを切るための3つの構築」 1. ユーザーストーリーマッピング 構築 2. プロダクトバックログ 構築 3. 開発プロセス
構築 Photo by Martin Katler on Unsplash
18 Scope ユーザーストーリーマッピング
19 Scope ユーザーストーリーマッピング バックボーン ナラティブフロー 画面 詳細 骨格 物語 (ユーザーストーリー)
UIデザイン タスク
20 Scope ユーザーストーリーマッピング アカウント登 録・認証する 支払い方法 を選択する 商品を 検索する 商品を
購入する 商品 ページを見る ジャンル で検索 メールアドレ スで 登録する SNSアカウン トで登録でき る カート に入れる クレジット カード を登録する ポイントを 配る クーポンを 配る 購入完了 メールを送る
21 商品を 検索する 商品を 購入する カート に入れる アカウント登録 ・認証する 支払い方法を
選択する 商品を 検索する 商品を 購入する 商品 ページを見る ジャンル で検索 商品名 で検索 価格が見える 商品 レビューが 見れる メールアドレス で 登録する SNSアカウント で登録できる ゲストで 登録できる カート に入れる クレジットカー ド を登録する ポイントを 配る クーポンを 配る クーポン を使う 電子マネーで 払う バックボーン 抽象度 優先度 t t ナラティブフロー 詳細 購入完了 メールを送る リリース #1(MVP)
increment iterative プロダクト(機能)の積み上げ方 22
23 商品を 検索する 商品を 購入する カート に入れる アカウント登録 ・認証する 支払い方法を
選択する 商品を 検索する 商品を 購入する 商品 ページを見る ジャンル で検索 商品名 で検索 価格が見える 商品 レビューが 見れる メールアドレス で 登録する SNSアカウント で登録できる ゲストで 登録できる カート に入れる クレジットカー ド を登録する ポイントを 配る クーポンを 配る クーポン を使う 電子マネーで 払う バックボーン 抽象度 優先度 t t ナラティブフロー 詳細 購入完了 メールを送る リリース #1(MVP) increment iterative
24 Priority プロダクトバックログ 商品を検索する 商品を購入する 商品を検索する 商品ページを見る アカウント 登録・認証する 支払い方法を
選択する 商品を購入する ジャンルで検索 商品名で検索 価格が見える 商品レビューが見える メールアドレスで 登録する SNSアカウントで 登録する ゲストで登録する カートに入れる クレジットカードを 登録する クーポンを使う 電子マネーを使う 購入完了メールを送る ポイントを配る クーポンを配る カートに入れる ジャンルで検索 商品名で検索 価格が見える 商品レビューが見える メールアドレスで 登録する SNSアカウントで 登録する カートに入れる クレジットカードを 登録する 購入完了メールを送る 初期MVP #1
25 「リードタイム課題 : その2」 初期MVPで作るべき、プロダクトのイメージが重なって無事開発が開始できる 次の出てくる問題として、 各レイヤーのスピード感の違いによる 機能結合のタイミング、デモのタイミング、意思決定のプロセス を整わせなければいけない
API 26 メールアドレスで 登録する ユーザーストーリー UIデザイン iOS API API iOS
API 結合 開発 / 設計 WF デモ Backends API Backends API ジャンルで検索 クレジットカードを 登録する ・ ・ ・
27 「0→1を組織でスタートを切るための3つの構築」 1. ユーザーストーリーマッピング 構築 2. プロダクトバックログ 構築 3. 開発プロセス
構築 Photo by Martin Katler on Unsplash
28 「流れ」を思考する やれることは沢山ある ・バリューストリームを設計する(バリューストリームマッピングを書く) ・TOC(制約理論)を意識して、ボトルネックはどこかを突き止める ・リソース効率ではなく、フロー効率を意識する ・プロセスをモニタリングする / プロセスを制御する
29 「流れ」を思考する やれることは沢山ある ・バリューストリームを設計する(バリューストリームマッピングを書く) ・TOC(制約理論)を意識して、ボトルネックはどこかを突き止める ・リソース効率ではなく、フロー効率を意識する ・プロセスをモニタリングする / プロセスを制御する
30 プロセスをモニタリングする 局所最適化ではなく、全体最適化を目的とした 「かんばん」 ストーリー WF 設計 iOS / BE
開発中 結合 計測をしてボトルネックの可視化 PO確認 クローズ
31 「かんばん」の累積フローを可視化する 工程(プロセス) リードタイム WIP 設計 開発 & 結合 PO確認
クローズ
32 スプリントレビュー(PO確認)待ちでの リードタイムがもったいない ↓ 検証用環境に上げてもらったら、 BitriseのQRコード読み込んで、 速攻確認→クローズの流れ 意思決定のプロセス
リードタイム スタート 価値 工程 WIP制限(作業の制御)をかけて、 1個ずつ流すように制御する ここでいうと複数ストーリーを着手しない WIP制限 Single Piece
Flow(1つのサイクルで1つの仮説)
34 まとめ ・人数規模や事業規模によって組織構造を最適化する ・どういう組織構造で作っていくか(構成と) ・どういうプロセスで作っていくか ・生産性の可視化 ・ボトルネックなプロセスに対策を打ち込む
35 ご清聴ありがとうございました