Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アンチパターンかもしれないがプロジェクトマネジャーがスクラムマスターをやることに意味があると信...
Search
3panda
January 23, 2025
1
800
アンチパターンかもしれないがプロジェクトマネジャーがスクラムマスターをやることに意味があると信じている
3panda
January 23, 2025
Tweet
Share
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
172
14k
Speed Design
sergeychernyshev
27
790
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Scaling GitHub
holman
459
140k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
Designing for Performance
lara
604
68k
Designing for humans not robots
tammielis
250
25k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Transcript
アンチパターンかもしれないがプロジェクトマネ ジャーがスクラムマスターをやることに意味がある と信じている 2025.1.24 事業成⻑へ導く スクラム運⽤ 〜アジャイル組織を推進する ヒントを学ぶ〜 @3panda
⾃⼰紹介 • 名前:シログチ リョウタ /3panda • 職業:スクラムマスター/ アジャイルコーチ • 経歴:
◦ Webフロントエンドエンジニア ◦ ゲームエンジニア ◦ AIベンチャーでプロマネ&EM ◦ フリーランスのスクラムマスター ←イマココ 詳しくはこちら
本⽇お話すること • 私が以前勤めていたAIベンチャーでのお話 • 私が初めてスクラムを取り⼊れたチームでのお話
アジェンダ 1. 私たちはどんなチームだったのか 2. アジャイルのプラクティスをチームにあったやり⽅に⼯夫 3. チームが成⻑するためにおこなった⼯夫 4. 本⽇のまとめ
1.私たちはどんなチームだったのか
担当していたプロジェクト • ⼤⼿企業の研究部⾨様からの研究委託 • ⼤⼿の製造業様からの省⼈化に向けたPoC • ⾃社プロダクトの技術検証 ※イメージです
扱っていたテーマ(例) • AGV(無⼈搬送機) x AIによる⼯場内点検の無⼈化 • ⼈協働ロボット x AIによる作業⼯程の省⼈化 •
深層強化学習による検査ロボットの最適化 • etc ※イメージです
チームの構成 • プロジェクトマネージャー x 1名(私) • アプリケーションエンジニア x 2名 ◦
ロボット‧カメラなどの制御 • ハードウェアエンジニア x 2名 ◦ ロボットやIoTデバイスなど調整やパーツの作成 • AIエンジニア x 1名 ◦ 撮影した画像を判定するAIモデルなど
チームの構成 • 多国籍なチーム ◦ ⽇本⼈ 3⼈ ◦ イタリア⼈ 1⼈ ◦ 中国⼈ 1⼈ ◦
ネパール⼈ 1⼈
余談:私以外はみんな英語が話せる \ I can't speak eng… /
2.アジャイルのプラクティスをチームに あったやり⽅に⼯夫
「スクラム、スクラム」と⾔わずに 気が付いたらスクラムを意識した
チーム内にスクラムへの懸念があった • スクラムの経験者が私だけだった • はじめてのやり⽅でメンバーが困惑していた • MTGが多いという懸念も上がっていた Scrum? Agile? MTG多い...
気がついたらスクラムを⽬指した • 開発のリズムを掴むことに注⼒した • 座学よりも実際にやってみるを意識した • アジャイルの⽤語はあまり使わないようにした
形骸化したデイリースクラムを課題解決 の場にした
デイリースクラムが情報共有の場になっていなかった • 15分で終わらすために慌ただしくなっていた • 進捗報告をだけをする時間になっていた • 抱えている課題を話せる雰囲気ではなかった 昨⽇はXXXをやり ました。 今⽇はXXXをやり
ます。 特に困ったことは ありません。 昨⽇はXXXをやり ました。 今⽇はXXXをやり ます。 特に困ったことは ありません。 昨⽇はXXXをやり ました。 今⽇はXXXをやり ます。 特に困ったことは ありません。
課題解決のきっかけを得る場を⽬指した • 15分で終わることを意識しない • アイスブレイクを挟んで和む場に • 相談や質問が活発化するようにファシリテーション \あれがこれで / \それは、あれが
/ \なるほど /
ゴールの認識合わせに集中した
完成の定義 と 受け⼊れ基準 が難しかった • 何をもって完成とするかが難しかった • 両者の違いが分からずに混乱していた • PBIの完成についての認識違いが多発した
完成の定義 ? 受け入れ基準 ?
ゴールは何かに集中することにした • 完成の定義 と 受け⼊れ基準 という⾔葉を使うのをやめた • ゴールというシンプルな⾔葉に置き換えた • 「このチケットのゴールは?」をチームで考えるようにした
\ゴールはなんだろう? /
スプリントレビューがチーム内共有に なった時も意義あるものにした
ステークホルダーへのレビューが定期的には⾏えなかった • クライアントに1,2週間に⼀度の出席は難しかった • ⾃社の役員や事業オーナーも常に出席は難しかった • プロジェクトマネージャーの視点で私が⾏うことも多々あった ※デモのイメージ
チームだけのレビューでも意義あるものに • ステークホルダー向けのレビューの予⾏練習の場にした • チームだけでもデモを⾏なってFBを出すようにした • 社内の通りすがりの⼈にもデモをしてFBをもらうようにした ※デモのイメージ
ふりかえり⼿法を定番のKPTからその時 のチーム合った「Good or NG」にした
KPTがチームに合わなかった • Keepが少し分かりにくかった • 分かりやすいProblemばかりになってしまった • そのためTryがProblemの改善ばかりになった Keep Problem Try
シンプルなものに変更した! • GoodとNGというシンプルで分かりやすいものにした • NGだけでなくGoodも出すことを意識した • チームの状態から次のアクションを考えるようにした GooD!!👍 NG👎 NextAction
今ならFun! Learn!Done!が良いかも
3.チームが成⻑するために おこなった⼯夫
チームのガイドラインを作成
チームが同じ⽅向を⾒れていなかった • 技術的なバックグラウンドが違っていた • 新しい技術が多く、⽬的を⾒失いやすかった • 取り組む内容が未知で悩んでしまう事が多かった • 事業⽅針が 変更されることが多かった
チームが同じ⽅向を向くためのガイドラインを作成 • 時間をかけて全員でガイドラインを作成 • 個⼈ではなくチームの⽅針をまとめた • 作って終わりではなく定期的に⾒直しも • 状況に合わせてアップデートも 例
• 巨⼈の肩に乗ろう • 個々の⽂化を尊重しよう • 5分悩んだら相談する • 休みは遠慮しないでとる • etc
チームの⽤語集をつくり認識の違いを極 ⼒なくすようにした
認識の違いが起きやすい環境だった • AI、ロボット、HWなどは専⾨⽤語が多かった • スクラムの⽤語も混乱の原因になっていた • 多国籍なチームだったので誤解が起きやすかった
チームの⽤語集を作ることで解決した • 専⾨のメンバーが思いつく⽤語を記⼊ • 新たな⽤語は直ぐに追記することを習慣化 • ⽤語が分からないまま進まないように気をつけた 用語集のイメージ
⾃⼰紹介を可視化してメンバー間の理解 を深めやすくした
お互いの事が分かりにくかった • 育った環境や⽂化が違っていた • 技術的なバックグラウンドもバラバラだった • それぞれの家庭の事情も違っていた
⾃⼰紹介を作成してお互いの理解を深めやすくした • 全員が同じフォーマットで⾃⼰紹介を作成 • ⾃⼰紹介はいつでも誰でも⾒れる状態に • 全員で読み合わせをして理解を深めた
こんな感じのフォーマットを使いました • 働ける‧働きたい間帯 • 働けない時間帯(お⼦さんのお迎えなど) • 得意なこと • 苦⼿なこと •
モチベーションが上がるシチュエーション • モチベーションが下がるシチュエーション • etc
あとは、とにかく会話!!
チームで会話することを⼤事にした • デイリースクラムだけでは知れないことが沢⼭ • 分かった気になっていたことが ひっくり返ることも • エンジニア間の雑談から課題が解決することも \ぺ ち
ゃ くち ゃ / \ぺ ち ゃくち ゃ /
4.本⽇のまとめ
私がこのチームでやったこと • 1⼈ではなくチームで課題に取り組んだ • セオリーに囚われずプロジェクトを進めることを優先した • チーム全体が成⻑することを第⼀に⾏動した
私がこのチームで学んだこと • チームが協⼒すればできることが増えること • お互いを理解することの⼤切さ • 雑談などを含めた会話の重要性
私たちはこんなチームに成⻑しました • 主語は「私」ではなく「私たち」 • これまでの経験から不確実に向き合える • 常に前向きに考えることができる • 出来ない理由ではなくどうしたら出来るかを考えられる
ふりかえると 私たちはアジャイルやスクラムのアンチパターンを いくつも踏んでいたかもしれません
それでもプロジェクトマネージャーであった私が スクラムマスターとなり、不確実なプロジェクトに向 き向き合ったことは意味があったと信じています。
その理由は
私たちは⾃律的な組織へと成⻑し たのしく働き そして結果も残したからです!
以上
ご清聴ありがとうございました!!