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
XP祭り2023_ウォーターフォールPjMがアジャイルを導入するまで
Search
tanaka3
September 30, 2023
0
28
XP祭り2023_ウォーターフォールPjMがアジャイルを導入するまで
XP祭り2023で発表させていただいた資料です。
tanaka3
September 30, 2023
Tweet
Share
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Happy Clients
brianwarren
98
6.7k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.8k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Git: the NoSQL Database
bkeepers
PRO
427
64k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Speed Design
sergeychernyshev
24
610
Designing for Performance
lara
604
68k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Transcript
ウォーターフォールPjMが アジャイルを導入するまで XP祭り2023 tanaka-san
アジェンダ • 自己紹介 • テーマ • アプローチ • 導入結果 •
まとめ
自己紹介 田中 久義(tanaka-san) Sierマネージャー • 入社以来ウォーターフォール案件 現在 • アジャイル開発の部署に異動 •
現場にアジャイル(LeSS)導入 • 5チーム(約20名)のスクラムマスター
誰に向けて? • 今までウォーターフォール型開発に参画してきた方 • これから初めてアジャイル型開発に参画する方 • これから現場を、アジャイルに変えていきたい方
ウォーターフォール(WF) ウォーターフォール プロジェクトマネージャー アジャイル • 予測型開発アプローチ • プロジェクトのライフサイクル(計画・設計・開発・テスト etc)をフェーズごとに区切って管理する •
フェーズごとに完了判定を行い、 次のフェーズに行く • 完了しなければ、次のフェーズに行かない(?) • フェーズ事の計画が上手くできる場合は問題ない
アジャイル(Agile) ウォーターフォール • 適応型開発アプローチ • 大まかな目標から始めて、 漸進的に開発を進めていくこと • イテレーションというサイクルの中で、 設計・開発・リリースを繰り返し行い、開発する
• 適応しながら進めていく、計画も変えていく アジャイル プロジェクトマネージャー
ウォーターフォール と アジャイル ウォーターフォールとアジャイルの違いは開発アプローチ WF:計画 > 実績 ⇄ Agile:実績 > 計画 アジャイル
実装 設計 計画 ウォーターフォール テスト 計画 設計 実装 テスト ソフトウェア開発するという目的は同じ!
プロジェクトマネージャー(PjM) ウォーターフォール • プロジェクトマネジメント • プロジェクト 独自のプロダクトやサービスを創造するため に実施さ れる 有期性のある業務を管理する
• なぜ管理が必要なのか? • プロジェクトはそれぞれ独自性のあるもの • 業務はそれぞれが相互に関連しあっている プロジェクトマネージャー アジャイル
アジャイルにはプロジェクトマネージャーは不要? プロジェクトにマネジメントは必要 • マネジメントを行うのが、マネージャーではなく、チームの 一人一人になった • Scrumのプロダクトオーナー=マネージャー、スクラム マスターがリーダーではない • 誰がどう行うかは、現場それぞれによって異なる
• マネージャーやリーダー経験のある人は、 どうやってみんなにマネジメントをおこなってもらうか、リー ダーシップを発揮してもらうかを考える
導入する現場 • 実際に参画した現場 • とある会社の社内システム開発チーム • 16名のマルチベンダーチーム • 慢性的な人手不足 •
毎朝全員のタスク状況を共有し、 チームのリーダーがタスクを割り当てる • リーダーが全員のタスクマネジメントを行っている • その負荷で先の見通しを立てたり、 ステークホルダーマネジメントが行えない
アプローチ ① チームに向けて • アジャイルの知見をもとに現場改善に着手 • 改めてチームビルディングを行う • 色々なワークを行い、チームを知り、自分を知ってもらう。 •
小チーム制を導入 • 人数を 3〜 5名程度に分けた小チームを構築 • Scrum / LeSSを導入 • チームリーダーはプロダクトオーナーに。 • 改善に意欲を持つメンバーをスクラムマスターに。(私と一緒に2人SM) • 残りのメンバーは、開発者に。
アプローチ ① チームに向けて 具体的なチームビルディングの手法 • AsIs-ToBe分析 • チームの目指す姿を作る(MVV) • ドラッカー式エクササイズ
• スキルマップ作成、インセプションデッキ作成 • ニコニコカレンダー • 模擬スクラム研修 etc… 何がチームに有効なのか、実際にやってみて仮説検証を繰り返す
アプローチ ② 個人に向けて • プロダクトオーナー、スクラムマスター • 一人一人のタスクマネジメントから、ステークホルダーマネジメントや プロダクト目的の明確化や共有に比重を置く • 自分たちが行うのではなく、どうすればやってもらえるのかを一緒に考える
• 開発者 • 自分たちでタスクを考えて実行していく • 個人ではなくチームで成果を残す
アプローチ ② 個人に向けて 具体的な活動 • ステークホルダーマネジメント • ステークホルダーマッピング • 会社方針の理解、会社のKPI、OKR
• ピープルマネジメント • 1on1、賞賛とフィードバック、ふりかえり • フレームワークを用いながら、 個々人が興味を持ち、意欲を持てる方向を一緒に探した • どうやるか(How)を教えるのではなく、なぜやるか(Why)・なにをやるか(What)に気 がつけるようにした
導入結果 • 現在のチーム構成 • メンバーは 16名から 23名で 7名増員 • 3つのフィーチャー開発チームと、1つのイネーブリングチーム
• チームの中から品質改善の声があがり、イネーブリングチームが出来上がった • 一つ一つの小チームが自律的に行動し、計画調整等も実行 • プロダクトオーナーは先を見据えたプロダクトバックログを作り、スクラムマスターは 自分の個性を生かした領域での改善を行えるメンバーに 今のところは順調に改善できている(と思われる)
まとめ • ウォーターフォールでもアジャイルでも重要なものは変わらない • ”誰がやるか”、”どうやるか”は変える必要がある • ウォーターフォール経験者がアジャイル開発に行く場合は、今まで1人でやってきた ことをみんなにどうやってもらうかを考えよう • やり方は押し付けるのではなく、現場のメンバーの考えを尊重しよう
• 自分の知見を周りに広げ、周りの知見を吸収しよう • 周りに広げようとすることで自分の知見はさらに高まる • 自分の成功体験・失敗体験をみんなに役立つ知見に昇華させよう これからも周りと一緒に成長していきたいと思っています!
参考図書 • 正しいものを正しくつくる / 市谷 聡啓 プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について • アジャイル型プロダクトマネジメント /
中谷 公巳 最高のチームで価値を実現するために • 問いのデザイン / 安斎 勇樹・塩瀬 隆之 創造的対話のファシリテーション • チームトポロジー / マシュー・スケルトン 価値あるソフトウェアをすばやく届ける適応
XP祭り2023 tanaka-san