hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

DevLOVE200 Bridge に参加しきました

2017年6月18日に、表題のイベントに参加しました。

基本的にメモの内容をそのままのせています。それと一言感想です

誤りなどある場合もあります。。ご容赦を

新規事業が対峙する現実から エンジニアリングを俯瞰する

黒田 樹 さん
エンジニアリングマネージャー

オートスケールより殺しに来る力のほうが強い

開発の秩序を保つためにスクラム

どんなに開発チームがいけて
ボトルネックが開発からビジネスへ推移
ても、チームに行けてないものをインプットしてると価値が出てこない

従来のプロダクトバックログ
仮説完成型のバックログ
必ず仮説検証してから実装する

企業内での新規事業得意なのか?

海外事業をグロースさせてこいと言われた

なんだかよくわからない日本人がお前らをグロースしてるよ

バイスプレジデントの席に3DSがおいてあった
任天堂の国から来たことを見せつけた
ゲームの腕前を見せつけて「おまえすごいな」と

膨大なビジネス企画のシャワーを浴びる

経験した各フェーズでの立ち回り

事業が対峙する現実

エンジニアリングはどうすればいいんだっけ?

ビジネスモデル わからないよというとき

どこで売り上げが発生しているか

エンジニアの書いたコード上で立つか? そうでないか

成果課金型の広告

深堀していると画面遷移がある
if bookedのロジックに入ったら ちゃりーん

そうすると離脱率をさげる
KPI CPA

エンジニアが成長貢献になりやすい
数値目標を持ったプロダクトチームがジャンジャン改善サイクルをよいパターン

アウトソースやってる会社 内製
どうやったらいいの?

そこのビジネスモデルのエンジンは何なのか?
営業に最適化されたエンジンになっている

AARRRモデル

Acquisition
マーケ、営業

売上、 CV >= CVR(プロダクト)
マーケ側 プロダクト側

コード上で売り上げが立たない場合

純広告
CVRの改善 は 次回発注への信頼獲得

売上 > CV >CVR(プロダクト)

いけいけなコードなどいくらでも活躍する場合がある

でもドメインコモディティ化 ビジネス貢献が可視化されない

エンジニアはコスト削減や生産性向上のような、ビジネス指標からは程遠い目標設定になる

守り中心でも攻めの要素があるよね

勘所

ビジネス戦略やプロダクト戦略

ビジネス貢献するとおもってやってることが実はそこまで重要ではない場合

前提の書き方が間違っている

目的意識はもってるものの ビジネスと目的がすりあっていない

ビジネス側とひざを突き合わせて語り合いお互いを理解しあうこと

目的に忠誠を誓う

目的に対してのIT戦略
SOE, SORの共存

SOEかSORかの2極化になりがち
チームのCaperbilityを考えよう

https://martinfowler.com/bliki/BusinessCapabilityCentric.html

過度な原理主義

それぞれの方法から光を当ててみる
2軸でグラフを作っちゃおう

戦略や各種優先度

ビジネスフェーズからエンジニアリングを見る

ビジネスフェーズ
検証する
顧客発見フェーズ

魅力発見

顧客実証フェーズ
当たり前品質 買ってもらうには性能も商品レベル

顧客開拓スケールフェーズ
すべてを振り切っていく

ビジネスフェーズ(アーリーフェーズ)
職種を超えたマルチロール型
一緒に企画を考える
なんでもやろう

顧客実証フェーズ
エンジニアの中でフルスタックエンジニアリングでやろう
数値を上げるためにはどんなエンジニアリングでもやる

顧客開拓
セグメント

何でもやる -> クロスファンクショナルに フェーズで推移

DevOpsやりましょう

柔軟にやりましょう なのに 予算一年でろっくしてるじゃないか

年次予算計画の圧 ウォーターフォール型に注力されてしまう

行動様式
自分流の行動様式

それぞれの特化された領域 それぞれの光の当て方に特化しちゃっている
顧客開発、リーン開発、リーンUX など並行に 思考実験が必要

真の目的を理解して それらを複合的に利用する

制約理論やFlow Efficiencyが全体を照らしている

リソース効率性とフロー効率性

リソース効率
稼働率は100パーセントにしやすい
働いている感は出やすい

フロー効率

This is Lean という本に書いてある

フロー効率

全員の机に一時置き場(書類受け)をつくる
大量の待ちタスクができる

1個のタスクが届くまではすごく長くなる

100パーセントの利用率の高速道路は駐車場と一緒

走っている最中に靴紐は結べない

コード上でチャリンチャリンいうモデル

基本的にフロー効率をあげる

同期するようなタスクを減らす

でっかいサービスのアプリチーム
アジャイルウォーターフォールが混在している

各部門が外側にある マーケ企画営業分析
SOR ウォーターフォール 
SOE アジャイル

SOR
リソース効率

フロー効率
ー> CCPM

UIUX改善
フロー効率
一こ流しを目指す

ビジネスを考えいて提案 受け入れられない
前提が間違っている

開発手法は手段
我々が忠誠を誓うのは目的

感想

コードが直接お金を生んでいるのか、いなければどうするのか、ということは今の現場に当てはまることだ。
守りの中でも攻めがある、という姿勢なんて本当にできるんだろうか? リーンでもアジャイルでも制約理論でも光の当て方がちがうなら何回でも違う方向から当ててみることをしたい

ソフトウェア開発の中心にあるのは『情緒』である

新井 剛さん

組織の壁 疲弊

アジャイル推進会
現場集め

ハイタッチする 最高のプラクティス

共感 のっと 問題解決

透明性がすごく大事
カンバンとか見える化

多忙表明 ニコニコカレンダー 手伝ってもらえる余裕

もやもやボード
言語化すらできないことをぽんぽんはる

データ更新の管理 国盗り合戦 地図で

レゴバーンダウンチャートを作る

いと楽し作戦
ワクワクする会社いっぱい ザッポスとか

宮本さん
人材交流

つながり作戦

会社見学ツアー
来ていただいている

メリットは会社のブランド強化
ファン
働いている環境を見てもらう

コミュニティの人たちとつながっていることが重要

アジャイルコミュニティへの恩返し

社内編(スライド参照)
すごい勇気づけ

いろんなことを会社のホームの文脈で話せる

喜びのほうがなぜいいんですか?
喜びながら働いている社員のほうが生産性が高い

新井さんが有利な点 役職

ワクワクする会社を目指す
ハッピーチームは生産性が高い
モチベーションよりもハッピーを目指すほうがいいんじゃないかな

悩み 人間関係
マネジメントは人である

エンジニア 理屈っぽい
同意はするが 感情が

知識を信じるしかない。。。

「情緒」

岡潔さん(数学者)

田畑を耕しながら数学をやってた
生涯で10篇の論文

「数学の中心にあるのは情緒である」

数は5感で感じられない

実態がないのに先にわかろうとする 分析過多

論証主義

日本文化では経験として知っていることを重視していた

理解は対立的にわかるのであるが「体取」は自分に取り入れる

数学も一緒

心を攻めていく

計算する能力 推論の能力すすんだとしても
他社の心を理解することが必要

クリエイトする力が未来のカギ
U理論
7つの習慣
学習する組織

同じことを言っている

逆説のスタートアップ思考

やりたいことはやってみないとわからない

始めるから情熱が生まれる
情熱があるから始めるのではない

内面からスタートするしかない

妄想する
発見が後からついてくる

自分が観測できる範囲を徐々に徐々に増やしていく

次の時代

誰もがこの働き方を気にいるわけではない

仕事は喜びにつながる
つながることが喜びにリンクしていく

DO Agile Be Agile どっちでもいい

その昔えきすぱぁとがなかった時代 紙の時刻表

ITで時計の針をちょっとでも進めたい

たどり着く場所 ないかもしれない
数学者 自分の人生の中でその論文が解けるかわからないけど必死こいてやっている

ソフトウェア開発
人と技術と文化が織りなす

感想

Do Agile, Be Agileどっちでもいい、かー。
逆説のスタートアップ思考でも「始めるから情熱が生まれる」という言葉に着目できていなかったなと思う。
ちゃんと始めなければ、と思わされました。

CROSS∞BORDERS 越境の果てに辿り着いた彼岸、さらにその彼方へ」

鍋島 理人さん

キャリアの話

ぬーらぼ バックログ カスタマーサクセス担当
4月ジョイン

翔泳社
DevLove Co founder

越境を愛するようになったか

翔泳社 2番目の職場

ゲーム会社のサウンドクリエイター

未経験の広告営業職

逃げとか迷いが前職へ導いた

コミュ障なので大変

営業と制作の相互不信
潜在的には合った

広告業界リア充オーラにあてられる

地道にこつこつ

予算
上限に対して行動目標
振り返りを行う

営業と編集の間
どうすれば喜んで仕事をもらえるか

圧倒的感謝

越境という言葉と出会う

違いを超えて目的を探る

ロールモデルがいた

デブサミの母 岩切さん

一番大切な贈り物
コミュニティに参加できたこと

ジェダイマスターではなくシス卿のイメージ
岩切さんが越境を体現 それを体験

エンジニアの祭り

世はまさに大エンジニア時代

デブサミのビジョン(スライド)

心は常にエンジニア
いろんなコミュニティ いろんな思い

場の理論
場へのコミット

越境をエナジャイズする場

テクノロジーが社会のためにできること
コミュニティを超えた連帯
東京一極じゃない 日本のそれぞれの場

デブサミの志を「だんだん」自分事化できた

転機2
世界ってひろーい
たーのしー

BPStudy
エンジニアコミュニティが培ってきたナレッジ
エンジニアコミュニティが企業をドライブする

Joyinc

人はみな自分の時間の投資家である

世界は何が起こるかわからない
やり残したことがないように悔いなく生きていこう

ご飯でも食べに行きませんか?

ぬーらぼ

社員60人
海外8拠点

エンジニアコミュニティがそのまま会社に

作ってるツールが絶え間ない越境を可能にしている

日本の会社のひとつの可能性を見た

感想

自分たちのプロダクトで戦ってみたい、ていう気持ちがあったんじゃないかなぁと思う
デブサミの志を「だんだん」自分事化できたっていうのがすごくよかった。

SIerの中心でSIerを語る

TIS
川島さん
大虎ぶる

会社の公式な活動
Qiita

実質一位

Devlove2008年くらいから

2010年くらいからスライドシェア
定年してから勢いが増している

定年を機にGitHubを使い始めた
定年超えてからプログラムかく量が増え始めた

PCの移行の時
プライベートで残していたノウハウやコードも断片的で使えるものになっていない

定年してからの活動
全部残っている

人の目にさらし、すぐに使える状態にしておくことにもっと気を使ったほうが良い

Sierとは何か?

SIerは技術力が低い?
LTフリースタイルバトルへ

Sierの生きがい

いろんな要素技術に携われる(かなり自由に選択できる)
かかわる人の多さ
圧倒的感謝を得られる

SIER最大の問題

隣のチーム・部門とやっていることが違いすぎてサイロ化しやすい

客先常駐などにより別の部署・チームとの交流が得られない

自分だけに対するインパク
ツールによる自動化で楽をする

公開しにくいVBAはやめておこう
先々の資産 使えるツールを開発

OSSを作り業務で使う
GitHubリポジトリ
区分けして作る

JP1 クラウド展開すると金がかかりすぎる
ジョブコントローラ

自由は作れる

外で話題にして顧客
部内に持ち込む

技術力はコミュ力を超える
世間話をしなくても お客様の言っていることを理化して解決してあげる

社内勉強会 どんなに頑張っても意識高い系しか巻き込めない

Advisory Team
部門をまたいで話ができるようになった

社内のソリューションを自分の持ちネタに寄せれるようになってきた

課題と出会いの多い職場で働くのはエンジニアの成長機会に事欠かない
35歳で定年している暇はない

感想

35歳で定年している暇はない、という言葉が良かった。
実のところ一番考えさせられたかも

モブプログラミングを通して見たアジャイルの真髄

及部 敬雄 さん

エンジニアの立場で

Why, What

複数の現場でやってきた
再現できる自信がある

ビジネス、エンジニアリング、チーム

自分の得意な エンジニアリング、チームから初めて
ビジネスに切り込む

そこまでできれば早くいきたい

モブプログラミングという働きかた

チームで一つの画面

常にモブプログラミング
もぶへのではいりはじゆう

プラクティスではなく働き方
志村-うしろうしろげんしょう

おかしをおいていく

達成感がある
使えるけど楽しい

やってよかったこと

生産性 スピード 相対的スピード
はまっても最小限
後追いコミュニケーションが減る
集中してやったら疲れる 定時に帰られる

やることモブしかなくなる
振り返り レビュー 常にやっているので定期的にはやらない
全員でダメだったらしょうがないと思える

心理的安全性
終ったらやったーといえる
ノウハウ スキル
全員が知っている状態で進む

動くプロダクトに常に集中する
チームの中心にある モブ自体が仕事の中心

アジャイルソフトウェア宣言のアジャイルゾーン(右側)

分担することを前提にしすぎている アジャイルでもウォーターフォールでも
仲間と一緒にやったーといっているか?

誰もがこのやり方を気にいるわけではない
一緒に働く人どんな人がいい?

一緒に影響してくれる人たち 戦友

モブプロはどうでもいい
DevはLoveですか?

感想

確かにピュアなアジャイルアジャイルソフトウェア宣言の右側だと思った。 同期がいらなくなるモブプロいいよな、って思う。 この話聞く前は、すべてのカイギをモブプロにしてみたらいいんじゃないかとか考えていた。
あと、楽天さんだからできるんでしょ、に、はいそうですと答えるのがいいな 一緒に働く人が最高である、そのために自分も最高であるのを目指している状態になりたいですね。

”越境”することを伝える現場コーチ自身の”越境”の話

中村洋さん

自分の越境の話

ミッション:「正しいものを正しく作る」現場を増やす

ある程度整ってきたら 背中を押してあげるだけで解決できるように

越境をできるようになるいこと

今は難しくても学んでいくことで越境できる
何か学んでいないと2回目、3回目で越境できない

前提や制約を置かない
ハンコ 予算 経緯

目的に忠誠を誓う
レンガを積んでるんですか? 境界を立ててるんですか? 祈りをささげられる場を作っているんですか?

目的のためなんでもやる
できないのは仕方ない

デザインの邪魔者は捨て去る

えっきょうする

できることが増える

武器を取り換えるではなく 武器を増やす

それまではモノづくりしか見えない ユーザーの風景 がみえる

客先常駐
自分がどこの所属会社かわからない

業務を知ろう ビジネスを知ろう
ビジネス課題

営業が案件をとってきて、、、みたいな状態から
交渉ができるようにすること

巨大組織の巨大プロジェクト
発注者からその先のユーザーの声 まったくわからない
小さいチームを作った
大きな案件は花形扱いだった
小さい案件だからこそチャレンジブルな人が多かった

お客さんではなく、使う人のことを考える

良いバックログ
「ユーザーの何割かがこういうことを言っています」
悪い
社長が言っています

えっきょうすることにフォーカス

自分なりの越境のやり方

やりたいこと やれること やるべきことを知る

ガッツとパッションがあることをまず見つける

機会と経験
まず、どれだけ自分で取りに行けるかが大事

経験からどれだけ学びを取り出されるか

発見がないなーと思ったら越境先を見ていくことが必要

感想

耳に痛いことを言ってくれる存在で、銀河英雄伝説のムライ中将を思い出した。
オライリーのデザインスプリントにあったように、好意的な懐疑論者であることが重要なんじゃないかと思う。

経験からどれだけ学びを取りに行けるか。。

発表内容とは少し離れるが、直近で気がかりな質問をぶつけてみた。
「チームでスクラムをやっていて、わりと漸進的にスクラムのプラクティスが導入でき、チームのモチベーションも高まっている」
「ただ、チームがお互いにスクラムの導入などに最初から合意できていることが理由ではないか?」
「豚として身を差し出さない上からの意見や、もし新しく入ってきた人に一緒にバスに乗ってほしくない人が来たらどうすればいいのか?」

チームの目的を話し合ってみて。
そこからの自然発生的なワーキングアグリーメントが存在しているはず
そうすれば自分たちがどんな人と一緒に働きたいのか、
逆に働きたくない人がどんな人なのかが可視化、明文化することができるはず
そうすれば自分たちはこんな感じにやってるので、チームに入っていない人にも「自分たちはこういう考え方で、こういうやり方でやっているんだけどどうですか」といえるだろう。

DevLOVE 立ち上げから学んだ、サービスを創り育てるということ

竹本 和彰さん

DevLove Co founder

得意技
スタートアップ 新規事業での開発

DevLove立ち上げ 一緒に見ていた目線

どういう風に巻き込まれたのか

スタートアップでゼロイチ

RubyKaigiの帰り道に

開発って楽しい? 楽しい
たまたま隣に座っていた

Rubykaigiの帰り道に至る前の話
越境への準備の話

  • なぜそこにいたのか
  • なぜその話になったのか

TISカイギ 社内版のデブサミ
マッシュアップアワード

TISカイギ
なんで手を挙げたのか?
おもしろそうなめんばーがいたから
ワクワク感があった

できたこと
部門の壁が大きい

マッシュアップアワード
藤原さん
並河さん
竹本さん
それまでサービスをチームで考えるという機会がなかった

すごい人たち
別世界の人ではない

開発は楽しい

社内読書会
社外の人も入ってきた
その回からDevLoveになっていた

漢訳者を呼ぶ
読者だけの読書会を超える

コミュニティ自体が越境していく
普通のエンジニアだった 越境していくことがすごく普通のことになった

何が自分の中で変わったのか あまり覚えていない

システム開発が自分の仕事

サービスを育てることが自分の役割

リフォームのマッチングサービス
多重下請け構造
SIERで経験していた

エンジニアができること
プロダクト開発、だけじゃない

何が目線として変わったのか 役割として変わったのかがこの辺

「生産性の高い組織づくり」

感想

2008年のRubyKaigiの帰り道の話は目にしているけれど、その前夜の話はあまりしらなかった。 エンジニアができること
プロダクト開発、だけじゃない
100パーセントできることをやっていきたいなと思った。

時を超えた越境への道

市谷 聡啓さん

Guildworks
チームのレビューが顧客・関係シャットのスプリントでもよりもはるかに厳しい

当事者の人より 当事者らしい目的を持とうじゃないか
ふわっとしたことから始まることが多い

目的に対して コミット、共感しないとたどり着けない

クライアントワーク 自社開発ということがいいわけに使える というのは気のせい

忠誠を誓うのは目的

目的のために目的を問い続ける
本当にそれでいいのか?

どこかでまちがってしまうことがある

一行のコードから、事業戦略まで
さかのぼっていけばいくらでもさかのぼることができる

大げさな話ではない
関係者のこうなってほしいという思い

考え方と活動
越境すること そのもの

2006年
塹壕の中 隣の部署 わからない

追い込まれていた
2007のデブサミ
特別なデブサミ
Rubyアジャイルの話
Rubyアジャイルでなく、これすげーなー そこにいきたい

どこからか現れる救世主を待つほど人生は長くない
自分たちでやってみる
社内版のデブサミTISカイギ

Repeat Dath March
生死の世界
本当に健康を害したりするから笑い話ではない

2008年
自分たちの好きな技術でいいものをいっぱい作るぞーみたいな人たち
正しいものを正しくつくりたいんだ、ということに立ち戻った

2人で始める安心感
なんかやろうとしたときにまわりにひとがついてきてくれるのかな

最悪一人ぼっちにならないで済む

ひとつ大事にしている考え方
自分が経験してないことを 見聞きして

稲作、一生かけて、たかだか60回
ソフトウェア開発 たかだか300人月

HangarFlight
どういう時にどう飛べば安全だ
格納庫に集まって話し合う

無謀な開発を止められない
ビジネスモデルの限界

たちどまったほうがいい
でも、会社にとっては対価を得られない事態になる

正しいものを正しく作りたい、といことに立ち戻った

当事者意識の境界を超える

越えるべき境界はそれぞれに違う
目的をとらえられている限り、境界は越えられる

越境 一人で突き進んで回り誰もいない

周りの人も巻き込まれていき 結果としていい方向に向かう

安定と混沌の

越境のための視点と技術

どこからどこを見るか

どこから?
意思決定 
プロダクトの目的から考えていく

目的の高さを視座という
同じ範囲を見ていても視座が変われば見えるものが変わる

視座が高ければ高いほどいい というわけではない
視座が高い、視野が広いところから 低い、狭いところを行き来できることが重要
可能な限り早く

実験とフィードバックによる調整
よくわからないことについて決め打ちでやるわけにはいかない

仮説検証 アジャイル

リーン原則とアジャイル原則

指し示す指ではなく 指の示す先を見る

ときどきによって必要な原則をもってきて 光を当てる

越境は孤独

プロフェッショナルは励まされ、動機づけられたときに、最高に実りのある仕事をする

Enagile

クラウドエナジャイズ
越境支援

感想

8年越しの再会、再開という話と2人の安心、という言葉が響いた 最悪2人に戻るだけ 共同創業者がいることがどれだけ心強いことなのかということがよく分かった。 目的のために目的を問い続ける「本当にそれでいいのか?」というのもすごく印象的。

越境していく、ていうのは目的のための自然な動きにすぎないかなぁと思った。 どこまで当事者になれるかということが、どんなことでも大事だと思う

Djangoで特定のmigrateをやったことにする

メモ

別のブランチでmigrateを実行したあとに、もとのブランチでmigrateを追加してやろうとするとエラーになることがある

django.db.utils.ProgrammingError: column "expires_month" of relation "profile" already exists

そういうときは、特定のmigrationファイルやディレクトリを指定して、fakeオプションを使って実行する

python3 manage.py migrate --fake auths/migrations/0009_hoge.py

docker-composeと組み合わせるとこんな感じ

docker-compose exec app python3 manage.py migrate --fake auths

リーンに、スモールチームでものごとを進める意味

Harvard Business Review 2017 4月号にのっていた三枝 匡さんのインタビューを読み直して、以下のようなことを考えた。
他にも、リーンスタートアップの本や以下のリソース効率についての記事も参考にしている

i2key.hateblo.jp

リソース効率やフロー効率についての考え方や、リーンの意味についてはまだまだ勉強中なのと、実践も足りなすぎるので誤りなどがある可能性があります。

トヨタ生産方式については、エクストリームプログラミングや、リーンスタートアップといった書籍でも言及されている

在庫を減らすことではなく、「時間の価値」つまり「フロー効率」を追求している

人はみな「リソース効率」を求めがち。 機械や人の稼働が100パーセントに近い状況、Googleカレンダーのスケジュールがいっぱい埋まっている状況がリソース効率が高い状態。

よく言われるたとえ
CPU使用率100%のコンピュータを使いたいと思うだろうか?」

リソース効率を追求すると結果として在庫がたまって、停滞してるところが出てくる。よくない。

フロー効率は、1個単位の製品の生産で見たときに一番速く生産ラインを回すための効率。
必然的に、製品が生産や改善をされないという待機時間を減らすことが優先される
たぶんここまではわかりやすいけど、その次が意識がついていかないかもしれない。

1個流しの生産フローがフロー効率を最大化する。

トヨタの生産方式の理想的な想定では、問題があったときに全体のラインを止めてでもラインに関わる人全員で改善を行う「アンドン」が実施される。
「アンドン」はリーンスタートアップで、名前付きで言及されている。

「モノ」や「儀式」を考えた生産のサイクルは次のようになると思う。

  1. Plan
  2. Product increment(出荷可能な単位の製品の増分)をつくること
  3. Metrics(メトリクス)あるいは顧客の声のチェック
  4. Retrospective(振り返り), Adaptation(適応)を行うこと

このサイクルをまわすのに一番速くなるのは「1個流し」。
複数のものを回すと最適化などに労力を取られたりするから、ってのもあると思う。

フロー効率を追求することは「時間の戦略」でもある。

製品の待機時間を減らすという意味で。

「1個流し」を実現するためにはスモールチームのほうが勿論いい。
チームにリーダーがいて意思決定や、決済的なことまでできることはすごく重要。

「競合」「顧客の声」にたいして、チームが敏感になることができる。

ここが、「リーンに、スモールチームでものごとを進める意味」ではないだろうか?

それ以外の問題

スモールチームを目指すだけだと、組織全体の事業などとのシナジーが薄くなる、といった問題も出てくる。
その先の話は三枝さんのインタビューを読めばよいかと思う。

Y Combinator のオンラインスクール採択者が語る "Startup School" の教えと学び

書くの遅くなりましたが、2017.05.15にあった表題のイベントを聞きに行ってきました。

atnd.org

ツイートのまとめはこちら

togetter.com

イベントの内容としてはYCのオンラインスクールに参加された2組のスタートアップの方に、主催の馬田さん(『逆説のスタートアップ思考』の著者)が司会となってパネルディスカッションと Live Q&Aを行うという形式です。

質問自体は会場の方からSli.doというサービスで募集されていました。

www.sli.do

メモ

※ 誤りなどがあればご容赦ください。

Mike Eidlin (Perapera Inc CEO) さん

シリコンバレーの最新ニュースやブログが日本語で読めるクラウドソーシング翻訳サービス「Perapera」を運営。

ペラペラ (PeraPera) - シリコンバレーで話題の記事を日本語でお届けするメディア

Kaya Onda (Founder at cocotrek) さん

世界中の人々が、グローバルにおける活躍のオポチュニティが得られるように、キャリア開発用のプラットフォームを開発し、非公開β版で運営中。

  • マイクさん

ペットのSNSの資金調達が当初の来日の目的だった
日本でシリコンバレーの情報をどうやって得ているのか調べたら、あまりにも手段がなさ過ぎた。
自分でキュレートと翻訳してみたら、そっちのサービスのほうがいけるんじゃないかということでピボット。

「ユーザと話せ」
ユーザと話すために1月に引っ越した

  • おんださん

カーネギーメロン大学
だれでも参加できるコミュニティだった

アメリカにいるときに感じた 世界中のトップの人が目指す オポチュニティ スタートアップに限らず

アジアにいる人たちに紹介する 日本にあるオポチュニティを自分のネットワーク(中国、アメリカ)に紹介する

十数人のアーリーアダプター

スクールを知ったきっかけ

オンラインビデオの授業 スクールがあってメンタリングがある YCombinator

何となく前から知っていた。

3,4回くらい応募していた。
アプリケーションするだけで自分の会社のことを考えられる

YCSchoolまたやるのでアプライしたほうがいい

おすすめの講義は?

一つはWhatsappのファウンダーの話

もう一つはアドラー? と 名前忘れたけどファウンダーのかた

ファウンダーのバックグラウンドやスキルに影響される

  • Whatsapp

先に物を作っちゃった
電話にでれるかでれないか みたいなアプリ
全然受けなかったけど、ユーザーの声を聴くことができた
それでピボットすることができた

「ユーザーと話せ」
「人がほしがるものを作れ」

起業家として(顧客の話を直接聞くのは)すごく難しい
人と話すことはめんどくさい

カフェで話す 「火曜日はダメなので水曜日にしましょう」みたいに何が何でも話す

「スケールしないことをやれ」

スタートアップが強いのはスケールしないことができるから
いっぱい動画見ているとパターンが出てくる
Dropbox, Airbnb なんで大きくなったか?

talk to user too much

新しく気付いたこと

企業とは伸びないといけないのにどうやってスケールしないことをやるのか
ユーザーと話すのは何を作るのかを分かるため
わかったら 作れ 出せ
トラクション がでないとき ユーザーと話せ

自分のPeraperaのメトリクス
リテンションいまいちだな、というのはわかっていた。
疲れててユーザーと話したくなかった

でもユーザーと話した
「このボタンが良くない」 「オンボーディングのフローが良くない」
ということがわかった

スケールしない中でも明確にKPIを決めたほうが良い

KPIステージごとに変わる

KPIを決めないとだらだらしてしまう

(質問: KPIをYCのメンターからきかれるのか?)
毎週アップデートをださないといけない

毎週出す YCがいっていること 決めたメトリクスが毎週10パーが伸びていたら当たってるね

YCのメンターは マジックじゃなくて簡単なことを言ってくる オンラインとかウェブで言われたり、書かれていること

だが難しい

周りの人
なるほどな、すごく勉強になる

一番重要だと思うメンタリング

  • 早くローンチしろ
  • プロダクト出したものからフィードバックをもらえ

プロダクトマーケットフィット

実はトラクションが直感的に感じられる

ユーザーから返ってきたもので感じられる

ホロヴィッツが話すPMフィットについて
市場があなたのプロダクトを引っ張ってくるくらいわかる
自分の頭が火山のようになった人たちはレンガを頭にやったらとけてそれをこねて柔らかくできるくらいである

リードホフマン
恥ずかしかったとしてもすぐ出せ

YCのいいところ
フォーカス
何が大切か?
やらないことを選ぶ
毎週10パーセントあげろといわれる
一つだけメトリクスを選んでそれを10パーセント上げる

力のフォーカス サービスのフォーカス
あれもこれもやりたくなる
スタートアップにはそれをやる体力はない
「フォーカスして MVP」

毎週火曜日の夜以外は会わない 怖がっていくか 10パーあがってうれしく行くか

3か月でやっていること 結構自分を追い込んでいる
その状態を続けられたら

メトリクス毎週10パー続けるメトリクス難しい
同じグループオフィスアワーに投資家が入ってくる
どうやって10パー続けるのか

日本では当てはまらないと思ったことは?

中国日本アメリカ
ユーザーインタビュー日本が一番難しい

学生頭いいけどリターンが低いと思われている

YCの主張

ユニコーンを作れ ベンチャー投資のため ユニコーンユニコーンユニコーンっていうカルチャーがない

medium資金調達やりすぎた

成功したらエンジェル投資家になる場合がある

YCombinatorはエンジニアをリスペクトしている
CEO 80パーセントとかを日本でやりがち
エンジニアに50パー渡せ
「信頼のため」
51,49でも信用してないことを示す
3か月遅かったからと言ってその後数年一緒に働く

メトリクスの10パーは本当に厳しい ただ、PMフィットしていればすらすら行く

一見よくないアイデア

学ぶのはすごく難しい
自分がほしいプロダクトを作っちゃう
僕が頭がいいからユーザーはこれ絶対ほしがる と考えてしまう

イデアそのものに対するダメ出しはない
パッションややる気があればやればいい

これを実行するために何をやるのかみたいなことは批判される

一見悪いアイデアは人に伝わらない
どうしたら伝わるのかというのをひたすら繰り返していかないといけない

やらないほうがいいといったことをfounderがやったりする

ユーザーインタビューの中でやることやらないことをどうやって決めている?

ボタンが一つ足りない confuse
直接顧客にインタビューすると、やさしいから「使うよ」っていうときがある
プロダクトを見せる前に 人生に関するインタビューをしたりして 本当にその問題があるのか validateする必要がある

お金を払ってくれるかどうか

そのハードルが高すぎる場合 個人情報を使ってアカウントを作ってくれるかどうか
そういうものはいずれ聞かないといけないけど今じゃないこともある

スケールしないところからスケールするタイミング

プロダクトマーケットフィット
いったことあるお友達は「なったら絶対わかる」といっている

このままのチームではやっていけない気がして、「エンジニア雇わないといけない デザイナー雇わないといけない」と感じた
wantedlyさん 「ほんとにPMフィットしていますか?」ってきかれる
きかれて冷静になった

PMフィットするまではリーンにしておく必要がある (※リーンとはムダ、ムラ、モレをなくす手法。リーンスタートアップそのものというよりもそういった意味合いだったと思う。)

ほんとのPMフィットはなかった企業がある

PSはしても市場が大きくなかった

PMフィット見つけるのは4年で早いほう
それぐらい大変なこと

本当に上手なスタートアップでも18-24か月かかる
逆に自信がありすぎると12か月分しか資金調達しないみたいなことがある

PMフィットを探している段階 いかにローンチするか

次のスタートアップスクールに入る人に向け一言

起業家はローラーコースター
ハイを高すぎないようにロウを低すぎないように
朝起きるまで考えない
スプリントするマラソン

感想

PMフィットが喉から手が出るほどほしいものだということが分かった。
とにかくパッションがすごい。一番重要なことだと思う。
この話を聞いた後にリーンスタートアップの本も改めて勉強してみて、とにかく顧客の話聞くとか、バッチサイズ小さくとか、真実のメトリクスとか、MVPを可能な限り早くローンチとかいろんな考え方が奔流のように頭を巡っている。
つたないメモですが、このメモを何回も読み返したいと思います。

非常に学びが多く、登壇者のお二人と馬田さんやスタッフの方に本当に感謝します。

虚栄の評価基準

リーンスタートアップの青い本を読んでいる

「リーンにとってメトリクスはエッセンシャルだ」という話はこの本を読む前から目にしたり、聞いたりしていた。
「いいメトリクスってなんだろう?」という疑問を漠然と持っていたけど、リーンスタートアップを読んで以下のような印象を受けた。

真実のメトリクスにアカウンティングしろ

虚栄の評価基準とは

  • 総顧客数
  • 登録数

などの累計数値がなりやすい

爆発的に成長するためのUI/UX改善などの施策をやったときに、過去の決断で変わっているのか、施策で変わっているのかがわからない。 もちろん、ABスプリットテストをするなどすれば、判断できることもあるだろうけど。

紹介されているのはコホート分析、つまり顧客が最初に製品に触れた時期ごとに分別されたもので、1回使った、5回使った、有料登録した、などのファンネルの割合がどうなっているのかを見る。 1%で推移していないなら、改善は効果がないことがわかる。

どんな時にでもコホートを使え、というのも往々にして正しいと思うが、顧客の本当の行動をメトリクスにできているかどうかが重要なんだと思う。

そして、その分析ができていれば顧客の話を聞くという行動にたどり着ける

ポエム

僕達は世界をライトウェイトにスクリプティングしたい。

 

だから大きなプログラミングはしないというのは大前提だ。

 

でもそうはいってられないことももちろんある

 

そういうときの考え方に役立つことをRebuildfmでnaoyaさんが言っていて、具体的にはデザインパターンのあの本読むといいですよ、ということだった。

 

地力をつけたいエンジョイ勢、ガチ勢にオススメなんだろう

Ubuntuでintellij IDEAのインストール、アップデート

ランチャーのショートカット情報の更新などで迷ったのでメモ (2017.12.13追記)

jetbrainsからダウンロードしたtar.gzを解凍したディレクトリを配置して、ランチャー用のdesktopファイルを作成するだけです。

/usr/local/にファイルを配置するようにしています。

gist.github.com

とにかくidea最高なので今すぐ使い始めるべき

むろん、pycharmやphpstorm,webstormでもいいです。

理由はいろいろあるけど、強力な補完機能だけでもメリットがコストを上回ってるのが直感的にわかります。