This page is intended for users in India. Go to the page for users in United States.

創業1年のスタートアップが、サービスリリースと同時に機能開発を3ヶ月止めた理由

新規サービスのリリース。その直後は落ち着く間もなく新たな機能開発に向けて走り出す、というのがスタートアップのイメージではないでしょうか。

ところがHiCustomerはなんと、サービスリリースと同時に新規開発を止めたといいます。異例とも思えるこの意思決定をしたエンジニアチームと社長に、話を伺いました。

(取材・執筆・撮影:五木田梨絵)

カバー写真 左から:大塚さん、白坂さん、肥前さん、小田さん・・・社長が写っていない

リリース直後にリファクタリング開始

肥前: サービスの正式版をリリースしたのは2018年12月なのですが、実はそこから2019年2月までは結構大規模なリファクタリングをしていました。なのでリリース直後、「これから機能追加を加速させていくぞ」というタイミングで新規機能の開発を止めていたんですよね。

これまでの流れはこんな感じです。

ーー なぜこのタイミングでリファクタリングをすることにしたのですか?

肥前: 2018年の夏以降は、とにかく怒涛の新機能リリースラッシュだったんです。でもリリースのたびにトラブルが起きていて…。毎回白坂さんと僕で徹夜するという、地獄のような日々でしたね(笑)。

原因は、腐敗が進んだコードベース。リリース前に業務委託で関わってもらっていた方が多く、開発基盤が整う前にメンバーの出入りが多かったんです。ドキュメントをほとんど書いていなかったこともあり設計思想やコンテクストが共有しきれず、負債がどんどん溜まっているような状況でした。このタイミングで整備しておくべきだったのですが、そこまで手が回っていなかったですね。

白坂: 本当は、正式リリースをするまでに必要な機能開発を終えた上で、本リリースするまでの期間にリファクタリングをするつもりだったんですよね。そしてリリースした瞬間に爆速で機能開発ができるような基盤を整えましょう、と。

肥前: たしかに最初はそのつもりだったね(笑)。

大塚: 僕は11月に業務委託で入社して初めて関わったリリースが、特に1番負債が溜まっているものだったんですよね。入社して早々、「これ、まずくないですか?」と言ったら「リファクタリングすることは決まっているから」という話だったんです。決まってるなんて素晴らしいなと思って、安心して正社員としての入社を決めましたね(笑)。

肥前:大塚さんと小田さんはジョインして最初の仕事がリファクタリングで、ちょっと申し訳なかったですね(苦笑)。

そんなわけで、2018年12月には正式版をリリースしました。

(一同拍手)

ーー そこからリファクタリングに着手したということですね。

肥前: はい。蓋を開けてみたらやるべきことは色々あり、結局3ヶ月もかかりましたね…。

ーー どんなことをしたんですか?

肥前: フロントエンドはほぼイチから書き直し、再設計しました。バックエンドはBlue/Green Deploymentというアプローチを用いて、リリース時のリスクを下げるような変更を行いました。

ーー その結果、今はどんな状況ですか?

小田: リファクタリングは先週完了して、すでに2、3回リリースがありましたね。

肥前: 以前はリリースのときに心拍数が上がって大変だったけど、平常心を保てるようになりました(笑)。先日のリリースは、念の為23時から5時まで予定をおさえていましたが、結局0時頃には終えることができました。

鈴木: でも朝の3時くらいに肥前さんからエモコメントが送られてきたよね。眠れなかったのかな(笑)。

小田: 俺速攻いいねした(笑)!

ーー たしかに朝の3時にこのメッセージはエモい…。サービスリリース直後だったということもあり、相当なプレッシャーがあったんでしょうね…!

リリース直後に新規開発をストップする、という勇気

ーー 社長の鈴木さんは、この状況に対してどう考えていましたか?

鈴木: いやー、正直ドキドキしてましたよ(笑)。ビジネスサイドとしてはリリース直後に新規機能開発をストップさせるのは、かなり勇気のいる決断でした。1日でも早く実装すべき機能が大量にあったので。

でも、エンジニアからは「リファクタリングをすべき」という声が定期的に上がってきていたんですよね。「向こう数ヶ月ではなく1年後、我々のカスタマーにより大きな価値を提供するために、今リファクタリングするべき?機能開発を進めるべき?」と聞いたら「リファクタリング」ということだったので。じゃあやるか、と決意を固めました。

β版の時点で既にある程度トラクションがあったため、今機能開発をストップしても直近に関してお金の面はどうにかなると思っていたので、それなら1年後にどれだけの価値を生み出せるかをベースに考えようと思ったんです。こうなったら仕方ないので、頑張って待っていましたよ(笑)。

ーー エンジニアサイドからすると、これを理解してもらえるのは嬉しいんじゃないでしょうか?お互いに理解しあえなかったり衝突することはないんですか?

肥前: 一発で理解しあえるとは思っていないですね。月に1、2度、サービスのロードマップについて話すタイミングでお互いにすり合わせをしています。

鈴木: お互いの守備範囲や専門範囲も違いますし、それに費やしてきた時間も違うので、表面的な状況を伝えるだけでは理解できないという共通認識があると思います。

先日も、この先1年で目指していく売上や、それを達成するためのアクションなどについてブレイクダウンして説明しました。その後に、「それなら開発側としてはこういう風に動いていくべきだよね」という自発的な議論が発生していたんです。目指しているゴールは同じなので、それを理解した上で自走できるメンバーが多いですね。

小田: 数字で話をしてもらえるのはいいですね。エンジニアとしてもそれをベースに優先順位を立てて意思決定がしやすくなります。

オンボーディングコストを下げるための基盤作りを進めている

ーー 今の課題はどんなところにありますか?

肥前: 新しく入った方のキャッチアップの難易度が高いところですね。コードは見れば状況がわかりますが、その根拠や背景が見えないんです。なので今はDesign Docを使ってドキュメント化を進めているところです。

正式リリース前に業務委託の方に協力してもらっていたときは、準備をせずに突っ走ってしまった感じでしたからね…。

鈴木:当時はやるべきことがたくさんあったので「とにかく人を増やさないと」と考えていたんです。でもフルタイムでの採用は難しいので、副業で色んな方に関わってもらった結果、社内からは「人が増えればいいもんじゃない」と言われてしまいましたね…(苦笑)。

肥前: 増やすなら先に相談してほしかったですよね(笑)。アポに行ってみたら「明日から一緒にやりませんか?」みたいな状況だったので…!

鈴木: そういう失敗を繰り返しながら大人になっています(笑)!

プロダクトに集中できるフェーズに

ーー 創業1年目にしてそんな失敗や困難を乗り越えてきたHiCustomerに今このタイミングで入ると、どんな経験ができますか?

肥前: 今なら、ようやくプロダクトの機能開発を全力で走らせることができます。プロダクトをよくすることだけに集中できますよ!

小田: 事業ドメインに共感できる人にはすごくいいタイミングだと思います。

肥前: プロダクトの規模も大きくなってきたので、今後はサービス単位でチームをわけていくつもりでいます。使う技術は、そのチーム内に任せられるような基盤を作っていきたいですね。これができないと、新しいメンバーに入ってもらってもスケールしないと思うんです。

小田: 開発環境はモダンですし、これからデータが溜まっていくのでその分析や活用もどんどん面白くなっていくと思います。

肥前: 合理的な意思決定ができるのはHiCustomerらしいところですよね。その基準はDesign Docにまとまっていますし。スクラムのポイントの考え方を用いてビジネスサイドとも対等に議論ができます。社長のワンマン経営の会社じゃないので安心してください(笑)!

小田: 上司によって会社の性格は変わりますからねー。上司がいいんですよ本当に。

ーー これ、書いても大丈夫ですか?言わされたっぽくならないですかね…(笑)?

鈴木: ちなみにこの記事をWantedlyでポストするの僕なんですけどね(笑)。

肥前: 手前味噌感がすごいわ(笑)。

ーー 上手くオチましたね(笑)!和気あいあいとした楽しい取材でした。

創業1年目のリリース直後にサービス開発をストップするのは、中々勇気のいる決断ですよね。ビジネスサイドがエンジニアへの理解を示し、長期的な視点で価値のある道を選択できるのは素晴らしいことだと思います。ここから先はプロダクトの成長に集中できるタイミング。この先のHiCustomerが楽しみです!


今回のリファクタリングに関連するブログポスト/スライドはこちら:

ServerlessなサービスのBlue/Greenデプロイメントの現実 | HiCustomer Tech Blog
いやー春が近いですね。ウキウキのHiCustomerの小田です。最近の騒動で知ったんですが、Linuxカーネルのstableへのバグフィックスの一部はNeural networkを使って自動的に選定されてバックポートされているようです。正直まだGregの超絶な能力のみを使ってマニュアルでさばいているのかと思っていました。一般的にバグのバックポートはめちゃめちゃerror-proneな作業なため、その辺が進化してくれると今後いろんなソフトウェアが幸せになりそうです。詳細は以下にまとまっています。PatchN
https://tech.hicustomer.jp/posts/blue-green-deployment-in-serverless/


HiCustomer株式会社's job postings
Anonymous
Picture?height=40&width=40
098a5059 0758 4fe5 bafe 76bec580d7ec?1545096087
0413a6c9 3d90 455f b7f7 06038a97f2d9?1523851948
F56bda7c 7978 499c 963c 02f641622859?1506991941
26f2026f bf08 46a8 831e ae1099699b55?1551430428
10 Likes
Anonymous
Picture?height=40&width=40
098a5059 0758 4fe5 bafe 76bec580d7ec?1545096087
0413a6c9 3d90 455f b7f7 06038a97f2d9?1523851948
F56bda7c 7978 499c 963c 02f641622859?1506991941
26f2026f bf08 46a8 831e ae1099699b55?1551430428
10 Likes

Weekly ranking

Show other rankings
If this story triggered your interest, go ahead and visit them to learn more

Page top icon