失敗から学ぶ個人開発

いくつかの個人開発をしていて失敗したことから学ぶなんたらかんたら。個人開発は苦しい瞬間もあるけど基本的には楽しいよ。

【ベーシック×GIG】エンジニアがスキルアップするための文化・組織づくりLT大会！
https://giginc.connpass.com/event/129254/

Transcript

1. 失敗から学ぶ個人開発 2019.05.29 @zaru
2. @zaru ベーシック CTO
3. いくつかの個人開発プロジェクトをやっ てきたけど、いくつかは失敗している
4. いくつかの個人開発プロジェクトをやっ てきたけど、いくつかは失敗している ここでの失敗の定義は完成できなかったり 放置してたりする状態のこと
5. なぜ失敗したのか、失敗しないためには どうしたら良かったのか振り返ってみた ちょっと
6. ふりかえり
7. 個人開発のパターン 個人でサービスを作る 個人でライブラリを作る チームでサービスを作る
8. 個人でライブラリを作る seed_builder Rails でテスト用データを自動生成 リレーションやバリデーションを考慮したテスト 用のデータを自動で良い感じに作ってくれる gem mailcraft 指定メールアドレスに届いたデータを API で受け取れる メールアドレスと Endpoint を送ると、代理でメールを 受信し、コンテンツを指定 Endpoint へ POST するだけ のサービスとライブラリ
9. 個人でライブラリを作る seed_builder Rails でテスト用データを自動生成 リレーションやバリデーションを考慮したテスト用 のデータを自動で良い感じに作ってくれる gem mailcraft 指定メールアドレスに届いたデータを API で受け取れる メールアドレスと Endpoint を送ると、代理でメールを 受信し、コンテンツを指定 Endpoint へ POST するだけ のサービスとライブラリ 完璧な easy を目指しすぎて要件が肥大化 いつまでもリリースできない状態 Bad 最初から完璧目指すのは無理なので、 割り切った仕様にすべきだった
10. 個人でライブラリを作る seed_builder Rails でテスト用データを自動生成 リレーションやバリデーションを考慮したテスト用 のデータを自動で良い感じに作ってくれる gem mailcraft 指定メールアドレスに届いたデータを API で受け取れる メールアドレスと Endpoint を送ると、代理でメールを 受信し、コンテンツを指定 Endpoint へ POST するだけ のサービスとライブラリ 作っていく中で周りの人にヒアリ ングしたけど誰も欲しがらなかっ たので途中でやめてしまった Bad 自分が本当に欲しかったら周りの声を 気にせず完成させるべきだった。誰の ために作るのかを明確にしたほうが良 かった
11. チームでサービスを作る pushnate ブラウザにプッシュ通知をするサービス チーム 　企画・ディレクション: 1名 　デザイン・開発 : 僕 2015年5月開発スタート 8月βリリース 2018年8月くらいまで継続改善
12. チームでサービスを作る pushnate ブラウザにプッシュ通知をするサービス チーム 　企画・ディレクション: 1名 　デザイン・開発 : 僕 2015年5月開発スタート 8月βリリース 2018年8月くらいまで継続開発メンテ やるべき事とやらない事の整理を してもらったのと、開発以外のこ と「マーケ」「問い合わせ対応」 「コンテンツ作り」を全部やって くれたので開発に集中できた Good
13. チームでサービスを作る pushnate ブラウザにプッシュ通知をするサービス チーム 　企画・ディレクション: 1名 　デザイン・開発 : 僕 2015年5月開発スタート 8月βリリース 2018年8月くらいまで継続改善 他企業などから競合サービスがど んどん出してくる中で、優位性を 作り込んでいく工数を割くことが できなかった Bad 撤退ラインが中途半端になっていたの で、他社売却・譲渡含めて決めるべき だった
14. 個人でライブラリを作る webpush Ruby でブラウザのプッシュ通知をする pushnate のサービス開発時に配信ロ ジックを OSS 化。mastodon や dev.to 、配信サービスなどで利用されてい るっぽい
15. 個人でライブラリを作る webpush Ruby でブラウザのプッシュ通知をする pushnate のサービス開発時に配信ロ ジックを OSS 化。mastodon や dev.to 、配信サービスなどで利用されてい るっぽい Google の node npm の次に公開でき たので、利用してくれるプロジェクト が増えた。そして、プルリクや issue をもらいやすい状況に。 Good
16. 個人でライブラリを作る webpush Ruby でブラウザのプッシュ通知をする pushnate のサービス開発時に配信ロ ジックを OSS 化。mastodon や dev.to 、配信サービスなどで利用されてい るっぽい pushnate サービス停滞と共にメン テしなくなってプルリクと issue が溜まってしまった… Bad
17. 初期から精力的にコントリビューションしてくれていた @rossta から嬉しい申 し出。信頼できる人だったので権限を移譲。バッサバッサとプルリクと issue を さばいてくれた。使われているけど自分がメンテする気がないなら権限委譲は やっていったほうが良い（ただし信頼できる人）。 これをキッカケに自分ももう一度メンテナンスをしよう…と思い直す。
18. モチベーションのスライド 当初のモチベーションは「自分が必要だから作る」だったけど、そこから「色んな人に使っ てもらう」にスライドすることにした。それを達成するために、以下の3つに絞って行動す ることに決めた。 ・存在を知ってもらうための活動 ・使ってもらいやすくするための活動 ・プルリクを投げてもらいやすくするための活動
19. モチベーションのスライド 当初のモチベーションは「自分が必要だから作る」だったけど、そこから「色んな人に使っ てもらう」にスライドすることにした。それを達成するために、以下の3つに絞って行動す ることに決めた。 ・存在を知ってもらうための活動 ・使ってもらいやすくするための活動 ・プルリクを投げてもらいやすくするための活動 awesome-ruby にプルリクを送って webpush を載せてもらった。その影 響かわからないけど、ダウンロード 数は2〜3倍くらい伸びた。
20. モチベーションのスライド 当初のモチベーションは「自分が必要だから作る」だったけど、そこから「色んな人に使っ てもらう」にスライドすることにした。それを達成するために、以下の3つに絞って行動す ることに決めた。 ・存在を知ってもらうための活動 ・使ってもらいやすくするための活動 ・プルリクを投げてもらいやすくするための活動 バッジで状態を可視化 readme を改善して、迷わず使える状 態にしたいけどできていない…
21. モチベーションのスライド 当初のモチベーションは「自分が必要だから作る」だったけど、そこから「色んな人に使っ てもらう」にスライドすることにした。それを達成するために、以下の3つに絞って行動す ることに決めた。 ・存在を知ってもらうための活動 ・使ってもらいやすくするための活動 ・プルリクを投げてもらいやすくするための活動 テストコードはカバレッジ100%なの で、rubocop を導入して最低限の コードフォーマットを揃えた。
22. 個人でサービスを作る LightningQR URL を QR コードに変換する チーム 　企画・デザイン・開発: 僕 1週間ほどでさくっと作成 NotifyHub GitHub の情報を通知 チーム 　企画・デザイン・開発: 僕 1年くらいダラダラと開発。完成はしてい ないけど自分が使う分には要件を満たした ので開発停止
23. 個人でサービスを作る LightningQR URL を QR コードに変換する チーム 　企画・デザイン・開発: 僕 1週間ほどでさくっと作成 NotifyHub GitHub の情報を通知 チーム 　企画・デザイン・開発: 僕 1年くらいダラダラと開発。完成はしてい ないけど自分が使う分には要件を満たした ので開発停止 自分が本当に必要だと思った機能、1つ だけに絞った結果、シンプルかつデザ イン要素が少なくなったのが良かった Good
24. 個人でサービスを作る raysCI プルリクごとのベンチマークサービス チーム 　企画・デザイン・開発: 僕 2017年5月開発スタート 10月クローズドリリース 一般で利用してもらえるレベルまで到達できず凍結
25. 個人でサービスを作る raysCI プルリクごとのベンチマークサービス チーム 　企画・デザイン・開発: 僕 2017年5月開発スタート 10月クローズドリリース 一般で利用してもらえるレベルまで到達できず凍結 サービスの規模とリソースのかけ方が明らかに 間違っていた。開発だけでも苦しいのに全部や ろうとしたのは無理筋 大量に余っていた有給を使って毎週休んで開発 に当ててたけど圧倒的に時間が足りなかった Bad
26. 個人でサービスを作る raysCI プルリクごとのベンチマークサービス チーム 　企画・デザイン・開発: 僕 2017年5月開発スタート 10月クローズドリリース 一般で利用してもらえるレベルまで到達できず凍結 サービスの規模とリソースのかけ方が明らかに 間違っていた。開発だけでも苦しいのに全部や ろうとしたのは無理筋 大量に余っていた有給を使って毎週休んで開発 に当ててたけど圧倒的に時間が足りなかった Bad 巻き込み力をつけるべき by こくしんさん
27. 個人でサービスを作る raysCI プルリクごとのベンチマークサービス チーム 　企画・デザイン・開発: 僕 2017年5月開発スタート 10月クローズドリリース 一般で利用してもらえるレベルまで到達できず凍結 技術的知見は得られた。GCP, k8s, GitHub apps, ベンチマーク手法, グラ フ描画などなど Good
28. 個人でサービスを作る raysCI プルリクごとのベンチマークサービス チーム 　企画・デザイン・開発: 僕 2017年5月開発スタート 10月クローズドリリース 一般で利用してもらえるレベルまで到達できず凍結 ユーザの使い勝手（easy）をリリース前から重要視し すぎて、開発工数が肥大化していってしまった。 作り込みすぎた悪い例として、Dockerfile の自動生成 だったり、テストデータの自動生成だったり、ベンチ マーク用コードの自動挿入だったり… Bad ダサくても、使いにくくてもいいか ら、サービスが問題を解決するのか、 ユーザヒアリングから入ったほうが良 かった
29. チームでサービスを作る noco 縦書きで書けるプラットフォーム チーム 　ディレクション: 1名 　デザイン: 1名 　開発: 僕 1年の間に2度のピボットし現在ベータリリースで開発中
30. チームでサービスを作る noco 縦書きで書けるプラットフォーム チーム 　ディレクション: 1名 　デザイン: 1名 　開発: 僕 1年の間に2度のピボットし現在ベータリリースで開発中 役割分担が明確でちょうど良かった Good
31. チームでサービスを作る noco 縦書きで書けるプラットフォーム チーム 　ディレクション: 1名 　デザイン: 1名 　開発: 僕 1年の間に2度のピボットし現在ベータリリースで開発中 3人それぞれのプロジェクトで実現したいことが違うの を、ちゃんと認識できておらず意見が分かれることが多 かった ディレクター : 素早く製品レベルにもっていきたい デザイナー : 自分が納得するものをじっくり作りたい 僕 : 技術的挑戦と品質のクオリティには拘りたい Bad 3人それぞれのやりたいこと・スピー ド感を共有しなおした上で、改めてプ ロジェクトで実現したいものを定義し た
32. チームでサービスを作る noco 縦書きで書けるプラットフォーム チーム 　ディレクション: 1名 　デザイン: 1名 　開発: 僕 1年の間に2度のピボットし現在ベータリリースで開発中 うまくいくかどうか分からない中で、実 際に狙っているユーザに使ってもらい、 フィードバックを元に大きくプロダクト の方向性を変えられたのは良かった Good
33. ピボットの流れ
34. 最初はチャット型コンテンツを Markdown や LINE UI 風に作ることがで きるエディタを目指していた
35. Markdown 良いんだけど、狙ってるユー ザ層は Markdown 使わない…シンプルに して、同時編集もできるようなモデルに しよう→Markdown 削除
36. 何でも書けるだと何にも書いてもらえな い…特化させよう→「旅」はどうだろ う？ 旅に特化して写真コンテンツをメイン に。位置情報や地図なども挿入できるよ うにした。
37. 旅好きユーザからのフィードバックは芳 しくなかったので原点回帰でクリエイ ター向けへ。 なんやかんやあって縦書きにしてみるか というところで現在開発中。
38. 自分で書いたコードを 容赦なく消していくの楽しい
39. 個人開発を失敗しないためには なるべく
40. 目的はシンプルに1つだけに絞る 誰のために作るのかを明確にする メンバーの大事にしたいことを知る ユーザの声を早く知る
41. おしまい