爆速成長する ANDPAD受発注開発チームにみる 1 → 10 と 10 → 100 フェーズの開発の違い

アンドパッドは一つの大きなモノリシックなアプリケーションを開発するのではなく、マルチプロダクト戦略をもとに様々なチームに分かれ、それぞれが裁量をもって開発を進めています。

今回はその中でも建設業法やインボイス制度などの関連法対応で爆速成長している ANDPAD受発注の開発チームの PdM 甲斐、テックリードの内山、マネージャの辻の 3 名が集い、実際どのように開発を進めているのか、特に 1 → 10 と 10 → 100 フェーズの開発や技術の違いをテーマに対談しました！

アンドパッドの開発チームがどんなことにこだわっているのか、わかる内容になっているので、ぜひご覧ください！

甲斐侑
プロダクト本部プロダクトマネージャ ANDPAD受発注・ANDPAD引合粗利管理担当

システムインテグレータ企業でエンジニア、事業開発を経験後、 2022 年 10 月にプロダクトマネージャとしてアンドパッドに入社。 10 → 100 フェーズの ANDPAD受発注・ANDPAD引合粗利管理をリードする。

内山博之
開発本部 EDI 開発チームテックリード

ソフトウェア開発企業で会計ソフトの開発に携わり、 2021 年 7 月にアンドパッドに入社。 ANDPAD受発注の 1 → 10 フェーズの開発から参加。

辻隆志
開発本部製品 (EE) 部部長

金融系事業会社で銀行・証券系システムの開発運用に携わる。 2023 年 3 月にアンドパッドに入社。入社以来 ANDPAD受発注・ANDPAD引合粗利管理の開発チームのマネジメントを担当。 2024 年 4 月から製品 (EE) 部の部長に昇格。

関連法を詳しく知らずとも法令遵守ができる UX を実現する ANDPAD受発注

辻 : 普段は同じチームでワイワイやっているので気恥ずかしいですが、まずはみんなで読者の方に自己紹介をしましょうか。まずは私から。 2023 年 3 月にアンドパッドに入社して、入社当初から ANDPAD受発注を開発する EDI 開発チームと ANDPAD引合粗利管理を開発するチームのマネジメントをやっています。前職では金融系事業会社に勤め、銀行/証券系システムの開発運用に携わっていました。
今日は対談のモデレータをするので、改めてよろしくお願いします。

甲斐 : 2022 年 10 月にアンドパッドに入社し、 ANDPAD受発注 / ANDPAD引合粗利管理のプロダクトマネージャ（ PdM ）を務めています。前職の SIer ではエンジニア → BizDev （事業を開発するポジション）をしていたのですが、自社プロダクト開発をやりたいと思い、入社しました。

内山 : 2021 年 7 月に入社し、もうじき 4 年目を迎えます。現在は ANDPAD受発注を開発する EDI 開発チームに所属し、テックリードをやっています。前職ではソフトウェアエンジニアとして会計パッケージを開発していて、簿記の資格取得が必須の環境でした。アンドパッドには Android 開発のポジションで応募したところ、器用に色々できることを買われ、 EDI 開発チームの 1 → 10 フェーズの開発から入りました。

辻 : 皆さん、ありがとうございました。では、早速、建築・建設業界になじみのない読者の方への前提知識として ANDPAD受発注を紹介しましょう。甲斐さん、お願いします。

甲斐 : EDI の仕組みそのものは古くからありますが、 ANDPAD受発注は建築・建設業界に特化しているところがポイントです。建築・建設プロジェクトでは材料や工務の発注と受注業務が大量に発生しますが、それをオンラインで完結できます。建築・建設業界における受発注のプロセスは見積から請求書発行、支払いまで多岐に渡る業務において建設業法や関連法の適用が求められ業務負荷が高いのです。それを ANDPAD受発注を使えば、業務を大幅に効率化できます。

内山 : 加えると、従来の業務ステップはすべて紙で行われていることが多く、非常に時間と労力がかかる作業です。ユーザーの方に聞くと、押印や記入などのために事務所に戻るといったこともしばしばだったそうです。

甲斐 : そういった煩雑な受発注プロセスの DX 化と同時に、先程の建設業法への対応、さらには最近話題のインボイス制度や電子帳簿保存法への法令遵守もできるところが特徴ですね。

辻 : さすが PdM ですね、わかりやすい。では、そんな甲斐さんが PdM としてプロダクトでこだわっているところはどんなところですか？

甲斐 : 建築・建設業界のユーザーにとって操作がわかりやすくて単純なこと、法令を遵守すること、この 2 つは相反することが多いのですが、そのどちらも満たすような UX を実現することですね。

辻 : そのこだわりがあって、 ANDPAD受発注を使えば、ユーザーは建設業法や電子帳簿保存法、インボイス制度を意識せずとも、法令に則って業務を行えています。

内山 : そうそう大工さんや職人さんたちが経理に詳しい必要はないのですよね。

辻 : 私の父親が個人で建築設計事務所をやっているのですが、このあたりの関連法がわからないので、結構な金額を払って全部外注していました。私の場合、そういう業界の煩雑なところを解消したいという思いが、アンドパッドへの入社動機にもなっています。

プロダクトの圧倒的成長を支える EDI 開発チームが持つこだわり

辻 : プロダクトのこだわりを聞いたところで、今度は内山さんに、開発するにあたってチームでこだわっていることを聞かせてもらいましょう。

内山 : PdM からもらった要件通りには作らないことですね。開発チームは意識しないでいると請負マインドになりがちなので、なぜその機能が必要なのか、ユーザーにとってどんなメリットがあるのか、自分たちが理解できないものは開発しないようにしています。

辻 : 出だしから PdM 甲斐さんの言う通りにはしないぞ、という発言がすごい（笑）。

内山 : いやいや、そういう意味ではないですよ（笑）。 PdM が決めた要件通りに開発していると、仮にその要件が間違っていると、それは外部要因なので開発チームだけでは改善できません。自律的に自分たちで開発を進めるために自分たちが作るものを見極められるようにしているという意味です。
だから、今ある機能をユーザーがどう思っているのか確認しますし、それを踏まえ PdM とも開発ロードマップの認識合わせをして、ちゃんと一緒に進めています。

辻 : 組織的にも PdM と開発チームは本部が分かれているので、 PdM と EDI 開発チームは馴れ合わずにいい距離感で出来ていると感じますね。

内山 : 開発チーム内もエンジニアにありがちな、この技術はこう使うべきといった原則論のようなものはなく、論拠を伴った開発になっています。開発スピードを優先するときや、このコードは保守性が悪くなってきたのでリファクタすべき、合いそうなライブラリがあればそれを導入しようなど、技術をフラットに見てディスカッションできています。

甲斐 : 開発チームがしっかり議論してくれるので、一緒に要件を深堀りしてブラッシュアップできていますよね。いい意味で最初の要件通りに作ってくれません。 PdM としてはさらに進めて、究極、要件ではなくユーザーの抱える問題や要求だけを開発チームに渡してしまい、 PdM は問題発見を中心に進められればと思っています。

内山 : そう、もっと実現したい UX だけを開発チームに渡してもらったほうがいいですよね。

甲斐 : そうそう。ただ一方で UX だけを渡そうとすると、意識せずに法令遵守できるようにという UX を実現するには EDI 開発チーム全員に法律知識をインストールしてもらう必要が出てきてしまう。なので、今は法律のポイントだけを伝えて、「だからこういう機能が必要なんです」という渡し方をしています。

内山 : 本当にその法令遵守の実装が難しい。一般的な業務フローを思い浮かべてしまいがちなので、あわてて修正することがあります。

辻 : そう ANDPAD受発注は自分たちが当たり前だ、便利だと思ったことを作ればいい世界ではないのですよね。

内山 : プロダクトが自然と法令遵守ができる UX を実現しているのと同じように、 EDI 開発チームも同じようにドメインへのこだわりがありますね。

辻 : というと？

内山 : 個人的にエンジニアにもドメイン志向が強い方と技術志向が強い方がいると思っていて、 EDI チームは、技術志向がありつつもドメインやユーザーが抱える課題や問題にも強い関心がある方がフィットするチームだと思います。

辻 : わかります。 EDI 開発チームは「この技術はこう使うべき」のような志向ではなく、ユーザーが抱える問題に対して、どう技術を活かすか、ということに興味があるというエンジニアが活躍するのですよね。

甲斐 : SRE など横断的に活躍するチームは別として、それはアンドパッドのプロダクト開発チームにみんな共通していることかも。

辻 : 確かに。と言いつつ、 QA ・SRE・リアーキテクティングチームなどもまた同じようにユーザがどんな使い方をしているのかは見ていますものね。

内山 : 何時にアクセスが集中する、という事柄一つとっても、ユーザーの行動に紐づくものなので、そうなりますよね。

エンジニアらしさを重視する文化

辻 : ちょっとずつ "らしさ" が伺えたところで、今度は開発チームで工夫しているところを聞いていきましょう。

内山 : 私が開発チームに入ったのが 1 → 10 フェーズで、目が届く範囲にユーザーがいたので、どれだけ開発速度を高めて、目の前のユーザーの課題を解決できるかということにフォーカスしていました。
それが今の 10 → 100 フェーズは、当たり前ですが、ユーザーが当時より圧倒的に増え、堅牢・正確さがより高いレベルで求められるようになりました。それに伴って、例えばテスト自動化など、開発で重視することがガラッと変わりました。

辻: チームが 1 → 10 を経て酸いも甘いも経験してきたことで、私もプロダクトのフェーズが変わってきたことを感じることが増えてきました。

甲斐 : 私も辻さんもトランザクションが多い決済系システムを前職でやってきた経験があって、チームの動きを見ていると変わったな、ということを感じますね。
加えて、品質への要求が高くなるに連れ、普通はテストの量が増え、開発のアウトプットの量は落ちがちです。ただし EDI 開発チームはテスト自動化に強いパッションを持っていたので、品質を高めながら、アウトプットの量が変わらなかったことに驚きました。

辻 : テストだけでなく、実はプロダクト導入などで手動の部分が少し残っているのですが、それも自動化しているところに、チームの文化の変化を感じますね。エンジニアの美徳に挙げられている "怠惰" とはこういうことだなと感じています。

内山 : プロダクトが爆速成長しているのにあわせて、作業量が増えたら、人数規模がますます増えることになってしまいます。それがここ数年で人数規模は、ほぼ変わらず、開発スピードを上げられています。

辻 : 成長速度がグングン上がってるのに、チームの規模は変わってないのは素晴らしい！マネジメントとしても、とても助かるところです。またシステムトラブルが増えたら、開発が滞るのですが、それもなく開発に集中できているのは自動化を始めとする品質を保つ工夫の賜物です。

内山 : そういう煩雑ごとを効率化したいエンジニアらしい方にはいい文化になってきました。お客様の DX を進めるなら、自分たちも DX を上げていこうぜ、という話ですね。

辻 : それはチームメンバーの中でも子育て世代が増えていることも影響しているかも知れません。もちろん他世代もいて、それぞれの背景を考慮する土壌になってます。

甲斐 : 以前と比べて、子育てにも理解があるチームになりましたよね。夜間作業やミーティングを設定する際も配慮する空気が自然にできています。なので夜間作業の自動化がガンガン進んでいる印象です。

内山 : 開発チームの持続性を意識するようになりましたよね。いろいろな世代を受け入れていきたいです。

プロダクトフェーズによって求められる技術とスキルは変わる

辻 : 先ほど話題に挙がったフェーズによって注力することが変わる、という話を深堀りして聞きたいですね。内山さんに違いを挙げてもらいましょうか。

内山 : 1 → 10 の特徴は何と言ってもスピード重視ということが挙げられます。目の前のユーザーを喜ばせたい、ファンになってもらうことが目的になっているので、 10 → 100 のフェーズに求められる安定性とはまた違ったものでした。

甲斐 : 10 → 100 のフェーズになると、要件や要求も変えましたしね。

内山 : あとは、 1 → 10 はがむしゃらに開発するので、属人性があっても許容し、何でもできるといった個人のタレント性も求められるように思います。

辻 : なるほど、確かに。反対に 10 → 100 のフェーズでは個人よりもチームとしての動きが求められますね。

甲斐 : そう、そのフェーズになると、今度は属人性を排して、チームでの再現性を重視するようになります。

内山 : 加えて、 1 → 10 フェーズの小規模でしかパフォーマンスがでないような作りだった機能を、 10 → 100 のフェーズで大規模利用できるように拡張するような開発が増えました。

甲斐 : 10 → 100 のフェーズになると、途端にシステムとして非機能要件への対応が多くなるのですよ。

内山 : 非機能要件は、機能要件とはまた違った考えごとが必要になるので、 1 → 10 が技術的な広さが求められるのに足して、 10 → 100 では技術的に深さが求められる印象を受けました。じっくり調査して、コードを書くという価値もでてきて、エンジニアとしてまた違った楽しさが味わえるようになりましたね。

辻 : いいですね。違いだけでなくエンジニアとしての楽しみも聞きたいです。

内山 : 非常に単純ですが、売上が伸びていると楽しいです（笑）。

甲斐 : あとはプロダクトが成長すると、一つの機能の使われる総量が変わるので、エンジニアにとっては多くのユーザーの業務を支えているという感覚にもなるでしょうね。

内山 : それは実感します。チームだとその喜びも分かち合えるので楽しいですね。

甲斐 : あとは非機能要件になると、インフラへの要求も当然出てくるので、それを内山さんが翻訳してチームに展開してくれているのはありがたいですね。

内山 : チーム向けに話すだけでなく、インフラ投資も必要になるので、経営陣に開発側から説明責任が求められる場面も増えました。その工数と費用をどう説明するか、難しいけど面白いですし、経営陣から試されているという新しい感覚も生まれました。

さらなる成長へ。次のフェーズに求められるマインドとスキルセット

辻 : これまでは 1 → 10 → 100 というフェーズでの話を聞いてきましたが、 100 → 1000 → 100000 と拡大する未来のフェーズに関して話題を広げます。そのフェーズではこの記事の読者の方が未来の EDI チームの開発に加わっていると期待したいので、具体的に ANDPAD受発注で今後どういったことが起こるのか、共有しましょう！

甲斐 : 成長著しいプロダクトなので、また 1 → 10 のようなダイナミックな開発も想定されます。さらに、これまでの開発ベクトルとはまた違った、 ANDPAD の各プロダクトを横断して Hub のように使われる展開も想定されます。受発注は本当に様々なところで行われているので、そのデータを拡張したり、横断的にプロダクトを接続することもあります。そうなると、開発難易度もググっと上がります。

辻 : ANDPAD受発注が ANDPAD 製品全体の horizontal SaaS になってくるということですね。

甲斐 : まさしく。

内山 : 難易度高そうで、さらに面白そうです！将来 EDI 開発チームに参加される方には「すべてをできることは求めていない。知らないことがでてきたら勉強するチャンス！」と、楽しんでもらえる人ならいいなと思いますね。私も Ruby/Rails 未体験で入社してリスキリングしてスキルを広げ、楽しいキャリアを積めていますので。

辻 : 内山さんが Ruby/Rails 未経験で入社されたのは初耳でした。それでも学習意欲が高いと、高いレベルでキャッチアップできるのですね。読者へのいいメッセージになったと思います。今日はありがとうございました！

内山・甲斐 : こちらこそいいモデレート、ありがとうございました！