リーンカンファレンス２０１３に行ってきた。
そのときのメモメモ 前半
■アジャイルからリーンそしてリーンスタートアップに
平鍋さん
ソフトのひと：圧倒的に多い
今日の人の紹介
バリューストリーム
作ったものがお客さんに届くのか
なぜ今アジャイルか
ミッション・リスク分割型ビジネスと
ウォーターフォール型開発（従来型）
→永和システムでもまだ半分ウォーターフォール
市場⇔ ビジネス ⇔IT
（ユーザー⇔情報システム部門⇔ベンダー）
従来型の問題＝要求の劣化
Stundishのデータ
６０％くらい使われない
ミッションリスク共有型ビジネスと
アジャイル型開発
市場にミートする製品
短いサイクル（２週間とか）でテストまでやってしまう
分割の仕方
ホールケーキでなくショートケーキを作る
ソフトウェア工学のおかげ
IDE：リファクタリング
クラウド・開発環境
→在庫もたなくていいけど、むずかしい
Webを使っている場合、ケータイアプリでは普通にできる
契約がむずかし
スクラム
製品バックログ：上から並んでいること
１週間で作れるものを抜き出す
タスクカンバン
Todo
Done
成果物→ハードディスクにある
→とまっているところ指がさせない
→させるようにする
アジャイルの現在位置
XP, →Agile→Lean
野中・竹内、Scurum
Leanの言葉でアジャイルを語る
TPS、デミングの思想をいれる：Lean
いま
大規模
組織改革
Lean／Agile
Agile／UX
kanban
Lean Startup：少量の投資で
スクラム
The new new product development game
ハーバードビジネスレビュー、野中先生が言っている
Lean Startup
製品バックログはどこからきて、どこへいくのか
→LeanStartupの入り口
顧客開発：作らなくてもいいから、どうみつけるか
アジャイルとスクラムの本
■リーンが製品開発を革新する
リーン、TOCとのかかわり
リーンの系譜
リーン：MITのベンチマーキング
日本の生産圧倒的高い
ウォーマック：リーンシンキング
ザ・トヨタウェイ
別の系譜
トヨタ生産方式
もうひとつの流れ（ソフト）
リーンソフトウェア開発
KANBAN
リーンスタートアップ
共通点
小さな「仮説→検証」サイクルを繰り返す
安価で早い知識獲得方法
組み立てラインで普及：スバル３６０
日本の製造業が生き残るには
ダントツ商品
→顧客価値の理解
→顧客価値実現のための技術的知識
→日本型イノベーション：リーン製品開発
リーン製品開発の発見
アレン・フォード博士
セットベース開発
トヨタだけが特別な設計
２００４年に博士がなくなる
勢い弱まる：リーン生産より小さい
成功事例
ハーレーダビッドソン
リーン製品開発
セットベース開発
|
チーフエンジニア制度 ------- リズム・流れ
---------------------------------------------------
A3プロセス（A3：１枚にすべてを書く）
顧客価値を理解していないと
→恐怖心から競合製品に入っている機能を全部入れる
使いにくい
高すぎる
不要な機能が入っている
顧客価値を理解していれば
・iPhone
楽しい
使いやすい
感動する
Dyson
美しい
吸引力落ちない
OXOけいりょうカップ
上からメモリ見える
これらの製品はいずれも顧客に何がほしいと聞いても出てこなかっただろう
チーフエンジニア
・起業家的システム設計者
顧客価値を深く理解
顧客価値を深く理解する方法
方法
体験法（自分が体験する）
観察法
主婦の調理の様子を観察
面接法
どんな問題を解決したいか
いつ幸せを感じるかを聞き出す
注意点
細かいことを見逃さない
旺盛な好奇心を持つ
脱思い込み思想
顧客の身になって考える（自己移入）
常に仮説を立てる
顧客の感情上のマイナスやプラスに敏感
マイナス：不快感、不満、問題
プラス ：高揚感、幸福感
セットベース開発
ライト兄弟の驚くべき成果
サミュエル・ラングリー １４年間：１度も成功せず
ライト兄弟：趣味で４年で、最初の設計で（２回目の実験）で成功
アマチュア発明家がなぜ？
知識を獲得・記録してから設計
ライト兄弟：死にたくなかった
→革新を盛ってから設計
風洞実験：数表、グラフに
設計
航空工学の発明
間違いだらけの製品開発改善
昔：構想設計
競争激化→効率化、LT短縮：CAD、フェースゲート：構想設計に適していない
今：詳細設計
構想設計段階を軽視、手戻り増える
ポイントベース開発とセットベース開発
ポイントベース
希望的観測によるキメうち
セットベース開発
代替案を考えていく。急がば回れ
セットベース開発の効果
・イノベーションを系統的に生み出す
・詳細設計期間・コスト激減
・開発効率が向上
セットベース開発に必要な知識
トレードオフ曲線
因果関係図
設計空間の領域を序所に狭める
製品開発での最大のムダは
開発中に獲得した知識を使い捨てにすること
図面以外の知識は暗黙知識化
リーンj開発学習システム
・知識ギャップ発見
・知識獲得
・文書化
・知識整理
・再利用のために一般化、承認
A3で知識ベースを作る
知識バリューストリームと製品バリューストリーム
安価に知識を獲得する
安価、部分的、低精度
スケッチ、モックアップ
↓
シミュレーション
ラピッドプロトタイプ
部分試作品
バラックセット
↓
技術試作品
量産試作品
流れ、リズム、プル
インテグレーション・イベント
代替案絞込、次段階学習計画
計画スパン：次のインテグレーションイベントまでしか立てない
遅れが出たら、上司がサポート
リーン製品開発でダントツクラブを開発したピン
マーケティングギミック
因果関係図
トレードオフ曲線を利用してダントツグラフ
まとめ
・ダントツ商品を確実に開発する鍵は
顧客価値知識
技術知識
リーン製品開発の効果
チーフエンジニア
顧客価値知識獲得
セットベース開発
技術知識獲得・再利用
顧客価値知識獲得
｜
｜
｜
---------------------------
｜ 技術知識獲得
知識の ｜
再利用 ｜
■リーンTOCによるヒット商品開発
制約条件の理論
CCPM
TOC（成約条件の理論）の発展の歴史
・ザ・ゴール 日本２００１年 アメリカ1983年
ゴールドラット
市場に対して、社内に対してどのように合意を得るか
クリティカルチェーンマネジメント
リーンとTOC
ゴールドラット：巨人の肩の上に立って （ダイアモンド）
→ニュートンの言葉
２人：ヘンリーフォード、おおのたいち
とよたTOCとは異なるが
根本同じ(共通）
ムラをなくす
過剰生産を防ぐ
全体最適
継続的改善
TOC（制約条件の理論）とは
鎖の強度：ゴール
最も弱い鎖：制約条件
制約条件を徹底的に管理する
計画のリスク：DBR／CCPM／DBM
合意形成のリスク：TOC執行プロセス
製造：DBR関係 たくさんある
開発：CCPM関係 （クリティカルチェーン）多く発表
CCPM活用の留意点
・売れない商品をCCPMを活用して早く開発しても意味がない
・FullKit：準備（要求・仕様の確定）ができないプロジェクトに
CCPMを適用しても成功させることが難しい
CCPMは実行時間のばらつきをヘッジする方法
フルキットになってから実行
アジャイル、リーンでできてから
売れないとは：製品ライフサイクル
よい製品だが売りにくい、ほとんどの製品は消滅していく
キャズム
アントレプレナーの教科書：キャズム前（ジャングル）
商品のメリットについて合意形成するための営業マンによる提案営業
営業の現場
お客さんは強い疑いを持っており提案を簡単には信用しない
カタログX
御用聞き
買い手の立場に立って問題を説明し、信頼を取り付けてから提案する
売り方を開発する
断れないほど魅力的な提案＝マフィアオファー
抵抗の６段階に対するマフィアオファーシート
１．問題に合意する
２．解決の方向性に合意
３．われわれの製品で解決できる
４．懸念事項
５．上司、関係者にも説明
６．言い表せない恐怖
A3一枚にまとめる
営業・商品企画・開発のいろいろな観点から
特徴的な機能３つをあげる
２０もあげちゃX
お客様にどういう良い状態を与えるか
これをひっくり返した悪い状態を作る
企業全体にどういう影響を与えるか合意
株主
従業員
お客様
重大問題
仮説→検証する（すぐ行く）
反応をまとめる
１：その問題はない
２：問題の存在不明
３：問題に対して受動的
４：能動的
５：
仮説検証を繰り返し、売り方を開発させる
マフィアオファーシート作成での学びを次期開発のインプットとする
１．特徴的機能は競合に対してダントツか
２．本当に重要な問題を解決できているか
３．懸念事項をなくす
BufferManagementのブログにいろいろ書いている
■VALUE STREAM & KANBAN FOR BUSINESS AGILITY
ビジネス価値を形にすることに、ソフトウェア開発は
どのように貢献するか
→Lean Agile
Agile２０１２
このセッションが扱う課題
企画と開発の分断
企画が開発にわたったら、あとはおまかせ
来た玉を打つ的に、要求を実装する
取り上げるセッション
２つバリューストリーム（あらん）
かんばん
あらんのはなし
アジャイルジャパン２０１０で話している
ソフトウェアバリューストリーム
バリューストリーム
お客様からはじまって、
要求が、ビジネス、開発をとおり
お客様にもどろまでの流れ
ビジネスディスカバリー
優先順位
計画作り（MMFユーザーにとって価値がある必要最小限の要求）
開発に引き渡す準備
開発チームに渡せる状態
ビジネスデリバリー
出荷可能な状態
各ステップをアクションに落とし込む
どこに時間をかけるか
流れを滞らせているのはなにか
多くのことを同時に仕掛ける
ほかとの待ち合わせ
遅れのコストを評価していない
対象大きすぎ／複雑すぎ
→特定の人に偏り
解決する手段
役割分担
プロダクトマネージャー：ビジネスのプロデューサー
プロダクトオーナー：システムプロデューサー
→コミュニケーションの問題：共有できる仕組み
なぜ、バリューストリーム
改善する箇所を検討できる
現状に対するToBeをかく機会
バリューストリームマップ
お話の世界？→ヘンリックへ
ヘンリック
ソフトウェアカンバン
Todo
doing
done
ヘンリックの話
フィーチャーがわかる
ひとつのカンバンですべてあらわす
役割に関わらず１枚のカンバンを共有する
プロジェクト全体とチーム固有
何度でも書き直す
Value Streamとは何か
自分が顧客の要求になったつもり
組織内を歩き回って自分で発見する。人に聞かない
「リーンソフトウェア開発」「リーン開発の本質」の本に出てる
ケントベック
マップ作るのは３０分
顧客に始まり、顧客に終わる」
マップ自体には価値はない
ValueStreaｍは、自分たちで書く
振り返れば、カンバンがある 楽天 及部氏
お話と日常をつなげる仕組みは必要
つづく・・・
そのときのメモメモ 前半
■アジャイルからリーンそしてリーンスタートアップに
平鍋さん
ソフトのひと：圧倒的に多い
今日の人の紹介
バリューストリーム
作ったものがお客さんに届くのか
なぜ今アジャイルか
ミッション・リスク分割型ビジネスと
ウォーターフォール型開発（従来型）
→永和システムでもまだ半分ウォーターフォール
市場⇔ ビジネス ⇔IT
（ユーザー⇔情報システム部門⇔ベンダー）
従来型の問題＝要求の劣化
Stundishのデータ
６０％くらい使われない
ミッションリスク共有型ビジネスと
アジャイル型開発
市場にミートする製品
短いサイクル（２週間とか）でテストまでやってしまう
分割の仕方
ホールケーキでなくショートケーキを作る
ソフトウェア工学のおかげ
IDE：リファクタリング
クラウド・開発環境
→在庫もたなくていいけど、むずかしい
Webを使っている場合、ケータイアプリでは普通にできる
契約がむずかし
スクラム
製品バックログ：上から並んでいること
１週間で作れるものを抜き出す
タスクカンバン
Todo
Done
成果物→ハードディスクにある
→とまっているところ指がさせない
→させるようにする
アジャイルの現在位置
XP, →Agile→Lean
野中・竹内、Scurum
Leanの言葉でアジャイルを語る
TPS、デミングの思想をいれる：Lean
いま
大規模
組織改革
Lean／Agile
Agile／UX
kanban
Lean Startup：少量の投資で
スクラム
The new new product development game
ハーバードビジネスレビュー、野中先生が言っている
Lean Startup
製品バックログはどこからきて、どこへいくのか
→LeanStartupの入り口
顧客開発：作らなくてもいいから、どうみつけるか
アジャイルとスクラムの本
■リーンが製品開発を革新する
リーン、TOCとのかかわり
リーンの系譜
リーン：MITのベンチマーキング
日本の生産圧倒的高い
ウォーマック：リーンシンキング
ザ・トヨタウェイ
別の系譜
トヨタ生産方式
もうひとつの流れ（ソフト）
リーンソフトウェア開発
KANBAN
リーンスタートアップ
共通点
小さな「仮説→検証」サイクルを繰り返す
安価で早い知識獲得方法
組み立てラインで普及：スバル３６０
日本の製造業が生き残るには
ダントツ商品
→顧客価値の理解
→顧客価値実現のための技術的知識
→日本型イノベーション：リーン製品開発
リーン製品開発の発見
アレン・フォード博士
セットベース開発
トヨタだけが特別な設計
２００４年に博士がなくなる
勢い弱まる：リーン生産より小さい
成功事例
ハーレーダビッドソン
リーン製品開発
セットベース開発
|
チーフエンジニア制度 ------- リズム・流れ
---------------------------------------------------
A3プロセス（A3：１枚にすべてを書く）
顧客価値を理解していないと
→恐怖心から競合製品に入っている機能を全部入れる
使いにくい
高すぎる
不要な機能が入っている
顧客価値を理解していれば
・iPhone
楽しい
使いやすい
感動する
Dyson
美しい
吸引力落ちない
OXOけいりょうカップ
上からメモリ見える
これらの製品はいずれも顧客に何がほしいと聞いても出てこなかっただろう
チーフエンジニア
・起業家的システム設計者
顧客価値を深く理解
顧客価値を深く理解する方法
方法
体験法（自分が体験する）
観察法
主婦の調理の様子を観察
面接法
どんな問題を解決したいか
いつ幸せを感じるかを聞き出す
注意点
細かいことを見逃さない
旺盛な好奇心を持つ
脱思い込み思想
顧客の身になって考える（自己移入）
常に仮説を立てる
顧客の感情上のマイナスやプラスに敏感
マイナス：不快感、不満、問題
プラス ：高揚感、幸福感
セットベース開発
ライト兄弟の驚くべき成果
サミュエル・ラングリー １４年間：１度も成功せず
ライト兄弟：趣味で４年で、最初の設計で（２回目の実験）で成功
アマチュア発明家がなぜ？
知識を獲得・記録してから設計
ライト兄弟：死にたくなかった
→革新を盛ってから設計
風洞実験：数表、グラフに
設計
航空工学の発明
間違いだらけの製品開発改善
昔：構想設計
競争激化→効率化、LT短縮：CAD、フェースゲート：構想設計に適していない
今：詳細設計
構想設計段階を軽視、手戻り増える
ポイントベース開発とセットベース開発
ポイントベース
希望的観測によるキメうち
セットベース開発
代替案を考えていく。急がば回れ
セットベース開発の効果
・イノベーションを系統的に生み出す
・詳細設計期間・コスト激減
・開発効率が向上
セットベース開発に必要な知識
トレードオフ曲線
因果関係図
設計空間の領域を序所に狭める
製品開発での最大のムダは
開発中に獲得した知識を使い捨てにすること
図面以外の知識は暗黙知識化
リーンj開発学習システム
・知識ギャップ発見
・知識獲得
・文書化
・知識整理
・再利用のために一般化、承認
A3で知識ベースを作る
知識バリューストリームと製品バリューストリーム
安価に知識を獲得する
安価、部分的、低精度
スケッチ、モックアップ
↓
シミュレーション
ラピッドプロトタイプ
部分試作品
バラックセット
↓
技術試作品
量産試作品
流れ、リズム、プル
インテグレーション・イベント
代替案絞込、次段階学習計画
計画スパン：次のインテグレーションイベントまでしか立てない
遅れが出たら、上司がサポート
リーン製品開発でダントツクラブを開発したピン
マーケティングギミック
因果関係図
トレードオフ曲線を利用してダントツグラフ
まとめ
・ダントツ商品を確実に開発する鍵は
顧客価値知識
技術知識
リーン製品開発の効果
チーフエンジニア
顧客価値知識獲得
セットベース開発
技術知識獲得・再利用
顧客価値知識獲得
｜
｜
｜
---------------------------
｜ 技術知識獲得
知識の ｜
再利用 ｜
■リーンTOCによるヒット商品開発
制約条件の理論
CCPM
TOC（成約条件の理論）の発展の歴史
・ザ・ゴール 日本２００１年 アメリカ1983年
ゴールドラット
市場に対して、社内に対してどのように合意を得るか
クリティカルチェーンマネジメント
リーンとTOC
ゴールドラット：巨人の肩の上に立って （ダイアモンド）
→ニュートンの言葉
２人：ヘンリーフォード、おおのたいち
とよたTOCとは異なるが
根本同じ(共通）
ムラをなくす
過剰生産を防ぐ
全体最適
継続的改善
TOC（制約条件の理論）とは
鎖の強度：ゴール
最も弱い鎖：制約条件
制約条件を徹底的に管理する
計画のリスク：DBR／CCPM／DBM
合意形成のリスク：TOC執行プロセス
製造：DBR関係 たくさんある
開発：CCPM関係 （クリティカルチェーン）多く発表
CCPM活用の留意点
・売れない商品をCCPMを活用して早く開発しても意味がない
・FullKit：準備（要求・仕様の確定）ができないプロジェクトに
CCPMを適用しても成功させることが難しい
CCPMは実行時間のばらつきをヘッジする方法
フルキットになってから実行
アジャイル、リーンでできてから
売れないとは：製品ライフサイクル
よい製品だが売りにくい、ほとんどの製品は消滅していく
キャズム
アントレプレナーの教科書：キャズム前（ジャングル）
商品のメリットについて合意形成するための営業マンによる提案営業
営業の現場
お客さんは強い疑いを持っており提案を簡単には信用しない
カタログX
御用聞き
買い手の立場に立って問題を説明し、信頼を取り付けてから提案する
売り方を開発する
断れないほど魅力的な提案＝マフィアオファー
抵抗の６段階に対するマフィアオファーシート
１．問題に合意する
２．解決の方向性に合意
３．われわれの製品で解決できる
４．懸念事項
５．上司、関係者にも説明
６．言い表せない恐怖
A3一枚にまとめる
営業・商品企画・開発のいろいろな観点から
特徴的な機能３つをあげる
２０もあげちゃX
お客様にどういう良い状態を与えるか
これをひっくり返した悪い状態を作る
企業全体にどういう影響を与えるか合意
株主
従業員
お客様
重大問題
仮説→検証する（すぐ行く）
反応をまとめる
１：その問題はない
２：問題の存在不明
３：問題に対して受動的
４：能動的
５：
仮説検証を繰り返し、売り方を開発させる
マフィアオファーシート作成での学びを次期開発のインプットとする
１．特徴的機能は競合に対してダントツか
２．本当に重要な問題を解決できているか
３．懸念事項をなくす
BufferManagementのブログにいろいろ書いている
■VALUE STREAM & KANBAN FOR BUSINESS AGILITY
ビジネス価値を形にすることに、ソフトウェア開発は
どのように貢献するか
→Lean Agile
Agile２０１２
このセッションが扱う課題
企画と開発の分断
企画が開発にわたったら、あとはおまかせ
来た玉を打つ的に、要求を実装する
取り上げるセッション
２つバリューストリーム（あらん）
かんばん
あらんのはなし
アジャイルジャパン２０１０で話している
ソフトウェアバリューストリーム
バリューストリーム
お客様からはじまって、
要求が、ビジネス、開発をとおり
お客様にもどろまでの流れ
ビジネスディスカバリー
優先順位
計画作り（MMFユーザーにとって価値がある必要最小限の要求）
開発に引き渡す準備
開発チームに渡せる状態
ビジネスデリバリー
出荷可能な状態
各ステップをアクションに落とし込む
どこに時間をかけるか
流れを滞らせているのはなにか
多くのことを同時に仕掛ける
ほかとの待ち合わせ
遅れのコストを評価していない
対象大きすぎ／複雑すぎ
→特定の人に偏り
解決する手段
役割分担
プロダクトマネージャー：ビジネスのプロデューサー
プロダクトオーナー：システムプロデューサー
→コミュニケーションの問題：共有できる仕組み
なぜ、バリューストリーム
改善する箇所を検討できる
現状に対するToBeをかく機会
バリューストリームマップ
お話の世界？→ヘンリックへ
ヘンリック
ソフトウェアカンバン
Todo
doing
done
ヘンリックの話
フィーチャーがわかる
ひとつのカンバンですべてあらわす
役割に関わらず１枚のカンバンを共有する
プロジェクト全体とチーム固有
何度でも書き直す
Value Streamとは何か
自分が顧客の要求になったつもり
組織内を歩き回って自分で発見する。人に聞かない
「リーンソフトウェア開発」「リーン開発の本質」の本に出てる
ケントベック
マップ作るのは３０分
顧客に始まり、顧客に終わる」
マップ自体には価値はない
ValueStreaｍは、自分たちで書く
振り返れば、カンバンがある 楽天 及部氏
お話と日常をつなげる仕組みは必要
つづく・・・
アクセス
トータル
ランキング
