アンチパターンかもしれないがプロジェクトマネジャーがスクラムマスターをやることに意味があると信じている

Slide 1

Slide 1 text

アンチパターンかもしれないがプロジェクトマネジャーがスクラムマスターをやることに意味があると信じている 2025.1.24 事業成⻑へ導くスクラム運⽤〜アジャイル組織を推進するヒントを学ぶ〜 @3panda

Slide 2

Slide 2 text

⾃⼰紹介 ● 名前：シログチリョウタ /3panda ● 職業：スクラムマスター/ アジャイルコーチ ● 経歴： ○ Webフロントエンドエンジニア ○ ゲームエンジニア ○ AIベンチャーでプロマネ＆EM ○ フリーランスのスクラムマスター ←イマココ詳しくはこちら

Slide 3

Slide 3 text

本⽇お話すること ● 私が以前勤めていたAIベンチャーでのお話 ● 私が初めてスクラムを取り⼊れたチームでのお話

Slide 4

Slide 4 text

アジェンダ 1. 私たちはどんなチームだったのか 2. アジャイルのプラクティスをチームにあったやり⽅に⼯夫 3. チームが成⻑するためにおこなった⼯夫 4. 本⽇のまとめ

Slide 5

Slide 5 text

1.私たちはどんなチームだったのか

Slide 6

Slide 6 text

担当していたプロジェクト ● ⼤⼿企業の研究部⾨様からの研究委託 ● ⼤⼿の製造業様からの省⼈化に向けたPoC ● ⾃社プロダクトの技術検証 ※イメージです

Slide 7

Slide 7 text

扱っていたテーマ(例) ● AGV(無⼈搬送機) x AIによる⼯場内点検の無⼈化 ● ⼈協働ロボット x AIによる作業⼯程の省⼈化 ● 深層強化学習による検査ロボットの最適化 ● etc ※イメージです

Slide 8

Slide 8 text

チームの構成 ● プロジェクトマネージャー x 1名(私) ● アプリケーションエンジニア x 2名 ○ ロボット‧カメラなどの制御 ● ハードウェアエンジニア x 2名 ○ ロボットやIoTデバイスなど調整やパーツの作成 ● AIエンジニア x 1名 ○ 撮影した画像を判定するAIモデルなど

Slide 9

Slide 9 text

チームの構成 ● 多国籍なチーム ○ ⽇本⼈ 3⼈ ○ イタリア⼈ 1⼈ ○ 中国⼈ 1⼈ ○ ネパール⼈ 1⼈

Slide 10

Slide 10 text

余談：私以外はみんな英語が話せる \　I can't speak eng…　/

Slide 11

Slide 11 text

2.アジャイルのプラクティスをチームにあったやり⽅に⼯夫

Slide 12

Slide 12 text

「スクラム、スクラム」と⾔わずに気が付いたらスクラムを意識した

Slide 13

Slide 13 text

チーム内にスクラムへの懸念があった ● スクラムの経験者が私だけだった ● はじめてのやり⽅でメンバーが困惑していた ● MTGが多いという懸念も上がっていた Scrum? Agile? MTG多い...

Slide 14

Slide 14 text

気がついたらスクラムを⽬指した ● 開発のリズムを掴むことに注⼒した ● 座学よりも実際にやってみるを意識した ● アジャイルの⽤語はあまり使わないようにした

Slide 15

Slide 15 text

形骸化したデイリースクラムを課題解決の場にした

Slide 16

Slide 16 text

デイリースクラムが情報共有の場になっていなかった ● 15分で終わらすために慌ただしくなっていた ● 進捗報告をだけをする時間になっていた ● 抱えている課題を話せる雰囲気ではなかった昨⽇はXXXをやりました。今⽇はXXXをやります。特に困ったことはありません。昨⽇はXXXをやりました。今⽇はXXXをやります。特に困ったことはありません。昨⽇はXXXをやりました。今⽇はXXXをやります。特に困ったことはありません。

Slide 17

Slide 17 text

課題解決のきっかけを得る場を⽬指した ● 15分で終わることを意識しない ● アイスブレイクを挟んで和む場に ● 相談や質問が活発化するようにファシリテーション \あれがこれで / \それは、あれが / \なるほど /

Slide 18

Slide 18 text

ゴールの認識合わせに集中した

Slide 19

Slide 19 text

完成の定義と受け⼊れ基準が難しかった ● 何をもって完成とするかが難しかった ● 両者の違いが分からずに混乱していた ● PBIの完成についての認識違いが多発した完成の定義 ? 受け入れ基準 ?

Slide 20

Slide 20 text

ゴールは何かに集中することにした ● 完成の定義と受け⼊れ基準という⾔葉を使うのをやめた ● ゴールというシンプルな⾔葉に置き換えた ● 「このチケットのゴールは？」をチームで考えるようにした \ゴールはなんだろう？ /

Slide 21

Slide 21 text

スプリントレビューがチーム内共有になった時も意義あるものにした

Slide 22

Slide 22 text

ステークホルダーへのレビューが定期的には⾏えなかった ● クライアントに1,2週間に⼀度の出席は難しかった ● ⾃社の役員や事業オーナーも常に出席は難しかった ● プロジェクトマネージャーの視点で私が⾏うことも多々あった ※デモのイメージ

Slide 23

Slide 23 text

チームだけのレビューでも意義あるものに ● ステークホルダー向けのレビューの予⾏練習の場にした ● チームだけでもデモを⾏なってFBを出すようにした ● 社内の通りすがりの⼈にもデモをしてFBをもらうようにした ※デモのイメージ

Slide 24

Slide 24 text

ふりかえり⼿法を定番のKPTからその時のチーム合った「Good or NG」にした

Slide 25

Slide 25 text

KPTがチームに合わなかった ● Keepが少し分かりにくかった ● 分かりやすいProblemばかりになってしまった ● そのためTryがProblemの改善ばかりになった Keep Problem Try

Slide 26

Slide 26 text

シンプルなものに変更した！ ● GoodとNGというシンプルで分かりやすいものにした ● NGだけでなくGoodも出すことを意識した ● チームの状態から次のアクションを考えるようにした GooD!!👍 NG👎 NextAction 今ならFun! Learn！Done!が良いかも

Slide 27

Slide 27 text

3.チームが成⻑するためにおこなった⼯夫

Slide 28

Slide 28 text

チームのガイドラインを作成

Slide 29

Slide 29 text

チームが同じ⽅向を⾒れていなかった ● 技術的なバックグラウンドが違っていた ● 新しい技術が多く、⽬的を⾒失いやすかった ● 取り組む内容が未知で悩んでしまう事が多かった ● 事業⽅針が変更されることが多かった

Slide 30

Slide 30 text

チームが同じ⽅向を向くためのガイドラインを作成 ● 時間をかけて全員でガイドラインを作成 ● 個⼈ではなくチームの⽅針をまとめた ● 作って終わりではなく定期的に⾒直しも ● 状況に合わせてアップデートも例 ● 巨⼈の肩に乗ろう ● 個々の⽂化を尊重しよう ● 5分悩んだら相談する ● 休みは遠慮しないでとる ● etc

Slide 31

Slide 31 text

チームの⽤語集をつくり認識の違いを極⼒なくすようにした

Slide 32

Slide 32 text

認識の違いが起きやすい環境だった ● AI、ロボット、HWなどは専⾨⽤語が多かった ● スクラムの⽤語も混乱の原因になっていた ● 多国籍なチームだったので誤解が起きやすかった

Slide 33

Slide 33 text

チームの⽤語集を作ることで解決した ● 専⾨のメンバーが思いつく⽤語を記⼊ ● 新たな⽤語は直ぐに追記することを習慣化 ● ⽤語が分からないまま進まないように気をつけた用語集のイメージ

Slide 34

Slide 34 text

⾃⼰紹介を可視化してメンバー間の理解を深めやすくした

Slide 35

Slide 35 text

お互いの事が分かりにくかった ● 育った環境や⽂化が違っていた ● 技術的なバックグラウンドもバラバラだった ● それぞれの家庭の事情も違っていた

Slide 36

Slide 36 text

⾃⼰紹介を作成してお互いの理解を深めやすくした ● 全員が同じフォーマットで⾃⼰紹介を作成 ● ⾃⼰紹介はいつでも誰でも⾒れる状態に ● 全員で読み合わせをして理解を深めた

Slide 37

Slide 37 text

こんな感じのフォーマットを使いました ● 働ける‧働きたい間帯 ● 働けない時間帯（お⼦さんのお迎えなど） ● 得意なこと ● 苦⼿なこと ● モチベーションが上がるシチュエーション ● モチベーションが下がるシチュエーション ● etc

Slide 38

Slide 38 text

あとは、とにかく会話！！

Slide 39

Slide 39 text

チームで会話することを⼤事にした ● デイリースクラムだけでは知れないことが沢⼭ ● 分かった気になっていたことがひっくり返ることも ● エンジニア間の雑談から課題が解決することも \ぺちゃくちゃ / \ぺちゃくちゃ /

Slide 40

Slide 40 text

4.本⽇のまとめ

Slide 41

Slide 41 text

私がこのチームでやったこと ● 1⼈ではなくチームで課題に取り組んだ ● セオリーに囚われずプロジェクトを進めることを優先した ● チーム全体が成⻑することを第⼀に⾏動した

Slide 42

Slide 42 text

私がこのチームで学んだこと ● チームが協⼒すればできることが増えること ● お互いを理解することの⼤切さ ● 雑談などを含めた会話の重要性

Slide 43

Slide 43 text

私たちはこんなチームに成⻑しました ● 主語は「私」ではなく「私たち」 ● これまでの経験から不確実に向き合える ● 常に前向きに考えることができる ● 出来ない理由ではなくどうしたら出来るかを考えられる

Slide 44

Slide 44 text

ふりかえると私たちはアジャイルやスクラムのアンチパターンをいくつも踏んでいたかもしれません

Slide 45

Slide 45 text

それでもプロジェクトマネージャーであった私がスクラムマスターとなり、不確実なプロジェクトに向き向き合ったことは意味があったと信じています。

Slide 46

Slide 46 text

その理由は

Slide 47

Slide 47 text

私たちは⾃律的な組織へと成⻑したのしく働きそして結果も残したからです！