東京海上日動システムズ
with Red Hat
コロナ禍でも！

LeSS(Large Scale Scrum)の実践によるプロダクト開発と組織改善！

アジェンダ
１．自己紹介 & プロダクト紹介
２．スクラムマスターがやって来た
３．LeSS(Large Scale Scrum)

４．コロナ禍のスクラム
５．スクラムと組織改善自己紹介 & プロダクト紹介

工藤 貴央（くどう たかおう）
東京海上日動システムズ
デジタルイノベーション開発部
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

2016年：東京海上日動システムズへ新卒入社
2017年：少品多品種保険システム改定
2018年：新人研修講師
2019年：東京海上グループのシンクライアント環境刷新
2020年：「地震に備えるEQuick保険」を現在開発中➡エンジニア人生で初めてのアジャイル・スクラム開発
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー≪好きなスクラムイベント≫ スプリントプランニング≪好きなWebサービス≫ いらすとや清水 弘毅（しみず こうき）
Red Hatサービス事業統括本部 アジャイルコーチ
オリンパス、GROOVE-Xでスクラムマスターに従事。
現在レッドハットにて日本の様々なエンタープライズ企業に向けてアジャイル導入支援・実践支援をしている。
最近の好きな言葉は『優れたスクラムマスターは業界をも変える』
スクラム・LeSSの壮大な実験コミュニティ『スクラム実験室』
アジャイル・リーン・スクラムの探求を目指した『Beyond Agile』運営・実行。
https://note.com/koki_jp
https://qiita.com/Koki_jp

Twitter:@koki_jp
https://scrum-jikken.connpass.com/

https://beyondagile.connpass.com/

プロダクト紹介
震度連動型地震諸費用保険(地震に備えるEQuick(イークイック)保険)◆最短3日で保険金のお受け取りが可能◆スマホのみで各種手続きが完結

スクラムマスターがやってきた2020年1月〜 現場に伺うと…
アジャイルだから開発の全体感が見えません！

PJ全体的にはウォーター
フォールです！

プランニングが長すぎて終わりません！
プロダクトオーナーはいません！

アジャイルだから全体感がわからない？

適切にスクラムが運用できてないな
スクラムマスターをやりたい人がいません！

〜現場の叫び〜プランニングを見たけど、確かにこれじゃ終わらないな

ウォーターフォールプロジェクトの中で無理矢理スクラムやってる〜コーチの観察〜いろんな言い訳が内外から聞こえる• 形だけのスクラムをやっても意味がない。

• 適切な役割の方が揃わないと効果がほとんどない。
• 開発チームだけ頑張っても仕方がない。
本当にそうか？
形だけでもいいじゃないの？

そこに“学び”があるはずだ！
“学び”があれば自分たち自身を”変えて”いける！

これは”挑戦”だ！
コーチ自身も自分を乗り越え続ける必要がある！

全員で、Do Agile
そして、Be Agileスプリントプランニングが終わらない問題
1週間スプリントで、ひどいときは09:00〜19:00でも終わっていなかった！

ActionProblem
優先順位の高いPBLがExcelにしまわれており誰も見ていない。

６人のチームで、同じテーブルに座っているが、各人ノートパソコンを開いて見ながら議論している。

スプリントプラン
ニングで実施するべきPBLが初見。

６人で一つの大きいモニターを見ていおり、脳が止まっている人が４人くらいいる。

直近３スプリントくらいのPBLを紙に印刷して壁に貼って見える化

ペアでプランニングして頂く。ノートパソコ
ンはペアで１台ならOK

PBI毎にA3の紙の上で設計・タスク分割
プロダクトバックログ
リファインメントの確実な実施

プランニング内を細かいタイムボックスにした

Result アナログ（紙とペン）最高！！
•••

一番良いときで3時間でプランニング終了！
メンバーの満足度・理解度も向上！
見積もり誤差も支障なし！

PO Proxy問題
POになるべきは親会社、バックエンドはWF、この体制のままいくべきか？
WF

基幹系DB

親会社
（真のPO)

Problem
PO役を”こちら側”に建てる必要がある。

基幹系バックエンド
DocAPI

Scrum

PBLフロントDBTeam
ScrumMaster/
Agile Coach

クライアント真のPOとはドキュメントベースのやりとり“こちら側”と“あちら側”という構造になってしまう。

AWS Lambda

PO Proxy

プロダクトバックログを”こちら側”で作る必要がある。

Proxyは構造的にNGということをResult PO
組織的には把握。

だが、このPJはこのまま進めた。

•

次の開発に繋げるための“壮大な学び”

リーダー忙しすぎる問題
タスクをベン図で可視化し、負荷分散！大切なのは数週間言い続けること！
あるメンバに負荷が集中他のメンバやPOに振る！

見える化して常にみんなでトラッキング！

スクラムマスターやりたい人いない問題
キャリアパスがない。どういう振る舞いが必要か不明瞭。誰も手を挙げれない。
担当チーム• うさぎ・あんこう• 観葉植物• モのル

背中を見て頂く！
清水が複数PJのSMをやってみる！
ファシリテーティング

コーチング

スクラムとはAgile-mindset
システム思考PBL分割ワーク
Lean-Thinking
The Great Scrum Master• Six Trumps• Decision Making• LeSS• POのROIについて…etc

トレーニングシチュエー
ショナリング

組織的にSM研修を毎週開催！上記で興味を持って頂いた方を募る！
••••••

ティーチング• 毎週月曜日13:00-15:00• 2020/3月〜9月

Result・・・スライドの後半に！

開発規模・全量が見えない問題
今のチーム体制で納期までにやりきれるのか？

Problem
おぼろげにやるべきことは把握されているものの定量化されていない

そもそも開発規模・全量を会話する場がない。

リーダやマネージャはおぼろげに知っているが開発メンバが把握していないチームのベロシティが測れていないスプリント日数がまちまちでベロシティが測れない

Action
１週間スプリントを確実に回すようにした

プロダクトバックログ
リファインメントの確実な実施

全量を大雑把に全員で把握！チャート化！
見える化！

他部署に関連するマイルストーンも見える化！

Result バックログリファインメントと見える化が超重要！！
••

このままだとやりきれないことが判明！
チーム増やすぞ！

大きめのホワイトボードを用意！

全量を数値化して貼り出す！
チームで進捗をトラッキング！

LeSS(Large Scale Scrum)メンバー増員問題
開発メンバーがいきなり倍以上に！

どのように開発を進めるか？

追加メンバー
一から仕様を教えるの大変そう…

開発チーム
この多人数でスクラム開発できるのか…

仕事の分担はどうしよう…

メンバー増員問題
開発メンバーがいきなり倍以上に！
うさぎチームどのように開発を進めるか？
あんこうチーム

チームごとにスクラム開発を進めていくLeSSを採用

LeSS(Large Scale Scrum)

https://less.works/it/resources/graphics/book-images

LeSS 〜スプリントプランニング〜

各ペアごとに進捗確認

プランニング

質問タイム

チーム内共有バックログ
バックログ確認確認

チーム間共有
各ペアごとにプランニング

進捗確認

質問タイム

チーム内共有

チームごとにプランニングを進め、最後にチーム間で情報共有&レビュー

あんこううさぎLeSS 〜スプリントレビュー〜

デモデモ
デモ担当交代

（1回目）

（2回目）

レビュー対象バックログ確認
確認

レビュー結果
チーム間共有
持ち帰り

デモ
（1回目）

デモ担当交代デモ（2回目）

2回に分けてデモを実施することで、全員が両チームのデモを確認できた

あんこうデモうさぎデモLeSS 〜その他の取り組み〜
ペア構成➡開発やプランニングの際は基本的に旧人類と新人類でペアを作成。業務要件の理解や技術のキャッチアップに時間がかかったが、最終的には新人類だけでも開発ができるようになった。

◆別チームの方が詳しいバックログを開発するとき➡チームメンバーを一時的に交換。属チーム化されがちなノウハウをそこで共有。
うさぎチーム

あんこうチームコロナ禍のスクラムテレワークへの不安
スクラム続ける？

ペアプロ
難しそう…

付箋の代わりにどうやってタスク管理する？

紙の付箋どうするか問題
これまで紙で管理してきたタスクや課題をどのように管理するか？

すべてオンラインへ移行！！

紙の付箋どうするか問題
同じ予定表を作成

プロダクト
バックログ

紙の付箋どうするか問題

オンラインでもプランニングのスタイルは継続

オンライン移行により改善された点１
システム構成図

絵心がなくとも安定した図が書ける

過去の図が残り続けるため、必要なときに簡単に参照できるようにオンライン移行により改善された点２◆大人数でのミーティング

情報の申請が増したため、ホワイトボードでは議論しにくい内容も議論しやすくなったリモートペアプロ
オンラインでもペアプロは継続

ZOOMの機能でペア毎に小部屋を割り当て＜リモートペアプロのルール＞
 ドライバがＰＣ画面を共有
 適当なタイミングでソースをコミット&ドライバ交代
 ナビゲータは指示出しのみ（キーボード操作はしない）

オンラインだと相談しにくい問題
リモートペアプロでは他ペアの状況がこれまで以上に見えにくい

順調！順調！

ここの実装よくわからない…
別のペアに相談したいけど向こうも忙しいだろうし…

オンラインだと相談しにくい問題
リモートペアプロでは他ペアの状況がこれまで以上に見えにくい

9:15

9:30

12:00

13:00

15:00

全体朝会チーム朝会

昼休憩

昼会

おやつタイム

ＡＭの進捗共有を行う。
困っているペアがいなければすぐに終えて開発に移る。

チームで集まって休憩。人狼や大富豪をしてリフレッシュ！

・昨日やったことの報告
・今日やることの担当決め
・課題共有

チームで定期的に集まる時間を決め、相談できる場を固定化した組織改善

スクラム(LeSS)は組織改善のトリガー• 目指すべき場所は、”１スプリントで出荷”して検査/適応し続ける状態。
• (1スプリントで出荷判断可能ではなく)• それを実現するために組織を変えていく• スクラムマスター(with マネージャ)の仕事

スクラムを適切に運営することにより、組織課題が明るみに出る。
“1スプリントで出荷”まで辿りつけないのはほとんど組織課題があることを示唆している！

スクラムマスターからの問い
なぜ、1スプリントで出荷できないのですか？

参考：スクラムマスターの真の役割
https://note.com/koki_jp/n/ne36e588eb6c8

Value Stream Map （価値の流れ）
DONE

UNDONEエンドユーザに価値が届くまでのリードタイムを可視化・無駄削減のためのツール

Doneの定義の拡張

https://less.works/it/resources/graphics/book-images

Value Stream MapにおけるDoneの定義の拡張
DONE

UNDONE

組織的にDoneの定義を拡張し出荷までのリードタイムを短縮するhttps://less.works/it/resources/graphics/book-images

コンポーネントチーム vs フィーチャーチーム

https://less.works/it/resources/graphics/book-images

PO Proxy問題
PO Proxyは組織構造的な課題。そして、『文化は構造に従う』※1
WF

基幹系DB

親会社
（真のPO)

基幹系バックエンド
DocAPI

Scrum

PBL

フロントDBAWS Lambda

PO Proxy
Team
ScrumMaster/
Agile Coach

コンポーネントチームでは１スプリントで出荷可能な製品は作れない

クライアント※1 Culture follows structure.
https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior#:~:text=Culture%20follows%20structure.&text=That%20is%2C%20if%20you%20want,does%20not%20really%20change%20otherwise.

PO Proxy問題
PO Proxyは組織構造的な課題。そして、『文化は構造に従う』※1
WF

基幹系DB

親会社
（真のPO)

基幹系バックエンド
Doc

フィーチャーチームは、そのチームだけで、出荷可能な製品を作れる

API

ScrumPBL

フロントDBAWS Lambda

PO ProxyTeam
ScrumMaster/
Agile Coach

クライアント1スプリントで出荷可能を目指し組織変革を睨んだ壮大な旅物語が始まろうとしている※1 Culture follows structure.
https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior#:~:text=Culture%20follows%20structure.&text=That%20is%2C%20if%20you%20want,does%20not%20really%20change%20otherwise.

自己組織化されたTeam• 実現する力

Organization

ステークホルダー/ユーザーDX

Product Owner• プロダクトビジョン• TeamのROI最大化

ScrumMaster• 壁を取り除く• スクラム運営責任• PO/チーム/技術/組織コーチ

組織的にスクラムマスターが集いはじめた

東京海上日動システムズ
デジタルイノベーション
開発部
綾部 翼

富士通株式会社
澤田 秀人

東京海上日動システムズ
デジタルイノベーション
開発部
中條 大輔

東京海上日動システムズ
デジタルイノベーション
開発部
中谷 和波

東京海上日動システムズ
デジタルイノベーション
開発部
小林 真晴

東京海上日動システムズ
デジタルイノベーション開発部
櫻井 麻美子

東京海上日動システムズ
デジタルイノベーション
開発部
松本 由紀

富士通株式会社宮川 怜

富士通株式会社
山浦 譲

富士通株式会社
荒木 光信

富士通ソフトウェアテクノロジーズ
ビジネスコラボレーション開発部
丸山 厚

レッドハット西森 剛

スクラムマスターは組織の変革者

ご清聴ありがとうございました！
私達は、一緒にアジャイルになる旅をしてくれる仲間を募集しています！！
https://www.tmn-systems.co.jp/recruit/career.html
https://www.green-japan.com/company/7224?job_offer_id=108087