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
【RSGT2018】ウォーターフォール 大規模プロジェクトの中で スクラムでチーム運営をやってみた
Search
kazusato
January 12, 2018
Technology
0
2.2k
【RSGT2018】ウォーターフォール 大規模プロジェクトの中で スクラムでチーム運営をやってみた
Regional Scrum Gathering Tokyo 2018登壇資料です。
kazusato
January 12, 2018
Tweet
Share
More Decks by kazusato
See All by kazusato
Kotlinでweld-junitを使ったら思ったように動かなかった話
kazusato
0
120
Other Decks in Technology
See All in Technology
【shownet.conf_】持続可能な次世代Wi-Fi運用に向けて
shownet
PRO
0
290
つよつよリーダーが 抜けたらどうする? 〜ナビタイムのAgile⽀援組織の変遷〜
navitimejapan
PRO
22
13k
【shownet.conf_】ローカル5Gを活用したウォーキングツアーの体感向上
shownet
PRO
0
280
kube-vipとkube-proxy置き換えCiliumを積んだ究極のK3sクラスタを建てる
logica0419
4
200
Azure Verified Moduleを触って分かった注目ポイント/azure-verified-module-begin
mhrtech
1
210
たった一人で始めた音楽制作が気がついたら会社公認の部活動になっていた話〜組織の垣根を超えるコラボレーションを実現するには〜 / On-KAG-bu
piyonakajima
0
180
テストコードの品質を客観的な数値で担保しよう〜Mutation Testのすすめ〜
ysknsid25
9
2.7k
AI時代のアジャイル開発(XP祭り2024版) / Agile Development in the AI Era in XPJUG
takaking22
13
3.5k
Vista FinderMx
jtes
0
160
Product Utilization of Large Language Models Starting Today
ymatsuwitter
3
980
普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
ytaka23
4
670
MLOpsの「あるある」課題の解決と、そのためのライブラリgokart
mski_iksm
1
160
Featured
See All Featured
How GitHub (no longer) Works
holman
311
140k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
4
110
Into the Great Unknown - MozCon
thekraken
30
1.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
158
15k
Designing for humans not robots
tammielis
249
25k
The Straight Up "How To Draw Better" Workshop
denniskardys
231
130k
Agile that works and the tools we love
rasmusluckow
327
21k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
6
240
Rails Girls Zürich Keynote
gr2m
93
13k
The Invisible Side of Design
smashingmag
297
50k
Transcript
3FHJPOBM4DSVN(BUIFSJOH5PLZP ΥʔλʔϑΥʔϧ େنϓϩδΣΫτͷதͰ εΫϥϜͰνʔϜӡӦΛͬͯΈͨ 佐藤 和彦(@kazusato) 2018/1/12
͡Ίʹ 2
ࣗݾհ • 佐藤 和彦(@kazusato) • ⽇本ユニシス株式会社 • 航空・旅⾏向けシステムを中⼼に担当 • 技術⾯ではサーバサイドJavaまわり中⼼でやってきた
• 認定スクラムプロダクトオーナー 3
εΫϥϜΛ࢝Ί͖͔͚ͨͬ • チーム内で起きるいろいろな問題に悩まされていた • 原因を考えると、ウォーターフォールでないがしろにされている ことが原因なのでは?と思った • スクラムのことを調べてみると、抱えている問題の解決につなが るのでは?と思った 4
νʔϜϦʔμʔͱͯ͠ͷΈ • 作業領域を越えたメンバー間のコミュニケーションが進まない • タスクの意図が伝わらないまま作業が始まることが多い • チーム内でスキル共有が進まず、誰かが困っていても他メンバー が助けることができない • 課題が個々のメンバーの中に埋もれ、チームレベルで共有して解
決することができない 5 メンバー間で話せば解決する問題を 悩んで時間を使ったり、話せば気づ ける考慮が漏れていたり 当然、結果も期待 通りにならない WFでは計画策定時にメン バーが関与していないから、 意図が伝えられていない WBSがあるとやることが決まっているよ うに⾒えるので、コミュニケーションも おろそかになりがち 特定の⼈だけ稼 働が上がる やらなければいけないことが⾒えないので、事前に計 画が⽴てられず、余裕がなくなってから発覚する
εΫϥϜΛ࢝Ί͖͔͚ͨͬʢ͖ͭͮʣ • プロジェクトの前提がWFといいつつ、他の⼿法と⽐較してWFを 選んでいるわけではなく、フィットしていない部分も多い 6 プロジェクト期間中に要 件が変わらないことはな く、要件の⾒直しもたび たび発⽣している 要件が変わらない部分に
ついても、最初にすべて を完璧に計画できるわけ ではない アプリの仕様変更だけではなく、こ んな検証もしておきたい、みたいな 要望も プロジェクト期間中の経験から、よ りよいやり⽅が⾒つかることも多い 特に⾃チームは、プロジェ クト内でもWFのフェーズか ら外れた進め⽅になること が多かった だったら、⾃チームの運営だけでも、 もっとよい⽅法にできないか?と考えた
ͳͥൃද͠Α͏ͱߟ͑ͨͷ͔ʁ 7 ⾃チームの改善のために チーム運営をスクラムで やってみて、実施する価 値があると感じた SIerの⼈(社内外)と話していると、「お客さんが WF⽂化なんで」「社内の制度が・・・」という理 由でスクラムを採⽤できないという話をよく聞くが、 ⾃チームの改善の範囲でも始めてみた⽅がよいので
は?と思った 確かに、社内・お客さんともにWF⽂ 化の中で、すぐにスクラムを導⼊す るのは難しい場合も多いと思う お客さんを含めてスクラムでやって、 より価値の⾼い物を作れるならその ⽅が望ましいけど ⾃分たちがやってきたことが参考になる ならと思い共有しようと考えた その結果、スク ラムの適⽤が⼀ 部プロジェクト に限定され、普 及しない
ϓϩδΣΫτ֓ཁ • 旅⾏関連の基幹系システムのリプレース • プロジェクト全体ではピーク時要員数200⼈くらい • プロジェクト管理はWF前提 • 期間は基本設計開始〜本番稼動で2年くらい 8
νʔϜ֓ཁ • ⾃チームのメンバーは時期によるが10〜20⼈ • 本発表の対象期間はメンバー10⼈(PO、SM含む) • チームの役割 • 本発表の対象期間 •
2017年4⽉〜7⽉ • その後も体制やチームの役割が変わりつつも継続中 9 このほかに協⼒会社への依頼作業も あるが、スクラムでのチーム運営の 対象外 アプリケーション構築で 使う共通部品提供、開発 標準化(サーバサイド、 クライアント、その他) データベースまわりの設 計、構築、ツール提供等 ビルド、デプロイの仕組 み作り、開発環境の構 築・保守 本番稼動後に向けた運⽤ 設計、ツール開発等 (APリリース、ログ可視 化、監視・・・)
࣮ફͷաఔ 10
࢝ΊΔ·Ͱ • 開始時点ではスクラム経験者不在(概要レベルの研修を受けた⼈ は何⼈かいる程度) • 2017年1⽉〜3⽉にチームメンバーの⼀部で「エッセンシャルスク ラム」の輪読を実施 • いろいろ考えたが、「チーム外とのコミュニケーションが今まで 通りできれば問題ないのでは?」と考えて導⼊することにした
11 この時点では、実際にスクラムを導 ⼊するか決め切れてなかった チーム内で説明し了承を得て開始(やっ てみて、合わないと思ったらやめるのも あり、という前提で説明)
࠷ॳʹͬͨ͜ͱ • 体制決め • プロダクトオーナー: チームリーダー(私) • スクラムマスター: 輪読メンバーの1⼈ •
開発チーム: その他全員(上記2名も兼務) • プロダクトバックログ作成 • メンバー全員で洗い出しを実施 • 元々の計画作業 • メンバーが抱えていた諸々の課題たち 12
ॳظͷϓϩμΫτόοΫϩά • メンバーが抱える課題に起因するアイテムがたくさん出てきた • 後から⾔われても困るので、「気になることは全部出して!(や る/やらないとか、いつ?は後で決めるから)」と依頼 13 それまでも、「タスクとしては終 わっているけど、◦◦の場合にはう まくいかないんで、後で対応が必要
と思います」みたいなのが結構あっ た 今まではメンバーの頭の中にしかなかっ たものがプロダクトバックログに集約で きたので、状況把握が楽になった
εϓϦϯτϓϥϯχϯά • プロダクトバックログができたので、スプリントプランニングを 始めたが、⼀筋縄ではいかなかった • 中途半端に終わったタスクの残課題対応みたいなアイテムは、で きていること/できていないことの境界も明確化できていなかっ たから⾒積もれるわけがない • メンバー間でのスキル共有ができていないから、理解に時間がか
かる(そもそも背景を知らない等)という問題も 14 ほぼ丸⼀⽇かけても、1週 間スプリント分の半分も終 わらず アイテムを⾒積もろうとすると、「そも そもこれって何をやるんだっけ?」みた いな話が始まる ・・・ということに気づく までにも数スプリント
σΠϦʔεΫϥϜ • 最初は「3つの質問」でやっていたが、なんか形だけなぞってい る感じがぬぐえなかった • それでも、徐々に課題をタイムリーに共有して、メンバー間で助 け合うことができるようになった • 最終的には、全員でタスクボードを⾒ながら、昨⽇やったこと、 今⽇やろうとしていること、気になっていることや困っているこ
とを話す、という進め⽅になった 15 スクラムマスターがデイ リースクラムを活性化し ようと試⾏錯誤 レトロスペクティブの中で、チームメンバーから もデイリースクラムをどうしたら活性化できるか という意⾒が出て改善できたのも⼤きい ⾔おうと思っていても忘れるこ ともあったが、タスクボードを ⾒ながらだと思い出しやすい
εϓϦϯτͷ࣮ࢪ • 最初の頃は、スプリントプランニングで担当者を決め、⾃分の担 当タスクしか⾒なくなっていた(スクラム導⼊前とあまりかわっ てない) • スプリントを繰り返す中で、徐々に、メンバー間で協⼒して進め ていくようになった 16 当然、他メンバーがやっているタスクに
関⼼も薄くなり、デイリースクラムも形 だけになってしまう ⽇々の状況に応じ、誰が何をやるかを 決めて進めるようになっていった
ྃ͠ͳ͍1#*ͨͪ • 最初の頃は、スプリント期間内で完了させるという意識が弱く、 あれもこれも⼿をつけて結局終わらないことが多かった • プロダクトオーナーとしては当然うれしくない 17 各⾃が⾃分の限界までタスクを 積み、やりきれないと未完了の ままスプリントレビューを迎え
るという感じ 終わらなかったPBIは中途半端に ⼿をつけている分、次の計画が ⾯倒(余計に⼿間がかかる) ここまでしかできないと ⾔っていいから、確実に終 わらせてくれた⽅がうれし い スプリントごとに、プロダクトオーナー としての要望を伝え、終わらなかった理 由を分析し、徐々に改善していった
εϓϦϯτϨτϩεϖΫςΟϒ • スクラム開始前は、プロジェクト内でふりかえりをする機会が限 られていた • スクラムでは毎スプリントふりかえりを実施するので、改善につ なげやすい 18 プロジェクト終了時とかフェー ズ終了時とか(本プロジェクト
ではフェーズ終了時にやってい た) ふりかえりをしても、同じメン バーで同じ種類の作業をするこ とが限られているので、やりっ ぱなしになりがちだった メンバーが⾃分たちのやってい る仕事のやりかたについて話し、 考える場を頻繁かつ定期的に作 れたのがよかった
ϓϩμΫτόοΫϩάͷϦϑΝΠϯϝϯτ • 次のスプリントプランニングまでにプロダクトバックログをきれ いにしないと、スプリントが回らなくなるので⼤変 19 メンバーが抱えていた課題起因 のアイテムは、プロダクトオー ナーも把握しきれていないので、 メンバーへのヒアリングが必要 7⽉までの期間は、ほぼ毎週⾃転
⾞操業状態で回していた(最近 はそこまでではない) こういう状況を経験して、スクラムを始める前の状態では 要求事項も⼗分伝え切れていなかったし、計画がきちんと ⽴てられないのも当然と感じた
ސ٬ͱͷؔ • もともとチームリーダー(私)が⾃チーム関連の顧客対応をして いたので、関係は変わらず(必要に応じ、メンバーにも参加して もらうが) • 顧客との調整結果に基づき、PBIの内容を⾒直したり、優先順位を ⾒直したり 20 チーム運営をスクラムでやっていることは伝えて
ないし、プロダクトバックログも共有していない ので、話す⾔葉(スクラムの⽤語は使わず)も以 前のまま プロダクトバックログを介して、チームメンバー とコミュニケーションできるので、やりやすく なった
ࣾใࠂ • こちらも、もともとチームリーダー(私)がやっていたので、役 割は変わらず • プロジェクト全体はWFで動いているので、それに併せて報告する 21 顧客対応同様、チーム外とのコミュニケーション はスクラムの⽤語は使わず プロダクトバックログの
優先順位⼊れ替え → WBS上のタスクの順序⼊ れ替え、など 当然、変更や遅延に対し ては原因を説明したり、 対応策を説明することに なる チーム運営をスクラムでやっ ているからといって何かが変 わるわけではない むしろ、チーム内をスクラムでやっている分、 状況把握ができているのでやりやすい(報告 のために改めて情報収集する必要がない)
࣮ફͨ݁͠Ռͷ·ͱΊ • 最初は何をやるにも勝⼿がわからないので、試⾏錯誤しながら • メンバー個々に抱えていた課題を表に出して、やる/やらないを プロダクトオーナーが判断する形にできたのがよかった • ふりかえりを頻繁かつ定期的に実施でき、メンバー間で仕事のや り⽅を話すようになったのがよかった •
チーム外とのコミュニケーションはプロダクトオーナーが「翻 訳」することで、チーム外との関係を変えずに進めた 22 しばらくは、プロダクトバック ログのメンテナンスが不⼗分で、 「スプリントプランニングが終 わらない」という状態が続いた 1ヶ⽉くらいして、ある程度回 るようになったものの、安定し てきたのは3ヶ⽉後くらい
ͬͨ՝ͱ͜Ε͔Β 23
ͬͨ՝ • チーム内だけでは対応しきれない問題も発⽣した ① メンバー間のスキル共有が思ったより進まなかった ② プロダクトオーナー、スクラムマスターの専任化ができなかった ③ 他チームからの割り込み作業が多く、作業が進めにくいことが多 かった
④ テスト内容によってはプロジェクト終盤まで実施できないことが あった 24 メンバーにヒアリングしてみると、「チームが継続される前提 なら、もう少し他領域にも⼿を出そうと思うが、そうでないの で今までの担当領域中⼼になってしまう」との声があった プロダクトオーナーは元々チームリーダーとして専任に近かっ たが、スクラムマスターは完全に作業を持っていたので、他メ ンバーで代替できない作業が忙しくなると⾟い できるだけPBI化して対応したが、⽬の前で「今週中になんとか 〜」と⾔われると断りにくい たとえば、負荷テストはプロジェクト計画上、 環境が終盤まで⽤意できなかった
͜Ε͔Β • WFの中でなんとなく問題と思っていても仕⽅ないとしていたこと が、スクラムでやってみて、問題点が明確になった • 残った課題を改めて⾒ると、プロジェクト全体がWF前提なことに 起因するものが多い 25 チーム内で解決できるものは、 順次解決してきた
プロジェクト終盤まで実 施できないテストがある チームが維持されない 社内の仕組み、顧客との関係など、簡単に解決できない課題 も多いが、改めて「今までのやり⽅が本当に価値を⽣み出せ ているのか」と考える必要があると思う
·ͱΊ 26
·ͱΊ • WF前提の⼤規模プロジェクトの中で、チーム運営をスクラムで実 践してみた • チーム運営については、いろいろな気づきを得ることができ、具 体的な改善も実施できた • とはいえ、チーム内だけでは解決できない問題も発⽣した •
これらは、今までのやり⽅をふりかえるきかっけとすべきと考え ている 27 チーム外(顧客、社内)にはスクラムの ⽤語は使わずにコミュニケーションを ⾏ったが、特段問題なかった むしろ、チーム内の状況 が把握しやすくなったの で、やりやすかった 苦労も含め、やって始めて気づけること、⾝につくことが多 いので、やろうと思っているなら⼀⽇も早く始めた⽅がよい と思う
28 ご清聴ありがとうございました