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