Slide 1
Slide 1 text
Happy New Year 2020
Slide 2
Slide 2 text
Happy New Year 2020
and Thank you RSGT2020
Slide 3
Slide 3 text
The New New Product
Development Game
-お刺身とラグビー-
@kobase555
Slide 4
Slide 4 text
Conclusion First：最初に結論
Readable on the web:
Webで読める
“Harvard Business Review” did a Good Job!
https://hbr.org/1986/01/the-new-new-product-development-game
Slide 5
Slide 5 text
あと、「サシミ」の元ネタがわかる
Slide 6
Slide 6 text
English
ただし、英語です。以下、苦手な方向け。
Google翻訳のページ翻訳を利用すれば、80%
はなんとか読めます。
20%は日本語がわかりにくい。２０%は諦めて。
80%でも、雰囲気はつかめます。
辞書で調べられる人はがんばって！
英語が読める人は、私に教えてくさい
Slide 7
Slide 7 text
About Scrum of Scrum Alliance
“The term Scrum comes from a 1986 Harvard Business
Review article in which authors Hirotaka Takeuchi and
Ikujiro Nonaka made an analogy comparing high-
performing, cross-functional teams to the scrum formation
used by rugby teams. “
https://www.scrumalliance.org/about-scrum/definition
「スクラム」という名称は、
1986年にハーバード・ビジネス・レビューに掲載された論文に由来
論文の著者：竹内弘高先生と野中郁次郎先生
高いパフォーマンスのクロスファンクショナルチームと
ラグビーチームが使用するスクラムフォーメーションの類似を比較
Slide 8
Slide 8 text
The New New Product Development Game
日本語にすると『新しい"新製品開発"ゲーム』
製造業の新製品開発を調査・分析
新製品開発アプローチに共通する特徴をまとめた
対象：日本とアメリカの多国籍企業と製品
富士ゼロックス、Canon 、ホンダ、NEC、Epson、
Brother、3M、ゼロックス、ヒューレットパッカードなど
カメラ、コピー機、自動車など
Slide 9
Slide 9 text
Introduction of article and
My understand
論文の内容紹介と
私の解釈
（論文内容と解釈が
混ざっています...）
Slide 10
Slide 10 text
The New New Product Development
Game
競争の激しい新製品開発の世界では、
スピードと柔軟性が不可欠
従来の新製品開発はシーケンシャルなリレーア
プローチ
うまくいっている企業の製品を調査した結果、
“新しい”全体論的なラグビーアプローチを採用
していることがわかった
Slide 11
Slide 11 text
The New New Product Development
Game
Traditional: 従来型
Relay race approach:リレーアプローチ
New: 新しい
Rugby approach:ラグビーアプローチ
Slide 12
Slide 12 text
Relay race approach
リレーアプローチ
それぞれのスペシャリストグループが
次のグループに順番にバトンを渡していく
専門性、職能別の部署を次々にバトンを渡す
Slide 13
Slide 13 text
Relay race approach
コンセプト開発
Slide 14
Slide 14 text
Relay race approach
コンセプト開発→実現可能性検証
Slide 15
Slide 15 text
Relay race approach
コンセプト開発→実現可能性検証→プロダクト設計
Slide 16
Slide 16 text
Relay race approach
コンセプト開発→実現可能性検証→プロダクト設計→
開発プロセス
Slide 17
Slide 17 text
Relay race approach
コンセプト開発→実現可能性検証→プロダクト設計→
開発プロセス→パイロット生産
Slide 18
Slide 18 text
Relay race approach
コンセプト開発→実現可能性検証→プロダクト設計→
開発プロセス→パイロット生産→最終生産
Slide 19
Slide 19 text
Relay race approach
Sequential:直線的
Slide 20
Slide 20 text
Rugby approach
ラグビーアプローチ
ラグビーのように、
ボールをチーム内でパスしながら、
ひとつのユニットとなってフィールドを移動する
Slide 21
Slide 21 text
Rugby as Sports
Photo by Quino Al on Unsplash
Slide 22
Slide 22 text
Rugby as Sports
ラグビーはボール＝価値
ボール（価値）を常に先頭におくため、追い抜いてはい
けない。前に味方選手はいないため、
自分より前にボールをパスできない
そのため、ボールを持った前の選手が後ろの選手にパス
しながら、ボール（価値）をゴールまで運ぶ
結果的に、チームがひとつのユニットとして
ユニット内でパスをしながら、フィールド上をボールが移
動する
ボールは非線形でジグザグな軌道を描く
Slide 23
Slide 23 text
maybe this...
たぶんこう
Slide 24
Slide 24 text
Photo by Quino Al on Unsplash
Slide 25
Slide 25 text
Photo by Quino Al on Unsplash
Slide 26
Slide 26 text
Photo by Quino Al on Unsplash
Slide 27
Slide 27 text
Photo by Quino Al on Unsplash
Slide 28
Slide 28 text
Photo by Quino Al on Unsplash
Slide 29
Slide 29 text
Photo by Quino Al on Unsplash
Slide 30
Slide 30 text
Photo by Quino Al on Unsplash
Slide 31
Slide 31 text
Photo by Quino Al on Unsplash
Slide 32
Slide 32 text
Photo by Quino Al on Unsplash
Slide 33
Slide 33 text
Photo by Quino Al on Unsplash
Slide 34
Slide 34 text
Photo by Quino Al on Unsplash
Slide 35
Slide 35 text
Photo by Quino Al on Unsplash
Slide 36
Slide 36 text
Photo by Quino Al on Unsplash
Slide 37
Slide 37 text
Photo by Quino Al on Unsplash
Slide 38
Slide 38 text
Photo by Quino Al on Unsplash
Slide 39
Slide 39 text
Photo by Quino Al on Unsplash
Slide 40
Slide 40 text
Photo by Quino Al on Unsplash
Slide 41
Slide 41 text
Photo by Quino Al on Unsplash
Slide 42
Slide 42 text
Zigzag
ジグザグ
Slide 43
Slide 43 text
Rugby approach
【再掲】ラグビーアプローチ
ラグビーのように、
ボールをチーム内でパスしながら、
ひとつのユニットとなってフィールドを移動する
Slide 44
Slide 44 text
Rugby approach
厳選されたメンバーでひとつチームを構成
多くの専門分野にわたるメンバーの
絶え間ない相互作用から、
製品開発プロセスが現れる
メンバーが最初から最後まで一緒に働く
Slide 45
Slide 45 text
Traditional: 従来型
Relay race approach:リレーアプローチ
New: 新しい
Rugby approach:ラグビーアプローチ
Slide 46
Slide 46 text
Traditional: 従来型
Relay race approach:リレーアプローチ
↓調査・分析した結果、共通する特徴を発見
New: 新しい
Rugby approach:ラグビーアプローチ
Slide 47
Slide 47 text
共通する6つの特徴
「Moving the Scrum Downfield」
Slide 48
Slide 48 text
「Moving the Scrum Downfield」
Slide 49
Slide 49 text
「Moving the Scrum Downfield」
Slide 50
Slide 50 text
Scrum of Rugby
Photo by Olga Guryanova on Unsplash
Slide 51
Slide 51 text
「Moving the Scrum Downfield」
Slide 52
Slide 52 text
Moving the Scrum Downfield?
maybe this...
たぶんこう
Slide 53
Slide 53 text
Moving the Scrum Downfield?
Photo by Quino Al on Unsplash
Slide 54
Slide 54 text
Moving the Scrum Downfield?
Photo by Quino Al on Unsplash
Slide 55
Slide 55 text
Moving the Scrum Downfield?
Photo by Quino Al on Unsplash
Slide 56
Slide 56 text
Moving the Scrum Downfield?
Photo by Quino Al on Unsplash
Slide 57
Slide 57 text
Moving the Scrum Downfield?
Photo by Quino Al on Unsplash
Slide 58
Slide 58 text
Moving the Scrum Downfield?
Photo by Quino Al on Unsplash
Slide 59
Slide 59 text
Moving the Scrum Downfield?
Photo by Quino Al on Unsplash
Slide 60
Slide 60 text
Moving the Scrum Downfield?
Photo by Quino Al on Unsplash
Slide 61
Slide 61 text
Moving the Scrum Downfield
「Moving the Scrum Downfield」の6つの特徴
1. Built-in instability：組み込まれた不安定性
2. Self-organizing project teams：自己組織化チーム
3. Overlapping development phases：
重なりあう開発フェーズ
4. Multilearning：マルチラーニング
5. Subtle control：緻密なコントロール
6. Organizational transfer of learning：
学習の組織的な移転
Slide 62
Slide 62 text
Moving the Scrum Downfield
6つの特徴は、ジグソーパズルのピース
ひとつひとつの特徴だけでは、
スピードと柔軟性をもたらさない
組み合わせると、全体としてはじめて
「変化をもたらす強力な新しいダイナミクス」
のセットを生む
Slide 63
Slide 63 text
Moving the Scrum Downfield
「Moving the Scrum Downfield」の6つの特徴
1. Built-in instability：組み込まれた不安定性
2. Self-organizing project teams：自己組織化チーム
3. Overlapping development phases：
重なりあう開発フェーズ
4. Multilearning：マルチラーニング
5. Subtle control：緻密なコントロール
6. Organizational transfer of learning：
学習の組織的な移転
Slide 64
Slide 64 text
1.Built-in instability：組み込まれた不安定性
トップマネジメントは
戦略的に重要なプロジェクトを実行するための
大きな自由を与え、
非常に難しい要件を設定することにより、
チームに緊張の要素を作り出す
Slide 65
Slide 65 text
２．Self-organizing project teams：
自己組織化プロジェクトチーム
「ゼロ情報（事前の知識が適用されない）」
の状態に追い込まれると
チームは自己組織化の性質を得る
3つの条件（自治権、自己超越、相互交流）を
示すときに、自己組織化能力を持つ
Slide 66
Slide 66 text
Autonomy：自治権
トップマネジメントは、最初のガイダンス、金銭、精神的なサポートに限定。介
入しない。
チームは独自の方向性を自由に設定できる
「財布の口は開けるが、口は閉じたままにする」
Self-transcendence：自己超越
チームは、「限界」への終わりのない探求に夢中になっている
トップマネジメントによって定められたガイドラインから始めて、彼らは自分た
ちのゴールを確立し始め、開発プロセスを通して高め続ける
最初は矛盾したゴールに見えたものを追求することによって、現状をオー
バーライドして大きな発見をする方法を考案する
Slide 67
Slide 67 text
Cross-fertilization：相互交流
さまざまな機能の専門性、思考プロセス、行動パターンを持つメン
バーで構成されるチーム。
多様性が、新しいアイディアやコンセプトを育む。
メンバーが相互作用し始めるまで、相互交流は実際に行われない。
富士ゼロックスの例では、メンバーをひとつの大部屋に配置した。
チームメンバー全員が1つの大部屋にいる場合、
誰かの情報が試さなくても自分のものになる
自分の立場だけではなく、グループ全体にとって、何がベストで何が二番
目にベストかを考え始める
誰もが相手の立場を理解していれば、一人ひとりが喜んで与えるようにな
るか、少なくともお互いに話をしようとする。
Slide 68
Slide 68 text
3. Overlapping development phases：
重なりあう開発フェーズ
Slide 69
Slide 69 text
タイプA：
従来のリレーアプローチ、シーケンシャル
隣のフェーズと重ならない
Slide 70
Slide 70 text
コンセプト開発→実現可能性検証→プロダクト設計→
開発プロセス→パイロット生産→最終生産
Slide 71
Slide 71 text
タイプB：
隣接するフェーズの境界のみ重なりあう。最初と最後。
Slide 72
Slide 72 text
RSGT2020 Day1 の朝ごはん
※夜もお刺身食べました、おいしい！
Slide 73
Slide 73 text
タイプB： 「”サシミ”システム」
隣接するフェーズの境界のみ重なりあう。最初と最後。
魚の切り身が重なりあう見た目がお刺身に似ている。
Slide 74
Slide 74 text
タイプC：
複数のフェーズにまたがって、全フェーズが重なりあう
ラグビーアプローチ
Slide 75
Slide 75 text
ラグビーのScrumの語源：Scrimmageの意味
小競り合い、つかみ合い、乱闘
by RSGT2020 スポンサーセッション
Photo by Olga Guryanova on Unsplash
Slide 76
Slide 76 text
No content
Slide 77
Slide 77 text
Photo by Olga Guryanova on Unsplash
Slide 78
Slide 78 text
（チームの中で）人と人とが重なりあう
by RSGT2020 Keynote James Coplien
Photo by Olga Guryanova on Unsplash
Slide 79
Slide 79 text
3. Overlapping development phases：
重なりあう開発フェーズ
自己組織化の特性は、ユニークなダイナミックまたはリズムを生み出
す。
チームメンバーは異なる時間範囲(time horizons)でプロジェクトを
開始するが、期限に間に合うようにペースを同期することを全員が行
う必要がある。
また、チームは「ゼロ情報」から開始するが、各メンバーは市場と技術
コミュニティに関する知識をすぐに共有し始める。
その結果、チームはユニットとして機能し始める。
ある時点で、個人と全体が切っても切れない状態になる。
個人のリズムとグループのリズムが重なり合い始め、まったく新しい
パルスを作り出す。
このパルスが原動力となり、チームを前進させる。
Slide 80
Slide 80 text
Type A:
高度に階層化されたフェーズを段階的に進み、
前のフェーズのすべての要件が満たされた後にのみ、
次のフェーズに移行する
Type B and Type C:
すべてのフェーズが重なりあうため、
開発プロセス全体で発生する振動や「ノイズ」を吸収できる
ボトルネックが発生すると、ノイズのレベルが明らかに増加するが、プ
ロセスが突然に停止することはない。チームはなんとか前進すること
ができる
ただし、メリットとデメリットがある
Slide 81
Slide 81 text
メリット
ハードメリット：スピードと柔軟性の向上
ソフトメリット：ヒューマンリソース管理に関連する一連のメリット
共有された責任と協力を強化
関与とコミットメントを刺激
問題解決の焦点をはっきりとさせる
イニシアチブをとることを奨励
多様なスキルを開発
市場の状況に対する感受性を高める
Slide 82
Slide 82 text
デメリット
「集中的なプロセスを管理しなければいけないこと」から生じる
チーム全体とのコミュニケーション、サプライヤーとの緊密な関
係の維持、緊急時対応計画の準備、サプライズへの対応
グループ内でより多くの緊張と対立を生み出む
「誰かが100個のうち1個を良いと思ったら、前に進んでいる
明確な兆候。
しかし、誰かが100個のうち1個を良くないと思ったら、
私たちは最初からやり直さなければならない。
この認識のギャップは対立を生み出す」
Slide 83
Slide 83 text
4. Multilearning:マルチラーニング
学習は、複数のレベルと複数の機能の二軸
この2つが「マルチラーニング」
Multilevel learning:複数のレベル
個人、グループ、会社
Multifunctional learning:複数の機能
自分の専門外の分野を学習
Slide 84
Slide 84 text
５.Subtle control：緻密なコントロール
チームは自己組織化しているが、
マネジメントが「コントロールしない」わけではない
マネジメントは、不安定性、曖昧、緊張がカオスに変わる
ことを防ぐためのチェックポイントを確立する
それと同時に、創造性と自発性を損なうような
厳格なマネジメントを避けている
その代わりに、緻密なコントロールを行う
セルフコントロール
ピア・プレッシャーによるコントロール
愛によるコントロール
Slide 85
Slide 85 text
５.Subtle control：緻密なコントロール
「緻密なコントロール」の7つの方法
1. グループダイナミクス（集団力学）の変化を監視し、
プロジェクトチームに適切な人材を選択
2. （大部屋のような）オープンな作業環境
3. エンジニアが現場に出て
「顧客やディーラーが言わなければならないことを聞くこと」を奨励
4. グループのパフォーマンスに基づいた評価・報酬システム
5. 開発プロセスを通したリズムの違いを管理
6. 間違いの容認と予測
7. サプライヤに自己組織化を促す
何をすべきか(what to do)ではなく、問題を説明する
Slide 86
Slide 86 text
6.Organizational transfer of learning：学
習の組織的な移転
グループ内のマルチラーニングだけでなく、グループ外の人々に
学習を移転する
企業は、プロセスを標準化や制度化することによって、組織に
知識が伝わる
しかし、行き過ぎた標準化は、それが自体が危険を引き起こす
可能性がある。
外部環境が変化している場合、過去の成功体験からの標準
プラクティスはすぐに非実用的になる
アンラーニングは、チームが外部環境の現実性と調和を保つ
ことに役立ち、漸進的な改善のためのきっかけとなる
Slide 87
Slide 87 text
Moving the Scrum Downfield
「Moving the Scrum Downfield」の6つの特徴
1. Built-in instability：組み込まれた不安定性
2. Self-organizing project teams：自己組織化チーム
3. Overlapping development phases：
重なりあう開発フェーズ
4. Multilearning：マルチラーニング
5. Subtle control：緻密なコントロール
6. Organizational transfer of learning：
学習の組織的な移転
Slide 88
Slide 88 text
Some Limitations
いくつかの制限
新しいアプローチには制限がある
新製品開発の「すべての状況で機能する」とは
限らない
Slide 89
Slide 89 text
メンバーの途方もない努力が必要。
ピーク時には残業が100時間、それ以外は60時間
当てはまらないかもしれない
革新的なイノベーションを必要とする画期的なプロジェ
クト
航空宇宙企業のような大規模プロジェクト。
大きすぎて、Face-to-Faceが困難
一人の天才がイノベーションを発明し、配下の人々が明
確に定義された仕様に従う組織
Slide 90
Slide 90 text
Managerial Implications：
マネジメント層との関連
マネジメント層との関連
環境の変化（競争の激化、大規模な市場の分
裂、製品ライフサイクルの短縮、高度な技術と自
動化）により、マネジメント層は従来の製品開発
方法を再考せざるを得なくなった。
スピードと柔軟性を実現するには、製品開発プ
ロセスを異なる方法でマネジメントする
3種類の変化を検討するべき
Slide 91
Slide 91 text
Managerial Implications：
マネジメント層との関連
3種類の変化
1. プロセスを促進できるマネジメントスタイルを採用する
製品開発が線形的で静的に行われることはほとんどなく、試行錯
誤の反復的で動的なプロセスが含まれる。
2. 異なる種類の学習
従来のアプローチでは、有能なスペシャリストのグループ
対照的に、新しいアプローチは、非専門家が製品開発を行うため、
異なる学習が必要。
3. 新製品開発に異なるミッションをアサインする
多くの企業は、新製品開発を将来の収益源として扱ってきたが、
一部の企業では組織に変化をもたらす触媒としても機能する。
Slide 92
Slide 92 text
近年、環境は劇的に変化しており、
世界の市場で効果的に競争するための
ゲームのルールは変更された。
製品開発のスピードと柔軟性を達成するために、
試行錯誤とそれによる学習に依存する動的プロ
セスの利用が必要。
私達に必要なのは、絶え間なく変化する世界の
中での、絶え間ないイノベーションである
Slide 93
Slide 93 text
Introduction of article and
My understand
論文の内容紹介と
私の解釈
でした！
Slide 94
Slide 94 text
個人的な感想
注意したいこと
約35年前の論文。1976～1982年の少数の
製造業の新製品開発プロセスを分析した調査
結果である。約40年前の新製品開発のこと
うまくいったチームの共通項を見出したもので
あり、結果的なアプローチであり過程ではない
ソフトウェア開発ではない。スクラムそのもので
もない。
Slide 95
Slide 95 text
そう思った上で
Slide 96
Slide 96 text
個人的な感想
2020年の今でも大切だと感じる部分があるし、
新たな発見もある
「たしかにスクラムの原典だ」と感じられる内容
これらが1980年頃からあった！？という衝撃
自己組織化
クロスファンクショナルチーム
アンラーニング
マイクロマネジメントでないマネジメントの形
Slide 97
Slide 97 text
そういえば、
トヨタが出てきそうなのに
出てこなかった
(トヨタ生産方式は、
生産工程以降の話だから？)
Slide 98
Slide 98 text
個人的な感想
わからないことが増えた
ここからどうスクラムに繋がったかをさらに詳しく知
りたい。取り入れた要素や取り入れなかった要素、
変化した部分もあるはず。
特に、欧米の文化を前提にしているはず。
トヨタはどれくらい関係あるの？
わかりやすい例、制限の残業100時間の話は、
持続的でないと思うが、
スクラムはこの問題をどのように解決したのか？
Slide 99
Slide 99 text
個人的な感想
「The New New Product Development
Game」を読んでからRSGT2020に参加したこ
とで、解像度を高く理解できた
読んだこと自体は、「New Year」と掛けただけ。
偶然が重なった。
川口さんありがとうございます！
Slide 100
Slide 100 text
Conclusion：結論
Readable on the web:
Webで読める
“Harvard Business Review” did a Good Job!
https://hbr.org/1986/01/the-new-new-product-development-game
Slide 101
Slide 101 text
参考：川口さんの感想
https://kawaguti.hateblo.jp/entry/2009
0914/1252881028
Slide 102
Slide 102 text
参考：平鍋さんの「野中郁次郎のスクラム」
https://anagileway.com/2019/02/23/th
ank-you-scrum-fest-osaka-2019/
Slide 103
Slide 103 text
参考：アジャイル開発とスクラム
https://www.amazon.co.jp/gp/product/4
798129704/
Slide 104
Slide 104 text
Thank you for Listening
@kobase555
Software Developer.
I am an Agile fan.