ハートフルに働いていてもしんどいこと
町野史宜氏（以下、町野）：ありがとうございました。では、今から質疑応答に進めさせていただきたいと思います。質問のある方はいらっしゃいますか？ ぜひ手を挙げて、質問を受けてみたいなと思うんですけれども。
質問者1：ハートフルというか、ユーザーに満足していてという話を聞いてうかがいたいんですが、けっこう泥臭い部分もあるのかなと思っていて。ハートフルに働いていてもしんどいこととか、教えていただきたいです。企業で働いていてつらいなと思ったこととか、教えていただきたいなと思います。
奥原拓也氏（以下、奥原）：つらかったことは、さっきラブグラフさんも開発者が1人って言っていたんですが、3日前くらいまで僕もサーバーサイド1人っていう。1,000万ダウンロードでサーバーサイド1人って、けっこうやばい。
（会場笑）
僕はけっこう、Githubの草がめちゃくちゃ生えるみたいな感じがめちゃくちゃあって、この規模のサーバーを1人で支えているっていう自信もあったし、すごく楽しかったけど、やっぱりつらかったなというところがありましたね。
高野福晃氏（以下、高野）：つらかったこと。1個あるのが、スピードを優先して作っているので、時間が経つと当然負債になっていきます。それが重くのしかかってきてつらくなるなっていうことがあるんですけど、うちの場合は割とCTOと相談しています。
例えば、業務の20パーセントは負債解消にあてようとか。リファクタリングするための工数確保は効果、数字で取りにいくと負けちゃうので、CTOと話して「じゃあリファクタリングしていいですかね？」「君が言うならいけ」という感じで現場のエンジニアの肌感を信頼してやらせてくれる環境があります。そのおかげでいい感じに返済できているのかなと思っています。
カスタマーサービスを大切にしている
成澤克麻氏（以下、成澤）：ラブグラフでは、さっきおっしゃっていた通り1人で開発するところがだいぶ大変だなというところです。1人でサーバーサイドはもちろんフロントエンドもけっこうあるので開発して、かつインフラも全部面倒を見なきゃいけないみたいなところがつらいところではあるなとは思っています。
本当に自分が理解していないところがあると、例えばさっきのDockerを理解していないところがあって障害があって「よくわからない」で終わってしまうと、サービスが一生終わってしまうような感じです。
本当に自分で全部が全部を理解していないといけないのはつらいところではあります。ただ、その責任感みたいなところでこの1年成長できてきたのかなと思っているので、いいところではあるかなとは思っております。
町野：ありがとうございます。あと2～3個質疑応答を受け付けられるので、よろしかったらこのタイミングで手を挙げてご質問いただけると大変うれしいんですが。はい、ありがとうございます。
質問者2：とくに奥原さんにおうかがいしたいんですが、スライドの中にあったアプリ内のコメントとかがめちゃくちゃ多いなと思ったのが1個。あれだけのコメントって、しかもレシピ動画とかですごくくるというイメージがなかったのですが、そこは持続的なファンとのコミュニケーションみたいなことを意識されているのかなというのと。
あれって立場的に、上の方々がすごく気にしないとああいう意見が集まるような施策ってなかなか打てないんじゃないかなと思っています。奥原さんの守備範囲を超えるかもしれないんですが、会社全体でそういう雰囲気があるのかどうかをおうかがいしたいです。
奥原：やっぱりCM系のサービスって、例えばこれはちょっと悪ふざけかもしれないんですけど、「砂糖ってどこに売っていますか？」みたいなユーザーの方もいます。開発的な実情を言うと、コメント機能がそもそもあったからという。
CTOが1人で作った時に、今の「たべれぽ機能」と「コメント機能」があって、もともとけっこうコメントがきてたんです。それをとりあえず返そうみたいなところがあったんですが。
きれいなことを言うと、やっぱりメルカリさんとかって社員の半分がCSみたいな、CSをめちゃくちゃ大事にしているというところもあって。僕らもCM系のサービスというところで、全社的に誰もが「CSってすごく大事だよね」と思っているかなということですね。
町野：ありがとうございます。では、お願いします。
いろいろな働き方が増える今、仕事はどう分担するか
質問者3：今スタートアップで、エンジニアは1人くらいでいいという状況がけっこう多いじゃないですか。そのうち副業とか業務委託が多いので、そこで作業範囲は決めたほうがいいかなと思っています。ここは難しいけどやっぱり自分が作った方がいいか、そこは誰かにお願いする方がいいか、その決め方の根拠というか基準はどうでしょうか？
成澤：おっしゃる通り、すごく難しいところだなと思っています。とくに解もない話かなとは思っているんですが、最近すごく気にしているのは、将来的にどうなってほしいのかというところです。
すごく重要な機能で丁寧に作らないとだめだから、この人には任せられないという感じでずっとやっていただいていると、その人にはずっとその仕事しか任せられないというところはあるのかなと思っています。
若干チャレンジングになるし、いろんなことを吸収してもらわないと難しいけど、この人に任せて、将来的にはこの辺も全部任せられるようになってもらいたいということを意識しながら（任せるようにします）。もちろん、そこをしっかり丁寧に作りたいかどうかとか、バランスを見ながら考えていくことですね。
町野：お二人もよかったら、その辺お話しできるところがあれば。
高野：うちの場合は、僕が5人目で入社したので、そもそも状況が違う部分はあるんですけど、うちの中で誰がどこをやるかみたいなところは、わりと一番得意なやつがやるというかたちで決まっています。それは、それが一番市場に早く出せるからという感じです。
その後、それが影響してなにかよくないことが起きたりしたら、すべてチームで解決しようという感じで、コンセンサスがとれています。ただ気を付けたいのが、それをやってしまうとできるやつにさらに仕事が回ってきて、ビギナーな人にはなかなか仕事が回ってこないということがあるので、そこはちゃんとCTOやスクラムマスターが調整して、なるべく負担が偏らないようには気を付けてやっています。
なにを優先して開発すべきかの優先度の付け方
奥原：delyの場合はけっこう特徴的かなと思っています。クラシルを始めて本当に初期ぐらいしか、業務委託がいなかったんです。Androidで業務委託でやっていただけて、あとは業務委託を雇っていない状況です。CTOに聞いたら「パツパツくらいがちょうどいい」みたいな。「とりあえずやって」と言われればやるみたいな感じです。
余計なリソースをやっていると、やっぱり脂肪になっていくんですよ。コミュニケーションコストだとか、いろんなものが高くなってしまっていて。うちは、例えばエンジニアも9時から18時は絶対フルタイムでいるとか、そこらへんはすごく他のスタートアップにはないような特徴かなと思っています。あまり答えになっていないかもしれないですけど、とりあえず「いる人でやる」みたいなとこがうちの特徴かなと思っています。
質問者4：3人の共通したお話として、「お客様に早く価値を届けることが大切だよね」というお話があったかと思います。早く価値を届けるために、生産性を上げていくことも重要になると思うんですが、なにをやるべきかを正しくジャッジして決めていくかという開発の優先度が重要かと思います。
まずなにを優先して開発すべきかという優先度の付け方について、どのような取り組みやスタンスでやられているかを教えていただければと思います。
奥原：優先度は僕らもまだまだです。例えば僕だと、サーバーサイドが1人というところで。リソースがめちゃくちゃ限られている中で、どうやって優先度をつけているかというと、エンジニアが入ってきたときに、「delyは今事業的に何本収益の柱があって、今どこを一番伸ばさなきゃいけないか」を初めのオン・ボーディングの時に1～2時間使って、かなり詳細に説明するようにしています。
「今なにが大事か」が浸透すると、おのずと方向性（が合う）というか、みんな「これを今やらなきゃいけないことだよね」という同じ考えに至るかなと思っています。
優先度の付け方は、スタートアップだと日々、「今なにを一番やらなきゃいけない」とか「あのサービスがつぶれたから僕らもやらないといけない」ということがあったりします。優先度はけっこう日ごとに変わっていくので、朝会とかでやっているという感じですね。
あえて数値化せずカンバンで表現する
高野：他の2社も同じだと思うんですけど、コネヒトの場合は、優先順位は人が決めています。ついこの間までは、CEOが決めていました。最近は委譲して、VPoPというプロダクトの責任者がいるんですけど、その人が決めるようにしています。
それはどうやって表現されているかというと、ZenhubというGithubのイシューを拡張するようなサービスがあるんですけど、それを使っていて、まさにカンバンのボードみたいなかたちでイシューが一列に並んでいる。その並び替えで優先順位を表しています。
それがどういう基準になっているのかは、正直POの頭の中にあります。POはたぶん事業計画とかいろんなものを勘案してやっているんですけれど、あえて数値化とか見える化はしていなくて、カンバンで表現しています。
数値化して全員が優先順位を判断できるようにしてもあまり意味がないので。なぜこれをやるのかという目的さえ共通認識として持っていて、かつ現場のメンバーが「この人が優先順位が高いって言うんだったら、絶対これは売れるサービスのために必要なんだ」と信じてやっているような、そういう信頼関係から優先順位が決まっているという感じです。
成澤：優先順位をどう決めているかということに関しては、経営課題に基づいて決めているみたいな、ちょっとつまらない話になってしまうんですが。あと、どう仕組み化しているかという話に関しては、うちもアジャイル開発の仕組みを取り入れていて、JIRAを使って、JIRAのボード上に上から順番にやっていくようにしています。
そこのチケットの整理みたいなものを主にPMが全部やってくれているのと、僕自身ももちろん入ってそのチケットの整理をしていたりします。
あとはスタートアップだからあるあるだと思うんですが、僕自身も経営陣として経営会議に参加していたり、PMもそこに参加していたりするので、密に直接経営課題を把握した上で判断しているかたちになります。
町野：ありがとうございます。最後に。
ユーザーの声を聞きすぎての失敗はあまりない
質問者5：今の方の質問と関連しちゃっていると思うんですけれども、みなさんユーザーの声をよく聞いているということで、逆にユーザーの声を聞きすぎて方向性を間違っちゃったかなみたいなことがあったりするのかが気になりました。
先ほどの経営者の経営課題として、軸がちゃんとしているから取捨選択ができているのかもしれないですが、逆にそう進んでいくと、例えば当初のサービスのイメージから若干変わっていくようなことになるのかなと。そういうところで、もしなにかお話ししていただけることがあればお願いします。
奥原：直接ユーザーの声を聞くことはあんまりやっていないです。ユーザーヒアリングとかは、僕らがやっていることの答え合わせだと思うので、ユーザーヒアリングで、例えば「こういう機能がほしい」と言って「やろう」というのはあまりないのかなと思っています。
僕らエンジニアは、社員も1ユーザーとして考えているんです。例えば管理サイトを作ると言っても、スタッフもそんなにリテラシーが高くないので。1ユーザーとして考えると僕は、クラシルってごはんを全部食べられるんですけど、料理人の人から「こういう機能がほしいんだけど」と言われると、「わかりました」と言ってすぐ実装しちゃうんです。それがけっこう蛇足だったりはしました（笑）。
高野：ユーザーの声を聞いて失敗しちゃったということはあまりないと思っています。先ほどスライドの中で、ユーザーインタビューをしていますとお話ししたかと思うんですが、ユーザーに質問すると「こういう機能がほしいです」とか、「こういう時に困っています」と話してくれるんですけど、「じゃあ実際にアプリを開きながら話してみましょうか」と言って、操作しているときが一番勉強になりますね。
「あ、そこでそういう動きをするんだ」とか、「そこから戻るのは私たちの想定外だった」とか、そういうことを意識しています。ユーザーが言ったことよりは、行動などから改善点を見つけています。なので、そんなにユーザーの意見を聞いて失敗したということはないです。もちろん、当たらない施策はあるんですけど（笑）。それはそれでちゃんと振り返って、やめるならもうリバートして戻すみたいな感じです。
ラブグラフには2人のユーザーがいる
成澤：弊社のラブグラフの話だと、ユーザーに当たるものがお客様とカメラマンの2人いるのがすごく難しいところです。C2Cのプラットフォームをやっている方だとかなりあるあるだと思うんですが、お客様の言うことを聞きすぎるとか、カメラマンの言うことを聞きすぎるようなところがけっこう難しかったりします。
そこで失敗したかどうかはまだよくわからないんですけど、ちょっとやりすぎたかなと思っているところとしては、僕自身がカメラマンですし、創設者もカメラマンがいて、新メンバーもカメラマンが多いというところなので、「カメラマンとしてはこの仕様はちょっとこうだよね」とか。
「お客様のためにこういう仕様を入れたいんだけど、これはカメラマンにすごく負担が強いられるからどうしよう」ということを考えがちだなというのは、反省としてあります。
どちらもしっかりいいものにしていかなきゃいけないというのはもちろんなんですが、一番に優先させるべきはお客様なのかなという話を、とくに最近は改めてしているところです。ただ、やっぱりすごく難しいなと思ってはいます。
町野：はい、ありがとうございます。では、これで質疑応答の時間は終わりにさせていただきたいと思います。本日はありがとうございました。
（会場拍手）
