初めての個人開発でのサービス作り(企画〜リリース)の失敗談と学び

はじめに

みなさん、こんにちは！
Habitat Hub のボードゲーム好きエンジニア @tom-takeru です。
（詳細は tom-takeru Web をご覧ください。）

今回は1日のスケジュール管理サービス daydule を企画からリリースまで行った中での失敗談と学びをご紹介したいと思います。

実際の時系列で企画〜ベータ版リリースまでを順に追いながら、その中での失敗談を書きました。ファーストリリースまではスケジュール意識を持って進めたかったので、ウォーターフォール開発チックにプロジェクトを進めました。

本記事はあくまでも「ファーストリリースまでスピード感を持って進めたい」という目標に対する後悔と反省をまとめたものです。「まずは一回トライしてみる」という意味では良い経験になったと思っています（この経験がなければ本記事も書けなかったです）。

タイトルで個人開発と書きましたが、正確には「プライベートでチームを作って開発」しています。ネット上で「個人開発」という言葉が強いので、あえて使いました。

本記事では daydule の内容について、深く言及しませんが、参考資料として詳細な設計書なども差し込んでいます。プロジェクトの詳細は、 dayduleのアプリ概要 や dayduleのシステム概要 でご確認ください。全体感や技術スタックなどを記載しています。

失敗談

企画（2022/6〜）

Habitat Hub のもう一人の初期メンバーである @mellbrother と2人で、企画を練り始めました。

まだ技術力もそこまでなかったので、いくつか企画案を出した中から自分たちのできる範囲で考えた結果、この daydule を開発することになりました。自分達の技術力アップという側面も考慮してこの企画案を実施することを決断しました。

参考：最初に @mellbrother が作ってくれたサービス概要

「夢を膨らましすぎた」

初めて企画からサービスを作るということもあり、機能に関してたくさんのアイディアが出て夢が膨らみました。
アイディアがたくさん出ることは良いのですが、

• その機能を開発するのにどれくらいのコストがかかるのか？
• その機能はどれくらい重要な機能なのか？

というとても重要な視点が欠けていました。
正確にはその視点でも少しは考えていました。
ですが、「この機能があれば便利だろう・自分が欲しい機能だ」というところを重視してしまい、その機能の優先度や開発コストについて吟味する時間をほとんどとりませんでした。

要件定義（2022/8〜）

できた企画案を元に、要件を固めていきました。
具体的には、

• 画面遷移図
  • 画面遷移を全て書き表した図
• シーケンス図
  • 各機能に関わる要素とそれらの間での連携の流れの図
• 機能一覧
  • アプリケーションが動くのに必要な機能の一覧
• テーブル設計のたたき台
  • DBに保存するデータの設計の下書き

を作成したり、挙動について議論して仕様を確定させたりしました。

参考：画面遷移図

「資料を作る目的をはっきりさせていなかった」

この段階で資料をいくつか作りましたが、資料完成がゴールとなってしまいその後はほぼ参照しないようなものがたくさんありました。チーム内での認識合わせという意味で活用できていたものもありますが、なくても良かったと感じる資料もありました。

参考：作成後あまり使わなかったシーケンス図の一部

「要件定義段階で仕様検討に時間を使い過ぎた」

仕様検討で週1回行っていた会議の、ほとんどの時間を使ってしまっていました。もちろん必要だった議論もありますが、その結論が実際に実装してみると全く見当違いだと分かったり、議論したのにファーストリリースでは未実装の機能などもあったりして、今となって見てみると無駄な時間となってしまった部分が多々あります。

参考：仕様検討ために作った資料（結局ファーストリリース時点では未実装）

設計（2022/9〜）

機能一覧の一つ一つの機能を、アクティビティ図・処理詳細表で構成された設計書として明文化しました。ここでは結果的に50個以上の設計書を作成しました。また、このタイミングで Figma 上にプロトタイプを作成しました。

参考：設計書一覧の一部

参考：Figmaのプロトタイプ

「細かい機能まで設計書を作り過ぎた」

すぐに実装できるような簡単な機能まで丁寧に設計書を作成し、多大な時間を割いてしまいました。プロジェクトが進んでいる感はありました。お客様に納品する場合や、自分とは別の実装者がいて実装する場合は必要だったかもしれませんが、私たちのチームのように設計者≒実装者の場合はここまで作り込む必要はなかったなと思います。

参考：スケジュール作成の機能仕様書のアクティビティ図の一部

開発（2022/11〜）

設計書の作成が終わり、それらの設計書を元に開発を行いました。
ここに最も多くの時間を割きました。

「工数見積もりが楽観的だった」

当初の予定では開発は2022年12月には終わらせる予定でしたが、結局2023年の6月ごろまで開発が膨らんでしまいました。開発していく中で追加で必要になった機能などのも相まって、想像の何倍もの時間を費やすこととなってしまいました。設計書をいくら丁寧に作っても、結局やってみないとわからないことはたくさんありました。

ベータ版リリース（2023/8〜）

開発が終わり、ホスティングサービスを利用して本番環境へのデプロイとドメイン取得を行いました。
そして、ベータ版をリリースしました。

学び

ここまでご紹介した失敗談を踏まえてそこから得た学びを、ここまで辛抱強く読んでいただいた皆様に共有します。

「機能の実装優先度を見極めることに時間を使うべし」

今自分で見ても当たり前に感じることですが、実際にリリースまでの道のりを企画からやってみると、夢が膨らみ色々と機能を詰め込みたくなってしまいました。コストや重要度をもとにその優先度を決定する工程には、しっかりと時間を割くことがとても重要だと感じました。

---

「目的を持って資料を作るべし」

とてもシンプルです。目的を持って物事を進めることはこれに限らず言える重要なことですが、ついそれを忘れてしまい手段が目的となってしまうことがあります。資料作成においてもその活用目的をはっきりさせてから作るべきだとしみじみと感じました。目的をしっかりと定めていれば、無駄な資料は作らずに済んだように思います。

---

「分析麻痺せずに手を動かしながら修正していくべし」

分析麻痺という言葉を広めたかったので、あえてこう書きました。分析麻痺とは、分析・検討にかかるコストがメリットを超えてしまう状況です。
最初にいくら検討しても、やってみないとわからないことはたくさんありました。実際に手を動かしてみると、想像もしていなかったような課題がボコボコとモグラ叩きのように出てくるものです。なので考えるのは程々にして見切りをつけ、前に進むのが良いと思いました。
もちろんある程度検討しておかないと大量の手戻りが発生する議題もあります。そういうものを見極めてそれだけは深く検討し、あとは走りながら考えた方が良いというのがこの学びの意図です。
アジャイル開発が近年主流になりつつある理由も身に染みて感じました。

---

「工数見積もりは余裕を持たせるべし」

余裕を持って工数を見積もることはプロジェクトを計画通りに進める上でとても重要です。やってみないとわからないことはたくさんあるからです。簡単なタスクに余裕を持たせすぎるのはあまり良くありませんが、少しでも不確定要素のあるタスクには余裕を持たせた方が、結果的に計画通りに進められると感じました。

さいごに

ファーストリリースまでの道のりでの「失敗談」と「そこから得た学び」についてご紹介しました。この経験が皆さんのプロジェクトに少しでも役立てば幸いです。

また、本記事でご紹介したプロジェクトの成果物である daydule は今後もアップデートを予定しています。ぜひ、ご利用いただき、貴重なフィードバックをお寄せください。皆さんの声を聞かせていただくことで、私たちのサービスをより良いものにしていきたいと考えています。

さらに、本記事や daydule に関するご質問や提案がありましたら、お気軽にコメントを残してください。皆さんとの対話を通じて、私たちの知見を深め、共有することができればと思います。

Habitat Hub では、今後もメンバーが交代で定期的に記事を投稿します！
ぜひ、フォローをよろしくお願いします

最後までお読みいただき、ありがとうございました。