チームが大きくなったので、開発プロセスを運用してみた

プロジェクトマネジメント Tips LT会 vol.3 で発表させていただいた資料です。

Transcript

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