「社外に頼んでいる感覚なく着実にプロジェクトが前に進む」株式会社ディー・エヌ・エー Pococha事業部様 - UZUMAKIクライアントインタビューvol.5
UZUMAKIのクライアントである株式会社ディー・エヌ・エー 様は、LIVEコミュニケーションアプリ「Pococha(ポコチャ)」を運営されています。今回UZUMAKIは、バックエンド開発におけるリファクタリングのお仕事で技術基盤チームをお手伝いさせていただいております。
急成長するサービスにおいて、新規開発と技術的な負債の解消をどのようにバランス良く仕事を回していっているかということについてお話をきかせていただきました。
画面左下から昇順に、UZUMAKI 今さん、橋本さん、山田さん
今回UZUMAKIで関わらせて頂いている「Pococha」のサービス概要について、簡単に教えていただけますか？
北澤さん（Pococha事業部 システム部 副部長※以下敬称略）：「Pococha」はスマホで誰でも気軽にライブ配信と視聴ができるライブコミュニケーションサービスです。配信者(以下 ライバー)はトークで、視聴者(以下 リスナー)はコメントでコミュニケーションをすることによって、自分の個性を表現したり、それに対して応援したりして、一人ひとりの「幸せなつながり」を繋いでいます。
Pocochaのライブ配信の特徴は、ライバーをリスナーが見るというという一方的なものではなく、我々は、ライバーとそこに集まるリスナーが、双方向でコミュニケーションをして楽しめるということに価値があると考えています。誰でも気軽にスマホで配信ができて、リスナーも手頃な人数が集まって楽しめる空間を作っています。
※詳細はこちらをご参照ください
Pocochaのサービスを展開することで解決したいユーザーの課題を教えてください。
北澤：一見すると、ユーザーは配信を見にいっているように思えるのですが、実は、見るというより話をしにいっているんです。
例えるなら、馴染みのBARがあって、毎週末同じ時間に通ってて遅れたら、「なにかあったの？」って聞かれるじゃないですか。それと同じ感覚で、Pocochaでライバーは、定期的に同じ時間に配信をしている際に、たまにリスナーが遅れて参加すると、ライバーから「今日は遅かったね。どうしたの？」とかって聞かれるんですよ。
つまり、双方向なところに価値があり輪の中に入っていくことができて、また、輪の中に入っていきやすい工夫が沢山盛り込まれているんです。
特にコロナ禍以降で、人とのつながりを求める人のニーズを満たしていくサービスになっていると思います。
また、配信者であるライバーからの側面ですと、YouTuberを筆頭に社会的に一定の職業として認められてきていますが、ちゃんと稼ぐということの難しさにユーザーの課題があると思っています。誰でもライバーとしての活動を開始したからといって、すぐにお金になるわけではなく、きちんと収益化していくには何ヶ月も時間を使っていく必要があるんです。
その点において、Pocochaではライバーが最初のフェーズから報酬を得やすい仕組みがあるといえます。
本業としてたくさん稼いでいきたい方もいれば、週に数時間スキマ時間にやってみたいという方もいらっしゃいます。Pocochaだと自分のペースで活動できて、すぐに報酬が得られるところが強みかなと。
今回、UZUMAKIに声をかけていただいた背景は？（背景にどんな開発課題がありましたか？）
北澤：よくある話だと思うんですが、サービスを開発した当初Ruby on Rails(以下Rails)を使ってシンプルなアプリケーションから始めたんですが、サービスが大きくなっていくにつれて、リファクタリングの必要性が出てきたんです。
これまでは、開発をしているメンバーで、仕事時間のうちある程度の割合をメンテナンスする作業に割り当てていたのですが、サービスの成長速度を止めずに進めていくには、片手間でリファクタリングしていては間に合わなくて、専属で技術的負債を解消してくれるチームが必要になったというのがきっかけでした。
しかも、今回のリファクタリングは、Railsのアップグレードなので、システムの中で奥の深いところの修正をしないといけなくて、これまでそういう経験をしてきた方じゃないと任せるのが難しく、誰に頼んでいいんだろうということを悩んでおりました。
志水さん（Pococha事業部 システム部 ※以下敬称略）：そんなときに、弊社がスポンサーをしていた銀座Rails のイベントで、UZUMAKIさんもスポンサーをされていることを弊社のメンバーが見つけて御社を知ったというのが経緯だったかと思います。
北澤：そうでしたね。たしか、CTOの今さんが登壇されていましたし、この件をきっかけとして御社のHPからRailsのリファクタリングの実績を拝見してお声掛けさせていただきました。
今（UZUMAKI CTO）：登壇したことでこういう繋がりができるとは思っていなかったので、ありがたいです。もっと登壇しようと思いました。笑
納品のない受託開発についてどう思われましたか？
橋本（UZUMAKI エンジニア）：今回、一括発注ではなく”納品のない受託開発スタイル”で開発をさせていただいていますが、このスタイルだからこそうまく行った、解決できたと思うところはありますか？
北澤：ソフトウェアって生き物みたいなものなので、そんなに先のことを見通してお願いできるようなものではないと思っているんですよ。つまり、作ってみないとわからないこともあるし、細かく作ってプロダクションに反映させてみて、その反応をみて軌道修正していくものだと思っています。
特に、Pocochaは規模の大きなサービスなので、たくさんの人が同時に開発を進めていっているんです。そういう意味で、一括発注というのはなかなか難しい側面がありました。
なので、納品のない受託開発のスタイルは我々に合っていましたし、UZUMAKIの皆さんは、柔軟にプロジェクトを進めていただいた印象があります。
今：そうですね。納品しました！といって、作業したGitHubのブランチをPull Request(以下PR)で持ってこられたとしてもコンフリクトがたくさん発生するだろうから、もらっても困っちゃいますよね 。笑
橋本：僕らがGitHubのPRとして工夫していたのは、PRレビューしていただく間のタイムラグをどのように埋めていくかでした。コンフリクト防止の観点で、レビューしてもらえないと作業が進まない待ち状態になるのではなく、次の作業をPR待ちブランチから派生させて、手が止まらないようにしたりしていました。
山田（UZUMAKI エンジニア）：PRの工夫という意味だと、PRのMainブランチへのマージタイミングについて、個別PRの性質次第で早めにマージするように提案したりしていました。本番環境への影響があまりなく、かつ、後からマージするとコストが掛かるものがあると知っていたので、なるべく手間がかからないことを意識していました。
リモートで開発を進めさせて頂きましたが、どう感じられましたか？
北澤：我々も完全にリモートワークで仕事をしているのでそれ自体に特に違和感はありませんでした。気にしていたのは、コミュニケーションの頻度と濃度で、これについては会社の文化によって相性の合う合わないがあると思っていました。
UZUMAKIさんとは、お仕事をした最初のころから開発をする上で必要な「共通言語」が多かった印象です。定例のミーティングは週1回で行っていましたが、伝えたいことがきちっと伝わっていたり、判断に悩ましいところは事前に気にしていてくれたりしたのがありがたかったです。
我々も普段リモートワークで仕事をしていて、UZUMAKIメンバーの方もリモートワークをしているので、社外の方に仕事を依頼している感覚はなかったと思います。 笑
志水：テキストコミュニケーションという点では、Slackでうまくコミュニケーションがとれたのが良かったです。意外に思われるかもしれませんが、Slackでも会社の文化が違うと、メールのように〇〇様から始まって、何卒よろしくお願いします。ということもあると聞いたことがあるので、気軽に話せたのが良かったです。
UZUMAKIとプロジェクトを進めて頂いて、期待されていた部分は達成されましたか？
栗山さん（Pococha事業部 システム部 ※以下敬称略）：今回、リファクタリング周りで依頼したことはたくさんあるのですが、その中でもRailsアップグレードの作業が一番大きかったといえます。
この課題について、予め問題が起きそうなところを潰していただきましたし、PRを工夫することでコードの差分が大きくならず品質の高いアウトプットを出していただけました。現にQAを通しても、大きなバグが見つかることなく、無事Railsアップグレードを完了することができました。
プロジェクトの進め方としても社員同士でやっているときと、まったく変わらない空気感で進められたのが印象的でした。特に、週1の定例で、毎回毎回課題の優先順位をつけることや、ネクストアクションを決めていき、毎週成果を共有してもらうというサイクルがうまく回っていたと思います。
志水：スピード感としても、期待していた以上の速度でRailsアップグレードが完了したのでとても満足しております。
北澤：あとは、依頼のしやすさというのが今回あったと思います。
仮に、我々の課題を他の外部のパートナー企業に依頼することを想定すると、調査をする作業がまず必要で、そこに対しての影響範囲を確認するんです。その中から複数の対応策を考えて、その対応策での開発をエンジニアに依頼するんです。
つまり、開発をお願いするにしても、その前後での作業がかなりかかるので開発だけをお任せしても旨味が少なかったりします。
その点UZUMAKIさんは課題レベルからまるっとお願いすることができたのでとても助かりました。
今：ありがとうございます。我々で工夫していたのは、課題があったときに、複数の解決策を提案して、判断しやすいようにメリット・デメリットを予め伝えるようにしていたことです。解決策の判断をする上で、検討してもらいやすいように心がけていたので、そう言っていただいてとても嬉しいです。
北澤：是非今後ともよろしくおねがいします！
本日はお忙しい中ありがとうございました！
お知らせ
XではUZUMAKIの新しい働き方や日常の様子を紹介！ぜひフォローをお願いします！
https://twitter.com/uzumaki_inc
TechBlogではUZUMAKIの技術情報を紹介！
UZUMAKIではRailsエンジニアを絶賛募集中です。
ご興味を持っていただいた方は、ぜひ応募よろしくお願いします！
いいなと思ったら応援しよう！
