アンドパッドではマルチプロダクト戦略のもと、様々な Rails アプリケーションと開発チームがあり、そして様々な技術課題があります。

そこで今回はそんな技術課題の中から、 3 つのチームの課題を紹介すべく、 ANDPAD早受取 開発チームから 西 亮祐 、 ANDPAD受発注 開発チームから 北舘 賢志朗 、 ANDPAD黒板 開発チームから 仲澤 義広 が集まり、各チーム（以下、それぞれ早受取チーム、受発注チーム、黒板チーム）の技術課題と解決模様をそれぞれ話し、ディスカッションしました。

2015 年 5 月にファーストコミットが行われ、今年で 10 年となるアンドパッドの Rails アプリケーションにまつわる課題解決を、プロダクト開発が大好きな Rubyist に興味をもってもらいたく開発をリードするエンジニアの座談会を企画しました。

そして、 Kaigi on Rails 2025 では、アンドパッドの技術課題にちなんだクイズも出題します ! ぜひ「アンドパッド ドリンクコーナー」にお越しいただき、チャレンジしてください !!

西 亮祐 

ANDPAD早受取 開発チームのエンジニア。 普段は Rails や Next.js を用いて開発を行っている。

北舘 賢志朗 (GitHub: kkitadate Qiita: kkitadate)

ANDPAD受発注 開発チームのエンジニア。普段は Rails と Nuxt.js を用いて開発を行っている。

仲澤 義広 (X: nooboolean)

ANDPAD黒板 開発チームのエンジニア。 普段は Rails と Nuxt.js を用いて開発を行っている。

「作らない」ことで課題を解決する

―― まずは簡単に皆さんの自己紹介をお願いします。

北舘 : 受発注チームの北舘です。本日はよろしくお願いします。

仲澤 : 黒板チームの仲澤です。プライベートでは今年 12 月にマイホームが完成予定で、待ち遠しい日々を過ごしております。よろしくお願いします。

西 : 早受取チームの西です。今年の 7 月に他のチームから異動してきたばかりですが、頑張っていきたいと思います。よろしくお願いします。

―― 皆さん、ありがとうございます。 では、早速、西さんから所属チームとプロダクトの紹介を簡単にお願いします。

西 : 早受取チームは PdM 、 PMM 、エンジニア複数名で構成されています。また、「ANDPAD早受取」という請求書買取型の資金化サービスを開発しています。 このプロダクトは「ANDPAD受発注」という別の ANDPAD プロダクトと連携しているのが特徴です。 ユーザーは「ANDPAD受発注」を利用して発行された請求書をもとに、請求金額を早期に受け取ることができます。 画面上で請求書を選ぶだけで申請ができる手軽さが魅力の一つになっています。

技術要素としては、バックエンドが Rails 、フロントエンドが Next.js です。 その他ネット銀行の API や本人確認サービスとも連携しています。

―― ANDPAD早受取は前回の PdM 米山さんの 記事 でも紹介されているので、読者の皆さんにもぜひご覧いただきたいですね。 その記事でも触れられていますが、改めて開発にはどのような特徴があるのでしょうか？

西 : プロダクトが検証フェーズにあることは大きな特徴です。 検証フェーズでは素早くリリースして仮説を検証することが求められます。 そのため必要最低限の開発にフォーカスし、作り込みすぎず、常に「この機能は仮説を検証するために本当に必要なのか」と問い続けながら開発しています。

―― 作り込みすぎるのは、よくやってしまう失敗ですね。 具体的にはどのような仮説検証をしているのでしょうか？

西 : 最近の事例を例に話すと伝わりやすいですね。 ANDPAD早受取の当初の仕様では、初期設定を完了しないと機能に一切アクセスできませんでした。 初期設定には、個人か法人かという "事業区分" を選択するステップや、会社情報や口座情報を入力するといった複数のステップがありました。 これらが未完了の場合、ユーザーは何もできないのですが、この完了率が想定よりも低かったのです。 そこで「初期設定を行わなくても申請フローの一部を体験できるようにすることで、初期設定の完了率が上がるのではないか」という仮説をチームとして検証することになりました。 初期設定さえ済ませてしまえば後は画面上で請求書を選ぶだけでよいという手軽さを知ってもらうことで、初期設定へのモチベーションを上げてもらう狙いがありました。

(初期設定 未完了の画面)

―― to C 向けのプロダクトでよく起こるような課題が発生していたのですね。 簡単そうに見えますが、条件が変わるので、なかなか難しい開発になりそうですが ... ？

西 : そうなんです、予想通り、技術的な課題にぶつかりました。 要件は「初期設定をスキップして申請画面にアクセスできること」でしたが、申請画面のコードを調査すると、事業区分が既に選択されていることを前提とした実装が多いことがわかりました。 事業区分は初期設定の中で選択されるものなので、初期設定をスキップできるようにするためには、事業区分が未設定であることを想定した実装に変更する必要がありました。 この変更は影響範囲が非常に広く、コードの保守性も低下することが予想されました。

そこで、冒頭でもお伝えした「この機能は仮説を検証するために本当に必要か」という問いに立ち返りました。  今回のケースでは、「初期設定をせずに申請フローを体験できるようにすることで初期設定の完了率が上がるのではないか？」という仮説を検証するために「事業区分のスキップ」まで実装する必要があるのか、を改めて問い直しました。

答えは「No」でした。 なぜなら、事業区分という、個人／法人を選択するだけの簡単なステップが完了率を大きく下げる要因とは考えにくかったからです。 そこで、「事業区分の選択のみスキップ不可とする」という仕様を開発側から提案し、 PdM と合意しました。その結果、予定通りの日程でサービスをリリースすることができました。

―― なるほど、要求された仕様を見直すことで、課題を解決したのですね。 なかなか面白いお話でした。

仲澤 : ちなみに、他の初期設定項目に関しては、同様の課題はなかったのでしょうか？

西 : 機能を実際に使用するにはその他の設定項目も入力が必要になりますが、機能の体験そのものには必要ないため、他の設定項目ではそのような課題は発生しませんでした。

仲澤 : なるほど、 機能の体験に必要なデータを精査できたのがポイントだったのですね。 一方で、「事業区分の選択のみスキップ不可」という仕様の変更は PdM とスムーズに合意できたのでしょうか？

西 : はい、比較的スムーズにできました。 「本来あるべき仕様は何か？」ということを PdM と議論したうえで、「今は一旦この仕様でリリースするが、最終的にはこうしたい」というかたちで合意を形成しました。

北舘 : 同じようなケースがあったときの参考にしたいのですが、最終的には初期設定全部をスキップする想定なのでしょうか？

西 :いえ、最終的にもスキップはさせないという結論になりました。 ただし、スキップさせないなかでもいくつか方法があるため、その中で理想的なものを実現したいと考えています。

北舘 : どんなフローになるのか、気になるので、その理想的な流れがリリースされたら共有してください。

西 : ぜひ ! 逆に私からも質問なのですが、お二人は「作らない」という意思決定をしたことで、特に印象に残っている経験はありますか？

仲澤 : はい、あります。 黒板には「豆図」という小さい図の画像を挿入できるのですが、その豆図を他の黒板でも再利用したいという声がユーザから寄せられ、作成した全ての豆図を自由に管理できる機能を開発する話が持ち上がりました。 しかし、黒板は連日大量に作成されており、それに応じて豆図も大量に作成されます。 よって、再利用するつもりのない豆図で溢れてしまい、管理しきれないことが予想されました。 そこで、チームは一度立ち止まり、この機能の作成を中止しました。 代替案として、「再利用したい豆図のみを管理する」という方針に変更し、現在新しい機能を開発中です。

西 : やはり途中で立ち止まって、仕様から見直すということはあるのですね。

北舘 : 受発注チームでも「作らない」に近い判断をすることはよくあります。例えば、とある画面の検索項目にフリーワードで入力する項目がありましたが、当初は文字数制限がありませんでした。 本来であればフロントエンドとAPI側両方でバリデーションを設定するべきですが、そもそもユーザーが検索項目に想定外の大きな文字数を入れることはないという前提と、画面側のバリデーション実装が比較的大変だったため、 API 側だけで異常データを防ぐ、という判断をしました。

西：なるほど、ユーザーはこのような使い方をしないだろう、という仮説は、エンジニアと PdM どちらが持つことが多いですか？

北舘 : 場合によりますが、今回のようにエンジニア側から提案するケースでは、エンジニアが既存の DB にあるデータやログから確認することが多いですね。 ちなみに、エンジニアが PdM から渡されるデータだけでなく、独自で収集するデータから顧客理解を深めることは、いい方法だなと感じます。

西 : たしかに、エンジニアならではの、いい顧客理解の深め方ですね。

(Rails エンジニアとして入社後、Go 、Vue.js 、React と幅を広げてきた西)

非同期処理の信頼性という課題を、丁寧に調査して解決する

―― 続いて、北舘さんに 「ANDPAD受発注」とそれを開発する 受発注チームのことを伺っていきましょう。

北舘 : 受発注チームは PdM 、デザイナー、 QA など様々なポジションのメンバーと複数のエンジニアで構成され、大きめの体制で開発を進めています。 開発しているプロダクトは「ANDPAD受発注」というクラウド型 EDI システムで、見積もりから請求までの一連の業務をデジタル化し、建設業界の業務効率化を支援するものです。 特に、元請け会社と協力会社間の情報共有をスムーズにする役割を担っています。

―― 昨年のニュースリリースでは、 ANDPAD受発注の流通総額が 2 年で 614% 成長とすさまじい成長をしているので、それに応じて開発体制も強化されているのですね。

関連ニュース: 「ANDPAD受発注」の流通総額が2年で614%成長 　建設業の請求書受領から査定業務に対応した新サービス「ANDPAD請求管理」も提供開始

北舘 : はい、プロダクトも、チームもスケールしているのに合わせて、アプリケーションへの要求も信頼性や拡張性といったものに、より重点が置かれるようになりました。

―― プロダクトの成長フェーズによっても開発は変わってきますよね。

北舘 : はい。 そこで、今日はその信頼性に関して、非同期処理を安定させる取り組みを話したいと思います。 ANDPAD受発注の機能の一つに「発注書自動作成」があります。 これは法的要件を満たした電子署名付きの発注書を自動生成し、ペーパーレス化を実現するものです。 この機能には色々な技術をくみあわせているのですが、主には AWS SQS (以降、 SQS) と AWS Lambda (以降、 Lambda) を利用した非同期処理によって実現されています。 具体的には、 Rails アプリケーションからのリクエストを SQS にキューイングし、 Lambda が処理して Rails アプリケーションに結果を返すという流れです。

(発注書自動作成の流れ)

―― 非常にトランザクションが多そうな機能ですね。 ここで信頼性が求められたと。

北舘 : おっしゃるとおり、利用数が多い機能で、そのほとんどは上手く動作していたのですが、稀に発注書が作成されていない事象が発生していました。 発生頻度が稀とはいえ、発注に関することなので、場合によってはお客様の調達にも影響します。 そこで、原因調査を進めたところ、非同期処理で発注書の作成から保存までを行っていたのですが、 Lambda が処理したときのリトライ処理に不足があることがわかりました。 具体的には 500 系の何らかのネットワークやサーバエラーが起きたときにリトライされていなかったのです。

そこで解決策として、 Lambda 側でリトライ処理を実装し、特に Rails アプリケーションに発注作成処理を API コールする部分で、即座にリトライできるようにしました。 これには Faraday Retry という Gem を使って 500 系のエラーに限定して即座にリトライするよう、シンプルに実装しました。 またリトライ間隔も指数バックオフで自動調整しました。

―― 非同期処理は原因特定が難しいものですが、丁寧に調査されたのですね。

西 : 素朴な疑問として、一般的な Rails アプリケーションでの非同期処理を実現するときは Sidekiq と Redis の組み合わせが多いと思います。 あえて SQS と Lambda を採用された背景は何でしょうか？

北舘 : Sidekiq が Rails アプリケーションに密着したスタックであるのに対し、 SQS と Lambda を採用することでポータビリティを高める狙いがありました。 例えば Go などを将来的に採用することも視野に入れており、そのような技術への移行も考慮していました。

西 : ANDPAD にはメインのモノリシックな Rails アプリケーションがあって、その一部として実装されているプロダクトもありますが、ポータビリティを重視するということは、 ANDPAD受発注はそうではないのですか？

北舘 : ANDPAD受発注はメインの Rails アプリケーション とは別のアプリケーションなので、それが技術選定を柔軟にできる背景にあります。

仲澤 : このあと私も非同期処理のことを話すので、リトライは頭を悩ませるポイントです。 そこで聞きたいのですが、リトライの最大回数やインターバルの値はどれぐらいに設定したのですか？

北舘 : 最大リトライ回数は 5 回で、インターバルは指数バックオフの仕組みを利用しているため、最初は 1 秒から始まり、リトライするごとに 2 倍になっています。 最大では約 30 秒間待ちます。

仲澤 : それらの数値が特定の意図を持って決められたように感じました。今後の参考のため、どのような経緯でこの設定値になったのか教えていただきたいです。

北舘 : 500 系エラーの原因の多くがネットワークエラーだったので、約 30 秒待てばネットワークが復旧するだろうという想定があったからですね。 また、長すぎると Lambda の実行数が増加し、 AWS アカウントの制限を圧迫する可能性があるため、そのバランスを考慮しました。

仲澤 : 設定値の背景がよく理解できました。詳しくご説明いただき、ありがとうございました。

(Kaigi on Rails 2024 にも参加した北舘)

ライブラリ選定は慎重に綿密に、導入効果を最大限にして課題を解決する

―― 最後に、仲澤さんに 「ANDPAD黒板」とチームのことを伺いましょう。

仲澤 : 黒板チームも 受発注チームと同様に、 PdM 、デザイナー、 QA などを担当するメンバーと、複数のエンジニアで構成されており、多数のメンバーが在籍しています。 その中で私はバックエンドエンジニアとして Rails で開発をしています。  開発しているプロダクトは「ANDPAD黒板」で、工事現場で工事記録を残すために使われる物理的な黒板を電子化した電子小黒板を一元管理できるものです。 スマートフォン一つで黒板情報が入った工事写真を簡単に撮影できます。 これまで手間だった黒板の持ち運びや、黒板の書き直し、写真整理といった作業を大幅に効率化します。

特徴的な機能として、現場によって数百枚数千枚必要になる黒板を CSV から一括作成できたり、山間部など電波が届かない現場でも使えるオフラインモードがあったり、図面から AI がテキストを抽出して転記することで、黒板の作成をアシストする 黒板 AI 作成などがあります。

―― 先程の豆図といい、 ANDPAD黒板はお客様のペインを解消する機能を次々と出していますね。

関連記事: ML エンジニアの森 直幸が AI 機能で大ヒットを飛ばしている背景

仲澤 : おかげさまで話題となる機能のリリースが出来ています。 今日はその中でも「配筋マーカー」機能についてお話しします。

関連ニュース: ANDPAD黒板、配筋検査を効率化する「配筋マーカー」機能を提供開始

「配筋マーカー」は、配筋検査をデジタル化した機能です。 配筋検査は、マーカーなどを使い配筋が設計図通りに組まれているかを検査するものです。 普段は物理的なマーカーを設置して写真を撮るのですが、「配筋マーカー」では電子小黒板付きの写真に、 Web 上で電子マーカーを設置できるようにすることでデジタル化しています。  これを実現するには、被写体画像レイヤー、電子小黒板レイヤー、注釈レイヤーという三層構造のレイヤー化ができる SVG 画像の導入が必要でした。 当時の ANDPAD には SVG 画像を操作して保存する機能はなく、初めての導入だったことに加え、既存の写真機能 (JPEG ダウンロード、写真台帳出力など) でも SVG が使えるようにする必要がありました。

―― 建築・建設業界らしい SVG 画像の操作や保存もお聞きしたいところですが、既存機能も複雑な要件のもとに作られているので、その改修も一筋縄ではいかないですよね。

仲澤 : まさしくおっしゃるとおりで、そこに 2 つの技術課題がありました。 最初の課題は SVG 画像の JPEG 変換です。 既存の写真機能として JPEG 出力が必要だったため、 SVG を JPEG に変換する必要がありました。 これまで画像処理には RMagick を使うことが多かったので、今回も RMagick で試したところ、テキストに黒縁が付いたり、日本語テキストが失われたりする問題が発生しました。

これを解決するために Gem を含めた調査を経て、 ruby-vips という libvips の Ruby バインディングである Gem を導入しました。 これにより、黒縁や日本語テキストの問題が解消されました。 また RMagick よりも処理速度が速く、メモリ消費も抑えられることが判明したため、黒板チームでは既存機能も含めて ruby-vips への置き換えを検討しています。

西 : なかなか劇的な効果があったライブラリ変更ですが、どのような調査を経て ruby-vips に決まったのですか？

仲澤 : まずは複数の選択肢を洗い出しました。 既存の RMagick の拡張、ヘッドレスブラウザの利用、それだけでなく Gemini など 生成 AI も活用して選択肢を広げました。 その上で、比較するべき観点を明確にしました。 例えば、「 SVG 変換時に黒縁が付かないか」「日本語テキストが正しく処理されるか」といった機能的な観点に加え、「パフォーマンス（ベンチマーク）」「導入の容易さ」といった技術的な観点も評価項目に入れました。 選択肢を列、観点を行として表を作成し、比較することで最終判断をしました。 今回のユースケースでは、日本語テキストの再現性が高く、かつパフォーマンスにも優れていたため、 ruby-vips の採用を決定しました。

西 : なるほど、やはりライブラリの選定は慎重になりますよね。 選択肢を AI で増やすのはとても面白いですね。

仲澤 : ありがとうございます。 続いて、 2 つ目の技術課題は、写真台帳の Excel 出力におけるパフォーマンス問題です。 この機能は、 Web 上で工事写真台帳をカスタマイズし、 Excel にプロットする既存の機能です。今回の SVG 対応での要件として、 SVG 画像から被写体画像レイヤー(３層のうちの1層)のみを抽出し、 Excel に出力する必要がありました。 この抽出と画像化に 1 枚あたり数秒かかり、 Excel 出力の上限 3,000 枚と合わせると、著しいパフォーマンス劣化が懸念されました。

関連記事: 3,000枚の工事写真を Excel に！AWS Lambda の非同期実行で作る写真台帳 Excel 出力機能 - ANDPAD Tech Blog

仲澤 : Excel 出力自体は既に Lambda による非同期処理で実現していましたが、この画像抽出処理は Lambda に渡す前に行われる同期処理だったので、時間がかかっていました。 そこで、この画像抽出処理を Sidekiq で非同期化することで解決しました。 これにより、 Excel 出力の処理全体が二重に非同期化されることになりましたが、パフォーマンス検証の結果、ユーザが同期的に待てる時間ではないが、非同期であれば待てる時間であることが確認できたため、この方式を採用しました。

(ANDPAD黒板チームのテックリードとなった仲澤)

北舘 : 先ほど、仲澤さんから同じ非同期処理のリトライの質問をもらったので私も (笑)。 もし Lambda の処理が失敗した場合、ユーザにすぐにフィードバックできないので、 UX を工夫することが求められると思います。 どんな打ち手を行ったのでしょうか？

仲澤 : 工夫というよりは既存の仕組みを活用したのですが、メインの Excel 出力処理が元々 Lambda で非同期化されているので、その実行ステータスを確認できる機能がすでに存在していました。 今回 Sidekiq を使った画像抽出処理も、その既存の実行ステータス確認画面で進捗やエラーを把握できるように連携させました。

また、リトライ処理も気になると思うので追加すると、 もし Sidekiq 側でエラーが発生した場合、リトライし続けないよう、最初の実行から 1 時間経過しても完了しない場合はエラーとみなすようにハンドリングしています。 そのため、ユーザーは基本的に処理状況やエラーに気づけるようになっています。

北舘 : 既存機能の拡張は大変なことばかりだと思っていましたが、すでにある仕組みが使えるのは、とても便利ですね !

―― では、 3 人の話が終わりましたね。 それぞれ異なる Rails アプリケーションのエンジニアならではの話で、日々ものづくりをする中で、アンドパッドの各開発チームがどのように課題解決を進めているのか、読者にも伝わったと思います。 今日は対談ありがとうございました !

仲澤 北舘 西 : ありがとうございました !

まとめ

この記事では、アンドパッドには様々な Rails アプリケーションがあり、プロダクトの特徴や開発フェーズによってチームや開発の進め方が違うこと、技術課題も様々あることをお伝えしました。 いかがだったでしょうか ? 読者の皆さんの課題解決の参考に、また、アンドパッドの様々な技術課題に興味をもっていただければ幸いです !

また、今回はプロダクト開発チームにフォーカスしましたが、アンドパッドには横断開発を行うチームもあり、モノリス化した Rails アプリケーションの技術課題に取り組むチーム、プロダクト連携の技術課題に取り組むチーム、 Ruby やライブラリアップデートに取り組むチームなどなど、沢山のチームがそれぞれ技術課題に取り組んでいます。

Kaigi on Rails 2025 のアンドパッドブースでは技術課題にちなんだクイズを出題しますので、課題解決を体験いただけます。 ぜひお越しください !

では、 Kaigi on Rails 2025 でお会いしましょう !