リーンカンファレンス2013～ヒット商品を作る仮説検証型開発プロセスとスキル～に参加しました

メモを取っていた分だけなので、漏れなどもたくさんあります。

詳細について

http://esminc.doorkeeper.jp/events/2263

会場

福井県ビジネス支援センター　福井南青山291　2F多目的ホール

会場名がややこしいが、表参道から3分くらいの場所にある。
1階は福井県のアンテナショップ。2階が多目的ホール。
床から電源がとれそうだったものの、金属製のフタが開かず利用できなかった、、、

アジャイルからリーンへ、そしてリーンスタートアップに

講師：平鍋　健児さん

会場アンケート。参加者の職業は？
→ソフトウェア開発者95%、ハード系、生産業はちらほら

永和の中でも半分はウォーターフォールのプロジェクト。
アジャイルはビジネス価値が高い、美味しい部分から作っていきましょうという話のこと。
いきなりショートケーキを作るようなイメージ。
　→今までは難しかったが、ソフトウェア工学が発展した。オブジェクト指向、テスト、リファクタリング、などなど技術の発展。
　15年前にはできなかったことができるようになってきた、しかし難しい。
　最近のお菓子業界は、本当にショートケーキを作れるようになっている。
　毎週ショートケーキを作るのは難しい。うまく合わせるのは大変。
　でも合わせる技術が発展してきた。それがリファクタリングなど。

自動車産業などは指をさして確認が可能。でもソフトウェアは指がさせない。
　→指がさせるものを作ってしまえ　→付箋などアナログ管理に繋がる
　ソフトウェアの成果物はハードディスクに埋もれて見えない。
　見えない状態を作らないようにする。

アジャイルの歴史
　→アジャイルはいくつもの方法論を合わせて呼ぶための名前。アンブレラワードと言われる
　リーンはソフトウェア生産をリーン形式の言葉に置き換えて、組織経営に関わる話としている
　元々はTPSからきている。デミングの思想が取り入れられている。
　テストされていないコード、作りかけは仕掛品だと最初に言い始めたのもリーン。
　KANBANは2010年頃、同じくリーンスタートアップも同じ頃。

スクラム
　→スクラムの原点はthe new new product development game
　new newとは「新製品開発の新しいやりかた」
　工程間で区切るのではなく、最初に考えた人は最後まで面倒を見ろ。ということ。

　スクラムではスプリントの前後が表現されていない。
　バックログはどこへ行くのか。作ったものはどこへ行くのか
　売れるか売れないかわからない世界。
「顧客開発」がもっとも重要。作らなくても、何をつくるべきなのかを見つける

リーンが製品開発を改革する

講師：稲垣　公夫さん

自己紹介
　リーン 元々は1990年、製品開発の世界から。
　1996年 リーンシンキング
　2003年 ザ・トヨタウェイ
　2000年の中場からトヨタのあらゆる切り口の研究がされた。本も多数出版された。

リーン生産とは
　・小さな仮説検証サイクルを繰り返す
　・安価で速い知識獲得方法
　リーンはイノベーションの方法であって、よく言われるような無駄取りではない。
　気がついていたらイノベーションが起きているのが日本的イノベーション

顧客価値の理解
　→顧客価値を理解していないとどうなるか　→　恐怖心から競合製品に入っている機能を全て入れる。いわゆる全部入りの製品ができてしまう。
　全部入りの製品は、使いにくい、値段が高すぎる、不要な機能が入っている

　もし顧客価値を理解していると、どうなるか。
　→ iPhone、ダイソンの掃除機（吸引力が落ちない）
　→ オクソの計量カップ　上から用量が読める
　これらは顧客に「何が欲しい？」と聞いても出てくるものではない。

リーン製品開発とは
　→チーフエンジニア制度、セットベース開発、リズム、流れ、A3プロセス　で構成される。

チーフエンジニアとは
　→起業家的システム設計者、ハイリスクハイリターンの職位。スーパーマン
　オクソの例
　　消費者の困りごとを解決する商品しかつくらないというポリシーがある
　　思い込みから脱する、仮説をたくさん立ててどんどん検証していく
　　日本人は他人の感情を読む能力が高い。誰でも顧客価値を理解できる

顧客価値を深く理解するためには技術的知識が必要。

セットベース開発とは
　→ライト兄弟。1900年頃、なぜアマチュアの発明家が成功できたのか
　「知識を獲得、記録してから設計した」
　当時の有人飛行では墜落して死ぬ人が多かった。ライト兄弟は絶対飛べる確信を得てから作りはじめた。結果、最初の設計で成功した。
　実験を繰り返す。小さな風洞を作って翼の模型を作ったり、揚力の計測をする毎日。
　今では航空工学という新しい学問を発明したと言われている
　　いきなり図面を書くのではなく、知識を得てから図面を書いていた

現在は競争が激しくなり、効率化やスピードが求められる事が多いのでポイントベースになってしまう。よくない。
ポイントベース開発＝希望的観測
セットベース開発＝得られた知識を再利用、

知識バリューストリーム。知識の再利用をする

知恵を工夫で補う。
組織が大きくなってくると、立派な試作品が無いと知識が得られないと思ってしまう
ラフからはじめようとしないとセットベースはうまくいかない

リズム、流れ
　→何を学習したか、何を学習するか。インテグレーションイベント。
　アジャイルと同じ。全てを計画することはない
　仮説　試作　検証のサイクルを繰り返す

徹底的な顧客価値理解をする
家電は量販店で売るようになってからいらない機能が増えていった
お客さんにアピールできる、いらない何かがついた商品が増えた

ゴルフクラブの改良の例
遠くにまっすぐ飛ぶこと以外は徹底的に排除。
これまでの新規開発で多様なデータが揃っていた。

まとめ
　→ヒット商品を確実に出すために
　　顧客価値を理解する、お客さんもしらないような価値をみつける
　　技術知識を身につける

TOCを活用したヒット商品開発プロセス

講師：西原　隆さん

質問：ザ・ゴール読んだ人は？
　→７割くらい
　生産の環境を変えていくビジネス小説　アメリカでは30年ぐらい前に出ている
　生産以外の分野の改善手法も。スループット会計、TOC、CCPM、などなど

リーンとTOC
　ゴールドラット博士
　巨人の肩に立って。影響を受けた人物はフォード、大野耐一。車以外の産業にも使えるように開発した
　リーンの子供がTOC
　ムダを無くす、過剰生産を防ぐ仕組み、全体最適を追求する、継続的改善。TOCとリーンは共通している
　ボトルネックがあるというのがTOCの考え
　　制約条件を管理して改善していく
　　計画のリスク、DBR CCPM DBM
　　思考プロセス
　　製造でDBR、開発でCCPM　→大和ハウス、マツダ、NTTデータ、ドラクエ10 2012の発表事例などなど

売れない商品を早く作っても意味が無い
　Fullkit: 準備が（要求、仕様の確定）が出来ていないプロジェクトにCCPMを適用しても成功させることは難しい
　セットベース段階はリーン、アジャイルで、その後にCCPMということをよくコンサルしている

売れない商品を早く開発してもいみがない
　売れないというのは、キャズムを超えていない状態。キャズムよりももっと前に消えていくものも多い

お客様は強い疑いを持っている。簡単に提案を信用しない。
　→営業でいい経験をしたことがない、完全に信用していない、買う気のあるところを見せてはいけない。

まず自分の製品で解ける問題を説明する。そこで合意形成を作ってから話を進めていく方法が良い
　しかし実際は営業マンは色々なものを売っている。全てでこれを実践するのは難しい。。。
　そのため「売り方を開発」する必要がある。断れないほど魅力的な提案＝マフィアオファー
　　→６段階の抵抗を乗り越える。A3シートに作る。商品企画、営業、開発で仮説検証チームを作る
　　　お客様は機能ではなく、もたらされたよい状態を買う

提案営業とコンセプト立案、構想設計、開発実行
開発と営業の溝を無くす活動が必要。組織の壁が無くなって、初めて出来る。

バリューストリームがビジネスアジリティを加速する　～リーンアジャイルの海外事例～

講師：市谷　聡啓さん

質問：アジャイルを知らない人
　→０人
質問：アジャイル開発をなにかしらやっている
　→半分くらい

よくある課題
　→企画と開発の分断

　ビジネス側
　→一旦企画が開発側に渡ったらあとはお任せ。開発の状況がわからない。
　どういうフューチャーがどういう状態にあるのか、いつリリースできるのかわからない

　開発側
　→来た玉を打つ。何故その要求なのか？まで立ち入らない。基準がわからないので言われた通り作る
　開発チームは頑張るが、部分最適化が進む。

　　ユーザーや顧客のために生まれたアイディアがソフトウェアになり、価値が生まれるというサイクルが回せない

Alan Shalloway の話していたagile conference 2012の内容
　http://www.manaslink.com/articles/4435
　カスタマーからコンセプトが生まれる　→　ビジネスが受け取ってプロダクトにする　→　devが開発　→　カスタマーに戻す
　この流れの中に様々なボトルネックがある。

　質問：「バリューストリーム」を聞いた事が無い人
　→３割くらい

　お客様から始まって、要求がお客様に戻っていくまでの価値の流れ＝バリューストリーム
　ビジネスディスカバリー、ビジネスデリバリー
　MMF＝ユーザにとって価値があって、最小限のもの

　時間を計り、どこに時間がかかっているのか。
　　作業している時間と待ちの時間を算出、アクションからアクションに移る時間もかかるので計る
　　手戻りもある、この時間も計る
　　待ちを含めて全部にかかる時間が見えてくる
　　流れを滞らせているものが何か
　　同時に仕懸かる？待ち合わせ？
　　遅れを評価していない
　　大きすぎ、複雑すぎてわからない

　特定の人に役割が集中してボトルネックになることがよくある

　プロダクトオーナー、プロダクトマネージャーのロールを分けるといい、という話も。
　　マネージャーはMMFにしていく人
　しかしPOの役割を分けると、コミュニケーションのボトルネックが新たに生まれる可能性
　お互いが共通の目標に向かって、日々の状況がわかる仕組みが必要
　　そこでバリューストリーム。どこで分断していたかがわかる。

概念はとてもよくわかるが、これだけでは実践できない。
現場を支える仕組みが必要
そこで

Henrik Knibergさんの話
http://www.manaslink.com/articles/4535

普通のソフトウェアかんばんと言われているものは「todo doing done」で構成されている。これをバリューストリームにする
ideas, feature, next 10 feature, develop, system test などなど、1つでバリューストリームの全てを表現する

デイリーMTGはdelivery cocktail Party
　それぞれのチームで、それぞれの看板を更新
　次の時間で役割毎に集まり直す
　チームだけが知っていれば良いタスクは、タスク用カンバンで分ける

しかしアナログでは定量的に測定するのが難しい
　ベロシティの計算など、手でやるのは大変。
　しかし方法はある。フィーチャー毎にどのくらい時間がかかったかを計る。サイクルタイム。着手した時間と、完了した時間をメモっておく

バリューストリームの書き方
　自分がユーザーの要求になったつもりで、各ステップを通過していく
　歩き回って、自分で発見する。人に聞かない
　書く時間は30分。それ以上かけると詳細になりすぎると。
　顧客から始まり、顧客に終わる。
　マップそのものに価値は無い

リーン開発時代に求められるスキルとキャリア

講師：渡辺　登さん

過去にIPAでスキル標準の策定などを行っていたが、スキル標準を作っていても人材育成には繋がらない

いいものを作っていれば良いという時代ではなくなった
　→ITスペシャリスト、ITアーキテクトから、ビジネスクリエータ、サービスクリエータ

富士通が再定義したロール
　→ビジネスプロデューサ、フィールドイノベータ、コンサルタント、サービスインテグレータ

あまりメモ取れず

アイデアを事業に進化させる企業のサイエンス〈リーンスタートアップ〉

講師：和波　俊久さん

リーンスタートアップの歴史
　元をたどるとスティーブン・G．ブランク。
　ベンチャーの失敗のパターンをまとめていた
　メモ取れなかったのですが、http://www.venturenow.jp/column/ogawa/20120704018199.html　あたりをどうぞ。

フィードバックループで何を学ぶのか
　→そのために、何を作るのか
　事業は一発勝負ではない。積み重ね。

会社の中でやる新規事業開発はお金はそれほど重要ではない
　サポート、支援は大事
　だがモチベーションが一番大事。無くなると何も起きないし、誰も何もしようとしない。
　起業はサイエンスとマネジメント。ようは学べるし実践できる。

いまでも生き残っている会社には、何らかの勝ちパターンがある
　→それを誰でも出来るようにプロセス化　→　きちんと出来る（プロセスを守れる）人が評価される
　マニュアルから外れる人は非常識として扱われてしまう。

　常識が一番のリスク。
　脱皮しない蛇は死ぬ。
　計画を実行できる人よりも、想定外の変化への対応力が必要

ゲームチェンジャーの出現の兆候
　カテゴリ名が変わる時
　携帯電話→スマートフォン　携帯市場がスマホ市場。こういう変化では新しいビジネスモデルが生まれる事がよくある。
　現在は自動車→EVが始まっている。ただの乗り換えだけではない、ガワだけ買ってソフトを入れて。という世界になるのでは。アメリカでは既に数百の会社が。。
　破壊的イノベーションが起きている可能性が高い

スピードを上げるというのは無駄を無くすということ。
無駄の見極めがリーンの本質。

長期で大きいものであれば失敗のイライラが大きい
小さく失敗すればイライラも小さい。そこで学んで次に生かす

感想

平日の昼からということもあり、スーツ率が非常に高かった。
一番良かったのはやはり市谷さん。バリューストリームについてはちょうど「リーンソフトウェア開発と組織改革」を読んでいたところだったのでしっくりきた。

リーンソフトウェア開発と組織改革

そしてバリューストリームそのものをカンバンにしてしまうのは確かに有効な手だと思う。ただしスクラムと相性が悪い感じも。それぞれのエリアで分業が進んでしまいそうかなぁ。悪い事ではないのだけども。
そして「セットベース開発」。これは初耳。
ようは学びをちゃんと溜め込んで、検索もできるようにして有効活用して、打率を上げていこうということなんだけども、リーンスタートアップ的な「まずやってみる」みたいな考えとは相反する。
しかしリーンスタートアップでいう learn の結果をきちんと残すような活動が出来ていれば、いずれセットベース開発のようになるのではなかろうか？

リーンとリーンスタートアップは別物だけど、よく混同されがち。別物だと理解している人じゃないと今回のイベントは辛いのでは？と。（特に最後が和波さんだったりとか）
自分としてはもうちょっとリーンの本質的な部分を勉強する必要がある。こっちのほうがスクラムよりも組織論としてお話出来るようになれる。