)ベーシックではCanvathというWebサービスを運用しております。このサービスは、ユーザーがアップロードした画像をスマホケースや、Tシャツといったグッツに印刷をすることで、オリジナルグッズを「ひとつから、どこよりも安く」発注することができるサービスになってます。
僕自身はサービス立ち上げ時には参加してなかったのですが、おかげ様で昨年の11月のサービスリリースから順調に売上を伸ばすことができ、タイトルにもある通り「悲しみの谷」を乗り越え、「約束の地」にたどり着くことができました。
ちなみに「悲しみの谷」とか「約束の地」というはY Combinatorが発表しているスタートアップが通る道のことです。
マーケティングを捨てよ、サポートへ出よう。事例から見るスタートアップ初期におけるユーザー獲得より
僕は2015年の9月ぐらいから徐々に開発に参加をするようになり、10月から本格的にCanvathの担当になりました。担当になりいろいろソースを見ていくうちにスピード重視で開発を続けてきた弊害が出て来始めているなーというのを感じたので、今後どうやって開発を進めていくべきか、というのを考えました。
悲しみの谷を乗り越えるまで
リリースしてから悲しみの谷を乗り越えるまでは、とにかくスピード！スピード！スピード！で開発を続けていくことになります。
でもここはサービスの宿命といいますか、立ち上げるタイミングではMVPを定めて、「まずはとにかく早くリリースするんだ！！！」というテンションで進めていくことになります。
リーンスタートアップと言われる方式にです。この辺の話ですね。
リーンスタートアップにおける良い仮説、悪い仮説
メンテナンス性の高いソースコードを書こうとすると、今後の運用方針を考えて設計をしていかなければなりません。ただ続くかどうかもわからないようなサービスにそんなメンテナンス性を求めてもしょうがないですし、今後の運用方針もそんなに決まってないパターンが多いかと思います。
世の中に出してリリースしてみないとユーザーが望むものかどうかがわかりません。様々な想定をして開発を進めているとどうしたって、その分の開発スピードは落ちてしまいます。
先ほども書いたとおり開発初期には関わっておらずにいたので、ぶっちゃけ、こここうだったらいいなーとか、なんでこうなってるんだー、っていうのはめっちゃあって、「うわー！！」ってたまに叫びたくなりますが、サービス立ち上げ時の歴史的背景などは一応しってますので、そんな時はその時に必死に開発をしていたであろうエンジニアを思い浮かべています。
そして思います。「そうだ、誰もが100%完璧なソースコードをかけるわけではない、その時その時の状況にあったベターな方法をしていこう」と
Y Combinatorはこの時期には
「コードを書く」か「顧客と話す」こと以外はするな
ときつく言っているぐらいな状況ですので、そんな中で将来の運用方針とか考えるのある意味無駄になってしまいます。
とにかくやらないことを決めて、やることを徹底的に絞るフェーズになります。
約束の地を迎えて
Canvathは約束の地に辿り着くことができました。つまりサービスとしては今のやり方の引き延ばしで拡大していけるフェーズになりました。
ここまで来れたのは本当にすごいことだと思います。
ただ、約束の地に着いてサービスの方向性が定まった時にもそのまま進めると、早い段階でスピード重視の開発が効果を持たなくなってしまいます。 その理由を下記に書いていこうと思います。
理由1：開発者の人数が増える
この辺りからある程度お金をかけることができるので、場合によっては開発者も増えてくることになると思います。 Canvathでも9月に僕が入り、10月にもう1人エンジニアが加わり2名体制になりました。
人が増えてくると、自己流プログラミングは効かなくなります。
「あれ、ここの処理ってなんで最後に1足してるんだ？？」
「このファイルつかっている・・・のか・・・？？」
みたいな謎処理、謎ファイルが各所にあると、せっかく人を増やしても理解するまでに時間がかかってしまい開発スピードがあがりません。
なので、誰が見てもわかりやすいコードを書く必要がでてきます。そのためにはコーディング規約、コードレビューを通してコードの質を担保していくようにしていくことになります。
またわかりにくい箇所はドキュメント等を残すなど、他人と共有をする意識をもってすすめていきます。
後は人が今後増えた時にすぐに開発にjoinできるように、vagrant+chef（itamae)などを使用して誰でも環境をすぐに用意できるように用意しておくことも大切ですね。
理由2：数値管理するべき指標が増えてくる
最初のころは見るべき指標は絞っているので、その数字だけが見れるようスプレッドシート管理でもことたりると思いますが、サービスの規模が大きくなってくるとどうしても見るべき数値が増えてくることになります。
そのため数値管理の機能をフロントへの機能追加と同時に充実させていかないと運用がしんどくなりますし、異常値にも気づきずらくなってしまい、クリティカルなエラーを見逃してしまうことになってしまうかもしれません。
Canvathでは初期のころはとにかく熱狂的なファンを獲得することを重視して運用してきてましたので、ユーザーの発注数を重視して見てきていました。しかし今では発注する商品の数が増えてきましたので、各商品がいくつ発注されているかとか、各ユーザーごとの発注数ですとか、いろいろみたいデータが増えてきています。運用の流れも決まってきたところで、運用レベルで改善できる機能も少しずつ意識していかないといけないと思っています。
ちなみにリリース初期にファンを獲得するとこの重要性に関しては、Y Combinatorの創業者であるPaul Grahamもこう言ってました。
「初期のユーザーを満足させることに注力していたスタートアップが行き詰ってしまったケースは見たことがない」
理由3：バグが顕在化してくる
バグ自体は開発スピードをあげれば、それに比例するように発生してしまうものだと思います。ただリリース初期のタイミングではそんなに利用するユーザーもいないため、バグが潜んでいても明るみにでることは少ないです。
ただ利用ユーザーが増えてくれば、様々なデバイスや様々な使い方をするユーザーが訪れるようになります。そうなると今までひっそりと隠れていたバグたちが表舞台にでてきて暴れ出します(^^;)
発生した都度バグ対応をしていくと、本来開発すべき機能の開発に集中できなくなってしまうため、バグを修正するだけでなく、バグの発生を少しでも押さえられるような開発体制、環境を用意していくことが大事です。
既存のバグに関してはすでに潜んでいるので、ある意味どうしようもないのですが、、、今後開発を進めていく上では先ほどもあげたコードレビューや、テストコードによって防いでいきたいと思っています。
あとは本番環境とテスト環境で微妙に違うので、「テスト環境でOKだったのに、本番デプロイしたらエラーになったンゴ」とかよくある？ことが発生していたので開発環境周りも綺麗にして、理想の開発環境を準備するタイミングでもあると思っています。
理由4：修正範囲が増えてくる
コピペして機能を追加してきた場合に、そのコピペした箇所に修正を入れたい場合コピペの数だけ悲しみが生まれてしまいます。
ひとしきりサービスが起動にのってきた今では、これ以上悲しみを増やしてはいけないので、リファクタリングをして共通処理部分もまとめてスケールしやすい状態にしていかないと、スケールするのが難しくなってきてしまいます。
最後に
「とりあえずものを作る」っていうのはぶっちゃけ結構すぐできるようになると思います。（もちろんサービスを1から立ち上げるっていうのとはベツモノです）
ハッカソンが結構いい例だと思いまして、ハッカソンは短期間の勝負なんですが、その後の運用のことなんて全く考える必要ないので、「例外処理？そんなもの知らねー！」、とか「検索して出てきたこのソースコードをコピペだ！！」的なノリでどうにかなっちゃいます。どっちかというと体力勝負で、経験が浅くてもそれなりのものができちゃったりします。
経験値があると、どういった検索ワードで検索すればよいのかとかが、すぐに出てくるのでその辺の差は付きますが。
しかしこの完成したものを保守・運用していくとなると話は別です。
リブセンスの方が作った資料にもありましたね。
人は1ヶ月でエンジニアになれるのか
動くものを作ること自体は難しくない。 ただ何も考えずに作ると、 その後の変更に耐えられない
動くものを作ることと、サービスを継続的に 改善できるようにしていくこととは全くの別物
これはめちゃ同意。
というわけで、これからいいサービス頑張ってつくっていきます。