「46,000RTのエンジニア」
町野史宜氏（以下、町野）：はい、ありがとうございます。では最後にラブグラフ成澤様、お願いいたします。
成澤克麻氏（以下、成澤）：はい。では、最後のLTということで、ラブグラフの成澤から発表させていただきます。タイトルは「日本中のカップルを支える技術」です。どうぞよろしくお願いします。
今回の発表では軽くサービスの紹介と、サービスで使っている技術の紹介と、あともう1つ。だいたい規模が5人から20人ぐらいになってきたスタートアップの開発事情、生々しいナマの声をご紹介させていただこうと思います。よろしくお願いします。
まず先に、自己紹介をさせてください。成澤克麻と申します。ラブグラフでリードエンジニアをしております。前職はディー・エヌ・エーという会社でソーシャルゲームを作っていました。その頃から開発だけじゃなくて、けっこう1人で企画・開発・分析して、という感じで幅広く開発をしておりました。
2年半ぐらいディー・エヌ・エーに勤めた後に、今住んでいるシェアハウスで代表の駒下と出会ったのをきっかけに、今の株式会社ラブグラフにジョインしました。大学時代は自然言語処理という研究をけっこうがんばっていました。好きなものは写真と旅と日本酒とビールです。
ぜんぜん関係ないんですけど、写真が好きなので、撮った写真の紹介をさせてもらいます。桜の写真がすごく好きなので、桜の写真と、あと女性のポートレートとかをよく撮っています。こんな感じの写真とか、あとこれも桜ですね。これは家の近くなんですけど、目黒川の夜桜の写真とか。こんな感じで写真を撮っております。なんにも技術は関係ないんですけど、こんなことをしております（笑）。
（会場笑）
それで、これが高じてテックノートさんに最近インタビューをしていただいたんですけれども、そのインタビューのタイトルが「46,000RT越えの夜桜写真を撮ったエンジニア兼カメラマン」という、なかなかパワーが強いタイトルを付けていただきまして（笑）。「46,000RT エンジニア」で検索すると、僕がトップにくるような感じです。
（会場笑）
「46,000RTのエンジニア」として覚えていただけると幸いです。
1人で始めたサービスが今は全国レベルのサービスに
成澤：では、簡単に会社の説明をさせてください。ラブグラフという会社では、出張撮影サービスの提供をしております。
どんなサービスかというと、主な客層はカップルで、それ以外にご家族もいらっしゃいます。例えば、カップルの方々がうちのライブサービスで、「この日に撮影をしたい」と撮影を申し込まれると、その場ですぐにカメラマンが手配されます。
カメラマンから「どこでどんな感じで撮りたいですか？」という感じでヒアリングが始まって、撮影日当日は2人のデートに同行するようなかたちでカメラマンが2人の自然な素敵な姿を撮って、すぐに納品して、それがWebサイト上で見られる。そして、他の方が撮った写真も見られる、というようなサービスを提供しております。
もともとは創業者の駒下が1人で始めたサービスがSNS上で人気になって、1人で全部対応していたのですが、「お客様に交通費をいただくことになってしまい、申し訳ない」という話で全国のカメラマンに協力を呼びかけたら、すごく有名なカメラマンがたくさん集まってくれて。
そして、たくさんのカメラマンが集まったら今度はマッチングの問題で、アサインとかを1人でずっと手動でやっている時期がありました。それがまた「大変だね」という話でエンジニアを雇ったりして、だんだん会社として大きくなっていった、というサービスです。
どんな写真を撮っているかというと、これは前撮りの写真ですね。こんな写真を撮っていたり。カップルだけじゃなくてご家族もこんな感じで、主に外で自然な素敵な写真を撮ったり。最近は友達同士でも浴衣を着て撮影とか、こんな感じで撮影をしております。
僕自身も撮影に行ったりしていて、もちろん平日はエンジニアとしてずっと働いているんですが、土日はけっこうカメラマンとして撮影に行ったりしています。
このお客様はすごくおもしろくて。おもしろいと言ったら失礼なのですが（笑）、撮影前まで喧嘩をしていたらしくて、カメラマンとしては、撮影前に喧嘩されると非常に困るのですが、でも撮影してたら「楽しくて喧嘩してたことも忘れちゃいました！」なんて嬉しいことを言ってくれて。
1ヶ月の記念日ごとに彼氏さんの方から手紙を送っているらしいんですけど、この日は2年半くらいの記念日に撮影に来ていただいて、その日に今までの手紙と全部一緒に撮影したり、あとその場で手紙を渡しているところを撮影したりしました。こんな感じのハートフルなサービスをやっております。
テレビとかにもけっこう取り上げられていて、右下とか、弊社の代表が林家ぺーさん・パー子さんを撮影していたり、最近はNHKの『U-29』という番組の密着取材で30分ぐらい出たりとかしていました。
ラブグラフが提供するサービス
成澤：Twitterとかで「ラブグラフ」と検索していただくと、とても雰囲気がわかるんですが、なんかめちゃくちゃポジティブな感じで、「ラブグラフという素敵な写真を無限に見る日」とか言ってくれたり、「ラブグラフの写真よすぎて感動」とか、「選びきれないどうしよう」みたいなことを言ってくれたり。
あと、「ラブグラフ」と「ディズニー」という単語がすごい出てきて、「ラブグラフとかディズニーとか行きた～い」という感じで、一緒に出てくる世界観がディズニーとか。あとは、スターバックスなどがよく出てくるような感じになっています。
Webサービスとしてはラブグラフはどんなことをしているかというと、4年前の創業前には駒下が1人で全国のカメラマンと全国の撮影依頼のお客様を、メールとかLINEとかで死ぬほどマッチングしているようなことがあったらしくて。もう一日中、ずっとそれをやっているような時期があったそうです。
それだともちろん「創業者が死んでしまうよね」というのと、やっぱりお客様にとっても全部手動だとなかなか返信が遅かったりという問題がありました。今ではその辺が全部Webサービスになっています。例えばカメラマン一覧がこうやって見られたり。レビュー機能があるので、カメラマンがどういう人なのかが、レビューで見られたりとか。
あとは、申込ページがあって、そこでポチポチとやって。この申込ページが地味に複雑なんです。今Vue.jsを使ってやっているんですけど、例えば「東京都」を選ぶと、東京都の地図が出てきます。
その地図の中でここ、というのを選ぶと、そこから半径10キロメートル以内にいるカメラマンの予定をフェッチしてきて、その予定をもとにカレンダーが作られて、誰かしらカメラマンがいたら「撮影可能なカメラマンがいます」というやり方で、すぐにマッチングできます。なかなか可動的に作られている申込ページです。
あと、マイページのほうで納品された写真が見られたり。最初はサンプル写真で納品されるんですが、ポチポチとやって「これがほしいです」というかたちで、全部マイページから「この写真ください」と依頼できるサービスを提供しています。
見えない裏側の管理画面も便利に
成澤：表側はそれなんですが、裏側の管理画面も実はいろんな機能があります。例えばカメラマンの方だと自分の撮影依頼の一覧が見られたり、まだ誰もアサインされていない撮影一覧が見られたり。
その詳細を確認して、お客様が入金してくれているかどうかを確認したり。自分の予定を入力すると、そこにお客様が申し込んでくるとか。その予定が自分のGoogleカレンダーと同期していて、Googleカレンダー上でちゃんと見られるようになっているとか。
あとは写真の納品は、普通のUIなんですけど、ドラッグアンドドロップでヒュッと写真をやると、非同期でうちのサーバーへ送られるようになっているとか。当月の報酬の確認ができたりとか。あとは、依頼を受けた時にメールやSlackで通知がくる仕組みを提供しています。
運営側が使う管理画面も同じUIなんですが、そこにはさらにいろんなものがあります。違うところだと、例えばうちでは写真教室やっているんです、その教室の方の管理画面もあったり。体験会もやっているんですが、その管理画面もあったりとか。
あと、自社でメディアも持っているのですが、WordPress的なものも自社で全部実装していて、自社メディアの管理画面や各種のCRUDがあります。
他にもイラストレーターさん用の画面があったり、ライターさん管理画面だったり、外で見えるよりもかなり多くの機能があって。いつも驚かれるというか、僕自身も驚きながら入社した経緯があります。
なぜこんなことをしているかというと、お客様をゲストとお呼びしているのですが、ゲストが直感的なUIでなんの不自由もなくできるようにすること。
そして、ラブグラファーと呼んでいるカメラマンが、本当に撮影体験をよくすることだけを考えていられるように。本当だったら、フリーランスのカメラマンは請求書を作ったりしなきゃいけないんですが、そんなことをせず、かつ、お客様の入金確認もこちら側のシステムで全部するようにしてあげたりとか。
サービスの向上だけを考えられる環境を作る
成澤：あとは、うちのスタッフが煩わしい管理作業に追われるのではなくて、「これ以上このサービスをよくしていくためにはどうすればいいか」というところだけを考えていられるようにするのが、開発チームのミッションです。ということでがんばっております。
それで、このサービスがどうやって作られているのかというと、意外とモダンな感じで作られています。Railsの最新バージョンだった5.1でやっておりまして、「早く5.2にしたいな」と思っているところだったり。あと、フロントエンドはES6とwebpackとかで作っていたり。
分析面もけっこう充実しています。先ほどコネヒトさんも使っているっておっしゃっていたんですが、Re:dashを使って、あとログはFluentdでElasticsearchに流してKibanaで可視化しています。最近はGoogleアナリティクスに同期するために、Googleデータスタジオを使っていたり。あとBigQueryを使ったりとか。
インフラ周りは全部Dockerで、開発環境も本番環境も全部Dockerでやっています。これはわかる人向けにrake statsです。こんな感じで、そこそこの規模という感じです。
どれぐらい技術的な話をしようかなと思っていたんですが、開発体制の遍歴みたいなものをお話しします。最初は2015年頃、社員は3～4人ぐらいであとはインターン生数人みたいなところで、エンジニアは1人だけでした。
この頃の1人目のエンジニアは、僕ではなかったんですが、イシューベースで優先度とかスケジュールを口頭で全部やって、全部よしなにやるようなかたちで進めていたそうです。
2016年の7月に僕が入って、エンジニアが2人になりました。一応「まだまだ大丈夫かな」とは思いつつ、エンジニアが2人になったので、ある程度開発チームとして「もうちょっとまとまっていかないといけないよね」という話をしました。
タスクの優先度をもうちょっとしっかり見えるようにスプレッドシートでまとめて管理したり。あと、「このタスクはいつまでにやりましょう」という話をWBS（Work Breakdown Structure）を引いてスケジューリングしたり。週2ぐらいで開発定例をしっかりやって、お互いにすり合わせる会を始めました。
エンジニアが1人になり反省したこと
成澤：開発内容としてはいろいろやっていたんですが、当時悩んでいたことは管理コストです。「2人なのにこんなに開発定例をする必要があるのか」とか、「WBSを作る必要があるのか」みたいな話で悩んでいたり。あと、質とスピードみたいな話です。
うちはかなり、他の人にけっこう驚かれるぐらいにはコードのクオリティーを担保して、しっかりまっとうな開発をしていくことを心がけてずっと2、3年やっています。ただ、実際「どれほど質にかけるべきなのか」という話でけっこう迷ったりはしていました。
振り返って思うことは、「週2ぐらいでゆるく開発定例していきましょう」という話はたぶんバランスがとれていたなと思っているんですが、最近は、目の前の開発をゴリゴリと進めていくようなことをしがちだったなというのは、けっこう反省としてあって。
もうちょっと長期的に、「このプロダクトはどうあるべきなのか」をしっかり考えて、半年後とか1年後の中長期を見据えて、その時に必要な開発を丁寧にやっていくべきだったなと思っております。その辺はけっこうPMとかプロダクトオーナーとかが不在だったので、なかなか難しかったなとは思います。
エンジニア2人でやっているとお話ししましたけど、その後、エンジニアが1人退職してしまい、エンジニア1人体制になってしまいました。圧倒的に人手が足りないところにかなり悩んだり、「エンジニア1人ってすごく寂しいな」と思いながら障害対応をしたりしていました。
その時の振り返りとしては、採用の重要性をもっともっと上げるべきだったなというのと、「選択と集中」というところで、本当に「なんの開発をすべきなのか」に、もっと思考を寄せるべきだったなと思います。
最近というか半年前ぐらい前の10月頃から、業務委託でエンジニアを採用したり、副業のエンジニアを採用したりしていました。この頃にPMが1人ジョインしまして、アジャイル開発とかも導入しました。
「コードのクオリティーを高く保つ」というこだわり
成澤：開発内容はともかく、当時悩んでいたことは、レビュアーマネジメントがめちゃくちゃ多くなってきて、なかなか開発時間が確保できないことがありしました。
ただ、振り返ってみて思うのは、やっぱり1人でやるよりも何人かで、しかも気の置けない仲間で相談がしっかりできて、チームでわいわい開発できたのがすごく良かったなと思っています。この頃から、1人じゃなくてチームで開発するというところが板についてきたかなと思っています。
次は若干雑になっちゃったんですが、最近の話としては、副業とかを減らしてきて、インターン生ががんばってくれていてバリバリ活躍中という感じです。
さっきもあったのですが、うちでけっこうこだわりを持ってやっているところとしては「コードのクオリティーを高く保つ」というところです。副業のエンジニアがいるのですが、元ディー・エヌ・エーとか、すごく優秀な友達のエンジニアから「すごい。こんなにきれいなコード見たことない」という感じで、きれいなコードを考えています。
コードの質がしっかり高いものを目指していかないと、一生低いままなので。低いままで開発し続けてしまうと、やっぱりメンテナンスがどんどんダメになってしまう、というこだわりを持っています。ただ、質とスピードはどっちも取らなければいけないので、エンジニア一人ひとりが、自分が成長することでしっかり開発の質もスピードも上げていきましょうという哲学でやっております。
いちエンジニアとしては、本当にこの進め方ですごくいいなと思ってはいるのですが、リードエンジニアとして、マネージャーとしての立場として言えば、なかなか「教育も大変だよね」とか「採用も難しいよね」というところで、そこに関してはずっと1年間迷い続けているなという感じではあります。この辺の話とかぜひ誰かとお話ししたいなと思っているので、次の交流会でお話しできたらなと思っております。
カメラマンとしてドッグフーディングをしながら開発している
成澤：この辺もいろいろ書いたんですけど、時間が押してしまっているので、例えばHoundCI、ご存知ですかね？ コーディング規約のClツールで、規約を遵守しないと、RuboCopとかが怒ってくれるんですけど、これを必ず守るルールでやっています。これは、けっこう特徴的なのかなと思っております。
あと、みなさんも使っていると思うんですが、Slackです。うちは本当に、なんでもかんでもSlackに通知を送るようにしていて。お客様とかカメラマンがなにをしているのかをしっかり可視化できるように、かつ透明感です。エンジニアだけがログを見られるというのではなくて、運営の誰でもそれが見られて、かつそれに対して、「これはまずくないですか？」とか「このお客様はすごくいいお客様だね」みたいな話ができるというようにしております。
あと、Vue.jsを使っていて、けっこう満足しています。Dockerも使っています。Dockerはすごく勉強した今となっては快適なんですが、けっこう学習コストはかかったし、これからもたぶん新しいメンバーが入る時に、Dockerを知らないとかかってしまうなというのはあって、どうだったのかなと思っております。
懇親会でお話ししたいなと思っているのは、各チームでけっこういろいろやった話です。開発をやったりマーケをやったりCSをやったり、カメラマンのマネジメントをやったり。組織が回る仕組みを作っていますというお話とか。
僕自身カメラマンなので、管理画面を自分自身で作って使っています。カメラマンとして、ドッグフーディングしながら開発していますというお話とか。この辺のお話とか興味あったら、ぜひお聞きください。
こちらで最後になるんですが、ラブグラフでは一緒に働いてくれるエンジニアを大募集しております。今日のお話を聞いて興味を持っていただいた方は、この後社員が来てくれているので、ぜひお話しください。交流会で社員とお話しした方には、素敵な贈り物を用意しております。ということで、ご清聴ありがとうございました。
(会場拍手)
