ミッションたぶんPossible

どこにでもいるシステムエンジニアのなんでもない日記です。たぶん。

#DevLove リーン・スタートアップ・ナイト に参加してきました。



5月16日 DevLOVE リーン・スタートアップ・ナイト(東京都)



 昨晩は東京都飯田橋クラスメソッド株式会社で開催された「DevLoveリーン・スタートアップ・ナイト」に参加してきました。参加条件は「リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす」を読んでいること! 加えて少人数の座談会形式であったため、参加に際してそもそもハードルの高い勉強会でした。かく言うオレ自身も…



と怖気づいていたのですが…











とまぁ多方面からの後押し(?)もあって半ばヤケで参加、早速本を買ってきてGWで一気に読み進めました。ちなみに参加枠は10人でオレは9人目の登録者。募集開始一日足らずで満席とは、DevLove恐るべし。



 まずは自己紹介から。こくちーずからの参加登録+αで13名が参加となりました。

 続いてDevLove船長:@papandaさんから会の主旨説明。座談会の進め方と、事前に参加者に答えて貰った「座談会で取扱いテーマ」を紹介されます。



座談会前半戦

― メモ ―

  • 人生のPivot
    • 自分の信念を否定される瞬間
    • SONYPanasonic
      • 得意のテレビ事業がダメになった
  • 製品開発
    • 時代の流れ:プラットフォーム技術の進化による、それまでのプラットフォームの陳腐化
    • →でも作り切った
  • →「失敗を達成する」
    • 日本の企業
      • 真面目で精密に作りこむ
      • 必要ないものを厳密に作っちゃう
  • 思い込みを外す
    • →まず「思い込んでいる」という自分の状態に気付く
    • 数字等可視化できるもので表現
      • →否定されて再検討
  • プロダクトバックログ
    • やらないことをリストアップ
  • MVPで聞く
    • 押し売りじゃダメ
  • Build → Major → Learn
  • Pivotが必要 = ビジネスが上手く行かなくなる
    • 全然違う方向を見てる
    • 外的要因
  • リーン・スタートアップに向いてない業種は?
    • 例えば農業とか?
      • バッチサイズが大きすぎる?
    • →ビミョーにチューニング
      • 何も考えてない他者よりは競争力がつく
    • →全体ではなくポイントポイントにリーンを用いる
    • →輸出とかなら?
    • →高齢化に適した農作物って?
    • →売り方・販路
      • ex)楽天…どれが売れたか分かる、欲しいものが伝わってくる
      • ex)農協…渡したらお金受け取っておしまい
    • ポイントの当て方次第なのでは?
  • 五カ年計画
    • だいぶ先のストーリーまで考える
    • 途中で変更できない
    • →なんで変更できない?
      • 会社のポリシー
      • プライド
      • 勿体ない
        • →「捨てる」=「価値がある」という意識を共有


 直前に@papandaさんから見せて貰った「座談会で扱いたいテーマ」の中で一番目立っていたのが@hyoshiokさんの挙げた「人生のPivot」というヘビーなテーマ。我々のテーブルには@hyoshiokさんがいらっしゃったので、そこから話が始まりました。リーン・スタートアップの場合は計測を行うことでPivotを踏むか否かの判断を行うわけですが、人生に正解は無いし可視化できる指標もほとんどの場合が存在しない。それぞれが身の上話的な事は軽くしましたが、それ以上は広がりませんでした。


 続いてそれぞれがどんなテーマを挙げたのかを話ていきます。オレから挙げたのは「リーン・スタートアップに向かない業種は?」。オレは実家が農村にあることもあって、「農業のようにバッチサイズが大きいものはBuild → Major → Learn」のサイクルが長くなりすぎてしまい、リーン的な実践は難しいんじゃないかという考えからです。
 これに対し「農作物を育てる過程は確かに変えようがないが、他の工程ひとつずつを見直すことはできるのでは?」「販売ルートを変えてみるとか。たとえば楽天とか(@hyoshiokさんより)。」「直販であれば、どれが売れているか、どれを欲しがっているかが直接わかる。翌年の耕作対象をそこから見直すことはできる」などなど。大きなバッチサイズのものであっても、ポイントポイントでPivotを踏めるところはあるんじゃないか、という意見が大勢でした。


 続いて別の方から、ついこの間まで彼が関わっていたプロジェクトの話を伺います。

  1. 元々大きな計画(それこそ5カ年といったような)でいくつかのプラットフォームで自社製品を開発している
  2. まず1つ目のプラットフォームから開発を始め、リリースした
  3. 続いて2つ目に着手しようとした
  4. このタイミングで元々計画していたプラットフォーム全てへの進出が無意味になる様な技術要素が台頭してきた
  5. 開発を続けることができずプロジェクトは凍結へ

 この事例では、そもそも大きな計画の中であったので、「Pivotを踏む」ということ自体が念頭に無かったのですが、では「どうして大きな計画になった時に止められないのか」という話に発展します。結局のところ、感情論だったり思考が硬直していたり、またそもそも「ビジネスの見直し条件」みたいなものを設定しておく必要があったんじゃないか、なんて意見も出ました。





座談会後半戦

― メモ ―

  • 計測の重要性
  • 教育サイトの話
  • マーケティング
  • 実例から
    • ニコニコ動画
      • リニューアル後にユーザーから叩かれてる
      • なぜPivotを踏まなくちゃいけなかったか?
        • UIから探る
        • 20代の70%が利用?
    • はてなブログ
      • 大々的に公開してしまった
      • ユーザーが付き合ってくれるか?
    • アーリーアダプターの呼び方
      • Facebook:頻繁に変わる
      • →変わっていくことに慣れて貰う
    • ブランドを傷付けない
  • リーン・スタートアップに向いてない業種
    • バッチサイズの長さ
      • 本当に問題か?
      • 並列でやれば?
    • サービスが大きい
    • 方向転換できない
      • 車に例えると?
        • 車体が重い
        • ハンドルが重い
        • スピードが速すぎる
        • 運転手がへたくそ
    • ステークホルダーの多さ
      • 政治
    • なんとなく悪い方向に向かうことが分かってるが、今は調子が良いためカードが切りづらい
      • サッカー:選手交代のタイミング
    • →Pivotの条件をコミットしておく
    • 五カ年計画を見直せない
    • →リーン・スタートアップ=仮説があいまいで不確実なものに用いる
      • ダム工事だと仮説じゃなく決定事項では
  • リーン・スタートアップに必要な知識体系


 席替えをして後半戦へ突入。


 まずはそのテーブルで前半に話していた内容を簡単に共有して貰いました。それまでは、メンバーにエンジニアが多かったことから、計測の話題が中心を占めていたとのこと。他、マーケティングの知識の必要性が話題に上がったとありました。


 後半戦では割と実例から話が進んだと思います。まず話題に出たのが「ニコニコ動画」。最近ニコ動ではUIを大幅に変更したのですが、それが既存ユーザーから物凄く叩かれているそうです。じゃあ、なんでそんな大きなリスクを冒してまで変更を加えなくてはいけなかったのか。仮に「計測をしていた結果としてPivotを踏まざるをえなかったとしたら?」という観点から、じゃあどの指標がPivotを踏む原因になったのかを変更されたUIから逆に探し当ててみることはできないか、と。
 同様に割と最近リリースされた「はてなブログ」。既に「はてなダイアリー」があったにも関わらずリリースし、機能が揃ってないだの使いにくいだのと散々バッシングを浴びましたが、そもそもなんで「はてなブログ」をリリースしなくちゃいけなかったのか、を材料に考えることもできるのではないか、と。

 これらのサービスに対して「元々サービスにファンがいて、その最もコアなファンが真っ先に反旗を翻した(お前らの愛は重い!)」「アーリーアダプターを上手に掴まえることが重要」という意見が出て、「アーリーアダプターって、どうやって呼び込むんだろうね?」という新しい疑問点も生まれます。
 また、批判に対する防ぎ方として「Facebookはしょっちゅう機能追加やらUI変更やらやっていて、いつ変える、というより、いつもなんか変わってる、ということが多い。」「いっそ常に変わることにユーザーに慣れてしまったらよいのでは?」なんて意見も出ました。


 そしてまた話は変わって、このテーブルでも「リーン・スタートアップに向いてない業種」の話題に。やっぱり農業を引き合いに出したんですが、こちらでも「期間のバッチサイズは変更できないけど、並列で色んな作物を作ることはできるから、手数を多くして検証していくことはできるんじゃないか、という意見が。
 じゃあ何が向いてないの? という問いには「ちょっと前にニュースになった、ダム工事なんかは方向転換しにくいんじゃないか」という意見が出ます。一方で「リーン・スタートアップは『仮説が曖昧だったり不確実なものだったりするものに用いるもの』だから、そもそもダム工事みたいに仮説も何もないケースでリーン・スタートアップを適応しようというのが無理なんじゃないか。」という対論も出ました。リーン・スタートアップが何に使えて何に使えないかという話は、もうちょっとケーススタディが増えてこないとピンと来ないのかもしれません。


 また話は変わって、冒頭の計測指標の作り方やマーケティング知識の必要性の話から「リーン・スタートアップを行うにあたって必要であろう知識体系って何かあるのか?」という話題になります。ここで、知識体系というか、能力のひとつとして「テストコードを書ける能力」が出て、「リーン・スタートアップでは開発するプロダクトに対してテストコードを書いた方が良いのか?」という疑問が出されます。残念ながら疑問が出てきたところでタイムアップ、議論はいったん終了となりました。


 

座談会延長戦

― メモ ―

  • テストコード
    • あった方が良い
      • コードを全て捨てるわけじゃない
      • 仕様を把握できる
      • そもそもテストを書かないような体制で出す製品はロクなもんじゃない
    • テストを書く必要がないように作っていく
      • 既製品を利用
    • 大事なところだけ書く

 延長戦は、3テーブル全てが同じ議論に参加しての形に。我々のテーブルで尻切れトンボで終わってしまった「リーン・スタートアップでは開発するプロダクトに対してテストコードを書いた方が良いのか?」が全員で話し合われました。

 大勢として「書けるなら書いた方が良い」という意見が占め、スピードを優先させたからといって、Majorするのであれば品質もちゃんとしとかないと、というのは共通意見のようでした。
 またそもそも論として「ソースコードを書かなくても済む方法の模索がまず必要」という意見も。既製品を用いたり、ペーパーモックだったりと、ソースコードを書かなければテストコードを書く必要も無い訳で、リリース当初Wordpressを用いていたというグル―ポンの逸話を参考にした意見も出ました。



総評

 とにかく議論するのが難しかったです。面白かったけど、とにかく疲れた!! まだ本が出版されてから一ヶ月程度しか経ってない中で議論している訳ですから、全員がそれほど理解が深い状態ではなく、手探りで話題を探す、という状態がずーっと続いたと思います。また、前回の「7人のアジャイルサムライ」と大きく違うのは「誰も実践できていない」こと。実践できてないがゆえに、誰も回答や経験を持っておらず、ボヤッとしたまま議論が進…めばまだマシな方で、突然沈黙がテーブルを覆うこともしばしば。おそらく@hyoshiokさん以外はビジネスを取り回す立場に無かった人たちばかりで、憶測と推測で議題を出したり意見を述べたりする他無かったので、みんな自分の意見に自信を持てないんでしょう。少なくともオレは終始疑問符を頭に浮かべてる状態でした。

 議論の最中にも出たんですが、ソーシャルゲームでは指標を計測して、そこからドラスティックにゲームを作り替える、という話を聞きます。まさにリーン・スタートアップの手法に適合し、であるなら、GREEMobageのゲーム開発者が1〜3人くらい議論に混ざって貰えると、また違った議論が出来たのかなぁ、とは感じました。


 あと余談ですが、勉強会が終わった後で

  • 「バスケはアジャイル・リーン的だ!」 → 「じゃあバスケやりますか。」
  • 楽天でリーン・スタートアップの勉強会やるんですよ〜。」 → 「じゃあ極力参加しますわ。」

などなし崩し的に色々スケジュールが決まっていったんですが、オレは果たして過労死しないのか、は疑問が残るところです。