顔出し不要の音声配信プラットフォームサービス「#私を布教して」を運営する同社には様々な経歴を持った社員が集まりサービスを作っています。中にはBtoCサービスの開発がはじめてというメンバーも...。
今回は4月に実装された「新人ライバー応援キャンペーン」を例に、普段どのようにプロダクト開発を行なっているかを取材しました。前職までのBtoB開発とCARROTでのBtoC開発で感じたギャップや、大事にしていることなどを率直に話していただきました。

ーー早速、新機能が実装されるまでの流れを聞いてみたいと思います。まず、新機能の話があがるのはどこからですか？

エンジニア原

プランナーです。機能の要件はプランナー側でイメージをある程度固めてもらった段階になったところでキックオフ。複雑なサービスの場合は、キックオフ前にデザイナーさんに画面イメージを作ってもらうこともあります。

ーーキックオフに参加する人数や職種について教えて下さい。

エンジニア原

企画を担当するプランナー、UIデザイナー、 サーバー担当、クライアント担当、QA担当の五人が基本です。リーダーが参加すると言うよりは、自身の守備範囲の仕様は自身で理解して開発するので、実装担当が出席します。
開発の規模が大きくチャレンジングな機能だと、担当を区分けしています。

ーープロジェクトに関わる人全員が参加するんですね！キックオフでは、デザインチームと開発チームはどんなことを考えていますか？

エンジニア原

プランナーが企画した機能のアイデアを元に、付随した提案や想定されるトラブルなどの質問をし、アイデアをブラッシュアップさせて仕様書にまとめていきます。
キックオフ段階では新機能が入ることで、既にアプリにある機能に与える影響やシーンは何か・どういうものかを想定したり、仕様書に書いていないシーンの対応について質問しながら、打開策を考えたりしています。

デザイナー鈴木

打ち合わせでは「なぜこれを実装するのか」という意図や、想定しているUIイメージを確認するようにしています。ヒアリングを元に実際にデザインにおこし、完成したものを見せて再度意見を拾い、新たな不明点を解消していきます。

ーーキックオフでプランナーからエンジニア、デザイナーに新機能のイメージを共有する際は、テキストベースで共有することが多いですか？

プランナー栗原

テキストだけで共有するのは、僕はやらないタイプだけれど...どっちがいいの？笑

一同

笑。

デザイナー鈴木

個人的には、話し合いをする際はテキストよりも具体的なイメージがあったほうがわかりやすいと思うので、一旦イメージしている画面をざっと作るのは好きです。

プランナー栗原

プランナーによりますが、僕自身も画面をつくって説明するタイプです。急いでいる時でもホワイトボードで図解するか、参考アプリを見せて具体的なイメージで共有するようにしています。ワイヤーフレームベースの認識を初期の段階で擦り合わせしておくと楽なので、今後もそれを当たり前にしていきたいです。

ーーキックオフ以降も2回、3回と打ち合わせは密に行うのでしょうか？

エンジニア原

そうですね。日々の業務と共にSlackベースでコミュニケーションをとりながら、打ち合わせを重ねます。ベンチマークしやすい機能の場合は1回で十分なのですが、抽象度が高いものは、各自に宿題があるので、複数回重ねます。ある程度方向性が見えてきたら、デザインへ関係がなく実装が確定している部分から、開発に着手し始めます。なのでキックオフで仕様が大方決まると、デザインと開発作業はほぼ同時並行で行われます。

プランナー栗原

「新人ライバー応援キャンペーン」の時は、実装したい機能についてメンバーが正しく理解する必要があったので、打ち合わせは2回行いました。

ーースケジュールはどのように組んでいますか？

プランナー栗原

アプリには審査があるため即リリースができません。開発の進捗状況で審査日を決めると、開発が長引いた際にエンジニアのプライベートがなくなってしまうどころか、芋づる式でQAなど工程が後ろのメンバーにも影響がでてきてしまう。CARROTでは、毎週特定の曜日に審査を出すということを決めて、その日までにやるべきことを設定した上で、余裕があれば追加し、できなかった場合は翌週にまわすようにしています。

ーーなるほど、CARROTでは審査日を固定し、それに合わせてやることが決まるんですね。

プランナー栗原

プランナーの要求レベルにあわせて開発を行うと、苦労の多いプロジェクトになりがちです。基本は審査日ベースで計画的に開発していけるようにスケジュールを引くことで、開発メンバーが消耗することを避けています。細かくアップデートしていった方がお客様のデータが取れるので間違いが少ない。
一方で、成長し続けるために3ヶ月に1回ごとにお客様の体験を大きく変えるような企画の開発を行うように心がけています。機能がリリースされるとバグの対応に追われるため、すぐ新しい開発に進めるわけではなく、次の開発までに凪のような落ち着いている期間があります。エンジニアが作業やバグ対応に追われている間は、プランナーとデザイナーが新規の企画を考え、エンジニアの対応が落ち着いてくるタイミングでキックオフを行い、同じように実装まで進めていきます。

エンジニア原

どちらかが手隙の時は次の機能の準備や作業を行なっているので、無駄がないですね。

ーーデザイナーもプロジェクトで進めていく上で意識していることはありますか？

デザイナー鈴木

プロジェクトの初期段階であるデザインのFIXが遅れると、その後の実装も遅れてしまう。デザイナーの最初の動きがスケジュール通りのローンチを左右するので、絶対に遅れないように頑張っています。

エンジニア原

ありがたいなって思うのが、開発に話が降りてくるキックオフのタイミングで最低限の画面や項目があるので、議論を次の段階に進めやすいです。

ーープロダクトを作っていく上で、自分がサービスの利用者であるかどうかが、開発の難しさに直結するという話を聞きます。エンジニア、デザイナー、プランナー含め、自分自身が1人のお客様であるケースは多いものですか？

プランナー栗原

程度の差はあれど、実際にサービスを利用しているメンバーは多いと思います。ただ採用の場面では、その方がお客様だったら嬉しい限りですが、それを重視はしてはいません。お客様のことを理解できるかどうかは重視していますかね。

ーーリリースが近くなるタイミングでは、どのようなコミュニケーションをしますか？

エンジニア原

最後の段階では、開発とQAが忙しくなり、開発のV字モデルに沿って動いている感じですね。今回の「新人ライバー応援キャンペーン」においては、大きなトラブルなくリリースできました。

ーーリリースのタイミングで揉めたことはありますか？

エンジニア原

抽象度が高い案件に関しては、QAの作業が始まってからイシューが発見される場合があります。揉めたというよりは対応をどうするかバタバタした時はありますね。キックオフ段階でQAはたくさんのユースケースを想定してはいるのですが、出来上がって初めて見えてくるものもあるので、こればかりは仕方ないところですが。

プランナー栗原

インタラクティブ性がある機能はその傾向が強いです。例えば投げ銭機能だと、投げ銭をするリスナー、投げ銭をもらうライバー、同じ枠内で視聴を楽しむリスナーに作用するので、三者の見え方が異なってくる。私たちが確認する項目も三倍になる。想定されるパターンも多いので、結果的に抽象的になってしまう。

ーープランナーやデザイナーに対して困ることや改善してほしいことはありますか？

エンジニア原

困ることは鉄板だと思いますが、ギリギリの仕様変更。だからこそ、キックオフの段階で内容を詰めるか、対応可能なように作り、仕様変更しなければならない状況を潰すようにしてます。

ーー仕様変更は起こりうるものですか？

エンジニア原

最近はそこまでないですが、抽象度が高い案件だとたまにあります。
開発側が実装した上で、キックオフで出てこなかったイシューがあった時は、落とし所を決めることもあります。頻度としては前職の受託開発時代のの何百分の一、何千分の一なので頻度はかなり低いです。本当に困った仕様変更はCARROTに入ってからだと1、2回くらいかなと。

ーーそう感じるのはすごい良いことですね。

プランナー栗原

もしかしたら数はもっとあると思うのですが、キックオフやコミュニケーションを厚くとっているので、実装に入る前に相談ができているんだと思います。本当は変更の方向性には動いているかもしれないが、もう少し前のタイミングで議論できているので、ストレスがかかっていないのかなと思います。

ーー同じ質問をプランナー、デザイナーのお二人にも伺いたいのですが、困ることや改善してほしいことはありますか？

プランナー栗原

「言われたものを僕が作るので」というスタンスの方で、最初から「UXの企画の打ち合わせに興味がない」というのは困りますね。ギリギリまで一緒にUXを考えてくれる時間が欲しいです。この段階からエンジニアにも話に参加してもらうことで、小さなすれ違いを避けることができます。

ーーある種のUXを考えることが暗黙知を増やすことに繋がるんですね。

プランナー栗原

「決められたことをやりたい人」にとってはあまり面白くない環境かもしれないですが。UXの部分を開発側に共有することで、「将来こういう体験が想定されるかもかもしれない」と備えることもできて、『実装の先回り』ができる。この言葉は弊社のCTOや原さんがよくいう言葉です。

エンジニア原

『実装の先回り』というのは、「これを意図していることはこういうことだろうというのを先回りして想定すること」で、より機動力を上げる意図があります。さらに「この体験を良くするフェーズ2、フェーズ3があるんだったらこういうふうになるんじゃないかな」と想像力を働かせ、構造を変えて拡張性をもたせやすくしています。

ーーデザイナーで、困っていることや改善してほしいことはありますか？

デザイナー鈴木

実装する段階で若干デザインと変わっている時があって、理由を教えてほしいと思う時があります。意図しない変更であれば修正してもらうのですが、意図があって変更したものについては、教えてもらえると今後に活かせるので助かります。

ーー原さんはBtoCの開発が初めてと聞きました。このBtoC向けのプロダクトの開発と前職のBtoBの開発で何かギャップはありましたか？

エンジニア原

前職が受託開発だったので、自社のBtoCサービスはCARROTが初めてです。感じたギャップは、開発の規模感が1回1回違いますし、リリースのタイミングも違うことです。前職の業務システムの開発だと数ヶ月に1回とか、本番のリリースが数年後ということもありました。BtoCのリリース頻度はBtoBと比べるとハイペースに感じます。実際にローンチした機能の反響もリアルタイムで見れるので、そのサイクルが新鮮でした。

ーーキャッチアップに苦労することなどはありましたか？

エンジニア原

特別苦労していることはありません。開発とお客様の関係性が近いので、お客様からの反応に対して常にアンテナをたてている必要性はあります。我々は普段の実装でも意識していますが、慣れない人は苦労するかもしれません。

プランナー栗原

デザイナーもそうですが、そもそもの話で、「アプリの審査日」というのにも苦労するかもしれませんね。

デザイナー鈴木

たしかに。

ーーBtoCプロダクト開発の魅力や醍醐味を教えていただいてもよろしいですか？

エンジニア原

お客様との距離がCARROTは近く、クライアントとベンダーという関係ではないので、同じ方向を向いて開発ができます。距離が近いからこそ、お互いの勝手が結構わかっている。

ーーお客様の理解度を上げるためにやっていることってありますか？

プランナー栗原

それでいうと、お客様ヒアリングにデザイナーやエンジニアも参加しています。

エンジニア原

もし不具合の話が出てきたら「ごめんなさい」と謝ろうと思って出席していました。不具合がどんな影響をあたえているかを知る機会があるのはとても良いです。「いつもお疲れ様です」「いつもありがとうございます」という温かい返事をいただけることも、前職では皆無でしたね。

デザイナー鈴木

実際に自分が作ったアプリの使い勝手や意見が聞ける場所がなかったので...それが生で聞けるのは他社ではできない体験ですよね。

ーー直接労ってもらえるなんて、優しい世界ですね。お客様との血の通ったコミュニケーションができるのは確かに自社サービスを持っているからこそですね。インタビューさせていただきありがとうございました！