Regional Scrum Gathering Tokyo 2018登壇資料です。
3FHJPOBM4DSVN(BUIFSJOH5PLZPΥʔλʔϑΥʔϧେنϓϩδΣΫτͷதͰεΫϥϜͰνʔϜӡӦΛͬͯΈͨ佐藤 和彦（@kazusato）2018/1/12
View Slide
͡Ίʹ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しばらくは、プロダクトバックログのメンテナンスが不⼗分で、「スプリントプランニングが終わらない」という状態が続いた１ヶ⽉くらいして、ある程度回るようになったものの、安定してきたのは3ヶ⽉後くらい
ͬͨ՝ͱ͜Ε͔Β23
ͬͨ՝• チーム内だけでは対応しきれない問題も発⽣した① メンバー間のスキル共有が思ったより進まなかった② プロダクトオーナー、スクラムマスターの専任化ができなかった③ 他チームからの割り込み作業が多く、作業が進めにくいことが多かった④ テスト内容によってはプロジェクト終盤まで実施できないことがあった24メンバーにヒアリングしてみると、「チームが継続される前提なら、もう少し他領域にも⼿を出そうと思うが、そうでないので今までの担当領域中⼼になってしまう」との声があったプロダクトオーナーは元々チームリーダーとして専任に近かったが、スクラムマスターは完全に作業を持っていたので、他メンバーで代替できない作業が忙しくなると⾟いできるだけPBI化して対応したが、⽬の前で「今週中になんとか〜」と⾔われると断りにくいたとえば、負荷テストはプロジェクト計画上、環境が終盤まで⽤意できなかった
͜Ε͔Β• WFの中でなんとなく問題と思っていても仕⽅ないとしていたことが、スクラムでやってみて、問題点が明確になった• 残った課題を改めて⾒ると、プロジェクト全体がWF前提なことに起因するものが多い25チーム内で解決できるものは、順次解決してきたプロジェクト終盤まで実施できないテストがあるチームが維持されない社内の仕組み、顧客との関係など、簡単に解決できない課題も多いが、改めて「今までのやり⽅が本当に価値を⽣み出せているのか」と考える必要があると思う
·ͱΊ26
·ͱΊ• WF前提の⼤規模プロジェクトの中で、チーム運営をスクラムで実践してみた• チーム運営については、いろいろな気づきを得ることができ、具体的な改善も実施できた• とはいえ、チーム内だけでは解決できない問題も発⽣した• これらは、今までのやり⽅をふりかえるきかっけとすべきと考えている27チーム外（顧客、社内）にはスクラムの⽤語は使わずにコミュニケーションを⾏ったが、特段問題なかったむしろ、チーム内の状況が把握しやすくなったので、やりやすかった苦労も含め、やって始めて気づけること、⾝につくことが多いので、やろうと思っているなら⼀⽇も早く始めた⽅がよいと思う
28ご清聴ありがとうございました
kazusato
minorun365
oracle4engineer
hayatokudou
bonjiri_niwa
nikkei_engineer_recruiting
tjmtrhs
nomu
tgalopin
ganota
lhazy
kentosuzuki
korodroid
paulrobertlloyd
nonsquared
afnizarnur
rocio
vanstee
philhawksworth
frogandcode
addyosmani
robhawkes
productmarketing
speakerdeck