投稿日:2019-12-16最終更新:2020-01-07クロス元の投稿をみる(https://qiita.com/cdm...)はじめに個人開発というのはやはり難しく、サービスのアイデアを考え、設計し、実装して、運用するといった過程の中で何度も壁が立ちはだかります。その内容は技術面、マインド面、環境面など様々です。今後も個人開発を続けていく中で、自分はもちろん他の開発者さんが同じ壁にぶつからないよう、また、ぶつかってもすぐに乗り越えられるよう、僕の経験ベースでその壁の乗り越え方をシンプルに淡々とまとめていきたいと思います。誰もが一度はぶつかるであろう壁から、それあなただけでしょって壁まで様々ですが、少しでも参考になったら嬉しいです!筆者についてサービスを作るのが趣味で普段からWebサービスをゼロから作って、育てて、時には壊してというのを繰り返しています。最近はアプリ開発の方も頑張ってます。1年前はこんな記事も書きました。気軽にアウトプットできる技術ブログサービス「Qrunch(クランチ)」をリリースしたQiitaに投稿するのはそれ以来なので若干緊張気味です。:★★★★☆どんな壁?:いざWebサービスを作ろうとしても何もアイデアが思い浮かばない解決策:身近な課題をひたすら探すサービスを作る上では何かを解決する系のアイデアであり、かつ自分が当事者であるとモチベーションも続きやすいです。自分が普段ネットを使っていて不便だと思うこと、今使っているサービスの不満点、などなんでも良いのでとりあえず書き出してみましょう。大体この中に自分の技術力でも解決できるような課題が存在します。自分の中での課題が見つからないという場合は、日々Twitterのタイムラインで流れてくる身近な人が抱えている課題をピックアップしてアイデア化するのもありです。回避策:しょぼいアイデアでも日々書き残していくいざサービスを作るというときにアイデアも出ないし身近な課題すら見つからない場合は、普段からアイデアを無理やり出して書き残しておく癖をつけると良いです。上の画像は以前僕がNotionでまとめていたシートの例です。この時は「1日3個のアイデアを生み出す魔法のシート」と名付けて、どんなにしょぼいようなアイデアでも毎日朝・昼・晩の3個出してメモし続けるようにしていました。結果、アイデアを考える癖というものがかなり身に付きましたし、その中からも何個か形にして現在も成長してるサービスもあります。アイデアが考えれない方はぜひ参考にしてみてください。そのうち100、200とアイデアが溜まっていき、気づいたらかなりな資産になっています。:★★★★★どんな壁?:アイデアは思いつき実装に取り掛かったものの、途中でモチベーションが続かなくなり結局プロジェクトを放置してしまう回避策:まずデプロイしてしまうWebサービスを開発する上では、ローカルでひたすら作りこんである程度完成したらデプロイしてリリースという流れが一般的ですが、この方法だと最後のデプロイに辿りつく前に力尽きて投げ出してしまうというパターンに陥りやすいです。いうことで僕は最低限の環境構築ができたらまずデプロイしてしまうということをしています。これによって、サービスをリリースするということに対するハードルがかなり下がり、開発途中でモチベが下がるということも相当減りました。このパターンを採用する際は最低限のベーシック認証とクローラー拒否設定は必ずしておきましょう。content="nofollow">回避策:覚えたての技術の練習場所にしないこれは自分もよくやってしまうのですが、エンジニアは何か新しい技術を覚えた際に「せっかくだからこの技術を使ってサービスも作ってしまおう」という考えになりがちです。サービスを作る目的が「技術力の向上」なのであれば良いですが、「ユーザーに何らかの価値を届けること」が目的なのであれば、やむを得ず新しい技術を使う場合以外、絶対に慣れた技術を使ったほうが良いです。僕は今まで、ユーザーに何らかの価値を届けることが目的だけどついでに新しい技術も習得しちゃおうなんてことを何度もやってきましたが、それらのプロジェクトはほぼ全て途中で疲れて辞めちゃいました。サービスを作る上での目的をブレずに持ち続けるべきです。:★★★★☆どんな壁?:授業や仕事で個人開発の時間がとれない。開発リソースが足りずに全く進捗がでない回避策:どこで妥協するかを決めておくある程度プログラミングに慣れてきた段階にいる時こそ、完璧を追い求めがちになってしまい、あれもこれも自分の手で作って結局手一杯みたいなことになりがちです。サーバー管理が面倒なのであればHerokuを使ってもいいですし、本来自動で処理すべき機能も始めは手動でリリースして余裕ができてから自動化してもOKです。極論、テストコードだって必要性を感じるまでは書かなくてもOKです。サービスの本質的でない部分はどんどん手を抜いて、後から余裕ができたら補強していくという考え方がベストだと思います。回避策:技術的な資産を作る・使う多少のデザインは違えど、Webサービスは「使い回せるパーツ」が数多く存在するので、そういったコードは汎用性を持たせた状態でGitHubリポジトリかなんかに保存させておいて、使いたい時にコピペして使い回せるようにしておきます。自分はよくRailsを使ってサービスを作るのですが、「外部ログイン機能を持ったSNS系サービスのRailsプロジェクト」「テキスト投稿系サービスのRailsプロジェクト」というように後々同じ形式のサービス作りそうだなと思った時点でパッケージ化してこれもGitHubにあげちゃいます。それに加えて、開発環境や本番環境、DBなどのインフラ部分は必ずDockerコンテナの上に載せて、これも汎用的なものがあればイメージをexportさせて使い回せるようにさせています。example-container.tarこうすることで無駄なコーディングを減らし、サービスづくりの本質的な部分にちゃんと労力を掛けることができるようになるので個人的におすすめです。Bootstrapは、レスポンシブ対応で配色パターンも指定されており、チーム開発の現場でも効率的に実装を勧められるなどメリットが沢山ありますが、CSSのサイズが膨大だったり、jQuery依存な箇所があったり、既に指定されているスタイルが邪魔をして逆にカスタマイズしにくいなどといったデメリットも多いです。スクラッチのどちらかに移行したほうがいろいろと楽ですし、”個人開発”っぽい見た目からも脱却できます。回避策:それっぽくなる配色を選ぶあまりデザインに凝ってないサイトでも、配色さえちゃんとしてれば、それっぽいサイトに見せることができます。色彩感覚に自信がなくても、配色ツールなどが沢山ありますので、それらに頼ればOKです。僕が普段からよくお世話になっているサイトを以下に紹介しておきます。Insights:https://developers.google.com/speed/pagespeed/insights/ここでは、フロント側が原因なのかサーバー側が原因なのかが分かれば良いので、項目としては「サーバー応答時間」と全体の速度に着目すればOKです。DBサーバー間のネットワーク環境の確認nginxやApacheなどのサーバーソフトウェアの設定値等の確認SQL文の見直し(N+1問題を引く起こすクエリはないかなど)などをメインに追っていき、問題箇所をひたすらチューニングしていきます。経験上、フロント側の速度は画像やファイル等のサイズを最適化するだけで大幅に改善するので基本的にはそのくらいで大丈夫かなと思います。Insightsでの点数が高いからといって、ユーザーの体感速度も速いというわけでもないので、ある程度の点数が取れて問題なさそうだったら、特にこだわりとかがない限りそこでチューニングは打ち切って良いです。:★★★★☆どんな壁?:リリースまでたどり着いたが、だれにも使ってもらえない。そもそもサイトに訪問してくれない回避策:ターゲットとなるユーザーに直接アプローチを掛けるリリースしたけど誰にも使ってもらえない場合は、TwitterやFacebookでターゲットになりそうな人を探して直接アプローチを掛けます。アプローチの内容はフォロー、いいね、リプライ、DMなど様々ですがこれはターゲットの属性をみながら適切な方法を選びましょう。下手に身近な人に使ってもらおうとしても、そもそもその人がサービスのターゲットユーザーではない可能性が高いので注意が必要です。回避策:サービスを紹介できるサービスを使うインターネット上には自分が作ったWebサービスを紹介できるサービスが存在します。掲載したからといってドンとユーザーが来るわけではありませんが、基本的に無料で掲載できますので誰にも使ってもらえない場合は有効活用します。:★★★★☆どんな壁?:サービスをリリースしたが、コンテンツがないため人が集まらず、人が集まらないためコンテンツも生まれない回避策:過疎っているようにみせない工夫をするたとえ内部の実情としては過疎っていたとしても、初めてサイトに足を運んだ人からは過疎っていないようにみせる工夫が必要です。過疎っているようにみせない工夫の例を以下に挙げておきます。:★★★☆☆どんな壁?:サービスをリリースできたが、サーバー代が高くてやっていけない回避策:ひたすら無料プランを攻める誰もが真っ先に思いつくことではありますが、サーバー費用を徹底的に抑えたい方は、AWS、Azure、GCPなどで提供されている無料枠を使いつぶすという手があります。各クラウドサービスの無料枠については以下の記事で解説されているので気になる方はご参考ください。構成にする上の回避策と相反する内容ではありますが、便利だし技術的挑戦のために全部AWSで構成する!みたいなことをやるともれなく高額の請求がきます。クラウドは、企業が運営しているような大規模サービスではコスパが発揮されますが、小中規模のサービスの運用では逆にコスパが悪くなってしまう可能性が高いです。無料枠で収まらない可能性が高いのであれば、オールクラウドは少し考えた方が良いでしょう。個人的におすすめなサーバー構成としては、さくらやConoHaなどのVPSサービスに、AWSのS3やCloudfrontを併せて使うという方法です。無料枠を使わずとも1500円前後で1つのサービスが運用可能です。:★★☆☆☆どんな壁?:リリースしたサービスが無事にバズったが、サーバーがパンクしサービスが利用できなくなる回避策:はじめから最低限スケール可能な構成にしておくL4でもL7でもどちらでも良いのでリリース前からロードバランサは噛ませておくと良いです。ConoHaのL4ロードバランサだと月額1000円、自前で実装するL7ロードバランサだと月額600円程度で利用可能です。オートスケールまではしなくてもこうしとくだけで、リリース後のバズで負荷が掛かっても、サーバーをクローンさせて割り振るIPを追加すればいいだけなのでかなり安心です。あるとないとでは大違い。謝れる準備をしておく下で紹介するその10でも通じることですが、もし何かしらの原因でサービスが落ちた場合、できるだけ早く現状と予定を通知できるようにいざという時どう対応すればいいかをマニュアル化して残しておくとよいです。:★☆☆☆☆どんな壁?:運用しているサービスがDDoSなどの外部攻撃を受けて瀕死状態になってしまう回避策:オリジンサーバーのIPを隠す以前、リリースしたてのサービスにDDoS攻撃があり、ロードバランサ、数台のAPPサーバー、DBサーバーが全てダウンしてしまうことがありました。その後、様々な人に助けれて解決したわけですが、結論からいうとCloudFlareやAWSのCloudFrontなどの負荷分散機能付きのCDNサービスを上段に噛ませてあげることで対策ができました。個人サービスにDDoS攻撃などが来ることは滅多にないので必ず対策すべきとまではいきませんが、Cloudflareなどは無料枠でも十分に利用することができるので、ひと手間かけて対策しとく分には損はないかなと思います。:★★★☆☆どんな壁?:リリースしたサービスが無事にバズってユーザーが一気に流入したけど、ニ週間後には殆どがいなくなってしまった。実際に運営しているサービスのアクティブユーザーの推移これはサービス毎に原因が様々なので、以下抽象的な内容になっていますがご了承ください。バブルが弾けてもあきらめない特にコミュニティ系・CGM系のサービスで、リリース初期にバズったことで人がたくさん集まったがその後殆どいなくなる、なんてことを経験するともれなく精神がボロボロになります(上図でいう1から2)。少なくとも開発仲間がいればその辛さを分け合えますが、個人開発となるとそれはもう・・・。開発した本人からみても、コンセプトの段階から明らかにズレていたなどといった場合を除いて、2の状態が続いてもあきらめずにサービスの改善を続けましょう。穴が開いたバケツを修繕する図中2の状態に陥ったらまずなぜ人が離脱していったかを考えます。人がいなくなったから直ぐにまた宣伝などして呼び込もうとせずに、サービスの根本的な部分から疑って、改善すべき部分を時には1から実装し直すなどして作り直していきましょう。新規ユーザーの流入元を確保する完璧ではなくともサービスの改善が出来てきたら、次は新規ユーザーの流入元を確保するフェーズに入ります。ここで一番手っ取り早いのがSEO。サービスに関連するコンテンツを自分で追加するなりして地道に検索流入を増やしていきます。それと同時に他に改善すべきところはないかを少しずつ探り、随時修正していきましょう。後はひたすらこれの繰り返しです。:★★★☆☆どんな壁?:開発と運用を全て一人でこなしているため、リソースが足りず、一部の運用やユーザー対応などに手が回らなくなってしまう解決策:無駄な作業は意識的に自動化していくサービスの機能追加や改善だけに手を取られていると、メンテナンスに掛かるコストが増大して最悪の場合サービスを閉鎖せざるを得ないところにまで陥ることもあります。サービスを個人で作り運用していく以上、使えるリソースは限られていますので、手動で行っている無駄な作業は意識的に自動化していきましょう。時には外部ツールに頼るのもありです。:★★★☆☆どんな壁?:CGM系のサービスを運用していると、「誰かが投稿してくれたかな?」などといったことが気になり何度もサイトを確認しにいってしまう。解決策:SlackやLINEを最大限活用するサービス上で何かイベントが起きる度にSlackやLINEに通知を送るようにします。それぞれAPIキー等を登録さえすれば1行2行のコードでPush通知を送れるので、スマホでも気軽に確認ができます。以下はRailsでgemを使った場合のコード例になります。ある日突然検索流入が激減する遭遇確率:★★☆☆☆どんな壁?:今までサービスにあった検索流入がある日突然なくなった。どのページへの流入がなぜなくなったかが全く分からない。回避策:日頃から検索順位を追っておくサービス内のコンテンツに関係する検索ワードは日頃から順位を追っておき、Googleのアルゴリズムアップデートの影響などをいち早く察知できる状態を整えておくと安心です。検索順位チェック専用のツール等も存在しているので、CGM系サービスの運営者さんとかは色々調べておくといいかもです。使うことをおすすめしておきます(...!)おわりに以上が個人開発をしてきて僕がぶつかった壁とその解決策まとめでした。Qrunch.netサーバー提供フィードバックを送信する。