【RSGT2018】ウォーターフォール 大規模プロジェクトの中で スクラムでチーム運営をやってみた

Regional Scrum Gathering Tokyo 2018登壇資料です。

Transcript

1. 3FHJPOBM
   4DSVN
   (BUIFSJOH
   5PLZP
    ΢ΥʔλʔϑΥʔϧ େن໛ϓϩδΣΫτͷதͰ εΫϥϜͰνʔϜӡӦΛ΍ͬͯΈͨ 佐藤 和彦（@kazusato） 2018/1/12
2. ͸͡Ίʹ 2
3. ࣗݾ঺հ • 佐藤 和彦（@kazusato） • ⽇本ユニシス株式会社 • 航空・旅⾏向けシステムを中⼼に担当 • 技術⾯ではサーバサイドJavaまわり中⼼でやってきた • 認定スクラムプロダクトオーナー 3
4. εΫϥϜΛ࢝Ί͖͔͚ͨͬ • チーム内で起きるいろいろな問題に悩まされていた • 原因を考えると、ウォーターフォールでないがしろにされている ことが原因なのでは？と思った • スクラムのことを調べてみると、抱えている問題の解決につなが るのでは？と思った 4
5. νʔϜϦʔμʔͱͯ͠ͷ೰Έ • 作業領域を越えたメンバー間のコミュニケーションが進まない • タスクの意図が伝わらないまま作業が始まることが多い • チーム内でスキル共有が進まず、誰かが困っていても他メンバー が助けることができない • 課題が個々のメンバーの中に埋もれ、チームレベルで共有して解 決することができない 5 メンバー間で話せば解決する問題を 悩んで時間を使ったり、話せば気づ ける考慮が漏れていたり 当然、結果も期待 通りにならない WFでは計画策定時にメン バーが関与していないから、 意図が伝えられていない WBSがあるとやることが決まっているよ うに⾒えるので、コミュニケーションも おろそかになりがち 特定の⼈だけ稼 働が上がる やらなければいけないことが⾒えないので、事前に計 画が⽴てられず、余裕がなくなってから発覚する
6. εΫϥϜΛ࢝Ί͖͔͚ͨͬʢ͖ͭͮʣ • プロジェクトの前提がWFといいつつ、他の⼿法と⽐較してWFを 選んでいるわけではなく、フィットしていない部分も多い 6 プロジェクト期間中に要 件が変わらないことはな く、要件の⾒直しもたび たび発⽣している 要件が変わらない部分に ついても、最初にすべて を完璧に計画できるわけ ではない アプリの仕様変更だけではなく、こ んな検証もしておきたい、みたいな 要望も プロジェクト期間中の経験から、よ りよいやり⽅が⾒つかることも多い 特に⾃チームは、プロジェ クト内でもWFのフェーズか ら外れた進め⽅になること が多かった だったら、⾃チームの運営だけでも、 もっとよい⽅法にできないか？と考えた
7. ͳͥൃද͠Α͏ͱߟ͑ͨͷ͔ʁ 7 ⾃チームの改善のために チーム運営をスクラムで やってみて、実施する価 値があると感じた SIerの⼈（社内外）と話していると、「お客さんが WF⽂化なんで」「社内の制度が・・・」という理 由でスクラムを採⽤できないという話をよく聞くが、 ⾃チームの改善の範囲でも始めてみた⽅がよいので は？と思った 確かに、社内・お客さんともにWF⽂ 化の中で、すぐにスクラムを導⼊す るのは難しい場合も多いと思う お客さんを含めてスクラムでやって、 より価値の⾼い物を作れるならその ⽅が望ましいけど ⾃分たちがやってきたことが参考になる ならと思い共有しようと考えた その結果、スク ラムの適⽤が⼀ 部プロジェクト に限定され、普 及しない
8. ϓϩδΣΫτ֓ཁ • 旅⾏関連の基幹系システムのリプレース • プロジェクト全体ではピーク時要員数200⼈くらい • プロジェクト管理はWF前提 • 期間は基本設計開始〜本番稼動で2年くらい 8
9. νʔϜ֓ཁ • ⾃チームのメンバーは時期によるが10〜20⼈ • 本発表の対象期間はメンバー10⼈（PO、SM含む） • チームの役割 • 本発表の対象期間 • 2017年4⽉〜7⽉ • その後も体制やチームの役割が変わりつつも継続中 9 このほかに協⼒会社への依頼作業も あるが、スクラムでのチーム運営の 対象外 アプリケーション構築で 使う共通部品提供、開発 標準化（サーバサイド、 クライアント、その他） データベースまわりの設 計、構築、ツール提供等 ビルド、デプロイの仕組 み作り、開発環境の構 築・保守 本番稼動後に向けた運⽤ 設計、ツール開発等 （APリリース、ログ可視 化、監視・・・）
10. ࣮ફͷաఔ 10
11. ࢝ΊΔ·Ͱ • 開始時点ではスクラム経験者不在（概要レベルの研修を受けた⼈ は何⼈かいる程度） • 2017年1⽉〜3⽉にチームメンバーの⼀部で「エッセンシャルスク ラム」の輪読を実施 • いろいろ考えたが、「チーム外とのコミュニケーションが今まで 通りできれば問題ないのでは？」と考えて導⼊することにした 11 この時点では、実際にスクラムを導 ⼊するか決め切れてなかった チーム内で説明し了承を得て開始（やっ てみて、合わないと思ったらやめるのも あり、という前提で説明）
12. ࠷ॳʹ΍ͬͨ͜ͱ • 体制決め • プロダクトオーナー: チームリーダー（私） • スクラムマスター: 輪読メンバーの1⼈ • 開発チーム: その他全員（上記2名も兼務） • プロダクトバックログ作成 • メンバー全員で洗い出しを実施 • 元々の計画作業 • メンバーが抱えていた諸々の課題たち 12
13. ॳظͷϓϩμΫτόοΫϩά • メンバーが抱える課題に起因するアイテムがたくさん出てきた • 後から⾔われても困るので、「気になることは全部出して！（や る／やらないとか、いつ？は後で決めるから）」と依頼 13 それまでも、「タスクとしては終 わっているけど、◦◦の場合にはう まくいかないんで、後で対応が必要 と思います」みたいなのが結構あっ た 今まではメンバーの頭の中にしかなかっ たものがプロダクトバックログに集約で きたので、状況把握が楽になった
14. εϓϦϯτϓϥϯχϯά • プロダクトバックログができたので、スプリントプランニングを 始めたが、⼀筋縄ではいかなかった • 中途半端に終わったタスクの残課題対応みたいなアイテムは、で きていること／できていないことの境界も明確化できていなかっ たから⾒積もれるわけがない • メンバー間でのスキル共有ができていないから、理解に時間がか かる（そもそも背景を知らない等）という問題も 14 ほぼ丸⼀⽇かけても、1週 間スプリント分の半分も終 わらず アイテムを⾒積もろうとすると、「そも そもこれって何をやるんだっけ？」みた いな話が始まる ・・・ということに気づく までにも数スプリント
15. σΠϦʔεΫϥϜ • 最初は「3つの質問」でやっていたが、なんか形だけなぞってい る感じがぬぐえなかった • それでも、徐々に課題をタイムリーに共有して、メンバー間で助 け合うことができるようになった • 最終的には、全員でタスクボードを⾒ながら、昨⽇やったこと、 今⽇やろうとしていること、気になっていることや困っているこ とを話す、という進め⽅になった 15 スクラムマスターがデイ リースクラムを活性化し ようと試⾏錯誤 レトロスペクティブの中で、チームメンバーから もデイリースクラムをどうしたら活性化できるか という意⾒が出て改善できたのも⼤きい ⾔おうと思っていても忘れるこ ともあったが、タスクボードを ⾒ながらだと思い出しやすい
16. εϓϦϯτͷ࣮ࢪ • 最初の頃は、スプリントプランニングで担当者を決め、⾃分の担 当タスクしか⾒なくなっていた（スクラム導⼊前とあまりかわっ てない） • スプリントを繰り返す中で、徐々に、メンバー間で協⼒して進め ていくようになった 16 当然、他メンバーがやっているタスクに 関⼼も薄くなり、デイリースクラムも形 だけになってしまう ⽇々の状況に応じ、誰が何をやるかを 決めて進めるようになっていった
17. ׬ྃ͠ͳ͍1#*ͨͪ • 最初の頃は、スプリント期間内で完了させるという意識が弱く、 あれもこれも⼿をつけて結局終わらないことが多かった • プロダクトオーナーとしては当然うれしくない 17 各⾃が⾃分の限界までタスクを 積み、やりきれないと未完了の ままスプリントレビューを迎え るという感じ 終わらなかったPBIは中途半端に ⼿をつけている分、次の計画が ⾯倒（余計に⼿間がかかる） ここまでしかできないと ⾔っていいから、確実に終 わらせてくれた⽅がうれし い スプリントごとに、プロダクトオーナー としての要望を伝え、終わらなかった理 由を分析し、徐々に改善していった
18. εϓϦϯτϨτϩεϖΫςΟϒ • スクラム開始前は、プロジェクト内でふりかえりをする機会が限 られていた • スクラムでは毎スプリントふりかえりを実施するので、改善につ なげやすい 18 プロジェクト終了時とかフェー ズ終了時とか（本プロジェクト ではフェーズ終了時にやってい た） ふりかえりをしても、同じメン バーで同じ種類の作業をするこ とが限られているので、やりっ ぱなしになりがちだった メンバーが⾃分たちのやってい る仕事のやりかたについて話し、 考える場を頻繁かつ定期的に作 れたのがよかった
19. ϓϩμΫτόοΫϩάͷϦϑΝΠϯϝϯτ • 次のスプリントプランニングまでにプロダクトバックログをきれ いにしないと、スプリントが回らなくなるので⼤変 19 メンバーが抱えていた課題起因 のアイテムは、プロダクトオー ナーも把握しきれていないので、 メンバーへのヒアリングが必要 7⽉までの期間は、ほぼ毎週⾃転 ⾞操業状態で回していた（最近 はそこまでではない） こういう状況を経験して、スクラムを始める前の状態では 要求事項も⼗分伝え切れていなかったし、計画がきちんと ⽴てられないのも当然と感じた
20. ސ٬ͱͷؔ܎ • もともとチームリーダー（私）が⾃チーム関連の顧客対応をして いたので、関係は変わらず（必要に応じ、メンバーにも参加して もらうが） • 顧客との調整結果に基づき、PBIの内容を⾒直したり、優先順位を ⾒直したり 20 チーム運営をスクラムでやっていることは伝えて ないし、プロダクトバックログも共有していない ので、話す⾔葉（スクラムの⽤語は使わず）も以 前のまま プロダクトバックログを介して、チームメンバー とコミュニケーションできるので、やりやすく なった
21. ࣾ಺ใࠂ • こちらも、もともとチームリーダー（私）がやっていたので、役 割は変わらず • プロジェクト全体はWFで動いているので、それに併せて報告する 21 顧客対応同様、チーム外とのコミュニケーション はスクラムの⽤語は使わず プロダクトバックログの 優先順位⼊れ替え → WBS上のタスクの順序⼊ れ替え、など 当然、変更や遅延に対し ては原因を説明したり、 対応策を説明することに なる チーム運営をスクラムでやっ ているからといって何かが変 わるわけではない むしろ、チーム内をスクラムでやっている分、 状況把握ができているのでやりやすい（報告 のために改めて情報収集する必要がない）
22. ࣮ફͨ݁͠Ռͷ·ͱΊ • 最初は何をやるにも勝⼿がわからないので、試⾏錯誤しながら • メンバー個々に抱えていた課題を表に出して、やる／やらないを プロダクトオーナーが判断する形にできたのがよかった • ふりかえりを頻繁かつ定期的に実施でき、メンバー間で仕事のや り⽅を話すようになったのがよかった • チーム外とのコミュニケーションはプロダクトオーナーが「翻 訳」することで、チーム外との関係を変えずに進めた 22 しばらくは、プロダクトバック ログのメンテナンスが不⼗分で、 「スプリントプランニングが終 わらない」という状態が続いた １ヶ⽉くらいして、ある程度回 るようになったものの、安定し てきたのは3ヶ⽉後くらい
23. ࢒ͬͨ՝୊ͱ͜Ε͔Β 23
24. ࢒ͬͨ՝୊ • チーム内だけでは対応しきれない問題も発⽣した ① メンバー間のスキル共有が思ったより進まなかった ② プロダクトオーナー、スクラムマスターの専任化ができなかった ③ 他チームからの割り込み作業が多く、作業が進めにくいことが多 かった ④ テスト内容によってはプロジェクト終盤まで実施できないことが あった 24 メンバーにヒアリングしてみると、「チームが継続される前提 なら、もう少し他領域にも⼿を出そうと思うが、そうでないの で今までの担当領域中⼼になってしまう」との声があった プロダクトオーナーは元々チームリーダーとして専任に近かっ たが、スクラムマスターは完全に作業を持っていたので、他メ ンバーで代替できない作業が忙しくなると⾟い できるだけPBI化して対応したが、⽬の前で「今週中になんとか 〜」と⾔われると断りにくい たとえば、負荷テストはプロジェクト計画上、 環境が終盤まで⽤意できなかった
25. ͜Ε͔Β • WFの中でなんとなく問題と思っていても仕⽅ないとしていたこと が、スクラムでやってみて、問題点が明確になった • 残った課題を改めて⾒ると、プロジェクト全体がWF前提なことに 起因するものが多い 25 チーム内で解決できるものは、 順次解決してきた プロジェクト終盤まで実 施できないテストがある チームが維持されない 社内の仕組み、顧客との関係など、簡単に解決できない課題 も多いが、改めて「今までのやり⽅が本当に価値を⽣み出せ ているのか」と考える必要があると思う
26. ·ͱΊ 26
27. ·ͱΊ • WF前提の⼤規模プロジェクトの中で、チーム運営をスクラムで実 践してみた • チーム運営については、いろいろな気づきを得ることができ、具 体的な改善も実施できた • とはいえ、チーム内だけでは解決できない問題も発⽣した • これらは、今までのやり⽅をふりかえるきかっけとすべきと考え ている 27 チーム外（顧客、社内）にはスクラムの ⽤語は使わずにコミュニケーションを ⾏ったが、特段問題なかった むしろ、チーム内の状況 が把握しやすくなったの で、やりやすかった 苦労も含め、やって始めて気づけること、⾝につくことが多 いので、やろうと思っているなら⼀⽇も早く始めた⽅がよい と思う
28. 28 ご清聴ありがとうございました