失敗から学ぶ個人開発

Slide 1

Slide 1 text

失敗から学ぶ個人開発 2019.05.29 @zaru

Slide 2

Slide 2 text

@zaru ベーシック CTO

Slide 3

Slide 3 text

いくつかの個人開発プロジェクトをやってきたけど、いくつかは失敗している

Slide 4

Slide 4 text

いくつかの個人開発プロジェクトをやってきたけど、いくつかは失敗しているここでの失敗の定義は完成できなかったり放置してたりする状態のこと

Slide 5

Slide 5 text

なぜ失敗したのか、失敗しないためにはどうしたら良かったのか振り返ってみたちょっと

Slide 6

Slide 6 text

ふりかえり

Slide 7

Slide 7 text

個人開発のパターン個人でサービスを作る個人でライブラリを作るチームでサービスを作る

Slide 8

Slide 8 text

Slide 9

Slide 9 text

個人でライブラリを作る seed_builder Rails でテスト用データを自動生成リレーションやバリデーションを考慮したテスト用のデータを自動で良い感じに作ってくれる gem mailcraft 指定メールアドレスに届いたデータを API で受け取れるメールアドレスと Endpoint を送ると、代理でメールを受信し、コンテンツを指定 Endpoint へ POST するだけのサービスとライブラリ完璧な easy を目指しすぎて要件が肥大化いつまでもリリースできない状態 Bad 最初から完璧目指すのは無理なので、割り切った仕様にすべきだった

Slide 10

Slide 10 text

個人でライブラリを作る seed_builder Rails でテスト用データを自動生成リレーションやバリデーションを考慮したテスト用のデータを自動で良い感じに作ってくれる gem mailcraft 指定メールアドレスに届いたデータを API で受け取れるメールアドレスと Endpoint を送ると、代理でメールを受信し、コンテンツを指定 Endpoint へ POST するだけのサービスとライブラリ作っていく中で周りの人にヒアリングしたけど誰も欲しがらなかったので途中でやめてしまった Bad 自分が本当に欲しかったら周りの声を気にせず完成させるべきだった。誰のために作るのかを明確にしたほうが良かった

Slide 11

Slide 11 text

チームでサービスを作る pushnate ブラウザにプッシュ通知をするサービスチーム　企画・ディレクション: 1名　デザイン・開発 : 僕 2015年5月開発スタート 8月βリリース 2018年8月くらいまで継続改善

Slide 12

Slide 12 text

チームでサービスを作る pushnate ブラウザにプッシュ通知をするサービスチーム　企画・ディレクション: 1名　デザイン・開発 : 僕 2015年5月開発スタート 8月βリリース 2018年8月くらいまで継続開発メンテやるべき事とやらない事の整理をしてもらったのと、開発以外のこと「マーケ」「問い合わせ対応」「コンテンツ作り」を全部やってくれたので開発に集中できた Good

Slide 13

Slide 13 text

チームでサービスを作る pushnate ブラウザにプッシュ通知をするサービスチーム　企画・ディレクション: 1名　デザイン・開発 : 僕 2015年5月開発スタート 8月βリリース 2018年8月くらいまで継続改善他企業などから競合サービスがどんどん出してくる中で、優位性を作り込んでいく工数を割くことができなかった Bad 撤退ラインが中途半端になっていたので、他社売却・譲渡含めて決めるべきだった

Slide 14

Slide 14 text

個人でライブラリを作る webpush Ruby でブラウザのプッシュ通知をする pushnate のサービス開発時に配信ロジックを OSS 化。mastodon や dev.to 、配信サービスなどで利用されているっぽい

Slide 15

Slide 15 text

個人でライブラリを作る webpush Ruby でブラウザのプッシュ通知をする pushnate のサービス開発時に配信ロジックを OSS 化。mastodon や dev.to 、配信サービスなどで利用されているっぽい Google の node npm の次に公開できたので、利用してくれるプロジェクトが増えた。そして、プルリクや issue をもらいやすい状況に。 Good

Slide 16

Slide 16 text

個人でライブラリを作る webpush Ruby でブラウザのプッシュ通知をする pushnate のサービス開発時に配信ロジックを OSS 化。mastodon や dev.to 、配信サービスなどで利用されているっぽい pushnate サービス停滞と共にメンテしなくなってプルリクと issue が溜まってしまった… Bad

Slide 17

Slide 17 text

初期から精力的にコントリビューションしてくれていた @rossta から嬉しい申し出。信頼できる人だったので権限を移譲。バッサバッサとプルリクと issue をさばいてくれた。使われているけど自分がメンテする気がないなら権限委譲はやっていったほうが良い（ただし信頼できる人）。これをキッカケに自分ももう一度メンテナンスをしよう…と思い直す。

Slide 18

Slide 18 text

モチベーションのスライド当初のモチベーションは「自分が必要だから作る」だったけど、そこから「色んな人に使ってもらう」にスライドすることにした。それを達成するために、以下の3つに絞って行動することに決めた。・存在を知ってもらうための活動・使ってもらいやすくするための活動・プルリクを投げてもらいやすくするための活動

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

個人でサービスを作る LightningQR URL を QR コードに変換するチーム　企画・デザイン・開発: 僕 1週間ほどでさくっと作成 NotifyHub GitHub の情報を通知チーム　企画・デザイン・開発: 僕 1年くらいダラダラと開発。完成はしていないけど自分が使う分には要件を満たしたので開発停止

Slide 23

Slide 23 text

個人でサービスを作る LightningQR URL を QR コードに変換するチーム　企画・デザイン・開発: 僕 1週間ほどでさくっと作成 NotifyHub GitHub の情報を通知チーム　企画・デザイン・開発: 僕 1年くらいダラダラと開発。完成はしていないけど自分が使う分には要件を満たしたので開発停止自分が本当に必要だと思った機能、1つだけに絞った結果、シンプルかつデザイン要素が少なくなったのが良かった Good

Slide 24

Slide 24 text

個人でサービスを作る raysCI プルリクごとのベンチマークサービスチーム　企画・デザイン・開発: 僕 2017年5月開発スタート 10月クローズドリリース一般で利用してもらえるレベルまで到達できず凍結

Slide 25

Slide 25 text

個人でサービスを作る raysCI プルリクごとのベンチマークサービスチーム　企画・デザイン・開発: 僕 2017年5月開発スタート 10月クローズドリリース一般で利用してもらえるレベルまで到達できず凍結サービスの規模とリソースのかけ方が明らかに間違っていた。開発だけでも苦しいのに全部やろうとしたのは無理筋大量に余っていた有給を使って毎週休んで開発に当ててたけど圧倒的に時間が足りなかった Bad

Slide 26

Slide 26 text

Slide 27

Slide 27 text

個人でサービスを作る raysCI プルリクごとのベンチマークサービスチーム　企画・デザイン・開発: 僕 2017年5月開発スタート 10月クローズドリリース一般で利用してもらえるレベルまで到達できず凍結技術的知見は得られた。GCP, k8s, GitHub apps, ベンチマーク手法, グラフ描画などなど Good

Slide 28

Slide 28 text

個人でサービスを作る raysCI プルリクごとのベンチマークサービスチーム　企画・デザイン・開発: 僕 2017年5月開発スタート 10月クローズドリリース一般で利用してもらえるレベルまで到達できず凍結ユーザの使い勝手（easy）をリリース前から重要視しすぎて、開発工数が肥大化していってしまった。作り込みすぎた悪い例として、Dockerﬁle の自動生成だったり、テストデータの自動生成だったり、ベンチマーク用コードの自動挿入だったり… Bad ダサくても、使いにくくてもいいから、サービスが問題を解決するのか、ユーザヒアリングから入ったほうが良かった

Slide 29

Slide 29 text

チームでサービスを作る noco 縦書きで書けるプラットフォームチーム　ディレクション: 1名　デザイン: 1名　開発: 僕 1年の間に2度のピボットし現在ベータリリースで開発中

Slide 30

Slide 30 text

チームでサービスを作る noco 縦書きで書けるプラットフォームチーム　ディレクション: 1名　デザイン: 1名　開発: 僕 1年の間に2度のピボットし現在ベータリリースで開発中役割分担が明確でちょうど良かった Good

Slide 31

Slide 31 text

チームでサービスを作る noco 縦書きで書けるプラットフォームチーム　ディレクション: 1名　デザイン: 1名　開発: 僕 1年の間に2度のピボットし現在ベータリリースで開発中 3人それぞれのプロジェクトで実現したいことが違うのを、ちゃんと認識できておらず意見が分かれることが多かったディレクター : 素早く製品レベルにもっていきたいデザイナー : 自分が納得するものをじっくり作りたい僕 : 技術的挑戦と品質のクオリティには拘りたい Bad 3人それぞれのやりたいこと・スピード感を共有しなおした上で、改めてプロジェクトで実現したいものを定義した

Slide 32

Slide 32 text

チームでサービスを作る noco 縦書きで書けるプラットフォームチーム　ディレクション: 1名　デザイン: 1名　開発: 僕 1年の間に2度のピボットし現在ベータリリースで開発中うまくいくかどうか分からない中で、実際に狙っているユーザに使ってもらい、フィードバックを元に大きくプロダクトの方向性を変えられたのは良かった Good

Slide 33

Slide 33 text

ピボットの流れ

Slide 34

Slide 34 text

最初はチャット型コンテンツを Markdown や LINE UI 風に作ることができるエディタを目指していた

Slide 35

Slide 35 text

Markdown 良いんだけど、狙ってるユーザ層は Markdown 使わない…シンプルにして、同時編集もできるようなモデルにしよう→Markdown 削除

Slide 36

Slide 36 text

何でも書けるだと何にも書いてもらえない…特化させよう→「旅」はどうだろう？旅に特化して写真コンテンツをメインに。位置情報や地図なども挿入できるようにした。

Slide 37

Slide 37 text

旅好きユーザからのフィードバックは芳しくなかったので原点回帰でクリエイター向けへ。なんやかんやあって縦書きにしてみるかというところで現在開発中。

Slide 38

Slide 38 text

自分で書いたコードを容赦なく消していくの楽しい

Slide 39

Slide 39 text

個人開発を失敗しないためにはなるべく

Slide 40

Slide 40 text

目的はシンプルに1つだけに絞る誰のために作るのかを明確にするメンバーの大事にしたいことを知るユーザの声を早く知る

Slide 41

Slide 41 text

おしまい