成長するプロダクトのための 開発プロセスの改善

Transcript

1. 成長するプロダクトのための 開発プロセスの改善 2025/2/28 DevLove関西 茂野智幸 1
2. 自己紹介 名前 　茂野 智幸（しげの ともゆき） 業務役割 　新卒入社7年目 　課長 　プロジェクトリーダー その他 　休日は料理する 　スノーボードやフットサル 　今年の目標は体を柔らかくする 2
3. はじめに 3 この10年でLANSCOPEというプロダクトと開発チームは大きく成長 しました。 一方で、プロダクトに関わるチームの増加に伴い、チームごとに進め 方が変化し、これによりプロジェクト運用が難しくなってきました。 生じた課題、プロセスを統一するための仕組みづくり、目標としてき た形ついてお話しします。
4. 開発メンバー数の推移 4 8年間で3倍以上
5. どんな課題がでてきたか 5
6. 初期は1チームでプロダクト開発 6
7. プロダクトの拡大によりチーム数の増加 7 チームA チームB チームC
8. プロダクトの拡大によりチーム数の増加 8 PdM合意得た？ 見積もりタイミング？ 必要なドキュメント 作成抜け？ チームA チームB チームC 別チームで同じ課題 性能テストはどこが実施？
9. チーム数増加に伴う課題 9
10. 改善の方向性と実施したこと 10
11. 目指す形 11 ・開発プロセスがプロダクトで統一され、不要な手戻りが発生しない ・だれがどのプロジェクトを指揮しても、一定の成果物がアウトプット される
12. 実施したこと 12
13. プロダクトとしてのベースのプロセスフローを定義 13 要件定義、調査設計、開発、テスト、リリースといったフェーズごと の流れを一枚絵で作成
14. プロダクトとしてのベースのプロセスフローを定義 14 ⇐プロセスフェーズごとにやることを 深堀り、作業詳細を定義。 ほかにも曖昧だったことを明確にした。 ・要件定義時のステークホルダー ・詳細設計のフォーマット化 ・ユニットテストと結合テストの棲み分け など
15. プロダクトとしてのベースのプロセスフローを定義 15 これらすべてを総括して、”成果物チェックリスト”を作成し、だれがどの プロジェクトを指揮しても、一定の成果物がアウトプットされる状態を とった。
16. 懸念 16
17. ここに気をつけた 17 1. 開発者をフローでガチガチに縛らない ・手戻り発生などによる全体のリードタイムを減らすことが目的の一つ。 ・フロー定義により、リードタイムをさらに増やすことはしたくなかった。 ・PLが実施すべきプロジェクト大枠のフローとする。 2. 開発者同士の共有の場は別で設置 ・開発課題は開発者同士で随時連携し合う。 　・ブランチ戦略/ライブラリ更新時の製品影響/セキュリティ課題など ・他チームの改善提案を取り込む土壌はできており、開発者も意識を持てて いた。 ・現状整っている仕組みは無理に変えず、各チームのやり方に一任する決断 もとった。
18. ここに気をつけた 18 3. 関門にしない ・No:フローをすべて終わらせないと次に進めない。 ・Yes:あくまでも`ベース`のフロー。遵守することで、プロダクトとして整 合性が取れる。
19. ナレッジの集約 19 SharePoint チャットツール バックログ チームの知識 プロジェクトの要件定義。 ステークホルダーとの相談 証跡。 プロジェクト遂行上の チーム間の調整ごとや調 査結果。 タスクやプロジェクトの調査 結果。計測結果。 各チームの専門知識や 開発知見。
20. PMOの設置 20
21. 結果 21
22. 改善前 22 PdM合意得た？ 見積もりタイミング？ 必要なドキュメント 作成抜け？ チームA チームB チームC 別チームで同じ課題 性能テストはどこが実施？
23. 統一したプロセス 23 チームA チームB チームC PMO テスト棲み分け デザイン マニュアル 同じ成果物 ステークホルダー 他チーム課題のインプット 設計書の粒度統一
24. 効果 24 ・新規参画プロジェクトリーダーの道標ができた。 ・チーム異動者が、変わらないフローで開発できるようになった。 ・他部署のチーム（テスト・マニュアル・デザイン）の混乱が減り、プ ロジェクトに関わるタイミングが明確になった。 ・ドキュメント整備により、テスト設計/観点のスピードと精度向上。 ・曖昧なフローから生じていた手戻りが減少した。 ・プロセス不統一による漠然とした不安が払拭された。
25. まとめ 25
26. まとめと学び 26 ・バラバラだったプロセスを一つにできた。 ・フローの構築（Quality）と開発工数（Delivery）のちょうど良い塩梅 を見極めて定義できた。 ・既存のやり方を変更することは、変える側も変えられる側も労力が大 きい。 ・でも、全員が納得できる形を目指すことで、プロダクト全体として幸 せな方向に進むはず。（中長期的）
27. 今後のこと 27 さらなる組織のスケールに対応 プロダクトの強化に伴って、チームや関わる部署が増えることが予想。 状況に合わせてフローをアップデートしていく。 その時、常にリードタイムと天秤にかける。 改善思考を停滞させない やり方の定義が進むと、それに従えばOKという意識が強くなりがち。 例えば新規参画者のギモンを吸い上げてフローを見直すなど、より良い 形を模索する。