エンジニアの田中です。そういえば、もう3ヶ月経ったので、これまでにやったことを振り返ってみます。
今はまだ前職での記憶も鮮明に残っている一方で、入社してから色々と見えてきたものもあるので、割りと冷静な視点で書けるかなと思っています。実は、これくらいのフェーズのスタートアップにJOINするのは2度目です。経験を活かして先回りしてつぶせた部分もあれば、全然通用しなかった部分もあり、学びの多い3ヶ月となりました。
今、スタートアップ・不動産テックといったキーワードやtoC向けのサービス開発などに興味をお持ちの方に、少しでも現場の雰囲気が伝われば幸いです。
簡単な経歴
近年のお仕事では主にRubyとSwiftをいったりきたりしています。それなりに転職を経験してきたので、年齢は30半ばです。
金融系のSEとしてキャリアをスタートし、主にメガバンク向けアプリケーション開発と基盤リプレイスを担当しました。その後、C.A.モバイルという所で広告プロモーション用iOSアプリを色々と作らせて貰いました。同時にプライベートでは他社のメンバーとチームを組み女性向け人材系サービスの開発も行っていました。
色々あってプライベートプロジェクトが頓挫してしまったので、仕事終わりに人材系スタートアップのLiBという会社に遊びにいきました。当時、CTOがたった一人で、ものすごい熱量でコードを書いて頑張っていました。大変そうだったので、何となく流れで週末や夜間にLiBを手伝うこととなりまして、いつのまにかフルタイムのメンバーとしてJOINしてました(笑)。
１つのサービスにじっくり取り組んで数値をみながら、少ないリソースで改善サイクルを回していくスタイルはLiBが初めてで、色々と失敗しながら勉強させて頂きました。また3年の間に2度のオフィス移転を経験し、10人程度から70人近くまで人員拡大する過程を経験しました。この経験から急激に人が増えていく過程で何が起きるのか、以前より想像力が働くようになった気がします。
そして今、ご縁があってHousmartに在籍しています。
Housmartってなんですか？
Housmartは圧倒的にわかりやすく、自由な不動産市場の創造を目指して頑張っている会社です。詳しくはこちら。
自分はここでエンジニアとして働いています。
不動産ということでお硬い雰囲気を想像するかもしれませんが、職種や肩書問わず誰とでもフラットに議論して、お客様にとって良いと思うことはどんどんやらせてもらえていると思ってます。
エンジニアがボードメンバーの半数(3人)を占めていて、非エンジニアのボードメンバーやセールスのメンバーも定期的に時間をとってプログラミングを勉強してたりします。不動産事業を営む企業としては珍しい風土ではあると思います。
エンジニア組織
顔ぶれ
年齢としては30前後のメンバーが大半を占めていて、みな、マルチスキルのメンバーで、全員が一人でプロジェクトを持って走りきれるメンバーです。もちろん分野によって得意不得意はありますが、そのつどレビューやペアプロも交えながら いい感じに補完しながらやれていると思っています。開発に参画しているメンバーはエンジニア7人、デザイナー1人といった構成です。
体制
エンジニアをリーディングしていく上で求められる役割は色々あると思いますが、ことスタートアップにおいて、以下のようなロールはCTOに一手に委ねられることも多いかと思います。
- 技術戦略
- プロダクトのロードマップ策定
- 組織設計、人事評価
Housmartでは、上記3つそれぞれの領域において、責任者をおいています(もちろん、みんなエンジニアです)。
これが良いか悪いかはチームの状況だったり会社のフェーズ次第ですが、実際問題としてそれぞれのロールは頭の使いどころだったり、学習コストを払うべき分野も異なるので、今のチームにはフィットしているのではないかと思っています。
開発スタイル
現在のスキルセットだけでチームを区切るような事はせず、個々のエンジニアが担当施策の中でユーザヒアリング・営業同行・数値分析・企画・インフラ・Rails・iOS・Androidなど必要に応じて何でもやります。
そんなスタイルなので、自分もAndroid触り始めたり、Machine Learning用のリポジトリも覗き込んでみたり、セールスオペレーションの効率化に取り組んだりと、世界観が広がっていってます。
個々人が複数分野に知見をもっていることで、案件をすすめる上でのコミュニケーションコストが低いのも嬉しいポイントです。
投資
投資という意味では2週間のスプリントの中で、以下の時間を明示的に確保しています。
- 短期的な指標で評価しようとすると優先順位が上がりにくいオペレーションや開発環境の改善を行う「kaizen day」
- 自身の興味のある技術の自由研究にあてる「lab day」
何に投資をするか、というのは「自分達がどうありたいか」に深く関わってくるので、このあたりはHousmartの考え方が色濃く出ている所だと思います。
lab dayを導入した背景については、こちらにも詳しく記載しています。
また、外部の専門家も巻き込んで、画像認識や価格推定、自然言語処理といったR&Dっぽいプロジェクトも複数走っています。
やったこと
ここまでは弊社Housmartの紹介でした。ここからは自分が入社してからやったことを大きく4つに分けて振り返ってみたいと思います。
1.グロースハック
JOINした当時から見学率(見学申込を頂いたUU/MAU)をプロダクトチームの目標数値とおいて、数ヶ月間走ってきましたが、結果としてかなりアグレッシブな目標数値を達成でき、成功だったと言える結果となりました。
エンジニアとしてサービスの数値を動かすことができ、(まだまだ至らない部分はありつつも)お客様のニーズに一定応えられたことは純粋に嬉しく思っています。
グロースハックの文脈では、自分は以下のことに取り組みました。
サービスの内容把握
最初の一ヶ月は、デバッグや簡単なバグ修正、開発環境の改善などを行いながら、合間にポチポチSQLを叩いて主要な数字を拾い、サービスの実態を把握することを心がけました。この期間にアプリのUI/UXで気になる所もどんどんSlackに投げ込んで、周りもそれにリアクションしてくれる過程で色々と理解が深まりました m(_ _)m。
ボトルネックの特定
見学率向上という目標自体は非常にはっきりしていたものの、本当に改善すべき箇所を特定してリソースを集中投下する必要がありました。 そこでアプリの起動から見学に至るプロセスの中でボトルネックになっている部分(=開発リソースを投下して改善すべき部分)を特定しました。分析ツールとしては、これを使えば全部把握できます!といったものはなかったためKeen、 SQL、モバイルアプリの各種SDKなどを総動員して、ボトルネックを特定しました。
デプロイした内容を振り返り、全員が見える場所で共有する
当時はタイトな開発期間の中、複数の施策が並行して走っており、放っておくと「デプロイしっぱなし」になっている施策もありました。今振り返ってみても、数値が下がるようなリスクがありそうな施策はほとんど打っていなかったはずですが、それでも「どの程度よくなっているのか」「本当に悪くなっていないのか」が把握できないと次のチャレンジができなくなります。
そこで、まずは開発リソースを大きく投下した主要な施策から、クエリを叩いて施策の結果を振り返り、得られた結果をこれまたSlackとDocbaseに投げ込んでいくようにしました。
また、施策の実装に着手する前に、「そもそもリリースした後、どの指標を確認しに行くんだっけ?」みたいなことも会話するようにしました。
周囲のエンジニアが計測環境をゴリゴリ整えてくれていっている最中のことでしたので、色々見れるものがあって楽しかったです。感謝しかないです。
2.コミュニケーション改善
人数が増えて開発ラインが複数走り始めていたのですいが、お互いのタスクの細かいところまでは把握できておらず、トラブルの予兆をキャッチするのが難しくなってきていました。
そこで昨日やったこと・今日やること・困っていることを毎朝Slackに投げ込むようにしました。自分の投稿がきっかけかどうかよく覚えてないのですが、いまでは他の人も毎朝Slackに同じ形式で投げ込んでくれるようになりました。
昨日やったこと/今日やること/困っていること
ちなみに、上の写真の”昨日やったこと”の部分は、JIRAに記録された内容をもとにスクリプトで自動生成されています。西辻さんというエンジニアが作ってくれました。キャー ニシツジサーン。
お互いのタスクを毎朝把握する、わかりやすいメリットとしては以下のようなものがあると思います。
- 他の人がマージしたいタイミング/デプロイしたいタイミングを知る(コンフリクトによる手戻りを防いだり、テスト環境を占有して使用したい時間帯等を把握する。)
- サポートできる人/サポートを必要としている人を把握する。
- 各自、頭の中が整理されてタスクの棚卸しができる。
新卒の時は日報とかバカにしてましたが、今となってはなかなか良いものだと思っています。
3.Railsのコード整備
成長するサービスの常として、それなりに技術的負債もたまり始めているものの、いま在籍しているメンバーは非常に改修スピードが速く、熱量も高い人達なので、一人で立ち向かう必要も全くないと思ってます。なのでサンプルになりそうなテストコードを書いたり負債を可視化することに注力しました。ごく一部の抜粋になりますが、こんな事をやってました。
- bulletを入れて n plus one queryを検知しやすくした。
- FactoryGirlがたまに落ちる作りになってたので、ちょこちょこ修正した。
- テストカバレッジ上げたかったので、機能実装の際にはなるべく該当する部分のテストを書いて、バグ出た所にもテストを書いた。
- CIにカバレッジレポートを連携させてみんなが見えるようにした。
- メールのリデザイン案件が走り始めたので、メールのテストがDRYになるようにshared_examplesを書いた。
自分の事だけ書きましたが、みんな忙しい中、リファクタリングや開発環境整備のPRもバンバン飛ばしててスゴイなーと思います。
4.外部発信(Tech Blog、OSS貢献)
Housmartの事業は、誰のどんな課題を解決しようとしているのかがはっきりしており、純粋に良い事業だと思っているので、もっと多くの方に知って頂けたらなと思っています。
ということで、更新が止まっちゃってたTech Blogも再開しました。ついでに前職でお世話になったReactiveSwiftにも少し貢献できて嬉しかったです。
SwiftのOSSライブラリに機能を追加したときに心がけたこと · カウル Tech Blog
Tech Blogについては、まだ手動で運用してる部分も多いので、この辺を自動化したいと思います。 記事の内容を解析して自動でタグ付けしたり、基本的なtypoなんかは自動検出できると嬉しいですね。
実際に一番時間がかかっているのは、「何を書くか」というネタづくりの部分だと考えているので、ここも何かしらテクノロジーでサポートできると良いなーと思っています。
今後の課題
モバイルアプリのグロースハックについては、かなり事例なども公開されるようになってきて、計測用のSDKもReproなど便利なものが出てきました。実際にこういったツールを駆使し、施策を打つことで、アプリのリテンションは一定の改善をみることができました。
一方で、お客様の体験を真の意味で変えにいくには、Webアプリ、モバイルアプリの様な表の部分だけ改善していてもなかなか難しく、裏側の不動産業務に踏み込んで、オペレーションの改善も同時にやっていかなければならないと実感しています。このあたりはいまだに分析や自動化に不向きなバラバラのフォーマットでデータが保存されていることも多く、まずはデータを整備するところから始めなければなりません。
いわゆるモバイルアプリのグロースハックよりも更に泥臭い訳ですが、それだけに未開の領域で、やること盛りだくさんなので、今から燃えています。
所感
commit logだったりDocbaseを見ながらまとめてみました。
今後も、自分の守備範囲を区切らず、事業の成長とエンジニアチームの成長の両面に貢献しながら頑張っていきたいです。
転職してから、何人かの方からHousmartどう?と聞かれましたが、一点の曇りもなく「楽しいですよ。」と答えられる自分が居たので、価値観だったり空気感はフィットしていると思っています。
自身もプロダクトもまだまだ伸びしろがあると思っているので、現状に甘えずやっていきたいです。
Housmartでは不動産業界を変えるカウルを支えるエンジニアを募集しています。
今話題のReTech！業界を変えるカウルを支えるエンジニアをWanted！