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.1k
【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
98
Other Decks in Technology
See All in Technology
どうするコスト最適化のトレードオフ
tetsuyaooooo
1
530
VSCodeの拡張機能を作っている話
ebarakazuhiro
1
570
JAWS-UG Bedrock Claude Night
yamahiro
3
610
Tellus の衛星データを見てみよう #mf_fukuoka
kongmingstrap
0
220
Cypress or Playwright?
rainerhahnekamp
0
110
私が trocco を推す理由
__allllllllez__
1
260
エンジニア候補者向け資料2024.04.24.pdf
macloud
0
3.3k
本当のAWS基礎
toru_kubota
0
530
リテール金融(キャッシュレス・ネット銀行・ネット証券)の競争環境と経済圏
8maki
0
1.2k
20240418_Google ColabにLLMが搭載されたようなのでPython x データ分析の勉強方法を考えてみる
doradora09
0
140
アクセス制御にまつわる改善 / Improving access control
itkq
0
550
ChatGPT for IT Service Management (IT Pro)
dahatake
7
1.6k
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
175
21k
Making Projects Easy
brettharned
108
5.5k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
30
6k
jQuery: Nuts, Bolts and Bling
dougneiner
59
7.1k
Faster Mobile Websites
deanohume
299
30k
Unsuck your backbone
ammeep
663
57k
Building Effective Engineering Teams - LeadDev
addyosmani
28
1.8k
The Illustrated Children's Guide to Kubernetes
chrisshort
31
46k
Documentation Writing (for coders)
carmenintech
60
3.9k
The Mythical Team-Month
searls
216
42k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
17
1.4k
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 ご清聴ありがとうございました