Webサービスを一人で開発してみてわかったこと５選

先月、小規模なWebサービスをひとつ自分で作って公開しました。
今回初めてチームなしに一人でプロダクトを作ってみたことで、改めて気付かされたことを５つ備忘録として残そうと思います。

１．いかに組織に助けられていたか
２．「だいたい知ってる」では何もできない
３．「試してみる」のは簡単なことではない
４．自分がやらない限り何も起きない
５．折れないためのマイルール

作ったのは「ちょっと贅沢なボトルを相乗りでグラスワインに分けて飲む機会をマッチングするアプリ」 です。地元の個人店のバーなどにコロナ禍で足が遠ざかった飲み仲間たちが集まりやすくなるネタを作りたい、と思い半年以上コツコツとやっていました。（ご興味あれば下記リンクご参照ください）

経緯

Webサービス「ワインスプリッティ」の開発には自分以外の工数をかけない（つまり外部への出費を最小限にする）ことが大前提でした。サービスを作っても意味があるかは自分の仮説にすぎないし、作るといっても実装者としての現役時代から長年のギャップがあって技術も変わっています。
まず何かを真剣に作ってみることで効果的にリスキリングしたいというのが一番の狙いでもありました。

結果として、手触り感のある楽しさを取り戻すことが出来ましたし、企業組織の仕事で染みついた「当たり前」をアンラーンするよい機会にもなりました。
現実には未達事項も多くてベータ版と称していたり、有効なプロモーションが出来ていない現状とか、エクスキューズが色々あります。甘く見たわけではありませんがやっぱり大変です。
一歩ずつ進めて行こうと思っています。

なお、テクニカルな話は別の機会に譲りますが、ユーザーがスマホ（またはPC）からブラウザで開いて使うWebアプリ（Progressive Web App）の形になっていて、主催者と参加者の２サイドのプラットフォーム、クラウド側はGoogle Firebaseを使っています。

１．いかに組織に助けられていたか

組織的に分業しているからこそ、会社では自分のチームが狭い得意領域に集中できます。
同時に、自分たちの視界に入らないところで色んな人に頼っていたことを痛感します。

たとえば、サービス名を決めるだけでも結構な事案があるんですね。
組織で自分の提案を通すには書類も要るしアポや交渉など面倒なことはたくさんありました。しかもほぼ通りません。自主開発ではそれは思い通りになる代わり、分業の境界線の向こう側にあった仕事も全部しなければいけません。
候補の名前は既に使われていないか、商標登録の先例はないか、ドメインはとれるか、変な意味にならないか。複数案の得失調べて決定すること、商標出願すること、その名前でSNSアカウントをつくること等々。そしてアカウントはその後、運用しなければいけません。

また職務発明として何度も出願する経験はあっても手続きの実際は実は何も知りません。
インターネット出願に必要な事前登録や設定はどうするのか。商標を出すルール、申請書の書き方、特許庁への料金の支払い方、諸々あります。ただ支払いたいだけなのに、Amazonみたいにカートに入れて注文ボタンを押せば成約メールがくるのとは全く違って難解極まりないものでした。
初めてのインターネット出願で商標１つ出すのに１週間は潰れました。

よく、職場インタビューなどでうちのチームは社内支援が得られず全部自分たちでやりました、という人がいますが、傲慢です。組織に思い切り支援されています。見えていないだけです。
お互いに専門領域で持ち合っているのでお互い様ですが、現役時代にもっと境界線の向こう側に思いをはせることが出来ていたら、すれ違いがちな部署間のコミュニケーションももう少しうまくやれたのかもしれません。

２．「だいたい知ってる」では何もできない

マネージャーや上位設計者としては、その技術に関して要所を理解していれば、A案とB案どちらをとるか、要件Cは対応可能か、判断つきますし指示は出せて仕事は回ります。
しかしマネジメントから実装まで全部自分がやるとしたら、半端な知識では全く使い物になりません。
自分が手を動かして使いこなしていないものは、だいたい知ってる（分かった気になっている）にすぎません。実際にどのファイルとどのファイルに何を入れるのか、ここに書くコードはどうするのか、当たり前ですが一字一句正確にCodingしなければ動きません。

概念上は出来るはずのことも、実際の実装では様々な矛盾が生じて仕様を変えたくもなります。
まあ、自分だけのメリットとしては、理解してない人間を説得したり仕様変更通知なる書面を書いたりする労力が不要で、ベストな仕様変更を瞬時に選択できることではあるのですが、止める人もいないのでたまに大間違いをして手戻りしてしまうこともあります・・
いずれにせよ、調査してポイントを理解しただけで分かった気になっている詰めの甘さでは、実践することはできず※、最後まで咀嚼しきる執着力が必要です。
（※実はAIアシストを使うとこの辺の事情は変わってきています。私もGithub copilotがなければもっと時間がかかっていたでしょう。）

コードに限らずSNSの活用も同様です。インスタとハッシュタグを使って定期的に発信云々の一般論的な方針を決めただけでは、投稿用画像の準備、乱立するハッシュタグの取捨選択、投稿順や頻度・時刻はどうするか、いいねやフォロー返しはどこまでやるか等々、いざ自分の手で入力して投稿ボタンを押すとなった瞬間に無数の疑問が湧きます。やっぱりマーケターのサポートが欲しい。

分かっているつもり、では実は何も分かっていない・実行できないことに気付かされます。

３．「試してみる」のは簡単なことではない

リーンスタートアップやアジャイルを学ぶと、まず小さく失敗してループを回そうとみんなが言います。
では「小さく」とは何か。試してみるとは、どこまでのレベルのものを、いつどこで誰に試すのか。

開発プロセスを理解しているはずの社内の人間ですら、開発の上流段階で見せたモックアップ（画面操作だけが本物らしくみえるが実際には機能しないソフト）から誤解が広まったり、原理試作（特定課題だけの検証用ソフト）をみて機能不足を批評したりと、前提条件があるにもかかわらず、うっかり出したものが独り歩きする苦い経験がかつて何度もあります。同じことが当然起き得ます。

今回のアプリではボトルワインの相乗りを募集する側のホスト（お店を想定）と応募するゲスト（参加するお客さん）をマッチングしますから、試してくれる人たちを探す必要があります。その人たちは素人ですから前提条件など気にしませんし協力的である理由もありません。となると「試してみる」に耐えうるところまで実装しないと成立しません。

実は今回も最初はモックアップを作り、知人らにフィードバックをもらい、原理試作を経て実際にクラウドで動くように変えて行ったのですが、どこまでできたらMVP（最小限実用可能なプロダクト）と言えるのか。相当に悩みました。トラブル時のサポートも自分一人のリソースだけなのでミスったときのダメージが怖いです。
協力してくれるお店のマスターや顔見知りのお客さんに迷惑をかけずにやれるのか？

実際、前年末のモックアップからMVP候補になったのは翌4月で、それを実際に試してくれたマスターとお客さんに聞くと案の定、機能実装の優先度を見誤っていました。この流れは正しいループですが、未実装機能の優先順位を修正した後も、どこまでがMVPなのかに悩み続けました。
ちなみに、入力されたワインのタイトルからOpenAIのGPTを使ってお客勧誘文を自動生成する機能を早々に入れたのは自分の興味本位の選択でしたが、期待以上にデモ効果があって楽しかった。

結局、8月末にやっとベータ版をリリースし、9月から勧誘を開始しました。（サポートが不安なので、自分のSNSや地元の付き合いなどから徐々に宣伝しています）

「試す」とは軽々しく言えるものではなく、最善を尽くして「試す」であることが身に沁みました。

４．自分がやらない限り何も起きない

自分が出した複数案から自分で決めるわけですが、自分の気付かない観点からの対案がありませんしレビューアーもいません。自分が出さない限り新しい案は増えませんし、自分で調べない限り判断材料も増えません。友人知人・飲み仲間たちと話をしたり新しい店に行ってみたりすることで気付きやヒントも頂きましたが、それも自らその機会を作ればこそです。
自分の意志で進めない限り、本当に、何一つ進まないし、想定スケジュール通り進んでいなくても何も尻を叩いてくれるものがありません。

組織の仕事では仮に自分が止まっていも全体でみれば必ず何かが進捗しています。誰かとの間に守るべき納期がありマイルストーンを互いにチェックするので頻繁にトリガーがかかります。
自分の裁量だけで調整できないことが組織の仕事の辛いところでしたが、個人に左右されない仕事の流れに乗っているので、そうそう逸脱せず収束していくのは結果を出す仕組みとしてとても有効です。

ストレスに思っていたことの利点を後になって素直に認める気持ちになりました。

個人には波があるので、絶好調でノンストップの時もある一方、コンスタントに進捗を続ける事が思った以上に重いです。身軽なはずなのに重い。

でも変ですよね・・・嫌ならやらない選択肢が今はある。
そもそも、努力感なく没頭できることだからこそ始めたことなのに、いつの間に「頑張って続けなきゃ」になってしまうのでしょうか？

何か目標を設定し達成すべく頑張るべきだという観念は、長年の仕事で染みついたものです。
これを否定するのはとても気持ちが悪いんですが、一旦アンラーンしたうえで改めて、好きだから続けると思えれば自然とモチベーションも回復します。
それが次のマイルールにつながります。

５．折れないためのマイルール

自分できめたルールをもっておくことが大事だと思いました。

進めるにつれて初期検討の段階で見通せてない問題点が次から次へと出てきて手が止まります。
迷いに迷って決め切れずに気持ちが萎えることも何度もあります。
知見のある人なら半日で片づけそうなことが一週間かかってうんざりしてしまう。

でもやりたいことの道の先がそれらを乗り越えた向こう側に延びている以上、やっぱり折れずに続けたい。そんなとき私の場合は次の様に考え、あるいは習慣づけることで対策しています。

自分自身の性格や環境などに特化した専用のツールです。
（現役時代にもっとこういう工夫をすればよかったのに、と今になって思います）

自分ロードマップを見返す

好き嫌い・得手不得手・ジョハリの窓・・・シニアセミナーなんかでもやりますが、自己分析をして自分がこれから大事にしていくもの、20年後どうなっていたいか、行動指針等をまとめた自分ロードマップを描いてあります。いわば自分の人生の中長期戦略です。

実は退職直後、1年後、2年後と自分自身も変化していくので毎春アップデートしています。
この初心をリマインドし、やりたかったことが出来る自由に感謝することで、目先の躓きがあっても気持ちがとても楽になります。

時間の使い方を見える化する

少々テクニカルな話ですがGoogleカレンダーに活動実績を毎日記録しています（予定の変わりに実績を入れていく）。
何をやってたか分からない日というのがない様に、一日ネットフリックスを観ていたり、夜中にぼーっと飲んでいたら、それで良いのでその通りに記録しています。
スクリプトが自動で一週間毎の集計をしてグラフ化するので、時々これを見ることで波があることを客観的に受け入れ、不調な時期があっても悩まない様にします。

10分間テイクオフを取り入れる

つい先延ばしで手が付かない問題、は誰もが抱える悩みではないでしょうか？
それでも一旦やり始めるとスイッチが入って気付くと長時間集中してたりしますよね。
なので最初の一手のハードルを下げるスローガンをいくつかつくって見えるところに置いています。

私の例はこんな感じです（飽きるのでときどき変えてます）が、精神的な動機付けではなく具体的な行動を促すものが良いようです。

「嫌な作業は複数ステップに分け、ステップ１を10分だけやって進んだことにしよう。」

「ゴールは有限、１日１か所でも追加・修正を続けられたら、いつかは辿り着く。」

「どうせ逃避するなら、好きな別テーマの調査や読書に使おう。時間を溶かすな。」

適度にリフレッシュする

自分に合ったガス抜き方法を自覚していることは大事だと思います。

自分はインドア派ですが人付き合いも好きなので、行きつけのバーで飲み仲間や初対面の人と話をしたり、一人で新しいお店を開拓するのも大好きです。デジタル一眼を持ち歩いて写真をよく撮るので、気に入ったお店はGoogleローカルガイドとしてマップに画像とクチコミを投稿します。地味ですが楽しい。

ちょいちょい飲みすぎで翌日使い物にならないことも容認し、自分にとっては手軽で再現性のあるリフレッシュ手段になっています。

最後に

私はなるべく気力体力が残っている時点で会社組織に依存しない生き方へ切り替えたかったので、再雇用に関心はなくて還暦より1年早く退職しました。（勤めていた会社に「見なし定年」という支援制度があったので恵まれていました）

現時点での損得勘定でいえば、会社に残り続けた方が経済的にトクだったことは間違いありません。

それでも私にとっては今これを書いている自分の方がハッピーに思うのは、自分の価値観に合っている選択だからです。生活が変わると価値観も変わり得ますが、内なる声を押しつぶすと、残ったにせよ或いは逆に辞めてしまったことで後悔する人もいるでしょう。

私と同じような岐路で思案している方がいましたら、何かのご参考になれば幸いです。

追伸：
このサービス開発にまつわる技術トピックはこちらにまとめてみました。

Webサービス「ワインスプリッティ」の技術トピックス

以上

---

参考：