【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得
https://supporterzcolab.com/event/410/
に行ってきたので、そのときのレポート
対象者
- 現在新規事業の立ち上げに携わっている方
- これから新規事業にたずさわるかもしれない方
- (もしくはたずさわりたいと思っている方)
- ライブラリを書くより、プロダクト開発が好きな方
話すこと
- 作りすぎて失敗したことの事例紹介
- つくりすぎないために
- コアバリュー大事
登壇者の方が作ったサービス
pook
https://s.pook.life/lp/
ランサーズは、オンラインクラウドソーシングの会社だが
pookはオフラインでやることに特化したサービス
→ オフィスで肩を揉んでくれたり
→ 栄養士の方が手作りご飯を届けてくれたり
本題
エンジニアの新規事業への関わり方
そもそも新規事業って?
新規事業とは、既存事業から生かして、新しい経済成果を生み出すこと。
対して、起業というのは0から始めること。
どうやって関わって行くの?
求められること
サービスを作ることが求められる。
実際には、プログラムを書くというよりは、問題を解決すること。
失敗1:作りすぎた。
リリース時に作ったのは、
- APIの数150本
- ページは80個
ガチガチの仕様をその通りに作ってリリースした。
多いと何が悪いか。
多いとリリースが遅くなる
→ 多すぎたということは、無駄なことを作ってしまった。
→ 使われないコードはただのゴミ。
本当にあった怖い話
nヶ月書けて作った仕組みをすぐに消した。
顧客が本当に求めていたものと違った。
どうすれば良かったか?
作らなければよかった
→ しかし作って見ないと分からないこともある。
→ 作る前にそもそも考えることがあるはず。
- 同じような体験ができるサービスを作って模擬する。
- ユーザーにもっとヒヤリングする
- プロトタイプで実験してみる。
反省
- 作らないで実験できないか考えてみる。
- 試したい仮説をすぐに実装できないか考える
失敗2:技術選定
エンジニアあるある。
最近イケてる○○という技術を使おうぜ!
→ 既存に縛られないので、使いがち
結果
情報が少なくて死ぬ。
社内で知識が多い人の助けも受けられない。
サービスがあたるか当たらないかという問題の前に
サービスが作れるか作れないかという問題が発生する。
反省
- 枯れた技術を使うべきだった
- もっと協力しやすい技術を選定すべきだった。
- できるかどうか分からないは早めに潰す。
失敗3:仕様が変わる。
どうしてそうなった?
- 作るべきものがあやふやだった
- 目的を達成するための機能がもりもり
- 全部マスト
どうすればよかった?
コアバリューを定めて、やらないことを決める。
コアバリューとは?
ミッションやビジョン実現のために、組織が独自にもつ共通の価値観。
これを選定することで、作らないものを決めることができる。
→ コアバリューはなんですか。どうしても欲しい機能はなんですか。と唱える。
→ そうすることで、議論の着地点も見つかる。
反省
コアバリューを決めて、作らないを決める。
まとめ
新規事業開発に置けるエンジニアの心得
- 一番大事なことは作らないこと
- また、そのために、コアバリューを決める。
- エンジニアとして問題を解決することにコミット
とはいえ、経験がないと分からないことが多いので、経験をたくさんしよう。
Q & A
Q1.
コアバリューを決めることでいらないものが見えてくるということだったが
APIの数など具体的にはどの程度減ったりするか?
A1.
Apiの数は80本になったりした。大体全部合わせて半分くらいになった。
Q2.
やっていくなかで一番コストがかかることは?
A2.
新規事業でいうと、人件費が一番コストになる。
技術でいうと、どこにコストがかかるか?
→ 作って捨てればいいので、キレイに作らないことを考えればよかった。
→ 無駄にキレイにつくることを考えてしまった。
→ 結果、使われないキレイな部分ができてしまった。
なので、キレイに作るっていうところにコストがかかる。
Q3.
新規事業をやる上で、予算をどのくらいに抑えろとかあったか?
A3.
最初はなかったが、途中からなんでこんなに時間かかってんだとかあった。
最初はノリで始まったものだが、どうしてこれこんなに時間かかってるの?とか。
新規事業は黒転するまでに時間がかかる。
→ なので、試算を前もってしておいて(エンジニアどのくらい必要です。どのくらいでリリースできます。どのくらいで黒転しますとか)ロードマップ考えておこう。
Q4.
開発するに置いて、「これ使ったよ」みたいなツールとかあるか?
A4.
プロトタイプを作るツールでいうと、InVisionというツールを作っていた。
InVisionというのは、web上ピピッと操作してプロトタイプを作れるツール。
逆にコンフルエンスを使ったのは失敗だったと思った。
コンフルエンスはバージョン管理ができたり、キレイに書けたりすることができるツール
別にキレイに書く必要はなかったが、キレイにかけるがために、キレイに描こうという空気ができてしまった。
それよりも、ガンガンアウトプットできるようなツールのほうが良かった。