リーンカンファレンス2014
ずいぶん前の話になってしまったのですが、1/28日に永和システムマネジメントさん主催のリーンカンファレンス2014 (http://esminc.doorkeeper.jp/events/7693)に参加してきました。すぐに記事を公開するつもりが、下書き書いて満足してしまって、今日に至りました。
さて、このカンファレンスは、リーンソフトウェア開発とかTOCとか、リーンスタートアップとか、TPSから始まって様々な形に派生しているリーンを一同に集めてしまうという意欲的なカンファレンスです。特に面白かった内容を中心にまとめます。
トヨタのカタとリーン製品開発（稲垣公夫さん）
面白かったのはセットベース開発のお話。
セットベース開発では、セットベース開発では、構想段階では仕様を1つに決めないで、できるだけ多くの案を平行して開発していく。
まずは、以下の3つの領域で、充分に良く分かっていないことを洗い出す。（知識ギャップ分析）
事業目的
顧客価値
技術能力
これらの知識ギャップに対して、1つの仮説を決めるのではなく、複数の仮説（代替案）を出して、高速に検証しながら設計案を絞っていくというやり方。
僕らは、とりあえずでも1つの仕様を決めて、問題があれば都度対処していくやり方をするけど（これはポイントベース開発というらしい）、これだと、場当たり的に問題が発生してその都度手戻りが発生してしまい多くのムダが発生する。
セットベースでは、先に様々な仮説を検証することで、後からの手戻りを減らそうという考え方です。（フロントローディング）
また、検証結果はA3用紙一枚にまとめておき、次の開発でも活かせるようにしているらしく、ゴルフメーカーのPINがちょっとしたパラメータを変えただけで、新しいドライバーを開発した例が紹介されていました。
大量のA3データをどうやって管理しているんでしょうかね。
http://www.slideshare.net/leanconference/1inagakilean-conference2014-31061061
セールスバッファマネージャー開発事例（西原隆さん、羽根田洋さん、市谷聡啓さん、角征典さん）
TOCのコンサルティング会社の西原さんが自社の製品開発を永和システムマネジメントさんと一緒に紆余曲折しながら開発を進めたお話です。特に責任ある立場の方が自分の失敗事例を発表するのはとても勇気のいる行動だと思います。ありがとうございました。
ローンチまでの流れ
LAMDAモデルを使って、知識ギャップ分析
テストマーケティングしながら、仮説検証
LeanCanvasを作って、角さんに確認（かなり仮説の精度が高かった）
仮カタログを作って、コンセプトとストーリーを明確化
開発は、アジャイルで、インセプションデッキ、ストーリーScrum(?)
進めていくと、やっぱりこれも欲しいになる。それが続いて、明らかに予算オーバーが見えた。
一旦中断
再度予算確保して再開（アベノミクス効果www）
狩野モデルを使って、要求を分析して、当り前と魅力的機能に絞った。一元的要求はすべてカット。
無事ローンチ
予算的な制約があったにせよ、狩野モデルの一元的要求をすべてカットしたことはとても勇気がある行動だなと思いました。
一元的な要求が無いということは、競合製品の土俵に乗らないことを意味していて、これはかなりの覚悟が要ります。「そんなコトもできない製品なの？」になりますから、リスク回避型の人にはできません。
これでローンチするべきかどうかの話は別としても、MVPを作る上ではこれは良いアプローチだと思いました。
魅力的品質と当り前品質だけのMVPを作っておけば、その魅力的品質の価値が本当にあるのか検証が行えます。一元的品質を含めてしまうと、ミニマム(最小限)にならないし、当り前品質が無いとVaiable（実行可能）ではないのですよね。ただ、当り前品質は思い込みも多いので、魅力的品質だけに絞っても面白いかもです。
http://www.slideshare.net/leanconference/3-sb-mleanconference2014-31061070
大野耐一の創り方（金田 秀治さん）
今回のカンファレンスで一番面白かったです。金田さんが、大野耐一から直接教えを受けた言葉はとても刺激的でした。
それにしても、今回の金田さんといい、アジャイル系のカンファレンスでお話し頂いた黒岩さんといい元トヨタ系の方のエネルギーはんぱねーっす。
トヨタの強みは何か？
会社に必要な機能は3つある
今日の業績
明日の準備
企業の体質改善
大抵の企業は、今日の業績しか見ておらず、明日の準備を本当に組織や人事レベルまで落とし込んで真剣にできている会社はない。トヨタはそれがあるから強い。
トヨタの購買方針は、部品は買わない企業を買う。変化し続けられる企業から買う。
改善の種類
改善には2つの種類がある
1.負けないための改善:問題解決型 IE, QC,PM
2.勝つための改善：ありたい姿へのチャレンジ:TPS
改善とはより良くすることなのに、ほとんどの企業でやっているのは不具合対処。生産技術部門の尻拭いをしている。
大野耐一さんが、工場の視察に来た時に、金田さんが改善するアイデアが見つからないと相談した時に、返ってきたのはたった一言。
「困り方が足りん！」
大野さんは、滅多に答えを教えてくれる人ではなかったそうです。
トヨタの仕組み
TPS-1：鈴村喜久雄さん：QCDがありたい姿で、業界レベルを超える
TPS-2：大野耐一さん：ありたい姿に近づく
TPS-1は、トヨタの中で鈴村学校として、体系化されている
TPS-2は、大野ファミリーと呼ばれて、大野さんから直接教えを受けた人達で成り立っている（暗黙知の部分？）
モウカルとモウケルは違う
ムダの排除だけじゃ勝てない、トヨタはムダを徹底的に排除している。徹底的でなければいいかげん。
「負けない改善」はモウカルけど、これでは業界横並び、ありたい姿に近づくからこそモウケル
どうやったらありたい姿を描けるのか？
会場からの質問に対する答えなのですが、なんとかしたいと思って、現地現物現実を見ると何かに気付く、それがありたい姿。
http://www.slideshare.net/leanconference/6kaneda-leanconf2014-31115937
その他当日のスライド
ソフトウェア開発を加速させるリーン開発の原則：http://www.slideshare.net/leanconference/2amano-leanconf2014-31061068
派生開発をリーンにするXDDP：http://www.slideshare.net/leanconference/4xddp-leanconf2014-31061072
メイカーズ革命～オートデスクにおける３Dプリンタへの取り組みとアジャイルなビジネス環境～：http://www.slideshare.net/leanconference/5shiozawa-leanconf2014-3106107
個人的な感想
構想段階の意思決定を遅らせる
リーンスタートアップの考え方でも、最初の仮説は大抵外れるので、仮説 > 検証 > ピボット（方向転換）を繰り返すことが重要なのですが、場当たり的に進めていくと、あっちやこっちに方向性が変わっていって、「あれ？結局何をしたいんだっけ？」になりがちです。
新製品開発においては、セットベース開発の考え方で、構想段階に知識ギャップ分析をして、あらゆる仮説を洗い出し、1つに決めずに高速に仮説検証を繰り返しながら、1つの答えを導きだすというやり方の、効率的に正解に近づけるんじゃないかと思います。
負けないための改善で満足していないか？
アジャイルのプロジェクトだと、イテレーションの終わりに振り返りをやって小さな改善を繰り返します。これだけだと、金田さんの言葉を借りれば負けない改善が中心になってしまう。
勝てる改善は、プロジェクト内だけだと、どうにもならないことが多いので、それをきちんと会社として組織化できるかが重要だと思います。
