VPoT 秒速が語るアンドパッドの技術選定

アンドパッドの VP of Technology として、様々なプロダクト・機能開発を技術面でリードする古橋一真こと秒速に、アンドパッドにおける技術選定の進め方をインタビューしました。

技術選定を、プロダクトをリードするエンジニアの裁量に任せている理由や技術選定を行うエンジニアに必要なスキルを分解しました！

株式会社アンドパッド
執行役員 VPoT
秒速 (古橋一真)

フィードフォース、 Speee を経て 2020 年 12 月アンドパッド入社。
秒速として Ruby 界隈で活動中。

アンドパッドではプロダクトをリードするエンジニアが裁量をもって技術選定をしている

―― まずはアンドパッドでの技術選定をどのように進めているか伺えますか？

まず前提として、アンドパッドには ANDPAD施工管理をはじめ、 ANDPADチャット、 ANDPAD図面、 ANDPAD検査、 ANDPAD黒板、 ANDPADおうちノート管理など建築・建設業界向けに多数のプロダクトが存在します。各プロダクトは固有のユーザー・業務の課題を解決するため、固有の要件とニーズを持っています。そして、それぞれ特色のあるプロダクトの開発を牽引しているエンジニアがいます。

―― 建築・建設業界向けにマルチプロダクトで開発を進めていると。では、各々のプロダクトではどのように技術選定を進めているのでしょうか？

まず技術選定に共通する前提として、プロダクトのチームメンバーのスキルセットと適合する技術を選定し、開発プロセスがスムーズに進行することがまず必要です。これに加えて、新しい技術を採用するなど、挑戦的な技術の選定を織り交ぜることもまた重要なことです。

これらがある上で、立ち上げフェーズのプロダクトならエンジニア 1 人で、グロースフェーズのプロダクトなら複数人が技術選定に協力する場合もありますが、各プロダクトにおいて意志と責任を持って事業を前に進めてくれるエンジニアの考えを技術選定に反映しています。

―― なるほど、プロダクトで事業を前に進めるエンジニアによって技術選定がなされているのですね。逆に、組織的に "こうあるべき" のような指針はないのでしょうか？

技術スタックを統一することの利点は理解しつつも、 責任を持って推進してくれるエンジニアの裁量で意思決定できる組織であることを重視 しています。

なぜ、技術選定を "意思と責任を持つ" 現場のエンジニアに任せるのか

―― 事業を前に進めるエンジニアに裁量をもたせて、技術選定をしているのは、どういう背景からでしょうか？

あくまで開発は集まったエンジニアが行うものです。技術の流行り廃りなどが先行する選定の理論よりも、チームに集まったエンジニアが自身の開発に対する考えとスキル、プロダクトの成長を見据えて、複数の技術の選択肢から現実解として進めたものを選定の結果として重視しています。現場の技術選定は、プロダクトや事業をどこまで伸ばしたいのか、どんなエンジニアが採用できているのか、によって行われるものです。

アンドパッドの場合はプロダクトや事業を遠くまで伸ばしたいと考えているので、現場の技術選定を重視しています。

―― なるほど。技術の流行よりもプロダクトの成長予測やエンジニアの意思が重要になるのですね

もともと、エンジニアが歴史的に専門職としての裁量を求めたり、技術を磨いてきた人たちであり、複数の選択肢の中からどちらがよいかという議論を重ねて、論理立てた選択ができる人たちです。そういうエンジニアだからこそ想像力をもって、創意工夫して技術選定してもらいたいことも背景にあります。

また、企画から開発をして、プロダクトが完成して、デプロイして、ユーザに使ってもらうまではとても大変です。そこに到達するまで機能開発や運用保守なども含めた全ての仕事を進めながら責任を持ってリードするエンジニアに、技術選定も任せるほうが有効ですし、任せる側もやりやすいです。

すべての技術選定には良いことも悪いこともついてくる

多種多様なエンジニアを採用でき、技術交換もできる

―― エンジニアに技術選定の裁量があることで、うまくいっていることを教えていただけますか？

アンドパッドが多種多様なエンジニアの採用を続けられていることですね。 Go や Ruby/Rails や、 React 、 Vue など技術の幅が持たせられています。通常、規模が大きくなると、技術選定の自由度が下がる傾向にありますが、アンドパッドでは開発文化が変わらず、各々のチームが技術選定する土壌が変わらずあります。

また、統一された技術スタックではないため、エンジニア各自で技術交換ができるところは、エンジニアにとってやりやすいし、面白いところではないでしょうか。私自身も Ruby/Rails だけでなく Go も React も Vue も書きます。

―― エンジニアの裁量と技術を磨く場があることに繋がっているのですね。一方で、その技術選定方針がプロダクトにどう影響したのでしょうか？

素早く開発できる Ruby/Rails を選定して ANDPAD は大当たりしているので、うまくいったと言えます。また ANDPAD が成長し、リクエスト数が増加してきたところで Go を選定し、並列処理の利点を活かし、うまく大量のリクエストを処理できているので、技術選定が多様であることがプロダクトにも寄与していますね。

ノウハウの蓄積、資産の再利用が難しい

―― 逆に、困っていることやデメリットはございますか？

一つの技術スタックではないので、ノウハウなどの蓄積に工夫が必要になります。その観点では資産の再利用も難しく、例えば、 Ruby/Rails と Go 、 React と Vue などで再実装になることもあります。

―― 確かに！インターフェイスを工夫するなどで解決できるにせよ、シームレスにはいかないところですね

また、 Ruby/Rails で立ち上がってから、 Go がバックエンドの技術の 2 つ目に追加されました。そのときはそれぞれの言語に熱意がある人が立ち上げたため、その熱意から技術的なディスカッションとして意見がぶつかる、白熱することもありました。ぶつかること自体はよいことなので、今ではそれが熟練してきて、組織としても問題ない = 継続して開発できる状態になりました。

―― 技術をマルチに選定するということはいいことばかりでもないのですね

すべての技術選定には、よいことも、悪いこともついてくるもの です。ただ、このように進めるからには、発生するであろう、こういった痛みを乗り越えることも視野に入れている、ということです。

技術選定を行うエンジニアには何が必要か？

―― ここからは技術選定を行う "意思と責任を持つ" エンジニアについて深掘りします。この "意思と責任を持つ" エンジニアには具体的にどのようなスキルが必要なのでしょうか？

エンジニアであれば、誰でも技術選定ができるわけではありません。大きくは 3 つのスキルが順番に必要です。

技術を用いてプロダクトを前に進める力があること
リーダーシップがあること
少し先を視て、多角的な考え方ができること

技術で前に進める力とは "知らない課題でもやりきる" スキル

―― 3 つに絞られるとわかりやすいですね。一方で、人によって解釈が変わりそうな言葉もあるので、一つひとつ伺いたいと思います。まずは一つ目の "技術を用いて前に進める力" です。これはどのようなスキルでしょうか？

すべての技術を知っているスーパーマンはいません。ということは、必ず解き方がわからない問題や課題が出てきます。 この "知らない課題" でもやりきり、結果にコミットできるスキルが重要だと考えています。技術選定を行うエンジニアには複雑な課題を解決できる技術、10 年後に輝く技術などを用いて、それらの実行結果としてプロダクトや機能開発を前に進められる力が必要です。

―― なるほど、やりきる力ということですね。このスキルを身につけるには、どのようにするとよいのでしょうか？

前に進める力があるエンジニアをみると、いくつになっても興味を持ったことがあれば、その探求・実践を積み重ねている人、考えきった人についてくるように見えます。

多角的に考えるとは、人・リソース・時間軸を変数と捉えて、現実解を出すこと

―― 続いて必要になるのが、 "リーダーシップ" ですが、これはこの言葉の通りですね

リーダーシップがないと先に進めません。技術で前に進める力があることが最低限必要で、次にこのリーダーシップがあり、ここまでは出来るエンジニアが多い印象です。ただし、技術で前に進める力とリーダーシップだけで技術を選定すると博打になってしまい、誤った方向に進んでしまう可能性もあります。

―― そこで最後に必要になるのが、 "先を見据えて多角的な考え方ができること" ですね。この多角的とは、どのようなものになるのでしょうか？

中長期に見て、どこまでのフェーズを支える技術になるのか、開発組織の拡大にどこまで影響するのか、技術トレンドや採用市場はどうか、自身でメンテをいつまで、どこまでできるのか、といった人に関わるものが一つ。加えて、資金などのリソース、そして時間軸も視る必要があります。

―― 本当に多角的としか形容できないほど、多くの要素を視るのですね。最後に挙げられた時間軸というのはリリース期限などのことでしょうか？

期限もその時間軸の一つですが、それだけでなく立ち上げフェーズの一年なのか、グロースフェーズの 2 ～ 3 年なのか、といったことや、リーダー自身の将来のキャリアという時間軸もあります。

そして、ここで挙げた、人・リソース・時間軸は刻々と変わります。技術選定はこの 3 つを変数として、たくさんのステークホルダーが納得する現実解を出すということでしかありません。

―― 非常に難しいですね。先を見据え多角的に考えることはどのようにすると身につけられるのでしょうか？

このスキルは失敗を繰り返しながら、ちょっとずつ前に進んで学び、磨くほかありません。ゲームで失敗しながら、その失敗を糧に前に進むことに似ていますが、実際のビジネスでは何度も失敗することが許されにくいので、ここが難しいところですね。

技術選定は最高の開発、最高の開発組織を構成するための一部でしかない

―― ここまで伺うと、技術選定に加え、技術選定者になる難しさもわかった一方で、技術選定以外に重要なことがあるようにも伺えます

技術選定は、最高の開発、最高の組織を生み出す一部でしかありません。技術選定がすべてではなく、あくまで 決定的に必要なのは「人」 です。まず、人がいて、良い技術選定をして、良い開発者体験を作り、そうするとまわりの開発者も高め合い、良いスキルが身につき、活気に満ち溢れ、それがまた新しい「人」を呼び、ビジネスも続く、というスパイラルになるのが最高の開発、最高の組織であり、技術選定はその一部なのです。

―― 大事なのは、まず人であるということ、とても理解できました！今日は長時間にわたり、ありがとうございました！

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

アンドパッドの技術選定の進め方やエンジニアに裁量がある開発文化に共感・興味を持たれたなら、ぜひエンジニア採用サイトや募集中のポジション、カジュアル面談などを通じてコンタクトください！