本連載では、第一線でご活躍されているエンジニア組織のリーダーをお招きして、対談形式でこれまでのキャリア、組織のリーダーとして大切にしていること、組織課題などを語っていただきます。ナビゲーターは元DMM.comのCTOで、現在は株式会社デジタルハーツでCTOを務める城倉和孝氏です。

第5回目は、インフルエンサー(YouTube、Instagram、TikTokなど、各SNS上での発信により世の中に大きな影響を与える存在)と企業とをつなぐプラットフォーム『toridori marketing』や『toridori base』など、さまざまなインフルエンサー事業を展開している、株式会社トリドリ(toridori)のCTO 長坂翔吾氏にお話を伺いました。

株式会社トリドリ(toridori) 取締役CTO 開発部部長 長坂翔吾氏
大学時代は人工知能の研究室に所属。そのころ専攻したデータ分析の知見は今のプロダクトにも生かされている。前職ではゲームやWebサービスのアプリ開発に携わり、サーバサイド開発の経験も豊富。現在はトリドリでCTOとして開発チームを統括している。
note:https://note.com/toridori_inc/n/n70fc71c1f162

人力だったインフルエンサーマーケティングをシステム化

城倉さん(以下、「城倉」):今日はよろしくお願いします。はじめに、トリドリの事業内容やサービスについて簡単に教えていただけますか。

長坂さん(以下、「長坂」):当社はインフルエンサーマーケティング(インフルエンサーの発信を介して、企業のサービスや商品を認知させるマーケティング手法)を中心として、インフルエンサーに関わる事業を広く展開しています。中でも開発が携わっている2つの事業について説明させていただければと思います。

現在積極的に開発をおこなっている「プラットフォーム事業」は、インフルエンサーと広告主(自社の商品やサービスの広告活動をおこないたい企業)とをマッチングさせるサービスです。特に中小企業が紹介・PRのために適切なインフルエンサーを探すのは難しいので、それをうまく解決する仕組みを作るのが事業の目標となっています。

もうひとつが「SMM(ソーシャルメディアマーケティング)事業」です。こちらはアフィリエイトやアドセンスを取り扱っています。インフルエンサーごとに適した商材の提案やサポートをおこなっており、システムではアフィリエイトのクリックの計測などを実施しています。

城倉:ありがとうございます。開発がどういった関わりをしているのか気になっていたのですが概要は理解できました。

長坂:実際、今までのインフルエンサーマーケティングは人力でやっている企業が多かったですね。ただ、広告主が中小企業や個人事業主で、インフルエンサーもいわゆるフォロワーが数千~数万のマイクロインフルエンサーと呼ばれる方々をターゲットにした場合、人力では限界がありスケールができません。

城倉:なるほど。さきほどご説明いただいた、今力を入れているプラットフォーム事業が、その中小企業とマイクロインフルエンサーとをつなぐシステムになるんですかね?

長坂:はい。広告主のもとへ数百応募があって、採用されるインフルエンサーの人数も100人単位になってくるので、そこをシステマチックにさばけるようにして、それぞれがやりやすいプラットフォームを提供するというのが最大のポイントになっています。

ただ実際に応募してきたインフルエンサーが、その広告主の商品やサービスを効果的に紹介・PRできる方だったか、適していたのかといった効果測定が難しく、まだ課題は多くあります。

城倉:インフルエンサーごとにコンバージョンなどを取るのはやはり難しいですよね。利用するSNS独自の機能や制限もありますし。

長坂:そうですね。特にわたしたちがターゲットにしているインフルエンサーは、Instagramをメインに活動されているので「いいね!」やコメント数はもちろん取れるんですが、「いいね!」率が高いからといって必ずしも購入率が高いわけではありません。ユーザーの購買行動に結びついたかどうかはまた別の指標として取る必要があります。

マーケティングの効果には「認知」と「集客」があります。分かりやすく「集客」に結びついて効果が出た場合は別にして、ものによっては「認知」どまりのケースもあり、効果検証ができるよう改善を続けています。

そういった課題を解決しながら、わたしたちが目指しているのは、濃いファンがついているマイクロインフルエンサーの活動インフラになるようなプラットフォームの提供です。

チームの再編で解決した課題と新たな問題点

城倉:ここからはチームの現状や抱えている課題、そして今後の展望などをお聞かせいただければと思います。

長坂:分かりました。これについては、本当にいろいろあるんですが……(笑)

前提として、当社はもともとはアフィリエイトの事業が主軸で、規模が大きいインフルエンサーがメインのクライアントでした。そこからマイクロインフルエンサーをターゲットにした新しいサービスを開発するというので、ここ1年の利用ユーザーが急増し、新しい問題もたくさん出てきてはいます。

城倉:なるほど。アフィリエイト事業を主軸としていたころは開発チームはひとつで、そこからエンジニア組織が大きくなってきて、チームを分けるといったこともされてきたと思います。

長坂:自分がジョインしたときは全社合わせてエンジニアは5人ほどのチームでした。さすがにこの規模のサービスをやっていくには人手が足りないとなって採用を始めました。今は正社員で10人ちょっと、アルバイトの方も含めて15人ぐらいの体制です。

ちょうど1、2ヶ月ほど前はプラットフォーム事業のチームとSMM事業のチームの境もなく、どちらの業務もこなす状態だったんです。それが採用に力を入れたことで、エンジニアが専属になって、やっとひととおりのことがチーム内で完結する体制にできました。

今の課題としては、サービスを成長させつつ、短期間のうちに多数入ってきた新入社員がサービスを理解して、うまく開発フローに乗るための手順をしっかり整えることだと考えています。それをないがしろにすると、人が増えても開発をスケールさせることは難しいんですよね。

あと、本当に最近の話ですが、1チームにしては人数が多くなってきて効率が悪いという声もあります。今度はひとつの事業の中での適切なチームの分け方について考えていかなければならないと思っています。

城倉:ありがとうございます。事業単位で分けたチームをさらに最適なサイズにしていこうというのが今のフェーズということですね。

長坂:はい。特にプラットフォーム事業に関しては、日々の問い合わせも多く、ユーザー数も倍々に増えていて、開発人数を多めに割いているからこその課題です。

メンバーの「やりたい」を尊重しサポートする技術選定

城倉:つづいて採用している技術スタックについて伺ってもよろしいでしょうか。

長坂:提供しているサービスを大きく分けると、インフルエンサー向けはモバイルアプリ、企業向けにはWebサービスを提供しています。そしてそれらに繋がるバックエンドがあります。

アプリはFlutterを利用して開発しており、そこにFirebaseも用いています。フロントはメインでReact、バックエンドはメインはRailsですが、最近は分散してありまして新規システムはGoで実装しているものもあります。また、今後はNode.jsでサーバー側もやっていこうと考えています。

城倉:なるほど。幅広い技術を適材適所で使う方針を持っているんですね。

長坂:そうですね。自分としては何かひとつにこだわるより、いろんなものを試したほうがおもしろいし、勉強にもなってよいという考え方です。メンバーには試してみたい技術があればどんどん取り入れてもらって構わないと伝えています。もちろん推したからには責任を持ってもらいますが、わたしもできる限りサポートします。

城倉:あまりトップダウンで「これをやるべきだ」というスタイルではなく、話し合って合意していくみたいなスタイルなんですかね?

長坂:時間が差し迫っているとか、締め切りが短い場合ですと、慣れた技術を使おうということはあります。ただ、リニューアルしよう、新しいものを作ろうというときはまず担当者にどんな仕組みで作るのか決めてほしいと依頼をします。やりたいことが実現できるかなど調査結果をまとめてもらいます。

わたしからおすすめすることもありますが、絶対これを使ってほしいっていうのは基本的にはやらないですね。

城倉:なるほど。ではトリドリに入ってくるエンジニアは、わりと新しい技術への興味が強い方が多かったりするんでしょうか。

長坂:技術自体新しめのものを取り入れられていると思うので、そこにひかれてきましたと話すメンバーはいますね。あとは「自分はこの技術をよく使っていて、これを絶対導入して社内で広めたいんだ!」といった意欲があるメンバーは多いかなと思います。

城倉:いいですね。サービスもイノベーションというか、新しいことをやっていこうというパワーがある領域じゃないですか。中の技術も同じように、新しいものにどんどんチャレンジしていこうみたいな雰囲気なんですかね。

長坂:それはありますね。そのため採用時には、結構新しいことを勉強しないといけない環境ですよと伝えてはいます。

城倉:すばらしいですね。お話を聞いていると、興味がある技術に触れられる楽しさを感じるのと同時に、これからエンジニアとして必要なスキルを身につけられる環境でもあるのかなと思いました。

長坂:実際、今やりたいこともできるし、今後のためにエンジニアとして伸ばしたいスキルを身につけられるし、みたいな話をしてくれるメンバーも多いです。

一般的には「バックエンドエンジニアで採用したらバックエンドをやる」「フロントエンドエンジニアで採用したらフロントエンドをやる」と決まっていますよね。当社でもメインの領域はもちろんあるんですけれども「フロントエンドメインだけどバックエンドも知っておきたいならやってみていいよ」という感じで、特に制限は設けずにやりたいならチャレンジしていこうというスタンスです。

今後もっとユーザー数が増えると大量のデータを扱うことも出てきて、アルゴリズムやビッグデータの分野にも携わる機会が出てくると思います。サービスのスケールによって、そういった機会がある点も魅力に感じてくれているんじゃないでしょうか。

城倉:なるほど。自分の希望した技術が使えて、新しい技術にも触れられる機会が多くて、エンジニアにとっては魅力的ですが、長期的に見たときの懸念点みたいなものはあったりしますか?

長坂:もちろんあるとは思っています。ただ、どちらかといえば負債になっても丸ごと見捨てるわけではなく、それを引き継いで作り直すところもチャレンジだと捉えています。もし負債が対処できない状況にまでなったら新しいものに変えていけばいいですし。そういったことを定期的にできる体制を目指しています。

城倉:代謝を上げるというイメージですかね。

長坂:そうですね。開発サイクルを早く回せる体制を整えていきたいです。

Flutterを早くに採用、開発における魅力とは

城倉:モバイルアプリ開発ではFlutterを採用しているんですよね。導入時期も比較的早いほうではないですか?

長坂:最近は導入されている企業さんも多いとは思いますが、たしかにFlutterを利用して開発したアプリのリリースが1年半前くらいだったのでわりと早かったと思います。

城倉:ちなみに長坂さんが思う、Flutterの魅力ってどういったところなんでしょうか。どうやって導入の意思決定をされたのか気になります。

長坂:バックエンドを担当していた自分と当時のアプリ開発の担当者とが「Flutter、いいよね」と意気投合しまして、だったらやってみようと導入を決めました。

実はそれ以前に知り合いの会社がFlutterを導入して、少人数のチームにも関わらず早いサイクルでいろんなサービスをリリースしていたんです。Flutterでの開発の先駆けでもあったので、その人に現場に即した話を聞けそうだなとも考えていました。

もちろんフレームワークとしての魅力もあります。まずはなんといってもiOSとAndroidでそれぞれ開発するコストを減らせる点です。また、当時新規SDKに対して新しいパッケージもどんどん出てきていて、開発がやりやすい状況になってきている感覚がありました。特に我々のようなアプリ開発をする企業は、OSネイティブではなくてFlutterやReactのようなフレームワークの採用が今後さらに増えていくだろうと思って選択しましたね。

今はFlutter開発の人員も少しずつ集まっていて、Flutterで開発できる体制が整っています。

城倉:逆にFlutterのここは大変だなと感じている部分はありますか?

長坂:そうですね……現時点でサービスへの影響はそこまでないんですが、まだ活発に開発されているフレームワークなので、大きなバージョンアップが定期的に来るというのはやはり大変ですね。

ちょうど先週、1系から2系への切り替えがありまして、なんだかんだ1カ月ちょっとは取られてしまいました。そこは新しいフレームワークを導入するデメリットと言えるかもしれません。

あとは最新のOSの機能を取り込むハードルが高いという点もあります。たとえば、iOSもしくはAndroidの新しいバージョンがリリースされて、何か新機能が実装されていてもFlutterはマルチプラットフォームなので両方に適用する仕組みができるまではそれが使えません。もし特定のOSだけの機能を使いたいとなると、ネイティブプラグインを書かなければならない状況も今後出てくるかもしれないなとは思っています。

城倉:Flutterってまだそんなに情報が多くないですし、そういったことを発信すると喜ぶ方も多いかもしれませんね。

長坂:面接で応募者に聞いてみても、たしかにFlutterで開発してるっていうのは珍しさだったり目新しさがあるみたいです。そこは採用にもつながるので、やっていきたいですね。

はじめてのスクラム導入、運用しながら改善を続けていく

城倉:ここまでのお話だと、新しい技術を使いながらサービスも組織も順調に拡大してきているといった印象を受けるのですが、そのあたりの手応えとまだ解決できていない課題などがありましたらお聞かせいただけますか。

長坂:これまでは必要に迫られてやらざるを得ない状況だったのが、今は「どれをやるとよいか」という選択ができる段階になりました。

その上で今度はいかに事業的に一番効果が高いものはどれなのかを考慮して実装を進めていくか、仕様決定からリリースまでの流れをどのように改善して効率化していくかといったところが課題ですね。そこに対しては、スクラム開発を導入したことによって、タスクの優先度やステータスを可視化できるようになり先の見通しが立てやすくなったことで効果を感じています。

一方でスクラムに関しては、自分自身はじめての導入で、実際やってみてうまくいかない部分もあります。たとえば、コストの算出方法やチケットの整理、あとは利用しているシステムとの連携にも問題があります。チケット管理のために導入したツールの機能とわたしたちのプロセスとが合致していなくて余計な工数を取られてしまうなど、日々発生する問題や悩みは引き続き解決していく必要がありそうです。

編集部:この点についてはぜひ城倉さんにご意見を伺いたいですね。

城倉:スクラム開発って経験学習なんです。なので問題というより課題というか、聞いていて非常にいい形で実践されていると感じたので、継続していくことで解決できると思います。メンバー間のコミュニケーションで工夫されている点などはありますか?

長坂:そうですね。確かにそこも課題のひとつだと思っています。というのも現在は完全にリモートワークを実施しているので、どうしてもコミュニケーション機会は減ってしまっています。

開発チーム内は基本的にDiscordというツールを常時つないでおいて、いつでも聞いたり答えたりが可能な状態にはしていますが、それでもオフィス勤務よりは話しかけるハードルは高いと思います。

そのため、少し他の会社さんとは逆行するかもしれませんが、状況がもう少しよくなったらリモートワークはいったん解除して、オフィス体制に戻すことも考えています。

というのも、この1、2年が事業としてものすごく重要な局面だと思っていて、エンジニア間だけでなく、他事業部のメンバーとのコミュニケーションも大切にしていきたいんです。やはりオペレーションや問い合わせの担当、あとは営業のメンバーとはオンラインだけでは円滑なやり取りが難しいですよね。

雑談も減ってしまって、今そのあたりの具体的な対策は取れていないので、リモートを続けるのであれば改善はしていきたいと思っています。

城倉:リモートでうまくできる部分と対面でないと難しい部分とがあるというのは共感しますし、個人的にはよい意思決定だと思います。

ウォーターフォールのようなドキュメントを引き継ぐ開発と違って、スクラムはコミュニケーションがすべてみたいなところがありますから。またオフィスに集まろうということに対して、メンバーの反応はいかがですか?

長坂:理解を示してくれるメンバーは多いのですが、通勤への抵抗もありますね。

城倉:実際バランスが難しいですよね。入社してからまだ一度も出社されていない方もいらっしゃるんですか。

長坂:それはさすがにいないですね。入社したメンバーからいろいろ質問をするのはハードルが高いと思っているので、入社時だけはオンボーディングとして新入社員とメンター的な役割をする先輩とが隣り合ってすぐに聞ける体制でやってもらっています。

メンバーの成長のためにCTOとして貪欲に学び続ける

城倉:ここまでのお話で、技術に対するフォローアップ力やアンテナを張ってよいものを取り入れていこうという気概を非常に感じられたんですが、やはりCTOとしてそういった点を大事にされてらっしゃるんですか。

長坂:そうですね。もちろん企業によってCTOの役割はさまざまかと思うんですが、今のチームに対するわたしの役割は、技術導入の意思決定をきちんとおこなうこと、そしてメンバーが困っていたら技術的なサポートすることが大きいと思います。

メンバーが「やりたい!」と言って導入した技術であっても、勉強してひと通りの知識をそろえておきます。技術的に問題があるもしくは実装で詰まっているときには、調査の方針や解決の糸口を提案できる状態にはしています。

城倉:最初の方向性を決める意思決定もそうですけど、決まった後のサポートというか、それに対して適切な情報を与えるところも大切にされているんですね。

長坂:メンバーが技術的に成長するためのアドバイスをするというのは大事にしているところです。

城倉:素晴らしいですね。メンバーがやりたいと言って、いいよと言ったからには自分もそれを受けてまず勉強するわけですね。簡単ではないと思います。それでも、質問されたらきちんと答えて支えてあげられる準備をするということですね。

長坂:さすがにすべての面で誰よりもできるところまではいけないんですけれども、わたし自身、業務で言語は5つほど経験がありますし、フレームワークも含めるともっとやっています。フレームワークが変わっても同じような仕組みや全体的にこうなってるだろうという想像はある程度できるので、そのあたりの知識を生かして問題点のあたりをつけて、アドバイスをしているという感じてす。

城倉:スタイルとしては、基本的には現場の意思を尊重して現場に任せるんだけれども、現場が困ったときは解決できるだけのスキルを身につけておいて、そこに関して意思決定してあげられるということですよね。

長坂:はい。そういうところを目指しています。

城倉:素敵ですね。ここまでお話をいろいろと聞かせていただきましたが、非常に理想的なCTOだと感じました。ありがとうございました。

株式会社トリドリ(toridori)の求人情報


Share