Scrum：適用領域の広がりとscrum for hw概説

Scrum
適用領域の広がりとScrum for HWのご紹介
2016/11/30
山海一剛
Scrum : the way to create better world
情報処理学会東海支部 2016年度第４回講演会

Ａｂｓｔｒａｃｔ
日本の製品開発方法にヒントを得て、90年代にソフト
ウェア開発手法として登場したスクラムですが、近年
欧米ではマーケティング部門、人事部門、さらには教
育現場にと、ソフトウェア以外に適用が広がりつつあり
ます。特に製品開発分野に適用した Scrum for HWは、
今や日本の強みすら脅かす存在になりかねません。
当講演では、ソフトウェア以外の様々な適用領域を紹
介するとともに、Scrum for HWについてはさらに掘り下
げた解説を行います。
2

Contents
1. スクラムとは
2. スクラムのエッセンス
3. ソフトウェア以外のスクラム
4. Combat Scrum
5. Scrum for Hardware
6. 適用事例
7. なぜ今Scrum for HWなのか
8. Scrum for Hardware Gathering
9. まとめ
3

自己紹介
• 山海一剛（さんかいかずたか）
– 大阪出身＆在住
– ＩＴアーキテクト
– アジャイル・コーチ
– 認定スクラムマスタ＆プロダクトオーナ
– UMTP L4モデラー
– オージス総研改善塾塾長&社内講師
4

Scrumスクラム
• 半分の時間で倍の成果をあげる手法
6Copyright © 2016 All Rights Reserved.

スクラムの語源
• The New New Product Development Game
– 一橋大学の野中郁次郎と竹内弘高が日本で行われている新製品開発のプロセ
スをNASA等の米国型のそれと比較研究した成果を、 “The New New Product
Development Game” としてHarvard Business Review 誌に発表した（1986年1-2
月）。
– 新製品開発という速さと柔軟さが求められる場面では、成果物を紙に書いてそ
れを渡すようなリレーをしていてはダメ。さまざまな専門性を持った人がチームを
組み、ラグビーのように開発の最初から最後まで一緒に働く。人とチームを重視
し、彼らに自律的に動ける環境を与えることでブレークスルーが起こりやすくなる
と同時に製品化までの時間が短くなる、と説いている
– 富士ゼロックス、キヤノン、本田技研工業、
日本電気、セイコーエプソン、ブラザー工業
など例に挙げて説明した日本の製品開発の
特徴的な進め方を「スクラム」と呼んだ。これ
がスクラムという用語の元となった。
（Wikipedia他）

ソフトウェアにおけるスクラムの広がり
アジャイル開発適用企業９５％
8
VersionOne : 10th Annual State of Agile™ Report

9
アジャイル適用のメリット
８７％変化への対応容易性
８５％生産性の向上
８４％プロジェクトの可視性向上
８１％モチベーション向上
８１％納期遵守率向上
…

10
適用している手法
Scrum(58%)
Scrum XP ハイブリッド(10%)
Scrumban(7%)
Kanban(5%)

２．スクラムのエッセンス
要求管理
スプリント
スクラムの要素

スクラムの要求管理

要求のフィードバックループ
13
http://www.dccia.ua.es/dccia/inf/asignaturas/MADS/2013-14/lecturas/06_Kniberg_Product_Owner.pdf
Copyright © 2016 All Rights Reserved.

バックログの考え方（氷山）
http://www.slideshare.net/reinhartdelille/scrum-methodology-how-to-build-the-death-star

見直し
つまりスクラムの要求管理とは
15
要求（バックログ）評価
循環するパイプライン
具体化・詳細化
実装
実現
ビジネス価値

スプリントとは

プロダクトオーナー(PO)
スクラムマスター(SM)
開発チーム
デイリースクラム
スプリント
スプリント振り返り
スプリントレビュースプリント計画
(part2)
スプリント計画
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
スプリント
スクラムの中核となる概念で、プロダクトの増加分
（インクリメント）を作成する期間のこと
一般的には２週間（1～4週間）

スクラムの１１の要素とは

スクラムの要素
３
３つの役割
５つのイベント
３つの成果物
19
５３

３３つの役割

スプリント
(part2)
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
開発チーム
プロダクトのビジネス価値について責任をもち、機能・優先順位・リリース
内容/時期、受け入れ可否について判断をする。
開発チーム
プロダクトを作ることに責任をもつ。
プロダクトの価値向上に対してPOにアイディアを提供する役割も担う。通
常3～9名。フラットな組織であることがよいとされている。
スクラムチームの機能と生産性について責任をもつ。
プロセスがうまく回るように、POや開発チームをサポートしたり、外部の
干渉からスクラムチームを守る役割をもつ。

５５つのイベント

開発チーム
スプリント
(part2)
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
スプリント計画(part1)
プロダクトバックログから今回の
スプリントで開発するバックログを選択
する。

開発チーム
スプリント
(part2)
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
スプリント計画(part2)
バックログを実現するためのタスクを洗い出す。
開発メンバーは最低限、最初に担当するタス
クを引き取る

開発チーム
スプリント
(part2)
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
25
進捗や予定、問題点などを開発チーム内
で共有するために、毎日行う。
通常、スタンドアップミーティングの形式で、
15分程度。

開発チーム
スプリント
(part2)
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
26
スプリントレビュー
プロダクトの増加分を開発チームが
デモンストレーションし、POがレビューする。

開発チーム
スプリント
(part2)
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
27
スプリントを振り返り、今後の改善計画
を立てる。

３３つの成果物

開発チーム
スプリント
(part2)
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
プロダクトバックログ
優先順位が付けられた要求事項の一覧。
POが管理する。
(各要求事項の見積りは開発チームが提供)

開発チーム
スプリント
(part2)
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
スプリントバックログ
スプリントにおける開発チームの仕事を定義した
タスクリスト。
開発チームが管理する。

スプリント
(part2)
(part1)
プロダクト
バックログ
スプリント
バックログ
プロダクト
の増加分
プロダクトの増加分
スプリントで開発した成果
31
開発チーム

１１の要素を満たせばスクラム
３５３
32
イベント役割成果物

３．ソフトウェア以外のスクラム

Scrum for Marketing

Scrum for Sales

Scrum for Human Resources

Scrum for Finance

Scrum for Education

4.Combat Scrum

Combat Scrum
Mike Few

「サージ」イラク戦争における戦後処理戦略
• ６つのスクラムチーム（90人の空挺隊員）
• 150,000のイラク市民（Diyala河渓谷地域）
• １３の種族
• ３つの宗派・民族（スンニ、シーア、クルド）
• ３つの対立的な暴動集団

スプリントゼロ
• 本格的な活動開始前に、「スプリントゼロ」として予備調査活動
– 私たちはこの地区について、どの程度知っているのだろうか
– ここの環境は我々に対して寛容か
– この地域で今まさに何が起こっているのか
– 私たちが持っているべき情報のうち欠けているのは何か
頻繁な偵察行動（＝現地現物）での情報収集

ユーザーストーリー
• 陸軍司令官として、IEDネットワークを分断したい。この地域
の紛争を収束させるために。
– AC1. All Primary and Secondary Roads in Zone identified
– AC2. All known obstacles and bypasses identified
– AC3. Enemy routes understood
– AC4. Bomb Maker Neutralized
– AC5. Known IEDs Dismantled
• イラク市民として、隣人とともに平和維持活動に協力したい。
紛争の収束のために
– AC1. Key Leaders Identified
– AC2. Influence Strategies Identified
– AC3. Initial Meetings Scheduled

デイリースクラム Nightly Huddles
• 「今日やったこと」「明日やること」「阻害要因の有無」
• 短期目標(2-4 week)に対して、我々は近づいているか
• 我々が学んだことに基づき、大局的に評価してみよう
• 組織間において解決すべき課題はないか
• それぞれをPlatoon, Company, Squadron のレベルで考える

平和に向けての交渉

５. なぜスクラムはこんなにも柔軟なのか
46

スクラムはシンプル
• 理解が容易
• 16ページにすべてが集約されている
• 実践は容易ではない

“At OpenView, we’ve found that Scrum can
double the production of anything – it
doesn’t matter whether it’s sales, marketing,
software, finance,” says Dr. Sutherland.
“It works everywhere.”
48
“At OpenView, we’ve found that Scrum can
double the production of anything – it
doesn’t matter whether it’s sales, marketing,
software, finance,” says Dr. Sutherland.
“It works everywhere.”

１１の要素を満たせばスクラム
３５３さきほどの説明の中にソフトウェア開発固有の
要素は見つかりましたか？

変化への対応
• ビジネスの目的を達成するためのソフトウェア要求を
抽出する
• あいまいなソフトウェア要求を、ビジネス価値に基づい
て優先順をつける
• 優先順の高い要求から具体化・詳細化する
• いくつかの要求を選び、決められた期間内で動くソフト
ウェアとして実装する
• 出来上がったソフトウェアを評価し、目的に近づいて
いるか検討する
• 他の要求を見直す

変化への対応
• ビジネスの目的を達成するためのソフトウェア要求を
抽出する
• あいまいなソフトウェア要求を、ビジネス価値に基づい
て優先順をつける
• 優先順の高い要求から具体化・詳細化する
• いくつかの要求を選び、決められた期間内で動くソフト
ウェアとして実装実現/実施する
• 出来上がったソフトウェア実現した/実施した結果を評
価し、目的に近づいているか検討する
• 他の要求を見直す

「仕事の仕方」のフレームワーク
つまりスクラムは

５．Scrum for Hardware

ひとことで言うと…
 Scrum for HWはScrumのフレームワークをそのままハードを含
めた製品価値に当てはめることで、製品開発の劇的なリードタ
イム短縮・コストダウンを狙うもの
 日本ではまだ知名度は低いが、海外の大手企業では、Bosch
が積極的に取り組んでいることが伝わっている（ただし公開さ
れている情報は少ない
Scrum for Hardware

 対象
1. ソフトを持たないハードウェア製品
 掃除機
 電動のこぎり
2. 組込みソフトウェアを内容したハードウェア製品
 携帯電話
 ネットワーク機器
 分析装置（化学、医療など）
3. 外部ソフトウェアと連携するハードウェア製品
 工場内の工作機械（電子制御）
 研究所の電子制御設備
Scrum for Hardware

I. Scrum Organization
III. Object-Oriented Architecture
a.Modular Components
b.Contract-First Design
c. Design Patterns
d.Re-use and
Inheritance
a.Roles and
Responsibilities
b.Sprints/Iterative Design
c. Make Work Visible
d.Measure Velocity
e.Continuous
Improvement (Lean)
II. XP Engineering
Principles
a.User Stories
b.Pairing and Swarming
c. Test Driven
DevelopmentXMfg
Scrum for Hardware ３つの要

ソフトウェア
 開発中どの段階であっても、成果物は価値を提供できる
（Potentially Shippable Increment）
 反復を繰り返すうちに、プロダクトの目的・機能すら変化していくことがある
 プロダクトは、必ずスプリントの終了時点で、開始時点よりも価値が増えている
 ステークホルダーが頻繁に動くソフトウェアを検証することで、価値を最大化し、
ムダを最小化できる
ハードウェア
 当初のプロダクトの目的・機能から大きく逸脱することはない
 開発中の成果物は最終製品において有用となるデザインの集合でしかない
 開発中にコンポーネントや機能は増えていくが、そのプロダクトとしての意味の
ある振る舞いが出来るのは、開発の最終段階でしかない
 ステークホルダーからのフィードバックループはやはり必要。でも動くものでの
検証よりも、コンセプトの発展や、モックアップを通しての検証が多くなる
ソフト開発との比較

 ３５３は残す
 ３つの役割、５つのイベント、３つの成果物は、そのまま
 下記はハードウェアの観点で見直しが必要
 チームの編成（異なる専門領域の人をひとつのスクラムチームに集める）…後述
 仕様を書く
 スプリント計画の実施方法
 作業のトラッキング
 バックログ（ストーリー）…後述
 スクラムチームとして必要なもの/重要なもの
 １チームあたり５~６人、大規模な開発では複数チームに分割する
 技術領域ではなく「製品が提供する機能」の軸で開発チームを分割する
 開発チームは必要な全ての技術領域から集める（通常、各一人になる）
 各チームの役割定義は重要
 チーム間連携の複雑さは、アーキテクチャの良しあしに依存する。それゆえオブジェクト指向
アーキテクチャは重要
適用のポイント

体制例

バックログ（ストーリー）
• ストーリーの種類
– ユーザストーリー
• 製品が提供する機能をユーザ視点で自然な文章で記述したもの
• プロダクトオーナーが書く
– テクニカルストーリー
• ユーザに見えない（ユーザとの接点ではない）部分、技術/インフラ寄りの要求
• 多くの場合ユーザストーリーを実現するための技術要求を表現したもの
• 通常、技術者によって記述される
– 不具合
• ハードウェアの場合
– バックログの大半はテクニカルストーリー
– ソフトウェアの場合と比べると、プロダクト
オーナー自身が書くストーリーは少ない

スプリント期間
• ２週間が一般的
– ３週間は「ありえなくはない」レベル
– 上記以外は（ソフトウェアと同様に）うまく行かない
– 留意点：ハードウェア屋は、２週間で出来るとは思ってくれない
– 動くコンポーネントを実現するには、時に数週間以上が必要になるこ
ともある
– ２週間で構築・検証・評価が可能な、より小さな単位（ストーリー）に分
割することがポイント

Bosch 自動車部品、ＤＩＹ用品
Ｊｏｈｎ Deere 農耕機器
Ｔｈｅｒｍｏ Fisher 医療機器
Ｃｉｓｃｏ Systems 通信機器（トライアル中）
Ｔｏｙｏｔａ U.S. 輸送機器（状況不明）
63
適用企業

64
John Deereの事例

65
John Deereの事例（１）
2012年当時の課題認識
 新製品開発プロセスの肥大化:リスク回避の名目で800プロセス以上
 プロジェクトの同時併存：２７プロジェクト、平均１０プロジェクト/人
 プロジェクト間連携の不足：プロジェクトごとにプロジェクトマネージャ
結果として
 新製品リリースまでに７年
 タスクスイッチによる生産性の低下

66
John Deereの事例（２）
進め方
 スモールスタート：チームXI (eXtreme Innovation)
 スクラムのトレーニングとコーチングを導入：経験者の雇用
 リズムを作り、データを収集する：ベロシティ、価値を評価
 Happiness Metricによりベロシティを改善
 データに基づく判断を行う

67
John Deereの事例（３）
スクラム導入の結果
 生産性の劇的向上：２か月で２倍、１６か月で７倍
 従業員満足度の向上：グループ内下位30%からトップ１％へ
 動くプロトタイプ完成までに８か月（以前は１８-３６か月）
 マルチタスクの解消：１時点では１プロジェクトのみ、毎年３製品をリ
リース

68
Boschの事例

Ｓｃｒｕｍ Day 2015&2016 IXO Challenge
by Dennis Heine & Thorben Höpke from Bosch Engineering GmbH

70
用意するもの
• 必須
– 5 Ixo's (at least one per table)
– 5 hex-chucks (Bohrfutter) (at least one per table)
– 5 drill pumps
• 推奨
– empty plastic bottles (at least one per table)
– hoses of diameter 2mm to 1/2 inch
– cable-ties (several sizes)
– cutter (knifes)
– pliers (Kombizange)
– 7 buckets
– floorcloth (Wischlappen)
– plastic sheet to protect the floor

72
ユーザー・ストーリー
分類ユーザーストーリー受入基準評価基準
コンセプト
の検証
顧客（プロダクト責任者）として、ＩＸ
Ｏが水を送出できることをデモして
欲しい。
プロダクトの実現可能性を早期に
検証したいから
ＩＸＯを使って、水をバケツ
から他のバケツに送出で
きること
水のロスが50m//10secで
あること
3pt：最多量のチーム
2pt：２位のチーム
1pt: 上記以外の水を遅れた
チーム
0pt: 水を送れなかったチーム
コンセプト
の検証
顧客（プロダクト責任者）として、ＩＸ
Ｏがジェット水流を吹きだせること
をデモして欲しい。
プロダクトの実現可能性を早期に
検証したいから。
ジェット水流を目視確認す
る
10cm以上であること
1pt
正確さジャック（エンドユーザ）として、
ジェット水流の飛距離を長くしたい
遠くの的に当てたいから
最低1.5m先の的に水流が
当たること
3pt: 3m
2pt: 2m
1pt: 1.5m
0pt: 0m
使い勝手ジャック（エンドユーザ）として、使
用時に水漏れ無しにして欲しい。
衣類がびしょ濡れになるのはいや
だから
ジェット水流使用時の水漏
れ量を判定
5mlの水漏れごとに -1pt

Ｓｃｒｕｍ Day 2015&2016 Water Pistol Challenge

７．なぜ今Scrum for HWなのか

なぜ今、求められるのか
トップ企業であっても、新しい製品をより早くリリースし
続けなければ生き残れない
• 製品リリースサイクルのリードタイム短縮
• ニーズ多様化に対応するための多品種化

なぜ今、可能なのか
• 技術革新
– ソフトウェアによる代替
• ２D/３D CAD
• シミュレーション
– Additive Manufacturing：早く安く試作する技術
• 電子部品（Rush PCB、Ruggeduino）
• ３Dプリンタ
• 形状射出サービス
– ＰＬＭ/ＰＤＭ等、開発のおける製品情報共有基盤
の進化・浸透

ソフトウェアシミュレーション

Additive Manufacturing

工夫
• スプリント毎のゴールを明確にする
• 同じコンポーネントであっても、スプリント毎に異
なる価値でストーリーを作る
形状、使い勝手
衝突安全性
生産準備（組み付けの容易さ）
…
• 実現するストーリーに合わせて、コンポーネント
の実現レベルを考える（バックログの分割・詳細
化がキー）

８．Scrum for Hardware
Gathering

 The 1st Gathering of Scrum4HW
 ８月25・26日、コーチやエヴァンジェリストを対象にした、最初のカンファレ
ンスである「Scrum for HW Gathering」が、米国コロラド州ボールダーで開催
された。
 また翌27日、 Scrum4HWの中心人物であるJoe Justice氏が設立した
Wikispeed社でワークショップも開催された
Scrum for Hardware Gathering

©2014ScrumInc.
Joe Justice
• Owner of all-Scrum automotive
Manufacturing Company
• Creator of eXtreme Manufacturing
Methods
• President of Scrum@Hardware
practice at Scrum Inc. Justice@ScrumInc.com
“WE HAVE FOUND TEAM MORALE TO
BE A MULTIPLIER FOR VELOCITY.”
Joe Justice @WikiSpeed

Wikispeed

感想
• Scrum４HWは確実に定着しつつある
• レベルが高い！
– スクラム実践経験は当然、スクラムコーチやコーチのコー
チ、コンサルタントが中心
– 実経験に基づくディスカッション（ついて行けない）
• 組織論、組織文化にフォーカスしがち
– Scrum４HWを成功させるには、組織変革、組織文化改革
を避けて通れない。
– どう実践するかではなく、如何に組織を変革するか
（Transform）が話題の中心になりがち

Wikispeed Build Party

Wikispeed Build Party at morning

Wikispeed Build Party

９．まとめ（メッセージ）

日本の労働生産性
• 日本の労働生産性は、先進7か国で最下位
• しかし製造業だけみれば２位

日本の新製品開発
• 日本のモノ作りの知恵は、世界に誇れるもの。
リーン、ＴＯＣ、アジャイルの母体となった。
• 野中郁次郎先生が世界に紹介したように、製
品開発でも抜きんでた要素がある（あった？）
• これは残り少なくなった日本の強み

TPS
Toyota Production System
Production
Product
Development
Software
Development Other Felds
U.S. and Europe
Japan
Scrum
Scrum4HW
Lean
TOC
Theory of constrains
Development Style in
Japanese Companies
The New New Product
Development Game
？！
SCRUM for HWの系譜
Sａｌｅｓ
Marketing
Education
Goverment

このままでは
• スクラムは、日本のモノ作りの知恵をうまくフ
レームワーク化し、どのような仕事にも適用で
いるよう汎化されたもの。
• このままでは、残り少なくなった日本の強みで
すら、太刀打ちできなくなってしまう！

やってみませんか！
Scrum for Hardware

ありがとうございました！

Scrum：適用領域の広がりとscrum for hw概説

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Scrum：適用領域の広がりとscrum for hw概説

Similaire à Scrum：適用領域の広がりとscrum for hw概説 (20)

Plus de Kazutaka Sankai

Plus de Kazutaka Sankai (7)

Scrum：適用領域の広がりとscrum for hw概説