NISHIO Hirokazu[Translate]
Hatena2012-11-14
hatena
<body> *1352902687*リーンスタートアップ:レバレッジメモ 「<a href="http://www.amazon.co.jp/gp/product/4822248976/ref=as_li_ss_tl?ie=UTF8&camp=247&creative=7399&creativeASIN=4822248976&linkCode=as2&tag=nishiohirokaz-22">リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす</a>」のレバレッジメモ ** Q: 「需要がある」と「技術的に実現可能」のどちらの仮説を検証すべきか? 「この製品を作れるか」ではなく「この製品を作るべきか」「この製品を中心に持続可能な事業が構築できるか」を問うべき(P79) コダックは次の4つの問いに答えることをチームに求めていると書いてある(P91) - 1:我々が解決しようとしている問題に消費者は気づいているか - 2:解決策があれば消費者はそれを買うか? - 3:我々から買うか? - 4:その解決策を我々は用意できるか? そして、1~3を飛ばして4に進み、顧客が問題を抱えているかどうかを確認する前に解決策を作ってしまう失敗が多い、とも書いてある。 消費者が問題に気づいていない場合→「ファイルの同期はほとんどの人が存在に気づいていない問題だとドロップボックスでは考えていた」から製品を作る前にプロモーション動画を作って「ベータ版の予約」という行動に出る人がたくさんいるかどうか(問題に気づかせれば欲しがるか)を検証した(P133) ** Q: どういう指標を立てるべきか 3つの「しやすさ」が重要(P.192) - 行動しやすさ。レポートが行動につながるためには因果関係がはっきりしていなければならない。それ以外は虚栄の指標。「総アクセス数」が増えたり減ったりしても何を行動したらいいかわからない。 - わかりやすさ。読み手にわかるデータでなければ意味がない。「人」を単位にするのがわかりやすくなるのでオススメ。 - チェック(検証)しやすさ。レポートの内容が正しいかどうかを別の手段で(直接顧客に聞くなど)検証できるか? 3番目はけっこう難しいな。 ** Q: 最初から定量的に計測するのは難しい、どうすればいいのか? 立ち上げ期のスタートアップには適切なモデルを導けるだけのデータがない。だから初期の戦略はどうしてもカンだよりになりがちだ(P.119) とのことなので最初はカンでいいようだ。重要なのは「データに基づいて判断すること」が重要だと考えて、それが出来る方向へ駒を進めること。 ** その他 検証のサイクルを短くすること アーリーアダプターは欠点をあまり気にしない。だから品質の悪いプロトタイプを早く出すアプローチが成功しうる。ビジネスが成長してメインストリームを相手にし始める時点で必ずピボットが必要になる。 検証すべき仮説。ユーザに価値を与えることができるか。このビジネスで継続的に持続可能な成長をすることができるか。 <iframe src="http://rcm-jp.amazon.co.jp/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=AAFFAA&fc1=000000&lc1=0000FF&t=nishiohirokaz-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=4822248976" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe> *1352904902*5分でポモドーロが終わってしまったらどうするか PySpaに行く車の中でid:Yoshioriと話していた内容の続きをTwitterに書いたので、流れ去らないようにブログに転載 <hr> 1ポモドーロ未満で作業が終わって余ってしまった時に何をするかって話、自分の過去ブログを見ても何度も質問されてた。原著では「やったことの見直し」「学んだことの繰り返し」「仕事の改善方法を考える」「結論のメモをする」などが挙げられている。 多分著者は「25分掛かると思ったタスクが5分で終わる」という事態は想定していないのでは。25分のタスクが22分で終わったとかなら、残りの時間をそういう方法で使うのはまだイメージできるし、勉強のようなインプットのタスクなら残り時間に繰り返すこともできる。 だけどもデバッグみたいな「見積りが困難なタスク」で5分で終わって20分余ってしまった時に、その場で20分使うような新しいタスクを考えて残り時間を「潰す」のは正しくないように思う。それでは他のポモドーロと比較できる「25分間の集中」にならない。 というわけで、何をして残り時間を過ごしたらいいかわからないくらいたくさん時間が余ってしまったら、それは潔くポモドーロをキャンセルして新しいポモドーロを始めるべきなんじゃないかと思っている。 >> yoshiori 「なるほど、でも、破棄したポモドーロの次のポモドーロの時に「さっきちょっと作業したんだしなんか損してる気がするなぁ」と考えてしまう卑しい心をどうにかしたい」 << 「うぁーい、25分掛かると思ってた作業を5分で終わらせたぞ、俺天才!」とか唱えればいいのではないだろうか 僕らは「楽しく仕事をこなす方法」を追い求めているのだから、25分集中したけどタスクが終わらなかったときは「やったぜ25分集中したぜ」タスクが終わったけど25分じゃなかった時は「やったぜタスクを終わらせたぜ」と常に楽しい方を選択すべきなのではないか。 「損した気持ち」とかネガティブな感情が湧いてくるシステムでは継続していけないだろうなぁと思っている。 >> yoshiori ああ、なるほど、「楽しく仕事がしたい」って言う大前提を少し忘れてた!もちろん「集中できるから」って理由は有るけど、大前提は「楽しく」だよね! ありがとう!なんか少し楽になった気がする なんかカッチリ考え過ぎて 25 分に収まらないとか、小さすぎるとかのタスクが嫌なものに見えちゃうのは気をつけないとなぁと、思う << そういうタスクは、従来型のTODOリストで管理してる場合は「サクサク倒せて心地よいタスク」のはずなんだよね。ポモドーロは従来型TODOで達成感を感じにくいでかいタスクを25分に刻むことで達成感を早く得られるようにしたのだが、逆に25分より短いタスクの扱いでデメリットがある。 「タスクの完了」っていう規模の軸と「25分集中した」という時間の軸の両方で達成感を得られるチャンスがある、ということが重要な気がしてきた。 >> yoshiori あー、なるほど。25分集中した事と、タスクを終わらしたって言う事をなんて言うか二個のご褒美だと思えば良いんだな。分かりやすくチョコ食べるようにしようかな。そうすると5分とかで終わった時はチョコ一個食べて次に進めるし25分集中してタスクも終わったら二個食べて休憩とか << 「達成感=精神的なご褒美」だから、わかりやすく物質的なご褒美にするのもありだね。でも僕がチョコ制度をやると「太る」と「虫歯になる」の2つの罰のチャンスが待っているw >> yoshiori そうすると「痩せる」と「虫歯を治す」って言う結構デカイタスクが追加されるねw << <iframe src="http://rcm-jp.amazon.co.jp/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=AAFFAA&fc1=000000&lc1=0000FF&t=nishiohirokaz-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=4048689525" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe> </body>

"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]