【やってみた】スクラムチームを超⽣産的にする ためのパタン・ランゲージ サイボウズ株式会社

⾃⼰紹介 ▌天野祐介 @ama_ch ▌Senior Scrum Master ▌Agile Coach ▌Cybozu / Freelance ▌スクラムマスター職能⼈材マネージャー ▌スクラムフェス仙台実⾏委員会代表

⾃⼰紹介 村⽥篤亮 2019年サイボウズ⼊社 kintoneのフロントエンド刷新 スクラムマスター兼エンジニア LVSPQQF !NZT@Y

⾃⼰紹介 ▌⽩⿃亜美 @__amishiratori ▌2020新卒⼊社 ▌kintone Design Systems ▌Design Technologist & Scrum Master

⾃⼰紹介 ▌張暁⻫（Zhang XiaoQi） ▌2019年サイボウズ中途⼊社 ▌kintone新機能開発 → フロントエンド刷新PJ ▌エンジニア 兼 スクラムマスター（今年から） ▌来⽇10年⽬にして北海道は初めて @x1a0q1

⾃⼰紹介 ▌たっしー（⽥代 雅治） ▌2020年 新卒⼊社 ▌フロントエンド基盤刷新プロジェクト ▌SM→PO ▌ロイズのポテトチップチョコレートが⼤好き mshrtsr !UBTTIJ

ターゲットとバリュー ▌Target Audience n ハイパフォーマンスなスクラムチームを実現するためのスクラムマスターの 活動に興味がある⼈ ▌Learning Outcome n ⾃チームのパフォーマンスを⾼めるために試したいアイデアが⾒つかった n 健全に機能しているチームの⼀例を知ることができた n ⽴ち上げ直後のスクラムチームでスクラムマスターがどんな活動をするの か知ることができた

kintoneの フロントエンド刷新と それを⽀える開発体制

kintoneフロントエンド刷新プロジェクトとは🤔

kintoneのフロントエンドをコードベース、 チーム体制から再設計するプロジェクト🚀

kintoneのフロントエンド刷新 ゴール 開発本部 サイボウズの 製品を開発する l 全てのページが React によって 表⽰されている l フロントエンドが技術的にも チーム的にも分割されている l ユーザー体験に関する指標に対 する計測が⾏われており、 チームの関⼼ごとになっている ※詳しくは「kintoneフロントエンドリアーキテクチャプロジェクトで⼤切にしていること」を参照

チームの分割🔪

kintoneのフロントエンド刷新 解決したい問題 ▌ 各チームの担当範囲が不明確 ▌ ͭͷܾஅ͕νʔϜશମʹӨڹ͢Δ νʔϜ νʔϜ νʔϜO ...... λεΫ ʘ༏ઌॱҐͷλεΫ͔Βணख͠·͢ʗ νʔϜ νʔϜ νʔϜO ...... ˓˓Λ΍Γ͍ͨͰ͢ 反対 賛成 分かりません 🙋

kintoneのフロントエンド刷新 チームで意思決定できる体制 νʔϜ" νʔϜ# νʔϜ9 … ▌少⼈数の職能横断チーム （6名以下推奨、10名以下必須） ▌各チームがミッションを持つ ▌各チームでミッション達成に必要と なるタスクを作る ▌各チームがオーナーシップを持つ ։ൃνʔϜશମͷϛογϣϯ ϛογϣϯ" λεΫ : ϛογϣϯ# λεΫ : ϛογϣϯ9 λεΫ :

▌Scrum@Scaleを採⽤ ▌25名が所属 ※兼務メンバー含む ▌独⽴したスクラムチーム ▌各チームのメンバーは 職能横断で構成 kintoneのフロントエンド刷新 開発体制

kintoneのフロントエンド刷新 組織⽀援 まとめ 運⽤本部 開発本部 サイボウズの インフラを⽀える サイボウズの 製品を開発する ▌kintone のフロントエンドのリアーキテクチャをプロジェクトとし て取り組んでいます ▌⾃律的に活動できるような体制・アーキテクチャを⽬指して フロントエンドを分割します ▌オーナーシップを明確化し認知負荷を減らすことで、挑戦・失敗が できる環境作りを⽬指しています

スクラムチームを超⽣産的にするための パタン・ランゲージ

https://ieeexplore.ieee.org/document/6759182

9個のパタン ▌1. Stable Teams ▌2. Yesterday's Weather ▌3. Swarming: One Piece Continuous Flow ▌4. Interrupt Pattern: Illigitimus Non Interruptus ▌5. Daily Clean Code ▌6. Emergency Procedure ▌7. Scrumming the Scrum ▌8. Happiness Metric ▌9. Teams that Finish Early Accelerate Faster

チームが準備を整えるためのパタン

1. Stable Teams (安定したチーム) プロジェクトマネジメントでは、問題を解決するために「リソースマネジメント」がよく⾏われる。⼈を多く移動さ せると、さまざまなコストが発⽣する︓ - 作業内容を把握するための管理業務 - チームのメンバー統合と業務の学習が必要になることによる効率低下 - ブルックスの法則にさらされる（遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに 遅らせる） それゆえ︓チームを安定させ、チーム間での⼈の⼊れ替わりを避ける。安定したチームは⾃分のキャパ シティを把握する傾向があり、ビジネスにある程度の予測可能性を持たせることができる。チームメン バーを可能な限り⼀つのチームに専念させる。 安定したチームのメンバーは、お互いを知ることができる。メンバーは、互いの仕事のスタイルを体験し、⼀ 緒にできる仕事の量を学習する。安定したチームは、親しみやすさと相互の期待に応える⼀貫性を増し、 信頼の共同体を発展させるようになる。 https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern- language/development-team/stable-teams

2. Yesterday's Weather (昨⽇の天気) ⾃尊⼼のある個⼈やチームは、⾃分に対してどんどん⾼い⽬標を設定するのが⼈間の性である。チームが 過度に野⼼的になるのも⼈間の性で、結果、⾃分⾃⾝や利害関係者を失望させないために近道をした り、期待したものを提供できなかったりする。 ⾃ら設定したパフォーマンスへの挑戦は、特に短期的には成果を上げることができる。しかし、このような⾼ いレベルは、⻑期的には維持できず、パフォーマンスは元のレベルに戻ってしまうのが⼀般的である。 それゆえ︓ほとんどの場合、前回のスプリントで完了した⾒積もりポイントは、次のスプリントでチーム が完了する⾒積もりポイント数を⾼い信頼性で予測することができる。 チームは、次の開発期間と条件に適した作業を選択することで、ステークホルダーの期待を管理することが できる。ベロシティは平均値と標準偏差を持つ統計量なので、チームの約半分は「昨⽇の天気」に⾜りず、 約半分がそれを上回ると予想する必要がある。⽬標は、ベロシティのばらつきを減らすようにプロセスを改 善することである。 https://sites.google.com/a/scrumplop.org/published-patterns/value-stream/estimation-points/yesterday-s-weather

チームがスプリントを終わらせるためのパタン

3. Swarming: One Piece Continuous Flow (スウォーミング) ⼀度に多くのことに取り組むと、個⼈の効率、チームのベロシティ、企業の健全性が極端に低下 することがある。もし全員が個々に⾃分の仕事に取り組んでいたら、お互いに助け合うことも、⻑ 期的にお互いから学ぶこともない。 それゆえ︓プロダクトバックログの1つの項⽬にチームの最⼤限の努⼒を集中させ、できるだ け早く完了させる。この項⽬を担当する⼈は、チームのキャプテンである。全員が可能な限り キャプテンを助けなければならず、誰もキャプテンを邪魔してはならない。キャプテンがDoneに なったらすぐに、次のバックログ項⽬に責任を持つ⼈がキャプテンになる。 このパタンは、チームの⼒を結集してビジネス価値を提供するために、ベロシティを最⼤化すること を⽬的としている。チームのアイデンティティを個⼈ではなくチーム全体に集中させることで、ス ウォーミングを促進させることができる。このパタンを導⼊することで、チームは⼀個流しのフローに 移⾏する。トヨタは、これが⽣産能⼒を最適化することを実証した。 https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern- language/development-team/swarming--one-piece-continuous-flow

4. Interrupt Pattern: Illigitimus Non Interruptus (割り込みバッファ) スクラムチームは多くの利害関係者にサービスを提供しており、スプリント中に優先順位が変わったり、現場で問題が発⽣したりして、 スクラムチームの作業が中断されることがよくある。営業やマーケティングの要求と経営陣の⼲渉が重なると、チームの慢性的な機能 不全を引き起こす。 それゆえ︓割り込みのための時間を明⽰的に割り当て、割り当てた時間内に収まる以上の作業を許可しない。もし作業が割り 当てを超えたら、スプリントを中断する。 ⽣産を阻害しないよう組織を⾃⼰組織化させるために、3つのシンプルなルールを設定する︓ 1. チームは過去のデータにもとづき、予期しないアイテムのためにバッファを作る 2. すべての瑣末でない要求はトリアージのためにPOを通す。いくつかの重要なアイテムは、POが割り込みバッファに追加する。 3. バッファがオーバーフローしたら、チームは⾃動的に中断し、スプリントを再計画しなければならない。POはマネジメントに⽇程がず れることを通知する。 さらに良いことに、バッファが満杯にならなくなると、チームは早期に終了し、バックログから前倒ししたり、阻害要因を取り除く作業がで きるようにな。さらに、もしチームが「昨⽇の天気」を使ってバッファのサイズを決め、バッファがほとんど⼀杯にならなければ、バッファのサ イズは継続的に⼩さくなり、割り込みの問題は解消される。 https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/illegitimus- non-interruptus

5. Good Housekeeping (グッド・ハウスキーピング) 作業環境がごちゃごちゃしていると、どこから何を始めたらいいのか、時間とエネルギーをロ スしてしまう。後⽚付けを先延ばしにすると、後⽚付け作業が蓄積され、進捗が滞る。こ のような混乱は、ベロシティや品質を製品急激に低下させる。 それゆえ︓完全にクリーンなプロダクトおよび作業環境を常に維持するか、または、毎 ⽇の終わりに清掃する。 作業環境がきれいだと、何をすればよいかが⼀⽬瞭然になり、タスクの流れがスムーズに なる。製品は毎⽇Doneの状態でなければならない。グッド・ハウスキーピングとは、⾃分 だけでなく、他の⼈の汚れもきれいにすることである。このアプローチは、アジャイルチームの 原則である技術的な卓越性への継続的な注意の重要な部分を占めている。 https://sites.google.com/a/scrumplop.org/published-patterns/value-stream/good-housekeeping

6. Emergency Procedure (緊急時対応⼿順) スプリントの途中で、突発的な要求や予期せぬ変更により問題が発⽣する。問題を迅速に特定し、迅速に対応する ことは、アジリティの精神の基本である。スプリント機能不全の原因は数え切れないほどあるが、このパタンは主に⼀般 的な問題の上位3つ(緊急の要求、技術的な問題、重要な⼈材や能⼒の喪失)に焦点を当てている。 チームは、うまくいっていないときは、プロダクトオーナーに相談しなければならない。それだけでなく、スプリントゴール達成 に影響する⼤きな問題に迅速に対処する⽅法について、プロダクトオーナーと合意しておく必要がある。 それゆえ︓バーンダウンが下がらないときは、パイロットが⽇常的に使うテクニックを試す。悪いことが起きたら、その 問題に対して特別に設計された緊急⼿順を実⾏する。 スクラムの緊急時対応⼿順︓（必要な分だけ実施する） 1. チームの仕事のやり⽅を変える。何か違うことをする。 2. 助けを求める。通常、バックログを他の誰かに譲ることによって。 3. スコープを縮⼩する。 4. スプリントを中⽌し、再計画する。 5. 緊急事態がリリース⽇にどのように影響するかを経営陣に報告する。 https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern- language/emergency-procedure

超⽣産的な状態を達成するためのパタン

7. Scrumming the Scrum (スクラムをスクラムする) スクラムチームのうち、パフォーマンスと価値創造能⼒の根本的な新しいレベルへのパラダイムシフトを実現 するのは、ごく少数に過ぎない。これは、ほとんどのチームが障害を特定し、取り除くことができないからであ る。 困難な障害は、時に極めて集中的な努⼒を必要とする。多くの障害に⼀度に取り組むと、成果は少なく、 チームの⼠気を低下させる。 それゆえ︓スプリントレトロスペクティブで最も重要な障害を1つ特定し、次のスプリントが終了する前 に除去する。最優先の障害を取り除くには、それをタスクとしてスプリントバックログに⼊れ、受け⼊れテ ストを実施する。そして、スプリントレビューで評価する。 最優先の障害に集中することで、最優先の障害への集中を失うことなく、他の優先順位の⾼い障害も取 り除くためにチームが⾃⼰組織化するという副次的な効果が得られる。 このパタンは、継続的に効率を⾼め、持続的に⾼い作業能⼒を確保するもので、ベロシティで測定するこ とができる。 https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern- language/scrumming-the-scrum

8. Happiness Metric (幸福指標) レトロスペクティブなどの活動では、⼀般的に多くの改善案が出る。ベロシティ向上に役⽴つとされるアイデアの⻑いリス トを思いつくのは⾃然なことである。選択された改善は、実際には速度をまったく向上させないかも知れないし、もし向 上させたとしても、最も重要な改善ではない可能性がある。 私たちは⼀般的に、⼈は⾃分の仕事をうまくこなすことで⼤きな満⾜感を得られると考えている。しかし、それ以上に 重要なことは、⼈々はしばしば、どんなことが⾃分をより効果的にするのか、どんなことが⾃分の邪魔をしているのかを理 解することができるということである。 それゆえ︓チームの合意によって選択された、⼀度に⼀つの⼩さな改善で、改善プロセスを推進する。チームに質 問を投げかけ、テーブルの上にある選択肢のうちどれが最もチームの情熱や参加意識を引き出せるかを考えさせ、 その答えを使って、チームを最も活気づけるカイゼンを選択する。チームは、次のスプリントでその項⽬に取り組むこ とを（⾃分⾃⾝に）コミットする。 多数決や誰かの決定ではなく、合意形成に導くことが重要である。ここで重要なのは、チームがコントロールできている と感じることであり、その感覚を損なうものは、このパタンを機能させる核⼼に触れるものである。結局のところ、これは チームの⾃律性を引き出し、増幅することである。 https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern- language/happiness-metric

9. Teams that Finish Early Accelerate Faster (早く終わらせるチームは早く加速する) スプリントに仕事を詰め込みすぎると、チームはプレッシャーを感じ、終わらせることができず、不幸になる。ノコギリ の刃を研ぐ時間を取れず改善も進まない。 それゆえ︓スプリントに⼊れる作業量を前回のスプリントよりも⼩さくし、より控え⽬なスプリントゴールを⽬ 指す。スプリントゴール（成果）の野⼼度は、作業のボリューム、コスト、期間に⽐例しない場合があることに注 意する。 スプリントの早期完了時には次のスプリントのアイテムに着⼿することで、将来のベロシティを⾼めることができる。 レトロスペクティブでカイゼンを特定し、最優先で次のスプリントバックログに⼊れることで、加速の確率を⾼める。 早く終わらせることによってチームは、⾃分たちが何をしているのかをより明確に考えることができ、障害物を取り 除き、次のスプリントのバックログを前倒しし、勝利への姿勢を⾝につけ、ベロシティを⾼めることができる。 https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern- language/teams-that-finish-early-accelerate-faster

やってみてどうだった︖ 〜スクラムマスターにインタビュー〜 Miroに移動してください↓ https://miro.com/app/board/uXjVPKGCL7s=/ Password:scrumsapporo