リリースまで進み続けるんだ！これはお前が始めた個人開発だろ？

パッケージリスト

大まかなプロダクトの方向性が定まり、次はパッケージリストというものを作ります。これは本の表紙の様なもので、１枚の紙にプロダクトのイメージ図、特徴機能、キャッチコピーを掲載します。ただこの中では特徴機能が重要な気がします。

この「特徴機能」は最初にいくつか候補を挙げておきます。それらの候補から最終的に３つに絞ってパッケージに載せます。しかしここで重要なのは「このプロダクトで何ができるのか」をはっきりさせることです。

この際、アジャイルサムライでは「フィーチャーでなく効能をつたえる」ことを重視しています。フィーチャーとは一言ですむ特徴や機能名のことです。RouteShareの場合、地図機能、記事機能、SNSサービスといった用語が当てはまります。しかしこれらの「特徴」や「機能名」を言ったとこでユーザーからしてみれば、「で、それらは一体何がいいの？」となっていまいます。これらの「特徴」や「機能名」でユーザーの

• どんなニーズを満たすのか
• どんな役に立つことやメリットがあるのか
• 何ができるようになるのか

を具体的に言える様にしましょう。アジャイルサムライでは上記３つのことを「効能」と言っています。RouteShareでは以下の様になりました。

地図にルートの描画、スポットの設置ができる。

• わかりやすいルートを作ることができる。どこの情報かわかりやすい。
• 地図でどこに何があるかを直ぐに把握できる。

地図のルートスポットから記事にリンクをはれる。

• 地図と記事の関連性がわかりやすいので、楽に内容を共有できる。

地図＋記事の投稿を作成できる。

• 自分が行った旅先の情報を他人に共有できる。
• プランナーとして利用でき、仲間とルートや旅程を共有しやすい。
• 道路情報や気をつけることなど、実際に行かないとわからない様な詳細な情報を共有でき、取得できる。
• 自分たちの町などのおすすめの回り方を発信できる。
• 写真も投稿できるのでダイアリーとして、旅の思い出を残すことができる。
• 直感的に場所を把握することができる。

設定したパスやスポットからどこに行ったかのデータを取得される

• 検索で場所、ルートから投稿を検索できる様になる。自分がいきたいと思っている、知りたいと思っている場所の情報を地図から探すことができる。

投稿にタグを貼ることができる。

• 都道府県、地名、やりたいことから目的のルートを探ることができる。

まずは「〜ができる」「〜する」という特徴を書いたら、「それによってユーザーにとってどう役に立つのか」を箇条書きで書きます。

パッケージは作っても作らなくてもいいですが、作った方がやる気は上がる気がします笑。

やること、やらないこと

方向性が決まり、実装したい機能が定まってきたら選定を行いましょう。RouteShareも開発していくとわかってきた技術的難点やコストの問題で端折った機能がたくさんあります。個人開発ではスコープ管理が自由な分、「こーした方がユーザーにとっていいのでは..」と考えることが多くなります。やること、やらないことを決めないと実装したい機能が後からどんどん湧いて、リリースが先延ばしになってしまい、最終的に途中で頓挫することが多いです。

正直言うとそのサービスが需要があるか、ニーズにマッチしているかは市場に出して使ってみてもらわないと効果測定ができません。後々の設計や技術選定、開発を行いながら「やらないこと（あとでやる）」と「やること」を選定していくといいです。経験的に「やらないこと」に振れないかと第一に考えるとスコープが無限増殖しません。

収益化構想

このサービスでは収益化を考えています。私自身は無料のサービスには限界があり、最終的には何らかの形で有料化・収益化することでより良いサービスになると考えています。使用ユーザーが増えることはその分、サーバスペックも要求されるようになりますし、当初のニーズに対する答え合わせもできるようになってきます。より安定的に、素早くビジネスとサービス品質を加速させるためにはマネタイズは重要になります。

RouteShareも一大プラットフォームになるべく、収益化の構想は考えています。ただし、正直言うとここは自分でも曖昧で「取らぬ狸の皮算用」をしているのでは？と感じているとこがあります。RouteShareでは以下の方法での収益化パターンを考えています。

1. 広告添付
2. 有料機能、サブスク化
3. 法人掲載枠を設ける

広告添付

Google Adsenseなどのサービスを利用して広告を添付します。シンプルで導入はしやすいです。しかし広告添付は収益化のためには非常に多くのユーザーが必要であり、また不安定です。

有料機能、サブスク化

一部機能に制限をつけ利用したい場合は有料会員としてサブスクを求める方法です。使用しているユーザーや料金、収益状況が把握しやすく収益が安定しやすいです。しかし有料で買いたいほどのニーズの解決や無料枠との差別化が必要であり、収益は単価を多く取るか少なくするかによって必要なユーザー数に依存するようになります。

法人掲載枠を設ける

私は最終的にはこの方法での収益化を目指しています。法人と契約して優先的に掲載できる枠を設けたり、法人のみが使用できる機能を提供、企画を立案してプロモーションを行うことです。サービスにそれなりにユーザーがいて、法人に対してそれなりの利益を提供するまでサービスの成熟と営業が必要なりますが、toCな収益形態よりも安定的で発展性のある収益化形態です。

収益化方法は色々とありますが、少なくともどのように収益を確保するかの構想は初期の設計段階でも考えておくといいです。

支出はシビアに感覚で判断しない

いきなり企画の段階でいうのも何ですが、個人の広報力やブランドがない状態でデプロイしても正直ユーザーは来てくれません。個人開発のツイートがバズってたくさん！というのは偶に見ますが非常に稀です。

正直大方のサービスは運営していき、少しずつユーザーを増やしていきます。サービスがいつバズって収益化まで繋がるかは「サービスがどれほどの期間運営しているか」に依存します。下手すると年単位になることもあります。

その時、支出の存在はリリース後の悩みの種になりますのでサーバ代は必ず計算して、いかにケチれるようにすることが重要です。

私の場合Laravelを使用するAPIサーバのためにVPSを新規に借りようとしましたが、計算しても月2000円は追加の出になるため、実は別のブログで運用しているレンタルサーバに導入しています笑

フロントに関してはGoogle App Engineを使用して必要な時に稼働するようにしました。とにかく支出はケチれるようにして、かかる費用は毎月監視するようにしましょう。

リスク

ここまではどんな機能を実装しようか、サービスがどうなるのかワクワクしながら進めたと思います。しかし機能を実装するで上にどんなリスクが生じるのかを考えましょう。実際に企画初期段階では以下のように考えていました。

• ユーザーが本当に何を望んでいるかわからない
• Stravaなどの強い競合からどうユーザーを引き込むか
• 最初の広報とユーザーに広めるか
• ルートパスからの検索の実装方法
• 検索コスト
• リッチテキストの実装
• Google API のリクエストコスト
• 本当に開発しきれるか

この時さまざまなリスクが思い浮かびますが、そのリスクが「自分が制御できるか」で対応すべきかを決めましょう。例えば「このサービスは受けるだろうか」「ユーザーのニーズをあてているか」は正直考えるだけ無駄なリスクです。なぜなら「その答えはユーザーのみが知っていて、そもそも市場に出さないとわからない」からです。もちろん競合調査などをして可能な限りリスクを下げることが必要ですが、自分がどれほどそのリスクに対して対策を取れるか、制御できるかを念頭にしておくことが大切です。

リスクをよく考えることで早い段階で課題を明らかにでき、プロジェクトが進んでから爆弾が爆発するのを防ぐことができます。あと気持ちがすっきりします笑

プロジェクトの管理

プロジェクトの管理はGoogle ドキュメントとスプレッドシートで行いました。企画書などはドキュメントにまとめ、スコープ、実装機能表などをスプレッドシートで管理しました。

個人開発であればJiraやBacklogよりもスプレッドシートぐらいで十分です。チームでも2,3人ぐらいまでなら大丈夫そうです。これらの記録は後で見返したりする時に便利ですし、課題管理はプロジェクトがどれほど進んでいるかの指標になるので作成しておくといいです。

また設計に関しては基本的にスプレッドシート、図などはDiagrams.netを使用しました。

設計

企画・構想が決まったら設計を行います。ここからようやくエンジニアっぽいことをやっていきます。

サイトマップと画面イメージを作成する

機能については企画の段階でまとめました。サービスではユーザーが画面上のUIを通じてデータの更新・閲覧を行います。すなわち「どんな画面が表示され、そこで何ができて、どう遷移するのか」を把握します。

いきなり画面図を書くのは大変なので最初はサイトマップというものを作成して「どんなページ（画面）」があれば良いのか？を決定します。webサービスの場合はURLのパスも決めてしましましょう。

サイトマップは名称、パス、タイトル、用途を記述し、認証や特定のミドルウェア的な制御を行う場合は追加で記入しておきます。

サイトマップを作成したらワイヤーフレームを作成します。ワイヤーフレームはページにどんなパーツを表示させ、どんな要素（データなど）を表示するのかを整理することができます。フロント部分で表示する要素を整理することで、実際にどんなテーブル構成にすればいいかを知ることができるようになります。

ワークフロー図を作る

次はワークフロー図を作成します。ここでいうワークフロー図はプログラム的な処理のフローです。例えばGoogle連携についてのフローは以下のような画像で表現しました。

ER図を作る

ER図にてテーブル設計を行います。フロント・バック内でのフローや要素を整理するとER図はすんなりとできることが多いです。

デザインを作る

エンジニアで一番大変なのはこのデザインの部分です。ワイヤーフレームをもとにして実際のデザインを作成します。私はAdobe XDを使用して画面ごとのデザイン、UI、パーツを作成しました。ここはFigmaでもXDでも大丈夫ですが、コンポーネントやレイヤー分けできるツールを使用した方がいいです。

デザインセンスがないと感じる場合

• 他のサイトを参考にする
• デザインの4原則を守る
• ブランドカラーを決める
• CSSフレームワークを使用する

以上４点を意識します。

他のサイトを参考にする

RouteShareはTwitter、Qiita、Stravaを参考にしてそれらを混ぜ込んだ形にしました。よく見ると似ている箇所があります。もちろん完全にパクるのは良くないですが、デザイン・UIの参考として作成した方が、少なくともダサいデザインにはならないと思います。

デザインの4原則を守る

これを守るだけでなんかいい感じになります。デザインの4原則とは

1. 近接
2. 整列
3. 強弱
4. 反復

の4点です。

例えば上記は登録された投稿一覧ですが、

• タイトルと投稿場所、サマリーとユーザー情報はある程度マージンをとる。
• それぞれの要素のパディングを同じにして開始位置を揃える。
• 背景色を利用して強弱、領域の区別をできるようにする
• 下のボタンなど似ている要素は似たレイアウトと感じで表示する

この4点を意識していくと結構いい感じになります。

ブランドカラーを決める

ブランドを決めます。RouteShareは道路の新型青看板の青色をもとにしています。その色を起点にしてColorHexaなどで輝度方向のパターンの色を使用するといいです。基本的にはブランドカラーはこのようにし決定して、色々とカラフルにしない方がいいです。しかしUIではキャンセル、確認といった箇所では赤・緑・黄色などを使用してしても問題ありません。

CSSフレームワークを使用する

デザインとCSS・UI系の工数を省きたい場合はCSSフレームワークを使用した方がいいです。RouteShareはBootstrap-vueを使用しています。フレームワークは好きなものを使用して大丈夫ですが、上記のブランドカラーなどを適用したりプロパティーを変更できるフレームワークを使用した方がいいです。

技術選定

設計やデザインを作成して技術選定を行います。リリースを重視し、個人開発であればあなたの得意なスタックで大丈夫です。正直いうと、ユーザーにとってみればバックエンドに何を使っていようが、動いていればまずいいのです。あとはあなたの開発効率の問題になります。個人開発ではモチベーションや初版リリースまで辿り着けるかが第一の関門となっています。

そのため技術的な勉強という要素を入れてしまうと、途中で挫折しかねません。もちろん選定したスタックによってはコストがかかってしまうものもあります。しかしその中でもコストと開発難易度がちょうど良くなるスタックを選択した方がいいです。

一番最初のことろはサーバーレス環境で全部おさめてやりたいとも思いましたが、デプロイの設定やFireBaseなどは初めてだったこともありやめました。LaravelとフロントエンドはVue.jsという構成も考えましたが、フロントの構築は１つのフレームワークで行った方が自分的にはかなり楽だったので、LaravelをバックにフロントはNuxt.jsという構成を取りました。

APIサーバとフロントサーバを用意する必要がありましたが、Google App engineの無料枠を利用できる様にしたり、APIサーバーも構成を工夫することで費用を抑えることができました。

１番の悩みの種はGoogle Map APIの課金ですが解決方法は見つけ、まずはリリースを優先するために地図表示はGoogle Mapにまずは任せることにしました。

外部サービスの利用時は規約をしっかり理解する

もし外部サービスのAPIなどを使用する時は規約を読んでおきましょう。公開して、収益を求めるサービスなので規約違反はNGです。

RouteShareの場合はGoogle Map APIで規約違反をしてしまう機能を開発しそうになった時がありました。RouteShareは地図にセットしたラインやスポットを計算して、周辺地図の画像をサムネイルとして設定できる機能があります。↓

このとき当初はGoogle Map static image apiを使用しており、バックエンドで画像のURLにリクエストしてレスポンスの画像をこちらのサーバに置いておくという方法をとっていました。しかしこの方法は規約違反であり、必ずブラウザからstatic image apiのURLを記載することとの規約がありました。

現在は地図サービスのAPIを別途契約して、タイル画像を取得して生成するようにしました。知らぬ間に規約違反することもあるので、規約は難しいですが一読しておくことをお勧めします。

開発

設計、技術選定、デザインがある程度完成したら早速開発を始めましょう。正直のこの開発時期が一番、挫折しやすいと思います。ここでは開発時に大切なことを書いておく程度にします。

とにかく作り上げること

個人開発の完成は自身のモチベに依存するため

• Better than Nothing
• Done is better than perfect

の気持ちを常に持っていた方がいいです。開発をしている際に一部の設計を見直したり、機能を追加・変更することがあると思いますがスケジュールとスコープがオーバーしないようにしましょう。

私も開発をしている時に「こうした方がいいのでは？」「もっと最適な方法があるのでは？」と思って思うように開発が進まないことがありました。

もちろん期限内に最善を尽くすの良いですが、完璧を求めようとするとズルズルと起源と対応すべきコストが増大します。途中で色々面倒になったり、仕事が忙しくなり放置..ということになります。今の自分が持っている技術スタックの最善を尽くして開発を進めてください。

保守性とテスト性は重要

作り上げることは重要ですが、品質を犠牲にするわけではありません。リリースはゴールではなく、マイルストーンであり経過点です。むしろサービスはリリースしてから始まりますので、リリース後の保守や改善のことも考えなければなりません。

その際に作り上げることを言い訳に自分ですらコードの内容を把握できないものや、保守性の低いものはリリース後のモチベを下げる要員になります。

継続的な開発のために

• 保守性を高める記述を心がける
• 可能な限りテストコードを書いて、改善コードをデプロイしやすくする
• バージョン管理は必ず導入する

以上のことはやっておいて損はありません。

毎日コツコツやること

あとはもう時間をかけるのみです。個人開発は睡眠時間を削ったり土日を使うことで捻出しました。仕事が終わったら直ぐに個人開発の環境を立ち上げておきます。

まとまった休みにやるよりも、毎日ちょっとずつの方が結果的にリリース達成の確率は上がります。

ここはもう、何とか時間を作ってください。心の中に「リリースまで進み続けるんだ！これはお前が始めた個人開発だろ？」と問いかけるようにしてください。

そしてリリース日やマイルストーンなど明確な目標期限を定めてください。個人開発は管理が自由な分、開発時間などを伸ばしがちです。期限を定めることでダラダラと続けることを防げますし、スコープが増大することも防げます。

リリース構成

開発進み完成してきたらリリースの準備を行います。リリース方法は使用している開発構成によってまちまちですが、基本的にはgitを用いてリリースを管理できるようにしたほうがいです。可能な限り、手動での反映を少なくできるようにした方がいいです。

RouteShareではgithub上でrelease,testといったブランチを作成して、本番環境もそれらのブランチからプルするようにしています。フロントエンドはGoogle App engineを使用しており、ビルドからサーバへのデプロイはgithub actionsで自動的に行えるようにしています。

ドメインの設定やSSLなどやることが多いですが、この辺はリリース時に1回で済むので頑張って調べてください。（私もそのうち書きます..）

今後の機能リリースではできる限り本番へのデプロイが楽になるような構成を最初に心掛けた方がいいです。

個人開発のススメ

色々端折ってしまった所がありますが、内容は以上となります。本記事では開発したRouteShareの詳細はお伝えしませんでしたが、また違う記事で機能について開発面で細かく解説した記事でも書こうと思います。ぜひ旅行好きな方はRouteShareを使ってみてください！

デプロイから1ヶ月たち、まだユーザー数やトラフィックも少ないですが今後は運用に注力したり、リリースまでに間に合わなかった機能を実装しようと思います。エンジニアであればこのように製品を自ら開発してビジネスを始めることができます。ディベロッパー的な視点や技術だけでなく、経営や運営、企画の力も付きます。総合的な力をつけたいエンジニアはサービスの大小あれど、色々な人に使ってもらえるアプリケーションを開発してみるといいと思います！