爆速成長する 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) 部の部長に昇格。

プロダクトの圧倒的成長を支える 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 未経験で入社されたのは初耳でした。それでも学習意欲が高いと、高いレベルでキャッチアップできるのですね。読者へのいいメッセージになったと思います。今日はありがとうございました！

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