チームが大きくなったので、開発プロセスを運用してみた
by
Mitsukawa
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
チームが大きくなったので、 開発プロセスを運用してみた @プロジェクトマネジメント Tips LT会 vol.3 Mitsukawa Ruka
Slide 2
Slide 2 text
自己紹介 ミツカワ ルカ ・所属: Sansan株式会社 ・役割: Sansan のWebアプリエンジニア → Data Hub のPMO ・趣味: Splatoon, Pokémon UNITE ・Twitter: @mitsuriver
Slide 3
Slide 3 text
はじめに 「Sansan Data Hub」を開発している開発チームの話をします ※弊社全体の開発組織の話ではありません データ統合基盤「Sansan Data Hub」
Slide 4
Slide 4 text
アジェンダ 1. 開発プロセスを作ろう 2. やったこと 3. で、どうなったか 話すこと - 開発プロセスをどうやって作ったか - 運用してみてどんな効果・学びがあったか
Slide 5
Slide 5 text
開発プロセスを作ろう
Slide 6
Slide 6 text
背景 エンジニアチー ム (2-4名) × 5 マネージャ PdMチーム (2名) PMO × 1 現在の組織体制 3 18 10 エンジニア人数の推移 2017/11 始動 2019/11 2021/11 現在
Slide 7
Slide 7 text
背景 開発チームの課題 - チームによって作業手順がバラバラ - プロジェクトの質が担当者依存 - うまくやれてるチームもある一方、課題があるチームも - リリース直前の手戻りが多い... - いつリリースされるのかよくわからない ... - リリース予定日が守られない...
Slide 8
Slide 8 text
目標 目標 基本的なプロジェクト管理プロセスが 確立されている 場当たり的で、プロセスが定義されていない 成功は個人の努力に依存する 組織で標準化プロセスが『定義』され、 各プロジェクトで利用されている プロセスが 『最適化』されている プロセスと成果物が 定量的に『管理』されている Lv.5 Lv.4 Lv.3 Lv.2 Lv.1 現状 CMMI 成熟度レベル
Slide 9
Slide 9 text
やったこと
Slide 10
Slide 10 text
やったこと 1. 開発チームへヒアリング&課題共有 2. 各工程の定義 3. 役割の定義(RACI図)
Slide 11
Slide 11 text
1. 開発チームへヒアリング&課題共有 課題の共有 → QCD改善のためのブレスト
Slide 12
Slide 12 text
2. 各工程の定義 項目 - 実施時期 - 誰がするのか - 何をするのか - 完了基準
Slide 13
Slide 13 text
3. 役割の定義(RACI図) 関係者のロール 工程 R:実行責任者 タスクの実行者。複数いても構わない。 A:説明責任者(承認者) 作業の完了を承認し、全体に責任を負う役割。原則1つのタスクに1人。 C:協業先 タスクを進める際の相談者。タスクを進める際に、双方向にやり取りを行う。 I:報告先 タスクの進捗状況の報告先。タスクを進める際に、一方向的なやり取りとなる。 役割
Slide 14
Slide 14 text
で、どうなったか
Slide 15
Slide 15 text
結果 - 手戻りがほぼなくなった - 品質up - リリース時期についてのコミュニケーションが増えた
Slide 16
Slide 16 text
時間軸 運用開始 直後 - プロセスを無視することが多発 - 再周知・再共有をした 運用開始 2-3カ月後 - プロセスを軸に開発をすることが定着 - 改善のサイクルが回りだした 運用開始 半年後 - プロセスによる恩恵をメンバーが感じ始める
Slide 17
Slide 17 text
まとめ - 標準化することにより、組織全体の底上げに繋がる - プロセスをみんなで育てると浸透しやすい