リーンスタートアップセミナー2013 in 札幌に参加しました

7月9日に行われた、リーンスタートアップセミナー2013 in 札幌に参加しました。
会場はアスティ45にあるACU(アキュ)。定員100名のセミナーでしたが、ほぼ満席、大盛況でした。

ワイクル株式会社の角さんによる、リーンスタートアップについての説明の後、株式会社もぐらの新井さん、株式会社リコーの山本さんがそれぞれの立場から実践しているリーンスタートアップについて語ってくださいました。
質疑応答も盛り上がり、大変有意義な時間となりました。

以下は講演時に取ったメモと、質疑応答です。

10分でわかるリーンスタートアップ – 角 征典 氏

この後の事例紹介の前提となる「リーンスタートアップ」とは何ぞや、という部分。
「Lean」と「Startup」に分けて説明してくださいました。

「Startup」

  • とてつもなく不確実な状態で新しい製品やサービスを作り出さなければならない人的組織
  • 社歴や規模は関係ない「不確実な状態」であればみんな対象になる
  • 顧客や市場が不確実 ←リーンスタートアップはこっち
  • 実験コストを抑えて実験を繰り返す方法
  • 最初から製品を作らない
  • コストを抑えて仮説を検証する

「Lean」

  • プルシステム(後行程引き取り):お客さんに売れたら補充する
  • お客さんはどこに?Get out of the building!! GOOB!
  • 顧客開発>製品開発
  • 作れるものを売るな、売れるものを作れ。

これらのキーワードが次からの事例紹介でリンクしまくるのでありました。

受託開発と自社製品販売の違い~自社製品を売るための長い道のり – 新井 俊一 氏

株式会社もぐらさんは「動画販売ショッピングモールXCREAM」「メイシー」といった自社製品をリリースしているスタートアップ企業。

  • 自社製品は単価が安い分、広告やマーケティングが必須
    → 成功した企業がさらに大きくなる、規模の優位性
  • 失敗や持久戦を覚悟する
  • アントレプレナーの教科書
  • 作りすぎないこと大事「開発期間が長過ぎたのでペイでできなかった」反省
  • 開発期間を自社営業販売にもっとあてるべき
  • 競合がひしめいている=市場を先に作ってくれていたという発想の転換
  • なぜ今まで誰も作らなかったのか? だれも必要としていないからじゃないか?

新規サービスを立ち上げようとするときには、「今まで誰もやっていないこと」を見つけることが最も重要、とぼんやりと思っていたので、
「今まで誰もやっていないっていうことは誰も欲しくないんじゃない?」という発想には目から鱗。

リコーUCSの開発をリーンスタートアップ的視点でふりかえる – 山本 陽平 氏

株式会社リコー の山本さんは、読んでみたいと思っている本(けどまだ読んでいない…)、「Webを支える技術」の筆者だったのでした。恥ずかしながら登壇されるまで「Webを支える技術の筆者」と「リコーのエンジニアの方」が全く結びついていませんでした。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
山本 陽平
技術評論社
売り上げランキング: 9,988

山本さんは、自社製品「リコーUCS(クラウドベースのテレビ会議システム)」の企画・開発の事例紹介をしてくださいました。

  • 我々は大企業だけれどスタートアップだった
  • 売り上げ目標以外は、何も決まっていなかった
  • 初めてチームを作るときに大富豪やることおすすめ => yohei’s diary – チームビルディングで大富豪をやった話
  • プロジェクト原則に「リーン開発」って書いてあった
  • そのころリーンスタートアップという本は出ていなかった。でもあとから考えるとこれはリーンスタートアップだった
  • 最初に構築した製品MVP:ストーリー仕立ての漫画
  • 段ボールの空き箱で作ったMVP
  • いろいろなネットワーク環境のお客様、想定とは大きく異なるユーザ
  • リーンは本質に集中できる

“やらなければいけないことを適切な形で実現しようとしたら、リーンスタートアップになっていた” ということが大企業でもありえるのだなあということを本物の事例で知ることができました。

質疑応答

いきなり、新井さんから山本さんへの
「プロジェクト原則すばらしい、公開しないの?」という質問から始まった質疑応答タイム。
質問も、それに対する答えもとても良かった。
(以下、質問者Q、角さんK、新井さんA、山本さんYとします。)

  • Q: どのタイミングでどういう判断をして、どういうPivotを行ったのか
    • K: 私は現在スタートアップではないが、Pivotについて。事業をするうえで必ずしも最初からうまくいくわけではない。小さいPivotでもいい、がらりと変える必要はないので変えようとしていくことが大事。
    • A: XCREAMで、当初は成人向けはお断りにしていが、途中からOKにした→その後軌道に乗った
    • Y: 価格の体系や攻める場所を変えてみるなどの小さいPivotはたくさんあったが、最初のビジョンを大きく変更するには至っていない。
  • Q: (新井さんへ)2つ目の製品を作ったタイミングや判断はどうしてたのか
    • A: 受託を引き受けるのをやめるという決断をしたとき。自分がもっとオーナーシップを持った製品が欲しかった。
  • Q: 開発スケジュールでデッドラインはもうけた?
    • A: デッドラインを定めずに作っていた、それはかえってコストを膨らませてしまって失敗だった。いつまでに出す(間に合わないのは削る)、という計画にした方がよい
    • Y: 経営レベルに約束したスケジュールが守れるかどうかの危機はなんどもある、デスマ状態、きれいな話じゃない。ハードウェア製品だと、型を発注しなければならない、そこまでにいろいろ決めなければいけない。ハードウェアの締め切りに縛られながらソフトウェアは反復可能にしていく難しさがある
  • Q: バリバリウォーターフォールでの開発しかしたことがない人が、リーンスタートアップにどうなじんでいくか、ギャップをどのように解決したのか
    • A: うちの組織は逆にそういう人がいない。逆に大手企業的な手続きや手順がわからなくて困ることがある
    • Y: 今も戦っている。最初からウォーターフォールの方法しか知らない人が入ってくるとリーンスタートアップの方法は難しい。説得するにも難しい、売れないともいわれた。最終的には…..やってしまって結果を出したもの勝ち、と。なるべく政治的に強い立場に立ちたい。
  • Q: それぞれのチームの人数とチーム編成教えてほしい
    • A: エンジニア2名、社長1名、カスタマーサポート数名:10人くらいでやっている
    • Y: 最初エンジニア25人、その後いろいろあって、ソフト開発だけで20人くらい。その他に営業が数万人レベルでいる。関連する人は死ぬほど多い。やりにくい部分もあるけれど、直売の販売網をこれだけ持っているというのはメリット。
  • Q: 作ろうと思ったプロダクトを作ることができる技術が最初からあったのか、作っていくうちに身につけていったのか
    • Y: 最初は研究開発をしていた人ばかりでプロダクトコードを書いていた人いなかった。Linuxなにそれおいしいの?というひとがクラウド基盤のリーダーとなっていったりした。HTML5もいいなと思って、やろうと思ってから身につけた。あとはライブラリを買ったり、もとからの資産があったりもしている
    • A: どうしてもできることから発想してしまう、技術的にできることから始めた。ものがない段階からお金をかけることができない
  • Q: チームビルディングの話、製品ビジョンを共有するまでの話やコツを知りたい
    • Y: チームビルディング大切(大企業だし)、全然知らない人と突然仕事をしなければいけなくなることが多い。同じ企業でも”初めまして”から始まるので、信頼もあまりない。情報共有の手段を密にしている(毎日wikiに日報を書く、IRC)。とにかく開発内部では情報を共有する。
    • K: Team Geek、内容よかったよ。どうやってアクの強い人をまとめるか。お昼ご飯を一緒に食べる。チーム感高まる。飲み会じゃなくてお昼ご飯というのが大事。
      下手は下手なりにパッケージの絵をみんなで書くのも大事
    • Y: Amazonはプレスリリースから始めるそうですよ
  • A: (山本さんへ)あの製品ってすごいニッチでいいところをついている、そこに至った決断やバックグラウンド知りたい
    • Y: そこを決めたのは私のボス、元々頭の良いエンジニアで、素養としてはマーケティングなどの知識もある。最初は”何でもできる”端末だったのだけど、”ここ”にしぼっていこうというリーダーの決定があった
  • Q: 不確実な状態から確実に「いける」とわかるタイミングがあるのか、ある場合、次の不確実にどうやって立ち向かうのか
    • A: じわじわのびているので、確信したというポイントはない。反応がある広告を見つけたとか、タイミングはある。粘り強くやるということ。
  • Q: 顧客からずれないようにするためにやっていること(ペルソナなど)がエンジニアではできないことのような気がするのだけど、専門的な人がいたのか?
    • Y: もともとR&D出身なので、そういうのを勉強している人はいた、あとはデザイン部門にお願いしたりもしている
  • K: 過去に戻って自分に伝えるなら何を伝えたいか
    • A: デッドラインを決めて最小限の機能でまずは世に出せ
    • Y: もともとコード書いてない。UIのCSSだけ。開発グループのマネジメントをしていた。でも、コードを書くよりもっとマーケティングしろとか、もの作りじゃなくて事業だってことをもっと考えておいた方がよかったんじゃないの、と伝えたい

質疑応答でも出てきた「Team Geek」は日本語に翻訳されてもうすぐ発売になるのですね。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか
Brian W. Fitzpatrick Ben Collins-Sussman
オライリージャパン
売り上げランキング: 9,691

平日の札幌で、こんなに濃くて良いセミナーに参加できて幸せです。
主催者、スタッフの皆様、ありがとうございました。

# 余談ですが、積読本の消化について本気で考えようと思いました。

2 comments:

  1. 今すぐ積読本を消化して、最初に紹介されている素晴らしい本を買ってくださいw

    1. はい…!! 早く新しい本に進みたいと思います!!
      (ブクマでご指摘いただいたところ、修正しました。ありがとうございます!)

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください