みんなの「作ってみた」

はじめての個人開発で挫折しなかった理由を分析する

2019/04/13

ginooosuke
ginooosuke

はじめに

今回初めて個人開発をしてプレリリース（Twitterで公開連絡）までできたので、今回の開発がどうしてプレリリースまでできたのかを振り返ってみようと思います。
個人開発とは言っていますが、友人(如月みなと)と二人での開発の記録になります。

対象とする読者

  • 個人開発をしたことがない人
  • 個人開発のモチベーションが維持できなかった人

筆者について

普段は Ruby on Rails でサーバサイドを担当している開発者です。AWS は業務で触っております。

作ったサービスについて

今回作ったサービスは、アイカツの同人イベントのサークルチェックを楽にするアプリです。
CCアイカツ

挫折しなかった理由

友人と二人で作り始めた

おそらくここが一番大きかったと思います。二人で作ることで得られた恩恵として、

  • アプリの役割から脱線しにくい
  • フィードバックが受けられる

がありました。

アプリの役割から脱線しにくい

今回の開発では最初にどういうものを作るかを決めて始めました。しかし、いつのまにか役割以上の機能を作りたくなり機能過多になり始めます。そうなった時には必要かどうか検証し、目的を見つめ直すことができます。自分が作っていない部分の機能は比較的冷静に見ることができますが、ひとりで開発をしていると見直す機会をつくるのは難しいです。個人開発に慣れていない人ほど難しいのではないかと思います。早い段階で修正できたのは大きかったです。

フィードバックが受けられる

基本的にサービスを見てくれる人はいないので、今のUIが優れているかをチェックするのは難しいです。開発側はどういう仕様になっているか知っているため、使いにくい部分をハックして使うように動作が最適化されていきます。そうなると使いにくい部分が見えにくくなり、悪いユーザ体験を残し続けることになります。
開発している範囲が違うと仕様を知らない状態になり、相手からのフィードバックが受けられる状態になります。使用する端末が違うため感じ方も違うため、フィードバックが得られる環境は非常に重要でした。

以上が二人で開発をした利点になります。他にも知識を補完しあえたり役割を分けたりなどがありましたが、大きかったのは上の二つでした。

やりたいと思ってからやり始めるまでのスピード

私がこのサービスを作りたいと思ってたのが 3月6日 で、次の日にはスプレッドシートに取得された画像が並んでいました。どういうものかの雰囲気が早くつかめることで、どういう課題があるかを知ることができます。モチベーションは時間が経てば落ちていくので、落ちる前に次の行動を起こせるかが鍵になると思いました。最初から100点を取ろうとすると絶対に頓挫するので、1点を積み上げて100点を目指すという気持ちで取り掛かるのが大切でした。

なぜ作りたいかのモチベーションを明確にした

このサービスを作った理由は、イベントのたびに全てのサークルをチェックするのが非常に大変で、もうその苦労をしたくなかったからでした。約 400 のサークルの Twitter アカウントを、前日にひとつずつクリックしていく必要があります。
そのうえ念入りにサークルチェックをしたと思ったのに必ず買い逃しが発生する。そうならないように、定期的にサークルチェックをする事で買い逃しが防げると思いました。

このサービスで担保する役割を明確にした

最初はこのサービスで Twitter ログインしてデータを管理できるようにするつもりでしたが、認証を入れる事で開発にかかる時間は大きく増えることが予想されました。そこでこのサービスでは「このアプリで画像をチェックして、リアクション（リツートやいいね）は Twitter 側で行う」としました。役割を明確にした事で、このアプリでは必要以上な連携機能は作らないことになりました。
役割が明確になると、このアプリが向かうべきゴールが決まります。ゴールが決まるとあとは作っていくだけなので、このサービスがある事で何をよくすればいいのかを決めることは非常に重要でした。

目的を達成出来る最小限の構成から考えた

多くの技術スタックを詰め込むことで、よりリッチなものはできていきますがその分詰まりやすくなります。フロントエンドを学習したい気持ちとは別に、必要十分なところから始めました。
一番最初に取り組んだのは、Google App Script(GAS) を使ってサークルリストを抜き出し、抜き出したアカウントから画像を抽出する部分でした。GAS はバッチ処理をさせることもできるので、この時点で必要な画像を取り出せるようにはなっていました。ただし、画像が小さく確認するのには不向きであることがわかったため、この時点で画像を見やすくする Web アプリケーションをつくる必要が出てきました。
次にWeb アプリケーションを作る際もサーバを管理したくなかったため、Amazon S3 の静的ホスティングについて調べました。HTTSにするためにCloudFrontを使ったり、独自ドメインを使うためにRoute53でドメインを登録したりしました。複数のことを同時にやるのではなく、最小限の構成から拡張していくことが未経験のスキルを習得する上で大切でした。
ただし拡張できない作り方になる場合もあるため、どういう作りになっていくかをざっくりと予想しておく必要はあると思います。今回は JSON API <-> Vue.js という設計は変わらなかったですが、MySQL などのデータベースの接続にしていたら別にやることが増えていたと思います。

常に課題を管理した

次に何をしないといけないかを管理することが、モチベーションを管理することにもつながります。やることがなくなってしまうと課題を抽出することに体力が必要になるため、アプリケーションを改善するスピードが遅くなります。開発のスピードが落ちるとモチベーションも低下しやすくなります。
課題の管理も手軽であればあるほど良いと思っています。GitHub Issue がめんどくさいようであれば別の手段を使えば良いと思います。今回は Google Keep をつかって管理しました。コミットとバグの対応を管理するには向いていませんが、ふたりで課題を管理する上では非常に手軽でした。

面倒な作業は自動化した

普段の業務にも共通する話かもしれませんが、できる限り繰り返す処理は自動化します。今回の場合は、Circle CI を使ってアプリのビルド、デプロイまでは自動化しました。ローカルでビルドしたものをS3にコピーする作業ですらストレスのかかる作業です。めんどくさいことは自動化して、どんどん思考から外すことで、体力をやりたいことに向けることができました。

最後に

抽象的な話になってしまいましたが、開発の過程を振り返ってみました。アプリケーションを作る上で参考になれば幸いです。やっぱり実際に手を動かしてみることは大切で、アプリをリリースしなくても多くのことを学習できました。次はコンテナあたりを触ってみたいです。
最後に、頑張って作ったアプリなのでたくさんの人に触ってもらいたいです。同じ悩みを抱えている人を少しでも助けられたら嬉しいです。

おまけ：今回のアプリ作成で学べたこと

初めて知ったこと、やったこと、感じたことをざっと書き並べてみます。

  • GAS で Twitter の API を叩くことができる
  • GAS で JSON API をつくることができる
    • ただし読み込みが遅い
  • S3 の静的ホスティングは簡単にできる
  • Vue.js のコンポーネント管理が難しい
  • UI フレームワークに頼ることで CSS があまりかけなくても綺麗なページになる
  • CloudFront のキャッシュ管理が難しい、スマホのキャッシュが厄介
  • PWA が思ってたより簡単にできる
  • Route53 でドメインが簡単に買える・設定できる
  • いい UI をつくるのが難しい
  • フッターにをつけることで使いやすさが抜群に上がる
  • テキストボックをタップした時にテキストが全選択された方が検索がスムーズになる
  • ユーザを待たせる時間をユーザにビジュアルで伝えないとかなり不快
  • PC とスマホでは UI 設計がだいぶ違う