Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

kazusato
January 12, 2018

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

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

kazusato

January 12, 2018
Tweet

More Decks by kazusato

Other Decks in Technology

Transcript

  1. νʔϜϦʔμʔͱͯ͠ͷ೰Έ • 作業領域を越えたメンバー間のコミュニケーションが進まない • タスクの意図が伝わらないまま作業が始まることが多い • チーム内でスキル共有が進まず、誰かが困っていても他メンバー が助けることができない • 課題が個々のメンバーの中に埋もれ、チームレベルで共有して解

    決することができない 5 メンバー間で話せば解決する問題を 悩んで時間を使ったり、話せば気づ ける考慮が漏れていたり 当然、結果も期待 通りにならない WFでは計画策定時にメン バーが関与していないから、 意図が伝えられていない WBSがあるとやることが決まっているよ うに⾒えるので、コミュニケーションも おろそかになりがち 特定の⼈だけ稼 働が上がる やらなければいけないことが⾒えないので、事前に計 画が⽴てられず、余裕がなくなってから発覚する
  2. εΫϥϜΛ࢝Ί͖͔͚ͨͬʢ͖ͭͮʣ • プロジェクトの前提がWFといいつつ、他の⼿法と⽐較してWFを 選んでいるわけではなく、フィットしていない部分も多い 6 プロジェクト期間中に要 件が変わらないことはな く、要件の⾒直しもたび たび発⽣している 要件が変わらない部分に

    ついても、最初にすべて を完璧に計画できるわけ ではない アプリの仕様変更だけではなく、こ んな検証もしておきたい、みたいな 要望も プロジェクト期間中の経験から、よ りよいやり⽅が⾒つかることも多い 特に⾃チームは、プロジェ クト内でもWFのフェーズか ら外れた進め⽅になること が多かった だったら、⾃チームの運営だけでも、 もっとよい⽅法にできないか?と考えた
  3. ͳͥൃද͠Α͏ͱߟ͑ͨͷ͔ʁ 7 ⾃チームの改善のために チーム運営をスクラムで やってみて、実施する価 値があると感じた SIerの⼈(社内外)と話していると、「お客さんが WF⽂化なんで」「社内の制度が・・・」という理 由でスクラムを採⽤できないという話をよく聞くが、 ⾃チームの改善の範囲でも始めてみた⽅がよいので

    は?と思った 確かに、社内・お客さんともにWF⽂ 化の中で、すぐにスクラムを導⼊す るのは難しい場合も多いと思う お客さんを含めてスクラムでやって、 より価値の⾼い物を作れるならその ⽅が望ましいけど ⾃分たちがやってきたことが参考になる ならと思い共有しようと考えた その結果、スク ラムの適⽤が⼀ 部プロジェクト に限定され、普 及しない
  4. νʔϜ֓ཁ • ⾃チームのメンバーは時期によるが10〜20⼈ • 本発表の対象期間はメンバー10⼈(PO、SM含む) • チームの役割 • 本発表の対象期間 •

    2017年4⽉〜7⽉ • その後も体制やチームの役割が変わりつつも継続中 9 このほかに協⼒会社への依頼作業も あるが、スクラムでのチーム運営の 対象外 アプリケーション構築で 使う共通部品提供、開発 標準化(サーバサイド、 クライアント、その他) データベースまわりの設 計、構築、ツール提供等 ビルド、デプロイの仕組 み作り、開発環境の構 築・保守 本番稼動後に向けた運⽤ 設計、ツール開発等 (APリリース、ログ可視 化、監視・・・)
  5. ࠷ॳʹ΍ͬͨ͜ͱ • 体制決め • プロダクトオーナー: チームリーダー(私) • スクラムマスター: 輪読メンバーの1⼈ •

    開発チーム: その他全員(上記2名も兼務) • プロダクトバックログ作成 • メンバー全員で洗い出しを実施 • 元々の計画作業 • メンバーが抱えていた諸々の課題たち 12
  6. εϓϦϯτϓϥϯχϯά • プロダクトバックログができたので、スプリントプランニングを 始めたが、⼀筋縄ではいかなかった • 中途半端に終わったタスクの残課題対応みたいなアイテムは、で きていること/できていないことの境界も明確化できていなかっ たから⾒積もれるわけがない • メンバー間でのスキル共有ができていないから、理解に時間がか

    かる(そもそも背景を知らない等)という問題も 14 ほぼ丸⼀⽇かけても、1週 間スプリント分の半分も終 わらず アイテムを⾒積もろうとすると、「そも そもこれって何をやるんだっけ?」みた いな話が始まる ・・・ということに気づく までにも数スプリント
  7. σΠϦʔεΫϥϜ • 最初は「3つの質問」でやっていたが、なんか形だけなぞってい る感じがぬぐえなかった • それでも、徐々に課題をタイムリーに共有して、メンバー間で助 け合うことができるようになった • 最終的には、全員でタスクボードを⾒ながら、昨⽇やったこと、 今⽇やろうとしていること、気になっていることや困っているこ

    とを話す、という進め⽅になった 15 スクラムマスターがデイ リースクラムを活性化し ようと試⾏錯誤 レトロスペクティブの中で、チームメンバーから もデイリースクラムをどうしたら活性化できるか という意⾒が出て改善できたのも⼤きい ⾔おうと思っていても忘れるこ ともあったが、タスクボードを ⾒ながらだと思い出しやすい
  8. ׬ྃ͠ͳ͍1#*ͨͪ • 最初の頃は、スプリント期間内で完了させるという意識が弱く、 あれもこれも⼿をつけて結局終わらないことが多かった • プロダクトオーナーとしては当然うれしくない 17 各⾃が⾃分の限界までタスクを 積み、やりきれないと未完了の ままスプリントレビューを迎え

    るという感じ 終わらなかったPBIは中途半端に ⼿をつけている分、次の計画が ⾯倒(余計に⼿間がかかる) ここまでしかできないと ⾔っていいから、確実に終 わらせてくれた⽅がうれし い スプリントごとに、プロダクトオーナー としての要望を伝え、終わらなかった理 由を分析し、徐々に改善していった
  9. εϓϦϯτϨτϩεϖΫςΟϒ • スクラム開始前は、プロジェクト内でふりかえりをする機会が限 られていた • スクラムでは毎スプリントふりかえりを実施するので、改善につ なげやすい 18 プロジェクト終了時とかフェー ズ終了時とか(本プロジェクト

    ではフェーズ終了時にやってい た) ふりかえりをしても、同じメン バーで同じ種類の作業をするこ とが限られているので、やりっ ぱなしになりがちだった メンバーが⾃分たちのやってい る仕事のやりかたについて話し、 考える場を頻繁かつ定期的に作 れたのがよかった
  10. ސ٬ͱͷؔ܎ • もともとチームリーダー(私)が⾃チーム関連の顧客対応をして いたので、関係は変わらず(必要に応じ、メンバーにも参加して もらうが) • 顧客との調整結果に基づき、PBIの内容を⾒直したり、優先順位を ⾒直したり 20 チーム運営をスクラムでやっていることは伝えて

    ないし、プロダクトバックログも共有していない ので、話す⾔葉(スクラムの⽤語は使わず)も以 前のまま プロダクトバックログを介して、チームメンバー とコミュニケーションできるので、やりやすく なった
  11. ࣾ಺ใࠂ • こちらも、もともとチームリーダー(私)がやっていたので、役 割は変わらず • プロジェクト全体はWFで動いているので、それに併せて報告する 21 顧客対応同様、チーム外とのコミュニケーション はスクラムの⽤語は使わず プロダクトバックログの

    優先順位⼊れ替え → WBS上のタスクの順序⼊ れ替え、など 当然、変更や遅延に対し ては原因を説明したり、 対応策を説明することに なる チーム運営をスクラムでやっ ているからといって何かが変 わるわけではない むしろ、チーム内をスクラムでやっている分、 状況把握ができているのでやりやすい(報告 のために改めて情報収集する必要がない)
  12. ࣮ફͨ݁͠Ռͷ·ͱΊ • 最初は何をやるにも勝⼿がわからないので、試⾏錯誤しながら • メンバー個々に抱えていた課題を表に出して、やる/やらないを プロダクトオーナーが判断する形にできたのがよかった • ふりかえりを頻繁かつ定期的に実施でき、メンバー間で仕事のや り⽅を話すようになったのがよかった •

    チーム外とのコミュニケーションはプロダクトオーナーが「翻 訳」することで、チーム外との関係を変えずに進めた 22 しばらくは、プロダクトバック ログのメンテナンスが不⼗分で、 「スプリントプランニングが終 わらない」という状態が続いた 1ヶ⽉くらいして、ある程度回 るようになったものの、安定し てきたのは3ヶ⽉後くらい
  13. ࢒ͬͨ՝୊ • チーム内だけでは対応しきれない問題も発⽣した ① メンバー間のスキル共有が思ったより進まなかった ② プロダクトオーナー、スクラムマスターの専任化ができなかった ③ 他チームからの割り込み作業が多く、作業が進めにくいことが多 かった

    ④ テスト内容によってはプロジェクト終盤まで実施できないことが あった 24 メンバーにヒアリングしてみると、「チームが継続される前提 なら、もう少し他領域にも⼿を出そうと思うが、そうでないの で今までの担当領域中⼼になってしまう」との声があった プロダクトオーナーは元々チームリーダーとして専任に近かっ たが、スクラムマスターは完全に作業を持っていたので、他メ ンバーで代替できない作業が忙しくなると⾟い できるだけPBI化して対応したが、⽬の前で「今週中になんとか 〜」と⾔われると断りにくい たとえば、負荷テストはプロジェクト計画上、 環境が終盤まで⽤意できなかった
  14. ͜Ε͔Β • WFの中でなんとなく問題と思っていても仕⽅ないとしていたこと が、スクラムでやってみて、問題点が明確になった • 残った課題を改めて⾒ると、プロジェクト全体がWF前提なことに 起因するものが多い 25 チーム内で解決できるものは、 順次解決してきた

    プロジェクト終盤まで実 施できないテストがある チームが維持されない 社内の仕組み、顧客との関係など、簡単に解決できない課題 も多いが、改めて「今までのやり⽅が本当に価値を⽣み出せ ているのか」と考える必要があると思う
  15. ·ͱΊ • WF前提の⼤規模プロジェクトの中で、チーム運営をスクラムで実 践してみた • チーム運営については、いろいろな気づきを得ることができ、具 体的な改善も実施できた • とはいえ、チーム内だけでは解決できない問題も発⽣した •

    これらは、今までのやり⽅をふりかえるきかっけとすべきと考え ている 27 チーム外(顧客、社内)にはスクラムの ⽤語は使わずにコミュニケーションを ⾏ったが、特段問題なかった むしろ、チーム内の状況 が把握しやすくなったの で、やりやすかった 苦労も含め、やって始めて気づけること、⾝につくことが多 いので、やろうと思っているなら⼀⽇も早く始めた⽅がよい と思う