Algoage Tech Blog

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

社内ISUCONを開催した話。実践を通じてパフォーマンス改善の知見を学ぶ利点とは

ISUCON(イスコン)とは「Iikanjini Speed Up Contest(いい感じにスピードアップコンテスト)」を略したイベント名です。 ISUCONでは「お題となるWebサービスを、決められたレギュレーションのなかで限界まで高速化するチューニングバトル」が繰り広げられます。パフォーマンス改善の結果はスコアとして表示されるため、参加者たちは自分たちの取り組みの良し悪しを定量的に把握できることが特徴です。

株式会社Algoageの開発チームでは、スキル向上を目的として社内でISUCONを実施しました。今回はISUCON開催の経緯やそこから得た学びについて、エンジニアの若菜実農(さねあつ)と石塚大策、纐纈優樹、Qurage、そしてスクラムマスターの日高尚美にインタビューしました。

原因調査や障害対応のスキルを体系的に習得する

――社内ISUCONを開催した経緯について教えてください。

石塚:Algoageの開発チームでは、アプリケーションのデプロイを毎日行っています。そして、フルタイムで働くメンバーは運用を持ち回りで担当しています。デプロイ中やその後に意図せず障害やシステムの高負荷が発生した場合などに、原因を特定して対処するスキルが必要だという共通認識をメンバー全員が持っていました。

とはいえ、こうしたスキルを習得する機会はそれほど多くありません。「全員がレベルアップするにはどうしたらいいだろうか?」という話をスクラムイベントでしていたところ、「ISUCONを実施するといいんじゃないか?」というアイデアが出てきました。

問題を一から用意するとかなり大変なので、2022年8月27日に本選が開催されたISUCON12の問題をそのまま流用することに決めました。

<ISUCON12の概要>

ISUCON参加者たちは、育成型放置ゲームの運営企業の社員という設定。このゲームが3周年を迎え、より多くのユーザーを集めるためにテレビCMを放送する。膨大なトラフィックがゲームのサーバーに集中することが予想されるため、サーバーのパフォーマンスチューニングを行って負荷対策をするというストーリーになっている。

若菜:社内ISUCONは2023年8月21日(月)から25日(金)までの5日間にわたり実施しました。予選を月曜日から火曜日にかけて実施し、本選に水曜日から金曜日まで取り組むという流れです。開発組織のメンバーを2つのチームに分けて、それぞれのチームにインフラとバックエンド、フロントエンドに詳しいメンバーが均等に配分されるようにしました。

――ISUCONを実施する期間に、プロダクト開発を一時的にストップすることになります。ビジネスサイドからの理解は得られましたか?

日高:私たちの場合は、すごく好意的に受け入れてもらえました。みんなのスキルが向上して障害対応などがよりスムーズになるならば、投資する価値があると思ってもらえたためです。加えて、プロダクトの開発や運用に影響を出さないための配慮として、お盆明けのなるべく余裕のあるタイミングを選びました。

若菜:ISUCONをその時期に実施するという周知は、イベントの2カ月前くらいからしていましたよね。

日高:それから、機能開発は1週間止めるけれど万が一システムの障害が起きた場合には即座に対応するとか、プロダクトに関する問い合わせなどはすぐに対応するようにして、事業に影響がないように進めました。

左から順に日高尚美、若菜実農、石塚大策

パフォーマンス改善の結果が点数としてわかるため、効率的な学習につながる

――ISUCONを通じてどのようなことを学びましたか?

石塚:普段、AWSのマネージドサービスなどを利用してインフラを構築していると、Webサーバーやデータベース、ロードバランサーなどの細かな設定を行うことはほとんどありません。ですが、こういった機会にそれらの設定を行うことで、学習の機会が生まれるのはとても良いと感じました。

纐纈:NginxやMySQLの設定などって、過去のISUCONに参加していた方々などがWeb上にノウハウをアップしてくれているんですよ。たとえば、こういうチューニングが効くとか、こういうパラメーターを調整すると良いといった知見を書いてくださっています。

今回の私たちがそうだったんですが、そういった過去のISUCONの問題を解いた方々の“秘伝のタレ”を調べて適用しながら、パフォーマンス改善の知識を実践的に習得できます。手を動かしながら学べるので、かなり効率が良いと思いました。

Qurage:ISUCONの良い点として、スコアが表示されることが挙げられます。普段の開発や運用のなかでは、自分たちの実施したことによって何かが改善した・していないという結果を定量的に測ることは難しいです。ですが、ISUCONならばゲーミフィケーションを通して、自分たちのやったことがシステムにどう影響を与えたのかがすぐわかります。

今回の社内ISUCONでは、エンジニアにとっての基礎知識である「開発環境の整備」「ログを読んで内容を分析すること」「計測をし、ボトルネックを特定して改善していくこと」などの重要性を再認識しました。ISUCONを通じて、そうした要素を学べるのは素晴らしいと思いましたね。これまで自分にとってISUCONは遠い存在だったんですけれど、この経験をしたことで「ISUCONめちゃくちゃ良いじゃん。また開催したい」と思いました。

纐纈:作業効率化が大事だという学びがありました。ISUCONではひたすらにベンチマークを出して、課題を特定して、改善を回してという作業を繰り返すので、頻繁に使うコマンドなどをすぐ出せるようにしておかないと、極端に効率が悪くなってしまいます。

業務のシステム運用のなかでも、作業の効率性をないがしろにしていると、相当な時間をロスしてしまうんだと肌で感じられたのが良かったです。それから、日々の業務のなかではスコアを競い合うような機会はないので、ISUCONに取り組みながらチーム同士で対決したことで、モチベーションが上がりました。

他には、計測の大切さが身に染みました。ISUCONで用意されているシステムには、パフォーマンスのボトルネックになる点が大量に存在しています。ですが、やみくもにパフォーマンス改善のための施策に取り組んでも、全くスコアが上がらないんですよ。計測をして、真のボトルネックを特定していかなければ何も効果が出ません。それを、スコアとして可視化してくれるのが良かったなと思います。

次回に向けての改善案

――社内ISUCONを次回も開催するならば、改善したい点はありますか?

纐纈:今回、私たちはISUCONのために5営業日も確保できたので、予選の段階で「ISUCONはこういうもので、こういう要素が大事なのか」ということを学ぶための時間がありました。でも、それほど期間を確保できない場合は、事前に各々がISUCONの概要や実施すべきことの基礎知識をインプットしておくべきだと思います。そうしなければ、環境構築や調査などに時間を奪われてしまい、学びが少ないままイベントが終わりそうです。

Qurage:もし次回開催するときにまるまる1週間を確保できないならば、たとえば1日目はチュートリアルのための時間にして2日目以降に課題を解くような感じにしますかね。みんなの認識を合わせたうえで課題に取り組むと、比較的スムーズに進むと思います。

日高:私はエンジニアではない立場としてISUCONのチームに参加していたんですが、エンジニアのみんなはすごいことをやっているんだという尊敬や感謝の念が湧いてきました。そして、開発や運用の流れなども理解できたので、もし余裕があれば開発チーム以外の人たちもISUCONを観戦できるようにしておくと、システムやエンジニアのことを学べてすてきだなと思いました。

Qurage:エンジニアたちが何をすべきか途方に暮れているときに、日高さんが気軽に「やっちゃえやっちゃえ」と声をかけてくれて助かりました。こういう応援のコメントがあることで、気が楽になるんですよ。

若菜:それから、エンジニアがISUCONに注力できるように、期間中開発チームに来た問い合わせを日高さんがさばいてくれたのも助かりましたね。私たちは他のことにマインドシェアを取られずにISUCONに集中できました。

纐纈:次回も開催するならば課題を解いた後の振り返りも入念に実施したいですね。学びを最大化するために、ISUCON終了後にみんなで解説や講評を見て、改善案を出す場を設けたいです。

若菜:たしかに過去に開催されたISUCONでは、運営チームが解説や講評を用意してくれているので、それに倣って振り返りをしたいですね。

石塚:他にも、環境構築などの作業をできるだけスムーズに終えられるような仕組みを用意しておきたいです。そうすれば、仮に次は1週間のイベント期間を確保できなくても、本質的な改善作業に時間を使えると思います。

左から順にQurage、纐纈優樹

ISUCONに取り組むことで得られた成果

――開発組織が通常のプロダクト開発だけではなく、社内ISUCONに取り組むことでどのようなプラスの効果があると思いますか?

纐纈:システムの課題をなるべく素早く特定して改善するという経験を積めることが大きいです。以前、APIサーバーのソケット数が上限に達しており、リクエストをさばけないという障害が本番環境で起きたことがあります。当時の私はそもそもそういった事象が発生し得ることすら理解していなかったので、何が起きたかわからず困っていたんです。

でも、ISUCONに取り組んだことでミドルウェアの設定やアプリケーションの実装方法などについて幅広い知識が身につきます。頭のなかに索引ができるというか。何かシステムのトラブルがあったときに、どのような原因なのか当たりをつけやすくなると思っています。

それから、プロダクト開発の業務以外にこういった社内ISUCONのようなイベントがあることで、仕事にメリハリが出ると感じています。お祭り的なイベントがあるほうが、前向きな気持ちになれますね。

石塚:ISUCONで改善の対象となるシステムは、良くないコードの書き方が意図的にされています。無駄なSQLを発行していたり、意味のないループをしていたり。そういったコードを見たからこそ、普段の業務でコードを書くときにも「マズい書き方になっていないかな」と意識するようになりました。また、結果がスコアとして表示されるので、実際にそのISUCONに出たチームと値を比較することで自分たちの相対的なスキルがわかるのも面白いです。

Qurage:エンジニアのなかには、ISUCONで取り扱っている技術になかなか触れる機会がない人もいると思います。私自身も、普段はフロントエンドの開発がメインなので、インフラの設定をいじるのは何年ぶりだろうという感じでした。そういう人にとって、ISUCONは技術的な関心領域を広げる良い機会になると思います。パフォーマンス改善の結果がスコアリングされることで、楽しみながら各種の技術に触れられるからです。

若菜:ISUCONに参加する前は、自分がどれだけチームの力になれるのか不安でした。でも、ISUCON関連の書籍や過去の問題などを読んでいると、できることはたくさんあると感じました。マニアックな知識を習得したスペシャリストでなければISUCONに挑めないかというと、全くそんなことはありません。肩の力を抜いて気軽に参加できるイベントでした。

それから、模範解答などを見て復習すれば、自分自身の技術的な幅を広げることができます。業務において何かの調査やシステムの改善などを行う際、基本的には自分の持っている知識の引き出しのなかから案を出すことになります。その選択肢を増やす意味でも、ISUCONは有益だと思います。

日高:開発チームのみんなが、前向きな気持ちでISUCONに取り組んでくれたことが何よりの成果でした。それに、これから採用面接を受けてくれる方々に「Algoageは、エンジニアが楽しみながらスキルを向上させるための取り組みをしています」と胸を張って伝えられるのも、プラスになると思っています。

【連載】データ分析基盤をdbt・Snowflakeに移行する【設計・実装編】

こんにちは、Ops-dataチームの上村(@contradiction29) です。以前、弊社内で運用されているデータ分析基盤を移行するにあたり、設計の方針を練る記事を投稿しました。

tech.algoage.dmm.com

今回はその続きとして、移行プロジェクトの実際の進行に焦点を当てて記事を書いていきたいと思います。

はじめに

これまでのあらすじ:運用していく中でつらみがたまってきた弊社のデータ分析基盤。開発しづらいし、運用もつらいし、何よりこのまま運用を続ければ確実に停止してしてしまう。End of Service Life (EOSL) は目前に迫っています。移行するしかない状況です。

とはいっても、単純に移行するだけでは、現場のアナリストやエンジニア、社内ユーザー、そしてその先にあるクライアントのニーズに応え、事業価値に貢献することはできません。真の「価値」に貢献するためには「思想」が必要です。そういうわけで、まずは基本的な設計思想をゼロベースで考え直すところから始めました(くわしくは前回の記事参照)。再掲します。

原則1:データ分析基盤は、 変化するニーズに応え、迅速に価値を提供できるように設計する

原則2:データ分析基盤の運用にかかる労力が最小限となり、データ利用者への価値提供に集中できるように設計する

原則3:データ分析基盤の利用者への「分析者体験」の最大化を第一の判断基準として設計する

原則はできたので、次は実装…と行きたいところですが、仕事をしている以上、プロジェクトが完了する確率を可能な限り引き上げる必要があり、そのためにはリスクに対して正面から取り組む必要があります。リスクを扱う上では、「とるべきリスク」と「とってはいけないリスク」を分別し、後者については事前に排除するのが得策です。そのうえで実装に入るほうが最終的な完成度は高まるし、期限を短縮することが可能となります。

この記事では、移行プロジェクト開始前にリスク排除を目的として実行したことや考えたことについて振り返ったのち、実際に「曳光弾開発」(詳細は後述します)を用いて設計・実装したプロセスについて記述していきます。最小構成の構築が完了した後の肉付けを経て、実際に稼働できる状態まで持っていく過程についてまでを今回の記事のスコープとします。 先に全体像を示しておくと、以下のような構成になりました。詳細は後述しますが、以下の3点がポイントです。

  • ELTの構成になっている
  • ほぼフルマネージドなサービスを使い、運用にかかる労力なるべく減らしている
  • 開発者体験を重視したツールを利用し、開発をやりやすくしている

データ基盤の全体像

それでは中身に入りましょう。

プロジェクトの障害を事前に排除する

一口に「プロジェクト進行上のリスク」といっても、分類法や観点など、色々な見方があると思います。PMBOKに書いていそうなことを引用するのもアリですが、ここでは自分と弊社のEMさんとの会話をもとに、リスクをどのように分類し、対処していったかについて振り返っていこうと思います。

タイミングリスク

データ分析基盤の移行を実施する際、タイミングを考慮することは重要です。一般論ですが、すでに稼働しているシステムに対して、数か月かけて大規模な変更を加えることは躊躇される傾向があります。タイミングを間違えることは、メンバーやステークホルダーの離反の一因たりえるものです。

逆に言うと、タイミングをうまく合わせられれば自然とリスクは排除されることになります。自分がデータ分析基盤の移行を行う際に一番気を付けたのはこの「タイミング」でした。端的にいうと、移行を行うには絶好のタイミングではありました。理由は2つです。

  1. 5~6月にかけてデータ分析基盤の事故が多発したため、ステークホルダー間で事故の記憶が新しかった

    • 詳細は前回の記事を参照してほしいのですが、根本的な原因は既存システム運用のつらさによるものであり、技術スタックの入れ替えが解決策であることは明確でした
    • そのため、基盤をドラスティックに変更することの重要性を説明しやすいタイミングだったといえます
  2. Athenaのパーティション制限の問題により、このまま稼働を続けれEnd of Service Lifeを迎えることは明白だった

タイミングのリスクはすでに排除されていると考えてよさそうです。頭を切り替えて、ほかの種類のリスクに関して考えてみます。

時間切れリスク

Athenaのパーティション制限がある以上、時間切れは明確に存在しています。設計・実装に時間をかけすぎれば、移行しきらないうちにデータ分析基盤が停止し、現場でデータを必要とするユーザーにデータを届けることが不可能になります。

そうなると、時間のかかる開発手法は使えません。ではどうする?「曳光弾開発」を使えば早くできそうです。

脇道:曳光弾開発とは何?

話が脇にそれますが、「曳光弾開発」の中身について話しておこうと思います。

ざっくりいうと、曳光弾開発とは、end-to-endで動く最小構成をまずつくり、機能を拡充しながら段階的にニーズを満たしていく開発手法のことです。「曳光弾」は光を放ちながら飛ぶため、開発の過程や方向性を明確に示し、それを追いながら機能や性能を拡充していくというイメージからこの名前が付きました。(出典:『達人プログラマー』)

データ分析基盤の文脈でいうと、まず一つのダッシュボードを選び、そのダッシュボードを作るために必要なテーブルを作り、そのテーブルを作るために必要なデータソースの取り込み処理を実装し…のように、最小構成のend-to-endのパイプラインを作ります。まず一本、横に長い線を引くイメージです。次に、その横の線を増やしていき、最終的にすべての線を実装する、という方法です。

データ分析基盤の構築において、最も難易度が高いのは「一番最初のend-to-endのラインの構築」です。逆にいうと、end-to-endのラインを拡充するのは相対的に難易度が低いといえます。曳光弾開発の手法を使えば、リスク(難易度)の一番高い部分から順に解決していくことになるため、リスク低減の観点から最適な手法であると考えました。

技術的リスク

リスクの話に戻ります。今回の移行では、大規模な技術の入れ替えを行うことを想定していました。加えて、筆者(移行時点では新卒2年目)はデータエンジニアとしての経験はあまり豊富ではありません。経験の浅いエンジニアがドラスティックな技術の入れ替えを行う場合、技術的なリスクがないと考えるほうが難しいでしょう。具体的には以下のようなものです。

  • 選択した技術では、非機能要件や機能要件を満たせない
  • 技術選択を誤れば構築に時間がかかり、時間切れになる可能性がある

確実に要件を満たせることを保証しつつ、高速に実装できる方式を選ぶ必要があります。曳光弾開発がまさにそれです。

人手不足リスク

移行に伴い多くの作業が発生するため、人手が足りなくなることが想定されます。今回のケースでは期限の超過がデータ分析基盤システムそのものの停止を意味するため、人員不足による遅れは極力避ける必要があります。

対応としては、以下のような方針とすることとしました。

  • 極力手戻りを抑え、かかる人手を最小限に抑える
    • やっぱり曳光弾開発
  • 人手が不要なところは自分一人でやる*1一方で、人手が必要になったタイミングでチームメンバーの助けを借りる
    • チーム内へのスキル普及も同時にできるため、一石二鳥です
    • 事前に頭出しや説得を念入りに行う必要があります

他にも、自分が通常の業務をさばけない間は、ほかのメンバーにフォローしてもらう体制を組んでいただいたりしました。非常に感謝しています。

資金リスク

データウェアハウスやSaaSの費用がかさみ、想定を超えてしまうリスクです。コスト超過それ自体リスクではありますが、ステークホルダーからの信頼を失うリスクもあるので、極力注意したほうがよいでしょう。金と政治が密接な関係にあるのは歴史が示す通りです。

対応策はシンプルです。

  1. 最近のデータエンジニアリング系の製品には無料期間があるものが多いため、無料期間中にしっかり見積もりを立てるようにしました
    • 例えばFivetranはコネクターごとに14日分の無料期間があります。その間にMAR(Monthly Active Record: Fivetranの課金単位)の見積もりを立てておきます
    • Snowflakeには30日分の無料期間と$400分のクレジットがあります。その間に、ウェアハウスの利用料の見積もりとストレージ費用の見積もりをざっくり出しておきます
    • 曳光弾開発とも相性が良いです
  2. 求められなくても、コストに関する報告は優先して実施するようにします
    • 報告をしっかりしておくだけで、怒られが発生するリスクはかなり減ります

政治リスク

政治的な問題により、移行プロジェクト自体が尻切れトンボになってしまうリスクもあります。具体的には以下のようなリスクです。

  1. チーム内メンバーの協力が得られない
    • 人手を借りられず、時間切れになる
    • 新たな技術を導入しても普及しない
    • 通常業務に忙殺され、移行にリソースを割けない
  2. ステークホルダーの合意が得られず、移行自体が中止になる
    • SaaSの利用に対して承認が得られない
    • 「鶴の一声」で移行自体が立ち消えになる

地道に対応していきましょう。メンバーへの頭出しや根回し、個別の説得を実施し、協力を取り付けるようにしました。「メンバーのスキルのキャッチアップを補助する」とあらかじめ宣言しておくのも有効です。開発の進捗は適時共有し、今どのような状況なのかが把握されている状態を作っておくのがよさそうです。

結論

様々なリスクを考慮した結果、「曳光弾開発」のスタイルで実装することを決めました。利点として魅力に思えたのは以下のような観点です。

  1. 動くことを検証しながら実装できる
    • 機能要件・非機能要件を満たせることを確実に保証しながら進むことができる
  2. 動くデモを作れる
    • ユーザーからの反応を得ながら開発できる
      • 特に、データ分析チームにはエンジニアが一人しかいないため、アーキテクチャに関するレビューが不可能な状態でした
      • 実際に動くプロダクトなら非エンジニアのアナリストでもレビュー可能です
    • 現状の共有がスムーズに行えるため、政治的なリスクを抑えられる
  3. 手戻りを抑えられる
    • 実装期間を最小限に抑えられるため、時間切れのリスクを抑えられる
  4. コストを図りながら実装できる
    • 資金リスクを抑え、政治的なリスクを抑えられる

方針が固まったところで、次は実際に開発していく過程を振り返っていきましょう。

実際の設計・開発

方針を前提に、実際の技術選定と実装の過程を振り返っていきます。

まず一番最初に決めるのはデータウェアハウスです。選択肢が少ないから決めやすいのに加えて、他の構成要素への影響が大きいため、一番最初に決めておくのが良いと判断しました。次に、データソースからダッシュボードに向けて、順番に技術選定を実施していきます。

では、技術選定の過程を振り返っていきましょう。最小構成の構築にかかった期間は一週間ほどでした。

データウェアハウスの決定 : Snowflake

バックエンドがAWSであり、ログがJSON LINES形式の形でS3バケットに出力されるため、同じAWS圏内で利用可能なものにする必要がありました。また、弊社の分析は基本的には日次バッチですが、一部の加工前データを利用した分析はリアルタイムで実施する必要があります。

なのでSnowflakeで確定です。Snowpipeもありますからね。BigQuery Omniを利用するよりも楽に設定できそうなのも魅力でした。

Snowflakeについてざっくり理解したい方はこちらをご覧ください。

www.youtube.com

この段階で、Snowflakeのアカウントを作成しておきます。無料期間を最大限活用していきました。

docs.snowflake.com

加工前データの取り込み:Fivetran + Snowpipe

データウェアハウスが確定したので、データの取り込み手段を考える必要があります。なお、dbtを導入することは確定していたため、ELT*2の構成になることが前提になっています。

データソースとしては3種類あり、それぞれ違った取り込み形式を利用してSnowflakeに取り込んでいきます。

Amazon S3バケット上に置かれたJSON Lines形式のファイル

ユーザーの行動ログはKinesis Firehoseを経由してS3バケット上にPUTされます。なお、分析のユースケース上、Kinesis Firehoseから出力されたデータはリアルタイムでクエリ可能な状態になる必要があります。

選択肢ですが、データウェアハウスとしてSnowflakeを利用しているため、事実上Snowpipe以外の選択肢がありません。Snowpipeで取り込みます。

docs.snowflake.com

なお、外部ステージ→Snowpipe→ローデータ格納テーブルの対応関係はTerraformでモジュール化しておきました。実運用に移行するうえでは、複数の対応関係を作る必要があるため、あらかじめモジュール化しておくと素早く実装できそうです。

Amazon RDS for Aurora MySQLインスタンス

プロダクト本体のバックエンドとして利用されているAmazon RDS for Aurora MySQLインスタンスSnowflakeに取り込みます。AirbyteかFivetranで迷いましたが、RDSのコネクタがあり、管理に手間がかからないFivetranを選びました。

www.fivetran.com

踏み台サーバーを経由した接続に時間がかかりましたが、Product部の纐纈さんと石塚さん*3に手伝っていただいたため、速攻で何とかなりました。逆に、接続の確立が終わってからはほとんどすることがありませんでした。

Fivetranにはコネクタごとに2週間の無料期間があるため、MARを図りながら料金を見積もっておきます。FivetranはActive Record (更新のあったレコードのような概念)の月次集計で料金が変わる従量課金型のツールです。コネクタを接続してから1週間ほどたつと勝手に見積もってくれたりします。

www.fivetran.com

記事執筆時点でFivetranを利用し始めて2か月ほど経ちますが、とにかく手間がかからなくてよいツールです。テーブルの追加やカラムの追加に自動で対応してくれます。Airbyte Cloudより料金は高いですが、運用をスマートにこなしつつ、ユーザーのデータのニーズに応える体制を作るうえでは必要なコストとしてとらえています。

Notion, Google SpreadSheetなどの手入力データ

弊社では、プロダクト本体では回収できないデータをGoogle SpreadSheetやNotionに入力してもらい、そのデータをデータ分析基盤内で利用しています。もともとAWS Lambdaを利用してCSV形式に落とし込んでS3上にアップロードする形で運用していたため、既存プログラムを修正するのみで対応完了です。

データの変換:dbt

データの変換ツールとしてはdbtを利用します。

www.getdbt.com

魅力に関しては既に多くの方が書かれているのでここでは割愛し、弊社のデータ分析チーム内での議論において、特に何の機能を魅力としてとらえていたのかだけ書こうと思います。さっと上げると以下のようなものです。

  • リネージュ把握機能
  • ドキュメント機能
  • ローカルでの実行機能
  • マクロの利用

運用して2か月たちますが、現場では特にリネージュ把握機能が人気のようです。ちなみに、筆者が初めてdbtを使ったときは感動して涙が出ました。良い時代に生まれてよかった…

dbtの実行管理ツール選定の観点

Findyで特集が組まれるくらい流行りのdbtですが、dbtのオーケストレーションには選択肢が多く、悩ましいポイントでもあります。dbtのDAG実行管理をどのように行うかにより運用時のコストが変わります。考慮した点としては2つありました。

特定のモデルの実行が失敗した場合、素早く復旧することが可能か?

具体的には以下のような点です。

  • 特定のモデルを選択して実行することが可能か
  • 特定のモデルの下流のモデルのみ、もしくは上流のモデルのみを選択して実行できるか

仮に上記のようなことを行えず、単純に dbt run するしかない状況だと、一つのモデルでエラーが発生した場合でも全てをやり直す必要があり、復旧時のオペレーションに時間がかかります。データは水物であり、どのモデルにも潜在的にエラーを起こす可能性はあるため、柔軟にモデルを選択して実行を管理できる必要があります。

特定のモデルを連続する期間にわたって再実行することが可能か?

例えば、日次で実行しているインクリメンタルなモデルがあったとします。そのモデルの実行を2023-09-01から2023-09-08までの期間だけやり直したい、ということは結構よくあります。いわゆるbackfillですね。

dagster.io

上記記事によると、backfillの定義は以下のようなものです。

For example, you have a table, and each day, you add records to it that correspond to events that happened during that day. Backfilling the table means filling in or overwriting data for days in the past.

(日本語訳) 例えば、あるテーブルがあり、毎日、その日に起こった出来事に対応するレコードを追加するとする。テーブルのバックフィルとは、過去の日数分のデータを埋める、あるいは上書きすることを意味する。

選ばなかった選択肢

リネージュを考慮した実行が可能であり、なおかつバックフィルが可能な手段となると、選択肢は3つほどありましたが、最終的にはDagster Cloudを利用する方針としました。考慮はしたが選択しなかった選択肢としては以下の2つがありました。

Airflow + BashOperator

  • Airflowをベースに、BashOperatorを利用して個々のモデルごとに dbt run --select model_name をしていく実装です。Airflowのクラウド環境を提供するAstronomer社のブログで公開されていた手法です。

    www.astronomer.io

  • すでに運用知見があるAirflowを利用できるのはメリットではありました

  • しかし、ブログを見た限り、実装が重くなりそうなため、あまり気乗りしませんでした

dbt Cloud

  • 筆者も個人的に利用しており、dbtの範囲内だけでオーケストレーションするなら良い選択肢だと思います
  • しかし、弊チームではデータソース取得処理の中でAWS Lambdaなども利用しています。最終的にはそれらを含めたオーケストレーションまでやりたいと考えているため、力不足感がありました

なお、ちょうど移行作業を実施していた7月ごろ、Astronomer社からCosmosパッケージが発表されました。このパッケージを利用する手段もありましたが、時期の都合上、技術選定の段階では考慮に入れることができませんでした。

www.astronomer.io

Dagster Cloudを利用する

メリットとデメリットを天秤にかけた結果、Dagster Cloudを利用して実装することに決めました。

メリット

モデルを展開したうえで実行管理ができる

  • わずかな行数のコードを書くだけで、dbtのprojectディレクトリ配下にあるモデルを取り込むことが可能です

    一部伏字になっていますが、実際のパイプラインの一部です

  • 特定のモデルを選択して実行することも可能ですし、特定のモデルの下流のみ・上流のみを選んで実行することも可能です

    上流・下流モデルに絞ったモデルの選択が可能

バックフィル・オペレーションが楽

  • ものすごく簡単です。一つあるいは複数のモデルをGUI上で選んで、期間を選択するだけです。下の画面で、右下にある「Launch 479-run buckfill」を押せば、479日分のバックフィルが実行されます

    バックフィル画面

開発しやすい

  • ローカルで実行とブランチデプロイが可能なため、Jobの開発がすごく簡単です。Dagster Cloudにおけるブランチデプロイ機能を利用すれば、プルリクエストごとにクラウド環境を作れるため、検証・開発が非常に容易になります。詳しくは公式ドキュメントを参照してください

    docs.dagster.io

  • SQLをちょっと直す程度では使わない機能ですが、新たなJobの開発など、データエンジニアリングの領域の業務では非常に有用な機能です

  • また、dagsterは日本語の文献が少なく、概念も独特なため学習の難易度は高いのですが、開発が簡単なので高速でフィードバック・ループを回しながら学習できるという利点もあります

サーバーレスな実行環境を作れる

  • Dagster Cloudのサーバーレス版を使えば、コンピュートを実行する環境の管理が不要になります。Airflowに対するMWAAのような感じです

    docs.dagster.io

デメリット

学習コストが高い

  • dagsterの公式ドキュメントを読んでみるとわかると思うのですが、dagsterには独特な概念が多く、Airflowなどの既存のDAG実行管理ツールに慣れたエンジニアでも学習には苦労するツールです
  • しかし、開発しやすいため、学習のためのフィードバック・ループを回しやすく、学習コストの高さを打ち消すことが可能であると考えました
  • (追記)Dagster Universityという公式のラーニングコースもあるようです

    courses.dagster.io

実際の活用事例が少ない

  • dagsterは導入事例が少ないため、意図しない挙動が起こった場合にググってもようわからん状態になりがちです
  • しかし、コミュニティによるサポートがあるため、最悪そこに投げれば何とかなるかもと思います。ならないかもしれませんが

結論

デメリットは確実にあるわけですが、それを補って余りあるメリットがあると判断したため、dbtの実行管理はDagster Cloudで実施することに決めました。

Dagster Cloudにも無料期間があるため、無料期間を利用して技術検証を行いました。dbtのモデルを取り込んだり、Pythonを書いたりできるかを検証していきます。いかんせん導入事例が少ないため、公式ドキュメントとGitHubのIssue、およびライブラリの実装を見ながら、なんとか運用できるラインまで持っていきます。CD周りは自動で生成してくれるGitHub ActionsのYAMLファイルを利用しました。もちろん、無料期間内に費用の見積もりを出しておくのも忘れずに。

最終的な設計図と肉付け

最終的な設計図は以下のようになりました。

データ基盤の全体像

プロトタイプの構築が完了したため、最も難易度とリスクが高い個所をクリアすることができました。あとは「肉付け」の過程を通して、実際に利用できるデータ分析基盤を構築していきます。やるべきことは主に二つです。

まず、S3上に存在する加工前データの生データをSnowflake上に取り込む必要があります。Snowflake-connector-pythonを利用したプログラムを書いて実行し、夜間に実行して完了しているようにしました。特筆するところはなさそうなため省略します。

docs.snowflake.com

次に、既存のSQLをdbt+Snowflake記法に書き直したうえで、移行する必要があります。こちらに関しては、dbtとSnowflakeの勉強会を開き、チームメンバーに作業を分担してもらいながら実装しました。こうすることで、作業の並列化して実装期間を短縮しつつ、チームへのスキル普及を行うことが可能です。

おわりに

実際に利用可能なデータ分析基盤の構築が完了しました。

話は変わりますが、漢の将軍韓信は河を背にして陣をひき、兵たちを奮い立たせ、10倍の敵を打ち破ったといいます。あえて退路を断つことが有効であることは、データ分析基盤の移行に関しても同じです。過去に使っていたGlue Jobをすべて削除し、Glue Catalogを吹き飛ばし、MWAAの環境を消去しました。これでもう退路はなく、前に進む以外の道はなくなりました。

データ分析基盤を移行した結果

最後に、データ分析基盤の移行の結果を取りまとめて記事を締めくくろうと思います。

パイプライン実行時間が約30倍高速になる

パイプラインの実行時間は2時間50分から5分に短縮されました。原因は複数ありますが、以下の2つが大きい思っています。

  • 時間のかかる処理がなくなったこと
    • 具体的には、Glue JobおよびGlue Crawlerの処理が無くなったこと
  • Snowflake自体の実行が早いこと

ウェアハウスのマルチクラスタ化やサイズ拡大を実施すれば、将来的にパイプラインが拡大してもこの速さを維持できる想定です。すごい時代だ…

開発の速度が(体感)10倍くらい速くなる

次に開発の速度ですが、変更を加えるまでのスピードが体感10倍くらい早くなったと思います。時間を図っているわけではないので正確なことは言えませんが、考えられる要因としては以下のような原因がありそうです。

  1. Gitのフローがgit-flowからGitHub-flowに変更になり、変更手順がシンプルになったこと
  2. ブランチデプロイが可能になり、データエンジニアリングのコストが下がったこと
  3. ローカルでのテスト実行が可能になり、検証が容易になったこと

いずれもdbtとDagster Cloud, そしてSnowflakeの組み合わせで実現が可能になったものです。

運用の労力削減

最後に、運用のコストもかなり下がりました。

  1. 運用コストの高いGlue Job (Spark)を排除し、ほとんどの変換処理をSQLで統一したため、チーム内の非エンジニアメンバーでも保守・運用できる範囲が広くなった
  2. エラー発生確率の高いGlue Data Catalogを排除できた
  3. バックフィルオペレーションの手順がシンプルになった
  4. 開発が容易になったたため、「運用を楽にするための開発」がしやすくなった

結果的に、データ分析基盤の移行によりチームのケイパビリティは高まり、より多様なニーズに応える体制が整いました。運用のコストが削減され、データを利用して事業価値に貢献するための「余力」が増えたともいえます。データ分析基盤自体はよりアジャイルなものとなり、浮かせた運用コストでデータによる価値向上にコミットできる分が増え、データ分析者の体験も向上させることができました。

今後は、データ分析チーム以外のメンバーでもSQLを書いたりできるように、データカタログを充足させたり、テーブルを使いやすくしたり、データガバナンスを強化したりしていきたいと考えています。まだまだデータ利用者側のニーズに応えきれているわけではないので、地道にフィードバックを受け取りながら改善していきたいです。

*1:データ分析チーム内にはエンジニアが自分しかおらず、技術選定や難関になりがちな初期設定、設計などを担えるのは筆者しかいない状態でした

*2:Extract, Load, Transform : とりあえず生データをデータウェアハウスに突っ込んどいて、あとはよしなに変換しよう!という考え

*3:詳細はこちら:https://tech.algoage.dmm.com/entry/2023/09/13/133111

*4:と2023年9月のSnowflake Data Cloud World Tourの基調講演で聞きました

プロダクト、技術スタック、開発の流れ。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カ月のスパンで実現しています。

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

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

【連載】データ分析基盤をdbt・Snowflakeに移行する【移行前のつらみと設計原則編】

1. はじめに

 こんにちは、Ops-dataチームの上村(@contradiction29) です。データアナリストとして入社したのち、ダッシュボード作りに没頭し、テーブル作成にのめりこみ、データエンジニアリングに夢中になり、今はデータエンジニア兼アナリティクスエンジニアをやっています。

 つい最近、弊社Algoageで運用しているデータ分析基盤のリプレイスを実施しました。その際、私は言い出しっぺ兼リードエンジニア兼ちょっとしたプロジェクトマネージャーのような役割をしていました。いろいろ思うところがあったため、考えをまとめてみようと思います。

2. イントロダクション

 チャットブーストCVは「日常生活の中からユーザーの購買・契約行動を後押ししてCVを増加させるサービス」です。

chatboost.dmm.com

 弊社AlgoageはチャットブーストCVに関する業務に注力しており、自分が所属するOps-dataチームではデータの利活用やデータ分析基盤の開発・運用を実施しています。データアナリスト4名とデータエンジニア1名(筆者)で構成されるチームです。

 チャットブーストCVが2022年2月にサービスを開始してから3か月後、データレイクとして利用しているS3バケットに初めてのデータが入りました。以来、データ分析基盤はチャットブーストCV本体と併走を続け、社内メンバーやクライアントの意思決定を合理化し続けています。データの量は1.5TB近くになり、BIユーザーの数は100名を超えました。社員数は大体100 ~ 150名なので、社員の半分以上はBIユーザーということになります。

 しかし、システムの運用に課題はつきものです。詳しくは後述しますが、さまざまなつらみがエンジニアやアナリストを苦しめました。データ分析基盤として存続していく上では致命傷となる「つらみ」も発見されました。つらみが全くない状態で運用した日は今まで一日もなかったと言っていいでしょう。

 運用の段階で溜まった知見を設計に反映させてつらみを解消するとともに、意思決定支援システムとしての価値を存続させるため、私はデータ分析基盤の移行を行うことにしました。データ分析基盤の運用を始めてから1年以上経ちました。知見が溜まった今なら、もっと上手くやれるはずです。データの利用者に対して直接向き合い、価値を提供する役目を持つデータアナリスト、およびBI・アナリティクスエンジニアとしての業務を続けてきたことで、自分の中で、以下のようなことがぼんやりとイメージとして形成されてきました。

  1. 社内のマーケティングチームをはじめとしたデータのユーザーがデータ分析基盤に何を期待しているのか
  2. どのような開発フローを構築すれば、素早くデータの利用者に価値を提供できるのか
  3. そもそも、データ分析基盤はシステムとしてどのような価値を提供するべきか

初期の段階ではなかったイメージが、今は自分の手元にある。やるなら今だ、と思いました。

 この文章では、Algoageにおけるデータ分析基盤移行プロジェクトについて、自分が何を考え、どのようなことを実行していったのかを記述していきます。形式としては「移行前のつらみと設計原則編」「設計・構築編」「運用編」の3編構成とします。

 データ分析基盤を作ったことがある方ならわかると思うのですが、データ分析基盤は一度構築して終わりではなく、運用の中で進化していくものであり、将来的な発展を見据えた上での設計・構築が必要になります。自分の知る限り、つらみの振り返りから移行後の運用まで全体的に記述した記事は珍しいと思うので、書いてみようと思います。

 この「移行前のつらみと設計原則編」では特に設計の前段階の要求定義に焦点を当て、既存基盤を運用していく中ではっきりとしてきた課題を描き、新しい基盤で何を目指すのか、方向性を明確にします。その方向性の元でどのような技術的な選択をしていくのかには踏み込まず、次の記事で細かく書こうと思います。

 想定している読者層は「データ分析基盤について興味がある人」とし、登場する技術について細かく記述することは行いません。Amazon AthenaやAWS GlueをはじめとするAWSの分析系サービス群、およびSnowflakeに関しては基礎的な知識があることを想定していますが、適時補足を入れていきます。

 構成は以下のようにしていきます。

 それでは中身に入りましょう。

3. 旧基盤の反省点

 この章では、移行を行う前の基盤について全体像をさっと記述してから、運用上何がつらかったのかについてふりかえっていきます。なお、移行を行う前のS3・Athena・Glueを中心とする基盤を「旧基盤」と呼ぶことにします。

旧基盤の全体像

まずはポンチ絵で旧基盤の全体像を掴みます。

旧基盤の全体像

 当時のマネージャーから聞いた話ですが、旧基盤を作成した当初、社内にはデータ分析基盤の構築・運用経験のあるエンジニアがおらず、とにかく素早く価値を提供するためQuick and Dirtyの精神で実装したそうです。それから地道に補修を重ね、上記の図ような構成になりました *1

 旧基盤は、役割別に3つのS3バケット「data-lake-raw」「data-lake-formatted」「data-mart」から構成されています。詳細について下記にまとめました。

バケット 中身 ファイル形式 データソース
data-lake-raw 未加工の生データ JSON Lines, parquet Kinesis Firehose
RDS(Glue Job経由で取り込み)
data-lake-formatted data-lake-rawのデータをフラット化し、ファイル形式を変換して個人情報を脱落させたもの parquet data-lake-raw
data-mart data-lake-formattedのデータをSQL経由で加工し、データマート化したもの。もしくはスプレッドシートやNotionから取り込まれたデータ CSVなど data-lake-formatted
スプレッドシート
Notion
  • 権限はAWS Lake Formationで管理し、DAG(Directed Acyclic Graph : 依存関係を考慮したタスクの集合)の実行管理はManaged Workflow for Apche Airflow (MWAA)でおこなっている
  • GitHubでコードを管理し、GitHub ActionsでMWAA環境へのデプロイを行なっている

 全体像をつかんだところで、具体的なつらみの話に入ります。なお、補足しておくと、以下で上げる技術は適切な使い方をすれば十分便利なものであり、つらみを出してしまったのは使いどころが悪かったためです。反省するべきは技術選定を行った我々で、技術そのものは適切な使い方をすれば価値を発揮できるものであることは明記しておきます。

AWS Glue Job (Spark):大型トラック

 Amazon Kinesis Data FirehoseからPUTされたJSON Lines形式 *2 のファイルはそのままでは分析に不向きなため、フラット化や個人情報を含むカラムの脱落処理をしたうえで、ファイル形式を列志向フォーマットに変更する必要があります。弊チームでは、この目的を達成するためにSparkのAWS Glue Job (以下Glue Jobと省略)を使用していました。機械学習を用いた処理や複雑なJOINは使っていません。

docs.aws.amazon.com

 端的に言うと、上記のようなユースケースであればGlue Jobを利用するのはオーバーでした。Glue Jobは開発者目線で開発しづらく、処理に時間もかかるため「JSONを展開する」程度の処理であれば使うべきではない技術だったのです。

開発しづらい

 Glue Job (Spark)はローカルで実行するにはあまりに重く、公式のDockerイメージ*3を使って100万行オーダー以上のデータを処理しようとすれば確実にMacBook Proが火を噴きました*4AWS上で実行できるNotebook *5 もありますが料金はかかりますし、使い勝手もいいものとは言えません。Glue JobはSparkを便利に使いこなすインターフェースを提供してくれるものの、小回りが利かないため、使うタイミングは慎重に選ぶべきツールです。

時間がかかる

 Glue Jobの処理の実行時間は合計で1~2時間ほどでした。詳しくは次の記事で述べますが、同様のデータをSnowflakeSQLで変換したところ、2分程度で全処理が完了しました。 2分!

徒歩30秒のコンビニに行くために大型トラックを使わない

 開発者体験の低さと処理時間の長さにエンジニアの技術的な不慣れさが合わさり、長年の開発でコードは黒魔術と化しました。今年の6月に処理落ちが発生したため、過去に別のエンジニアが書いたGlue Jobのコードを読み解いて修正する作業を私がやっていたのですが、大変つらい思いをしたのを覚えています。ローカル上でのデバッグ実行はできず、処理に時間がかかるため繰り返し実行して検証するのに時間がかかり、苦労しました*6

 しかし、同じ価値を発揮できる、もっと簡単な方法があったのです。処理時間はわずか2分ですし、SQLで書かれているのでチーム内の全員が取り扱えます*7。あの苦労はなんだったのでしょうか?例えるなら我々は、徒歩なら30秒でたどり着けるコンビニに、大型トラックで1時間かけていたのです。乗っていたのがトラックだと気が付かずに。他の種類の車を知らない人がトラックを「トラックである」と判別することは不可能です。今まで何と戦っていたのでしょう?トラックは本当に必要ですか?

 移行の結果を先取りしてしまうと、最終的にはdbtを利用したSQLを用いて、Glue Jobで実施していた処理をすべて置き換えることにしました。ほかの要素*8による影響もありますが、処理時間の大半を占めるGlue Jobの処理を省略出来た結果、パイプライン全体の実行時間は180分から6分に短縮され、約30倍の高速化を実現できました。

Amazon Athena:砂漠のオアシス

 分析用のクエリエンジン、およびデータマート作成処理のために使っていたAmazon Athena(以下Athenaと省略)はコストパフォーマンスに優れ、リソース管理が楽なツールです。実装されているSQLの関数は豊富であり、たいていの処理はこなしてくれます。

aws.amazon.com

 しかし、分析用のクエリエンジンとしては物足りないのに加えて、初期のテーブル設計時のミスが基盤全体のボトルネックになってしまいました。

青すぎた隣の芝生

 Athenaのコンソールにはクエリの自動補完の機能がありません。自動補完がなくてもSQLは書けますが、Google Cloud BigQueryやSnowflakeが同様の機能を持っていることを考えると、分析用のクエリエンジンとしては見劣りします。他のエンジンの利用経験があるアナリストからの評判は良いものではありませんでした。最近になって補完機能ができましたが、他のテーブルのカラム名が出てくる、カラム名を出すべきところなのにデータベース名が補完されるなど、精度の観点では実用的と言えません。

 Athenaはサーバーレスでクエリを実行でき、管理が楽で、コストパフォーマンスのよいツールです。ただ「BigQueryやSnowflakeでできることを実行できない」という意味では、分析用のツールとしては不便であったと言わざるを得ません。ほかのツールの「芝生の青さ」を知っている者にとっては、Athenaは「不便なツール」に見えたのです。

パーティションの制約とテーブル設計のミス

 また、INSERT INTO文を発行する形でデータマート作成時にもAthenaを利用していましたが、パーティションの同時作成数に上限があったのが致命的でした。

docs.aws.amazon.com

 弊社ではLINEアカウントを運用する形でビジネスを展開しており、「1つの運用アカウント」ごとに「1つのパーティション」を作成していたため、運用アカウントの数が一定数を超えると既存の処理がすべて停止することが分かったのです。移行開始前の段階ではまだ猶予があったものの、パーティションの上限に達するのは時間の問題であり、この問題をクリアできないとデータ基盤が停止することは明白でした。

 対応策としては以下の二つがありました。

  1. INSERT INTO文を分割する
  2. すべてのテーブルを一度破棄し、パーティションの定義を変更したうえで再作成する

 1はAirflow上の運用に落とし込むのが難しく、2はめんどくさすぎます。詳しくは後述しますが、AWS Glue Data Catalogに由来する問題もあったため、両者ともに本質的な解決策にはならないと判断しました。

エラー復旧のやりづらさ

 弊チームのAthena環境ではDELETE文が発行できない*9ため、異常なレコードが見つかった場合の対処にも時間がかかりました。異常なレコードを原因として処理が異常終了した場合、以下のような手順を踏む必要があります。

  1. まずはdata-lake-rawバケット内にあるデータから異常なレコードを含むファイルを見つける
  2. 特定したファイルをダウンロードしする
  3. ローカル上で操作してファイルの内容を変更する
  4. バケット上に戻す
  5. Glue Jobの処理からやり直す

この一連の流れを実行するまで時間がかかり、結構つらかったですね...

砂漠のオアシス

 データ分析基盤の構築初期段階においては、Athenaは優れたツールでした。サーバーレスのためリソース管理が不要で、コストパフォーマンスに優れ、基本的な操作は問題なくこなせます。使い始めたばかりの頃の自分にとっては、Athenaのクエリ実行能力や、インフラ管理の要らないサーバーレスの特性は、データ分析という砂漠の中のオアシス(救済)のように思えました。

 しかし、砂漠のオアシスは一時の救済をもたらしますが、真に緑豊かな土地を求めるならもっと遠くを目指す必要があります。データの規模が増大し、分析の要求が複雑化してくると、頻繁にAthenaを利用するデータアナリストの間で、分析用のクエリエンジンとしてのAthenaの不便さや、機能性の不足に不満がたまるようになりました。

 ちなみにですが、3つ挙げた課題のうち、2つめのパーティション数制限はテーブル設計時にもう少し考慮すれば回避できたはずで、最後のDELETE文の発行に関してはApache Icebergなどを使えば回避可能な問題ではありました。

docs.aws.amazon.com

AWS Glue Data Catalog:迷路の地図

 AWS Glue Data Catalog(以降Glue Data Catalogと省略)はHive MetastoreのAWS版にあたり、各テーブルのメタデータを保存する頭脳の役割を果たしています。

docs.aws.amazon.com

 長くなるため深入りしませんが、以下のようなエラーに悩まされました。Glue Data Catalogというよりは基盤の構造によるものです。

  • 少し重めのクエリを投げるとすぐ発生するHIVE CURSOR ERROR (S3 Slow Down)
  • 頻繁に発生するHIVE_PARTITION_SCHEMA_MISMATCH
  • S3上にファイルがあるのにAthenaからクエリできず、何度もMSCK REPAIRを行う必要があったり、何度やってもパーティションが追加できなかったり...

 Glue Data Catalogは迷路の地図のようなものです。示すルートが正しいことを保証しないものの、自分が現在どこにいるのか、またどこに向かうべきかの指示を提供してくれます。しかし、複雑さや頻発するエラーを考慮すると、最初から迷路に足を踏み入れるべきではありませんでした。そもそも迷路に入らずとも同じ目的を達成することは可能であることを考えると、迷路に入りこむメリットはなさそうです。

git-flow:重すぎた剣

 Airflowによる開発を行う際はgit-flowで行なっていました。git-flowはdevelopブランチとmainブランチを切り分けてあいのあいの...というものです。詳しくは以下の説明をご覧ください。

nvie.com

なぜgit-flowにしたのか?

 AWSのマネージド版Apache AirflowであるManaged Workflow for Apache Airflow (以下MWAAと省略) は環境の立ち上げに30分から1時間程度かかるため、ブランチ作成のたびに開発環境を作成するのは現実的ではありません。 *10。 ローカル開発用の環境 *11 もありますが、重いツールなのでローカルで立ち上げて実行するのもかなり辛く、Macbook Proが火を噴きました(2度目)。スペックの都合上、ローカルでの開発は現実的ではありませんでした。

 なので*12、MWAA上に開発用の環境と本番用の環境を二つ用意し、developブランチを開発用環境に対応させ、mainブランチを本番環境に対応させる形で運用していました。本番環境に変更を加える際、「通常通りの運用」として想定されていたのは以下のような流れでした。git-flowの少し変えたバージョンです。

  1. developブランチからfeatureブランチを切ってチェックアウト
  2. featureブランチ内で変更を加える
  3. featureブランチの内容をdevelopブランチにマージ
  4. mainブランチからreleaseブランチを切る
  5. developブランチに対するコミットをgit cherry-pickしてreleaseブランチに反映する
  6. releaseブランチの内容をmainブランチにマージ

「本番環境でテストすればいい」

 当然面倒なので、次第にmainブランチに直接変更を加えるのが流行るようになり、developブランチとmainブランチの差分が大きくなっていきます。そうなるとますますdevelopブランチ、および開発環境は使われなくなっていきます。やがて「本番環境でテストしよう。なんかあったらgit revert すればいいだろ、どうせ1日1回のバッチ処理なんだから」というノリになり、誰もdevelopブランチおよび開発環境を使わなくなりました。最終的に本番環境を利用して動作確認をするようになったため、レビューがおろそかになってコードの属人性が高くなったり、きちんと開発環境で動作確認をしていれば防げたようなミスが発生するようになりました。

 背景まで説明しておくと、Ops-dataチームはデータアナリストが多数派で、Gitを手足のように使いこなせるメンバーは多くありません。「基本的な操作は知ってるけど、そこまで詳しくはない」レベルの知識でgit-flowの運用は不可能です。メンバーのスキルセットと運用のミスマッチが本質的な原因です。

4. 設計の原則

 絶対王政下の圧政と対峙して人権思想が産まれたのと同様に、つらみに正面から取り組むためには「よりどころ」となる価値観が必要です。困難な問題に立ち向かうためには「思想」が必要であり、思想なき改革は「作業」にすぎません。また、技術的な選択にはトレードオフへの対処がつきものであり、トレードオフに対峙したときに寄るべき価値基準を事前に作っておくことには意味があります。

 この章では、新しい基盤を作る際の設計原則を提示し、それぞれの原則について旧基盤はどのような点で原則を満たしていなかったのかを書いていきます。「3. 旧基盤の反省点」で書いてはいないつらみも少し出てきます。

 なお、ここで記載されていることはすべて筆者の個人的な意見です。

原則1:変化に適応できる設計

 データに対するニーズはめまぐるしく変化します。1週間前のミーティングで要求されたダッシュボードが「やっぱいらないわ」と言われることもあれば、既存のニーズに対応した結果として変化するニーズ、状況の変化に伴い突如発生するニーズもあります。現実は常に想像を超えており、利用者のニーズを予測することは不可能です。

 であるならば、データのニーズに対応する戦略としては「堅実な予測」よりも「迅速なニーズの充足」に価値を置くべきと考えました。ニーズは放っておくと消失してしまうものですが、消えてしまうニーズの中には「真にユーザーが求めているニーズ」につながるものが隠れています。迅速にデータを提供できれば、そのようなニーズを永続的に満たす仕組みが作れるのです。逆に、遅くなればニーズは立ち消えてしまうでしょう。速さとは価値です。素早くニーズを満たせる仕組みには価値があります。

原則1:データ分析基盤は、 変化するニーズに応え、迅速に価値を提供できるように設計するべき

 具体的には、以下のようなことを目指します。

  • テーブルの要件定義を始めてから、実際にテーブルを作成するまでの時間を短くすること
  • テーブルの定義を変更するまでにかかる時間を短くすること
  • 開発フローをより単純にすること
  • 開発者体験を向上させること
  • メンバー同士で、データマート作成用のSQLのコードレビューをしやすくすること
  • テストを容易にすること

 旧基盤においては、この価値基準は満たされていませんでした。

  • テーブルを作成する主な手段が「mainブランチに直接マージして本番用のMWAA環境で実験する」だったため、テーブルの作成に時間がかかり、レビューも満足に行われなかった。
  • テーブル定義の変更が容易ではなかった
  • 開発フローは煩雑なものであり、開発者体験も悪かった
  • テストは「一回アドホックSQLで検証して終わり」だった
  • Glue Data Catalog由来のエラーが頻繁に発生し、開発を妨げていた

原則2:運用労力の最小化

 弊社のようなスタートアップ特有の事情ですが、データ分析基盤の「運用」だけに割ける人手は多くありません。もし仮にデータ分析基盤の運用にかかる手間が非常に重く、エンジニアやアナリストの労力の大半がデータ分析基盤の運用に割かれれば、その分だけ利用者目線での価値提供にコミットすることが難しくなります。

 であるならば、プロセスの最適化と自動化を通じて運用にかかる労力を最小限にし、価値提供にコミットできる体制を作る必要があると考えました。

原則2:データ分析基盤の運用にかかる労力が最小限となり、データ利用者への価値提供に集中できるように設計する

 具体的には、以下のようなことを目指します。

  • エラー発生時のリカバリーにかかる時間を最小化すること
  • 新規テーブル作成時や既存テーブルの変更時に発生する「バックフィル・オペレーション」を最適化すること
  • コスト監視、クエリ実行監視など、監視業務を自動化すること
  • 定常的な運用フローを最適化すること

 原則1と同様に、旧基盤においてはこの価値基準は満たされていませんでした。

  • 異常なレコードが原因で処理が落ちた場合、取り除いてから処理を再実行するまで長い時間がかかっていた
  • Glue Jobの段階でエラーが発生した場合に対応が可能なメンバーが一人しかおらず、危険性の高い状態だった
  • Glue Jobの開発のしづらさにより、エラー発生時の修復に時間がかかっていた

原則3:「分析者体験」の最大化

 データは複雑な現実世界を読み解くための武器です。利用者の手に渡り、適切な使い方で利用されることにより初めて価値を発揮します。データを分析する際の利便性を犠牲にすればデータは利用されなくなり、価値を失ってしまうでしょう。

 であるならば、データの「分析者体験」*13とでも呼ぶべきものを最大化するべきです。データ分析基盤の最上の価値を「データ利用者への「分析者体験」の提供」と定めます。当たり前のことですが、あらためて明示しておきましょう。

原則3:データ分析基盤の利用者への「分析者体験」の最大化を第一の判断基準として設計する

 旧基盤においては、分析者の体験を最大限配慮したとは言えないものになっていました。

  • Athenaが分析用のクエリエンジンとしては使いづらかったこと
  • メタデータの管理が一元化されておらず、情報が古かったこと
  • テーブル同士の関係性(Data lineage)*14が把握できず、どのテーブルからとってきたデータなのかわからないこと

おわりに

 この文章では、まず移行前のデータ分析基盤のつらみについて、構成する技術ごとに記述したのち、つらみを踏まえたうえで、新しい基盤で何を目指すのかの原則を提示しました。

 次の文章では、原則を踏まえた「設計」に焦点を当て、利用した技術の詳細やその検討過程を記述していきます。

*1:旧基盤が全く改修されなかったわけではありません。自分が入社した当時はAWS Step Functionsを実行管理に使っており、Git管理もGitHubではなくGitLabでした。本筋からそれるため、旧基盤の改修については割愛します。

*2:一つの行が一つのJSONレコードとなり、複数行組み合わさったファイル形式のこと。詳細についてはjsonlines.org参照 JSON Lines

*3:Glue JobはAWS公式が配布しているdockerイメージを使ってローカル開発が可能 https://docs.aws.amazon.com/ja_jp/glue/latest/dg/aws-glue-programming-etl-libraries.html

*4:2018年式のIntel Macで実施。また、Glue Parquet形式を利用している場合、ローカルで処理を完結させることがそもそも不可能です

*5:https://docs.aws.amazon.com/ja_jp/glue/latest/ug/notebook-getting-started.html

*6:プロダクト側から発行されるログの形式が複雑であったことも苦労の種となりました。本筋からそれるため、この話は割愛します。

*7:弊チームでは全員SQLが書けます。また、チーム内でGlue Jobを取り扱えるのはこの記事の作者だけでした

*8:例えば、Glue Crawlerの処理をなくしたこと

*9:後述しますが、Iceberg形式だとdelete文を発行できるらしい

docs.aws.amazon.com

*10:後述しますが、dagster cloudでは可能です。 Branch Deployments in Dagster Cloud | Dagster Docs

*11:https://github.com/aws/aws-mwaa-local-runner

*12:今思えば、mainブランチへのプルリクエスト作成時に開発環境にデプロイされるようにすればよかったのかもしれません。github-flowにするのは技術的に可能ではありました。プルリクエストを二つ同時に検証することは不可能ですが、git-flowの状況でもその弱みは変わりません。

*13:ユーザー体験(UX)のデータ版のような概念で、例えば以下のような状態が「データの分析者体験が良い」といえる 1. 必要なデータがどこにあるのかわかる状態 - メタデータが整備されており、ユーザーの近くに配置されている 2. 必要なデータをすぐに利用できる状態 - データの利用者が自分の力でデータを利用できる - クエリが書きやすい - よく利用する分析に関してはダッシュボード化されている 3. データの品質が担保されている - 欠損がない - ユニークであるべきカラムがユニークになっている、など

*14:Data lineageに関してはdbtの公式ドキュメント参照https://docs.getdbt.com/terms/data-lineage

業務の属人化や開発の遅延、長時間労働をAlgoageはどう改善したか。スクラムを導入し、開発者体験とアウトカムを劇的に向上させるまで

利点の大きいソフトウェア開発プロセスフレームワークとして、世の中に広く知られるスクラム。多くの企業がこの手法を組織に導入・実践して、開発生産性や開発者体験を向上させてきました。株式会社Algoageも、スクラムを取り入れて組織を改善した企業のひとつです。

かつて私たちは、開発プロセスをうまく整備できておらず、メンバーにかかる負担が大きく業務の属人性が高いといった課題を抱えていました。その状況を変えるため、アジャイル開発のスペシャリストである角谷信太郎さんにアドバイザーとして参画していただきました。さらに、メンバー同士で力を合わせて組織全体の方針転換を行い、スクラムに注力してきたのです。

今回はスクラムマスターの日高尚美とエンジニアの若菜実農、石塚大策、纐纈優樹、そして角谷信太郎さんにAlgoageにおけるスクラムの改善の歴史について聞きました。

開発体制を整備する前は「なんちゃってスクラム」状態だった

――開発プロセスの改善前は、どのような流れでプロダクトを作っていましたか?

若菜:「DMMチャットブーストCV」のファーストリリースが2022年5月なので、まずはその前の話からしますね。纐纈さんと石塚さんの2人が2021年の10月に、その1カ月後に私がAlgoageにジョインしました。当時はプロジェクト・タスク管理ツールの「Asana」を使って、かんばんボードでタスクをシンプルに管理していました。

纐纈:かんばんボードに思いついたタスクを入れて、それを担当者にアサインしていく。週に1回の30分の定例会で進捗を確認するという開発方式でした。

――2022年5月に「DMMチャットブーストCV」をリリースしてからはいかがですか?

石塚:それまではタスクのチケットのみで業務を管理していたのが、ストーリーの概念を取り入れるようになりました。そして、開発工数をポイントで管理していました。これはよくあるスクラムポイントではなくて、「仮にCTOの安田(洋介)が担当して1時間かかる作業ならば1ポイント」を割り振るというものでしたね。角谷さんがアドバイザーとして入るまでは、まだまだ“なんちゃってスクラム”のような状態だったと思います。

纐纈:当時は安田さんが開発組織のワントップで、開発のすべてを管理する体制でした。時間単位のポイント制を導入していたのは、そのほうが安田さんにとって管理しやすかったからです。実際に各タスクのポイントをつけるのは安田さんではなく開発者本人で、脳内に小さい安田さんを飼って「安田さんが見積もるとしたらこれは○○時間くらいかな」という感じにポイントをつけていました。

ただ、実際にはいろいろな要因で作業がそんなにスムーズに進まないので、見積もりと実績がズレることが多発していました。それに、CTOの立場になってからあまり開発に時間を割けていない安田さんの見積もりを基準にしていたのも、見積もりと実績の解離に拍車をかけていたと思います。

石塚:そのころ発生していた課題はいくつもありました。まず、全体的にレビューが滞っていたこと。各々が自分の抱えているタスクで手一杯で、レビューに時間を割けない状況でした。担当するタスクの種類も偏っていたので「この種類の作業はこの人しかできない」というケースが多く、それが業務の属人化やレビュー遅延のさらなる原因になりました。

それから、見積もりの精度が低かったことで特定のストーリーが予想より肥大化してしまうことが多発していました。1スプリントで終わる予定だったものが全く終わらなくて、結果的に4スプリントくらいかかってしまうようなことが発生していました。

作業の優先順位を決めることもうまく行っていなくて。社内やクライアントからの要望に急ぎで対応するなど、突発的に優先度が変わるケースがよくありました。それによって、もともと予定していたタスクを期限内に終わらせることができず、スケジュールが後ろ倒しになるなど課題がたくさんありました。

纐纈:改善のための体制変更なども何度かあったんですが、なかなか状況が変わらなくて、開発組織のメンバーの負担が大きい状態が続いていました。

日高尚美

日高:私は前職で認定スクラムマスターの資格を取得して、Algoageに来てからスクラムマスターを担当しましたが、実務経験が無かったこともあり当時はうまくスクラムを回せているとは言えない状態でした。開発チームのみんなが長時間労働を強いられながら、なんとかタスクの期限を守ってくれていました。スクラムマスターとして本当に未熟だったと思います。

アドバイザーとして、角谷さんが参画

――そんななか、スクラムの体制を整備するために角谷さんに参画してもらったのだとか。

日高:アドバイザーを誰にするか社内で検討していたときに、安田さんが「第一候補は日本で一番良い人にしよう。角谷さんはどうかな?」と言ったんですよ。アジャイルの世界では本当に有名人なので「え、角谷さんを呼べるんですか?」とびっくりしました。

角谷:安田さんと私の共通の知人を介して「Algoageがスクラムに本腰を入れて取り組むために、アドバイザーを募っている」と教えてもらったんですよ。私はちょうど時間の余裕ができたタイミングだったので「お手伝いできますよ」と返事をして安田さんにつないでもらって。トントン拍子に話が進み、その週のうちに参画することになりました。

角谷信太郎さん

――Algoageのメンバーから見て、角谷さんはどのようなスキルを持った方だと感じますか?

日高:角谷さんはバランス感覚が素晴らしい人だと思っています。一緒に働くなかで、勉強になることが多いです。スクラムでは、スクラムガイドという型を守らなければならない部分と、スクラムガイドに書かれていない自分たちで決めていくべき部分の両方が存在します。角谷さんはその線引きや実行することの決め方が画一的でなくて、状況に応じてより良い策を決めるような柔軟さがあります。これは、いろいろなチームを経験してきたからこそできることだろうなと思って、いつも感動しています。

石塚:角谷さんが参画する前も、自分たちでレトロスペクティブミーティングなどを運用してはいました。でも、あるべき正しいチームの姿を誰もわかっておらず、思い思いに意見を言う状態なので、収集がつかずに困っていたんです。

でも角谷さんが参画してからは、ミーティングのファシリテーションや論点の整理などをしていただいて、議論がまとまりやすくなったように思います。

纐纈:もともとスクラムの進め方を暗中模索していて、みんなが「私の思う最強のスクラム」の意見を押し付け合っていたんですよ。でも、角谷さんがそこにガイドラインを導入して、みんなが納得できる形でスクラムのイベントを進められるように整備したのがすごかったです。

角谷さんは、普段の生活からアジャイル的な考え方が身に付いていると感じます。たとえば、これまでは何かの変更をする際に、一気に0から100に変えてしまうような極端なケースが多かったです。でも、「まず小さく変えて少しずつ改善していく」という考えを角谷さんが取り入れてくれました。

若菜:経験豊富な角谷さんが、気軽に「アジャイルなんだし、まずは1週間だけ試してみれば?」とアドバイスしてくれるのが、すごくいいんですよね。

日高:角谷さんは開発チームにおける北極星のような存在です。私たちが自己流のスクラムをやっていたところに、「正しいスクラムはこの方角なんだよ」と道を示してくれました。

スクラムガイドをチームで読み込み、その概念を浸透させる

――スクラムの体制を改善するために、角谷さんは何から手を付けましたか?

角谷:どんな会社のアドバイザーをする場合でも、まずはスプリントプランニングやスプリントレトロスペクティブなど、一通りのスクラムイベントに参加します。そうすると、何の改善から手を付けるべきか、だいたいわかるんですよ。

余談ですが、Algoageの開発チームはスプリント周期が最初から1週間でした。これは、すごく良かった点ですね。「1週間のスプリントでは機能開発を終えられない可能性があるから」という理由で、スプリント周期を2週間に設定するチームに出会うことが多かったです。

でも、まだスクラムに慣れていないうちに2週間分の計画を立てても、なかなか見積もりがうまくできないんですね。それよりは、スプリント周期を1週間に設定して、改善のためのフィードバックの回数を増やしたほうが成功しやすくなります。

石塚大策

石塚:角谷さんが参画して間もない頃に、スクラムガイドの読み合わせ会を実施してくれたことが記憶に残っています。当時、私たちはスクラムに関連する用語の意味や、各種のスクラムイベントの目的などを正しく理解できていない状態でした。そこから、読み合わせのなかで角谷さんが説明をしてくれて、不明点を私たちが角谷さんに相談し、だんだんとスクラムの考え方が染み付いてきました。

纐纈:読み合わせ会は本当に良かったです。それまでは各々が「自分の思うスクラムのあり方」を提案するけれど、みんな正解がわからないから、何を指針にするべきか迷っていたんですよ。それを、「まずはスクラムガイドを遵守する」という方針ができて、メンバーの認識を合わせられるようになったことで、相当に動きやすくなりました。

日高:私が読み合わせで良かったと思うのが「これはスクラムガイドに書いてあるから、その内容を守る」「これは書かれていないから、私たちが話し合って決める」という感じに、定められていないことを明確化できたことですね。

――スクラムガイドの読み合わせを実施したのは、どのような意図があったのですか?

角谷:みんなが話してくれたとおりで、スクラムイベントに参加して話を聞いているうちに「スクラムの解釈が、チームとして定まっていないんじゃないか」と感じたんですよ。そこで、全員の認識を合わせる目的で、スクラムガイドを1行ずつ読んでいくことにしました。

スクラムガイドは、先人たちの実践が蓄積された集合知です。特に2020年11月版は非常によくできているので、スクラムガイドを中心にチームの認識を合わせて、実践を重ねていくことが大切です。

なかには、スクラムガイドの記載内容を一部分だけ取り入れてしまう開発チームもあります。でも「チェリーピックしてはならない」ことが、まさにスクラムガイドに書いてあるんですよね。記載された内容をそのままやることで、スクラムの成功確率が高まります。スクラムの基礎をみんなで理解するために、スクラムガイドの読み合わせを実施していきました。

日高:余談ですが、たとえスクラムの知識があっても実際にチームに導入するのは一筋縄ではいかないと、Algoageに来てから痛感しています。こういった地道な取り組みが、チームにスクラムの考え方を浸透させるうえで重要だと感じました。

メンバー同士の信頼関係を生み出すために

――スクラムガイドの読み合わせ以外にもさまざまな改善を行ったと思いますが、印象深いことはありますか?

纐纈優樹

纐纈:開発者としてつらかったのが、組織体制の変更がかなり激しかったことです。スタートアップなので、急ピッチでいろいろなものを変えなければならないのは仕方がないんですが、かつてのAlgoageは0を100にするくらいのレベルで日常的に体制を変えていたんですよ。そこに適応していくのが大変でした。

大変な状況のなかで体制の改善についての議論をすると、メンバー同士で意見がぶつかります。体制変更に関する混乱や不満があるので、雰囲気が険悪になるんですよ。今はこうしてみんなで和やかに、ポジティブなこともネガティブなことも振り返れていますが、当時はミーティング中にメンバーの意見がバチバチにぶつかり合うこともありました。

それに疲れてきて、だんだんと「ミーティングなどで意見を言うのをやめようかな」という気持ちになっていました。でも、日高さんがメンバーと雑談をする1on1を開催するようになって、そこからチームの雰囲気がかなり良くなりました。

1on1では、日高さんが「今の状況、ぶっちゃけかなりつらくないですか?」と踏み込んだ質問をしてくれて、それが「他の人たちに本音を話してもいいんだ」という心理的安全性につながったと思います。

角谷:1on1を実施したのは2022年の末くらいですよね。アドバイザーになってからしばらく経って、だんだんと良くなってきたけれど「チームワークをどうやって生み出すか」が課題だという話を日高さんたちとしていました。

私が立てていた仮説は「そもそも、会話の量が足りなくて信頼関係を生み出せていないんじゃないか?」ということでしたね。だから、目的を決めずに雑談をしましょうとアドバイスしました。すると日高さんが「メンバー全員とやります」と言ってくれました。

日高:全員との1on1は本当に良かったですね。信頼関係が生まれましたし、みんなもつらく感じているんだという目線合わせができたのは良かったです。

それと併せて、とても申し訳ないですがCTOの安田さんにスクラムイベントから外れてもらうことにしました。安田さんはその立場上、開発者の帽子やプロダクトマネージャーの帽子ではなく、どうしても「神様の帽子」をかぶった状態の発言になってしまいます。

それに、何かの施策に取り組む前にメンバーのことを心配して、「○○を考慮していますか?」とか「○○が発生したらどうしますか?」というブロックをかけるところがありました。もちろんリスクがゼロになるに越したことはないですが、プロダクトの立ち上げフェーズではケアする必要性が低そうな指摘や、課題が抽象的すぎて具体的な方針を話し合うだけでも1時間近くかかりそうな指摘を投げかけられることが多かったです。

そのため「まずは小さく始めて、少しずつ軌道修正していく」というアジャイルの思想をチームに適用するために、まずは私たちを信じて任せてもらえないかと伝えました。これが結果としてうまくいったため、安田さんが「神様の帽子」を脱いでも私たちのスクラムチームは回っていくという信頼を得て、適切な権限委譲が達成されたのかなと思います。

良いプロダクトを作るための健全な議論ができている

――2023年に入ってからはどのような改善をしましたか?

角谷:スクラムのスプリントレビューに、カスタマーサクセスや営業などのステークホルダーを呼ぶようになりましたね。

若菜:角谷さんから「スクラムチームの外部のステークホルダーへの単なる進捗報告の場ではないから、双方向でコミュニケーションをしてほしい」とアドバイスしてもらいました。

日高:スプリントレビューでなるべくステークホルダーの方々にも発言してもらうために「この前に作ったあの機能って、どう使われていますか?」とか「この機能をリリースしてから売り上げは伸びましたか?」など、なるべく相手に質問をすることを心掛けています。

石塚:ステークホルダースクラムイベントに参画する前は、みんな自分自身の「開発業務」にばかり目が向いていました。でも、スクラムの体制が整ってきて他の部署の人とも意見交換をすることで「より良いプロダクトのあり方」を考えられるようになったと思います。

日高:他にもモブワークや業務の1つ持ち制限などを取り入れました。1つ持ち制限というのは、仮に5人いたら「5人で5つのタスクを並行で走らせる」のではなく「5人で1つのタスクに合同で取り組む」ということです。

若菜実農

若菜:モブワークを行うことで、みんなでナレッジシェアできるのが良いですね。それに、モブワークが始まる前や休憩の時間などに雑談もできますし、コミュニケーション不足が解消されるのが優れています。

石塚:チームとしてひとつのタスクに取り組む形になった結果、冒頭で挙げたレビューの遅延や業務の属人化などの課題が解消されました。私たちの開発組織ではリリースサイクルを計測しているんですが、作り始めてからリリースされるまでの期間が明らかに短くなりましたね。

纐纈:これまでずっと「メンバーが複数のタスクを並行で抱えていること」が課題になっていたものの、なかなか解消できませんでした。でも、モブワークや業務の1つ持ち制限を取り入れてから、それが改善しました。明確に改善速度が上がっていますね。現在は、良いプロダクトを作るための健全な議論がきちんとできている感じがします。

若菜:スクラムの改善を行う前までは、ポイント式で開発業務を管理していたことが示すように、主に“アウトプット”を見ていました。でも今は、どうやってアイデアを価値に変えるかという“アウトカム”を重視できるチームになったと思います。

日高:私もみんなと同じ意見ですね。スクラムガイドにもあるように、スクラムイベントは「検査と適応、透明性」のためにあると思っています。イベントで検査して、状況に適応していくことで透明性を上げていく。透明性が上がると、チームが何に困っているか、次に何をしなければならないかの目線が揃う。改善のスピードが速くなって、さらにスループットが上がる良いサイクルになりました。

開発者体験の向上とアウトカムの最大化

――今、角谷さんはどのような方針でアドバイススクラムの運用をしていますか?

角谷:前半パートで出ていた課題であるポイントや見積りについては、現在は業務の1つ持ち制限を行っており1つのプロダクトバックログアイテム(以下、PBI)に全員で取り組んでいることから、「見積りポイント」などを割り当てていない状態です。

では、見積りをしていないかというとそうではありません。スプリントで取り組むPBIは、リファインメントを通じてなるべく1スプリント以内で完成できる大きさにしています。つまり、PBIの大きさを見積もるのではなく、1スプリントで完成できそうな大きさに合わせてPBIのサイズを調整してほしい、と伝えています。といっても、スクラムガイドに「作業を行う開発者は、その作業規模の評価に責任を持つ」と書いてあることそのままですが。

モブワークによってチームとしてPBIを完成させるという形態に移行したので、プランニングでは細かいタスクへの分割はしていません。管理するタスクが無いので、タスク個別での詳細な見積もりもしていません。その代わり、日々のデイリースクラムやモブワークで「PBIを完成させるためにどう進めていくのか」という作戦をチームで話し合って決めてもらってます。

ユーザー向けに機能をリリースする期日については、プロダクトチームとステークホルダーとで対話してターゲットとなる日程を定めて、その期日に間に合うようにリリースの目的を達成できるようにスコープを調整しています。

目の前のスプリントよりも先の“計画”は、現状ではPBIの優先度を適宜メンテナンスすることで、プロダクトチームとステークホルダーとの間で合意できています。しかし、「なぜその優先度になるのか」という根拠づけやその透明性が足りていないと感じています。スプリントゴールとプロダクトゴールとの結びつきに課題があるような状況です。それらを、また次のステップとして変えていきたいですね。

――今後、さらに改善したい部分はありますか?

日高:私が個人的に掲げているミッションは、この組織を持続可能にすることです。たとえば、もし私がいなくなってもチームが円滑に回るように他のメンバーにもミーティングのファシリテーションなどをお願いしたり、私に直接来ていた問い合わせを、なるべくチームに対する問い合わせに変えられるようにツールを導入したり。それから、新しく来たエンジニアを受け入れる体制作りのために、みんながドキュメント作成などをがんばってくれています。そういった整備を続けていきたいです。

纐纈:開発生産性はかなり安定したんですが、「良いプロダクトを作れているか」については改善の余地があると感じています。先ほど角谷さんも言ってくださったように、プロダクトとしてのゴールとスプリントとしてのゴールのひも付けに課題があります。機能をただ作るだけの、フィーチャーファクトリーの部隊になってはならないと感じており、オーナーシップを持って取り組めるチームにしていきたいです。

日高:たまに他部署の人たちの話などを聞くと、「本当は○○の機能を改善してほしいんだけれど、今は我慢してマニュアルを整備したり現場のオペレーションでどうにかしたりしている」といった意見をもらうことがあるので、そういった課題も解消したいですね。

角谷:みなさんが言ってくれたとおりで、開発体制は整ってきたものの、良いプロダクトにしていくにはまだまだ足りないことも多いです。中長期的なゴールを達成するためにはプロダクトチーム以外のチームとも力を合わせなければならないので、企業全体としての組織的な整備も行っていく必要があります。かなり良い流れになっているので、今後も組織をより良くしていく仕組み作りができるとベストですね。

――まとめとして、スクラムプロセスの改善を行う意義について、みなさんからコメントをいただきます。

日高:私は開発チームの人たちがすごく好きなので、その人たちが苦しまないで、楽しく、成長できる環境を作ることに全力を注ぎたいと思っています。そのための手段を常に模索して、ゴールに向けて進みたいです。

石塚:スクラムプロセスの改善に挑戦することで本質的な業務にみんなが注力する時間が増えるとか、話し合いをするためのベースができます。だからこそ、取り組む価値はとても大きいと思います。

若菜:個人的には、開発者体験がとても良くなったと感じます。個々人がタスクを抱え過ぎているとか、コミュニケーションをうまく取れないとか、レビューがなかなか進まないといった課題を仕組みとして解消できました。アウトカムを最大化するための手段として、すごく有効です。

纐纈:他の人たちが話しているとおりなんですが、開発者体験が向上することや本質的な価値と向き合えることなどが魅力です。エンジニアたちが前向きに働けるようになるし、機能を作ったけれど誰にも使われなかったなどの事態が起きにくくなるのが、大きな利点だと感じます。

「OSS開発に取り組む人たちを目にして、モチベーションが大きく上がった」RubyKaigi運営者・参加者対談

2006年からほぼ毎年、日本で開催されているオブジェクト指向スクリプト言語Rubyに関するイベント「RubyKaigi」。今年は長野県松本市にある「まつもと市民芸術館」で5月11日〜13日に開催され、参加者1,200人を超える盛況のイベントとなりました。株式会社Algoageのエンジニアである石塚大策と纐纈優樹は「RubyKaigi」に参加し、多くの学びがあったといいます。

今回は石塚と纐纈に加え、Algoageでスクラムマスターを務め2017年〜2019年のオーガナイザーでもあった日高尚美、第1回の「RubyKaigi 2006」から運営に携わる角谷信太郎さん*、「RubyKaigi 2015」からチーフオーガナイザーを務める松田明さんにインタビュー。「RubyKaigi 2023」の感想や参加する意義などを語り合いました。

*…角谷さんは、株式会社Algoageでプロダクトチームのアジリティ向上のためのアドバイザーとしてもご助力いただいています。

Rubyに携わる者にとって“お祭り”のようなカンファレンス

――まずは、Algoageのメンバーに簡単な自己紹介と「RubyKaigi」に参加した理由をお聞きします。

石塚:私は前職とAlgoageで合計3年ほど機械学習のエンジニアとして働いた後、直近の1年ほどはRuby on Railsを使ったサーバーサイド開発とAWSを使ったインフラ構築に携わっています。「RubyKaigi」に参加した経緯としては、Rubyについての理解が徐々に深まっていくなかで、Rubyそのものを作っている人たちに興味が湧いてきたためです。

また、社内で『メタプログラミングRuby』の読書会を開催しているんですが、この本に出てくる「プログラムを生成するプログラム」という概念は、これまで自分が機械学習に取り組んできた過程で見たことのない考え方でした。Rubyの言語仕様がすごく面白いと感じて、今回カンファレンスに参加しました。

さらに言うと、AlgoageはRubyコミッターの卜部(昌平)さんに業務委託として参画していただいており、一緒に仕事をするなかで卜部さんのレベルの高さをひしひしと感じています。それもあって、Ruby周辺のコミュニティに対して興味が湧いたので参加しました。

石塚大策

松田:ちなみに余談を話すと、Rubyコミッターの私から見ても卜部さんは次元が違うくらいRubyに詳しいです。石塚さんの意見には完全に同意ですね。

石塚:卜部さんってやはりすごい人なんですね。

纐纈:私も大策さんとほぼ同じ経歴です。もともと会社がAIに取り組んでいたため機械学習エンジニアをやっていましたが、事業を方向転換してWebアプリケーションを作ることになったので、Rubyを始めました。大策さんと同じようにサーバーサイドとインフラを担当しています。

「RubyKaigi」への参加を考えた経緯も大策さんと近いので省略しますが、それに加えて日高さんがもともと「RubyKaigi」の運営に携わっていたメンバーであることも影響しています。あるとき日高さんが「『RubyKaigi』に行ってみるといいんじゃない?」と言ってくれて、確かに面白そうだなと思って参加しました。

――日高さんからも簡単な自己紹介と、2017年〜2019年に「RubyKaigi」の運営に携わっていた理由を教えてください。

日高:私は大学で情報系を専攻していて、新卒でクックパッドにエンジニアとして入社しました。その後、紆余曲折を経てAlgoageに入り、スクラムマスターを務めています。「RubyKaigi」の運営に携わっていたのはクックパッド時代です。クックパッドOSSに力を入れている会社で、優秀なエンジニアの方々と一緒にOSSに貢献する「OSSコミットデー」という日がありました。

そのイベントの際に「クックパッドの若手のメンバーを『RubyKaigi』の運営に混ぜたい」ということで一本釣りされて、3年ほどお手伝いをしていました。「RubyKaigi」の運営に携わるのは本当に楽しかったので、大策さんや優樹さんに「『RubyKaigi』はお祭りみたいなカンファレンスだから、行ってきたら?」と送り出しました。

Matz is nice so we are nice

――他の技術カンファレンスと比べて、「RubyKaigi」はどういった特徴のあるカンファレンスだと思いますか?

日高:参加者がすごく多様だと感じます。「RubyKaigi」の黎明期からカンファレンスに携わっている人もいれば、若い方々も参加していますし、年代も国籍も人種もさまざまです。

松田:ちなみに今年は38カ国から参加者が集まりました。

――38カ国は確かに多いですね。

石塚:私は今まで機械学習系や画像処理系の学会には参加したことがあったんですが、プログラミング言語のカンファレンスに参加するのは初めてでした。最初にMatzまつもとゆきひろさん)のKeynoteを視聴し、「Matzって実在していたんだ。こんなすごい人が目の前にいるんだ」という気持ちになって、感動しましたね。

纐纈:私も技術カンファレンスには初参加だったので他との比較は難しいんですが、参加前は「わりと厳粛な雰囲気なのかな」と思っていたら、良い意味で全く違いました。

かなりカジュアルな雰囲気ですし、会場内を歩いている人がウキウキしていて。私たちのような新参者に対しても優しい雰囲気を感じました。それから、Rubyコミュニティ内の著名人が普通にその辺りを歩いていたので、すごい場だなと思って見ていましたね。

角谷:2人が言ってくれた雰囲気は、昔からですよ。私も「RubyKaigi」を最初に手伝ったとき、会場に行ったら「すごい人ばっかりだ!」と思ったんですよね。メーリングリストでしか拝見したことのなかった人が会場に山ほどいて、感動したのを覚えています。

その頃に私が受けた衝撃と、同じものを2人は感じたんでしょうね。良い意味でのカジュアルな雰囲気も昔からそうだし、スポンサー企業に対しても、お客さまというより一緒にやっていく仲間として接しています。

角谷信太郎さん

松田:私は角谷さんの後を引き継いで3代目の「RubyKaigi」のチーフオーガナイザーをやっているんですが、角谷フォロワーなので、昔からのRubyコミュニティの良さを損なわないように気をつけています。かつて、私が最初にRubyコミュニティに入ったとき角谷さんやRubyコミッターの笹田(耕一)さんなどが温かく迎え入れてくださって。その雰囲気がすごくRubyコミュニティらしいと思っています。

その原動力になっているのが、たぶんMatzなんですよね。「Matz is nice so we are nice」という言葉がありますが、本当にそのとおりだと思います。要するに、MatzはRubyという世界のピラミッドの頂点にいる人で、立場的には暴君のように振る舞ってもいいはずなんですが、本当に超いい人なんですよ。彼がNiceな存在だからこそ、それに影響を受けてみんなもNiceになるという、不思議なコミュニティですね。

OSSの開発者が、自分の書いたコードを自分の言葉で語る場

――「RubyKaigi」で印象に残っているセッションはありますか?

石塚:どれも面白かったですが、特に興味深く聞いたのが「Optimizing YJIT’s Performance, from Inception to Production」や「"Ractor" reconsidered」ですね。私たちAlgoageは「DMMチャットブーストCV」というサービスを作っているんですが、ユーザー数が徐々に増えているなかで、処理の高速化や大量にリクエストをさばくことなどに関心が強まってきました。だからこそ、これらのセッションは特に勉強になりました。

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

纐纈:私が印象に残ったセッションは3つあって、まず「The future vision of Ruby Parser」。スピーカーの金子さんの話術がすごかったです。Parserってかなり難しいことをしているはずなのに、とてもわかりやすく説明してくれたんですよ。

それから大策さんも言ってくれた「Optimizing YJIT’s Performance, from Inception to Production」。処理最適化の内容そのものも面白いんですが、それに加えてセッションで語られていることの熱量と物語性がすごいことに感動しました。

あと「Implementing "++" operator, stepping into parse.y」も良かったです。スピーチの構成がきれいに練られていて、聞いていて面白かったです。そして、聞いているうちに「もしかしたら、自分でもOSSにコントリビューションできるかもしれない」という気持ちになって、モチベーションが上がりました。

角谷:そういう刺激がカンファレンスでは大事なんですよ。「自分でもやれるかも」と思えるのは素晴らしいですね。

纐纈:新しい感覚でした。

纐纈優樹

松田:石塚さんと纐纈さんからすごくいいフィードバックをいただけてうれしいです。他のプログラミング言語のカンファレンスでは、実はこういった体験ができないと思っているんですよ。「RubyKaigi」が何を他との差別化要素にしているかというと、Rubyオンリーイベントであることだけではなく、OSSの開発者たちにスポットライトを当てていることなんです。要するに、OSSの開発者が、自分の書いたコードを自分の言葉で語るイベントって他にはあまりないんじゃないかと思います。

彼らにとってRubyは仕事に使う道具ではなくて、趣味で遊ぶおもちゃです。だからこそ「プログラミングは最高」という気持ちがあふれ出ているトークが多くて、それが参加者の方々にも伝わっているんでしょうね。

Rubyでつながる交友の輪

――会場内でさまざまな人と会うことも「RubyKaigi」の魅力ですが、そうした点で印象的な出来事はあるでしょうか?

角谷:「人と会う」という観点だと、展示ブースのスタンプラリーは日高さんの発案ですよね。

松田:おおー、そうでした! まず、スタンプラリーのことを説明すると、そもそも「RubyKaigi」は会場にいる全員がRubyコミュニティの仲間であり、スポンサー企業もそうだと思っています。だからこそスポンサーのみなさんにも、ただお金を出すだけではなくて何かしらお祭りを一緒に盛り上げていただくような関わり方をお願いするんですが、そのひとつがスタンプラリーですね。

会場の受付のところで参加者にスタンプラリーの用紙を配って、各企業のブースを巡ってもらいます。参加者とスポンサーの方々との会話のきっかけにしてもらうためです。そしてすべてのブースのスタンプを集めると、運営チームから景品がもらえます。

――その発足に日高さんが関わっていたのですね。

日高:別の技術カンファレンスでスタンプラリーをやっていて、それがすごく好評だったそうなんです。そこで、運営会議のときに「『RubyKaigi』でもやってみましょう」と提案しました。スタンプラリーを最初に実施した2018年の仙台開催のときにすごく好評だったので、恒例の取り組みになりました。

日高尚美

松田:イベント会場で出会うといえば、今年は「#rubyfriends」*が印象的でした。角谷さんはたくさん写真を撮っていましたよね。

*…技術カンファレンスの会場で会ったRubyコミュニティの方々と親睦を深め、その様子を「#rubyfriends」というハッシュタグをつけてSNSに投稿すること。

角谷:本格的に大勢の人たちが対面で会う「RubyKaigi」は久しぶりだったので、みんな #rubyfriends のことを忘れていそうだと思いました。そこで、「RubyKaigi」が始まる前の日に、emorimaさんやあちゃさんと「みんなで『#rubyfriends』をやって盛り上げましょう」と相談したんですよ。最初は私たち3人だけしかやっていなかったんですけど、だんだん他の人もやってくれてタイムラインがにぎやかになりました。

「RubyKaigi」は“旅行”の側面を持っている

――開催地での観光や食事も「RubyKaigi」の醍醐味です。

纐纈:「RubyKaigi」の会場では松本市名産のリンゴジュースやお菓子が無料で楽しめるようになっていて、それにまず感動しました。それから「RubyKaigi」の参加者には地元のお店で使えるクーポン券が配られていて、開催地域の活性化にも貢献しているんだと感じましたね。松本市はご飯がおいしくて景色もきれいで、大策さんと一緒に感動していました。

石塚:何種類か地酒を飲んだんですが、どれも最高でした。

纐纈:大策さんは地元名産のおそばを無限に食べていましたね。

石塚:いろいろなお店で、ひたすらおそばを食べていました(笑)。本当においしかったです。

松田:まさに、そういった楽しみ方をしてほしくて全国各地で開催しているのでうれしいです。

松田明さん

日高:おいしいものを食べるのって幸せじゃないですか。だから「RubyKaigi」の運営に携わっていた頃にも、食事には全力でこだわりましたね。会場にケータリングを発注する際には、業者の方に「地元名産の食材を入れてください」というお願いを毎回していました。

角谷:私が特に感動したのは水ですね。松本市は、名水とされる湧水が町中にあるんですよ。その湧水の井戸が市内に20カ所くらいあって、ほとんどの場所に足を運びました。

松田:お酒ではなく井戸水を飲み比べるのが、松本市ならではの飲み歩き体験ですね。クーポンに関して触れると、2022年に三重県の津市で開催した際に、ローカルオーガナイザーのuskeさんが商店街の人に話をつけて、地元の飲食店で「RubyKaigi」の参加者を優遇してくれる仕組みを実現したんですよね。それが、すごく評判が良くて。

三方良しの取り組みじゃないですか。1,200名以上の参加者が地元の飲食店で安く飲み食いできる。飲食店の方々はお客さんを誘致できる。「RubyKaigi」の運営側もイベントが盛り上がってありがたい。良いことずくめなので、今年も実施しました。地元の飲食店の方々に「新型コロナウイルスの影響でなかなか客足が戻らなかったけれど、『RubyKaigi』の期間中に大勢の人が来てくれて、活気が戻ったよ」と、喜んでもらえましたね。

角谷:「RubyKaigi」が終わった次の日に松本市で飲み歩いていたら、店のマスターに、「お兄さん、Rubyの人? 来年は那覇市でイベントが開催されるんだって? 頑張ってね」と言ってもらえました。町の人たちに認知してもらえたのはうれしかったですね。

毎日の生活にポジティブな影響がある

――「RubyKaigi」の参加前と後とで、価値観の変化はありましたか?

石塚:Rubyという言語への理解が深まっただけではなく、やる気が向上したのが一番大きいです。登壇者のみなさんが楽しそうに自分の書いたコードの話をしているので、自分もそうなりたいと思いました。「RubyKaigi」に参加した後は仕事以外でも毎日コードを書いて、必ず1日1コミットは積むようにしています。

纐纈:私もポジティブな影響が多かったです。まず、当たり前なんですけど、Rubyについての知識がすごく増えたこと。参加前にはRubyについての理解が浅い状態だったのに、カンファレンスで内部的な処理の流れやデータ構造なども学ぶことができたので、数日間でかなりの情報を得ることができました。

それから、モチベーションはかなり上がっていて、自分も登壇者の方々のようにレベルの高いエンジニアになりたいと思いました。OSSにコントリビューションできるように、GitHub上にあるRuby on RailsリポジトリのIssueやPull Requestを毎日見るようになりました。好きな言語でコードを書くのって楽しいじゃないですか。だから日々の仕事が楽しくなりました。

それから、個人的に大きな変化なのが、外の世界とつながりたくなったこと。コロナ禍の影響もあって、あまり外部のコミュニティには参加してこなかったんですよ。でも「RubyKaigi」に足を踏み入れてみると、Rubyを好きな人たちが、楽しそうにRubyの話をする世界がありました。それを体験して本当に面白いなと思ったんですよね。「RubyKaigi」後は、積極的にエンジニアの方々とのつながりを作るようになりました。

――Rubyを用いたプロダクト開発に携わる人が「RubyKaigi」に参加することの意義はどのような点だと思われますか?

日高:Rubyの裏側にRubyを作っている人たちがいると知ることで、気持ちが芽生えます。それから、会社のなかだけではなくて広いコミュニティとつながることができます。私の場合は「RubyKaigi 2017」の際に、すごく印象的なことがありました。

当時の私は、イベント最終日の翌日にクックパッドの同僚と開催地の広島を観光して帰ろうと思っていたんです。すると、Rubyコミッターの西嶋悠貴さんが急きょ参加してくれて、一緒に観光できました。この例のように、Rubyを好きな方々とのつながりができる、良い場だと思います。

石塚:特定技術の裏側の仕組みを理解することは、より良いサービスを作ることにもつながります。普段なかなか目にすることのない高度な技術に触れられる機会として、「RubyKaigi」は有意義な場です。

角谷:ぜひ次回も来てもらいたいですし、「RubyKaigi」以外にもRubyコミュニティがたくさんあるので、顔を出して知り合いを増やしたり、登壇したりしてもらえるといいなと思います。

松田:Asakusa.rb*にもぜひ来てくださいよ。大歓迎です。

*…毎週火曜日の夜に、東京下町周辺のRuby技術者たちが集まって何かをハックする地域Rubyistコミュニティ。

次回の「RubyKaigi」に向けて

――最後にみなさんから、来年に沖縄の那覇市で開催される「RubyKaigi 2024」に向けての意気込みをお願いします。

「RubyKaigi 2024」は、沖縄の那覇市にある「那覇文化芸術劇場 なはーと」で実施されます。沖縄の海底を模したデザインの、美しい色合いの会場です。

纐纈:次回も絶対に参加します。今回はちょっと真面目過ぎるスタンスで参加してしまったので、遊び足りなかったという後悔があります。次回は肩の力を抜いて、がっつり遊びに行く気持ちで参加したいです。

石塚:私も沖縄がとても楽しみですし、ぜひ参加したいと思っています。

日高:「RubyKaigi」はどんな方もウェルカムなイベントなので、この記事を読んでいる方もぜひ来てください。

石塚:来年は日高さんも行きますか?

日高:行きたい。優樹さんや大策さんは、イベント運営にも関わったらいいのに。

角谷:参加する以外にも、セッションのプロポーザルを出すという関わり方もあります。そういったことにも、ぜひチャレンジしてほしいです。今回のインタビューでみなさんが話してくれたように、「RubyKaigi」に参加したことで仕事やプログラミングが楽しくなったと言ってもらえると、やはりイベント運営をやっていてよかったと思います。

松田:そうですね。「RubyKaigi」は参加していただくだけでもとても楽しいとは思いますが、他にもいろいろな関わり方があって、それぞれ違った楽しみが味わえます。やっぱりみんなの前で登壇していただくのが一番の花形なのでそこはぜひ目指してほしいですし、運営に携わってくれるメンバーも絶賛募集中なので、興味を持たれた方はご連絡ください。今後とも「RubyKaigi」をよろしくお願いします。来年は那覇でお会いしましょう!

生成AIやLLMで切り拓く、次の時代の「当たり前」となるプロダクト。Algoage経営陣が見据える事業の山嶺

株式会社Algoageは2018年に、東京大学機械学習の研究をしていたメンバーが創業しました。創業当初はAIの受託開発から事業を開始。その後、2021年にSaaSプロダクトの自社開発へと大きく舵を切り、現在は新規顧客をコンバージョン(CV)へと導くことに特化したチャットボット型広告サービス「DMMチャットブーストCV」に注力しています。

Algoageの経営の根幹を支えるのが、CEOの横山勇輝とCo-founder & CTOの安田洋介です。Algoageが何を目指しているのか、そしてこの環境で働く意義は何かなどを、横山と安田に聞きました。

お互いに背中を預けられる心強いパートナー

――横山さんと安田さんがそれぞれCEO・CTOとして注力している業務についてお話しください。

横山:CEOという立場なので、業務としては「この会社の経営に必要なことすべて」にはなります。少し前まで私はCEOではなくCOOとして事業の立ち上げにコミットしてきましたが、現在は各部門やBizDevのメンバーに事業成長を一通り任せられるようになってきたため、現場からは少し離れ、事業に対してよりレバレッジが効く業務に時間を割くようにしています。

なかでも直近は、未来を描き、それを事業の中長期的な戦略に落とし込むことに注力しています。特に、生成AI領域の進化は重要な鍵になると考えており、CTOの安田だけでなく私自身も具体のプロジェクトに参加しています。

あとは、やはり採用ですね。手前味噌ですが、今かなり面白い事業を、非常にいい環境で、素晴らしい仲間と共にできているので、その魅力をちゃんと伝えていきたいです。

安田:CTOとして私が取り組んでいるのは、テクノロジーを軸として経営を最適化することです。現在のAlgoageは、プロダクトマーケットフィットができており事業拡大しているフェーズです。企業のフェーズに応じてCTOがフォーカスする業務は変わるものですが、いまは中期の経営戦略の立案や開発組織の編成・拡大、プロダクト・技術の戦略立案・実行に注力しています。

また、大規模言語モデル(LLM)や生成AIなどの最新技術をプロダクトに取り込んで活かすための研究・開発にも投資しています。リサーチをして市場のニーズや技術進化の動向を把握したり、さまざまなプロダクトをPoC的に開発して技術的な検証をしたりといったことをやっています。これらの施策を進めるためにも、組織としてのスケーラビリティを担保するためにも優秀なメンバーが必要なので、現在は採用活動に最も力を入れています。

――横山さんと安田さんは、それぞれお互いの強みや特性がどのような点にあると思われていますか?

安田:横山はまず、人を惹き付ける力が強いと感じています。ものすごく頭が切れてロジカルシンキングが強いのに、実はいじられキャラなんです(笑)。人間的なバランスの良さがあります。事実として前職の上司をAlgoageで採用できたのですが、その人は転職の理由を「横山さんの熱意に惹かれたことが一番の理由」と言っていました。

また、良い意味で技術やプロダクトに対する期待値がかなり高いです。横山自身ももともとAI研究やアプリ開発をしてきたバックグラウンドがあるので、技術で社会をもっと良くしていきたい・よくできるはず、という思いが強いからでしょうね。逆に言えば横山から要求される水準も高いですし、チャレンジングな課題にぶつかる場面も多いですが、CTOとしてはかなりのやりがいがあります。

他にも、これはAlgoage社員全員の特徴でもありつつ特に横山が持っている強みですが、学習意欲や成長力が圧倒的です。いまのAlgoageは、事業のやり方をどんどん最適なものにアップデートしていかなければならないフェーズです。だからこそ、横山の強みが企業経営において明確に活きています。

横山勇輝

横山:安田は、すごくシンプルに言ってしまうと天才ですよね。物事の本質を見極めて、中長期的な将来に起きることを的中させてしまう力があります。私とは全く違うアプローチでなぜか答えにたどり着いてしまうので、「どうしてこんなことができるんだろう」と驚く瞬間が多々あります。

技術的に難しい挑戦をするときや大規模なプロジェクトを進めるときは、困難がつきものです。そんなときでも「安田が絶対に突破してくれる」と思えるので、大きな夢を描けます。お互いに補い合う関係ですよ。私が企業としての長期的な計画を立てたり現場を動かしたりしつつ、安田がみんなを率いて大変な状況を突破してくれる。CEO・CTOとして適切な分担ができていると思います。

それから、技術だけではなく事業についても深い理解があること。同じ目線で経営についての会話ができるのは、私としてはありがたいですし信頼しています。お互いに本音で心地良く話して、経営が進むという関係性ですね。

テクノロジー時代の「当たり前」を生み出す

――企業として掲げるミッションや事業ビジョン、バリューについてもお聞きします。ミッションは「テクノロジー時代の『当たり前』を生み出す」、事業ビジョンは「誰もが簡単に、最良の意思決定ができる世界」ですが、これらの根底にある考え方を教えてください。

横山:ミッションの「テクノロジー時代の『当たり前』を生み出す」について話すと、私たちの世界で、30年前にはまだインターネットが一般家庭に普及していなかったことが信じられないくらいに、テクノロジーは世の中を変えましたよね。これからの30年にも同じくらいのレベルの変化が起きると想定すると、人類の進歩はすさまじいです。

特にここ10年強は、スマートフォンクラウドコンピューティングの普及で、テックスタートアップが活躍する土壌が整ってきました。スマートフォンが登場によりあらゆる人が日常的にインターネットの世界に参加したことで、ネット上にサービスを公開すれば、巨大な市場にアクセスができるようになりました。また、クラウドコンピューティングが普及してサービスの立ち上げや起業のハードルも低くなり、学生が創業した会社が世界的に有名になるようなことも、夢物語ではなくなっています。

このように“テクノロジー時代”では、限られた人だけが大きな力を持っているのではなく、誰もが世の中を変えるチャンスを与えられています。そしてそのチャンスは、30年前にインターネットがなかった時代から今を眺めるような、もしかしたらそれ以上の急激な変化を世の中にもたらす、非常に大きなものです。そんなチャンスが目の前に広がっているならば、チャレンジしないのはもったいないですよね。今このような“テクノロジー時代”にいるからこそ、「誰もが使っているような、未来の当たり前になるサービスを作っていきたい」という思いをミッションに込めています。

ミッション・ビジョン・バリューとは別に、ゴールも設定しています。これは10年以内に達成したい定量目標で「売上1,000億円級の事業を創る」ことです。私たちDMMグループの企業が共通して持っている特徴でもあるのですが、社会に大きなインパクトを与えるためには、テクノロジーを活用して価値のあることをやっていくだけではなく、ビジネスとしても成功しなければ、その価値を広く社会に広げることは難しいと考えています。それをゴールに込めました。

安田:事業ビジョンの「誰もが簡単に、最良の意思決定ができる世界」についてもお話しすると、テクノロジーの進化の転換期になった「コンピューター」「インターネット」「スマートフォン」の登場によって、人間の意志決定が加速したと考えています。

まずは計算機としてコンピューターが登場して、意思決定のために必要だった複雑な計算を一瞬でできるようになりました。そして、先ほど横山が言ってくれたようにインターネットやスマートフォンの登場によって誰もがいつでも情報にアクセスできるようになり、さらに意志決定が楽になりました。

でも、あらゆる人が幸せになれるような満足度の高い意思決定をできているかというと、そうではありません。なぜかというと、意思決定はすごく知能的な行為なんですよね。正しい選択をすることは難しいですし、これまではその行為を助ける機械に限界があったので、意思決定を最適化しきれていませんでした。

これに対し、AIの進歩がこの状況を変える鍵を握っていると考えています。コンピューターの知能レベルが上がることによって、より良い意志決定ができるようになる。そこにチャンスがあるはずだというのが、事業ビジョンとして「人の意思決定」の領域に注力する理由です。

横山:これまでの技術進化でさまざまな情報が手に入るようになりましたが、情報があふれているからこそ、自分が納得のいく、良い意思決定をすることは逆に難しくなっていると感じます。

たとえば転職など、人生に関わる大きな意思決定をするときは、どんなに情報を調べても、自分に必要な情報のみ取捨選択したり、自分に合わせて適切に解釈したりできなければ、良い意思決定はできないですよね。実際に、私が転職を決意したときは「自分をちゃんと理解してくれている信頼できる人が、自分に寄り添ってアドバイスしてくれたこと」が重要だったと思います。

今は、「より良い意思決定をできるか」は、そんなアドバイスをしてくれる人がたまたま身近にいたかどうかで決まってしまいます。それがもし、AIにもできるようになったらどうでしょうか?

意思決定に困ったとき「誰もが」利用でき、いつでも手軽に「簡単に」相談できるAIコンシェルジュです。人がやっているように、相手に寄り添い、必要な情報を提供しながら、時には背中を押して、本人が納得いく意思決定に導くことがAIにもできれば、その人の人生を幸せにするような「最良の意思決定」を実現できます。そんな未来を私たちは実現したいと思い、「誰もが簡単に、最良の意思決定ができる世界」というビジョンを掲げています。

そして、直近LLMの領域で起きているブレークスルーは、「自然言語からユーザーを理解し、寄り添い、パーソナライズする」と言った、まさに「最良の意思決定」にとって核となる技術進化です。だからこそ、今この領域に取り組むことに強くチャンスを感じています。

――バリューの「全員、リーダー。」についても、教えてください。

「全員、リーダー。」のバリューに、5つの行動指針がひも付いています。

安田:Algoageでは現在、海外ユニコーンにも負けないスピードで事業が急速に成長しています。またミッション・ビジョンに向かっていくためには、今の事業だけでなく、どんどん新しく事業も立ち上げていくべきだと考えています。

急成長し、さまざまなチャンスにあふれるAlgoageだからこそ、チャンスを自ら能動的につかもうとするリーダーに全員がなることが大切ですし、そうやってチャレンジしていける人にとってAlgoageは最高の環境だと思います。事業を自ら推進し、事業と共に成長していける仲間を集める。全員が最大限活躍できる環境を作り、その活躍によってAlgoageがさらに成長する。そんな組織でありたいという思いを、バリューに込めています。

「DMMチャットブーストCV」は人の意思決定を支えるプロダクト

横山:「人間の意思決定」という観点でもう少し話すと、私は幼少期に人生を変えてくれた原体験があります。私がいまこの場所でこうして働けているのは、小学校4年生の頃に学習塾に行くことを決心したからだと、本気で思っているんですよ。

小学校の友だちがあるとき「横山君なら頭がいいから、うちの塾のAクラスに入れるよ」と言ってくれました。「そのクラスって塾のなかでどれくらいの順位なの?」と尋ねると、その友だちの1つ下のクラスだったんですよね。負けず嫌いなので当時の私はカチンときて、母親に「塾に行きたい」と頼み込みました。

でも、入塾時にテストを受けた結果、私は最下位のクラスからのスタートでした(笑)。今思えば、それが最初の大きな挫折経験でしたね。本当に悔しかったので、それをバネに必死に勉強しました。また「少しでも効率的に成績をあげられないか」と、自分の思考パターンを認識しハックしようとする癖がついたのも、この時からだったように思います。結果としてクラスはとんとん拍子で上がりましたし、その後もこの時に身につけた習慣に多々救われてきました。がんばれば報われる・やり方から考える、というこの成功体験があって、それをベースに成長意欲の強い私の人格が形成されたと思っています。

つまり、当時の友だちが悪気なく煽ってくれたことが、「塾に行く」という意思決定の背中を押し、そのたった一つの意思決定で私の人生は大きく変わりました。意思決定の支援をすることは、その人の人生を大きく変えるポテンシャルがあるという意味で、非常に価値あることだと考えています。

――「DMMチャットブーストCV」はまさに、人の“意思決定”を支えるプロダクトですよね。

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

横山:はい、「DMMチャットブーストCV」はさまざまな商材で、ユーザーの中にある不安や迷いをチャットの中で払拭し、モノの購入やサービス利用における意思決定の背中を押すプロダクトです。このプロダクトが扱う商材の一つである「学習塾」のコンバージョン(CV)で、人生が大きく変わった経験をした私としては、意思決定を支援するプロダクトとして個人的にも思い入れがありますね(笑)。

既存のWebマーケティング手法は、基本的に「全員に対して画一的な情報を見せるもの」という意味で「広く、浅い」体験をユーザーに提供します。一方、店頭に足を運べば店員が自分に合わせて接客をしてくれますが、対応できる人数は限られるので、リアルでの接客は「深いが、狭い」体験と言えます。そのいいとこ取りをして、「広いし、深い」接客体験を届けるのが、「DMMチャットブーストCV」です。

私たちは「DMMチャットブーストCV」を通じて、ユーザー個々人に向けて、パーソナライズされた情報をインタラクティブに見せるという手法を切り拓いています。ただ、まだまだ事業としては黎明期であり、これをテクノロジーでさらに良くしていくことが求められています。そのためのR&Dや新規事業開発に投資できる資金的な余裕や事業体制があり、かつ創業メンバーにもともとAIの技術の知見があることが、Algoageの強みになっていますね。

安田:「DMMチャットブーストCV」のビジネスを成功させるためには「ユーザーの納得感を高めて、背中を押すこと」に寄り添わなければなりません。Algoageはそのためのトライ&エラーを積み重ねてきたので、社内にノウハウがたまっているんですよ。これは他社には一朝一夕で真似できないと思いますし、今後AIなどを活用してプロダクトを高度化するうえでも役に立ってきます。

安田洋介

技術の進歩の本丸に挑める環境がAlgoageにはある

――最新技術の研究・開発を行うために、今後はどのような取り組みをしますか?

横山:CTO室やその配下の生成AI/LLM専任チームを立ち上げました。CTO室は、安田が担っている開発組織の拡大やプロダクト・技術施策の推進などの業務を複数名で担い、企業・事業の成長をより加速させることを目指しています。

また、LLMや生成AIなどの技術は、今後私たちの事業ビジョンを達成する上で重要な鍵になります。かつ、これは短期的な流行ではなく、インターネットの到来と同じくらいの長期的な影響をもたらすと考えています。だからこそ、自分たちで手を動かしたり情報のキャッチアップをしたりといった、技術的な投資を目的とした生成AI/LLM専任チームを立ち上げるべきだと考えました。

生成AI/LLM専任チームには、エンジニアだけではなく「DMMチャットブーストCV」のシナリオ制作部門など、全社からメンバーが参加しています。LLMの革命的なところは、従来の機械はエンジニアがプログラムでしか指示が出せなかったことに対し、自然言語での指示でも、AIがかなり柔軟に意図を理解し始めていることです。これによってエンジニアだけでなく、現場や業務を理解している非エンジニア職のメンバーも一緒になって、生成AI活用・探索を進めていくことが重要になってきます。

――さらに開発を加速するうえで、どのような職種やスキル、マインドのメンバーに参画してほしいですか?

安田:マインドとしては、やはりバリューや5つの行動指針にフィットする人が強いです。事業を自ら推進できる「リーダー」として行動指針に共感し、これを高いレベルで実践できる人が活躍している実感があります。

あとは事業目線で物事を考えられると同時に、技術を信じる気持ちも強く持った開発者にぜひ参画してほしいです。つまり、事業を成功させることを優先度高く考えつつも、技術やプロダクトの力で価値を出していくスタンスの人。自分がそれを実現していくんだと信じて業務に取り組める人に来てほしいです。

スキル面では、スピーディーにプロダクトをスクラップ&ビルドできる人は、いまのフェーズで特に必要としています。それから、生成AI/LLMなどのように、未知の技術の情報をキャッチアップして、アイデアを積極的に出せる人がフィットする環境です。

横山:職種としては、プロダクトマネージャーやUXデザイナー、ソフトウェアエンジニアなどが開発組織において特に必要です。さらに、生成AI/LLM活用という意味では、マーケティング系の職種で働いている方で、最新技術を用いて新しいマーケティング手法を生み出していきたい人にも来てほしいです。

――「いまのフェーズのAlgoageだからこそ経験できること」は何だと思われますか?

安田:描いている目標を実現するために、Algoageはこれからも急成長し続けます。スタートアップとしてどんどん変化していく環境のなかで価値を発揮するのは、それ自体が楽しいことだと思いますし、自分自身の成長にもつながります。

かつ、Algoageがスタートアップとしてのスピード・裁量を持ちつつ、DMMグループのリソースをレバレッジできる立場にあることは、他にはない明確な特長です。一般的なスタートアップでは資金不足が原因で、本来投資すべきことが制約されるケースがありますが、Algoageではそういったことがありません。余計なことを考えず、事業を伸ばすことだけに集中できる、なかなかない環境だと思います。

横山:生成AI/LLMによって、今後確実に世の中は変わっていくと思います。なかでも変化の度合い・影響範囲の大きさの観点から、「人の意思決定」の領域は本丸といえるのでは、と考えています。

Algoageはこれまでの事業で、人の意思決定に最も深く、広く関われる立場を築いてきました。まず、意思決定の背中を押すことに全力で投資できるビジネスモデルがあります。また、これまでの事業運営のなかで、さまざまな業界・商材において、人の心を動かすコミュニケーションに向き合ってきた知見・プロが集まっています。さらに経営陣も含め、AI開発への知見もあります。

人とAIが協働し、さまざまな意思決定の、“最良”を追求していける。そのための条件がこれだけ揃っている企業は他にないと思います。そしてまさに今、鍵となる生成AI/LLMの領域でブレークスルーが起こりつつあります。

事業ビジョンの「誰もが簡単に、最良の意思決定ができる世界」は、非常に大きなチャレンジではありますが、私たちが、今、やるべきことだと強く確信しています。生成AI/LLMの黎明期に、本丸の領域に本気で挑みたい人には、ぜひおすすめしたいです。