Upgrade to Pro — share decks privately, control downloads, hide ads and more …

失敗から学ぶ個人開発

zaru
May 29, 2019

 失敗から学ぶ個人開発

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

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

zaru

May 29, 2019
Tweet

More Decks by zaru

Other Decks in Technology

Transcript

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

    View Slide

  2. @zaru
    ベーシック CTO

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  6. ふりかえり

    View Slide

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

    View Slide

  8. 個人でライブラリを作る
    seed_builder
    Rails でテスト用データを自動生成
    リレーションやバリデーションを考慮したテスト
    用のデータを自動で良い感じに作ってくれる gem
    mailcraft
    指定メールアドレスに届いたデータを API で受け取れる
    メールアドレスと Endpoint を送ると、代理でメールを
    受信し、コンテンツを指定 Endpoint へ POST するだけ
    のサービスとライブラリ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  19. モチベーションのスライド
    当初のモチベーションは「自分が必要だから作る」だったけど、そこから「色んな人に使っ
    てもらう」にスライドすることにした。それを達成するために、以下の3つに絞って行動す
    ることに決めた。
    ・存在を知ってもらうための活動
    ・使ってもらいやすくするための活動
    ・プルリクを投げてもらいやすくするための活動
    awesome-ruby にプルリクを送って
    webpush を載せてもらった。その影
    響かわからないけど、ダウンロード
    数は2〜3倍くらい伸びた。

    View Slide

  20. モチベーションのスライド
    当初のモチベーションは「自分が必要だから作る」だったけど、そこから「色んな人に使っ
    てもらう」にスライドすることにした。それを達成するために、以下の3つに絞って行動す
    ることに決めた。
    ・存在を知ってもらうための活動
    ・使ってもらいやすくするための活動
    ・プルリクを投げてもらいやすくするための活動
    バッジで状態を可視化
    readme を改善して、迷わず使える状
    態にしたいけどできていない…

    View Slide

  21. モチベーションのスライド
    当初のモチベーションは「自分が必要だから作る」だったけど、そこから「色んな人に使っ
    てもらう」にスライドすることにした。それを達成するために、以下の3つに絞って行動す
    ることに決めた。
    ・存在を知ってもらうための活動
    ・使ってもらいやすくするための活動
    ・プルリクを投げてもらいやすくするための活動
    テストコードはカバレッジ100%なの
    で、rubocop を導入して最低限の
    コードフォーマットを揃えた。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  33. ピボットの流れ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  41. おしまい

    View Slide