ROXX noteをご覧の皆さん、こんにちは！ ROXXの佐藤です。

本日は、プロダクト開発部門 agent bankチームを支えるエンジニア/松井さんにROXXへの入社経緯や、現在の業務についてお話しいただきます！

自己紹介

agent bankのおじさんエンジニア、松井 幸太（Kota Matsui）です。
自分がkawaiiくないおじさんであるという現実に耐えられず、kawaiiを追い求めてバーチャル世界に引きこもり、「夕暮おこは」を名乗って生活しています。

ーアカデミックな世界を出て、エンジニアとして働きはじめるまで

小学生の時に読んだ「化学便覧」に感銘を受け、物理学者を目指して図書館にこもる青春時代を過ごし、大学院まで物理の研究をしていました。
3年がかりで装置の設計と予備実験を行い、設計の報告をして国際学会で賞をもらえたりと順風満帆な研究者生活だったのですが、大学の予算の関係上、それ以上プロジェクトが進められなくなってしまったので、研究の道を諦め、博士課程を満期退学。その後、心機一転、自転車にテントや寝袋を積んで野宿旅に出ました。
予算20万程度、一日の支出1000円以内を目標に、公園で髪を洗ったり洗濯したり、100円マックと水を主食としながら、日本をあちこち見て回りました。とはいえ、結局装備が壊れ修理費用が賄えなくなってしまい、途中何度か日雇い労働も経験しながら、なんとか3年かけて、分割日本一周を達成できました。

旅の相棒二代目のランドナー。初代相棒のエスケープR3は酷使しすぎてフレームがずたずたになる壊れ方をしたので泣く泣く廃棄。写真は北海道の小清水原生花園にて。

ーエンジニアとしてやっていく覚悟

私が中学生の頃は、まだSNS（ソーシャル・ネットワーキング・サービス）というものも世の中に生まれていなかった時期で、インターネット上でお金をかけずに私事を公開するには自力で書いたHTML+CSSをホスティングするくらいしかなく、自己紹介とブログ記事を作ってレンタルサーバーに公開したのが初めてのコーディングでした。

そんな感じでスタートしたので、長らく自分ができるレベルのWebのコーディングなんていうのは、誰でもできるお遊びだと認識しており、大学では物理の研究者を目指して研究に専念していたのですが、日本一周のためのお金稼ぎでいろいろな場所で働いていくうちに、こんな子供のお遊びレベルですら世の中結構需要があることが分かり、楽しいことやってそれで食っていけるならいいなと思い、エンジニアとしてやっていくことに決めました。

旅を終えた後は、Webの受託制作の会社に就職しました。この会社で新たにフロントエンドの開発チームを組織することになり、採用・チームビルディング・教育・開発環境の整備などを行いました。

その後、自分のキャリアややりたいことを見つめ直すため、退職してしばらくニート生活を満喫していたのですが、親の視線も痛くなってきたので仕事を探しはじめたところ、ROXXにお声がけいただき、エンジニアとして入社しました。

ROXXとの出会い

物理研究の分野でも職を探してみましたが、装置の修理や保守・営業といった仕事ばかりで、興味を持つことができず、Webのエンジニアに絞りました。
採用面接では、各社の技術的なバックグラウンドと、その技術を採用した理由などを質問して回ったのですが、ROXXが一番合理的にしっかり考えていると感じられたことが、入社を決めた大きな理由でした。

ROXXへ入社して最初の仕事は、データのビジュアライゼーションでした。私がジョインした時点ですでにStorybookが導入されていたので、APIのスキーマだけ決めてサーバーの実装を待たずサクサクと実装をすることが出来ました。

Storybookを用いることでAPIやページの実装を待たず、
コンポーネントの動作だけに集中して実装を進めることができる

その後、前職で使っていたOpenAPIをチームでも使おうと提言し、OpenAPI Generatorと一緒にプロジェクトに導入しました。これによりこれまでエンドポイントを動かしてみるまで仕様が何も分からない状態だったのが、ドキュメントで可視化されるとともに、APIのスキーマ定義とTypeScriptの型定義を一致させられるようになりました。

実際に利用しているOpenAPIの一例。どのようなリクエストを送ればどのようなレスポンスが来るか分かるドキュメントとして機能するだけでなく、各言語へのモデル生成やAPIクライアントの生成、スキーマ適合テストなどが行える。

また、当時はチームメンバーのぎゃるさんが、Laravel用のテストモジュールを作ってくれたので、フロント・サーバーともにスキーマに適合しているか担保できる環境が用意出来ました。とはいえ既存のエンドポイント数が非常に多いため、現在もまだスキーマ情報を拡充中です。

昨年の大きな仕事としては、求人検索の検索エンジンのリプレイスを行いました。それまではMySQLの全文検索インデックスを利用していたのですが、特定の検索条件が重なるとデータベースに多大な負荷がかかる状態になっていました。検索インデックスをチューニングしたものの、根本的な解決には至らず、個人的に利用経験があったElasticsearchへの移行を提案しました。

データベースの負荷も抜き差しならぬ状態になっていたこともあり、チームメンバーも協力してくれたおかげで、β版を一週間でユーザーに提供、細かい不具合を修正して正式リリースを行い、大きな不具合も出さずに移行することが出来ました。検索の大幅な高速化だけでなく、負荷テストでも良好な結果を出しており、将来的にも安心できる状態にできました。こういった新技術へのチャレンジに対して、会社もチームメンバーも必要となれば一丸となって動けるのがROXXの良いところだと思っています。

旧検索エンジン（右のグラフ）では閾値を超えると実行時間が青天井に増加していたが、Elasticsearch移行後（左のグラフ）は急激な負荷上昇は見られなくなった

ーROXXの技術志向

ROXXの技術志向は、よく言えば自由です。技術面に対する強いガバナンスがなく、技術者に技術選定の裁量が広く与えられています。
また、エンジニアの志向は、全体的にトレンド志向が強く、トレンドになっている技術は何でも試してみるという傾向が強いかもしれません。

ーお互いを認め合えるカルチャー

全体で足並みをそろえることよりも、各々が全力で突っ走ることで前に進んでいくことが得意だと感じています。これは、エンジニアに限らずROXX全体がそういうカルチャーだとも感じています。

近年はチーム間の協力を見直す動きも出てきていますが、それにより前に進む力が抑制されるのは良くないよね、という共通認識を持っており、その辺りは良いバランスが維持されていると思います。

また、個人的に一番重要なこととして、ミーティングなどはいつもバーチャルの姿で参加してますが、怒られたことは一度もありません。バーチャルの姿での業務遂行ということは、受け入れ難い会社や環境もあるかと思いますが、異文化なオタクも受け入れてくれることは素晴らしいことだと思います。

今のご時世HMD無しでもフェイストラッキングとリープモーションで上半身の動きはトレースできるので、業務時間中でも身体的負担なくバーチャルの姿を維持できる。

ー自己成長を実感する

ROXXへ入社当時は、自分が何かに役立ち、それで食べていけるならそれでいいと思っていたので、何が得られるかについては何も考えていませんでした。
しかし実際のところ、入社時にはアジャイルの知識もなく、技術的にはフロントしかできませんでしたが、先輩たちにフォローしてもらいながら幅広い業務を経験させてもらったことで、サーバーサイド・インフラ・データ基盤周りなど一通り自走できるようになりました。また、現在は共通基盤設計ということでマイクロサービスアーキテクチャ・ドメイン駆動設計について学ぶ機会をもらっています。

ー入社してよかったこと

前職では新しいことに取り組もうと思ったら自力で学習するしかなかったのですが、ROXXではOJTやペアプロの機会が多く、実際の業務を通じて先輩たちから直接新しい技術を教わることが出来ました。
また、逆にまだチーム内で誰も扱ったことのない技術を導入する場合も、とりあえず一人しっかり勉強して運用フローを固めて運用してくのに必要なドキュメントを整理しておけば業務を通じて他のメンバーにも共有することができるので、新しい技術へのチャレンジもしやすく、先述のElasticsearchやdbt（data build tool）など多くの新技術を取り入れることができました。

agent bankを支えるプロダクト開発のミッション

ー私が取り組んでいる具体的な業務について

現在は、チーム開発から離れて共通基盤の整備を行っています。
agent bankは、元々モノリスのシステムとして構築されていますが、それゆえに変更の負担が大きく、新しい施策は、agent bankの外側の独立したシステムとして構築されることが増えてきています。
とはいえ、agent bankの持っているリソースなどと連携する必要も出てきたため、より汎用的でリソースの再利用が可能なアーキテクチャとしての共通基盤を整備していくことになりました。

アジリティを損なわず、それでいてシステムとしての安定感を維持できるよう、サービス間プロトコルやデータ基盤の整備などを行っています。
今のところ共通基盤チームは私一人しかおらず、技術選定からプロトタイプの作成と検証、運用フロー策定まで自分でやっています。

現在技術選定中のサービス間プロトコル

ー基盤構築で、私が大切にしていること

agent bankというプロダクトは様々なコンテキストのユーザーの業務が混ざり合う場であり、どうしても複数のコンテキストを持ったビジネスドメインが複雑に絡み合ってしまいます。
この状態で雑にシステム間を結合すると、あとから何かを変えたいとなった時に何をどうすればいいか誰にも分からない状態になり、壊しながら進むか、ちょっとずつ丁寧に進むか、のどちらかになってしまいます。
ビジネスドメインの複雑さを解きほぐし、各々のサービス、チームが自律的にアジリティを維持したまま新しい施策にチャレンジできるような基盤の実現を目指しています。

共通基盤周辺のサービス構成案の第一稿

もう一つの観点として、agent bankというシステムがあまりに複雑になりすぎており、新しく入った人がビジネスドメインとシステムの全容を理解するのにとても時間がかかるようになってしまっているという課題もあります。
この辺りもドメインの分割線を見直し、チームが可能な限り小さなコンテキストを把握するだけで済むような状態にリファクタしていく筋道を立てていきたいと思っています。

データ基盤の整備については、データに関するナレッジをエンジニアからビジネスメンバーに受け渡す、それを一人ひとり個別にではなく、新しく入ってきた人でもデータに対するナレッジが手に入るようになることを目標として構築しました。巷ではよく、みんなクエリを書けるようになろうみたいな標語を掲げているのを見かけますが、本質的な問題は、クエリという言語の習得ではなく、プロダクトの持つデータの意味や関係を誰でも理解できるようにすることだと思っています。

例えば、enum（文字集合に対応した数値データ）がテーブルのカラムに格納されていたとして、そのenumの定義がプロダクトのコードにしか書かれていないのであれば、どんなにデータを見てもその意味を理解することはできません。かといって、いくらテーブルに対するドキュメントを書いたところで、それがコードと乖離して保守されていなければ結局役に立ちません。

この辺りの課題感は、dbtを導入したことと、データウェアハウスの設計指針を決めたことで、ある程度担保できるようになってきたかなと思っています。今後もビジネスメンバーがデータを意思決定に利用できるような状態の維持を目指します。

データ基盤で提供しているデータはすべてdbtでデータの関係やカラムの意味などがコードと紐づく形でドキュメンテーションされ、誰でもデータの定義や流れを調べることができるようにした

ー目指すのは、多様なバックグラウンドが活かせる世界

目下一番重要なことは、agent bank全体のドメインモデルを構築することだと思っています。これは一回作り上げて「はい終わり」というものではなく、今後agent bankという事業全体の進化に合わせて成長していけるものでなければなりません。
現時点でのビジネスドメインにフィットするのはもちろんのこと、そのドメインモデルがきちんとビジネスレイヤーとコンセンサスが取れているものになり、ドメインモデルを更新していくことがbiz-devの共通認識になっている状態を目指します。
出来上がったドメインモデルの変化に追従できるようなアーキテクチャを作り上げ、いわゆるエンタープライズと呼ばれるような規模感になっても、スタートアップとほとんど変わらないアジリティを維持できるようにしていくことが今の私の目標です。

事業ドメインのコンテキストマッピングのひな形。まずは現状を把握したうえでビジネスドメインの変化に合わせて有機的に進化し続けられるアーキテクチャを目指す

現時点では一人で進めることに支障はないですが、中期的には属人化の観点や機動力の観点でも、私のようなことをする人をもう一人増やしたいと考えています。今のご時世なかなかモダンな大規模開発の経験が豊富な人に来てもらうのは難しいと思いますが、一緒に学び、成長していける仲間を探したいです。

ROXXのサーバーサイドはLaravelが主流ですが、今回、サービス間プロトコル検証の実験場として新しいサービスをGolangで作っています。サービスごとの適切な境界分離によって技術的多様性を維持することで、様々な技術的バックグラウンドを持った人を採用できるようにすることのみならず、例えば「今はPHPしか経験がないけどgoにもチャレンジしてみたい」といった人に、ステップアップのためのキャリアパスが提供できればと思っています。

エンジニアにとってagent bankが面白い理由

人材業界のビジネススキームでは、求職者と求人者という全く異なる二つのコンテキストが、選考という一つのコンテキストで密接に統合されます。ECにおける販売者と購入者が購入というコンテキストで交差することと比較すると、交差する密度が段違いです。
この複雑にコンテキストが交差するビジネスドメインの理解をせずに、技術視点でしか物事を見ていないままでは、まるで意味の分からないところから、意味の分からない変更を要求され続ける状態となります。小手先の仕様変更ならなんとかできるものの、ビジネスドメイン自体の本質的な変化に対応するには、影響調査の時点で大仕事になってしまい、結局は保守的な成長しかできなくなってしまいます。

要求されたことをシンプルに実現する方法を考えて実装するエンジニアにとっては、恐らくこの業界は面白いどころか苦痛なだけのものになるでしょう。しかし、ドメイン駆動設計を学び、複雑なビジネススキームをモデル化し、設計にしなやかさを付け加える術を学んだ人にとってはどうでしょうか？なかなかに挑戦しがいのあるビジネスモデルだと言えるのではないでしょうか。
ドメインモデルやユビキタス言語を作ったにも関わらず、いつの間にか放置されてるようなことは、ほとんどありえないでしょう。常にビジネスドメインに対し深い洞察を繰り返し、その時代、その時の組織の状態に合わせてドメインモデルの更新は繰り返されていくことになります。
折角分厚いエヴァンス本を読んでドメインモデリングの技術を学んだのに、役立てる機会がないと感じている人にこそ、ぜひ挑戦していただきたい分野です。
また、逆説的ですが、苦痛に感じる例として挙げたような人でも、自身が受け持っているドメインだけに集中して業務に専念できるよう、コンテキストの境界を明瞭にし、複雑な依存関係が生まれにくいようにしていくことが共通基盤チームのミッションでもあります。

ROXXが考えるスクラム開発

スクラムは、手段であって、目的ではありません。では、スクラムを利用する目的は何かと言うと、アジャイルの実現です。アジャイルを実現するためにスクラムが利用できる場合があるのであって、スクラムを使えばアジャイルになるわけではないし、スクラムを利用しなければアジャイルにならない訳ではありません。

私たちagent bankの開発チームがスクラムを採用する理由は、我々自身が、今この時このフェーズにおいて、スクラムの採用がチームにとって最もアジリティに寄与すると判断し、その判断にチームとして同意できているからに他ありません。自分たちで判断し自分たちで選び、自分たちで向き直れるこのスキームこそが、アジャイルの本質です。

例えば、先ほどElasticsearchへの移行を一週間で行ったことについて言及しましたが、この一週間とは、スプリントの一週間とは対応していません。データベースの負荷がのっぴきならないことになっていることが分かったのは、その週のスプリント開始後であり、既にスプリントゴールは別の機能開発に向けられていました。それでも緊急性を把握し、問題が生じた場合のユーザー価値への影響を考え、チーム全員で再検討し、もう既に始まっていたスプリントのスプリントゴールを破棄してまで、検索エンジン移行にチームとして集中することをチーム全員で判断しました。
Elasticsearchの実際のクエリ部分の実装は、確かに私が受け持ちましたが、それが出来たのは、チームとして検索エンジン移行に集中するというゴールのために、他のメンバーが不具合対応や差し込みタスクの対応をやってくれたり、またインフラ側は別のメンバーがやってくれたりと、チームとしてどう動くべきか全員で考え全員が適切に行動したからこそ、新機能の開発に集中できたのです。

そして我々は、普段からスクラムを実現するために、スコープを可能な限り徹底的に小さく切り分けることを訓練され続けてきました。そんな我々にとって、β版をリリースしてユーザーに価値を提供するために、何が出来ていれば良くて、何は後回しで良いか判断することは、ごく当たり前の日常的な思考であり、動作でした。

もしも、「古い検索エンジンと全く完全に同じ動きをして、一切おかしな挙動をしないことが完全に証明できない限りユーザーに新しい機能を提供することはまかり通らない」というようなことを言うメンバーが社内にいたのであれば、エンジンのリプレイスはもっともっと先延ばしになり、データベースはより破壊的なダメージを受けていたことでしょう。

ユーザーの価値について常に考え、価値を可能な限り素早く提供するにはどうすればいいか考え、そのためにチーム一丸となって全力で取り組む、これこそがスクラムです。ただ納期が一週間になって、何かあったら徹夜してでも一週間で納品する、みたいなミニウォーターフォールは、決してスクラムには成り得ませんし、アジャイルも実現できません。少なくとも、今のROXX、そして開発チームには、上部だけのスクラムを良しとするメンバーはいません。

形式論ではない本当の意味でのスクラムによる開発体験は、常にユーザーにとっての価値とは何か、ユーザーにとって価値を届けるにはどうすればいいか考えることを楽しめるエンジニアにとって、とても刺激的なものになると思います。

松井さん、ありがとうございました！エンジニアから見たagent bankの魅力が、読者の皆様にも伝わっていますと幸いです。ROXXのサービスを支えるプロダクト開発部門を中心にTech blogも更新中ですので、ぜひ覗いてみてくださいね！