Skip to content

Instantly share code, notes, and snippets.

@tnoda
Created January 8, 2015 14:06
Show Gist options
  • Save tnoda/d4baf80fcd101a32b781 to your computer and use it in GitHub Desktop.
Save tnoda/d4baf80fcd101a32b781 to your computer and use it in GitHub Desktop.

The New New Product Development Game

Intro

Scrum Origin

Scrum’s rich history can be traced back to a 1986 Harvard Business Review article, ”The New New Product Development Game” (Takeuchi and Nonaka 1986). This article describes how companies such as Honda, Canon, and Fuji-Xerox produced world-class results using a scalable, team-based approach to all-at-once product development. It also emphasizes the importance of empowered, self-organizing teams and outlines management’s role in the development process.

– Kenny Rubin, “Essential Scrum”, Chapter 1.

Takeuchi and Nonaka 1986.

Main

論文の概要

  • Takeuchi, Hirotaka, and Ikujiro Nonaka. “The New New Product Development Game.” Harvard Business Review (January–February 1986).
  • 新しい「新製品開発」ゲー
    • 新が二つなので “New New”
  • 製造業
    • ホンダ、富士ゼロックス、キャノン、ブラザー、3M, HP
  • より早く、より柔軟に攻略
    • 共通点を見つけた!

6 つの共通点

  1. 経営層の無茶振り (build-in instability)
  2. あとはよろしく (self-organizing project teams)
  3. フェイズなんて無かった (overlapping development phases)
  4. 多発学習 (multilerning)
  5. 隠密管理 (subtle control)
  6. 奥義の拡散 (organizational transfer of learning)

経営陣の無茶振り

無茶振りの例

  • 今までに無い若者向けの車を考えろ(ホンダ)
  • 製造コストを半分にせよ (富士ゼロックス)

無茶振りの条件

  • 責任は取るから自由にやれ
  • そして梯子を外す

あとはよろしく

無茶振りされた結果

  • 前例なし
  • どうやっていいか分からない

何が起こるか

  • 仕方がないので担当者たちで何とかする
  • 限界を突破する
  • 異種格闘技戦が起きる

フェイズなんて無かった (1/2)

一般的な開発では開発をフェイズに分割する。

フェイズなんて無かった (2/2)

しかし、より速く・より柔軟な開発を行っていたチームは違った。

lhs

刺身

./figs/sashimi.jpg

http://www.maff.go.jp/j/pr/aff/1101/mf_news_01.html

rhs

ラグビー

./figs/rugby.jpg

http://www.mod.go.jp/gsdf/1abnb/topics6much/index.html

多発学習

2 つの観点

重層学習

  • 個人の学び
    • cf. 3M の 15% ルール
  • グループの学び

そして総合格闘家へ

必要に迫られて

  • 柔道家がキックを学ぶ
  • ボクサーが寝技を学ぶ

隠密管理

ポイント

  • 自己管理に任せる (self-control)
  • 相互監視社会の確立 (control through peer pressure)
  • 社員は家族であり同志 (control by love)

7 つの方法

  • チームメンバーの随時入れ替え
  • オープンな職場環境 e.g. 大部屋
  • 技術者を顧客の元へ
  • 連帯責任(グループ単位で評価)
  • 開発の鼓動を感じとる
  • 間違いを無くせないことを知る
  • サプライヤの開発チームへの参加

奥義の拡散

2 つの方向

  • 後継プロジェクト
  • 社内の他のプロジェクト

注意点

  • 社内標準化すると速く広まるが変化への対応が遅くなる
  • あえて「昔のことは捨てる」会社もある
  • 環境が変わると奥義が無力化することが多い

いいことばかりではない

lhs

ブラック企業化

  • 毎月 60h 以上の残業
  • 多いときは当然 100 越え

過労死認定待ったなし

技術革新は起こせない

  • 新薬開発とか
  • 新素材開発とか

rhs

大規模プロジェクトには使えない

  • 時間と空間を共有することが前提
  • コミュニケーションコストの増大

天才を使いこなせない

  • 一人の天才が発明
  • 天才が詳細仕様を策定
  • 残りが下流行程を担当

経営層向け

  • 変化への対応が重要
    • 隣席症候群にかかったエンジニアは変化に対応できない
  • 変化に対応できる組織に
    • 経営層みずからが不確実性に挑戦しつづける
    • 開発フェイズの同時進行で多様性を制御する
    • 重要な決定を先送りできるようにする
  • 組織の学び・個人の学び
    • 従来は深い学び
    • 変化に対応するには広い学び
  • 新製品開発の目的は「製品開発」ではない
    • 会社に変化を起こすための「触媒」
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment