リーンカンファレンス2013でリーン開発に興味を持った！前半戦

widthw photo by @TAKAKING22

2013年1月28日、道の端っこにうっすら雪が残る日、

ふくい南青山291で開催されました「リーンカンファレンス2013　～ヒット商品をつくる仮説検証型開発プロセスとスキル～」に行ってきました！(雪国出身としてはもっと降ってほしかった)

こうゆうセミナーはあまり参加したことないんですが、職場の方にお勧めされたのと同時にアジャイル開発も行っているので、行かせていただきました。良い刺激になりましたっ！単なる感動ですがメモっておこうと思います！

☆「アジャイルからリーンへ、そしてリーンスタートアップに」平鍋さん☆

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

（あああ…あの本を執筆している平鍋さんだ…ﾄﾞｷﾄﾞｷ。サイン貰えばよかった…）

リーン開発の本質 ソフトウエア開発に活かす7つの原則

リーンソフトウェア開発についての本を多数翻訳されているんですね。

• ウォーターフォール型(従来型)の開発だと機能の60%は使われない
• 要求の劣化
• 市場、ビジネス、IT、それぞれのゴールが異なる

• ウォーターフォールはホールケーキ　⇔　アジャイルはショートケーキ
• ショートケーキだと、一番フレッシュな状態でお客様に提供できる
• ホールケーキだと一番下のスポンジ作る人はつまらないかも… ⇒この例がわかりやすいっ！確かに全行程を経験したほうが楽しいし

  

• タスクかんばん

• 実態のある物だと指をさせるが(ここで止まってるんじゃない？etc)、ソフトウェアだと明確にここと指差せない
• なら、タスクを作って貼って指差せるようにしてしまえば良い
  ⇒ 実際に現場でもタスクかんばんを用いてやっているけれど、遅れているか、順調なのかの進捗具合が目に見えてわかりやすいと思います！
  タスクを行うにあたって邪魔している問題を、他のメンバーだとすぐに解決できることもありますしね！
  

• TPS⇒って何それーって思ってたけど、トヨタ生産方式のことなんですね汗

トヨタ生産方式―脱規模の経営をめざして

今度読んでみたいー。

• アジャイルのホットな話題？
• 大規模開発、組織改革、リーン/アジャイル、アジャイル/UX(ユーザエクスペリエンス)

UXデザイン入門―ソフトウェア&サービスのユーザーエクスペリエンスを実現するプロセスと手法

UXっておもしろそう！ユーザが何かを使ったときに経験するプラスの感情を価値として重視…へえええええ！やはりなんでもできちゃう時代、他との差をつけるためにはこうゆうことも考慮しないといけないですよね

• kanban　⇒　ん？タスクかんばんとは別物？
• リレー　VS　ラグビー　⇒これ何の話だっけ……

何気なくアジャイル開発をしていたけど、なぜアジャイルが広まりつつあるのか、どういう経緯で生まれたのかなど知らなかったなあ …。

 ☆「リーンが製品開発を改革する」稲垣さん☆

• 日本のトヨタ生産方式→アメリカでリーンが生まれ→日本に逆輸入された
• 小さな仮説と検証を繰り返す
• 生産者のアイディアを反映させるため
• ダントツ商品→顧客価値→技術的知識

• リーン開発が生まれた歴史
• アレン・ウォード博士が日本のトヨタを視察
• 生産性5倍増の実績を上げたが、亡くなった後勢いが小さくなった
• A3プロセス
• A3用紙に全ての仕様を書く。知識を書く。

トヨタ式A3プロセスで仕事改革―A3用紙1枚で人を育て、組織を動かす

⇒A3プロセス…よくわからない…
少しだけ調べてみると、問題解決できる人を育て、組織を動かす…
うーん詳しくてわかりやすいのを探そうー

• 顧客価値
• 顧客価値を理解していないと、お客様があれもこれも欲しい！→全ての機能を入れる→結局機能いっぱいあって使いづらい

• 顧客価値を理解した例だと、ダイソンやiPhone、上からメモリが見れる計量カップなど
• 顧客価値はユーザに聞いてもでてくるわけではない
• ここにはチーフエンジニア(CE)の存在がある
• 体験法　観察法　面接法
  細かいことを見逃さない
  好奇心旺盛
  ！仮説をどんどん立てる！
  ！固定概念をなくす ！

 ⇒ユーザの潜在的な欲望？という言葉が正しいのかわかりませんが、それを引き出してものをつくるのが重要ですよね

• セットベース開発
• サミュエルラングリーは十数年間、一度も航空機を飛ばせなかった
• ライト兄弟は、たった4年で飛ばすことに成功した
• ライト兄弟は、とにかく死にたくなかった。だから、知識を獲得してから設計をし、模型を作ったりした。
• はじめは知識獲得が目的。徐々に精度をあげていく。

  

• 製品開発
• 構想設計をやらないで詳細設計をやると→手戻り発生
• 知識ギャップを埋めるため、＜仮説　試作　検証＞サイクルを繰り返す

 ⇒確かに、設計中、開発中に得た知識はその人の頭の中にしか存在しなかったり、その人しか知らなかったりというのはありますよね。また、この貴重な経験・知識を、いつでも、その開発メンバーなら誰でもすぐにアクセスできる場所においておく必要がありますよね…。

☆「TOCを活用したヒット商品開発プロセス」 西原さん☆

•  ムラをなくす
• 全体的
• 過剰生産防ぐ
• 継続的に
• 市場→社内→プロジェクトに広がった
• 方法論　DBR　CCPM

ザ・ゴール ― 企業の究極の目的とは何か

ゴールド・ラットさんはこの本を書かれた方？

•  買い手の立場に立って問題点を説明
• 売り方を開発する　A3で立場が違う人にも伝わるよう異なる観点でまとめて提出

•  売り方の仮説と検証を繰り返す→ターゲットを絞っていったり…

⇒今まで自分は、開発の中のことしか考えていなかったんですが、ビジネス面でも同様に、仮説、検証を繰り返すことが必要なのだと気づかされました…

後半につづく！