south37の日記

ちょろっとメモりたい事とかを書く用。もうちょっとちゃんとしたブログもあります。http://south37.hatenablog.com/

リーン・スタートアップ読み終わった。

エリック・リースの青い本。今更ながら読んだ。ざっくりとまとめてみる。

リーン・スタートアップの5原則

  1. アントレプレナーはあらゆるところにいる
  2. 起業とはマネジメント
  3. 検証による学び
  4. 構築-計測-学習のフィードバックループ
  5. 革新会計(Innovation accounting)

3 ~ 5が特徴的。

スタートアップの定義

「スタートアップとは、とてつもなく不確実な状態で新しい製品やサービスを創り出さなければならない人的組織である」

大企業の中にいようと、上記の定義に当てはまれば「スタートアップ」。よって、アントレプレナーはあらゆる場所にいる。

構築-計測-学習のフィードバックループを回す

戦略的仮説の設定

  • 成長仮説と価値仮説
  • 特に重要な仮説(一番リスクの大きな仮説)は、 挑戦の要

構築-計測-学習

  • MVP(minimum viable product)の構築
  • 革新会計による計測
  • 学習の後、ピボット(pivot)か否かを決断

仮説を検証する為に何を学習すれば良いか、その為にはどんなMVPを作ればいいかを考える。

革新会計について、より詳しく

1. 行動に繋がる評価基準(actionable metrics)を決める

成長モデルに応じて、評価基準は変わる。

ex. IMVUにおける「ファンネル型評価尺度」

  1. 顧客の登録率
  2. アプリケーションのダウンロード率
  3. 試用率
  4. リピート率
  5. 販売率

これらの値の変化を、行動に繋がる評価基準(viable statics)として使用。総ユーザ数、売り上げ等は虚栄の評価基準であり、危険。行動し易さ、分かり易さ、チェックし易さが重要。

2. 革新会計における3段階の「学びの中間目標(learning milestone)」
  1. 会社の現状を示す「データ」を、MVPから取得。これがベースライン。
  2. ベースラインの状態から理想状態へエンジンのチューニング(製品の最適化)。評価は全て 行動に繋がる評価基準 を基に行う。
  3. ピボットかどうかの見極め(エンジンチューニングの生産性を高める為に、ピボット)

さらっと書いたが、エンジンのチューニングも 検証による学び をベースにフィードバックループを回して行う。機能レベルでの改善等は全てエンジンのチューニングに含まれる。エンジニアやデザイナーの普段の仕事は、ひたすらエンジンをチューニングする事。

ループをスピードアップする為の工夫

  • 小さなバッチサイズ。小さければ小さい程効率化が進む。
  • 順応性の高い組織(状況の変化に合わせて、プロセスとパフォーマンスを自動的に調節する組織)を作る。

使用が薦められたリーン生産方式のパーツ

  • 現地・現物
    • 検証すべき仮説を選ぶのに役立つ。
  • かんばん
    • ユーザーストーリー(使い手目線でみた機能)は、検証による学びが得られてはじめて完結。
  • アンドン
    • 部品の欠陥などその場で解決出来ない問題に気づいたら、誰でも生産ラインを止めていい。
    • 局所最適化を避け、全体最適化を目指す。
  • ジャストインタイムスケーラビリティ
    • 製造プロセスを顧客の需要レベルに合わせる為に「プル方式」を採用。リーン・スタートアップ的には、「顧客に関する仮説」をプル信号とする。
  • 5回のなぜ
    • システムを改善する仕組み。順応性の高い組織を作れる。5回のだれは危険。

書籍「リーンスタートアップ」の感想

豊富な具体例を用いて「リーンスタートアップ」という手法について解説しており、読んでて面白くかつ分かりやすかった。ただ、具体例が途中途中で挟まり過ぎていていかんせん冗長な印象も受けた。各章の始まりの部分にエッセンスがまとめられているみたいなので、その辺を特に覚えておくと良さそう。

リーン・スタートアップ

リーン・スタートアップ

情熱プログラマーを読んだ

全体的に、プログラマーとしての生き方をモチベートする感じの内容。日々研鑽に努めるように諭したり、名前を売る事の重要性を説いたり。まあ、その通りだよねと思った。

一つ印象に残ったのは、「52. Better Than Yesterday」で出てきた一段落。

毎日の小さな改善は、目に見える結果に直接結び付かない事が多い。(中略)大きな目標を前にするとやる気が失せるのはそのせいだ。だからこそ、大きくて困難な目標を目指す時には、毎日その目標に近づけたかは気にせず、その目標に向かって昨日より 努力 できたかを考える事が大切だ。

ここで言う「努力」は、ただ何も考えずに長く働くとかでは無くて、目標に近付く為に自分が今出来る事をしっかりと見極めて、それを実践する事を意味している。小さなステップであっても、そのステップを確実に踏めているならば、その事自体に少しは満足感を抱いても良い。そう言っているのだと思う。

もともと、自分は「努力を評価して欲しい」みたいな考え方はあまり好きではなくて、「労働時間」じゃなく「生み出した価値」で評価されるべきと思っている。ただ、大きな目標を前にすると毎日進められる一歩が無視出来る程小さいのは事実で、その事に落ち込みそうにもなる。

しかし、この一段落のメッセージは、その小さな一歩一歩にも価値を見いだして良いといっている。その事で、何と言うか安心感みたいなものを感じた。

まとめ

情熱プログラマー、ポエミーな感じになれるのでオススメ。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

すごいHaskellたのしく学ぼう!を読んだ

読み終えての感想

まず間違い無く言えるのは、Haskellを学ぶ上では本当に良い本だと言う事。

(実は、Haskell本としてはプログラミングHaskellって本も以前読んでいた。が、型クラスとか型コンストラクタとかデータコンストラクタとかそういった重要な概念の説明が何も無く、読み終えても何も残らなかった。)

そういった意味では、「すごいH本」はHaskellの様々な要素を読み易い形で説明してくれていて、とても素晴らしかった。Haskellを実用する為に必要な情報が手に入るというか。

感心した点

HakellにはFunctor(関手)Monadのような、圏論で使われてる概念を型クラスとして取り込んでる部分があるんだけど、「すごいH本」は圏論での意味合でいは無く、「Haskellにおける役割」みたいなものをとても丁寧に分かり易く説明していた。

例えば、関手は圏論的には 圏を別の圏に写すもの で、実際Functor型クラスもそういう風に捉える事が出来る。けれども、「すごいH本」としては Functorは関数で写せる文脈付きの値 という立ち位置で捉えるようにしていた。

また、モナド圏論的には unitjoinが定義された自己関手 な訳だけど、「すごいH本」では Monadは普通の関数に食わせる事が出来る文脈付きの値 として捉えられていた(普通の関数と書いたけど、モナドを返すのが条件)。

こういった様々な捉え方はもちろん全て正しい訳だけど、HaskellにおいてFunctorやMonadの機能がどういう風に使われているかを考えた時に、 文脈付きの値 という捉え方はとても自然で、かつ有用だと思った。

「文脈付きの値」という言葉について

一応意味合いを説明しておく。例えばMaybe失敗の可能性のある値 として捉えたり、リスト非確定計算に用いられる値 として捉えたりするのが、「文脈付きの値」の意味するところ。FunctorMonadも基本的に型引数を一つとる「型コンストラクタ」として定義されていて、その引数の型の値に文脈を持たせる役割を果たしている。

Functorfmapを持っていて、普通の関数に文脈付きの値を食わせて文脈付きの値を返す事が出来る。次の例では、1, 2, 3の3つの可能性を持つ文脈付きの値に対して、普通の関数¥x -> x * 2を適用した結果、2, 4, 6の3つの可能性を持つ文脈付きの値が返ってきた事を表している。

ghci> fmap (¥x -> x * 2) [1, 2, 3]
[2, 4, 6]

また、Monadは文脈付きの値を返す関数に、文脈付きの値を食わす事が出来る。

ghci> let largerThan9 x = if x > 9 then Just x else Nothing
ghci> Just 3 >>= largerThan9
Nothing
ghci> Just 11 >>= largerThan9
Just 11

>>=を使って(メソッドチェーンのように)返り値を次々と関数に適用していったり、一連の処理をdo記法を使ってまとめたり出来る。

失敗の可能性、ログ、状態などを値に付属させて綺麗に表現出来る為、「文脈」という概念は優れていると思う。特に、Maybeを最初に知った時は感動した。nullでも0でもfalseでも無く、明確に「失敗」を表現する「値」であるNothingがあるというのは、素晴らしいのでは。

とりあえずまとめ

面白くて読み易いので、「すごいH本」を読んてみよう!

すごいHaskellたのしく学ぼう!

すごいHaskellたのしく学ぼう!

リーン・スタートアップ読み始めました。

エリック・リースによる有名な青い本です。

まだ本当に序盤しか読んで無いんですが、いくつか大事な事が述べられていて、その中でも

「検証による学び」を単位として進歩を計測する

という一文が印象的でした。

この一文は、リーン・スタートアップという手法における「進歩」を明確に定義しています。要は、どれだけ素早くたくさんの機能を作ったとしても、「検証」を経て「本当にユーザーにとって価値ある事」だと確かめられない限り、それはサービスの進歩とは呼べないという事です。

必然、「構築」->「計測」->「学習」のサイクルを素早く回す事がサービスを進歩させる為に必須の要素となります。「サイクルを回すのが大事」とただ述べるのでは無く、「進歩」の定義を明確にしてやる事で「サイクルを素早く回す事の重要性」を意識せざるを得なくさせているのが、とても上手いと感じました。

スタートアップは「求められていない物を作ってしまう」という失敗を犯し易く、そんな状況を打破する為に考案されたのがリーン・スタートアップです。その根本に「検証による学び」を据えているのは、とてもセンスが良いのでは無いでしょうか。

最後に、「リーン・スタートアップのルーツ」というセクションの中の一文を載せておきます。

リーン・スタートアップとは、サイクルタイムの短縮と顧客に対する洞察、大いなるビジョン、大望とさまざまなポイントに等しく気を配りながら、「検証による学び」を通して画期的な新製品を開発する方法である。

リーン・スタートアップ

リーン・スタートアップ

ホットエントリ入り?

http://b.hatena.ne.jp/entry/south37.hatenablog.com/entry/2014/02/17/JavaScript%E3%81%AE%E9%96%A2%E6%95%B0%E5%AE%9A%E7%BE%A9

もう一つのブログで結構前に書いた記事が、何故か今さらになってバズった。 普段誰にも見られてなくて寂しいくらいだったのが、200はてぶとかいってる。ビビる。

正直、めちゃくちゃ嬉しいです。

rubyのEnumertor

https://www.ruby-forum.com/topic/934794 にあるみたいに、Enumeratorにwith_indexとかつけてさらにEnumeratorを返すようなメソッドを呼ぶとき、|(e, i), j|みたいにカッコで囲んで前の要素を表現出来る。

例えば、

1.upto(10).each.with_index.with_index do |(a, i), j|
  p "a: #{a}, i: #{i}, j:#{j}"
end
=>
a: 1, i: 0, j:0
a: 2, i: 1, j:1
a: 3, i: 2, j:2
a: 4, i: 3, j:3
a: 5, i: 4, j:4
a: 6, i: 5, j:5
a: 7, i: 6, j:6
a: 8, i: 7, j:7
a: 9, i: 8, j:8
a: 10, i: 9, j:9

みたいな感じ。with_indexしてからinjectとか出来てけっこう便利。

matched_tags.each_with_index.inject(''){|str, (tag, i)| str + "| #{tag[:name]} | #{tag[:articles_num]} | #{i+1} |\n"}

で、markdownのテーブルとかさくっと作れる。

人気のプログラミング言語

って何なんだろうなーってちょっと気になったので、ちょろっと調べてみました。 方法としては、はてなブックマークで「プログラミング言語」もしくは「プログラミング」でキーワード検索とタグ検索を行ってみて、ひっかかった記事のタグからどの言語のタグが良く出てくるかを調べてみました。

続きを読む