個人開発のWebサービスを公開した＆その振り返り
はじめに
個人で開発していたToDo管理サービスOneProgressを公開しました。ソースコードはGithub上で管理しています(https://github.com/shimgo/one-progress)。このサービスを個人開発する上で発生した問題や、得られた知見について書いていこうと思います。
サービスの紹介
今回開発したOneProgressは、基本的な機能はシンプルなToDo管理のみですが、開始したタスクはすべてのユーザーに公開される、という特徴を持っています。これは、喫茶店などの人の目があるところで作業すると捗る効果をどうにかWeb上で実現できないか、と考えて作ったものです。
以下の画像の右側が現在すべてのユーザーが取り組んでいるタスクの一覧です。左側は自分が作成したタスクの一覧で、これらは開始するまで公開されません。
開発の目的
今回開発をするにあたり、目標としたのは単にWebサービスを公開することではなく、何もない状態からサービスを開発・公開し、さらにプロジェクトとして継続して運用可能な環境を作れる能力を身につけることでした。そのために単純にRailsアプリを作るだけでなく以下の条件を満たすリポジトリを作りあげることを目標としました。
- 外部サービスと連携する機能を実装すること(テストでハマる経験を得られると推測)
- 誰でも実行可能なユニットテスト、E2Eテストを用意すること
- 誰でも同じ開発環境上でアプリの動作が確認できること
- 環境構築は自動化すること
- workaround的な対処をできるだけ避けること
遭遇した問題
モチベーション低下問題
個人開発でよく聞く問題だと思いますが、やはりこの問題は発生しました。よくある対策は、コードの綺麗さを考えずとにかく動くものを実装して短期間で作る、といった方法でしょうか。しかし、私の場合は技術力の向上のため、良い設計が思いつかないためにworkaround的な対処をしてしまうことを避ける、という目標を掲げていたので、良い設計や実装について考えるために時間をかけてでも取り組みました。そうすると当然、一日で得られる成果が減り、仕事から帰って来て休む間もなく取り組んだ割に1コミットもできなかったりすると結構ヘコみました。
この対策としては、タスクを小さく刻んで少しでも進捗を得ている、という小さな達成感を得られるようにするのがいいのではないかと思いました。この経験があったために、OneProgressではタスクの目標時間の上限を60分までにして、タスクを小さく分解することを推奨する作りにしました。
環境構築自動化やりすぎ問題
環境構築は自動化する、という条件をつけましたが、これを守ることに固執して時間を多く費やしてしまった点がありました。プロダクション環境の構築を完全に自動化させようとするあまり、サーバーを使い始める前に一度しか行わない設定も時間をかけて実現しようとしてしまいました。
そのため、途中で効果の薄いものに関しては多少の手作業も許すことにしました。しかし、ここで時間をかけたことが無駄になったというわけでもありません。時間をかけて自動化の方法を模索したことでVagrantやAnsibleの使い方や連携方法について知見を得ることができました。
それでもやっぱり時間かけすぎでは？
コミットログから、機能実装、E2Eテスト、環境構築自動化ごとの期間をざっくり出してみました。
| 工程 | 開始 | 終了 | 期間 |
|---|---|---|---|
| 機能実装とユニットテスト | 2016/09/24 | 2017/04/10 | 約6.5ヶ月 |
| E2Eテスト | 2017/04/10 | 2017/05/28 | 約1.5ヶ月 |
| 環境構築自動化 | 2017/06/16 | 2017/10/01 | 約3.5ヶ月 |
…長いっすね。
SIer勤めで残業もある中、余暇でこつこつ進めて1年かけたのにサンプルアプリレベルのToDoアプリリリースって、結果だけ見ると"1年かけてこれだけ？"って感じですね。とはいえ、一年前の自分とは比べ物にならないくらいの知識が得られたと思っていますし、環境構築の自動化と結構な期間向き合ったことでインフラの知識やVagrant、Docker、Ansibleの知識も強化されました。
まとめ
開発の目的として、「何もない状態からサービスを作成・公開し、さらにプロジェクトとして継続して運用可能な環境を作れる能力を身につけること」を掲げていましたが、とりあえずは超小規模ながらも達成はできたかなと思います。それでも時間かけすぎた間は否めないので次はもう少し早く達成感を得られるようなゴール決めをしようと思います。モチベーションのコントロールはやっぱり大事です。
