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スクラム

• 半分の時間で倍の成果をあげる手法

6 Copyright © 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

５３


３３つの役割











開発チーム


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

５５つのイベント




開発チーム








スプリント計画(part1) プロダクトバックログから今回の

スプリントで開発するバックログを選択する。




開発チーム








スプリント計画(part2)

バックログを実現するためのタスクを洗い出す。開発メンバーは最低限、最初に担当するタスクを引き取る




開発チーム








25


進捗や予定、問題点などを開発チーム内で共有するために、毎日行う。

通常、スタンドアップミーティングの形式で、15分程度。




開発チーム








26

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




開発チーム








27

スプリント振り返り

スプリントを振り返り、今後の改善計画を立てる。


３３つの成果物




開発チーム








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




開発チーム









スプリントにおける開発チームの仕事を定義したタスクリスト。開発チームが管理する。









プロダクトの増加分スプリントで開発した成果

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

Development XMfg

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 by Dennis Heine & Thorben Höpke from Bosch Engineering GmbH


７．なぜ今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


© 2

014 S

cru

m In

c.

Joe Justice

• Owner of all-Scrum automotive Manufacturing Company

• Creator of eXtreme Manufacturing Methods

• President of Scrum@Hardware practice at Scrum Inc. [email protected]

“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 mid day

89 Copyright © 2016 All Rights Reserved. Copyright © 2016 All Rights Reserved.

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


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