ANDPAD の裏側では、複数のプロダクトが連携する巨大で複雑なシステムが稼働しており、日々高い性能要件と可用性が求められています。 そんな「ANDPAD」の大規模 Rails アプリケーションのリアーキテクティングを中心となって牽引してきたのが、 kei-s こと 白土 慧 です。 白土は、バックエンドエンジニアとして入社後、リアーキテクティングチームを立ち上げ、システムの根幹に関わる課題解決に取り組んできました。 そして現在、開発現場をリードするポジションから組織全体を俯瞰する立場へと軸足を移し、横断部門を管掌する『部長』として新たなキャリアを歩み始めています。

なぜ、エンジニアからマネジメントの道を選んだのか？ 巨大なエコシステムへと進化する ANDPAD が直面するシビアな要求や AI がコードを書く時代のエンジニアのキャリアなど、今回は、新部長・ 白土 慧 に、横断部門の使命と、複雑な技術課題に挑むエンジニアのキャリアパスを語ってもらいました。

白土 慧 （しらつち けい） GitHub: kei-s

北海道大学大学院卒業後、新卒で入社した企業でレコメンデーションシステム開発に従事。 その後フリーランスを経て、複数のスタートアップ企業の立ち上げにジョインし EC システムの開発や機械学習モデルを使ったソフトウェアの開発にも従事。 2021 年にアンドパッドにバックエンドエンジニアとして入社し、 Rails アプリケーションのリアーキテクチャを担当している。 Ruby や OSS 界隈では kei-s として活動。

(過去のインタビュー記事)

ボトムアップの限界。「巨大なエコシステム」化する ANDPAD が直面する要求レベルの変化

―― 白土さんは入社以来、リアーキテクティングチームの立ち上げなど多岐にわたる領域を牽引されてきました。 まずは、これまでのアンドパッドでのキャリアで印象に残っているエピソードを教えていただけますか。

個人的に一番やりがいがあったのは、データベースに関連する障害調査と、その根本解決に向けた取り組みですね。 外部キーに起因して、データベースのマイグレーション時にロックがかかってしまうという非常に厄介な問題があったんです。 障害対応なので、まずは応急処置としてすぐに状況を止めなければなりませんでした。 しかし、そこから原因を深く調査し、「すべての外部キーを廃止する」という方針を立て、長い期間を経て、まもなく問題を完全に閉じきるところまできました。 システムの根幹に関わる課題を根本から解決できたことは、大きな達成感がありましたね。

また、ベトナムのエンジニアメンバーたちと一緒に開発を進めるために、英語でのコミュニケーションを推進することにトライしたことも印象深いです。 大規模なモノリスの開発にベトナムメンバーも入れるように道筋を作り、そこからさらに他のベトナムの開発チームが同じように活躍できるようになるまで広げられました。

(関連するテックブログの記事)

―― そうした技術的な課題解決やチームの立ち上げを経て、今回エンジニアからマネジメントである「部長」の道へ進まれました。その理由は何だったのでしょうか。

一番の理由は、会社や開発組織の現在のフェーズにおいて、「そのロール（役割）が絶対に必要だ」と私自身が強く感じたからです。

これまでは、現場のエンジニアが課題を見つけ、ボトムアップで改善を進めていくアプローチでシステムを支えてきました。 しかし、 ANDPAD というサービスが成長し、大企業のお客様が増えてきたことで、会社やシステムに求められる要求レベルが格段に上がってきたのです。 特に、パフォーマンス性能や可用性に対する要求は以前とは比べ物にならないほど高まっています。 ANDPAD はもはや単なる SaaS ではなく、建設 DX 全体を巻き込む巨大なエコシステムになっています。

―― ANDPAD が「巨大なエコシステム」へと変化する中で、ボトムアップのアプローチだけでは限界が来たということですね。

求められる水準が上がり、やらなければならないことが山のように増えていく中で、リソースは限られています。 すると、ボトムアップで個別に「これが必要だ」と議論して進めている間に、状況が刻一刻と変わってしまうフェーズに来ていて、「今はこれを止めてでも、こっちの課題を優先してやるべきだ」といった、全体を通したシビアな取捨選択も非常に重要になります。 状況の変化に素早く気づき、組織全体として「何をやるべきか」を判断するトップダウンの役割が不可欠になってきたからこそ、私自身がマネジメントの立場に立って、その意思決定を担うべきだと考えたのです。

マネジメントへの視座の変化と、AI エージェントを活用した新たな開発スタイル

―― システムの裏側を支える「リアーキテクティング」の立場から部長に役割が変わったことで変化はありましたか。

視座は大きく変わりましたね。 これまではリアーキテクティングというプロダクトの裏側の改善がメインだったので、直接的に影響を与える相手は社内の「開発者」でした。 例えば、開発者からマルチプロダクト開発をスムーズにしたいという要求を受けて、プロダクト間連携用 gRPC API サーバを開発・導入する、といった具合で、お客様からの要求を直接受けて開発することはあまりありませんでした。

しかし部長になり、影響範囲が広がったことで、お客様の状況やビジネス側の温度感を「肌感」で理解しなければならなくなりました。 そのため、インプットの質と量を意識的に変えています。 以前は見なくても仕事が回っていたビジネス部門の総会資料を読み込んだり、ビジネス部門からの要求を聞いたりして、お客様が今何を求めているのかを間接的にでもしっかりキャッチアップするようにしています。

―― なるほど、視座は変わりますよね。 とはいえ、なかなかスグには適応するのは難しいもの。 何か参考にしていることなどはありますか。

部長陣の動きは参考にしていて、特に同じモノリスの基盤で開発している部門を見ている辻さんや、  VPoT の tricknotes さんの動きは非常に参考にしています。

(辻の登場記事)

(tricknotes の登場記事)

私はこれまで数百人規模の大きな企業での開発経験がなかったので、大規模な組織特有のルール作りや体制構築の「型」を知りませんでした。 辻さんは大規模な組織での経験が豊富なので、例えば有事の際の対応などについて「こういう考え方でルールを作るべきだ」という知見を持たれていて、とても勉強になります。 技術者同士の「技術的にどちらが優れているか」という議論ではなく、マネジメント層として「どう人を動かし、ルールを作り、最終的なお客様への価値（アウトカム）を出すか」という視点での意思決定は、部長ならではの視座だと感じています。

また、 tricknotes さんは、前述したように ANDPADへの要求が格段に上がった、つまり プロダクトのフェーズが変わったことで開発本部が大事にすべき価値観が変わったということを明確に示してくれます。 これまでのように機能をどんどん追加していくフェーズから、可用性を高めるため、耐障害性のレベルを一段も二段も上げなければならないフェーズに来ている。 そういった組織全体の方向付けの面で、大いに学ばせてもらっています。

―― 一方で、マネジメント業務が増加すると、ご自身で手を動かす時間はどうしても減ってしまいます。 そういった状況に、エンジニアとしての葛藤などはありましたか。

実は、複数チームのテックリードを兼任していた時期から、すでに他のメンバーに任せることが増え、自分で手を動かす時間は減っていました。 しかし最近は AI エージェントを使って「手を動かしている」んですよ。

例えば、メンバーに任せるのも気が引けるような、ちょっとしたタスクがありますよね。 そういうときに AI エージェントに対して「この会議をやっている間に、こういう処理を書いておいて」と指示を出しておくと、会議が終わる頃には見事に Pull Request を出せるレベルまで書いてくれているんです。 これは本当に素晴らしい体験で、部長としての業務をこなしながら、AI エージェントを動かすことで実装面でも価値を出せています。 AI が実装を担当し、人間である私は「AI に正しい問いを投げ、出力された結果をシビアにジャッジする」という役割にシフトしているのです。

「門番ではなく伴走者」横断部門が目指す価値と、スペシャリストの探求心

―― 今回、白土さんが管掌されることになった「横断部門」について、どのようなミッションやバリューを持つ組織にしていきたいとお考えでしょうか。

私が管掌しているのが、先程のリアーキテクティングチームに加え、 ANDPAD 全体の通知基盤を開発するチーム、アンドパッド内のカスタマーサクセスなどが操作する管理画面の開発を行う admin チームなどが所属する横断部門です。

その横断部門のバリューを一言で表すなら、「門番ではなく伴走者」です。

横断部門は、お客様に対して直接的な価値（機能など）を提供しているわけではありません。 私たちの価値であり、ミッションは、直接的にお客様に価値を提供しているプロダクト開発チームのメンバーたちが、「100% やりたいことをやれる」ように環境を整え、彼らの開発スピードを加速させることにあります。

―― 規制ではなく伴走というのが "らしさ" を感じるところですね。 ただ横断する仕事は関係者が多く難しいとよく言われます。 アンドパッドではどのような点が難しいでしょうか。

一番の難しさは、「お客様から直接要求が来るわけではないので、何をやるべきか自分たちで考え抜かなければならない」という点です。

誰かから言われたことをただやるわけではなく、いま、どの技術課題を解決することが、組織全体にとって最も価値が高いのかを常に自問自答し続ける必要があります。 例えば、リファクタリング一つ行うにしても、「なぜ今それをやるのか？」「それは将来的なシステムの耐障害性の向上にどう繋がるのか？」という根拠が不可欠です。 そのためには、各プロダクトチームの開発状況や、会社全体のビジネスの状況といった外部のインプットを常に把握し、適切なジャッジを下す必要があります。 そこが難しくもあり、自分たちで価値があると思ったことに挑戦できる面白さでもありますね。

―― なるほど。 では、その横断部門で活躍するには、どのようなことが求められますか。

様々ありますが、不可欠なのは広範な知識と粘り強い調査能力です。 そういった能力、つまり横断部門は技術のスペシャリストが求められる場の一つであるということです。 その良い例が、例えば、昨年末に記事になった 通知基盤刷新のプロジェクト であったり、メンバーの髙橋さんが手がけた「Ruby のメモリ使用量問題を調査し upstream で解決していただいた話」です。

―― Ruby コミュニティでも話題になった記事ですね。どのような問題だったのでしょうか。

Ruby のバージョンアップに伴うメモリ増大問題に対し、髙橋さんは巨大なコードから粘り強く原因を調査しました。 そして、見事に Ruby 本体の課題であることを突き止め、それが upstream への報告に繋がり、修正リリースされました。 こうした言語の深層に潜む課題から逃げず、根本解決できるスペシャリストの存在は組織にとって非常に重要です。

巨大で複雑なシステムだからこそ得られる経験。技術課題を発見し、解決できるエンジニアを求む

―― 大規模システムならではの高度な技術課題ですね。 そういったシステムを相手にする横断部門のエンジニアはどのようなキャリアやスキルを築くことができるとお考えですか。

ANDPAD は巨大でかつ Vertical SaaS という複数のプロダクトが連携して動く特性を持っています。 管理機能（Admin）や金融関連のシステムなど、求められる要件や設計思想が全く異なる様々なシステムが社内に共存しているのです。 このような複雑で巨大なシステム環境だからこそ直面する困難があり、それを乗り越える過程でしか得られない貴重な経験があります。

例えば、横断部門で様々なプロダクトの基盤に関わることで、システム全体を俯瞰する広い視野が身につきます。  ここで培った「システム全体の勘所」は、将来プロダクト開発のチームに異動した際にも強力な武器になります。 「この設計にすると後でパフォーマンス上の問題が起きそうだな」とか、「この変更は他のシステムにこう影響するはずだ」といったジャッジが的確にできるようになり、結果としてプロダクト開発を非常にスムーズに進めることができるようになります。  プロダクトを圧倒的に成長させるプロダクトエンジニアを目指す人も、マネジメントを目指す人も、技術を極めるスペシャリストを目指す人も、それぞれの道で圧倒的な成長機会を得られるはずです。

―― 最後に、この記事を読んでいるエンジニアに向けて、メッセージをお願いします。

私たちが現在メインで取り組んでいるのは、バックエンドの共通システム基盤の改善や、システム全体の可用性を高めるという非常に難易度の高いミッションです。

最近は AI エージェントがコードを書いてくれる時代になりましたが、システムに潜む「本当に解くべき難しい課題」を発見することは、AI には決してできません。 問題の所在を突き止め、AI に的確な問いを投げ、AI が出してきた解決策が果たして本当に最適なのかをシビアにジャッジする。それは、深い技術的知見と経験を持ったエンジニアにしかできない仕事です。

大規模システムならではの複雑な技術課題を見つけ出し、時間をかけてでも根本から解決したい。 そんな強い熱意と技術力を持ったエンジニアの方に、ぜひ私たちのチームに来ていただきたいと思っています。

―― 白土さんの横断部門の面白さや熱意が伝わってきました。本日はありがとうございました。

ありがとうございました！