自律的で協調的なチームの作り方 / How to build autonomous collaborative team in RSGT2019

by nakaly

Slide 1

Slide 1 text

中村亮介 – LINE Fukuoka株式会社⾃律的で協調的なチームの作り⽅ ~複数拠点、多⾔語、職能型組織で始めるScrum~

Slide 2

Slide 2 text

Agenda • プロダクトやチーム、チームの課題について • チームの変化の軌跡 • 変化の後課題はどうなった? • ⾃律的で協調的なチームの作り⽅とは • チームにもたらしたもの・⾃分の中で変わったこと

Slide 3

Slide 3 text

ϓϩμΫτ΍νʔϜɺνʔϜͷ՝ ୊ʹ͍ͭͯ

Slide 4

Slide 4 text

• 開発チームリーダー • サーバーサイドエンジニア • 社内アジャイルコーチ兼務 Weʼre hiring! https://linecorp.com/ja/care er/position/1405 ࣗݾ঺հ

Slide 5

Slide 5 text

ϓϩμΫτʹ͍ͭͯ トーク占い • LINEのトークルームでチャット or 電話で占い師に相談できる

Slide 6

Slide 6 text

ϓϩμΫτʹ͍ͭͯ トークCARE • 恋愛・仕事・⼈間関係の悩みについてカウンセラーに相談できる

Slide 7

Slide 7 text

νʔϜʹ͍ͭͯ • チームは東京と福岡に分散している • プランナー/デザイナー/エンジニア/QAはそれぞれ違う組織東京プランナーデザイナー福岡エンジニア QA

Slide 8

Slide 8 text

࿩͢͜ͱ • Agile/Scrum へ取り組むことで、プランナー・エンジニア間の՝୊ ͕ղফし協調的に取り組めるようになり、チームがより⾃律的に動けるように੒௕͍͓ͯ͘͠࿩ • 現在進⾏系で課題を抱えている⽅ • ここにも悩んでいる⼈がいるということが知れます • 百戦錬磨の⽅ • Agile/Scrum取り組みのやり始めの⼈が何考えているか知れます • マサカリください

Slide 9

Slide 9 text

νʔϜ͕͍࣋ͬͯͨ՝୊ • エンジニアが持っていた課題 • ⾒積もり前にビジネス側で開発のείʔϓͱσουϥΠϯΛܾΊͳ͍Ͱ΄͠ ͍ • 開発する機能に関してഎܠ΍໨త͕͋·ΓೲಘͰ͖ͳ͍ • 開発する機能の༏ઌॱҐ͕Θ͔Βͳ͍ • プランナー側が作成するཁٻ΍࢓༷͕ෆਖ਼֬だったり、不⼗分だったりするせいで、։ൃظ͕ؒԆͼ͍ͯΔと感じているのに理解されていない気がする

Slide 10

Slide 10 text

νʔϜ͕͍࣋ͬͯͨ՝୊ • プランナーが持っていた課題 • エンジニア側のݟੵ΋Γ͕ద੾͔Θ͔Βͳ͍ • エンジニア側がे෼ʹޮ཰Α͘ಇ͚͍ͯΔ͔Θ͔Βͳ͍ • エンジニアのചΓ্͛కΊ੾Γʹର͢Δίϛοτϝϯτ͕௿͍ように感じる • มߋΛॊೈʹऔΓೖΕͯσουϥΠϯ΋कΔようにしてほしい

Slide 11

Slide 11 text

มԽͷ͖͔͚ͬ • プランナーとの関係で悩んでいた時期にちょうど会社にそういった悩みをサポートする横断組織ができたのを聞いてサポートを依頼 • サポートに来た⼈なんか⾒たことある！ < 振り返りワークショップやるで

Slide 12

Slide 12 text

νʔϜͷมԽͷي੻

Slide 13

Slide 13 text

2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フロントエンドのエンジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に受けるScrumトレーニング 2018/04 リモートランチ 2018/03 ディスカッションを通して作る、要求、仕様の伝え⽅の共通認識 Scrumಋೖલ

Slide 14

Slide 14 text

2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フロントエンドのエンジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に受けるScrumトレーニング 2018/04 リモートランチ 2018/03 ディスカッションを通して作る、要求、仕様の伝え⽅の共通認識 ि1ͷৼΓฦΓͷಋೖ

Slide 15

Slide 15 text

ि1ͷৼΓฦΓͷಋೖ • 今までも⼤きなリリースの後にKPTスタイルでの振り返りはやっていたが、ProblemもTryもたくさん出すぎて、その後のアクションも実⾏されないものも多かった • 振り返りワークショップで私が学んだこと • ”ͳΔ΂͘සൟͰܧଓతͳվળ”の⼤事さ • 出て来たProblemを全部議論しようとすることより、ॏཁͳ΋ͷ ͔ΒΞΫγϣϯͰ͖Δようにしっかり議論することが⼤事

Slide 16

Slide 16 text

ि1ͷৼΓฦΓͷ͸͡ΊͷҰา • 起きていた問題: • プランナーが仕様を検討する時間を取るのに間があったり、漏れてしまったりし、その間開発が⽌まる。仕様のドキュメント反映漏れが起きる。という問題があった

Slide 17

Slide 17 text

ि1ͷৼΓฦΓͷ͸͡ΊͷҰา • やったこと: • エンジニアの⽅がどうすべきかわかっている場合もあるので、࢓༷ ͷఏҊをし、ϓϥϯφʔଆͷ0,Λ଴ͨͣに実装は進める • Slackで仕様質問するときはピンどめして、未解決の問題を明確にし、また解決のステータスをリアクションで表現する

Slide 18

Slide 18 text

ଟݴޠ؀ڥͰͷৼΓฦΓ • 共通⾔語がない中での振り返りは難しい • ⽇本語ネイティブ3⼈で残りの5⼈はそれぞれ⺟国語は英語じゃないけど英語の⽅が得意という状況 • やっていること • Slackを使⽤した振り返り • 英語でも⽇本語でもかけるし、もしわからなかったらそのまま google translateとかで翻訳できる

Slide 19

Slide 19 text

ଟݴޠ؀ڥͰͷৼΓฦΓ • やっていること • リアクションを使った投票

Slide 20

Slide 20 text

2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フロントエンドのエンジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に受けるScrumトレーニング 2018/04 リモートランチ 2018/03 ディスカッションを通して作る、要求、仕様の伝え⽅の共通認識 σΟεΧογϣϯΛ௨ͯ͠࡞Δɺཁٻɺ࢓༷ ͷ఻͑ํͷڞ௨ೝࣝ

Slide 21

Slide 21 text

σΟεΧογϣϯΛ௨ͯ͠࡞Δɺཁٻɺ࢓༷ͷ఻͑ ํͷڞ௨ೝࣝ • 起きていた問題: • プランナーが仕様書を作っていたが、エンジニア/QAメンバーはその書きっぷりに不満を持っていた • やったこと: • そもそもԿΛ࢓༷ॻʹॻ͍ͯཉ͍͔͠ちゃんと伝えていなかったかも？ • メンバーがそれぞれ࢓༷Λॻ͘໨తɺԿΛؾΛ͚ͭͨΒΑ͍͔ڞ ༗し、進⾏中の機能の仕様書を今後の⾒本となるものにした

Slide 22

Slide 22 text

σΟεΧογϣϯΛ௨ͯ͠࡞Δɺཁٻɺ࢓༷ͷ఻͑ ํͷڞ௨ೝࣝ • どうなった: • 振り返りで仕様書が良くなったという意⾒が上がる • 質問のやりとりをする回数が減った • 書き⽅が決まっていて書きやすいため、その場で回答して仕様書に反映されないということが減った

Slide 23

Slide 23 text

2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フロントエンドのエンジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に受けるScrumトレーニング 2018/04 リモートランチ 2018/03 ディスカッションを通して作る、要求、仕様の伝え⽅の共通認識 αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχ Ξͷॿ͚߹͍

Slide 24

Slide 24 text

αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχΞͷॿ ͚߹͍ • 起きていた問題 • QAによる⼿動テストが始まった段階でフロントエンドの起因と思われるバグの修正がフロントエンドエンジニアが2名しかいないこともありボトルネックになる • サーバーサイドとフロントエンドはそれぞれߴ͍ઐ໳ੑを持つことを期待されていて、ͦΕͧΕͰ࠾༻͕ߦΘΕɺผͷ෦ॺʹ ॴଐ͍ͯ͠ΔͨΊɺ結構お互い領域には踏み込み⾟い

Slide 25

Slide 25 text

αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχΞͷॿ ͚߹͍ • やったこと • 最初はQAメンバーによるテスト期間でόά͕ग़ͨ࣌には、余裕のあるサーバーサイドメンバーが積極的に໰୊ͷ੾Γ෼͚をする

Slide 26

Slide 26 text

2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フロントエンドのエンジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に受けるScrumトレーニング 2018/04 リモートランチ 2018/03 ディスカッションを通して作る、要求、仕様の伝え⽅の共通認識 ϦϞʔτϥϯν&ࡶஊSlackνϟϯωϧ

Slide 27

Slide 27 text

ϦϞʔτϥϯν • 起きていた問題: • リモートだとどうしても話すときは必要最低限のことのみ話がち東京のプランナー

Slide 28

Slide 28 text

ࡶஊSlackνϟϯωϧ • 要求・仕様の作り⽅の議論の中で本をオススメしたりする流れになり専⽤のチャンネルを作ることになる東京のプランナー

Slide 29

Slide 29 text

2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フロントエンドのエンジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に受けるScrumトレーニング 2018/04 リモートランチ 2018/03 ディスカッションを通して作る、要求、仕様の伝え⽅の共通認識 ϓϥϯφʔͱҰॹʹड͚Δ ScrumτϨʔχϯά

Slide 30

Slide 30 text

ϓϥϯφʔͱҰॹʹड͚ΔScrumτϨʔχϯά • 動機 • Scrumから学ぼう • プランナーとエンジニアで開発プロセスに関して共通の⾔葉・認識を作ろう東京のプランナー

Slide 31

Slide 31 text

ϓϥϯφʔͱҰॹʹड͚ΔScrumτϨʔχϯά • 結果 • Scrumが始まった • トレーニング受ける前はScrumから学ぼうというスタンスだったが全容を知って、興味はあるけどハードルが⾼いという印象が解消され、4DSVNࣗମΛಋೖ͢Δことになる • Scrumの背景やフレームワーク全体をϓϥϯφʔ΋஌ͬͯ ͍Δので導⼊がスムーズ

Slide 32

Slide 32 text

ϓϥϯφʔͱҰॹʹड͚ΔScrumτϨʔχϯά • 結果 • アジャイルマニフェストを読んでの議論したりすることを通して、チームの中のྑ͍։ൃϓϩηεͱ͸Կ͔ͱ͍͏͜ͱʹؔ͠ ͯϝϯόʔͦΕͧΕͷߟ͑ํͷҙݟͷަ׵͕Ͱ͖ͨ • ドキュメントは必要なこともあるよね？どういう時？ • ただ動くためだけのものを作るだと技術的負債が。。

Slide 33

Slide 33 text

2018/10 E2Eテスト 2018/08 モブレビュー・モブプログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロントエンドのエンジニアの助け合い Scrumಋೖޙ Scrum開始にあたっての準備

Slide 34

Slide 34 text

2018/10 E2Eテスト 2018/08 モブレビュー・モブプログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロントエンドのエンジニアの助け合い Scrum։࢝ʹ͋ͨͬͯͷ४උ Scrum開始にあたっての準備

Slide 35

Slide 35 text

Scrum࢝ΊΔʹ͋ͨͬͯ • PO誰にしよう? • 事情によりプランナーの中からは10ཱͯΒΕͳ͍ • 制約ある上での苦⾁の策として • エンジニアの中に1SPYZ10を⽴てる • Product Backlog Refinementを2フェーズに分ける ౦ژ ෱Ԭ プランナー Proxy PO QA Scrum Master 開発チーム “Pre” Product Backlog Refinement Product Backlog Refinement

Slide 36

Slide 36 text

Product Backlog Refinementを2フェーズに分ける • 優先順位⾒直しがメインの”1SFz Product Backlog Refinement • プランナーとProxy POとQA⾏う⼀種のPOチームな感じ • 施策の内容と⽬的の共有も⾏う • タスク分割と⾒積もりがメインのProduct Backlog Refinement • 施策の内容と⽬的の共有を英語で⾏う • Proxy POはPre Product Backlog Refinement以外でもプランナーと密に連携して施策を仕様に落とし込む

Slide 37

Slide 37 text

• 3FNPUF 4QSJOU 3FWJFX • Sprint Reviewにはプランナーもステークホルダーとして参加する • テレビ会議でつなぐ • QuickTime Playerのレコーディング機能を使ってスマホの画⾯を共有

Slide 38

Slide 38 text

ଟݴޠ؀ڥͰͷͳΒͰ͸ͷऔΓ૊Έ • Daily Scrumの前のアイスブレイク • ローテーションしているファシリテーターは勉強している⾔語で近況を話す • コミュニケーションで気をつけていること • ೔ຊਓಉ࢜Ͱ೔ຊޠΛ࿩࣌͢΋、ゆっくり、簡単な単語で話す • 英語に⾃信がないときは೔ຊޠ΋ॻ͘ • ⽂字でコミュニケーションをするときは׽ࣈΛଟ͘࢖͏

Slide 39

Slide 39 text

৬ೳܕ૊৫ͷ੍໿ʹ͓͚ΔScrum • ⼿動テストメンバーはアウトソースであり、すべてのScrumイベントに参加するのが難しい(リーダー2⼈はSprint Review/Retrospectiveには参加) • やっていること • 仕様書作成にQA観点を盛り込む • リリース前に最終チェックを⾏う • 以前のSprintで開発した機能の最終テストをSprintでの新規機能開発と並⾏して⾏う QAのリーダー2⼈はすべてのScrumイベントに参加するよう調整中！

Slide 40

Slide 40 text

2018/10 E2Eテスト 2018/08 モブレビュー・モブプログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロントエンドのエンジニアの助け合い αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχ Ξͷॿ͚߹͍ Scrum開始にあたっての準備

Slide 41

Slide 41 text

αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχΞͷॿ ͚߹͍ • 起きていた問題: • フロントエンドメンバーの1名離任よりフロントエンドが前よりボトルネックになりがちになる

Slide 42

Slide 42 text

αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχΞͷॿ ͚߹͍ • やったこと: • フロントエンドメンバーが最初の環境構築を他のメンバーに伝える場が開催されて、αʔόʔαΠυͷϝϯόʔ΋ϑϩϯ τΤϯυλεΫΛ΍Δようになる

Slide 43

Slide 43 text

2018/10 E2Eテスト 2018/08 モブレビュー・モブプログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロントエンドのエンジニアの助け合い ϞϒϓϩάϥϛϯάɾϞϒϨϏϡʔͷಋೖ Scrum開始にあたっての準備

Slide 44

Slide 44 text

ϞϒϓϩάϥϛϯάɾϞϒϨϏϡʔͷಋೖ • 起きていた問題: • 1週間スプリントで難しいタスクをレビュー済みまで持って⾏くのは難しい • やったこと: • 以前から開発リードである⾃分からモブプログラミングやろうということはあったがScrumを初めてϝϯόʔ͔Βࣗൃతにやろうという話が出る

Slide 45

Slide 45 text

2018/10 E2Eテスト 2018/08 モブレビュー・モブプログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロントエンドのエンジニアの助け合い ϦϞʔτҿΈձ Scrum開始にあたっての準備

Slide 46

Slide 46 text

ϦϞʔτҿΈձ • リモートランチの発展系 • Zoomで家から参加 • ⼦供が⼩さくて通常の飲み会に参加できない⼈も参加できる • 飲んだ後電⾞に乗って帰らなくていい

Slide 47

Slide 47 text

2018/10 E2Eテスト 2018/08 モブレビュー・モブプログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロントエンドのエンジニアの助け合い E2Eςετ Scrum開始にあたっての準備

Slide 48

Slide 48 text

E2Eςετ • 起きていた問題 • フロントエンドのバグ多い • やったこと: • 社内のテスト⾃動化チームの⼒を借りて導⼊ • 現在は時間がかかるリグレッションテストに特化

Slide 49

Slide 49 text

2018/10 E2Eテスト 2018/08 モブレビュー・モブプログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロントエンドのエンジニアの助け合い σβΠφʔͱͷີͳڠۀ(WIP) Scrum開始にあたっての準備

Slide 50

Slide 50 text

σβΠφʔͱͷີͳڠۀ(WIP) • 起きている問題 • デザインカンプ完成後、フロントエンドエンジニアリングの制約を考慮していないため確認のやりとりが発⽣しリードタイムが伸びる • 物理的に同じ場所にいないためJIRAやSlackを使った⾮同期のデザインをレビューしているがこちらもリードタイムを伸ばしがち

Slide 51

Slide 51 text

σβΠφʔͱͷີͳڠۀ(WIP) • やろうとしていること: • デザイナーのためのWeb UIデザインガイドラインを作成 • Zoomやテレビ会議システムを利⽤したデザインレビュー

Slide 52

Slide 52 text

結局どういうことをやってきたか ·ͱΊ

Slide 53

Slide 53 text

ϓϥϯφʔͱΤϯδχΞͷೝࣝ߹Θͤ • ディスカッションを通して作る、要求、仕様の伝え⽅の共通認識 • プランナーと⼀緒に受けるscrumトレーニング • Scrumの導⼊ • Pre Product Backlog Refinement • ふんわりとしたアイデアの段階からエンジニアが⼊ることで⼿戻りがほぼなくなった • Sprint Review • 早めのフィードバックがプランナー、QAからもらえるので最終⼿動テストで仕様バグ、認識違いがほぼなくなった

Slide 54

Slide 54 text

ৼΓฦΓ΍ScrumʹΑΔνʔϜվળ • 週⼀の振り返りの導⼊ • Scrumの導⼊ • サーバーサイド、フロントエンドエンジニアの助け合い • モブレビュー、モブプログラミングの導⼊ • E2Eテスト

Slide 55

Slide 55 text

ࡶஊΛ૿΍͢ • リモートランチ • リモート飲み会

Slide 56

Slide 56 text

΋ͱ΋ͱ͋ͬͨ՝୊͸Ͳ͏ͳͬͨʁ

Slide 57

Slide 57 text

ΤϯδχΞ͕͍࣋ͬͯͨ՝୊ • ⾒積もり前にビジネス側で開発のスコープとデッドラインが決めないでほしい • 規模が⼤きくなると⾒積もりが曖昧になり、開発が進むにつれて不確かさが減って⾒積もりが正確になることに関して共通認識が⽣まれた • 開発する機能に関して背景や⽬的があまり納得できない • product backlog refinementやsprint planningによる情報共有

Slide 58

Slide 58 text

ΤϯδχΞ͕͍࣋ͬͯͨ՝୊ • 開発する機能の優先順位がわからない • product backlogによる明確な優先順位管理 • プランナー側が作成する要求や仕様が不正確だったり、不⼗分だったりするせいで、開発期間が延びていると感じているのに理解されていない気がする • 期待値を共有することで仕様書の質が上がった • エンジニア側から積極的に仕様提案をするようになった • readyにならないbacklog itemは開発着⼿しない

Slide 59

Slide 59 text

ϓϥϯφʔ͕͍࣋ͬͯͨ՝୊ • エンジニア側の⾒積もりが適切かわからない • トレーニングを受けたことにより⾒積もり⽅への理解が⾼まったので、エンジニアも率直に”これはバッファーない⾒積もりです“と伝えるようになった • エンジニア側が⼗分に効率よく働けているかわからな • トレーニングでどのように働いているかが明確になり、 sprint retrospectiveでリードタイム短くするために⽇々改善されていることがわかる

Slide 60

Slide 60 text

ϓϥϯφʔ͕͍࣋ͬͯͨ՝୊ • エンジニアの売り上げ/デッドラインに対するコミットメントが低いように感じる • sprint goalを達成するために働いていることが明確に • 変更を柔軟に取り⼊れてデッドラインも守るようにしてほしい • sprint中の差し込みは基本的には許容していないが、次のsprintには差し込める差し込みによって⼤きな機能追加のデッドラインにどのように影響があるかわかる

Slide 61

Slide 61 text

ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γ ํͱ͸

Slide 62

Slide 62 text

ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γํ • ৼΓฦΓ͕νʔϜͷࣗ཯Λଅ͢ • 元から細かい指⽰をしないと動けない⼈はいなかったが、今まではチームも問題を考える時間がなく、⾒つけたとしてもそれをどう解決したらよいか、どう他の⼈を巻き込んだらよいか不明だったところ振り返りという、໰୊ΛνʔϜશମʹڞ༗ͯ͠チーム全体で取り組むという仕組みがあることでࣗ෼΋νʔϜશମʹӨ ڹΛ͓Α΅ͤΔͱࢥ͏ことが出来るようになる

Slide 63

Slide 63 text

ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γํ • プランナーとエンジニアの協調 • 仕様の作成⽅法にしろ開発プロセスにしろҰॹʹ࡞Γ্ ͛ͯߦ͘過程で様々な価値観を共有でき、できたものに納得感が持てる • 雑談で௚ۙͷ࢓ࣄͱ௚઀ؔ܎ͳ͍࿩をすることでプロダクトに対する姿勢や価値観を共有する

Slide 64

Slide 64 text

ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γํ • 開発チーム内での協調 • sprint goalはチーム全体のখ͞ͳ໨ඪでそれを達成するためになにをすればよいか考えるため、ϘτϧωοΫͱͳ Δͱ͜ΛօͰղফ͠Α͏と⾔うことになる

Slide 65

Slide 65 text

ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γํ • ·ͣৼΓฦΓͷಋೖ͍ͯͨ͠ • 振り返りだけなのでハードルが低いしここで、⾃律的な動きをする地盤ができていた • ϓϥϯφʔ΋ҰॹʹScrumτϨʔχϯάΛड͚ͨ • ステークホルダーの理解が容易に得られた • ॳظ͸ৼΓฦΓͰͳͥsprint goalΛୡ੒Ͱ͖ͳ͍͔ߟ͑ͨ • 皆でチーム全体のリードタイムを短くするにはどうすれば良いのかを考える習慣がついた

Slide 66

Slide 66 text

νʔϜͱͯ͠΋ͨΒͨ͠΋ͷ

Slide 67

Slide 67 text

νʔϜͱͯ͠΋ͨΒͨ͠΋ͷ • 13ϨϏϡʔϦʔυλΠϜͷݮগ

Slide 68

Slide 68 text

νʔϜͱͯ͠΋ͨΒͨ͠΋ͷ • 2"࠷ऴνΣοΫϑΣʔζͰͷόάͷݮগ Scrum後 Scrum前

Slide 69

Slide 69 text

νʔϜͱͯ͠΋ͨΒͨ͠΋ͷ • みんな楽しい • 年末の振り返りでのFun-Done-Learn • νʔϜʹೖͬͯྑ͔ͬͨという 'VO • εΫϥϜͷ։࢝という'VO %POF-FBSO

Slide 70

Slide 70 text

Agile/Scrumͱग़ձͬͯࣗ෼ͷத ͰมΘͬͨ͜ͱ

Slide 71

Slide 71 text

ࣗ෼ͷதͰมΘͬͨ͜ͱ • ⽴場や考え⽅が違うと思う⼈に対しても、খ͞ͳาΈدΓ͔ΒॳΊ ͯɺ͏·͘ڠௐͰ͖Δことがあると思えるようになった • もともと⾦融系のSIer出⾝ということもあってか責任範囲を過剰に捉えたり、衝突が発⽣しそうなときは強く主張して交渉で物事を解決するような傾向にあった • でも⾃分の中のนΛऔͬ෷͑Δようになってきた感覚がある

Slide 72

Slide 72 text

ࣗ෼ͷதͰมΘͬͨ͜ͱ • ͏·͘ߦͬͨ΢ΥʔλʔϑΥʔϧͷͦͷઌがあることを知った • 今までは、割りと⼤きな機能開発や初期開発がスケジュール通りに⾏けば満⾜で、なぜならιϑτ΢ΣΞ։ൃ೉ͯ͘͠େମԌ ্ͨ͠Γɺ஗Ԇͨ͠Γ͢Δのに⾃分の今までの経験から炎上しない開発を出来てきたってのを⾃慢に思ってたが、Agile/Scrum と出会って、その先があることを知った

Slide 73

Slide 73 text

ࣗ෼ͷதͰมΘͬͨ͜ͱ • リードタイムを重視する。WIP制限を設けて並⾏で取り組むタスクをがあまりないため、ॠؒख͕ۭ͍͍ͯΔϝϯόʔ͕ग़ͯ͘Δ͜ͱ ͕͋Δ͚Ͳ͋·Γؾʹ͠ͳ͍ようになる • mtgや直接喋る同期的なコミュニケーションを全否定しない。むしろリードタイムを短く出来るならੵۃతʹϑΣΠετΡʔϑΣΠε ͷձ࿩Λଅ͢

Slide 74

Slide 74 text

THANK YOU