Algoage Tech Blog

Algoageの開発チームによる Tech Blog です

プロダクト、技術スタック、開発の流れ。Algoageの“開発組織の今”をすべて解説します

Algoageはテクノロジーを活用して「未来の当たり前」になるようなサービスを開発・提供するスタートアップ企業です。Algoageはシステムがユーザー1人ひとりのパートナーとして寄り添い、あらゆる意思決定をサポートする未来の実現を目指しています。現在は、新規顧客をコンバージョン(CV)へと導くことに特化したチャットボット型広告サービス「DMMチャットブーストCV」に注力しています。

今回はAlgoageでプロダクト開発に取り組む、エンジニアの若菜実農(さねあつ)と石塚大策、纐纈優樹、Qurage、そしてスクラムマスターの日高尚美にインタビュー。「DMMチャットブーストCV」の概要や採用している技術、プロダクト開発の流れなどを聞きました。

「DMMチャットブーストCV」の強みとは

――まずはチャットボット型広告サービス「DMMチャットブーストCV」の概要を教えてください。

日高:「DMMチャットブーストCV」は、ユーザーをコンバージョンに導くことに特化したチャットボット型広告サービスです。このプロダクトでは、LINE上で動作するチャットボットが自動接客をして、ユーザーの購買行動を後押しします。

「DMMチャットブーストCV」の特徴は「クライアント企業の負担が少なくて済むこと」です。Algoageではクライアントと直接やりとりをしている他社で言うところのカスタマーサクセスやアカウントマネージャー的なポジションのメンバーたちが、クライアントの事業やサービスを理解したうえで、コンバージョンに導くためのシナリオやクリエイティブなどを提案しています。

クライアントは「DMMチャットブーストCV」を導入して、LPにタグを埋め込むだけで済みます。それに、完全成果報酬型になっているので、導入の初期費用が一切かからないのが特徴です。

日高尚美

石塚:「DMMチャットブーストCV」では、LINEで特定のアカウントの友だち追加をしたユーザーに、いくつかの質問をします。そして、回答結果に基づいてユーザーの属性情報をデータベース内に保存しています。その属性に基づいて、たとえば「○○に興味のあるユーザーに対してLINEでメッセージを送る」などの処理を実施するような流れです。LINE内でユーザーに情報を提供することで、クライアントが提供するプロダクトへの興味を持ってもらい、コンバージョンを促しています。

纐纈:また、クライアントのLPにJavaScriptタグを組み込むことで、ユーザー行動のログ情報を取得して、LINE登録後にその情報を紐付けることも可能です。ダイナミックリターゲティングと呼ばれるもので、Webサイトの閲覧情報やユーザーのLINE内のトーク結果などを踏まえて、ユーザーごとに違う商品をおすすめする機能が実現できます。

石塚:さらに、クライアントが提供するWeb APIと連携することでLINE内で購買が完結するとか、非エンジニアの社内ユーザーがシナリオを入稿できる仕組みを実現するなど、他社のツールでは実現できない機能をいくつも提供していますね。

技術スタックや開発の流れ

――採用している技術スタックについてもお話しください。

纐纈:バックエンドはRuby on Railsを使っており、フロントエンドはTypeScriptとVue.jsの3系です。インフラとしてはWeb APIAmazon ECS on AWS Fargate上で動かしています。リレーショナルデータベースは、Amazon Aurora MySQLです。

フロントエンドのファイルは、ビルドした結果をAmazon S3に保存して、そこからAmazon CloudFrontを経由して配布する構成になっています。画像ファイルもAmazon S3Amazon CloudFrontによる配布ですね。もともと開発組織の人数が少なくて運用に工数を割くことを避けたかったため、可能な限りマネージドサービスを使う方針を選んでいます。

石塚:データベースとしては他にもAmazon ElastiCache for RedisやAmazon DynamoDBなどを使っています。Redisは「DMMチャットブーストCV」の一斉配信機能で用いており、配信対象のユーザーをフィルタリングしたうえでRedisにいったんエンキューし、その後にデキューしてSidekiqによる送信を行っています。Amazon DynamoDBは処理を高速に行えることから、大量に出力されるログの情報などを格納しています。

纐纈:システム監視はDatadog、構成管理はTerraformを用いています。E2Eテストの自動化のために、Playwrightというツールを使っています。以前は、Algoage社内にQAテスト専任のメンバーがいなかったんですよ。そこで、システム品質を向上させるためにE2Eテストのコードを書いて、自動化できるものはなるべく自動化するようになった経緯があります。この「なるべく自動化」という方針はテスト以外の業務についても同様ですね。

纐纈優樹

――プロダクト開発はどのような流れで進めていますか?

日高:過去記事のインタビューでも触れましたが、基本的に標準的なスクラムイベントはすべてやっています。1日の流れとしては、朝10時のデイリースクラムから始まります。スクラムイベントを実施する金曜日とそれ以外の2パターンで、月曜日から木曜日は昼休憩やミーティングをのぞいてエンジニアのみなさんはモブワークをされていますね。

Algoageの開発は「業務の偏りを無くして、なるべくみんながすべての業務を担当できるようにしよう」という思想が強いです。そのため、スクラムイベントも、昔は司会をスクラムマスターの私が固定で担当していた時期もありましたが、今は担当を持ち回りにしています。

石塚:レトロスペクティブではサイクルタイムなどを確認して、うまく開発や運用を回せているか、もし課題があるならそれは何かなどの認識合わせをまず実施しています。その後に、今週に起きたことや改善したほうが良いことなどをみんなで話し合い、KPTAを用いた振り返りに移るという流れになっています。

リファインメントではプロダクトオーナーが各ステークホルダーの要望や重要度、期限などを整理したうえで、開発組織のメンバーとともにタスクを整理していきます。そこで決めた方針をプランニングで改めて確認し、優先度の高いものから実施していく体制をとっています。

メンバーの相乗効果を促すために

――全面的にモブワークを採用しているのは、Algoageの開発組織の大きな特徴ですよね。

石塚:数カ月前までは各々が別々のタスクを持って、バラバラに開発するようなスタイルだったんですよ。でもそのやり方だと、レビューの段階で初めて他の人の目に触れるケースが多くて、認識齟齬から手戻りが起きることが頻発していました。それから、仕様や設計を知らない人に説明するコストも高いなど、いくつも課題がありましたね。

纐纈:モブワークを導入すると、そういった課題が解消されました。昔は「1つのタスクに全員で取り組むと、効率が悪いんじゃないか?」と思っていましたが、むしろ真逆でした。進捗がかなり良いし、システムの品質も高くなっています。

開発チームの全員が仕様や設計の認識合わせをしながら作業を進めるので、何か齟齬があってもすぐに気付けるんですよ。それに、たとえば「ドメイン知識はあるけれど開発スキルが低めの人」と「ドメイン知識はあまり無いけれど開発スキルが高めの人」が一緒に作業することで、相乗効果も発揮できます。

Qurage:私は2023年7月からAlgoageに参画しましたが、モブワークに取り組む意義をきちんと理解しながら実践・改善しているチームはこの会社で初めて経験したので、素直にすごいと感じています。過去の職場で私はモブワークをチームに定着させてうまく機能させるように促す役割でしたが、Algoageではその必要がないくらいうまくいっていましたね。

――Qurageさんも「開発組織の改善」に意欲的なタイプなのですね。

Qurage:問題が全くない会社やチームは存在しないと思っていて「自分が主体的に動いて、それを解決するぞ」というスタンスで働いています。Algoageで働くメンバーたちは、そういったマインドが強いですよね。

Qurage

――メンバーのコミュニケーションを増やすために実践していることはありますか?

若菜:新しく参画してもらった人には、チームメンバー全員と1on1で話す機会を設けています。それから、最近始めた取り組みとして、新しい人が入ってきたら既存のメンバーがサポーターになって、チームに馴染むまでコミュニケーションを密にとって仕事を進めていますね。

そのなかで、「チームでは過去にこういうことがあって、こう改善してきました」とか「プロダクトのミッション・ビジョンや開発組織の方針はこういう意図があってこうなっています」といった説明もしています。

――開発職以外のメンバーとはどのように連携を取っていますか?

日高:定期的にステークホルダーと話す場としては、スクラムのスプリントレビューとプランニング、リファインメントの3つがあります。スプリントレビューとプランニングに関しては、開発する機能の方針や成果などを確認するために参加してもらっています。リファインメントはより中長期的な目線での計画をして、各ステークホルダーと会話をしながら要望をヒアリングし、要件を決めています。

その結果として、スクラムチームとしては健全に、プロダクトチームと他のチームメンバーたちは対等な立場で仕事を進められています。たとえばクライアントから要望が挙がっても、それを突発的な差し込みのタスクとして対応しないように、営業やカスタマーサクセスのメンバーなどが調整・配慮してくれています。開発のロードマップをどのように進めるかについては、プロダクトチームが責任と裁量を持って決めています。

デプロイ頻度とプロダクト品質をどちらも向上させる

――他にプロダクトの開発・運用を改善した事例はありますか?

石塚:プロダクトのデプロイ頻度を向上させました。「DMMチャットブーストCV」のファーストリリースは2022年5月で、その時はまだオペレーションの自動化がされておらず、そもそもデプロイの手順もきちんと整備されていなかったんです。リリースの準備が整ったタイミングで、Terraformのコマンドを叩いて手動デプロイをしていました。

纐纈:開発した機能のQAも、リリース前の1回のみでそれ以降は実施しませんでしたね。

石塚:QAが不足している状態でリリースするので、障害が発生することがありました。それから半年くらいが経って、開発体制を整えていこうという話になり、「Four Keys(ソフトウェア開発チームのパフォーマンスを示す4つの指標)」を改善することになりました。この指標に「デプロイ頻度」が登場するので、どうすればこの値を向上させられるかを、メンバーで考えていきました。

安定してデプロイをするために、デプロイ作業の自動化やQAの整備が必要という認識になりました。そこからロードマップを策定して、数カ月かけて必要な作業の洗い出しや仕組みの整備などを進めましたね。

石塚大策

日高:まずは週1回のデプロイから始めましたよね。そして、2023年2月末から週2になりました。

石塚:デプロイ頻度が週2だったときは、QAで実施するテストケースがあまりに多すぎて、テスト自動化を進めてはいたものの、手動テストの工数がかなり多かったんですよ。あまりに工数がかかるので「これだけテストが大変だと、デプロイ頻度をさらに上げるのは無理では?」となり、テスト内容の見直しをかけることにしました。

纐纈:当時は、品質を向上させようとするあまりテストケースの網羅性を上げすぎていたんですよ。そこで、品質を落とさずにテストの量を減らす方法をみんなで検討して、不要なテストケースをバッサリ省くことにしました。そうした改善を続けて、今では毎日デプロイしつつサービスの品質を高いレベルで保てています。

経験から学び、成長するスピードが著しいチーム

――今後、Algoageのプロダクトチームをさらに拡大される予定ですが、どのような人を採用したいですか?

石塚:スタートアップは社内の仕組みや体制などが整っておらず、成長過程です。その環境で、自分自身で考えて積極的に動いてくれる方だと助かります。

Qurage:人によってモチベーションを感じる部分や得意領域は違うと思うんですよ。やりたいことを突き詰めたい人や他のメンバーをフォローしたい人もいると思います。自分の関心や得意を、既知の課題やその人の視点で新たに見つけた課題と柔軟に結びつけて成果につなげ、楽しみながら仕事に取り組める人だとAlgoageにマッチすると思います。

纐纈:限られた種類の仕事だけしたい、という人にはおそらく向いていないんですよ。Algoageのエンジニアは、全部をやることが特徴です。フロントエンドやバックエンド、インフラはもちろんですし、開発体制の改善やチームビルディングなども担います。自分の領域を限定せずに、いろいろなことに挑戦できる人だと良いですね。

若菜実農

――それでは最後に、これから一緒に働く仲間に向けてメッセージをお願いします。

日高:Algoageのプロダクトチームは楽しい組織だと思います。私はあまり仕事への意識が高いほうではないですが、そんな私でも前向きに頑張れているのは、一緒に働きたいと思えるメンバーが揃っているからです。

石塚:纐纈さんの話とも関連しますが、Algoageのエンジニアはすべての領域を担当します。「幅広くなんでもやりたい」というモチベーションの人にはすごく合っていますし、満遍なくスキルを伸ばせる環境です。

纐纈:Algoageは今、サービスがどんどん成長しているフェーズです。これからさらに事業を伸ばすためにも、一緒に働いてくれるメンバーが必要で、まだまだ人が足りていません。今回のインタビューで何か気になるところがあって、興味を持ってくださった方はぜひ応募してほしいです。

Qurage:このチームはこれまで、開発組織が陥りがちなトラップを一通り踏んでいるんですよ。たとえば、スクラムがうまく回らないとか、プロダクトの品質に課題があるとか。でも、これまでの事例ですごいと思っているのは、学習速度が半端ではないことです。一般的な企業では改善までに半年や1年かかることを、1カ月や2カ月のスパンで実現しています。

自分たちの経験を通して学び、その本質を理解して、これほど改善に取り組めるチームは世の中にそれほど多くありません。このスピードで進化していけるのは、本当にすごいことです。

若菜:自立的に動ける、オーナーシップのある人が良いですね。積極的に改善を行っているチームなので、主体性のある方ですと活躍がしやすいはずです。それから、自分たちの取り組んだことによって、プロダクトチームだけではなく他のチームにも良い影響を与えることができます。そういった環境に面白さを感じる人は、ぜひ来てください。