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