ボクココ

サービス開発を成功させるまでの歩み

1人エンジニアでサービスを成長させるために実施したい4つのこと

ども、@kimihom です。

1人エンジニアでサービスを成長させるために実施したいことについてまとめてみる。

ローンチ前と後の違い

サービスローンチ前の開発ほど楽しいものはない。誰かに何かを言われるわけでもなく、ただこれを作る!と決めたものを夢中になって作っていける。間に割ってくる人もいない。いかに早く、そして良い物を作り上げることがローンチ前の使命だ。

ローンチした後からは別物となる。少数の見込み顧客がつきながら、その様子を見ながら開発していかなければならない。当然開発だけって状態ではなくなってきて、サーバーの運用やバグの修正、顧客サポートなどあらゆるタスクが入ってくる。

この時点でうまく人を雇ったりするのも1つの手かもしれないが、私はローンチ後も2年以上、ずっとエンジニア1人でやってきた。同じような人が今後出てきた時のために、私からの言葉として以下の文章をまとめる。

インフラを無駄にこだわらない

これはローンチ前に設計しなきゃいけない話ではあるんだけど、ローンチ後にインフラ整備をするようなケースがあったりする。それははっきり言って時間の無駄だ。一体なぜ現状アクセスがほとんどない(そして将来アクセスがくるかどうかもわからない)サービスのインフラで、将来のデータ量やアクセス数を気にしなければならないのか?

1人でやってるって場合は、ローンチ後も基本的にアプリケーションのコードをひたすら改善していくことが求められる。Infrastructure as Code だとか、マイクロサービスなんて話題は出てこない。

インフラは既にある信頼された PaaS を利用しよう。これによってデプロイ周りやインフラの構成など、自前で構築せずともベストプラクティスな環境を利用できる。

値段が高くなるなんてことは気にする必要はない。自前でインフラを持つことによってかかるインフラエンジニア1人のコスト or 自分でインフラに試行錯誤に使う時間に比べたら、PaaS にそれなりのお金を払うなんてことは本当に微々たる料金だ。しかも長年の経験と知恵で研ぎ澄まされてきた PaaS は雇ったインフラエンジニアよりも優秀な成果を生むだろう。

同じように、自前でやらなきゃいけない部分はサービスのコアの部分に集中させ、それ以外の一般的な部分(検索やDB, KVS)も外部の Addon という形で導入しよう。これによってサービスとは関係ないインフラレベルで問題が起きた時は自分で調べるのではなく、サポートに問い合わせてその分野の一流のプロフェッショナルにお願いすることができる。これだけでインフラ管理の手間がなくなる。同様に、ログ管理やメトリクス管理など、これらもPaaS の提供するアドオンで構成すれば、インフラは一流インフラエンジニアが構築した並みの環境を用意することができる。

改めて、1人でサービスを開発するのなら一番大事なのは、サービスのコア部分の開発だ。そのサービスで顧客に一番価値を届けられる部分を磨き続けること。それにいかに時間を費やすことができるかが勝負だ。そこさえ極めていけば、他の企業が10人かかって同様のサービスを出してきても対等に立ち向かえるサービスを作り上げることができる。

ぶっ壊すことを恐れない

実際にサービスを公開してみたら、顧客は違う機能を求めている傾向が強かった。そんなことがよく起こる。そん時にシステムを0から作り直さないといけないくらいのレベルでもぶっ壊していった方が、最終的にはいい結果を生む。なーに、0から作り直すっていったって、たかだか数ヶ月の時間をかけて作ったシステムではないか! 恐れずぶっ壊していこう。変に以前のサービス内容にこだわって変更しないままビジネスが成長しないことの方がよっぽど恐るべきことである。

だから、私は0->1のフェーズでテストコードをガリガリと書くのをオススメしない。1人でサービスを作ってローンチしたなら、テストコードを書く価値ってのはそこまで高くない。自分の中で設計図が全て頭に入っているので、他のメンバーが意図しない修正をされる心配もないのである。逆にテストコードを書けば書くほど、先ほどのぶっ壊すって選択をしづらくさせる。

こういう判断も、人が多ければ多いほど遅くなるだけだ。スピード感ってのは0->1のフェーズでは最も大切だけど、人が多いだけで遅くなってしまう。エンジニアは本当に限られた少数精鋭でやるべきだと考えている。私みたいにエンジニアは1人でも全然問題ない。

顧客管理の自動化を検討する

顧客が50, 100 と増えてきたら、顧客を自動で管理できるような体制を整えることを検討しよう。俗にいう管理ツールの整備だ。

具体的には CRM に顧客を登録して、チャットやメールなどの履歴、ユーザー行動、現状の設定状況などを全て一元管理できるような仕組みを用意することが望ましい。CRM の用意が難しいのなら、自前で社員の誰もが気軽に(そしてセキュアに)顧客情報にアクセスできる環境を用意しよう。これによってエンジニアだけでなく、ビジネスやマーケティング / サポートの人が顧客情報に手軽にアクセスできるようになり、新規顧客獲得の分析や、サポートの品質向上など、あらゆる面においてサービスの改善に役立ってくる。

サービス成功において大事なのはサービスの機能だけではない。こうした顧客情報をいかにして管理して社内で共有していくかってのもサービスの成功に重要な要素だ。

これによって社内の無駄な連絡コストも減る。みんなが CRM に情報を入力していくようなベースを整えていければ完璧だ。

情報を発信する

0->1 を作り上げたサービス開発のノウハウってのは情報の宝庫だ。ゼロから技術を使って構築した経験ってのは他の人も確実に欲しい情報で、拡散されやすい性質を持っている。

その技術を使ってどうやって実現したか。どこで詰まって、どうやって解決したか。何の情報が参考になったか。ブログを書くだけでなく、イベントに登壇したっていいかもしれない。私自身、ローンチ後はかなりのイベントに参加して知見を共有していった。そして今でも可能な限りイベントに参加してこれまでの経験をシェアするようにしている。

登壇履歴と資料 - ボクココ

ブログや登壇によってエンジニアとしての価値を高めることもできるし、サービスの宣伝もできる。0->1をやったのに何も情報発信をしないってのはあまりにも勿体無すぎる選択だ。1人エンジニアの場合はコードを書くだけでなく、こうしたアウトプットも必ず求められる。

終わりに

今回の4つのことは、私がやってきて正解だと思ったことに絞って紹介した。

1人エンジニアってのは時に孤独を伴うが、自分の理想のシステムを求め続けられるって意味でなかなかエキサイティングなことだと思っている。自分の極めたい技術のコミュニティに入れば、情報交換だってできる。だから自分のシステムは思い切って1人で作り上げるくらいの気迫を見せて欲しい。

サービスに対して情熱的なエンジニアが増えていって、いいサービスが増えて行くといいなと思う。