新規事業開発におけるエンジニアの心得

昨年、CtoCサービスの新規事業の立ち上げからリリース、グロースまでを一通り経験させていただきました。その中で多くの失敗や学びがあり、ぜひその内容をシェアさせていただければと思います。
特に、自分が新規事業で携わった pook(https://pook.life) というサービス(テレビにも何度か取り上げられました)を作っていく上で、主に失敗したことをベースに、学んだことや、こうしておけばよかったことなどをお話しできればと思います。

Transcript

1. 新規事業開発における エンジニアの心得 Tsuyoshi Numano @Lancers　2018/06/04 新規事業開発におけるエンジニアの心得
2. 本日のハッシュタグ - 質問や感想はこちらから #spzcolab
3. 自己紹介
4. 沼野剛志 1990年生まれ 出身高専　 ：神戸高専専攻科（~2012）：ロボット制御 出身大学院 ：JAIST（~2014）：VRの研究、出会いの研究で修論 株式会社リッチメディア（~2015）：メディアの運営・開発 現在はランサーズ株式会社で、研究の成果を生かしながら(?)プロダクト開発に励んで います。 自己紹介 Twitter @numanomanu
5. 今日お話しする内容 対象者 - 現在新規事業の立ち上げに携わっている方 - これから新規事業に携わるかもしれない方 - ライブラリを書くより、プロダクト開発が好きな方 話すこと - 作りすぎて失敗した事例紹介 - つくりすぎないために - コアバリュー大事 話さないこと - 人について
6. つくったサービスについて
7. pook（プック） https://pook.life C2Cスキルシェア
8. オフィスの会議室で座ったまま 目や肩をほぐしてもらっている様 子。 とても気持ちいいので凝ってるエ ンジニアにオススメ。 https://pook.life/services/1590
9. 栄養士のお姉さんがヘルシーな 手作り晩ご飯を届けてくれるサー ビスはコチラ。 ヘルシーと癒しーが足りてないエ ンジニアにオススメ。 https://pook.life/services/2493
10. エンジニアの新規事業に関わり方
11. そもそも新規事業って？ 事業を作る人の大研究　 2018/1/29 田中 聡、 中原 淳
12. - 企画の段階からエンジニアとしてアサイン。 - ある程度事業構想が決まってからのジョイン。 - 企画は当たるかどうかわからないという前提。 前提条件(自分がアサインされた時)
13. エンジニアとしての関わり 新規事業におけるエンジニアに求められること。 サービスを「つくる」という１点。技術は手段。 - x プログラムを書く - o 問題解決をする （プログラマではなくエンジニアという観点では新規事業とか関係 ないかもしれない）
14. 失敗１〜作りすぎ〜
15. 仕様をガチガチに決めて機能を作りすぎた - API 数 150 本 (GET:/users や POST:/service ) - ページ数 80 個 機能が多いと何が悪い？ => リリースするまでにかかる時間が増える => 当たるかわからない瀬戸際だと致命的
16. - 使われない機能を作ってしまった。 当たるかどうかわからないことに時間を使ってしまった。 作りすぎたということ ＝ いらなかった
17. そのコード 使われなければ ただのゴミ。
18. 本当にあった怖いはなし - nヶ月かけて作った仕組みをリリース後すぐにサヨナラ - 顧客が本当に必要だったものはコレじゃなかった。
19. - ユーザーの位置情報を共有する仕組みを作ったが必要では なかった。 - 体験としては面白いがマストな機能ではない => 他にもイロイロ・・・ 実際どんな機能が使われなかった？
20. どうすればよかった？ - 作らなければよかった。 => しかし、作って見ないとわからないこともある。 => つくる前に考えるべきことがあるはず。 - 同じような体験ができるサービスを使って模擬をする or - ユーザーに聞いてみればよかった or - 最低限の実装で試す。
21. - 同じような体験ができるサービスを使って模擬をする - 位置共有はMessenger で代替できるはず。 - ユーザーテストすればよかった。
22. 迷ったらユーザーに聞いてみる
23. 最低限の実装で試す、１ 実際の例） - ウィッシュリストが必要か どうか迷ったとき、すぐ Google Apps Script で 作ってリリース。 => その後、ユーザーからの 引き合いがよかったので、本 格的に実装。
24. 最低限の実装で試す、２ 需要があるかどう か、ボタンだけ置い てみる。
25. 反省 - ツクラナイで試せないかを考える。 - 試したい仮説をすぐに実装できないか考える。 => ユーザーに向き合うことが一番重要
26. 失敗２〜技術選定〜
27. エンジニアあるある 「〇〇って言語や、〇〇ってフレームワークが最近イケてるらしい から使おうぜ！」 新規事業やるときは既存制約に縛られないことが多いので、自分 たちの好きな言語やアセットで選びがち。
28. 最近イケてる〇〇を入れた結果 - 情報が少なくて死ぬ - 他人の協力を得られなくなる 当たるかどうかわからない以前に できるかどうかわからない。という問題が発生する。
29. - 後半の改善フェーズでは絶大なパワーを発揮したものの、前 半は発展途上の技術ゆえ、環境面でのハマりどころが多くて 辛かった。 React Redux の SPA を運用して得られた知見と実装例、開発フ ローもあるよ！ 逆に知見がないものだから、記事を書いたらすごい伸びた汗 (=> Cordova も採用したがこちらは逆に下火で辛かった。) React を採用した結果
30. モチベーションとのトレードオフ 作れる速度(会社や社会的なトレンド含む)と 興味（モチベーション） とのトレードオフ。
31. 反省 - 枯れた技術を使うべきだった。 - もっと協力を得やすい技術を選定すべきだった。 => できるかどうかわからないは早めに減らす。 （モチベーション問題ものあるので、個人的には良かった面の方 が大きい。）
32. 失敗３〜仕様が変わる〜
33. 度重なる仕様変更が・・・ - 最初は 〇〇 だったのに、xxになった。 ＝＞ pook も最初はプロ用、ワーカー用で２種類の「アプリ」で 作っていたが、途中で WEB に変更。
34. どうしてそうなった？ - 作るべきものがあやふやだった。 - 目的を達成するための機能がモリモリ。 - 全部マスト。
35. どうすればよかった？ - コアバリューを定め、やらないことを決める。 （後からやってみてわかった）
36. コアバリューとは - コアバリューとは、「ミッションやビジョン実現の為に組織が独 自に持つ共通の価値観」。プロダクトも同じ。 => 世界平和的ではなく、ユニークでなければならない
37. やらないことを決めて、やるべきことにフォーカス - コカコーラ 「リフレッシュ」　＝＞　アルコールやらない。（最近はやってるみたいですね） - スターバックス 「サード・プレイス」＝＞　美味しいコーヒーよりも大事 ＝＞作りすぎを解消し、作るべきものにフォーカスできる。
38. コアバリューが決まった結果 - つくらないものが決まる。 - 議論の着地点が見える。 pook のコアバリュー 「誰もが気づいていないスキルで稼ぐ」
39. コアバリューのつくりかた コンセプトのつくりかた – 2012/8/3 玉樹 真一郎 (著)
40. 反省 - コアバリューを明確にしてツクラナイを決める
41. まとめ
42. - ツクラナイ - 問題解決するために必要な手段を考え尽くしたか？ - 自分の好みだけで技術選定して痛い目を見ていないか？ - 作ったとしても最速で作って、さっさと試せているか？ - コアバリューを決める - やらないことが決まる。 - フォーカスするべきことに力を使おう => ユーザーに向き合うことが一番重要。 => エンジニアとして問題を解決することにコミット。 => が、経験して見ないとわからないことの方が多い。 新規事業開発におけるエンジニアの心得
43. おまけ１
44. それでもやはりエンジニアは作らなければならない - 「ツクラナイ」でも作らなければならない。 => 作るならとにかく最速で、試せる環境を用意する。 => API を３分で作ってみよう。（ライブコーディング）
45. GAS 使えると彼女もゲット！ （宣伝） Google Apps Script ならそれが可能
46. おまけ２
47. 組織的側面からの新規事業の道しるべ 事業を作る人の大研究　 2018/1/29 田中 聡、 中原 淳 人視点での、新規事業における見取 り図。やったことある人ならとても共 感できるはず。