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

Agile/Scrum へ取り組むことで、プランナー・エンジニア間の課題が解消し協調的に取り組めるようになり、チームがより自律的に動けるように成長していくお話
https://confengine.com/regional-scrum-gathering-tokyo-2019/proposal/8175/scrum

Transcript

1. 中村亮介 – LINE Fukuoka株式会社 ⾃律的で協調的なチームの作り⽅ ~複数拠点、多⾔語、職能型組織で始めるScrum~
2. Agenda • プロダクトやチーム、チームの課題について • チームの変化の軌跡 • 変化の後課題はどうなった? • ⾃律的で協調的なチームの作り⽅とは​ • チームにもたらしたもの・⾃分の中で変わった こと​
3. ϓϩμΫτ΍νʔϜɺνʔϜͷ՝ ୊ʹ͍ͭͯ
4. • 開発チーム リーダー • サーバーサイドエンジニア • 社内アジャイルコーチ兼務 Weʼre hiring! https://linecorp.com/ja/care er/position/1405 ࣗݾ঺հ
5. ϓϩμΫτʹ͍ͭͯ トーク占い • LINEのトークルームでチャット or 電話で 占い師に相談できる
6. ϓϩμΫτʹ͍ͭͯ トークCARE • 恋愛・仕事・⼈間関係の悩みについてカウンセラーに相談できる
7. νʔϜʹ͍ͭͯ • チームは東京と福岡に分散している • プランナー/デザイナー/エンジニア/QAはそれぞれ違う組織 東京 プランナー デザイナー 福岡 エンジニア QA
8. ࿩͢͜ͱ • Agile/Scrum へ取り組むことで、プランナー・エンジニア間の՝୊ ͕ղফし協調的に取り組めるようになり、チームがより⾃律的に動 けるように੒௕͍͓ͯ͘͠࿩ • 現在進⾏系で課題を抱えている⽅ • ここにも悩んでいる⼈がいるということが知れます • 百戦錬磨の⽅ • Agile/Scrum取り組みのやり始めの⼈が何考えているか知れます • マサカリください
9. νʔϜ͕͍࣋ͬͯͨ՝୊ • エンジニアが持っていた課題 • ⾒積もり前にビジネス側で開発のείʔϓͱσουϥΠϯΛܾΊͳ͍Ͱ΄͠ ͍ • 開発する機能に関してഎܠ΍໨త͕͋·ΓೲಘͰ͖ͳ͍ • 開発する機能の༏ઌॱҐ͕Θ͔Βͳ͍ • プランナー側が作成するཁٻ΍࢓༷͕ෆਖ਼֬だったり、不⼗分だったりする せいで、։ൃظ͕ؒԆͼ͍ͯΔと感じているのに理解されていない気がする
10. νʔϜ͕͍࣋ͬͯͨ՝୊ • プランナーが持っていた課題 • エンジニア側のݟੵ΋Γ͕ద੾͔Θ͔Βͳ͍ • エンジニア側がे෼ʹޮ཰Α͘ಇ͚͍ͯΔ͔Θ͔Βͳ͍ • エンジニアのചΓ্͛కΊ੾Γʹର͢Δίϛοτϝϯτ͕௿͍ように感じ る • มߋΛॊೈʹऔΓೖΕͯσουϥΠϯ΋कΔようにしてほしい
11. มԽͷ͖͔͚ͬ • プランナーとの関係で悩んでいた時期にちょうど会社にそういった 悩みをサポートする横断組織ができたのを聞いてサポートを依頼 • サポートに来た⼈なんか⾒たことある！ < 振り返りワークショップやるで
12. νʔϜͷมԽͷي੻
13. 2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フ ロントエンドのエン ジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に 受けるScrumトレー ニング 2018/04 リモートランチ 2018/03 ディスカッションを 通して作る、要求、 仕様の伝え⽅の共通 認識 Scrumಋೖલ
14. 2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フ ロントエンドのエン ジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に 受けるScrumトレー ニング 2018/04 リモートランチ 2018/03 ディスカッションを 通して作る、要求、 仕様の伝え⽅の共通 認識 ि1ͷৼΓฦΓͷಋೖ
15. ि1ͷৼΓฦΓͷಋೖ • 今までも⼤きなリリースの後にKPTスタイルでの振り返りはやって いたが、ProblemもTryもたくさん出すぎて、その後のアクションも 実⾏されないものも多かった • 振り返りワークショップで私が学んだこと • ”ͳΔ΂͘සൟͰܧଓతͳվળ”の⼤事さ • 出て来たProblemを全部議論しようとすることより、ॏཁͳ΋ͷ ͔ΒΞΫγϣϯͰ͖Δようにしっかり議論することが⼤事
16. ि1ͷৼΓฦΓͷ͸͡ΊͷҰา • 起きていた問題: • プランナーが仕様を検討する時間を取るのに間があったり、漏れて しまったりし、その間開発が⽌まる。仕様のドキュメント反映漏れ が起きる。という問題があった
17. ि1ͷৼΓฦΓͷ͸͡ΊͷҰา • やったこと: • エンジニアの⽅がどうすべきかわかっている場合もあるので、࢓༷ ͷఏҊをし、ϓϥϯφʔଆͷ0,Λ଴ͨͣに実装は進める • Slackで仕様質問するときはピンどめして、未解決の問題を明確に し、また解決のステータスをリアクションで表現する
18. ଟݴޠ؀ڥͰͷৼΓฦΓ • 共通⾔語がない中での振り返りは難しい • ⽇本語ネイティブ3⼈で残りの5⼈はそれぞれ⺟国語は英語 じゃないけど英語の⽅が得意という状況 • やっていること • Slackを使⽤した振り返り • 英語でも⽇本語でもかけるし、も しわからなかったらそのまま google translateとかで翻訳できる
19. ଟݴޠ؀ڥͰͷৼΓฦΓ • やっていること • リアクションを使った投票
20. 2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フ ロントエンドのエン ジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に 受けるScrumトレー ニング 2018/04 リモートランチ 2018/03 ディスカッションを 通して作る、要求、 仕様の伝え⽅の共通 認識 σΟεΧογϣϯΛ௨ͯ͠࡞Δɺཁٻɺ࢓༷ ͷ఻͑ํͷڞ௨ೝࣝ
21. σΟεΧογϣϯΛ௨ͯ͠࡞Δɺཁٻɺ࢓༷ͷ఻͑ ํͷڞ௨ೝࣝ • 起きていた問題: • プランナーが仕様書を作っていたが、エンジニア/QAメンバーは その書きっぷりに不満を持っていた • やったこと: • そもそもԿΛ࢓༷ॻʹॻ͍ͯཉ͍͔͠ちゃんと伝えていなかった かも？ • メンバーがそれぞれ࢓༷Λॻ͘໨తɺԿΛؾΛ͚ͭͨΒΑ͍͔ڞ ༗し、進⾏中の機能の仕様書を今後の⾒本となるものにした
22. σΟεΧογϣϯΛ௨ͯ͠࡞Δɺཁٻɺ࢓༷ͷ఻͑ ํͷڞ௨ೝࣝ • どうなった: • 振り返りで仕様書が良くなったという意⾒が上がる • 質問のやりとりをする回数が減った • 書き⽅が決まっていて書きやすいため、その場で回答して仕様書 に反映されないということが減った
23. 2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フ ロントエンドのエン ジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に 受けるScrumトレー ニング 2018/04 リモートランチ 2018/03 ディスカッションを 通して作る、要求、 仕様の伝え⽅の共通 認識 αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχ Ξͷॿ͚߹͍
24. αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχΞͷॿ ͚߹͍ • 起きていた問題 • QAによる⼿動テストが始まった段階でフロントエンドの起因と 思われるバグの修正がフロントエンドエンジニアが2名しかいな いこともありボトルネックになる • サーバーサイドとフロントエンドはそれぞれߴ͍ઐ໳ੑを持つ ことを期待されていて、ͦΕͧΕͰ࠾༻͕ߦΘΕɺผͷ෦ॺʹ ॴଐ͍ͯ͠ΔͨΊɺ結構お互い領域には踏み込み⾟い
25. αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχΞͷॿ ͚߹͍ • やったこと • 最初はQAメンバーによるテスト期間でόά͕ग़ͨ࣌には、余裕 のあるサーバーサイドメンバーが積極的に໰୊ͷ੾Γ෼͚をす る
26. 2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フ ロントエンドのエン ジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に 受けるScrumトレー ニング 2018/04 リモートランチ 2018/03 ディスカッションを 通して作る、要求、 仕様の伝え⽅の共通 認識 ϦϞʔτϥϯν&ࡶஊSlackνϟϯωϧ
27. ϦϞʔτϥϯν • 起きていた問題: • リモートだとどうしても話すとき は必要最低限のことのみ話がち 東京のプランナー
28. ࡶஊSlackνϟϯωϧ • 要求・仕様の作り⽅の議論の中で本をオススメしたりする流れにな り専⽤のチャンネルを作ることになる 東京のプランナー
29. 2018/04 雑談Slackチャンネル 2018/04 サーバーサイド、フ ロントエンドのエン ジニアの助け合い 2018/02 週1の振り返りの導⼊ 2018/06 プランナーと⼀緒に 受けるScrumトレー ニング 2018/04 リモートランチ 2018/03 ディスカッションを 通して作る、要求、 仕様の伝え⽅の共通 認識 ϓϥϯφʔͱҰॹʹड͚Δ ScrumτϨʔχϯά
30. ϓϥϯφʔͱҰॹʹड͚ΔScrumτϨʔχϯά • 動機 • Scrumから学ぼう • プランナーとエンジニアで開 発プロセスに関して共通の⾔ 葉・認識を作ろう 東京のプランナー
31. ϓϥϯφʔͱҰॹʹड͚ΔScrumτϨʔχϯά • 結果 • Scrumが始まった • トレーニング受ける前はScrumから学ぼうというスタンス だったが全容を知って、興味はあるけどハードルが⾼いと いう印象が解消され、4DSVNࣗମΛಋೖ͢Δことになる • Scrumの背景やフレームワーク全体をϓϥϯφʔ΋஌ͬͯ ͍Δので導⼊がスムーズ
32. ϓϥϯφʔͱҰॹʹड͚ΔScrumτϨʔχϯά • 結果 • アジャイルマニフェストを読んでの議論したりすることを通し て、チームの中のྑ͍։ൃϓϩηεͱ͸Կ͔ͱ͍͏͜ͱʹؔ͠ ͯϝϯόʔͦΕͧΕͷߟ͑ํͷҙݟͷަ׵͕Ͱ͖ͨ • ドキュメントは必要なこともあるよね？どういう時？ • ただ動くためだけのものを作るだと技術的負債が。。
33. 2018/10 E2Eテスト 2018/08 モブレビュー・モブプ ログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な 協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロ ントエンドのエンジニ アの助け合い Scrumಋೖޙ Scrum開始にあたっ ての準備
34. 2018/10 E2Eテスト 2018/08 モブレビュー・モブプ ログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な 協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロ ントエンドのエンジニ アの助け合い Scrum։࢝ʹ͋ͨͬͯͷ४උ Scrum開始にあたっ ての準備
35. Scrum࢝ΊΔʹ͋ͨͬͯ • PO誰にしよう? • 事情によりプランナーの中からは10ཱͯΒΕͳ͍ • 制約ある上での苦⾁の策として • エンジニアの中に1SPYZ
    10を⽴てる • Product Backlog Refinementを2フェーズに分ける ౦ژ ෱Ԭ プランナー Proxy PO QA Scrum Master 開発チーム “Pre” Product Backlog Refinement Product Backlog Refinement
36. Product Backlog Refinementを2フェーズに分ける • 優先順位⾒直しがメインの”1SFz Product Backlog Refinement • プランナーとProxy POとQA⾏う⼀種のPOチームな感じ • 施策の内容と⽬的の共有も⾏う • タスク分割と⾒積もりがメインのProduct Backlog Refinement • 施策の内容と⽬的の共有を英語で⾏う • Proxy POはPre Product Backlog Refinement以外でもプランナー と密に連携して施策を仕様に落とし込む
37. • 3FNPUF 4QSJOU 3FWJFX • Sprint Reviewにはプランナーもステークホル ダーとして参加する • テレビ会議でつなぐ • QuickTime Playerのレコーディング機能を 使ってスマホの画⾯を共有
38. ଟݴޠ؀ڥͰͷͳΒͰ͸ͷऔΓ૊Έ • Daily Scrumの前のアイスブレイク • ローテーションしているファシリテーターは勉強している⾔語 で近況を話す • コミュニケーションで気をつけていること • ೔ຊਓಉ࢜Ͱ೔ຊޠΛ࿩࣌͢΋、ゆっくり、簡単な単語で話す • 英語に⾃信がないときは೔ຊޠ΋ॻ͘ • ⽂字でコミュニケーションをするときは׽ࣈΛଟ͘࢖͏
39. ৬ೳܕ૊৫ͷ੍໿ʹ͓͚ΔScrum • ⼿動テストメンバーはアウトソースであり、すべてのScrumイベン トに参加するのが難しい(リーダー2⼈はSprint Review/Retrospectiveには参加) • やっていること • 仕様書作成にQA観点を盛り込む • リリース前に最終チェックを⾏う • 以前のSprintで開発した機能の最終テストをSprintでの新規機 能開発と並⾏して⾏う QAのリーダー2⼈はすべてのScrumイベントに参加するよう調整中！
40. 2018/10 E2Eテスト 2018/08 モブレビュー・モブプ ログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な 協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロ ントエンドのエンジニ アの助け合い αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχ Ξͷॿ͚߹͍ Scrum開始にあたっ ての準備
41. αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχΞͷॿ ͚߹͍ • 起きていた問題: • フロントエンドメンバーの1名離任よりフロントエンドが前よ りボトルネックになりがちになる
42. αʔόʔαΠυɺϑϩϯτΤϯυͷΤϯδχΞͷॿ ͚߹͍ • やったこと: • フロントエンドメンバーが最初の環境構 築を他のメンバーに伝える場が開催され て、αʔόʔαΠυͷϝϯόʔ΋ϑϩϯ τΤϯυλεΫΛ΍Δようになる
43. 2018/10 E2Eテスト 2018/08 モブレビュー・モブプ ログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な 協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロ ントエンドのエンジニ アの助け合い ϞϒϓϩάϥϛϯάɾϞϒϨϏϡʔͷಋೖ Scrum開始にあたっ ての準備
44. ϞϒϓϩάϥϛϯάɾϞϒϨϏϡʔͷಋೖ • 起きていた問題: • 1週間スプリントで難しいタスクをレビュー済みまで持って⾏ くのは難しい • やったこと: • 以前から開発リードである⾃分からモブプログラミングやろう ということはあったがScrumを初めてϝϯόʔ͔Βࣗൃతにや ろうという話が出る
45. 2018/10 E2Eテスト 2018/08 モブレビュー・モブプ ログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な 協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロ ントエンドのエンジニ アの助け合い ϦϞʔτҿΈձ Scrum開始にあたっ ての準備
46. ϦϞʔτҿΈձ • リモートランチの発展系 • Zoomで家から参加 • ⼦供が⼩さくて通常の飲み会 に参加できない⼈も参加でき る • 飲んだ後電⾞に乗って帰らな くていい
47. 2018/10 E2Eテスト 2018/08 モブレビュー・モブプ ログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な 協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロ ントエンドのエンジニ アの助け合い E2Eςετ Scrum開始にあたっ ての準備
48. E2Eςετ • 起きていた問題 • フロントエンドのバグ多い • やったこと: • 社内のテスト⾃動化チーム の⼒を借りて導⼊ • 現在は時間がかかるリグ レッションテストに特化
49. 2018/10 E2Eテスト 2018/08 モブレビュー・モブプ ログラミングの導⼊ 2018/07 2018/11 デザイナーとの密な 協業(WIP) 2018/09 リモート飲み会 2018/08 サーバーサイド、フロ ントエンドのエンジニ アの助け合い σβΠφʔͱͷີͳڠۀ(WIP) Scrum開始にあたっ ての準備
50. σβΠφʔͱͷີͳڠۀ(WIP) • 起きている問題 • デザインカンプ完成後、フロントエンドエンジニアリングの制約 を考慮していないため確認のやりとりが発⽣しリードタイムが伸 びる • 物理的に同じ場所にいないためJIRAやSlackを使った⾮同期のデザ インをレビューしているがこちらもリードタイムを伸ばしがち
51. σβΠφʔͱͷີͳڠۀ(WIP) • やろうとしていること: • デザイナーのためのWeb UIデザインガイドラインを作成 • Zoomやテレビ会議システムを利⽤したデザインレビュー
52. 結局どういうことをやってきたか ·ͱΊ
53. ϓϥϯφʔͱΤϯδχΞͷೝࣝ߹Θͤ • ディスカッションを通して作る、要求、仕様の伝え⽅の共通認識 • プランナーと⼀緒に受けるscrumトレーニング • Scrumの導⼊ • Pre Product Backlog Refinement • ふんわりとしたアイデアの段階からエンジニアが⼊ることで ⼿戻りがほぼなくなった • Sprint Review • 早めのフィードバックがプランナー、QAからもらえるので最 終⼿動テストで仕様バグ、認識違いがほぼなくなった
54. ৼΓฦΓ΍ScrumʹΑΔνʔϜվળ • 週⼀の振り返りの導⼊ • Scrumの導⼊ • サーバーサイド、フロントエンドエンジニアの助け合い • モブレビュー、モブプログラミングの導⼊ • E2Eテスト
55. ࡶஊΛ૿΍͢ • リモートランチ • リモート飲み会
56. ΋ͱ΋ͱ͋ͬͨ՝୊͸Ͳ͏ͳͬͨʁ
57. ΤϯδχΞ͕͍࣋ͬͯͨ՝୊ • ⾒積もり前にビジネス側で開発のスコープとデッドライ ンが決めないでほしい • 規模が⼤きくなると⾒積もりが曖昧になり、開発が進 むにつれて不確かさが減って⾒積もりが正確になるこ とに関して共通認識が⽣まれた • 開発する機能に関して背景や⽬的があまり納得できない • product backlog refinementやsprint planningによる情 報共有
58. ΤϯδχΞ͕͍࣋ͬͯͨ՝୊ • 開発する機能の優先順位がわからない • product backlogによる明確な優先順位管理 • プランナー側が作成する要求や仕様が不正確だったり、不 ⼗分だったりするせいで、開発期間が延びていると感じて いるのに理解されていない気がする • 期待値を共有することで仕様書の質が上がった • エンジニア側から積極的に仕様提案をするようになった • readyにならないbacklog itemは開発着⼿しない
59. ϓϥϯφʔ͕͍࣋ͬͯͨ՝୊ • エンジニア側の⾒積もりが適切かわからない • トレーニングを受けたことにより⾒積もり⽅への理解 が⾼まったので、エンジニアも率直に”これはバッ ファーない⾒積もりです“と伝えるようになった • エンジニア側が⼗分に効率よく働けているかわからな • トレーニングでどのように働いているかが明確になり、 sprint retrospectiveでリードタイム短くするために ⽇々改善されていることがわかる
60. ϓϥϯφʔ͕͍࣋ͬͯͨ՝୊ • エンジニアの売り上げ/デッドラインに対するコミットメ ントが低いように感じる • sprint goalを達成するために働いていることが明確に • 変更を柔軟に取り⼊れてデッドラインも守るようにしてほ しい • sprint中の差し込みは基本的には許容していないが、次 のsprintには差し込める 差し込みによって⼤きな機能 追加のデッドラインにどのように影響があるかわかる
61. ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γ ํͱ͸
62. ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γํ • ৼΓฦΓ͕νʔϜͷࣗ཯Λଅ͢ • 元から細かい指⽰をしないと動けない⼈はいなかった が、今まではチームも問題を考える時間がなく、⾒つ けたとしてもそれをどう解決したらよいか、どう他の ⼈を巻き込んだらよいか不明だったところ振り返りと いう、໰୊ΛνʔϜશମʹڞ༗ͯ͠チーム全体で取り 組むという仕組みがあることでࣗ෼΋νʔϜશମʹӨ ڹΛ͓Α΅ͤΔͱࢥ͏ことが出来るようになる
63. ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γํ • プランナーとエンジニアの協調 • 仕様の作成⽅法にしろ開発プロセスにしろҰॹʹ࡞Γ্ ͛ͯߦ͘過程で様々な価値観を共有でき、できたものに 納得感が持てる • 雑談で௚ۙͷ࢓ࣄͱ௚઀ؔ܎ͳ͍࿩をすることでプロダ クトに対する姿勢や価値観を共有する
64. ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γํ • 開発チーム内での協調 • sprint goalはチーム全体のখ͞ͳ໨ඪでそれを達成するた めになにをすればよいか考えるため、ϘτϧωοΫͱͳ Δͱ͜ΛօͰղফ͠Α͏と⾔うことになる
65. ࣗ཯తͰڠௐతͳνʔϜ΁ͷ࡞Γํ • ·ͣৼΓฦΓͷಋೖ͍ͯͨ͠ • 振り返りだけなのでハードルが低いしここで、⾃律的な 動きをする地盤ができていた • ϓϥϯφʔ΋ҰॹʹScrumτϨʔχϯάΛड͚ͨ • ステークホルダーの理解が容易に得られた • ॳظ͸ৼΓฦΓͰͳͥsprint goalΛୡ੒Ͱ͖ͳ͍͔ߟ͑ͨ • 皆でチーム全体のリードタイムを短くするにはどうすれ ば良いのかを考える習慣がついた
66. νʔϜͱͯ͠΋ͨΒͨ͠΋ͷ
67. νʔϜͱͯ͠΋ͨΒͨ͠΋ͷ • 13ϨϏϡʔϦʔυλΠϜͷݮগ
68. νʔϜͱͯ͠΋ͨΒͨ͠΋ͷ • 2"࠷ऴνΣοΫϑΣʔζͰͷόάͷݮগ Scrum後 Scrum前
69. νʔϜͱͯ͠΋ͨΒͨ͠΋ͷ • みんな楽しい • 年末の振り返りでのFun-Done-Learn • νʔϜʹೖͬͯྑ͔ͬͨという 'VO • εΫϥϜͷ։࢝という'VO
    %POF
    -FBSO
70. Agile/Scrumͱग़ձͬͯࣗ෼ͷத ͰมΘͬͨ͜ͱ
71. ࣗ෼ͷதͰมΘͬͨ͜ͱ • ⽴場や考え⽅が違うと思う⼈に対しても、খ͞ͳาΈدΓ͔ΒॳΊ ͯɺ͏·͘ڠௐͰ͖Δことがあると思えるようになった • もともと⾦融系のSIer出⾝ということもあってか責任範囲を過 剰に捉えたり、衝突が発⽣しそうなときは強く主張して交渉で 物事を解決するような傾向にあった • でも⾃分の中のนΛऔͬ෷͑Δようになってきた感覚がある
72. ࣗ෼ͷதͰมΘͬͨ͜ͱ • ͏·͘ߦͬͨ΢ΥʔλʔϑΥʔϧͷͦͷઌがあることを知った • 今までは、割りと⼤きな機能開発や初期開発がスケジュール通 りに⾏けば満⾜で、なぜならιϑτ΢ΣΞ։ൃ೉ͯ͘͠େମԌ ্ͨ͠Γɺ஗Ԇͨ͠Γ͢Δのに⾃分の今までの経験から炎上し ない開発を出来てきたってのを⾃慢に思ってたが、Agile/Scrum と出会って、その先があることを知った
73. ࣗ෼ͷதͰมΘͬͨ͜ͱ • リードタイムを重視する。WIP制限を設けて並⾏で取り組むタスク をがあまりないため、ॠؒख͕ۭ͍͍ͯΔϝϯόʔ͕ग़ͯ͘Δ͜ͱ ͕͋Δ͚Ͳ͋·Γؾʹ͠ͳ͍ようになる • mtgや直接喋る同期的なコミュニケーションを全否定しない。むし ろリードタイムを短く出来るならੵۃతʹϑΣΠετΡʔϑΣΠε ͷձ࿩Λଅ͢
74. THANK YOU