『実践リーンスタートアップセッション at クックパッド』ノート

2012/12/18に開催された『実践リーンスタートアップセッション at クックパッド』のノートです。開始時刻に間に合わなかったため、前半15分ありません。ただ、ノートを見る文には本編自体は問題なく参加できたみたいです。



～10 Steps to Product/Market Fit -製品/市場フィットを達成する10のステップ～



■Problem/Solution Fit

◆1. Document your Plan A

◇第一ステップ = Plan Aを文章化すること
・一番最初にあるアイデアをドキュメントにする
・特に重要なポイント
　→企業家はもともとの素性としてものごとを整理だって考えるのが得意な人が多い
　→そういう意味でもアイデアをきちんと文書化するのは有効

◇こういったものの文書化はスタートアップ以外の企業でもやっている
・そういう企業はビジネスプランや事業計画を書く
　→形こそ違えどスタートアップと同じようなものを文書化している
・「今日の会場でビジネスプランや事業計画を書いたことがある人は？」
　→「それが本当に楽しくてしょうがなかった人は？」
　→→（ほとんどいない）
・ビジネスプランや事業計画というのは、作りこむのがPainfulだということ
　→しかも作れと命令した人に限って最後まで読まない

◇ビジネスプランや事業計画のよくないところ
・分からないことを想定して作りこんでいかないといけない
　→空想の産物になりがち
　→→リアリティを反映しているというよりは、そうなる傾向がある

◇Lean Canvas
・「事業計画はなくて…　でも事業計画で求められているコアの部分だけを1ページに抽出してまとめ込んでいこう」
　→「それをビジネスモデルの形にしよう」
　→→そのビジネスモデリングのやり方がLean Canvas
・Lean Canvasが要素としているもの
　→ビジネスを実際にやっている人が見ればすぐ分かるようなもの
・強み
　→コアになるような前提条件などを非常にスピーディにまとめることができる
　→1ページに収まるものなのですぐにできる
・Lean Canvasは自分が作ったもの
　→だが、全くオリジナルなものではない
・ビジネスモデルキャンバスを基にした
　→それを調整してリーンキャンバスにした

◇なぜBusinss Model Canvasを作り変えたのか
・「どうして変えた変えた？」「根拠を教えてくれ」
　→よく質問を受ける内容の1つとして聞かれる
・アクショナブル（アクションをとり易いよう）に変えている
　→これが要点
・もっと知りたい人は…
　→私のブログを見れば1000ページくらいかけて説明している

◇ここまでが第1ステージ
・ビジョンを捉えるイメージで


◆2. ?

◇Product-Vision-Strategy
・アントレプレナーはアイデアが浮かぶとどうなるか
　→すごくクリアなシグナルとして何かを感じる
　→3つのレイヤに分けてそのアイデアを扱う
　→→これは知らずにをやっていると思う
・3つのレイヤ
　→Product
　→Vision
　→Strategy
　→→これがピラミッドのような構造になっている

  /\　　　← Product
 /__\　　← Vision
/____\　← Strategy

◇アントレプレナーの人にありがちな失敗
・このピラミッドを出来るだけ早く上にたどり着きたい
　→プロダクトを急いでしまう傾向がある
　→→ビジョンやストラテジーを考えることに、充分に時間を取っていないということ
・ビジョンやストラテジーは重要
　→この2つはピラミッドの基礎をなす部分
・ビジョンはだいたい誰でも考えていると思う
　→でも、ビジョンだけでは充分ではない

◇facebookの例
・結果的にソーシャルネットワークで最大のプレイヤーになった
　→facebookと同じようなビジョンを持った人達は他にもいた
・ではfacebookは何が違ったのか
　→Howの部分が違う
　→→「どういう風にビジョンを実現していったのか」が違う



■Product/Market Fit

◆3. Hone in process on early adopters first

◇facebookでさえも最初はアーリーアダプター中心にやっていた
・「いつかはfacebookのようなメインストリームの会社やプロダクトを作りたい」
　→スタートアップをやっている人はそう思う
　→だがfacebookも最初からそうだったわけではない
・facebookはまずハーバードの大学生をアーリーアダプターとした
　→ここでビジネスモデルを定義していった
　→→そういう過程をふんだ
・アーリーアダプターが誰かによって、ビジネスモデルは大きく展開する
　→これはリーンキャンバスを見てもわかる
・チャネルもプロダクトもソリューションもレベニューストリームも大きく変わる
　→アーリーアダプターがどういう人達なのか見極めることが大事

◇Geoffrey Moore "Crossing Chasm"
・アーリーアダプターまでと、そこからの拡大
　→この間には大きなギャップがある

◇一番初めはアーリーアダプターにきちんとフォーカスする
・「メインストリームに出ていきたい」「大きくて皆に使ってもらえるようなプロダクトを作りたい」
　→最初にに始めたときはそう思いがち
　→→これはよくありがちな大きなミステイク
　→→→そうでない
・「誰にも受けるようなものをメインストリームにもっていく」
　→そう思って作りこんでしまう
　→→結局は誰も使ってくれないような楽しめないものになってしまう
　→→こういう傾向も大きくありがち

◇キャズムを渡ることは1つの大きなポイント
・最初はきちんとアーリーアダプターから腰を据えてやっていくこと
　→キャズムを渡る近道はない
・アーリーアダプターからモメンタム（加速度）をつける
　→それからメインストリームに行く
　→→そういうステップをきちんと踏まないといけない

◇MVP(Most Viable  Product)
・「アーリーアダプターがどういう人達なのか」をきちんと分かったらどうするか？
　→そのアーリーアダプターがどういう課題を抱えているのか見極めていく
　→→ここで出てくるのがMVP
・MVPの定義はいろいろある
　→「カスタマに対してバリューを提供できる最小単位のソリューション」
　→→これが自分の定義
・MVPの例 = かなりストリップダウンされた何もついてないver. 1.0のリリース
　→ただし、カスタマーの直面している課題にきちんと何かできているもの
・MVPの例 = 中の人がオペレーションして、カスタマーに体験してもらう（コンシェルジュMVP）
　→作りこむ代わりに、こうやってバリューを確認するというやり方もある

◇「MVPが何か」ということをきちんと見極めてから作りこんでいく
・「カスタマーが本当に求めているもの・バリューとして感じられるものがその中にきちんと盛り込めているか」
　→MVPが何か分かったら作りこみをやる

◇一番初めにMVP・プロダクトをローンチした段階ではいろいろな問題が起こる
・それを使ってできるだけデータを集めたい
　→よくあるひとつの傾向
・でもやろうと思えば情報はいくらでも集められる
　→現代ではそのくらいの情報が存在する
・その情報の海に溺れてしまうこともある
　→マトリックスを作ってきちんと指標を追いかけていかないといけない
・始めは少ないツールで見るところから始まる
　→でも、そうこうしているうちに情報まみれになってしまう



◆4 Establish a standard measure of progress

◇進捗を図っていくスタンダードなものをきちんと作っていく
・情報まみれになってしまうことへの1つのソリューション
・既存の会社は財務指標できちんと測って業績を評価している
　→では、スタートアップのきちんとした指標は何か？

◇Dave Mcclure's "Pirate Metrics"
・ざっくりいうとカスタマーライフサイクルがどうなっているかを表す指標
　1. Acquitision : 新規の顧客を獲得
　2. Activation : どう一番最初のエクスペリエンスをしてもらうか
　3. Retension : 最初のエクスペリエンスすごくよかったら使い続けてくれる。カムバックしてくれる
　4. Revenue : 使ってもらうことで売り上げが立っている
　5. Referral : 使うことで満足しているカスタマーが他の人に宣伝してくれる

◇基本はこの5つ
・業績の指標として見るものはいろいろある
　→自分の会社ではこれに絞っている
　→→それぞれの後ろに詳細なのはある
　・この5つが基本でメインのルール

◇まずカスタマーバリューにきちんとフォーカスすること
・最初にプロダクトをローンチしたときはこれをやる
　→このタイミングではこれが重要
・成長がどうだとか売り上げやレベニューにフォーカスしてはいけない



◆5. Deliver value before growth

◇Pirate Metricsでバリューはどこに位置づけられているのか
・Acuisition
　→ここではない
・Activation
　→まずはよい良いカスタマーエクスペリエンスを提供できているか
　→そうじゃないと戻ってまた使ってもらうことはありえない
・Retension
　→2つめに重要なのがバリューの観点
　→使い続けてくれているか、カムバックしてくれているかも指標としてみる
・Revenue
　→課金モデル使っている場合は、ActivarionできていてRetntionしていれば売り上げや収益はついてくる
　→そういう意味では相対的に重要ではないかもしれない
・Referral
　→ここではない



◆6. The terrain before Product/Market fit is riddled with qualitative learning

◇ローンチしたばかり = 使ってくれるユーザは限定的
・ユーザの数が少ない
　→定量的な評価よりも定性的な評価の方がよっぽど重要
・ポイント = "「成長を求めてバリューを無視」はしない"
　→あえて限定的な数のカスタマーにフォーカスして情報を得たほうがよい
　→大規模な集団を使ってそこからインタビューしたり情報を得るよりもよい

◇まだまだ最初の段階なので分析ツールは使わない
・シンプルなもので学ぶようにしていく
・Pirate Metricsの5つのステージを書いたカンバンボード
　→Acquitision □□□□□□□
　→Activation □□□□□□□□□□□□□
　→Retension □□□□
　→Revenue □□
　→Referral □□□□□
　→→それぞれのカードがカスタマーに関する情報が書いてある
・指標を管理するにあたってするべきこと
　→Referralへカスタマーを持っていくためにはどうすればいいか
　→→できるだけカスタマーに満足してもらったうえで、Referralにいくように

◇実際に使っているユーザが限定的で少ないことはありがたいこと
・かなりパーソナルなところまで確認・ラーニングができる
　→10人～20人くらいしか使っていない
　→→学習のスピードも加速する
・一番最初なのでバグもあるかもしれない
　→人数が少ないのは非常によい

◇Product/Market fit拡大のステージ
・Pirate Metricsの5つのステージを書いたカンバンボードで、7～8割がReferralにできたら移行する



■Scale

◆7. Identify your engine of growth

◇ここまで来たら「どう成長させるか」「どこが成長のエンジンか」を模索する
・ここまで来ているということは、プランがマーク？し始めている段階


◇成長のエンジンとは？
・Acquisition - Paid
　→最初の成長エンジンは支払い
　→→できるだけユーザーベースを広げていくイメージ
　→維持できるようにするためには獲得コストがRevenueを下回っていないといけない
　→→そうじゃないと長期的には持続できない
・Retension - Sticky
　→できるだけ長い間使ってもらう
　→→例. 携帯電話の契約や雑誌の定期購入
・Referral - Viral
　→facebookやtwitterがこれをすごく活用している
　→→既存ユーザがReferralすることで、新しいカスタマーににうまく入り込んでもらっている

◇最初はどれか1つの成長エンジンにフォーカスをあてる
　→そうやって進めることが重要
　→→プロダクトによっては1つ以上の成長エンジンが関係していることも
・1つの判断の仕方 = 「プロダクトがどれだけ効果を出せるか？」
　→例えばfacebook
　→→3つのエンジンへの可能性があった
　→→→でもバイラルにフォーカスを当てた
　→→→→それは、そこが一番効果が大きいという判断をしたから（なのではないか）



◆8. Measure everything as a cohort

◇ユーザが増えた状態になるとパフォーマンスを計測するのが楽になるか？
・逆に難しくなってくる
　→ここまでいくとプロダクトのユーザベースもかなり増えている

◇何故ユーザベースが増えると難しいか？
・1つはプロダクトは常に変化しているものだから
　→新しい機能が加わってくる
　→マーケティングキャンペーンによって何か変わることもある
　→→川の流れのような（同じところに足を突っ込むことがないような）状況
・2つ目の理由はそれぞれサイクルの長さが違うから
　→例えばレベニューのサイクルは他より長い
　→→レベニューは後半にならないと入ってこない
・サイクルの長さが違うと原因と結果の関連付けが難しい
　→「何かが起こっても結果が出てくるのは数ヵ月後」というのが普通にありえる
　→→「うまくいってる」と思ったとき時点ではものすごく間違った方向に入っていたりすることもある

◇そういう風に悩んでいる人には？
・コホートの考え方が有効な手段
　→ある一定の特性ごとにユーザをまとめる(Align)
　→→こうすることで、さっき言ったような"ずれ"をなくす
　→→→これが基本的な考え方
・コホートはマトリックスによる管理方法の上級版
　→原因と結果をより関連付ける手法

◇ここまでくれば何が間違っていたか問題だったかというのは指標で分かる
・ただそれで解決したかというと…
　→そうではない
　→原因(Why)には、これだけでは充分ではない


◆9. Build a continuous feedback loop with customers for rapid hypothesis generation

◇ここで重要なこと
・いかにカスタマーからフィードバックをもらい続けてフィードバックループを実践できるか

◇"指標"ということで数値で表してしまいがち
・でも指標を作っているのは個々の人なのでこういうことが重要になる

◇「マトリックスと指標の裏に誰がいるのかははっきり分かるようにする」
・自分達の場合は仮説を立ててやり始めた
　→そうやって運用していった
　→→次に進んでくれるハッピーなユーザとそうでないユーザの両方を見た

◇どんな人達か限定できた段階で問い合わせをする
・何が問題なのかをメールで聞く
　→これはけっこう辛いこと
　→→1日100ユーザにメールを送るとかけっこう大変
・で、メールを自動送信するシステムを作った
　→問い合わせのためのメールを自動で作ってくれる
　→→1日に30, 40通くらいのメールが返ってくる

◇メールの回答はかなり活用している
・これのおかげでかなり理解が深まる
・次はどんなExperimentで回してみようかという判断もできる
・自動でメールを送るというのは全プロダクトでやっている



◆10. Breakthrough insights are usually hidden within failed experiments

◇失敗した場合に、いかにExperimentのプロセスを使えるか
・Experiment = 実験
　→新しい機能を追加するときは実験（評価・テスト）する

◇ピボットは（いろいろな意味で）間違った意味でも使い込まれている
・何かが1回でも失敗すると、それを理由になんでもいいからピボットしてしまう
　→よくアントレプレナーがやりがち
・本当の意味でのピボットとは単になんでも変えることではない
　→学習に基づいているのかが一番重要
・適当にピボットする = いろいろ試してみて何がうまくいくかを適当にやっているだけ

◇失敗それ自体はいいことだし想定するべきもの
・ホッケースティック曲線
　→幾つもの成功している会社がこういう曲線を描いて成長していた
　→→成功にたどり着くまでにはかなりの期間を要するということ
・伸びていない期間が長いのは？
　→ある程度やらなければいけないことが、前段階では必要だということ
　→→創立者が仕事をしていなかったとか、そのときたまたま間抜けだったとか、そういうわけではない

◇トヨタ生産方式でも同じ事を言っている
・課題・問題は何かというのを製造工程ですごく追いかけている
・「課題・問題がない = それがわかっていないということ」
　→この状態なら、そのこと自体が問題だと言っているくらいに追いかけている

◇実験に失敗はない
・単に想定外の結果が起きただけ
　→そのとおりだと思う

◇「失敗したからピボットする = 失敗から逃げる」ではいけない
・失敗があったのであればピボットする前にまずきちんと理解する
　→何故だったのかという原因を探ってからでないと、ピボットしてはいけない
・そうなると作業量が手間だということにはなりがち
　→でもExperimentをやるなら最終的には学習がなければいけない
　→→時にはカスタマーに戻ってもっと質問を投げないといけないかもしれない
・いずれにしても根本原因について見極めないといけない

◇失敗の中に通常は磨けば輝く宝石が眠っているということ
・それを見つけて磨くのが皆さんの仕事だと思う



■質疑応答

Q.
Pirate Metricsの5つのステージを書いたカンバンボードはどういう使い方になっているのか？

A.
カード = カスタマー。
カードの端には担当者の写真がついている。
一番注目して欲しいのはカスタマーがどれくらい各ステージにいるか。
ユーザが次のステップに進んだときカードを手で動かす。
10人とか20人程度なので、これでできる。
ただし、これでビジネスモデルを作れるかというと…　20人程度のユーザでは到底想定できない。
一方で「20人を満足させられないなら、到底満足できるビジネスモデルは作れない」という考え方も持っている。



Q.
アクティベーションやリテンションまで行ってからユーザ獲得やバイラルという話があったと思う。
ただ、新サービスはリリース直後がニュースとか掲載されやすいし、そういうときにツイートやPRもすると思う。
それに、ツール自体にバイラルも組み込んであることも多いと思う。
今の話を踏まえれば、最初の方はそういうことや機能の搭載はしない方がいいということか？

A.
そういうことで間違いない。
PRをあまりにも早い時期にやってしまうのはいけない。
印象付けるのに一番初めが重要というのもある（早い時期にPRするとProduct/Market fitしている途中のものが印象付けられてしまうということ）。
よく言っているのはできるだけ規模を小さくしてバリューを試すことをした方がいい。
何千人とか言う規模にする必要はないと思う
最初は10人とか20人くらいの小規模なもので始めて、そこにバリューがあるかどうかを確認する。
本当にPRをするのは、山を登ってもっと上のほうに行ってからでいい。それからで充分。
その時点でPRしてAcquisitionすればいいと思う。



Q.
10～20人くらいで始めて、その後PRする場合を考える。
ADを出すということではお金をかければいい。
リリースを打つとしたら「30万ユーザが使っている」とかあれば出しやすい。
逆に、そうじゃないとなかなか出しづらい。

この時、アプリの中から静かにバイラルを待つのか、それともお金を使って広告を打ったほうがいいのか？

A.
10人20人の規模のときにはメディアやプレスとは全くトークしない。
トークするのはカスタマーだけ。

facebookがローンチしたときも、一番初めから拡大を狙っていたわけではなかった
大学の寮の中でユーザを広げて、そこで全体に広がってから他の大学に広げた。
ただ、それもハーバード全体に広がったからといってすぐに広げたわけではない。
マーク・ザッカーバーグも、さっき言ったプロセスと全く同じことをやった。
あまりにも早い段階で成長にばかり意識を使うのはやめるべき。



Q.
日本の企業やアントレプレナーは製品を作ったら「価値がある」「みんな使ってもらえる」と思う
でも多くの製品は、誰も欲しくない使いたくないようなもの。
そういうものを既に作ってしまっている。

リーンスタートアップでは本当に価値があるものだけを市場に出そうとする考え方。
でも日本は作ってしまっている。そこにずれがあるように思う。

A.
それは日本だけではなくて、伝統的ないわゆるリリースとかローンチをやっているところはそうなのだと思う。
確認しないで作りこんでしまい、販売された後でないとチェックをしない。
これだと、販売するまでは学びが全くできていないということなので、失敗の率がすごく高くなるという問題がある。



Q.
リーンキャンバスを書くときに、どの時点の収益なコストを想定して書くのか？

A.
リーンキャンバスはコンスタントに変わっていくオーガニックなドキュメント。

一番初めにキャンバスを作るときのコストとレベニューは、どの段階というより「どこまで目指せるか」「ビジネスがどれだけ大きくなるか」というビジョンという意味で書くもの。
実現可能(Make sense)なものを書きこむこと。

作ったら各ステージごとにアップデートしていく。
例えばProblem/Solution fitのときには、それを実現するためにはどれくらいのコストが必要かということ。
「それを達成するには」というところで「どれだけの資金が必要か」などの観点から変えていく。

で、第一ステージをクリアできたら第二ステージ。
今度はEarly Tractionで、どれだけのコストが必要になるのか。

Lean Canvasは本当に日々明確に変えていくべきもの。
事業計画の場合、5ヵ年計画といって最初に作りこみ、それに後から現実をあわせていくと思う。
Lean Canvasはそうではなくて、それ自体を進化させていくもの。






Ash Maurya様、O'Reilly Japan様、クックパッド様、ありがとうございました。

『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』ノート - 質疑応答 (4 / 4)

2012/12/17に開催された『Running Lean -実践リーンスタートアップ　刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』のノートの質疑応答部分です。



◆質疑応答

Q.
日本でワークショップをやる予定は？
翻訳者である角征典氏のワークショップは素晴らしかったが、マウリャ氏のワークショップはそれと全く同じものか？
そうでない（同じものではない）としたら、日本で誰かにやってもらう予定などはあるか？

A.
角征典氏からは翻訳の過程で的を射た質問をたくさんもらった。
その中で自分として内容を詰めていったり、リファインしたものもあった。
彼はエッセンスを捉えていて、だから（彼のワークショップは）同じものだと認識している。



Q.
「書籍のMVPがワークショップ」というのは、ぱっと見た感じわかりにくいと感じた。MVPを見つけるコツというのは？

A.
MVPでは「課題が何か」をきちんと把握することと、「それに対して正しいプロダクトやソリューションを出せるか」を確認しなければいけない思う。
ここは人によって違うと思うが…　（これを踏まえて）自分の場合は「デモをできるかどうか」。
（MVPの定義に対して）少し厳密に考えるようにしている。

ここでいうデモとは、「デモをやることによって需要の有無を確認ができる」という意味でのデモ。
また、「デモをやることによってバリューを確認できるので、これを元に考えるといい」と提言もしている。

「バリューを提供できているかに注意すればいい」ということは、「どういう形で提供するか」ということをそんなに気にしなくていということ。
コードでなく全てを人がやっても、充分バリューは確認できる。



Q.
Running LeanのメソッドとLean Canvasは既存の企業においても有効？
有効ならどういった点に注意すれば？

A.
いろいろなビジネスの形態があると思うが、Lean Canvasの考え方は全てに有効だと思う。
事業の立ち上げだけではなく、プロダクトを新たに出すところなど。

「カスタマがいるか」「市場はどこにあるか」というのは一番リスクが多いところだと思うので、そこを注意すればいいと思う。
これらはそれを確認するための1つの有効なやり方だと思うし、そこさえ確認できれば後は容易に埋めていくことができる。

あとは、プランを完璧にしようとしすぎないこと。
チーム内で一緒に作るとしても半日。時間をかけるとしても、1日以上はかけないようにする。
以降はとにかく外にでて実際のデータの回収。
そういうことをできるだけすぐやったほうがいい。



Q.
日本という市場と、日本のスタートアップに対して考えていることは？

A.
日本に長くいたわけではないので、日本の市場やスタートアップについて特に意見があるわけではないが…　何人もの日本人のスタートアップの人とは話しをしているので、その辺りの意見や認識は持っている。

この2年、世界中を飛び回って世界中の国の人と話をした。
どこであっても、アントレプレナーとしてのスピリットや気持ちは同じだった。

一方で文化的な違いはある。
失敗に対してどこまで受け入れられる文化的な環境なのか。特にこれは大きいと思う。
周りの人から「そんなことやめとけ」と言われる文化か、そこまではでない文化か、というのはある。

できるだけ早期の段階で「リスクがどこにあるのか」というのを見極め、そのリスクを緩和させていくことが今日の話の1つのポイント。
必然的にリスクが減ってくるので、どの文化でもやりやすい手法であると思う。



Q.
プランをピボットするのかそれともそこで中止するのかの見極めがすごく難しい。
何かそこで大切にしているポイントは？

A.
これはすごく難しい問題だと思う。判断を迷うところだと思う。

自分個人でやるようにしているのは「成功というのはどういうものなのか」きちんと定義すること。
「5年後にどういう成功を収めるべきである」とか「どういう形を持って成功とする」であるとか、そういうものもあっていいけど、それだけではなくもっと短期的に。
「3ヶ月とか6ヶ月先に目指すところ」をきちんと定義できているかということと、それに対して定期的に確認するということ。
月に1回でも2回でもいいので、目指すところに対してどこまでいけているか、というのをきちんと測定する。
そういうことをやっていると「きちんと正しい方向に進んでいる」であるとか「これはどこにも向かっていない」であるとか、確認することができる。
もちろん上手くいっていないからといって経験や学びができないわけではない。
そういうことを繰り返しやっていると「これは方向的に向かっていない」とか、そういうサインが見えてくる。
こういう形で短期的に確認し続けるというのが1つのやり方。

もう1つやってしまいがちな傾向として、1回Experimentしてみて失敗したから「じゃあ変えよう」として失敗するたびに変えるというというのがある。
これではいけない。ランダムに適当にピボットというのはよくない。
失敗したのであれば、失敗の根本原因(Root cause)というのをきちんと見極めたうえで判断しないといけない。
失敗の原因さえ分かっていれば…　分かった上でのピボットであればいい。
ピボットはきちんとした根拠のあるものでなければいけない。



Q.
Experiment(Learn-Build-Measure)という流れの中を一通り回してみて、Learnの箇所は難しいと思った。
「正しい学びなのか間違った学びなのか」という判別が自分ではなかなかできない。
迷ったときに何が正しい学びなのかということを見抜く方法があれば教えて欲しい。

A.
私はLearn-Build-MeasureのサイクルをExperimentと言っている。これは科学的な言葉を"あえて"使用している。
なぜ科学の言葉を使っているかというと、「どんな仮定であっても、間違ったことを証明できる可能性がある仮定でなければいけない」と思うからだ。
「この何かを1ヵ月100ドルで提供する」と言った場合は「それに加入するかどうか」。具体的な数値でないといけない。
「この何かを良いと思ってくれるかどうか」だけだと、その仮定が間違ったという証明すらできない。
そうではなく、Experimentが成功か失敗かはっきりするような形の仮定を組むことが重要。

「100$じゃなくて80$-90$だ」となるかもしれないし、もしくは「5$-10$だ」とか。
後者の場合はビジネスとして成立しないということが分かる。
きちんとした仮定を持ち、それで判断すること。



Q.
今回の事例ではまずブログがあったということで、ある程度リーンスタートアップに興味がある人（カスタマー）がついていたと思う。
そうでない場合に、アーリーアダプターがいなかったのか仮説検証の方法が間違っていたのかを判断する方法は？

A.
「アーリーアダプターがどこにいるかわからないとき、どういう風に見つけていくか」という質問だとしたら…　最初のところではそこが一番リスクが高い。見つけるのも見極めるのも大変。
たしかに今回の事例ではブログというベースがあったが、それ以外のプロダクトの立ち上げでも使ってみたことがある。
そのときの例でいうと、想定するカスタマーセグメントを幾つかの切り口で作り、その人達に使ってもらうことで見極めようとした。
まずは限定した形で始めて、その中で本当に限定した人数からインタビューなどをした。
「まず規模を小さくして、そこからスケールアップして規模の拡大をできるかを考える」という形で始めた。






Ash Maurya様、O'Reilly Japan様、Yahoo! JAPAN様、ありがとうございました。

【建設予定地】『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』ノート - Yahoo! JAPANの事例 (3 / 4)

『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』ノート - ケーススタディ (2 / 4)

2012/12/17に開催された『Running Lean -実践リーンスタートアップ　刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』のノートのケーススタディの部分です。



◆ケーススタディ - アッシュ・マウリャ氏が本を書いたときの話

◇自分が本を書くにあたってどういうプロセスを辿ったか
・本を書きながらメソドロジの評価・テストをした
　→これについて細かく書いたのが『Running Lean』の第2章

◇この話は本を書くもっと前の段階から始まる
・そもそもはブログに書いていた
　→Running Leanの原則の部分についてはずっと書いていた
　→→ただし、原則について知っていたからではなく、自分も分からないから書いているという状態
・「ブログの内容を本にまとめるつもりはないのか」
　→そういった記事を幾つも書いていたら、このようなコメントがきた

◇本を書くような時間はなかった
・当時（今も）事業をやっている
　→正直に言うと興味はなかった
・作家 = 山小屋とか人里離れたところにこもって本を書く人
　→自分はそんな人間になりたくない

◇そうこうしているうちに、11 ～ 12人くらいからリクエストがきた
・この辺りから「これはどういうことができるか」というのを考えるようになった

◇自分に問いかけた質問
・「これは取り組むに値するものなのか？」
・「ソリューションを提供する価値があるだけの課題が存在するのか？」

◇何をしたか
・出版のリクエストした人に直接インタビュー
・ティーザー（触りとなる）ページを作った
　→プロダクトでいうデモのようなもの
・ブックカバーもないしタイトルも今とは違う
　→それは最適化の作業
　→→そういうものが必要になるのは最終的な段階
　→それらは「最初からしっかりしていなくてもいいだろう」という考え方
　→「タイトルやカバーにリスクはそんなにないだろう」

◇「一番リスクが高いところにフォーカスしよう」
・まずは目次を書き出した
　→本のリクエストをした人達と目次の案を共有した
　→→対話(Conversation)を行った
　→→→彼らからいろいろな意見をもらえた

◇「この目次のとおり、こんな形の内容で書いてくれるなら…　お金を出して買ってもいい」
　→対象（リクエストをくれた10人くらい）全員が言ってくれた
　→→ある程度繰り返してここまでもっていけた

◇ここまでが定性的な確認作業(Validation)
・これができても証明できないことがある
　→「スケーラビリティがあるか？」
　→「本を書くだけの労力を使う価値があるのか？」

◇目次ができた段階でティーザーページに変更を加えた
・タイトルを変更
　→ヒアリングしたときにいろいろな人からフィードバックをもらえた
　→→もともとよりいい案がたくさん
　→→→そのうちの1つがタイトルに
・この夏(2009年の夏）に出すということを宣伝
　→この時点では後4～5ヶ月先
　→かなりアグレッシブなスケジュール
・メールアドレスを送ってもらうシステムを組み込んだ
　→送ってもらうことで、どれだけの人が関心を持っているかを図れる

◇実際には夏には出版されなかった
・「ブログにいろいろ書いてあるからできるだろう」と思っていた
　→見積もりが甘かった
　→→結局遅れてしまった

◇変更した後にやったこと
・ブログやtwitterに書いて告知
・Eric riesなどにもコメントをもらった

◇その後…　何もしなかった
・他の仕事をやっていて、この本からはいっさい離れた
・エビデンスは作っていた
　→「関心を持っている人の規模が充分にあるか？」
　→これが確認できるまでは動かなかった

◇夏には1000を超えるメールアドレスが送られてきた
・プロジェクトとして価値がある
　→これだけのメールがくるのは、実際に課題として認識されているから
　→プロジェクト化

◇まずはMVPに手をつけることに
・ブログで情報はかなり書いていた
　→でも本を書くにはもっと膨大な作業が必要だった
　→→とてもすぐ終わるものではない
・MVPの（1つ）の定義
　→「最終製品の一番小さなバージョンをカスタマーに示し、そこから学ぶこと」

◇MVP = ワークショップ
・ワークショップを開催することに
　→目次をベースにスライドを起こした
　→→テキストしかないようなもの
　→→→時間をかけずに作ることができる
・オースティンで無料のワークショップをやると告知
　→30人が関心を示した

◇無料で始めた目的は
・バリューを確かめるため
　→「無料にも関わらずバリューが無いなら、絶対お金を出してくれない」
・リスク緩和
・無料だから気に入らなかった人は「ワークショップは駄目だった」で終わり
　→お金を返せと言われることがない
・30人の申し込みはあったが、10人だけ
　→最初は10人だけが参加するという形で組んだ
　→→あとで違うバリエーションのワークショップをやるための余裕を持っておきたかった

◇最初の1回目からうまく評価された
・「これならお金を払ってもいい」
　→いくらくらいかを確認
・残りの二回はPaidなワークショップに
　→最初の1回以降は全て有料

◇有料のワークショップ開催は目的でもゴールでもない
・「コンテンツにバリューがあると感じてもらえるか」を確認するのが目的
　→無料だとバリューがあると感じてもらえているかを確認しにくい
・夏の間はずっとワークショップを開催
　→中身や流れをリファインしていった
・でも本やチャプターは全く書いてない
　→この段階ではまだスライドを作っているだけ

◇夏に出すと言ったのに、夏の間ずっとワークショップをやっていた
・いろいろな人から「まだでないのか」「どうなっているのか」というメールが届くように
　→対応しないといけない
・「もともと想定したより見込みが甘くて…　時間がかかってしまっている」
　→「これからきちんとプロジェクトに対応する」
　→「あと1つ、約束しましょう」

◇普通の本のそれではないやり方でローンチした
・「この本は、ソフトウェアのようにイテレーションをベースにして出します」
・「無料のチャプターを提供します」
・「プレビューも提供します」
　→プレオーダーしてもらえれば、2週間毎にチャプター2つを送ると約束
・これらを受けてランディングページを変更
　→プレオーダーのページを追加
　→"coming this summer" -> "comming soon"
　→→どれだけ時間がかかるか分からない

◇2週間毎にリリースするというやり方は、想定外なくらい上手くいった
・2週間の間にいろいろなフィードバックをもらえる
　→それを元に改善をかけていくことができた
・読者自身もアントレプレナー
　→構成の変更内容の提案
　→図を作って送ってくれることも
　→もちろんスペルミス・誤字脱字・文法の指摘も

◇全員がフィードバックをくれたわけではない
・注文してくれた人の半分くらい
　→彼らはアーリーアダプターだと思う
・アーリーアダプターなので出たらすぐに欲しい
　→出た後にきちんと改善・ヘルプすることをいとわない
　→→アーリーアダプターにはそういう人が多いと思う

◇だいたい本の3/4を書いた
・ここで想定外のことがおきた
　→大手出版社から連絡をもらった
・この本はリークしているようなもの
　→何度も出している
　→PDFかつDRMも入ってない
・何度も確認した
　→そのくらい驚いた

◇出版社の人が気にしていること
・この本がマーケットを作ることが出来たこと
　→魅力(Traction)があるということ
　→気になっているのはそれだけ
　→PDFやnoDRMのことは特に心配していない
・まさしく投資家の考え方と同じ
　→始まったばかりのプロジェクトに投資するというのはリスクが大きい
　→→彼らの方でかなりのリスク削減策をとらないといけない
　→本でも同じ考えが言えるということ

◇勢いもあってそのまま第一項を書き終えた
・この時点では複数の出版社と話を進めるようになっていた
　→最終的には2010/2に販売
・ランディングページ・ブックカバーをこの段階で綺麗に
　→この段階になって始めて綺麗にすることが重要になった
　→それまでは全く気にしていなかった

◇アーリーアダプターの人達がいて助かること
・「これには本当に価値がある」と思うときちんと評価のコメントを出してくれる
　→実際にコメントをもらい掲載した

◇この本は大規模なソフトウェアと全く同じ
・終わりはなくてリリースがあるだけ
　→第一版は対話(Conversation)の始まり
　→今でも改定を加えている
　→ブログ、ニュースレターでの活動も継続している

◇徐々にカスタマー層が広がっていった
・最初はアーリーアダプターだけだった
　→ウェブデザイナーやデベロッパー
　→今ではいろいろな人が読んでくれるように
・ワークショップは継続してやった
　→ワークショップはこの本のMVPになっているため
　→→内容を変えたり、客層を変えたり
　→→→そうやってきちんと学習しながら、第二版を作っていった

◇ワークショップで知ることができたこと
・本についての学び
・アントレプレナーが問題・課題がとして感じていること
　→これらの課題のために、この本以外にもプロダクトも作った
　→→オンラインで使うリーンキャンバスというツール
　→→他のプロダクト（metricsSystemなど）への派生も

◇最後に
・メタ原則の要素を感じ取ってもらえれば幸い
・ケーススタディはこれ以外にもいっぱいある
　→ハードウェア
　→ソフトウェア
　→政府
　→→実際にこのプロセスを使ってプロジェクトの成功率を上げている事例も
・もっとケーススタディを知りたい人は？
　→Lean Start Up Conferenceを検索してみるといいと思う
　→→政府系・教育系などいろいろな事例が見つかる






Ash Maurya様、O'Reilly Japan様、Yahoo! JAPAN様、ありがとうございました。

『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』ノート - 導入・理論 (1 / 4)

2012/12/17に開催された『Running Lean -実践リーンスタートアップ　刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』のノートの前半です。



◆カスタマーとお金を出す人とスタートアップの中の人の話

◇まずは悪いニュースから…
・ほとんどのスタートアップは失敗に終わる
　→これが現実
・でも失敗するのはスタートアップだけじゃない
　→大企業が新製品を市場に投入するときも同じ
　→→大企業の中の人もアントレプレナー精神が必要
・そして、成功した例の2/3は途中でプランを大きく変えている

◇Not a better plan A but a path to a plan that works
・成功するためには何が大事か
　→必ずしも完璧なビジョンは必要ない
　→→計画がワークするように調整できるか
　→→それをリソースが無くなる前にできるか

◇今日話すこと
・"plan A"から"ワークするプラン"へ、システマチックに調整できるということ
・それをリソースがなくなる前にやるにはどうすればいいかということ
　→スタートアップはリソースがなくなってダメになる、ということが多い

◇どうしてスタートアップを成功させることは難しいのか？
・普通のスタートアップはどういう流れで進むのか
　→まず良いアイデアが浮かぶ
　→→そのアイデア（ソリューション）に恋してしまう
　→→→そしてそれをビルドする
・これが一番典型的な形
　→ソリューションへの情熱があるから動く、ということが多い
　→→それはマーク・ザッカーバーグも同じだった
・我々はプロダクトをそういう風に見てしまいがち
　→「どういう風にペイするか、どういう風に開発していくか」というのが一番難しい
・お金を確保するためにどうするのか？
　→投資家を探したり、社内なら予算をくれる人を説得するのが普通

◇ではお金を出してくれる人はどう見ているか？
・彼らは、我々の考えたソリューションに恋なんてしていない
　→ソリューションなんて何でもいいと思っている人が多い
・彼らの関心毎は1つ
　→いかに提案をスケールアウトさせ、ビジネスモデルとしてペイさせるか

◇お金を出す人が注目するものは何か？
・魅力(traction)があるか？
　→作っている人以外にユーザがいるか？
　→ユーザがバリューを感じているか？
・コストストラクチャとレベニューストリームに関する計画があるか？
・どれくらいのカスタマー数・市場規模があるか？
　→カスタマーが誰かなのかは気にしない
・ディフェンス力があるか？
　→成功した後、どれだけ他社から市場を守れるか
・まとめると
　→魅力(traction)があるか？
　→カスタマーや市場に展開できるか？

◇そこまでの魅力があることが証明できていないなら？
・それはなんとかしないといけない
　→まずはカスタマーから始める必要がある

◇カスタマーはどう見ているか？
・自分の課題やproblemを解決してくれるものが欲しい
　→始めはあなたのソリューションへ恋してない
・関心は「あなたはどういうソリューションを提供してくれるのか?」
　→課題とソリューションの間にあるのがプロミス
　→→プロミスに注目するのがカスタマー
・この時点で注意すること
　→どんな課題を対象にするのか、というのは具体的にイメージできているべき
　→→そうすれば、どういうカスタマーに確認すればいいか分かる
・facebookも最初はカスタマーを絞っていた
　→ハーバード大学の学生のためのサービス
　→今は誰でも使っているけど、最初は違った
・誰にでも受けるよう広いスコープにしてしまうと、結局は誰にも受けないものができあがる

◇次にカスタマーが気にすることは？
・どれだけ負担がかかるかということ
　→負担などいろいろなものが条件を満たしていて、プロミスが魅力的なら参加してくれる
　→→参加してもらえれば、いろいろ試してもらえる

◇True productとは何か
・ビジネスモデル全体のこと
　→ソリューションではない

◇アントレプレナーの本当の仕事は、ビジネスモデルが持っているリスクを削っていくこと
・対話をとおしてリスクを削っていく
　→顧客と
　→社内の人と
　→投資家と
　→アドバイザーと
　→ときには競合他社と
・どう対話するか？
　→それはRunning Leanに書いてある



◆Running Leanの3つのメタ原則
・Document your plan A
・Identify the riskest parts of your plan
・Systematically test your plan

◇メタ原則の基になる考え方
・本当のプロダクト(True product)はビジネスモデルだということ
・ビジネスモデルを考えるときもテクニカルな観点から説明が付くということは重要
　→そこは注意してやった

◇メタ原則1 : plan Aの文書化
・これはなんでもそう
　→家なら設計図
　→旅行なら旅程表
・きちんと文書化しようというもの

◇通常ならビジネスプラン（事業計画）やビジネスケースとして文書化する
・ビジネスプランを書くことが楽しかった人はどれだけいるか？
　→ビジネスプランはとてもｐａｉｎｆｕｌ
　→→しかも書けと指示した人は最後まで読まない
・でもこういうことをしっかりやるのはアントレプレナーには非常に重要
　→その前にどれだけ対話ができているのかという問題があることに注意

◇エグゼクティブサマリとかエレベータピッチを書けといわれることもある
・どうせそういわれるなら…
　→最初から1ページに綿密でシンプルなものを書くのはどうだろうか？
・それがLean Canvas
　→こういう形でも充分作ることができる

◇事業計画やビジネスプランを作ったことがある人は、見出しを見るだけでLean Canvasに何が書いてあるかわかる
・ビジネスで重要となる、コアになるものを書き出したもの
　→特にリスクに着目している
・ビジネスモデルキャンバスに調整を加えてある
　→よりアクションがとりやすいように
・分割統治
　→複雑な問題は要素ごとに分解するという方法
　→Lean Canvasも1つ1つが独立した観点からまとめてある
・だからといってバラバラで良いわけではない
　→最終的にはジグソーパズルみたいに1つにまとまらないといけない

◇メタ原則2 : どこが一番リスクを高いか見つけるには？
・ソフトウェア開発はリスクが高いところから手をつける
　→それはビジネスも同じ
・どこにリスクがあるか、どうやってそれを低減するか
　→これが成功へのひとつの道
・EasiestではなくRiskestなところから始めるということ
　→これはポイント
・プロダクトを作るのはEasiest
　→特にプロダクトを自分で作っている人にとってはそう
・プロダクト自体が失敗するのは作りこみの問題ではない
　→カスタマーが見つからない、市場がないというのが一番の理由

◇どこがリスクなのか見極めるためには？
・Problem/Solution fit
　→課題と解決がどれだけフィットしているか
　→解決・対策に値する課題が存在しているのか
・もともとはトヨタ式、リーンの考え方
　→外・現場に出て行かないといけない
　→自分がいいと思っていることだけをやっていてもダメ

◇カスタマーに存在する問題、その中で何が重要なのか知る方法
・これはいろいろあると思う

◇カスタマーの重要な問題を理解した上で出来ることは
・何を最小単位で提供できるか
・MVP(Most Viable Products)
　→本当に小さな規模のソリューション
　→小さいけどカスタマーにバリューは提供できているもの

◇今までの伝統的なやり方
・時間をかけた作りこみ、テスト、調整
　→それからくカスタマーに使ってもらっていた
　→→そうやってできたものを使ってもカスタマーは迷子になってしまう
・途中のものでも、それがカスタマーの望むものか確認しながら進める
　→全体が出来上がってからカスタマーに出すのではなく
・小さい規模でも「これはカスタマーがバリューを感じている」という確認をとる
　→それからスケールするというステージに進むべき

◇通常のやり方とProblem/Solution fitの違い
・どのサイクルでもカスタマーを巻き込んで進めている
・プランをまとめて、そのプランにどういうリスクがあるかを確認する
　→そのリスクに対して体系的にテストもやるべき

◇メタ原則3 : システマチックにテストする
・Experiment - Eric RiesのBuild-Measure-Learnのサイクル
　→アイデア（仮説）からスタート
　→それを元にプロダクトを作る
　→→本当に小さなもの、全部ではないもの
　→実際に使ってもらう
　→そして定量的定性的に計測する
　→データとして確認する
　→データを活かして学習する

◇学習することによって調整を行う
・学習することで、想定していたリスクの正しさが分かる
　→違えば修正して進めばいい

◇Experimentを回していく上で重要なもの
1. スピード
 →時間は、スタートアップにとって一番大切で一番足りないリソース
2. 全てのExperimentはLearningで閉じる
　→成功のいかんに関わらず学ぶことはできる
3. 適切なフォーカスができているか
　→回そうとしているExperimentのフォーカス自体が正しいか
・フォーカスをきちんとやる
　→これがないと、Experimentのサイクルを回してもアクションが伴わなくなってしまう
　→→カスタマーすらついていないのにサーバを増設したりコードを書いてしまったりとか

◇次の3つを、フィードバックループを回す形でやっていく
1. Document your plan A
2. Identify the riskest parts of your plan
3. Systematically test your plan
・左から右、右から左へと



◆リーンスタートアップとは何か

◇リーンという言葉自体が昔は誤解を生んでいた
　→チープとか良くないプロダクトであるとか

◇リーンはトヨタの製造システムから取ってきた考え
・リーンの考え方の重要なポイント
　→いかにムダを省くか
　→いかにリソースを有効活用するか
・お金は重要なリソース
　→ただ、お金が一番価値があるリソースというわけではない
　→一番価値があるのは時間
・お金や人的資源は増減できる
　→時間は一定方向にしか進まない

◇自分のリーンスタートアップの定義
・ある一定の時間の単位で、何が一番リスクなのか最も効果的に学べるやり方






Ash Maurya様、O'Reilly Japan様、Yahoo! JAPAN様、ありがとうございました。

『DevLOVE2012 - これからの自分戦略 〜組織に埋もれない自分のウリコミ〜』ノート

2012/12/16に開催された『DevLOVE2012 - これからの自分戦略 〜組織に埋もれない自分のウリコミ〜』のノートです。



◆山本裕介氏による自己紹介

◇自己紹介
・あちこち転職する人
・侍（ツール）の人
・元ｔｗｉｔｔｅｒの人
・twitter4jの人

◇自分戦略は何のためにあるのか
・自分がやりたいことをできるようにする
・やりたくないことをしなくてすむように
・収入が上がる
　→仕事の上では大事な話

◇決定する要素
・やりたいこと・やりたくないこと
・やれること
　→やりたくないけどやれること、ってある
・妥協できること
　→やりたくないけど、やりたいことの為に
・自分を取り巻く環境
　→自分がどういう環境にいるのか考えることが重要
　→→会社
　→→日本
　→→世界
・何が金になるのか
　→考えておくことが重要
・やりたい / やりたくないことはどんどん変わっていく
　→自分戦略も常に変わっていく

◇自分はなにをやりたいか
・組織に飽きっぽい、なじめない
・技術（ソフトウェア）で食べていきたい
・でも技術一辺倒にならないように
　→それなりにビジネスマンとして渡り歩けるスキルは大事
・なんとなくグローバルな
　→世界を相手に仕事ができたら面白い。そういう親を見てかっこいいと思ってた
・政治に力を注ぎたくない
　→権力・人の面子とか気にせず技術にフォーカスしたい

◇自分にやれること
・java
　→ずっとやってきた
・エンタープライズアーキテクチャ
　→会社でやってきた
・プロジェクトマネジメント
　→それなりのユーザがいるOSSのプロジェクトをまわし膨らませてきた
・API設計
　→twitter4jはtwitterのAPIを使いやすくするためのライブラリ
　→→APIのたたき方
　→→twitter4jを使う側の使いやすさ
　→→初心者から上級者までいろいろな人が使う
　→→→どうしたら簡単に迷わず使えるかを考えている
　→→→→どうしたら問い合わせが無く、シンプルでスムーズに使えるか
・ちょっとの英語
・ちょっとの折衝
　→顧客と対話する場を自分で作ってやってた


◇自分戦略に辿りつくまで
・何をしてきたか
　→大きく三つ
　→→個人として社会人になるまで
　→→仕事としてこれまで
　→→社会人になって個人として何をしてきたか

◇個人として社会人になるまで
・雑誌掲載のゲーム手打ち
　→主にベーシックとか
・遊ぶだけで満足しなくて改造
・自分でプログラム
　→最初はベーシック
・パフォーマンスの問題が
　→MSXでマシン語(Z80)
・作ったソフトをtakeruで展開
　→自分のソフトを掲載依頼が来た
　→そこからフィードバックをもらえたりした
・結果身に着けたこと
　→プログラミングスキルの下地
　→マシン語（低レベルなレイヤで起きていることの把握）
　→→javaの後ろで何が起きているかとか

◇個人として何をしてきたか（社会人以降）
・作ったものは全てオープンソースに
　→楽するためにはどんな苦労でもしてやる
・侍
　→javaのスレッドダンプの解析ツール
・虚無僧
　→webLogicサーバのモニタリングツール
・わらじ
・twitter4J
　→twitterAPIを触るツール
・変な名前になってるのは？
　→自明な名前をつけるのが好きじゃない
　→英語圏で検索したときに露出しやすい
　→日本発と言うイメージも打ち出せる
・twitter4J
　→javaでtwitterならこれがわかりやすいということで

◇社会人になって個人として何をしてきたか
・（中略）

◇社会人・個人としての活動を通して身に着けたこと
・技術力
　→日本顧客の要求レベルはすごく高い
　→→「問題があったけど、これで回避できました。今度からはこうしてください」では駄目
　→→→「恒久的な対策はどうする」「いつ直るんだ」
　→→→→海外とは違う
・顧客を安心させる能力（ハッタリ力）
　→自社の製品を全て知っているという分けではない
　→だからといって「わかりません」ばかりでは信頼されない
　→→それっぽく見繕う力は大事
・ある程度の折衝能力
　→営業とも仕事をしてきた
・国や地域で（商）習慣が異なるという認識
　→要求レベルが違う
　→注文の仕方も国によって違う

◇振り返って自己分析
・細かいことでも非効率は嫌い
　→人件費がかかりすぎるような仕組みとか
・正義重視（エンジニアとしての正義）
　→効率化/高速化大事
　→→くだらないマニュアルオペレーションではなく、できればなんでも自動化したい
　→→非効率な部分は止めたい
・人の面目のために正義を軽視とか無理
　→「偉い人があの技術を押しているから」とか
・自分の信じることをしたい
・自分の信じるものを売りたい
　→会社は商品の幅を広げていく
　→中にはいけてないソリューションや製品も出てくる
　→ビジネスマンとしてはそういうものも扱わないといけない
　→→自分が信じられないものを使うのはいやだ
・自分の正義から外れる環境はストレス
・政治軽視
　→政治は嫌い
　→密室での会議は嫌い
　→→タバコ室に集まるだけやけに詳しかったりとか
・オープンがすき
・技術を広める
　→社内で内製するだけではなく世界に広める

◇これから何をしていくのか
・何をしたいのか
・自分が何をできるのか
・何をしないといけないのか
　→したいことだけしてもお金にならないかもしれない
　→出来る範囲でないといけない
　→やらないといけないこともあるだろう

◇何をしたいか
・スケールするビジネス
　→時間に対してお金を貰うより自分で開発
　→今からだと周回遅れかもしれないけど、まだ間に合う
・なにかしら貢献したい
　→自分が頑張ることでみんなが助かるようなことがあれば
　→自分が面倒だと思うことは他の人もそうだろう
・DRO(Dont repeat ourself)
　→みんなが、同じ事をしなくて済むような世界になればいいなー
・社内には転がしておくにはもったいないツール・技術がたくさんある
　→「これすごい便利ですね。オープンソース化しないんですか？」「業務時間中に使ったので…」
　→→そういうのはもったいない
　→自分の時間で作って公開すれば世の中のためになるし自分の宣伝にもなる

◇何ができるか
・英語が少し
　→もっと出来る人がたくさん
　→武器というほどではない
・java
　→代わりがたくさんいる
・API設計
　→なかなかお金にならない
・人にものを教える
　→自分からやりたいといってやってるわけではないけど
　→けっこう好き
　→でもスケールしない

◇差別化ポイントとして大事なところ
・手を動かす
　→いろんなツールが普遍的に転がっている時代
　→「○○できます」だと「へー」で終わってしまう
　→→手を動かしてものを作ることがすごく大事
　→今までは中間的なツールばかり作っていた
　→→これからは最終製品のアプリを開発したりしたい
　→→→自分を売り込めるようなものを
　→でもやりたいことばかりやっているわけにもいかない

◇何をしなければいけないか
・当座の資金確保
　→SIerでバイト
・他の収入源も考え中
　→自分が好きな製品の売り込み
　→→ライセンスビジネスって儲かるかというと…
　→→→これに対して力を注ぐつもりはない
　→→製品を作っている会社の社員になるかというと…
　→→→「うーん…」という製品も売らないといけなくなる
　→やりたいのは幸せになれるツールを広めること
　→→自分が好きなものだけを売りたい
・売名
　→全然知らないエンジニアに仕事を頼むのは難しい
・モノ書きで名前を売る
　→収入源としては期待していない
　→→物凄いスピードでかかないといい収入にはならない
　→でも伝えるのは好きだから書く
　→→「あの記事を書いている山本さん」と言ってもらえる
・腕磨き
　→新しい技術にキャッチアップしないといけない
・技術選定
　→自分でサービスを作るのに何がいいか
　→→自前なので標準にこだわる必要はない

◇まとめ
・10年先を見据えたキャリアプラン
　→そんなのない
　→常に変化していくもの

◇結果論として何がうまくいったか
・面白いことを見つけたら転職
　→やりたいことができる（可能性が高い）
　→→ずっといるとやりたくないことがどんどん増えてくる
　→収入アップ
　→新しい出会い
　→→過去の出会いの切捨てではない
　→→→会いたい人とは会える
　→→→会いたくない人とは会わなくていい
・「やだなー」と思ったらどんどん転職するのがいいと思う
　→安定収入のためには同じ会社にずっといるのが無難
・オープンソース
　→技術力向上
　→コミュニケーション能力向上
　→グローバルで通用するマネージメント力向上
　→売名！
・情報発信大事
　→ブログ
　→ソースコード公開
　→勉強会などで話す
・収集するのは簡単
・情報発信すると情報が集まる
　→フィードバックや他人のコメントがもらえる

◇自分戦略
・好きなことをやればいい
・10年先を見据えるなんてできない
　→そうではなく半年先、1年先を見据える
・愚痴はよいけど、行動に移さないとだめ



◆質疑応答

Q.
オープンソース開発を続けるモチベーションの源は？

A.
公開するだけなら簡単だけど、使ってもらえないとつまらない。
誰も使わない、フィードバックがないだとモチベーションを保てない。
だから宣伝はすごくしている。
twitter4jはtwitterが流行ると思ったので作った。
海外のニュース系サイトに投稿したりしてメディアに露出するようにし、認知度を上げた。
そうやっているうちにパッチが飛んできたりして、それでモチベーションが上がった。
いろいろなところで使われているというのは一つのモチベーション。
でも、使う人が増えすぎてプレッシャーを感じることもある。


Q.
仕事の外でアプリを作る時間をどう捻出するか？

A.
気が向いたときにやってる。
業務時間中には全く触らない。
「仕事で役に立ちそうだけど、会社だけじゃなくて世界の他にも困っている人がいるなー」というものは業務時間じゃなく個人で作って公開している。


Q.
所属している会社に飽きたきっかけは？

A.
飽きっぽい性格なので何年かいると飽きてしまう。
逆に何十年も勤めている人にそのモチベーションについて聞きたい。


Q.
面白かったり変だったり印象に残っている面接は？

A.
「会社に来ませんか？」誘われたので顔パスで入れるのかと思って会社に行ったら　…ガチで面接されたことがある。


Q.
ここだけは譲れないといった条件は？

A.
最低限はお金。現状維持以上というのは大事。
あと自分がやりたいことができるか。
でも1億2億くれるならやりたくないことでもやる。






山本裕介様、CyberAgent様、DevLOVE様、ありがとうございました。

『DevLOVE2012 - Social Change 〜ソフトウェア開発者が経営者になるまでと、これからの戦略〜』ノート

2012/12/15に開催された『Devlove2012 - Social Change 〜ソフトウェア開発者が経営者になるまでと、これからの戦略〜』のノートです。



◆はじめに

◇倉貫義人氏の自己紹介
・ソニックガーデンという会社を経営
・twitterとブログをやっている
　→お客様、ユーザに見てもらえる
　→自分達が何を考えているか、やっているかを書いている
　→→ブログなら外の人にも社員にも読んでもらえる
・「心はプログラマ、仕事は経営者」がモットー
　→日本では、営業出身の人やプログラマだったけどその心を忘れた人が経営者をやっている
　→→そういう経営者ではなく、プログラマの気持ちがわかる経営者のままでいたいと思いながらやっている
・少ない人数でどれだけ大きいことが出来るか
　→それがかっこいいと思っている会社
　→たくさんの人数で大きいことをやるのは普通
　→→普通なのはかっこよくない
　→ＩＴは少ない人数でも大きい仕事ができる業界
・Agile x Ruby x Cloudが技術的プレゼンス
　→アジャイルでずっと繰り返して開発
　→RoRでずっと保守性の高い状態を保つ
　→クラウドでスモールスタート・スケールアウトしている
・やっていること
　→自社のサービス
　→納品のない受託開発

◇キーワード
・エンドユーザ「所有から利用へ」
・作り手「完成させることから持続させること」へ
　→お客様は所有するわけではない
　→→完成させても仕方が無い
　→→利用してもらわないといけない
　→→→利用してもらうためには持続しなければいけない
　→完成しただけではお金は儲からない
　→→月々使ってもらってお金になる
　→「バグがありません」と言っても利用者がいなければお金にならない
・「ソフトウェアそのもの」ではなく「ソフトウェアが使えること」を売る
　→今までは作ったものを売ったらお金をもらえるというビジネスモデル
　→→これは八百屋と同じ
　→→→一次産業
　→ソニックガーデンは「使えること」を売る
　→→タクシーや映画館を考える
　→→「そのもの」ではなくて、移動する距離や映画を見ることを買う
　→→→これは三次産業
・ソフトウェアはまだサービス産業になっていない
　→サービス産業としてのITをやっているのがソニックガーデン



◆キャリアと自分が考えていることの話

◇学生時代
・プログラムをずっとやっていた
　→ベンチャーで働いていた
　→アルバイトとしてすごく給料がよかった
・研究室の仲間たちとフリーソフトを開発
　→ウェブで公開
　→みんなダウンロードしてくれる
　→掲示板に書き込んでくれる
・プログラムを書くと反応がもらえる
　→これは最高
　→→「インターネットとプログラミングを一生やっていこう」

◇まず海岸沿いのSIerに
・入社年度に経営方針の転換が
　→「技術大事だね」から「マネジメント大事だね」へ
・デスマーチプロジェクトに参加
　→周りはプログラミングの経験がないが、自分はベンチャー出身
　→→プログラミングができるということで悲惨な現場に
　→→ガンダム世代なので「1年戦争だ！」
・でもプログラマには1億円 ～ 2億円のプロジェクトを立ち直らせることができない
　→どれだけ画面を速く作ることができてもダメ
・あるとき平鍋さんに出会った
　→XP本を紹介された
　→→「俺の考えていることと同じだ！」
　→→「XPやアジャイルを広めていけばプログラマとして出世していく道があるのでは？」
・社内勉強会をやってみた
　→部内のメーリングリストに投げた
　→→でも反応がない
　→社外の勉強会やコミュニティに参加
　→→社内にいると半径3メートルしか見えない
　→→社外にいけばいろいろな人に会える

◇XPを読んで、そのとおりマネジメントを行った
・エンジニアをしていたが、徐々にマネージャの立場に
　→マネジメント・お金の計算…
　→→こういうのは苦手
・XPのとおりマネジメントをやった
　→仲間が集まってきた
・新入社員から育てた
　→やりたくない人がいるので、引き受けてしまう
　→→真っ白なキャンバスにアジャイルを教えることができる
・あえて炎上プロジェクトに入るという育て方もある
　→若いときだけ限定の手法
　→こういう場所ではみんな困っている
　→わらをもつかむ思いなのでやってくれる
　→「朝5分でいいから立ってミーティングしてみましょう」
　→アジャイルとか言わないでやるのがポイント
　→→上手くいったら「アジャイル」という
　→→上手くいかなかったら「それは無理でしょう　…上手くいくわけないじゃないですか」で収める

◇アジャイルのチームを作って中間管理職になったが
・ある日、会社の都合でチームが解散
　→履歴書を書いた
　→→「これじゃ転職してもPMやらされるわ」
・「もう一回プログラマをやろう」
　→でもjavaでは若い人に勝てない
・「エンタープライズでrubyをやろう」
　→でも受託はやりたくない
　→→「社内システムをやろう」

◇人月と完成責任のビジネスモデルは止めようと決めた
・そのために3つ捨てた
　→java
　→マネジメント
　→SIerの受託開発
・あと社内での出世も捨てた
　→「好きなことをやろう」
　→社内システムを作る仕事についた
・内製でアジャイルをやってすごくうまくいった
　→内製でアジャイルはすごく上手くいく
　→最初は2人で始めた
　→→それが全社展開するまでになった
　→→→その社内SNSを使ってイベントを企画・開催する人まで現れた

◇サラリーマンとしての転機
・また部下を持ってかれた
　→自分達でビジネスにすれば解散されないだろう
・社内SNSをオープンソースにしよう
　→会社を辞めて現場に行ってもそこに戻れるだろう

◇自分戦略の振り返り
・オーナーシップを持つ
　→会社を辞めるときまで自分は"会社の中にいる人間"だと思っていた
　→→そうではなくて、個人と会社は対等
　→→単に雇用契約をしているだけ
　→→→どっちが上か下かとかない
　→自分の人生は自分でオーナーシップを持たないといけない
　→→オーナーシップは「自分が会社員である」とか、そういうことには全く関係ない
・変化は自分から起こす
　→待ってから変化を起こすと大抵うまくいかない
　→→自分から変化を起こすようにした
・自分のチームを作る
　→2年目に辞めようと思って相談したとき言われた
　→「まだ止めたほうがいい」
　→→いま辞めても仕事はない
　→→元の会社から仕事をもらう形になる
　→→→ただ下請けになるだけ
　→→→→これはつまらない
　→「有名になれ」
　→→「自分の名前で仕事ができるように」
　→「仲間を作れ」
　→→いまだと自分が病気になったら終わり
　→→本当にやりたいことがあるなら一緒にやってくれる人が必要
　→→→仲間・チームを作らないといけない


◆起業・ソニックガーデン・ビジョン

◇起業を決めたときに考えたこと
・リーンソフトウェアビジネス
　→大きなことをするのに大きなお金を使うのがソフトウェア開発
　→→でも、いまのソフトウェア開発にそんなにお金がいらない
　→→→少人数でも開発できる
　→→→データセンターもクラウドで代替できる
　→→→→少人数でもそれなりのことがやれる
・ライフスタイルカンパニー
　→一生プログラマとして働きたい人がいる
　→→どうすれば（彼らが）それをずっとやっていけるかを考えている
　→上場してバイアウトとか考えてない

◇ソニックガーデンの3つビジョン
・IT業界の産業革命
　→お客様の真のパートナーになりたい
　→「作って終わり」はパートナーじゃない
　→→お客様がもうかったら自分も儲かるような、そういうやり方
・プログラマを一生の仕事にできるような業界にしたい
・いつでも夢にチャレンジできる社会に

◇世の中にはオーダーメードで作りたいというニーズがある
・受託はやるけど納品しない、派遣しない
　→月額定額モデル
・金額を見積もりから分離する
　→出来る範囲で頑張る
・顧問弁護士の働き方と同じ
　→プログラマも月額定額で顧問になればいい
　→→これは、お客様から見たら社員（内製部隊）に見える
　→→個人的には内製が一番いいと思う
・でも内製は難しい
　→実際にエンジニアを雇えるか？
　→いいエンジニアが分かるか？
　→→だからそこにエンジニアとして入る
　→→→移動しないで月額定額でやる

◇月額定額の形態が向いているビジネス領域がある
・次のようなものが必要な領域
　→スピード重視
　→フィードバック
　→スモールスタート
　→スケールアップ
・社員向けのシステムではなく一般向けのシステム
　→例えばEC。お客様の外に付加価値を提供するようなもの
・これからの時代はそういうビジネスばかりになる

◇完成指向から持続可能へ
・バグ0ではなく、出たときにすぐ直せるように
　→バグがないのは当然だけど、長く使っているといつかは出る
　→→そのときにどれだけ早く直せるかが大事
　→ある一点ではなく、ずっと続けることが大事
・コードの共同所有
　→綺麗なコードでないといけない
　→→リファクタリング
　→→コードレビュー
　→→テストコード
　→→→技術戦略に至っていく
　→みんな好き勝手に言語などを選定すると共同所有できない
　→プロジェクト毎に好きな技術を使うと技術が残らない
　→→プラットフォームの統一が必要
　→→→ここまでいくと経営戦略
・サーバ落ちてもいいけどすぐ復旧できるように
　→「絶対に落ちない」ではなく

◇品質とは何か
・仕様どおりに作っても仕様が間違っていると…
　→それはゴミ
　→ビジネス的に正しいことをやらないと価値にはならない
　→→ただただテストとか頑張っても仕方が無い

◇究極的にはプログラマが全部やるべき
・プログラマが要件定義から運用まで全部やる
　→テストはマーケティングからビジネスまで
　→運用はローコストキャリア
　→→技術の統一
　→→徹底的な自動化
　→→→少ない人数でも回せるように

◇所有から利用という波は明らかにおきている
・完成から持続へ
　→一次産業から三次産業へ
・まさしく産業革命
　→こういう活動を起こしていくことが大事

◇ソニックガーデンでは新規事業をたくさんやっていこうとしている
・でもビジネスは難しい
　→失敗したら死んでしまう
　→成功しても死んでしまう
・起業リスクはリスクじゃない。マネジメントすることができる
　→大きな山にいきなり登ったりはしない
　→小さな山を何回か登ってから
　→→起業リスクもそういう風にマネジメントできる
・ウェブ開発は基本的に人件費だけ
　→でもみんなホールインワンを狙う
　→でも脱サラして一念発起とか
　→→これはナンセンスだと思う
・スタートアップはまだ産業ではない
　→スタートアップを成功させるためには経験とか学びの時間が必要
　→→でもサラリーマンにはその時間がない
　→→→会社を飛び出さないといけない
　→→→→これはすごくもったいない
・一発成功はない
　→何回か失敗して、それから成功する
・学びの時間と一念発起のギャップをどうすればいいか
　→年齢が少々高くても企業できる社会に
・ソニックガーデンでは、顧問もスタートアップも一緒にできる
　→優秀な人は週の前半に仕事を終えてしまい、時間を作り出せる
　→→その時間にチャレンジできる

◇プログラマを一生の仕事にできるように
・「高みを目指し続けたい」
　→まずそう思ってもらいたい
　→→でも1人では登れない
・プログラマ = ソフトウェアのエンジニアリング全てに責任を持つ人
　→エンジニアリング = マーケティング・ビジネス・プロダクト以外の全て
　→ソフトウェアの全てを見る覚悟が必要

◇ソフトウェアの価値
　・完成した時点では0
　→お金を払って作ってもらったなら、最初はむしろマイナス
　→動かし続けて始めて価値がうまれる
・運用して使ってもらうところが本当に大切
　→エンジニアには運用・保守 ～ 最後の死んでしまうところまで見る覚悟が必要
　→でもそれができるプログラマってどれくらいいる？
　→→多くない、でもできないわけではない

◇どうすればソフトウェアの全てを見ることができるか
・ずっとRubyとお客と話すことしかやっていないエンジニアがいる
　→そうやって成長すると6年目にCTOになれる
　　→入社1年目から育てると全部のことができるようになる
・戦略とはどんなことに時間を費やすかということ
　→自分の時間を上手く使えばみんなにもできる

◇ソフトウェアの産業革命
・最初の産業革命で、職人から工場の時代になった
　→インターネットの登場
　→→再び工場の時代から職人の時代に
・プログラマはマニュアル化のできないナレッジワーカー
　→ノマドでタイムフリー
　→プログラマの生産性が一番高いのはマネジメントされていない状態
　→→自由にやらせるほど生産性が上がる
・ナレッジワーカーはマネジメントできない存在 = 大企業は不要
・会社としてどうやって自由にやらせる？
　→大きな会社じゃ無理
　→→小さな会社にするしかない
・人を信頼することが重要
　→小さい会社なら、信頼することができる
　→→個人の顔が見える範囲の会社で充分
　→ソーシャルメディアによる信頼と共感の世界
　→出来る量について嘘をつかない

◇ソニックガーデンの三つのチェンジ
・Embrace change
　→変化を受け入れる
・Fearless change
　→自分から変えていく
・Social change
　→変われたならそれを回りに広める



◆途中で出てきた話

◇脳のブレーキを壊す
・この前の（何かの）世界大会で記録が2回3回と塗り替えられることがあった
　→ここ10年破られていない記録だった
・誰かが1人破った
　→他の人も「オレもいける」となった
・社内で半径3メートルだけ見ているとそうなる
　→偉い人も社外の飲み会で見ると普通のおじさんだった
　→→そういう人達がすごい仕事をしている
　→→→「自分もできるのでは？」と思えた

◇外の活動と中の活動をする「ガラパゴスなキャリア戦略」
・大きな会社にいて外で講演・発表している人は珍しい
　→重宝される
・大きな会社でアジャイルをやっている人は珍しい
　→やはり重宝される
・エンジニアは自分の腕こそキャリアと考えがち
　→でも実は自分がいる環境も含めてキャリア
・自分の周りの環境も自分の価値
　→社内でやっていることを内緒にするのは勿体無い
　→社外でやっていることを社内に還元しないのは勿体無い

◇会社で新しいことをするには？
・提案ではなく相談
　→提案だと、上司は必ず反対する
　→→威厳がなくなるから
　→「○○をやりたいけどどうしたらいいか分からない」と聞く
　→→Yes / Noではない聞き方をする
・肩書きはくだらないけど大切
　→役職が低いと返事をくれない人がいる
　→→大企業では大事
・トップかららの視点と言葉を身につける
　→「社長もそういっているよね」ということで納得してもらえる

◇サラリーマンは意外とチャレンジできる
・経営者でチャレンジして失敗するとやばい



◆SIerとそのビジネスモデルについて

◇世の中は人月か成果物の完成責任かのどちらか
・macBookAir
　→モノにお金を払う
　→完成責任のビジネス
・弁護士
　→「絶対に勝訴してください」ではない
　→1時間辺り幾らのビジネス
・日本のSIerはねじれている
　→人月ビジネスなのに完成責任がある
・生産性を上げるほど売り上げが下がる
　→時間や人が必要な提案をする方が評価される

◇SIerでアジャイルをやろうとしてもあまりうまくいかない
・ビジネス的に完全に成功しない
　→アジャイル関係のものには別に悪いことは書いてないのに…
・なぜなのか？
　→そもそものSIerのビジネスモデルが悪い
　→→SIerのゴール：ものを売ること
　→→お客様のゴール：使ってお金をもらうこと
　→どうしてもいさかいが起きる
・SIerのビジネスモデル = 決まった要件の中でどれだけ作るか
　→このモデルが悪いのではないのか？

◇SIerを経営者の視点から見ると
・要するに保険屋
　→ユーザは「システムが完成するという安心」を買う
　→お金を出せば最後はなんとかしてくれる
・リスクを丸抱え出来る企業体力、これが優位性になる
　→合併するのはそういうこと
・保険屋ならそれは正しいかもしれないが
　→赤字プロジェクトに入ったエンジニアは悲惨
　→→人生を消費してしまう
　→→これはお金で解決できない

◇SIerとクラウドのビジネスモデルの違い
・SIerは作ってお金をもらって終わり
　→品質管理が製造業の考え方
　→→作りこんで、売る瞬間が最高品質
・SIerは製造業の考え方
　→一発ゴールの世界
　→こういう世界はウォーターフォールは理にかなっている
　→→アジャイルとか言わなくて良い
・SIerのつもりでクラウドビジネスをやっても全然儲からなかった
　→使っている瞬間を最高にしようと切り替えたら上手く回り始めた

◇今のシステム開発には問題がある
・派遣業界で人間のビジネス
　→業界の中の人から見ても問題がある
・ちょっと画面を変えるだけで数万、数十万かかる
　→業界の外の人から見るとこういう問題がある
・実際はそんなに費用も時間もかからない
　→数字が膨れるのはバッファがあるから
・みんなが自分の分のバッファを積む
　→期日を切ると、それは絶対に達成しないといけなくなる
　→→絶対にやるためにはバッファは積まないといけない
・バッファを積むのは人間だから仕方が無い
　→持たないというのは単なる精神論
　→→でも積むとぼったくりになってしまう。
・バッファが積まれる理由
　→「絶対にできる？」と言われると「5日」と返す
　→「できなくてもいいけどどれだけかかる？」だと「3日」
　→→バッファは"絶対"の約束から生まれる
　→→完成と納品から納期が発生し、それには"責任"が生じる
　→→→そしてバッファが積まれる
・納品しなければ上手くいくのでは？
　→ソニックガーデンがやっていること







倉貫義人様、CyberAgent様、DevLOVE様、ありがとうございました。

『DevLOVE2012 - 周りを巻き込みながら歩んできた関西人スクラムマスターの自分戦略』ノート

2012/12/15に開催された『Devlove2012 - 周りを巻き込みながら歩んできた関西人スクラムマスターの自分戦略』のノートです



◆講演者（中村洋氏）について

◇自己紹介
・大阪在住のエンジニア
・認定スクラムマスター
・5社くらいを2,3年くらいで渡り歩いてきた

◇コミュニティ活動
・devlove関西
　→セッション10個
　→100人を超える申込者があった
・スクラム道関西
　→アジャイル実践者が集まる
　→ワークショップでアジャイルの普及
・デブサミ関西
　→来年は実行委員長　

◇今日一番伝えたいこと
・「ええと思ったらやっていこう」
・人間、やらない理由はいくらでも出せる
　→それだといつまでたってもできない
・そういう思考にそもそも入らないことにした
・フィードバックをもらうようにした
　→厳しいフィードバックもある
　→→でもそれがあれば方向転換、突き進むなど考えることができる
・フィードバックを得る環境を作ることが重要（仲間など）

◇自分戦略の源泉
・基本路線
　→「ええと思ったらやっていこう」
・三つの柱
　→チームの成長
　→エンジニアをつなぐ
　→スパイラルな成長

◇自分の源泉にあるもの - チームの成長
・仕事の仲間が成長していくのを見るのが好き
　→時間、品質などが良くなっていく
　→振り返りで成長している様を見られるのはうれしい
・成長させるのではない
　→成長するのは彼自身
　→成長できる環境を精一杯整える
　→自分の経験を話すことはある
　→→でも押し付けはしない
　→しょうがない環境があれば整える
　→→たやすく成長できるように
・「自分達でできるからお前はもういらない」
　→こう言われるのが夢

◇自分の源泉にあるもの - エンジニアをつなぐ 
・自分には世界を変えるようなコードは書けない
　→でも、そういう人をつなぐのはちょっと上手かもしれない

◇自分の源泉にあるもの - スパイラルな成長
・主に自分自身へのモチベーション
　→同じところをぐるぐる回るのはいや
・次に会ったときお土産を渡したい
　→数ヵ月後も同じレベルのアウトプットをしているのはいや
・「この人と接点があれば自分にとってプラスなんだ」
　→そう思われる存在でいたい
　→でも他人にお土産を求めているわけではない

◇誰かの役に立ちたい
・これはみんな持っていると思う

◇そのためにどうするか
・自分でハンドルを握る
　→周りに影響されずに自分の判断で
・そのために4つのことをやる

◇自分でハンドルを握るための4つのこと

・やりたいことを表明する
　→半年に一度の評価面談ではみんな話す
　→→でも日常からやっている？
　→言っているつもりでも全然伝わっていなかったりする
　→→表明してやっていくこと = 自分のやりたいことをやる第一歩
・爪を砥いで準備
　→表明するだけでは駄目
　→→準備してるかどうかは表明の真剣さにつながる
　→→→やっていた方が回りは認めてくれる
・雪かきをやる
　→他の人がやりたがらないこと
　→チームでやっているとそういうタスクが発生する
　→→そのときに積極的に手を上げて拾っていくことを心がける
　→→→信頼貯金が出来る
　→そうすると、いいボールが回ってきたときにそれをまわしてくれる
　→ムダだと思われているタスクは、自分が好きに出来る
　→→効率化したり作業自体を廃止したりできる
　→→→チームのためになる
・仲間を見つけて巻きこむ
　→人間1人だとダークサイドに落ちやすい
　→言い訳もしやすい
→「それは違う」と言ってくれる仲間は重要



■エピソード

◆とあるお客様にて(10年くらい前）

◇コンテキスト
・100人くらいの開発会社
・ほとんどお客様先に常駐
　→自社には月に一回帰る

◇ここは面白かった
・こういうところはたいがいつまらない
　→ここは違った
・技術的にとがっている人もいた
・常駐先のお客様がいろいろやらせてくた

◇前提
・お客様と自社の両方に信頼貯金があった
・何回か社内勉強会やっていた
　→でもうまくいってなかった
　→平日帰ってきた後
　→→なかなかやらない
　→客先常駐なので、普段は顔を合わせない
　→→休日にわざわざそういう人と会おうとは思わない

◇こういう状況の中での問題
・独りでお客様先へ行くことが多い
　→目の前のタスクでいっぱいいっぱい
　→→技術を学ぶ機会がない
・結果として若手のモチベーションが低い
　→言われたことだけやればいい
・これはもったいない

◇アクション
・チームに若手をどんどん引き入れていった
　→本社に戻ったとき、姿勢のある若手とかいたらチームに引き入れる
　→姿勢を重視
・ペアプロやレビューなど一緒に考える時間を多く取った
　→タスク渡して放置という現場が多いがそうやらなかった
　→→そういう時間を徹底的にとった
・魚ではなく魚の釣り方を教えた
　→最初は釣れない
　→→何回かやると釣れるようになる
　→→→そのうち改善するようになる
・機能で分けてシステム開発
　→工程で分けない
　→「若手はとりあえずテストでも…」ではない
　→→そうではなく、縦串で一通り任せる
　→→→そうすると横のことも判る
　→小さな開発だったのが功を奏した

◇起こったこと
・人を集めすぎたので自分の仕事が回らなくなった
　→朝早く仕事を開始
　→→同じ勤務時間でも、残業するよりはるかに仕事ができる
・指示待ちではないやり方を知ってもらった
　→考えることでやりがいをもてるし、楽しくできる
　→自分でいかようにもできる
　→→ただ、全員がそうなったわけではない
・会社の数字にも貢献できた
　→若手をどんどん引き入れたので

◇ここでのまとめ
・社外常駐でもやりようがある
　→成長もできるし仲間も作れる
　→諦めたりやらない理由にはしない
・自分で仲間を見つけて巻き込もう

◇わざわざなんでそんなことをやるか
・もっと顧客に価値を届けたい
・若手にこうすればいいのではと伝えたい
・そういう情熱があった

◇何で辞めたか
・会社が派遣主体に
　→「翌月から○○に行って」みたいなのが多い
・チームから優秀な若手がはがされる
　→彼らが転職してよい会社にいく
・もういいかなとなった



◆某SIer

◇コンテキスト
・6000人規模でサラリーマンSEはそれなりに多い
・とんがった人もたくさんいた（る）
・人材輩出企業

◇自分の状況
・本部系部門で社内向けフレームワークやツールを作成
・Redmineやjenkinsなど生産性向上のセミナーや勉強会の開催

◇問題
・勉強会に参加者がなかなか集まらない
　→本社での開催ではそこそこくる
・これからとんがるかもしれない人達をつなげることができていない
　→これからとんがろうとしている人が現場にはそれなりにいたにも関わらず

◇アクション
・ローラー作戦
　→声を掛けまくった
　→メール・社内SNS・ランチ
　→→とにかく話しかけるようにした
　→社内SNSでのみ面識がある人に、出張したときに直接会った
　→→そうやって一本釣りした
　→10人に声をかけて1人釣れると成功だと思う

◇ポイント
・全員が社内勉強会に熱心なわけではない
　→大きい会社なので「粛々と定年まで給料をもらえればいい」という人もいる
・相手が何を求めているかを考える
　→相手のメリットや不安を聞く
　→→「今の業務ではすぐに役に立たない…」
　→→「業務時間内なので上司の許可が…」
　→→「勉強不足で怖くて…」
　→→→すぐに使えるコンテンツを入れたりハンズオンして手取り足取りで教える
　→→→相手が欲しいものを聞いて、内容を調整する
　→→→マシンを持ってきてもらって明日もって帰って使えるようなもの提供する
・一部や全部を業務時間外に開催する
　→「残業代はどうするのか？」という声
　→→そういう人は放っておく
　→組織がそういうことを言うなら、それはさっさと見切りをつける
・もっと上の人に働きかけてお墨付きをもらう
　→上にの人はもっと人材育成とかそういう目線がある
　→→彼らを口説く
　→現場の人は目先のプロジェクトを見てしまう
・社外勉強会をそのまま持ち込む
　→休憩の時間に見に来てもらう
　→→突然当てられることや怖いこと、そういうことはないということを知ってもらう

◇Fearless change
・人が取るアクションには理由がある
　→こういう組織はアーリーマジョリティが一番多い
　→→アーリーマジョリティを巻き込むためにアーリーアダプターをいかに巻き込むか
・流れが出来れば自然にいける
　→参加した人が、自主的にコミュニティを作ったりするように
　→各部門にバラバラにいたリーダー達に連携が
・大きな組織でもうまく巻き込めば仲間を見つけコミュニティを作れる
・社外コミュニティの情熱で社内に（小さな）変化をもたせる
　→パッション大事

◇なんで転職したか
・数千人が変わるのを待つには人生は短い
　→1割でも変わればいいかとおもった
　→→だけどそれも遠かった
・ユーザの声をもっと聞きたかった
　→大きい会社なので間に他の部門が入ってしまう
・カットオーバー後の話をする機会がない
　→そもそもチームが解散したりとか



◆今の会社

◇状況
・自社プロダクトサービスを作っている（ウェブブラウザ）
・職人肌のエンジニアが多い
　→毎朝にgithub3時間使う人とか
　→窓の社でノミネートされてるとか
・勉強会主催者もいる

◇やってること
・現在進行形で巻き込みしている
・3チームのスクラムマスタ
・部門の障害をやっつけたりもする

◇問題点
・ドライブ力が物足りない
　→職人肌の人は自分である程度の問題設定を作れる
　→→それを片付けることもできる
　→でもビジネスとかユーザが苦手
　→→そこの突破力がない
・開発プロセスが未成熟
　→個人は当たり前のようにテストなどやっている
　→→でも、組織としてみると俺々ルールが多い
　→方向を間違えなければいいところにいくのに…

◇入ってやったこと
・姿勢を見つめなおしてもらう
　→正解がない問題を自分達で考えるように
　→よいブラウザって？
　→→答えはない
　→→→使ってみて始めてわかる
　→仮説検証する姿勢重要
　→→そういう取り組みをするようにする
・フィードバックを正面から受けられるように
　→厳しいメッセージにも目を背けずに
　→→そこから一生懸命考える姿勢を
・透明性を維持する
　→朝会で自分のことを素直に話せる人ってどれだけいる？
　→→上司の進捗会になっていることが多い
　→→→それは朝会じゃない
　→自分でタスクを取り、周囲が助ける
　→→自分達で判断してやっていく

◇入ってやったこと
・ふりかえり
　→wikiにいろいろ書いてもらう
　→→書いてどうするの？
・テストコードがない
　→テストを書こう
　→→こんなの意味ない
　→→→こういうのを改善した
・タスクボード
　→redmineを使っていたけど…
　→→進捗はよくわからない
　→タスクボードを作った
　→→朝会に持って行ったりしている

◇姿勢を変えるために
・社内勉強会
　→『チーム力を上げる"朝会"のコツ』
　→プロダクトオーナー勉強会
　→ユーザストーリの作り方
・結果
　→自律的なチームになりつつある
　→チームのアジリティも上がりつつある
　→→まだまだこれからできることがあると思う



◆最後に

◇コミュニティについて
・様々な経験を持ついろいろな人達の集まり
・それをどう使うかは自分次第
　→話を聞いて終わるか
　→自分のコンテキストに合わせて使うか
　→使った結果からさらに相談したり
・仲間とめぐり合う部隊

◇何時に起きてるか
・22:00に寝る
　→3:00に起きる
　→→6:00に会社
　→→→9:30に始業

◇情熱はすごく大事
・でも1人で燃やし続けるのは難しい
　→周りを巻き込みように
　→社内にいなければコミュニティで
・巻き込まれてくれている仲間にThanks!

◇「ええと思ったらやっていこう」
・「もうこんな年だから…」「こんな状況なので…」
　→自分が勝手に作っている制約
・いいと思ったらその日から始める






中村洋様、CyberAgent様、DevLOVE様、ありがとうございました。

『スクラム道 EXPO 2012 - 午後のセッション』ノート - 2 / 2

2012/10/28に開催された『スクラム道 EXPO 2012』午後のセッションのノートです。間が空いてしまったので、パート1と2に分けました。

パート1はこちら


◆岩崎 奈緒己氏「分散スクラム」

オフショア & スケーリング（複数チームが連携してスクラム）について


◆海の向こうのスクラム（オフショア）問題と改善
・無理だと思う人たくさんいるのでは？
　→JIRA, Redmine
　→skype

◇問題：全員が映っているわけではない
・ビデオ会議なので起こる
　→誰が誰に話しているか分からない
　→こっちは盛り上がっているが、あっちは…
・解決
　→呼びかける
　→→「○○さんに質問です」
　→実況中継
　→→「○○がいます」
　→→「相談中だから待ってください」

◇問題：途切れる声
・「……が………の……………でいいですか？」
　→大事なときにこそ起こる
・解決
　→チャット
　→→話をしながら打つ
　→ビデオ
・会議用スライドを画面で共有する
　→アジェンダを写しながら話す
　→→その場でスライドに成果を書き込む
・直接行って会う
　→ぜんぜん違う

◇海の向こうのスクラムのまとめ
・特別なツールがなくても話し方やちょっとした準備で改善することが多い
・直接会ってどんな人か知ることが一番効果的（特に初期）


◆チーム連携（一箇所で複数チーム）問題と改善
・リリースバーンダウンを並べる
・全体の課題のためのボードを作る
・同期を作るためにマイルストーンのボード
・体制図

◇問題
・スプリント計画、レビューとか人が多い
　→合戦みたいになっている
・プロダクトバックログが大きい

◇2段階の会議
・多すぎる会議
　→基本はチーム単位で行うこと
・Scrum Of Scrumで連携
　→チームをまたぐ課題は別の会議体で

◇ストーリーマップ x バックログ
・1枚のシートに大量の項目・文字があったので対策
　→プロダクト全体をストーリーマップで表現
　→各チームごとのプロダクトバックログを作成
　→細かい受け入れ条件は別シートへ

◇スケーリングする場合のまとめ
・複数チームに関係することを話し合う会議体が必要
　→そうしないと「あのチームこんなことやってるの？」「聞いてないよ」とか生まれやすい
・各チームがプロダクトの全体像をつかめるような資料が必要
　→各チームが何やっているかは全体像があればだいたい掴める


◆崩れてしまったときの心の持ちよう

◇うまくいっていない場合
・みんなが「これでいいじゃん」で進めてしまった
　→「なんかおかしい。いや、絶対おかしい」となった
・オフショア・大規模だと問題が起こりやすいし複雑化しやすい
　→起こっても見えにくい
　→→チームではうまく行っていてもプロダクト全体では問題とか

◇止める
・そういうときは止めないといけない
　→まずはプロダクトオーナーに相談
・非効率なスプリントを中止する
　→冷静になりましょう
　→大きいものは小手先でやっても上手くいかない

◇消す
・でも緊急でやるべきことはやり切る

◇組みなおす
・情報を整理していく
　→大きなものから小さなもの
　→荒いものから細かいもの
・インセプションデッキが狂っているのにプロダクトバックログを直しても意味が無い

コンセプト
□□□□□□□□
□□□□□□□□
↓
ワークフロー・ストーリー
□□　□□　□□　□□
□□　□□　□□　□□
↓
タスク
□　□　□　□　□　□　□　□　
□　□　□　□　□　□　□　□


◇要求以外でも重要な情報は整理
・検討課題
・リスク
・周知、情報共有

◇1つずつ着実に行う
・みんなが見えるように
　→でも早く
　→→改善疲れが出てくるので

◇巻き込む
・1人でやっていても、周りがしらける
　→息が続くうちに
　→みんなが見放す前に

◇まとめ
・いかに状況を早く見える化するか
・いかに改善が目に見えるようになるか
　→それぞれ掛け算になっている
・プロセスを止めるのも組みなおすのも全員が疲れる
　→巻き込む気力とスピードが肝
　→引っ張るのではない

◇最後に
・『小さな工夫、大きな成果』が大事
　→大規模・オフショアって大きく見えるが、大事なのはちょっとした小さな工夫
　→→それを着実にやれるか
・できないのはそういう工夫を飛ばしているから
・誰がやるか
　→皆で
・ピラミッドになっていて「あの人が言ったからやる」ではない



◆上田 佳典氏「はじめての自己組織化」

◇自己組織化とは何か
・自分の言葉で説明できる？
　→脱コマンドアンドコントロール
　→タスクをアサインしない
　→クロスファンクション
　→優れたチームワーク
　→→いろいろある

◇ここで動画
・self-organization in hanoi traffic



　→信号がない
　→警官がいない
　→それでも自分達で状況理解・判断・行動
　→→外から指示されないというのがポイント
・『チームとして』最適な方法を自分で判断し行動すること
　→『自分として』ではない

◇どういう観点で考えるか
・ビジョン・ゴールを共有する
 →QCD + S
・長期的・短期的で考えることができる
　→ノウハウ共有
　→チームとPOの教育
　→→といった観点を踏まえ、自己判断で行動できるように
・全部インセプションデッキで話す内容
　→インセプションデッキを作って総合判断する
・デッキを作ったら放置でよい？
　→そうではない

◇スクラムマスター・プロダクトオーナー・管理職は自己組織を加速するためにどうすればよいか？
・補助輪になる

◇自分で考えて動くってどういうこと？
・自動車教習所で教わること
　→認知
　→判断
　→操作（行動）
・人が行動して失敗するときはこのどれかの段階でつまづく
　→スクラムマスター・プロダクトオーナー・管理職はつまづく原因を取り除く
　→→特に認知・判断をしっかりサポートする
　→→→ウォーターフォールの人に対しては特に重要

◇プラクティスで気をつけること
・朝会
　→個人のタスク整理ができていない
　→→状況と自分自身がやることを認知できていないから
　→朝会前にリマインド
　→→朝会前に整理するフェーズを入れられるように

◇それでも3つの共有事項がいまいちなことが…
・正直な思いを伝える
　→チームに共有事項の感想を求める
　→→そうやって自分の立ち位置を理解してもらう
・タスクを選べない
　→背中を押す
　→→「失敗してもいい。取っていい」
　→→→今まで失敗しないように仕事していると安全側に倒したがる
　→WIP(work in progress)の制限
　→→自分自身がやることをはっきりさせる
　→WIPがよくわからないならペアワーク
・プランニング
　→ストーリーの実装方法が分からない
　→→スキル不足
　→→消極的
・メタ情報の収集不足
　→プロダクトオーナーに聞けばわかることを聞けない
　→→請負根性
　→→スキル不足
　→プランニングで意見を求める（設計・実装・ストーリーポイント）
　→→「どう思う？」積極的に聞く

◇ポイント
・情報収集する
・自分で考える
・成長する

◇ふりかえり
・課題意識の欠如
　→KPTの希薄化
　→どこか他人事
・自分自身の成長戦略を立てられない
　→TRYがプロダクトの話ばっかり
・本音KPT
→本音で喋れる場をまず作る
→→楽天の藤原さんは、まずリラックスできる場を作るという
→期待を出し合う
→→「どうなって欲しいとか」お互いに求めるものをお互いに出し合う
・根本原因分析
→開発をやっているとじっくり考える暇がない
→→時間が無いならKPTせずにいきなり根本原因分析をするのもあり
→→→ゲームストーミングのSquid（イカチャート）
・じっくり考えることが重要

◇革新会議
・じっくり考える時間がない
　→でも重要
・成長するエンジンが欲しい
　→あればほうっておいても成長してくれる
・従来型の報告会議をビジョン・ゴールのメンテナンスの場にしてみた
　→自分の成長戦略を考える場に
　→→やり方はチームに任せる

◇大事だと思ったこと
・自橙明
　→釈迦が亡くなるときの話「自分で考えて決めろ」
・自分が明かりになって道筋を明るく照らす
　→自らが常に意思決定に関わるように

◇これまでのやり方が通用しないのは何故か
・他人が過去に決めた仕組みやルールだから
　→これからは状況に応じた"意思決定"自体が重要になる
・ソフトウェア開発でも適切なカードを切るスキルが求められる時代に

◇"答え"ではなく"答えを出す方法"を学ぶ
・でもそれだけじゃ足りない気がする

◇神々の意識改革
・お偉いさんの意識を変えてもらう
　→チームや個人を信頼し許可を与える
　→→そういう上司の一言と後押しは心強い
・神々からの支援
　→チームが解決できない問題を解決してみせる
　→→会議室の予約・組織をまたいだ勉強会etc.
　→→→社長に直談判して、社長を通して解決してもらったことも
・アジャイルのゴーサイン

◇まとめ
・チームとして最適な方法を自分で判断し行動すること
・観点
　→ビジョン・ゴールを共有する
　→QCD + S
　→長期的・短期的で考えることができる
　→ノウハウ共有
　→チーム・POの教育
・補助輪
・認知、判断、行動
・神々の意識改革
・信頼、許可、支援

◇最後に
「コマンドアンドコントロールからさよなライオン」

岩崎 奈緒己様、上田 佳典様、スクラム道様、ありがとうございました。