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