ひとりでサービスを作るときに考えていること
[ これはなに ]
個人開発でWebサービスを作るときに、その作り手が何を考えているのかをまとめたものです。本職はPMの時代があった、現無職が書いています。
こんにちは。私はたまにひとりでWebサービスを作っているのですが、そのときに何を考えているのかについて聞かれることが多かったので、そんなことを簡単にまとめてみることにしました。
個人開発とチーム開発では考える観点が少し違うのですが、その違いも楽しみながら読んでいただけると嬉しいです。
今回作ったサービスはこちらです。このエントリではこのサービスを題材に、サービスを作るときに作り手（ひとり）が何を考えているのかを書いていきます。
ちなみにこのサービスは、検討開始〜実装やデータ生成〜リリースまでの流れを大体3週間くらいで終わらせています。
なお、制作の背景などはこちらのエントリに書いていますので、このエントリでは主に「作り方」に焦点を当てて書いていきます。
作りたいことが降りてくる
私が何かのサービスを作るときは、特にこれといった理由がないことが多いです。なんとなく「これを作ったら楽しそう」とか「やってみたいなー」みたいなフワッとした気持ちが湧き出てくることがあって、それに従って作っているような形です。
ですので、普通の事業を作るときのような「売り上げ目標」だとか「資金調達のためのストーリー」といったことは特に考えず、ただ単に「作りたいな」という気持ちが降りてきたときに作っています。
ですので、それが降りてくるまでは（私の場合は）特に何もしていないことが多いです。個人で作るのであれば、気分がノラないものを作っても意味がないですからね。
[事業の場合との違い]
事業だとこれは本当にダメですね。
社長の気まぐれで何かを作ったケースは大体失敗しています。
ちゃんと調査したり、裏付けのある「直感」をもとに何かを作り始めてください。じゃないと、作る側の社員が疲れ果てて辞めていきます。
競合がいないかを調べる
作りたいことが降りてきたからといって、それをそのまま作ることはまずしません。自分が作ろうと思っている何かの多くは他の誰かがすでに作っているので、まずはそれを調べます。
調べた結果出てきたものが自分のやりたかったこととほぼ同じ場合はそのアイディアは諦めてしまうことが多いです。また、全く競合がいない場合はなぜそのような状況になったかを考えます。
今回でいえば、本のレビューサイトの競合は無数に存在するものの、AIが作成した本のレビューサイトは（私の知る限り）ほとんど存在しない（少なくとも、パッと検索して出てこない）ことが明白だったため、実際に作るかーという気持ちを高めました。
ここまで大体半日〜1日くらいです。作業というよりは妄想時間ですね。
[事業の場合との違い]
事業の場合、競合調査をしっかりするケースが多いと思います。が、個人的にはこれは悪手だと思っています。
しっかり調査しないとわからない程度の競合はいないのと同じですし、調査しなくても分かる程度の競合は強いです。その意味では、これらを時間をかけて調べることに特に意味はないと思っています。（作り始めた後に機能の参考に調査する、、、などは徹底的にやった方が良いです）
それらの状況を踏まえ、自社のリソース（人的・資金的）でその状況を覆せるかという部分に主軸を置いて考える方が良いです。事業の場合はM&Aという裏技も使えますからね。
証明したいことを考える
競合がいないからといってすぐに作り始めるわけではありません。
サービスや事業というものは、何か「証明したいこと」が必要だからです。その証明したいことの多くは「この事業でお金が稼げるか」ということに集約されるのですが、個人開発の場合はそれに限らないケースが多いです。
今回のサービスにおいては「AIが生成するコンテンツに価値はあるのか」というものを証明したいことの中心に据えることにしました。
この証明自体は世の中でも殆ど検証されていない問題であり（少なくとも、本のレビューという文脈においては）、証明する価値がある問題だと認識するに至りました。
なお、競合がすでに存在し、かつ、その競合が全てを証明してしまっていたとしたら、その時点でその案は諦めることとなります。
[事業の場合との違い]
上述のように、その事業によってお金を稼げるかどうかがほぼ全てだと思います。つまりは、面白さや知的好奇心よりもお金が優先されることが多いです。この部分が、私にとって会社の事業が魅力的に思えない一つの理由だったりしますが、それはただのお気持ちですね。
事業でいえば、このタイミングで市場規模や実際に生み出せそうな売り上げの概算を出すのが通常だと思います。とはいえこれらはただの妄想に過ぎないので、スッと終わらせるのが良いかなと経験上思います。
実現可能性を考える
「AIが生成するコンテンツに価値はあるのか」ということを証明したい場合、それは本当に証明可能なのかを考えていきます。
今回のケースにおいては
ChatGPTがAPIを公開したため、AIでの文章生成が容易になった
という事象がとても大きく、それによって「実現可能性はある」との結論に至りました。
また、これまでにWebサービスは散々作ってきたこともあって、Webサービスを作るという部分においては特に問題がありません。つまり、AIによる文章生成が可能になった時点で全てのハードルはクリアしたといえます。
証明したいことが見つかり、実現可能性があると判断できた時点で、私はそのサービスを実際に作る決心を固めます。
ここまでで大体二日くらいでしょうか。実作業としては、ChatGPTによる文章生成を色々試したり、APIの使い勝手を試したりしていました。
[事業の場合との違い]
事業で行う場合、これにプラスアルファで「コンプライアンス」の問題がつきまといます。AIによる自動生成を是としない企業においては、今回私が作ったようなサービスはそもそも出すことが出来ないでしょう。
また、人員による制約がある場合も多いです。そのスキルを持った人がいないケースも多いですし、企画者はいるものの実装者がいないケースも多いです。その観点では、個人よりも検討の因子が多いため、実現可能性の判断の検討は難しい印象です。
ここの判断を失敗するとどう考えてもその事業はうまくいかないため、事業の実現可能性を冷静に判断するようにしましょう。この時点での撤退は、最小コストで済んでいるのでむしろプラスだと思います。
リリース目標を決める
個人開発なのでいつリリースしても特に問題はないのですが、なんとなくの目標があった方が頑張れることを知っているので、ざっくりのリリース目標を決めます。
作り始めたのが（Gitのコミットログを見る限り）2023/3/6 らしいのですが、その翌週に友人と会う予定があったので、そのタイミングで何か見せられると面白いなと思ってその日をひとまずの目標にしました。
この段階では、とりあえず本番環境で動いてそれっぽいものが見える状態まで仕上げたいな、、、くらいを最初の目標にしていました。
また、正式なリリースをいつにするかもざっくり考えていました。大体一ヶ月後、つまりは2023年の3月中にはリリースしたいな、、、くらいの気持ちで諸々を進めていくことにしました。
[閑話休題]
実際の事業を進めるに当たって、リリース目標を定めないケースを多々見かけますが、これは確実に悪手です。リリース日（つまりは時間）という変えられないものを定めることにより、いろいろな制約を生み出すことが出来るからです。
「この制約をいかにクリアするか」という部分にさまざまな知恵を使う必要があり、その結果としてプロダクトのクオリティが高まっていきます。開発を焦らせるためではなく、制約によるクオリティの向上（場合によっては不要な要素の切り捨て）を狙うために、リリース目標を定めるのです。
もちろん、実現不可能なリリース目標を定めることはナンセンスですので避けましょう。
[事業の場合との違い]
事業の場合も当然にリリース目標を定めましょう。とはいえ、事業の場合は「天から与えられたリリース目標」が付きまといます。
これらは大抵無理難題であり、意味不明なものです。基本的には突き返すか、それが難しければその制約内での実現可能な案を考えましょう。
この時点での調整に失敗すると、その開発は確実に炎上します。
インフラを考える
私が個人開発をするときに最初に考えるのはインフラです。なぜかといえば、私はインフラがとても弱いからです。
アプリケーションのコードを書いたりといったことはなんとなく出来るのですが、サーバーの設定やネットワークの設定などは正直よくわかりません。ゆえに、ここを先にクリアしておくことで、他の部分の開発に集中できるわけです。
なお、個人開発をするときは基本的にPaaSを選択するようにしています。サーバーのメンテナンスがほぼ不要というのは、個人開発にあたってはとても有用ですからね。
検討の結果、今回は CloudRun を選定しました。普段は Google App Engine や Heroku を選択することが多く、CloudRun は殆ど使ったことがありませんでした。ゆえにこのタイミングで一度使っておくか、、くらいの気持ちで選択しました。
普通のWebアプリケーション + ChatGPTのAPIを叩く、くらいの処理しか行わないことは明白なので、それなりに実績のある PaaS であればなんでも良いかな、くらいの気持ちでした。
[事業の場合との違い]
実際の事業でWebサービスを作るにあたってインフラから考えるケースは少ないと思います。というのも、多くの場合一番問題になるのは「人間」の労働力だからです。
個人開発の場合は「労働力＝自分」なので、そこを考える必要はありません。ゆえに、自分が一番苦手な分野をどうするかを先に考えることで、のちの作業を効率的に行える状態にする方が大切だと思っています。
ちなみに、事業でやるとしても、インフラに余程実績のある人がメンバーにいない限りPaaSを選択すると思います。実際に使われるかどうかもわからないサービスのために専用のインフラを用意するのはバカらしいですからね。
アプリケーションのアーキテクチャを考える
インフラを考えた後は、アプリケーションのアーキテクチャを考えます。どの言語を使うかとか、どのフレームワークを使うかとか、そんな部分です。
私の場合、個人開発の際は「なにかひとつは新しいものを使う」というルールを決めています。もちろん、慣れた構成で作る方が開発自体はとても早いのですが、それだと常に同じことの繰り返しになってスキル的な向上も見込めませんし、なにより飽きてしまいます。ゆえに、新しい何かをアーキテクチャに含めるようにしています。
とはいえ今回はインフラに CloudRun を使うという時点で新しいものを取り入れていたのですが、アプリケーション側もなんとなく普段と違うフレームワーク等々を使ってみることにしました。
当初は Kotlin にしようかなと思っていたのですが、さすがに慣れない言語までいくと大変だなと思ったので、今回は下記の構成にしました。
Python
BlackSheep（PythonのWebアプリケーションフレームワーク）
Tortoise ORM（ORマッパー）
Python は比較的慣れていたのと、Django や Flask には飽き飽きしていたので BlackSheep を使ってみたいなとなんとなく思って選択しました。BlackSheepにはORMが含まれていないので、これはやむなしで Tortoise ORM を選択することにしました。
また、今回のサービスはあくまでも表示が中心で入力は少なくなると考えられたためテンプレートエンジンによるレンダリングを中心とした構成とし、React等のJavaScriptは極力使わない方針にしました。
[事業の場合との違い]
今回、アーキテクチャの選定は「なんとなく」で選んでいます。スキルの向上などもなんとなくの目的には含まれているので、使ったことがない何かを使うことに意味があると考えているからです。
他方で事業の場合はなんとなくの意思決定はNGです。このような意思決定のもと技術選定されたサービスをたまに見かけますが、大体が悲惨なことになっていますね。技術選定した人も、そのうち辞めちゃいますからね。
なので、事業の場合は「このアーキテクチャで想定している期間耐えられるか」といった観点から真面目に検討する方が良いです。この「耐えられる」には、コード的な意味もありますし、組織的な意味もあります。ちゃんと考えましょう。また、その際は自分のエゴは可能な限り捨てましょう。
実装方針を決める
アーキテクチャを決めた後に、なんとなくの実装方針を決めておきます。ここでいう実装方針とは、テストをどこまで書くかとか、CSSのフレームワークをどうするかとか、サーバーサイドのディレクトリ構成をどうするかとか、そのような部分です。
ある程度短期間での開発を考えていること、他方で意外と作り物が多そうであることを考えるならば、下記の方針が良さそうだなと考えました。
CSSはTailwind以外使わない
CSSのメンテナンスは本当に大変なので。。
テストは最低限書く
モデル周り、ユースケース周りは最低限書く方が効率が良いと判断
他方でE2Eテストまでは流石に不要と判断
もちろん他にも考えること、決めることはあるのですが詳細は割愛します。
[事業の場合との違い]
事業としてサービス開発を進める場合、この辺りはきちんとドキュメント化しておくことが望ましいです。その際は、なぜその結論に至ったかの理由を書くようにしましょう。
その理由には「急いでいたからこの選択しかなかった」とか「当時のメンバーが慣れていた」とか、そのような理由が含まれていることはむしろ望ましいです。あとから実装方針の変更を考える際に、「そんな程度の理由ならさっさと捨ててしまおう」ということが明白になるので。
お金周りを考える
Webサービスを作るときにかかるお金は下記の三種類です。
人件費
サーバー費用
その他コンテンツ費用（イラスト等の発注、APIの利用料等）
今回のサービスにおいては、人件費は自分だけなのでノーカウント、サーバー費用は多く見積もっても月1万円程度（通常は数千円）、デザイン等は自分で行うためイラスト等の発注は不要、とはいえChatGPTのAPIの利用料がかかる、といったところでした。
そのため、念の為ChatGPTのAPIの費用がどの程度になるかの概算だけ出しておきました。その結論として、まあ許容範囲かな、、、といったところだったので、まあいいやと思って開発を進めることしました。
また、どのようにマネタイズしていくかも最低限考えます。とりあえずアフィリエイトでいいやという気持ちがあったため、それ以上考えることはこの時点では止めました。
[事業の場合との違い]
事業の場合、売り上げを増やすことが目的になることが多いです。そのため、お金周りをどうするかはわりと真剣に考える必要があります。
とくに、人件費が山のようにかかります。びっくりします。サーバー費用なんてゴミみたいなものです。その辺りを考えつつ、どのようなビジネスモデルで売り上げを立てていくかを事前にちゃんと考えましょう。
このあたりは「経営企画」とか「事業開発」みたいな人たちが考えることが多いですが、多くの場合「妄想」ばかり言ってくるので、現実的なワーストケースとベターケースくらいもきちんと考えるように促しましょう。
撤退ラインを決める
お金周りを考えるついでに撤退ラインも決めておきましょう。
ある程度開発した後はサーバー費用のみになることが多いので、月々数千円であれば払い続けてしまう選択も悪くないとは思います。が、「証明したいこと」が「証明できない」ことが判明した時点で撤退する方が賢明です。
今回のサービスにおいても撤退ラインは定めていますが、流石にそれを書くのはやめておきます。
なお、個人開発の場合は作成したサービス自体がポートフォリオになることも多いです。その観点からいえば、月々数千円程度であれば払い続けておく方が長期的にメリットを得られるケースも多いとは思います。
[事業の場合との違い]
撤退ラインを決めない事業、とても多いですね。個人開発と違い、事業の場合は撤退ラインをちゃんと決めて、その上でそれらをちゃんと守るようにしましょう。
事業を撤退しない＝人件費を垂れ流すと同義であるため、個人開発とは比べ物にならない程度の費用がかかってしまいますからね。
また、たいして売れてもいないサービスを残しておくことは、その会社等にとってのメリットはあまりありません。サクッと撤退を決めた方が好印象です。
他方で、ビジネス判断だけで撤退を決めてしまうと、作り手側の気持ちがついてきません。そのため、撤退基準を決める場には開発メンバーをきちんと加えておきましょう。その方が、納得感を持って撤退を受け入れることができます。
「お前らは数ヶ月、あるいは数年注ぎ込んで作ったものを無にするボタンを押す時の気持ちを考えたことがあるのか？」と、問いかけてみるのも良いでしょう。その想像力すらないビジネスサイドのメンバーがいるのであれば、その会社は結構危ういかなと思います。
広める方法を考える
サービスを実装しただけで使ってもらえるほど世の中は甘くありません。ということもあり、どのようにしてそのサービスを広めていくかを考えていく必要があります。
今回のケースでは主に二つの流入経路を考えています。
SNS
SEO
SNSでサービスを知ってもらうというのは近年の常套手段です。リリース後の告知時に手伝ってもらえそうな友人とかを探しておくと良いと思います。
また、今回のサービスはSEOでの流入を当然に想定しています。つまりはSEOに対しての知識、それらを実現するための方法を理解しておく必要がありますが、それはたまたま知っていたのでそれを踏まえて実装しています。
[事業の場合との違い]
事業の場合、ここに「広告」や「営業」という技が増えています。この辺りは個人と比べて比較的イージーだなと思います。お金をかければ一定のインプレッションは得られますかｒね。
また、「PR」という手段もあります。とはいえここは常日頃のメディアリレーションがないと難しいこともあり、個人開発者には厳しい領域かなとは思います。
なお、どのように知ってもらうかによって実装内容は変わります。SNSを重要視するのであればOGPは最重要ですし、広告を重視するのであればLPやトップページのデザインはとても大切になります。またLPOを前提としたアプリケーションの作りにするなども大切になってきます。
この辺りはビジネスサイドに閉じず、開発メンバーと一緒に考えていく方が良いと思います。
考えながら手を動かす
とりあえず手を動かします。それだけです。
実装しながら次に作る機能の設計を頭の中でしたりしますが、設計した内容は個人開発でもドキュメントに残しておく方が無難です。実装している間にどんどん忘れていってしまいますからね。
また、今回はChatGPTと共に実装していました。初めて書く機能のコードや、ちょっとした共通処理なんかは、ChatGPTに生成してもらう方がGoogle検索するよりも断然早いです。
例えばこんなやつですね。decimal は普段あまり使わないので、いちいち調べていると時間がすぐ溶けてしまいます。
このレベル感のコードであればほぼ正解を出してくれるので、他の処理を実装している間にChatGPTに質問して彼らの回答を待つという、一人二役プレイで実装していました。
[事業の場合との違い]
手を動かすのは当然ですが、ドキュメントの残し方が少し変わります。
というのも、そのドキュメントの読み手が自分だけではないからです。
ですので、自分だけが分かる記載ではなく、将来入ってくるであろうメンバーが分かるような粒度、質で書くことが望ましいです。それが書かれていないがゆえに辛い思いをしているサービスを沢山見てきたので、可能な限り何かを残すようにしまそう。
色々さわってみて考える
これは人にもよると思いますが、私の場合は「デザインツールでデザイン→実装」というやり方はせず、「実装しながらデザインを調整」という感じで作っています。
ですので、実装自体は比較的早いのですが、細かい調整が必要になるケースが多々あります。さらにいえば、スマホとPCでは操作感がかなり異なるため、スマホの場合にどうなるかを常に気にしなければいけません。
とはいえそれらはとても面倒なので、一旦ざっくり作ってしまって実際にデプロイしてみて、それからスマホでその機能を色々触ってみて違和感がないかを見極める、、、といったプロセスをとっています。
デザインツール上やエディタ上で色々やっていても、実際にスマホで触るまでわからないUI上の問題は多々ありますからね。
[事業の場合との違い]
よくもわるくも、考える人・デザインする人・実装する人が別れているケースが多いのが事業におけるサービス開発です。その場合の問題点は、彼らそれぞれのメンタルモデルが異なるという部分です。
ですので、その機能の目的やサービスの根底にある思想などにつき、きちんと共通意識が持てるようにすることが大切です。そうすることで、デザインと実装の差異に気付きやすくなります。
また、事業の場合は（様々な制約により）簡単にデプロイ出来なかったりします。テスト環境をうまく使うとか、バージョンごとに確認できる環境を作るとか、そんな諸々のテクニックを使って出来る限り実機で確認できる環境を作っておきましょう。そして、実際に実機で触る場面を増やしましょう。
性能問題について考える
AIが一部のコンテンツを生成していることもあり、思ったよりも早くデータ量が増えてしまい、性能問題をわりと早い段階で考えることになってしまいました。
嬉しいような悲しいようなと思いつつ、インフラへの課金を増やしたり、きちんとクエリチューニングしたりして対応しました。この辺りはただのチューニングなので詳細は割愛します。
[事業の場合との違い]
本番リリース後に性能問題が出ると、事業の場合は結構な問題になってしまいます。特にお金をいただいているBtoBサービスの場合などは、下手すると返金どころか会社に対しての訴訟問題に発生する可能性すらあります。
なので、最低限の性能テストを行なっておくことが望ましいです。
コード量が増えてきて悩み出す（Now）
実装方針に従って実装していたものの、コード量が増えてきたなというのが直近（2023/3末）の悩みです。
その理由は、裏側でデータを作成するための処理が案外多かったというのと、表示部分のコンポーネントが微妙に使いまわせなかったということに起因しています。後者についてはきちんとコンポーネント設計をすることによって回避可能でしたが、そこはやむなしですね。
最低限のテストは書いているのでロジック部分で問題になることは今のところ無いのですが、表示部分が結構手間になってきました。（同じようで少し違うコンポーネントへの修正漏れとか、スマホの場合に少しだけ表示が崩れるとか）
ここからどの程度機能拡張していくかによって方針は変わっていくので、そろそろちゃんと考えないとな、、、といったのが現在です。
[事業の場合との違い]
事業の場合、よほどのことがない限りある程の期間は開発が続きます。そのため、最初から「コード量が多くなること」を前提として進めていく方が良いです。
その場合のアプローチは二つあります。
・最初からとても綺麗に作る
・最初は捨てる予定で作り、PMFが見えた時点で作り替える
後者のアプローチを取る企業が多いのですが、実際に作り替えを成功させられた事例は殆ど見たことがありません。大体が、PMFが見えそうな時点でコード量が多くなりすぎて、もはや作り替えは不可能といったジャッジをしてしまうからです。
とはいえ初期フェーズでは必要な機能が何になるかなどわからないことの方が多いので、サクッと作ってサクッと捨てるというのを意識的にやっていくと良いかなとは思います。捨てる意思決定の先延ばしさえしなければ、大きな問題になることはないので。
おわりに
考えていることを書いていたらとても長くなってしまいました。
個人開発だからといって適当に作ると大変なことになるよといった話や、事業としてサービスを作るときとは考えることが少し違うよといったことが伝われば良いなと思います。
P.S. サービスについて物申したいとか、何かを相談したいとかあれば、よしなにDMいただければと思います。BOT以外は大体返信しています。
P.S.2 頑張って書いたのでお布施いただけると嬉しいです。
ここから先は
¥ 500
まいにちのご飯代として、よろしくお願いします。