なぜ今、リアーキテクティングが熱いのか？大規模Railsアプリのリファクタリング最前線で体感していること。

建設業界のDXプラットフォームを目指す「ANDPAD」は、サービスの成長にともないリアーキテクティングが必要なフェーズになりました。これは「ANDPAD」に限った話ではありませんが、歴史があればあるほど、大規模サービスを最善のアーキテクチャに導くことは簡単ではありません。

そのような中、「ANDPAD」のリアーキテクティングチームの中心メンバー白土慧（しらつちけい）さんは、日々開発の”つらみ”を解消しています。Web系スタートアップのリードエンジニアとして活躍していた白土さんがアンドパッドにジョインし、なぜ今リアーキに取り組んでいるのか、そこにはどんな面白さが詰まっているのかインタビューしました。

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

ゼロからプロジェクトを立ち上げてきた。今度は大きな組織で課題を解決したい。

ーまず最初に、白土さんのアンドパッド入社経緯を教えてください。

入社前の私は、社員数が多くて30名程度、エンジニアチームが10数名という規模の組織で働いてきました。前々職のスタートアップは、ビジネスサイドの創業者2名に続き最初のエンジニアとして入っていたんですよ。プロダクトやエンジニアチームの立ち上げを、中心メンバーとして経験できたことはプラスだったと思います。

一方で、大きな組織で働いたり、大規模サービスに携わる経験がなかったのでチャレンジしたいと思っていたんですよね。ちょうどそんな折に、先にアンドパッドで活躍していた佐藤竜之介（@tricknotes）※1から「最近どう？」と連絡をもらいました。もともと佐藤と私は、いわゆるRuby/Rails界隈と呼ばれるつながりで親交があったんです。

以前からアンドパッドはRuby/Railsのイベントでスポンサーをしていることを知っていましたし「エンジニアにとって魅力的な環境かもしれない」と感じていました。しかも、建設業界のDXというビジネスも面白そうだと思ったんですよね。

「Ruby on Railsでつくったアプリケーションの規模がかなり大きくなっていて、そろそろリアーキが必要なんだけれど、みんな手がつけられないでいる。興味があればやってみませんか？」と佐藤にも誘われ、元々興味がある分野だったのでやってみようと思ったのが入社の決め手です。大規模Webアプリケーションの課題解決にチャレンジできるチャンスだと思いました。

手応えのあるリアーキテクティング。システムの”つらみ”を把握するのに１カ月かかった。

ーアンドパッドにジョインして、どんなことに着手したのですか？

まずはどこからリアーキすべきなのか手がかりを得るために、各プロジェクトチームにヒアリングをかけました。具体的には、開発中に感じている”つらみ”と、やりたくてもやれていない課題などを出してもらったんです。アンドパッドの古参エンジニアに話を聞いたり、過去の議事録から探したり、あらゆる手段で情報収集しました。

集めた情報から見えてきたのは、アプリ内部の修正に各チームが着手しにくい状況だったことです。特に、業務ドメインをまたいで利用される箇所に課題がありました。具体的な問題の一つは、データベース上のリレーションの問題で、写真や資料などのストックデータが、ポリモーフィック関連でつながれていたことです。ポリモーフィック関連の場合、あらゆるモデルと紐づけできるし、設計時になかったモデルを足していけるという便利な面もありますが、外部キーを設定できない欠点があります。また歴史的な経緯から、対象データを呼び出す手続きが複雑になっていました。写真データに関して、どの箇所からどんなふうに使われてるのか、全て把握している人もいなかったんですね。写真データは業務ドメインを跨いで利用されているため影響範囲が大きく、修正が他のチームにも影響する恐れがあり、触りづらかったのだと思います。

そこで、複数のドメインを横断した問題を解決するリアーキテクティングチームを結成しました。リアーキテクティングというと通常はマイクロサービス化する活動と思われる場合が多いと思いますが、現状を把握した上で私が導き出したアプローチは、データの関連を見直し、その持ち方を変更することでした。

リアーキの方針は「安全」です。まずは、自分たちで膨大にあるデータ利用のパターンを一つずつ調査し、着手する優先順位をつけるところから始めました。その後、改修が他のチームの開発に影響しないよう、旧アソシエーションを新アソシエーションに登録し、同期させながら進めていくダブルライトで慎重に進めていきました。

写真のデータに関連する修正はもうすぐ終わります。その後に資料のデータを進めて、「ANDPAD」の本丸ともいえる案件情報というデータに着手する予定です。

Technology Firstというバリューは「課題解決」と結びついてこそ真価を発揮する。

ー開発リリース頻度を変えたことも、リアーキテクティングチームですよね。

もともと「ANDPAD」のリリースのタイミングは、障害発生時に対応を行うCX（カスタマーエクスペリエンス）と連携するために週1回ときまっていました。ですが、それではリアーキのペースが上がらないんですよね。そこで、週2回リリースできるようにVPoEに相談し、他部署と調整することで、サイクルを早めることができるようになりました。サービス全体がよりスピーディーに展開できるようになるし、週1回が限界だと思っていた人たちに「週2回でも問題なくできるんだ」と思ってもらえる事例となったと考えています。

個人的にリアーキは、これから注目される領域であり、世の中的に需要が大きい領域だと感じています。というのも、これはどんなサービスにも言えることだと思いますが、以前のアーキテクチャでは今のビジネス要件に耐えられなくなってくるからです。ある程度歴史のあるサービスはちょうど過渡期じゃないでしょうか。一方で、まだリアーキの知見を持つエンジニアは少ない印象です。だからこそ面白いと感じています。

ー白土さんは勉強会も開催していますね。

『ソフトウェアアーキテクチャ・ハードパーツ』の輪読会を定期的に開催しています。全てのアーキテクチャはトレードオフの関係で、現場段階の最善はあったとしても、唯一無二の最適は存在しません。だから、「あらゆる妥協点を加味して、最適ではなく最善のアーキテクチャを導き出していきましょう」という内容のディスカッションをしています。読書会を通じて、問題意識の共有ができたらいいなと思ったんですよね。

例えば、「マイクロサービスが流行っているからウチもやりましょう」って考えるのではなく、今あるサービスの課題に対して最善のアーキテクチャをまず考えます。その上で、マイクロサービスが使えるなら入れる。最終的にユーザー価値につながる開発をすることが大前提だと考えています。

大規模開発は複雑だが面白い。最善アーキテクチャへ昇華し、ユーザーへ価値を届ける！

ー改めての質問ですが、アンドパッドでやりたかったことが実現できていますか？

アンドパッドは同じユーザーが、写真や図面、チャットなど複数のサービスを利用するので複雑なんですけれど、そこが面白いと思っています。データも溜め込まれているので、それを活用しやすくすることで、便利なサービスが生まれる土壌をつくりたいです。大規模なサービスを支える開発をしていますから、やりたいことが実現できていますね。

それに加えて、アンドパッドのエンジニアは他者と連携を取りチームプレイすることが得意な人が多いです。自分のチームだけ良ければいいという感じではなく、「困っていることないですか？」「ここ大丈夫ですか？」とお互いに助け合っています。エンジニア一人ひとりが、「ANDPAD」のサービス全体に興味をもち、バリューを出したいと考えているからだと思います。

前職までは小さい組織で働いていたので、他のメンバーが何をしているかも把握していたし、問題が起きても自分の力ですぐに直すことができたんですよね。アンドパッドの場合は、そうはいきません。これまで関わりがなかった人たちと連携することは必須ですし、連携すること自体が刺激的で面白く、自分自身の成長にもつながったと思います。プロダクトチームがたくさんあるので、一つの改善がとても大きなインパクトを生み出します。これがやりがいです。