『実践リーンスタートアップセッション 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の教育
・補助輪
・認知、判断、行動
・神々の意識改革
・信頼、許可、支援

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

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

【チラシの裏】今日の送別会の帰り道に思ったこと

2007年の4月、社会人になって初めての給料をもらった週末、電車がなくなる時間まで飲み、そして歩いて帰った。

サラリーマンとして稼いだお金でお酒を飲んだというささやかな満足感とか、これから始まる社会人としての人生に対する晴れやかな気持ちであるとか、今日飲んだ同期の仲間達とずっとやっていきたいという希望とか、自分の世代が今以上に会社を盛り上げていくのだという野望とか、一生懸命勉強して優れたシステムを作るのだという向上心とか、いろいろな気持ちを抱えてワクワクしながら歩いた。社会人として成長していく自分のことを思うと、明日のことを考えるのが楽しくて仕方がなかった。

そして、本日付で私は会社を辞めた。明日から別の会社に勤めることになる。

昔の常駐先の職場の先輩が送別してくれることとなり、普段いかない場所で飲み、自転車に載っておらず、飲んでばかりだったので締めのラーメンが必要　…など、いろいろな条件が重なり、たまたま5年半前と同じ道を歩いて帰ることになった。

キラキラした何かを抱えていたあの日の自分と、その会社を辞めたという半ば冷めた気持ちを抱えている今の自分が同じ道を歩くという偶然に驚きながら、当時のことを思い出したり、今の自分に重ねてみたりしながら帰った。

やりたいことを貫き通すために会社を飛び出したのだという覚悟や、新しく迎えてくれる仲間の期待に応えることへのプレッシャーなど、今の自分には向き合わなければいけないものがあって、だから当時のような純粋で晴れやかな気持ちで歩くことはできなかった。でも、それは、自分が当時より少しは成長していることの証なのだと思った。


今までお世話になった会社の皆様、ありがとうございました。そしてこれからお世話になる会社の皆様、宜しくお願い致します。

『第4回テックヒルズ UI,UXの衝撃 ～ユーザーを魅了するプロダクトの裏側～』ノート

2012/11/07に開催された『第4回テックヒルズ　UI,UXの衝撃　～ユーザーを魅了するプロダクトの裏側～』のノートです。



◆酒井洋平氏 「開発者のためのUXデザイン」

◇UI/UXって？
・UXって？
　→ユーザエクスペリエンスの略
・UIって？
　→ユーザインターフェースの略
・なんでUI/UXで一括りなのか？
　→この状況は不思議
・ネットでも専門家がいろいろ書いている
　→でも、皆「ん？」という状態なのではないか？と思う

◇↑のあたりを整理する
・UXはユーザからみた主観的な経験
・UIはユーザの主観的経験を支えるための接点となるいろいろな道具
　→券売機、ATM、自販機など。

◇人(UX)　←→　UI　←→　システム
・人に属するものがUX
・↑を支えてシステムとつながっているのがUI
・これが同時に語られるのはどういうことかということ。
　→大事なポイント
・旧来、デザイナーはUIを大事に考えてきた
　→いまはUXについても考えないといけない
　→→それはUIがUXを支えているから
　→→→そこまで考えざるをえない状況になっている
　→だからUI/UXという表現になってきている

◇ユーザの主観的経験なのでデザインできるのか？
・個人の内面的なものだからできないと思われるが…
・そうではなく、ある主観的経験が想起されることを企図した設計と考える
　→多くの場合はビジネスとしてやるもの
・ユーザに"価値がある主観的経験"を想起させること企図した設計
　→"個人的には"それがUXデザインだと思っている
・この辺りは議論になっている
　→ウェブ上
　→各種専門家など
　→UX白書
　→→UX白書をググってご覧ください

◇ユーザって誰？　ユーザにとっての価値は何？
・この辺りをいま課題に感じている
　→ユーザって誰？どこにいる？
・見つけてきたユーザにとっての価値を真剣に考える
　→それをやらないとUXはできない
・今までのウェブでは数打てばあたるというところがあった
　→この辺は肌感覚でやっている人も多いのでは？
・どうやって見つけるか？
　→難しい

◇価値発見プロセス
1. 計測
2. 気付き
3. ベンチマーキングと観察
4. 脳内でプロトタイピング
5. ストーリーテリングで価値を訴える
　→このような活動をとおして新しい価値をもたらそうとしている

◇UXデザインをサマライズする
・あるUXの価値（ユーザにとっての価値）がある
　→それをどう発見するか？
　→どう実現するか？
　→→これがポイント
・具体的な価値が見つかったときにどうするか
　→部門横断的に価値に向けて動かないといけない。
　→→マーケティング・プランニング・デザイン・エンジニアリングなど…
　→UXの専門家がいるだけではどうにもならない
　→→全社的に理解してやっていかないといけない

◇展望
・マーケティングやプランニングなどの領域でもUXデザインと同じ考えを別の言葉で使ったりするのではないか
　→同じような活動が行われたり
　→同じことを別の言葉で指していたり
　→→そういうことが多い
・UXデザインの周辺ではその辺が整理されて全体統合的な流れが出てくるのでは
　→それが活発な企業から成功事例が出るのかなー


◆橋本建吾氏　「UI/UXについて 〜LINEの場合〜」

◇UX design ≠ UI design
・全然違うもの

◇理解を深めるために
・Janice Fracerの写真

from The Difference Between UX and UI: Subtleties Explained in Cereal

　→食器や食材がバラバラの状態
　→→この状態だとどうすることもできない
　→→これをプロダクト、機能リストして考える
　→これをスプーンで統合する
　→→スプーンはインタフェース
　→→カップにシリアル
　→→ミルク
　→→スプーンで朝食
・これはUXとしては原始的なもの
　→でも結果として空腹が満たされる
・もう少し上層的な考え方
　→牛乳の量をコントロールしてシリアルの質感を変える
　→砂糖やジャムで味を変える
　→→こういうのもUXのアプローチだと思う
・自分でもチョイスしてみる
　→日本食
　→木の橋
　→漆の器
　→陶器
　→→ユーザの感じるものがずいぶん違う
　→→同じ結果でも与える印象はずいぶん違う
・材料や素材のチョイスで結果が変わる
　→このチョイスがUIデザイナーの役割

◇UXとは？　UIとは？
・UXはユーザの感受であり体験
・UIは感受性を生み出す入り口、窓

◇NHN UX Designプロセス
1. simple
・NHNに入ってまず上長に言われたこと
　→半年くらい言われ続けた
・なぜUIにシンプルさが必要なのか？
　→様々なものが双方向的になっているから
　→→ユーザが参加するインターネット、という構造の出現
・ブログメディアの発展
　→素人の人でも情報が流通できる
　→→不特定多数の人間が情報を流通
　→非専門家による情報の供給
　→→シンプルなインタフェースが必要になる
 →→→誰でも使えるようなもの
・この考えはビジネスのデザインにも影響する
　→そういうデザインの方が強い
　→→0.5秒で持って帰ってもらえるようなもの
　→シンプルにUIを構築すると同時に、シンプルにバナー・広告も考える
　→→そちらの方がよい

2. Quick and Fast
・まず昔の一般的なワークフローについて考える
　→plan →> design -> develop
　→→ウォーターフォール的なワークフロー
　→工期が読みやすくて進行に有利
　→→でもプロジェクトのロールバックには弱い
・今やっている方法
　→UXがリサーチ
　→UIキャッチアップしてプロトタイプ
　→1回では終わらせずループをクルクルまわす
　→あるUIが完成したら開発にまわす
　→ここでもUXの方でデザインやインタラクション、ニーズへの満足度を検知
　→足りない場合は開発に戻す
　→これを半日とか一日単位でぐるぐる回す
・比較
　→ウォーターフォールはプランが無いと動けない
　→後者は起点がどこでもよい
　→→どこからでも回せる
　→→→クイックな開発・意思決定ができる

3. 意匠
・身の回りにあるもの
　→材質とか色など、ポイントを持ってものを選んでいるはず
・スマートフォン
　→→液晶などが進化していて非常に品質の高い表現ができるようになっている
　→毎日使うスマホのアプリにそこまで気を配っている人がどれだけいるのか？
　→（作り手も）あまり心血を注いでいないような気がする
・最近はUIコンポーネントがライブラリ・共有化されている
　→パーツを組み合わせればある程度のサービスができるということ
・差別化を図るには？
　→意匠を追及し、UXを高めていかないといけない
　→→特にUIデザイナが取り組まないといけない、という課題
　→→「ノイズを取り除く」
・流れや空気感を壊さないようなデザイン
　→画面上の情報のボリュームよりも
　→→そういうところにデザイナもコミットしないといけなくなってきている
　→→→「かんなをかける」と表現している
・「かんなをかける」
　→ざらざらした四角い木
　→→かんなをかけるとなめらかで気持ち良い質感になる
　→→→それはUIデザイナがやらないといけないこと
　→→→→そのためにはプロトタイプデザインを重ねていくしかない
・かんなをかけたUIはそれがごく当たり前のように見える
　→その当たり前に気付くか否かが重要
　→→だからプロトタイプを作り日々デザインする
・見た目や使い勝手に磨きをかける
　→そうすることで気持ちいいUXデザインができる

◇まとめ
・UIデザイナの選択の連続がユーザ体験を様々に彩る
　→一つ一つの選択の与える影響が大きい
　→→選択することに、より注視する
・使う人の立場、状況を踏まえデザインをシンプルに
　→シンプルにするのは怖い
　→→そこを踏み込んでいくことほどのUXのアプローチはない
・プロトタイプデザインを繰り替えす
　→そうすることで品質のでこぼこをなくす



◆坪田朋氏　「アジャイル開発におけるUX」

◇UI/UXについて
・UIって単語はイメージしやすい
　→議論の中で出てきても腹落ちする
　→でもUXは違う
　→→議論するときだいたい着地しない
・UXの定義をUX白書から引いてみた
　→「UXという分野は、システムの利用（あるいはシステムとの出会い）を通じて人々が持つ経験について…」
　→→なんど読んでも腑に落ちない
　→うまく言語化できないと思ってしまう
・UXという言葉が1人歩きしている
　→多くの概念を包括している
　→1つの定義で言い表せなくなっている？
　→→この言葉を使って議論することは危険？
・でもUXの意味を考えた
　→システムの利用を通じて人々が持つ体験
・UXって？
　→フレームはある
　→→タイムスパン
　→表すための要素もある
　→→ハニカム構造
　→自分で学んではき出していかないと身につかない

◇UXデザイナーとは
・自分はどう思っているか
　→イケてるプロダクトを作りたいと思っている
・ユーザーの立場を中心に考える
　→ユーザ価値のためにどうプロダクトを作ればよいかを考える
　→様々な方法論を組み合わせて課題・要求を解決する

◇イライラUIが生まれる理由
・最終的なプロダクトアウトはUI
　→なんでイケてないUIが出来あがるか
・ユーザニーズの不理解や市場の勉強不足
　→UXデザインで重要になってくる
・コミュニケーション不足やチューニング不足
　→UXデザインの後に出てくる
・これらがないと、イケていないUIデザインになる

◇Denaでの開発プロセス
1. リサーチ
2. 要件定義、UI開発
3. テストリサーチ
4. リリース
・これをループ
　→UXデザイナはこの全ての責任者だと思っている
　→→何をやるかを決めてチームを回すところまで

◇リサーチでなにをやっているか
・定量調査
　→アンケートを使って、数値化・グラフなどで表現したものを分析
　→→主観が入るところを定量化して明確に
　→→→いろいろな軸で切り取る
　→キャッチコピー・サービスの機能名・コア機能のニーズ・イラスト・キャラクターなど
・定性調査
　→定量調査で終えないものを追う
　→→実際に使ったときにボトルネックになっているものとか
　→→→スマホでゲームしているときの視線の動きなど
　→競合サービスに対しても使い、ヒアリングする
・競合調査
　→何が刺さっているかなどを切り出す
　→→ターゲットユーザー
　→→プロモーションマーケティング
　→→デザイン
　→→→設計
　→→→グラフィック

◇調査した後はUI開発
・要件定義やUI開発をする
　→要件定義は、何が課題で何をするかを決める
・まずはストーリー
　→それからUI設計
　→→ペーパープロトタイピングやワイヤフレームワーク
　→→→課題をどうUIで解決できているかを見る
　→使いやすさを考えるために実機でモックを作る
　→→HTMLやcssで再現
・違和感を感じた部分は何度も作り直す
　→必要かどうか迷った機能は落とす
　→→迷うような機能をユーザは使わない
・UIが決まったらGUI
　→どういうグラフィックにするかをデザイナと決める
　→→複数パターンを作る
　→→→チームやアンケートで採用する案を決める

◇リリーステスト
・プロダクトを始めて触る人が直感的に分かるようにしたい
　→ユーザに見てもらう
　→→テキストやアイコンなどの直感的な判断に関わるところを見てもらう
　→作っている側は慣れるので冷静に判断できない

◇リリース
・本当に受け入れられてアクティビティが向上しているかを見る
　→A/Bテストなど
　→→乱数・特定地域やセグメントなどで分ける

◇まとめ
・UI設計で重要なこと
　→徹底的な分析
　→→定量/定性
　→プロトタイピング
　→→実際に作る前
　→→→巻き戻りのコストを下げるため
　→→UIを決めてからGUI
　→ユーザーテストの実施と繰り返し
　→→盲目的になってしまったところを解決する

◇スクラム開発
・数年前から欧米で流行っているアジャイル開発の手法
　→上記のやり方をどう回すか？というところでスクラムを使っている
　→欧米では採用が多い

◇現場に求められていることは
・スピード
・スピード
・スピード
　→ウェブ開発では重要

◇高いスピードと品質を求められる
・マネジメントの期待する要求でスピードを出す
　→出した後は数字を求められる
・品質をスピードを達成しないといけない
　→スクラムだと品質とスピードが出せる

◇スクラムによる開発プロセスの最適化
・優先度・目的の可視化
・役割の明確化
・コミュニケーションコスト減

◇スクラムフレームワーク
・ストーリー
　→プロダクトバックログ
　→スプリントバックログ
・ミーティング
　→スプリント計画
　→朝会
　→振り返りとレビュー
・役割
　→プロダクトオーナー
　→スクラムマスター
　→チーム
・誰が何をやっているか、意思決定者が誰か、が明確化されている

◇スクラムについて
・ストーリーの書き方
「<サービス>においては、<目的>をしたい。なぜならば<将来の対象>は<現在の対象>に比べて<統計的事実>だからだ」
・スプリントは2週間
　→最初の月曜がプランニング
　→最後の金曜日がレビュー
・スクラムチーム
　→各人が専門（意思決定権）を持っている
　→→意思決定者が明確なので、コミュニケーションコストが減る
・チーム
　→UXデザイナ・リサーチ・エンジニア・UIデザイナなどに分けている
・スクラムではスクラムチームがまとめる
　→ディレクター制だとディレクターに集中してしまう
・チーム外のステークホルダーにはレビューで見せる
　→それを次のスプリントで改善する

◇ディレクション工程のシステム化
・Excelで線表を引く時間すらもったいない
　→ガントチャートはやめて朝会
　→アナログのタスクボード
　→→みんな自分で管理
・ミーティングは全員たってやる
　→タスク管理ツールはシンプルに
　→→タスクボード
・UIデザイン
　→パワポでワイヤーフレームから、チームでホワイトボードへ
　→→決まればデベロッパとGUIの人へ
・偉い人からの差し込み
　→基本的にはブロック
　→→レビューにまわして「次にやりましょう」

◇専門性について
・浅く広くではない
　→スペシャリストが作り、決める
・コンセプト・優先順位を明文化することでチームは自走する
・スペシャリスト同士のコミュニケーションに特化する
　→コミュニケ-ションコストを減らす

◇まとめ
・企画者は1人
　→事業管理している人
・サービスデザインはエンジニアやクリエイターの領域
　→彼らが作るのが一番早い
・UI設計はリサーチとテストがとても大事
・UXを考えないUIは時代遅れなのでは
　→リリースして終わりではない
　→→リリース後の効果分析を徹底的に行う
　→→→次に何をするかを決める






CROOZ株式会社様, 酒井洋平様, 橋本建吾様, 坪田朋様, アカデミーヒルズ様、ありがとうございました。

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

2012/10/28に開催された『スクラム道 EXPO 2012』午後のセッションのノートのパート1です。

パート2はこちら

◆高橋 一貴氏「スクラムマスター思い出語り」

◇アジャイルコーチをやっている

・自分は推進係

　→知らないところで好きにやっていたりする

・昔は壁に張り物がなかった

　→今は場所取りが必要なくらいになっている

◇スクラムマスターって？

"スクラムマスターは、スクラムチームとのやり取りで役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらうようにする。

スクラムマスターは、みんなのやり取りを変えてもらうことで、スクラムチームの作る価値を最大化するのである。"

 - (Ken Schwaber and Jeff Sutherland､ Scrum Guide)

　→みんなのやり取りを変えてもらうことでスクラムチームの作る価値を最大化する

◇最初はわからないことだらけ

・スクラムマスターについて

　→どこまで理解しておけば？

　→チームとの関わり方のコツは？

・どこから始めれば？

　→『塹壕より Scrum と XP』を読んだ

　→→今だと若干古いところがあるので注意

◇失敗

・Excelでスプリントバックログとプロダクトバックログを一元管理

　→プロダクトバックログのアイテムの下にインデントでタスクを並べる

・個人別にバーンダウンチャート

　→個人の遅れもばっちり把握

・フロントエンドとバックエンドでチームをわける

　→効率的な分業

・スクラムマスターがタスクをアサインした

　→抜け盛れを防ぐ

・レビュー完了はスクラムマスターが判断

　→確実な品質確保を

・詳細仕様をプロダクトオーナーに承認してもらう

　→外部仕様より先の話

・ミーティングはスクラムマスターがどんどん発言

　→進行も決定も効率的に

　→自分の意見もどんどん言う

◇こういうことをしているといろいろ変になる

・タスクの残量が把握できない

　→並べてあるから見える化

　→→全体量が分からない

　→→メンテナンスが大変

・遅れている人を問いたださないといけない

　→いつも遅れている人に余計なプレッシャー

・堂々巡り

　→「バックエンドが終わってないから画面作れない」

　→「いやいやフロントエンドが終わってないから見せられない」

・追加タスクが申告されない

　→バーンダウンチャートが増えるだけだから隠してしまう

・自分のところでレビューが溜まりすぎる

・POと話がかみ合わない

・チームから活気が消えた

◇どうなったか

・葬式のような振り返り

　→ミーティング全てお葬式に

　→→こんなはずではなかった

◇もう一度定義をよく見直した

・スクラムの理解と成立のために

　→皆のやり取りを変えてもらう

　→→スクラムチームの外側ステークホルダーに理解と行動を促す

　→→→個々の作業に関与しすぎるからうまくいかない？

◇やり方を変えた

・手法や環境へ働きかける形へ

　→作ったものや個人ではなく、全体的な視点で

・スプリントバックログは付箋とペンで

　→『塹壕より Scrum と XP』どおりにやってみた

　→→一覧性がぜんぜん違う。何が起こったかすぐわかる

・チーム全体のバーンダウンチャートのみに

　→チームを解散させたいなら個人別バーンダウンチャートがオススメ

・チームはクロスファンクションで組成し直し

・放置・滞留しているタスクに気付いてもらうように

　→「しばらく貼りっぱなしだけどどうしたの？」

　→→意外と話してくれる

　→→→フィードバックすれば自主的にやってくれる

・レビューはチームで完結

　→実施有無とレビュー観点のみ見る

　→後はチームに任せる

・詳細仕様は求められた場合のみ説明

　→プロダクトオーナーはデータベースとかに興味ない

・ミーティングへの貢献の仕方を変える

　→ゴールとアジェンダを必ず用意

　→→参加者に手伝ってもらうつもりで

　→進行のコントロールに徹する

　→→内容には干渉しない

　→→→"誰が喋るか"を決めては駄目。"誰から喋るか"を決めるのはよい

◇大事だと思うこと

・いっぱい勉強してやってみる

　→今はいろいろなところで話を聞ける

・『自分が信頼している人に見せる態度』でみんなに接する

　→ノーガードで飛び込んでしまう

　→→ガチで殴ってくる人はいない

　→チームの少々の混乱は覚悟しておく

・Be Nice

　→いい人のいいところを容赦なく真似る

◇変えられないものを受け入れる

・変えられるものは変える

　→そこはあきらめない

・判断できる力をつける

高橋 一貴様、スクラム道様、ありがとうございました。

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

2012/10/28に開催された『スクラム道 EXPO 2012』午前のセッションのノートです。


◆和田　卓人氏「ペアプログラミング ホントのところ」

◇質問「ペアプロすべきか？」
・答え「状況による」
　→それはずるい
　→→経験者としてそういう結論になるのはわかるが…
・ペアプロは議論を巻き起こす
・見た目も派手

◇ペアプログラミングって何？
・書籍「プログラマが知るべき97のこと」
　→「いかに周りの人とお客と仕事をするか」という中身が詰まっている
　→→プログラマは技術が優れいてるだけでは充分ではない
　→→他人との連携でより大きな成果が上げられるようでなければならない
・2人で1つのマシン、1つのキーボード
　→ドライバとナビゲータ
　→2人でコラボレーション
・いろいろなイベントではモヒカンが切りあう形になっている
　→それも面白いが…
　→チーム（ペア）でプログラミングするもの

◇ペアプロをやっている人の結論
・外国でやっている人も国内でやっている人（自分）同じような結論に至る
・やっている人とそうでない人ではイメージがだいぶ違う

◇ペアプロの利点
・規律の強化
　→1人だとサボったり、コーディング規約が億劫になったりする
　→→1人だと悪魔のささやきに負けやすい
　→→2人でコードを書いているときは天使の方が勝る
　→ペアプロ中ってtwitterやネットサーフィンをしない
　→→仕事モードになっている
　→→→仕事と休みのメリハリが付きやすい
・より良いコード
　→品質は上がっていく
　→→すぐ隣にそのコード使う人がいる
　→→フィードバックが非常に早い
　→→→それが良い効果をもたらす
　→ペアは最小のチーム
　→→シンプルさはチームが決めるもの
　→→→複雑なコードは書かなくなる
　→力技でこなす「動けばよい」みたいなコードも書かなくなる
・快活なフロー状態
　→1人と2人とでは深く集中した状態（フロー）が異なる
　→→ペアならではでのフローがある
　→→→1人のときとは異なるフローの状態に入れる
・チームの士気向上
　→ペアプロをすると部屋が無言ではなくなる
　→会話をしていくことがチームの仲の良さ
　→→情報が伝わりやすくなる
　→→→チームがよりよい方向に行く
・コードの共同所有
　→プロダクトコードに持ち主がいない状態
　→→少なくとも2人は知っている状態
　→「ある個人しか知らない」というのはない
　→→保守性が高まる
・学習効果
　→ペアプロはばらつきを一番早く吸収できる
　→→エディタ・開発環境・ネーミングなどなど
　→教える側は知識の整理などが必要
　→→教える側にも学びがある
・チームの一体化
　→チームが同じ方向に進むという方向付けがやりやすい
・割り込み削減
　→ペアプロ中の人には割り込みにくいという調査結果
・つまり…
　→教わる側は当然学べる
　→教える側は滅多なことは言えなくなる
　→→実は教える側の方が学べる

◇1人でプログラミングするのと、2人でするのとの違い
・最大の違いは"喋るか喋らないか"
　→この差は非常に大きい
　→→1人の場合、考えてコードに落として　…というのをグルグル回す
　→→2人の場合、声に出すので頭の中をもう一段整理しないといけない
　→Rubber Duckingという手法もある

◇機能しないとき
・管理者はハードウェアに投資したくない
・現場がペアプロに最適化されていない
　→机の並び方など
・現場では従来型の雇用方法を採用している
　→覚悟や適正など、ペアプロに向いたプログラマーを雇っていない
・現場では反社会的な行動を大目に見る
　→コーディング規約に従わない
　→ペアプロやらなくても「プログラマはそういうものだから」で看過されてしまう
・ペア作業の生産性が理解されていない
　→「生産性が半分になるじゃないか」という管理者の意見
　→→生産性は2割増しくらいになる
　→→仕様・スキルの伝達・Better Codeなどの生産性がある
　→ペアプロにはペアプロの生産性がある
　→→なかなか理解されない
・現場では的確でない開発者を雇っている
・現場は過労と人員不足に陥っている
　→「この期に及んで二人でコードを書くなんて」
・開発者は一緒に仕事をしている人達全員を好いているわけではない
・開発者はそのような面倒なことをしたいとは思わない
・たいていのソフトウェアの現場では、優秀さのことを本当は気にかけていない

◇ペアプログラミングをエゴの問題
・角谷さんとKent Beckさんとのやりとり
　→ペアプロするとき自分のキー配列とかの好みはどうする？
　→→「おまえの好みとチームの成功とで大事なのはどっち?」
・ワインバーグによるエゴレスプログラミングの十戒

◇ペアプロを入れるかどうか
・結局はIt depends.
　→気に入らない人という人も一度やってみると即座に気に入る（塹壕とScrum本）
　→→（結局）8割は気に入る
　→→それでも2割には通じない

◇ペアプロは楽しい
・楽しいのが一番
　→「楽しい」はものごとを前に進めるためのプリミティブな原動力



◆吉羽 龍太郎氏「Doneの定義 虎の巻（再演）」

◇出荷可能な製品とは？
・Doneの定義
　→実施しなければいけないことの一覧
　→→プロジェクトとして定めた『出荷可能な製品』を作るため

◇（個人的には）次の単位でDoneを定義したりする
・バックログ単位
・スプリント単位
・リリース単位

◇何が出来たら完了なのかを決めるもの
・どこまでやったら終わりかが分からずにやると…
　→悲惨なことになる
　→→だからゴールを決めてからやる

◇手戻り
・本人だけできていないつもりで延々と作りこむ
　→時間の無駄が発生
　→→（ex. 誰が見るのか分からないのに、一生懸命レイアウトを整える）
・本来やっていないといけないことをやり忘れる
　→セキュリティとか考えずにとりあえず作る
　→→後でセキュリティホールが見つかったりする

◇アジャイルな進捗の判断は0 or 1
・ウォーターフォールは80%などあるが、アジャイルにはない
　→アジャイルでは、できたか、できていないか
　→アジャイルは判断が必要ということ
　→→その基準がDoneの定義
・バーンダウンチャートの数字が信用できる理由は？
　→Doneの定義に従って進めているから
　→Doneの定義がないと見せかけの進捗でごまかせてしまう

◇プロダクトバックログの受け入れ基準との違い
・受け入れ基準とは
　→どこまでできたら終わりか？を書くもの
　→→機能要件適合性の判定のためのもの

◇体験談
・悪い受け入れ基準
　→『ソースコードが綺麗なこと』
　→→あやふや
・良い受け入れ基準
　→ソースコードをCheckStyleで検証し、重要度N以上の違反がないこと
　→→全員が合意できる
・変な基準を強制される
　→品質はコンテキストに寄る
　→→金融・医療・ウェブでは異なる
　→→→社内品質基準は顧客の期待と関係ない
　→そもそもゴージャスすぎる
・守っているかどうか判断できない
・そもそも定義の中身を知らない

◇Doneの定義を守れない理由
・なぜの分析が足りない
・別の圧力に負けれる（スコープの圧力など）
・チームがオーバーコミット
・そもそもDoneの定義が曖昧

◇どうやって改善するか？
・振り返りで改善
　→プロセスが改善されることでDoneの定義が変わっていく
　→1スプリント目と10スプリント目で同じなのは逆にやばい
　→→それは、従来のウォーターフォールの書き方を変えただけ
　→プロセスは自分達で変えることができないといけない

◇Doneの定義の更新
・自明のDoneは外す
　→チームが成熟するとでてくる
　→→もっと進むと『リリースのDoneの定義』をスプリント内でやれたりする
　→→→でもやりすぎには注意

◇Doneの定義の縮小
・気をつけなければいけないこと
　→明確に守れていないものを外すのはまずい
　→→本当に顧客の期待に応えられているかを考える

◇Doneの定義充足の検証
・Doneの定義を見ればチームの技術力がわかる
　→自動化できるものは自動で
　→→より本質的なものに時間が使えるようになる

◇Doneの定義をいつ決めるか？
・見積もりや契約の前に大枠が決まっているべき
　→そうでないと工数がぜんぜん異なる
・誰が決める
　→プロダクトオーナー + スクラムマスター + チーム
　→→プロダクトオーナーは外部のステークホルダーの声も聞く
・決め方
　→必要な作業を付箋に書き出す
　→実施タイミング(Release, Sprint, etc.)でグループ分け
　→リスト化して印刷して、皆が持つ

◇荒ぶる四天王
・品質は固定パラメータ
　→スコープ達成の圧力に負けない

◇大事だと思うこと
・プロジェクト開始時点で決める
・スプリントで全部やろうとしない（最初は無理）
・チームが成熟したら拡張
・品質は固定パラメータ
・途中で縮小しない
・自動で検証
・定義をみんな知っている


◆市谷 聡啓氏「Your Mind is the Scene of Development」

◇なぜインセプションデッキ？
・プロジェクトに然るべき人が集まっているかを確認
　→いないと後で話が変わる
・プロジェクトがしかるべき方向を向いているかを確認
・「チームメンバーが誰もいないところで合意したことを前提にしているからプロジェクトがダメになる(The Agile Samurai)」

◇インセプションデッキとは
・10個の問いから構成されている

◇いつデッキを作るか？
・プロジェクトキックオフ？　最初のイテレーション？
　→それでは遅すぎる
・契約前、予算取り前
　→検討する段階で作る
　→正しい制約を作るために

◇予算が確定した後にデッキを作るにしても、プロジェクトの前提は後からは動かしにくい
・だからステルスデッキ（受注前のインセプションデッキ）
　→前提を作る
　→目的に適した制約を作り、プロジェクトを開始する

◇プロジェクト開始前・開始後で進め方が違う
・開始前（ステルスデッキ）
　→ステークホルダーにはインセプションデッキとあえて言わない
　→→相手の期待値が上がる
　→あくまで制約をあぶりだすための仕掛け
・開始後（インセプションデッキ）
　→目的を明らかにして作る
　→→プロジェクトの方向を明らかにするために

◇インセプションデッキのCRUD
・Create
　→プロジェクト開始前と後
・Read
　→最初はデッキの内容のチームへの定着を図る
　→→週一回全員で点検するなど
・Update
　→デッキの更新はプロジェクトの方向が変わるということ
　→→その認識を併せる
・Delete
　→デッキが用を成さなくなったとき

◇ゴールデンサークル
・why, how, whatの順で考える
　→インセプションデッキの前半5枚がwhy
　→後半5枚がhow
　→ユーザストーリがwhat
・howが変わる
　→インセプションデッキに影響が及んでくる
・whyが変わる
　→プロジェクトの方向が変わる
　→→ステークホルダーが認識しているかを確認
　→→→プロジェクト全体で判断し合意する

◇インセプションデッキの弱点
・whoが弱い
　→エレベータピッチの「対象顧客向け」しかない
・whyを考えるためにはwhoは必要

◇エレベータピッチ
・whoの分だけエレベータピッチを考え、作る
　→ターゲットが複数
　→→ニーズが複数ということ
・複数ニーズに対してプロダクトは1個でよいのか？
　→そういう疑問をステークホルダーと話し合う

◇やることやらないことリスト
・いきなりやらないことを出すのは難しい
・目的
　→スコープを明らかにする
　→加えて、開発への期待を明らかにするためにも使える
　→→開発の苦い経験を明らかにしてもらう
　→→ここを見誤ると、この後の開発での相手の期待がわからなくなる

◇プロジェクトコミュニティ
・誰がどういう理由でソフトウェア開発に関与するのか、気付くのは案外難しい
　→顧客には顧客組織が分かる
　→開発は開発の人しかわからない
　→→コミュニティを明らかにする必要がある
・開発のよくある役割を確認する
　→顧客に過去の開発であった役割を思い出してもらう

◇重要なこと
・練習重要
　→本番は本番の結果を出さないといけない
・質問力重要
　→良質な問いかけがプロジェクトの行く末を左右する
　→→アクションラーニングオススメ





和田 卓人様, 吉羽 龍太郎様, 市谷 聡啓様, スクラム道様、ありがとうございました。