こんにちは！Recruiting Groupの高橋です。
現在BASEでは、エンジニア採用を積極的に行っております。
そこで今回はエンジニアの方向けに、取締役EVP of Developmentのえふしん（藤川）さんとCTO川口さんにBASEのプロダクト開発におけるエンジニアリングの課題や、今求めているエンジニア像についてインタビューしました。
採用活動を行う中で、採用候補者の方から「今BASEに入社してもやることあるの？」という質問を受けることもあるそうです。しかし川口さん、えふしんさん曰く、さらなるプロダクトの成長やコロナの影響によるスケーラビリティの問題など、開発において取り組まなければならない課題は山積みなのだとか。
また、なぜBASEは今もPHPを使っているのか・今後切り替える予定はあるのか、マイクロサービスに切り替えないのか、といった採用候補者の方からよくいただく質問についても回答してもらいましたので、BASEのエンジニア組織について深く知っていただけますと幸いです。
エンジニア向けの会社紹介資料も公開していますので、こちらもあわせてぜひご覧ください。
まずはじめに、現在の開発組織体制を教えてください
えふしん：BASEのプロダクト組織は職能で大きく分かれており、Product Devというエンジニアの組織と、Product DesignというPM、デザイナーの組織で構成されています。
Product Devはさらに「Service Dev」「Platform Dev」「Data Strategy」「Corporate Engineering」4つの組織に分かれています。
特に採用を積極的に行っているのはService DevのWebアプリケーションエンジニア・フロントエンドエンジニアとなります。
自分たちで物事を考え、課題解決できる組織を
現在の開発における課題を教えてください。
えふしん：「BASE」はこれまで、初心者の方が簡単に使えるサービスを目指し、プロダクトに向き合ってきました。しかし、ショップオーナーさんがビジネスを成長させ、規模を拡大されている過程で、「BASE」がその成長を支え続けるためにこれまで以上にスピーディにプロダクトを成長をさせ続けなければいけません。「初心者の方が簡単に使える」というコアバリューはこれからもずっと守っていきたいですが、成長するショップオーナーさんにも使い続けていただくにはどうしたら良いのか、ということを開発で実現していくことが今後の課題になります。
プロダクトをリリースしてから約8年が経っていることもあり、社外の方からはもうすでにプロダクトの機能ができ上がっているように思われることもあるかと思います。
えふしん：ビジネスを成長させたショップオーナーさんを支えていくプロダクトにするためには、まだまだ「BASE」としては足りていない部分が多くあると思ってます。
BASEのサービス開発においては、特定の機能開発や機能改善を行う目的でプロジェクトを立てて、プロジェクトごとに各職能のメンバーを集めチームを結成し、リリースまで行うという「機能別組織」で開発を行っていました。しかしそれではリリースしたらチームは解散、また新たなプロジェクトへ取り組むことになり、プロジェクトを継続し発展させられるような体制になっておらず、「問題が発生したら解決する」というプロセスになってしまいがちです。
今後は自分たちで起こりうる課題を考え、ショップオーナーさん方よりも先に提案できるようなチームを作りたいと思っています。特定のドメイン領域に対してチームを専属でつけてKPIを追いかけるような体制になっても良いのではないかという議論もあります。
職能別の組織ではなく、ドメイン別の組織を作っていくということなのでしょうか。
川口：でもドメインに対する組織構成が正解だとも思っていないです。今年の4月頃、コロナの影響で開発の優先度を大きく変更しましたが、1年前からドメインに対する組織構成だったとしたら柔軟な対応ができなかったと思います。あくまでも、今はこういう選択肢も視野に入れているフェーズだと認識しています。
えふしん：自分たちで課題を考え問題解決できるような、自分ごとで「BASE」を伸ばそうとする人が増えれば増えるほど、「機能別組織」と「ドメイン別組織」の両方の選択肢がアクティブに考えられるようになります。人材育成と人材採用の両方を考えているので、今いるメンバーにもより広い視野で考えられるようになってほしいと考えていますし、いろんな経験を持った方に新しく入っていただきたいとも考えています。
スケーラビリティを意識した開発がテーマとなる
コロナの影響によるアクセス増により、新たな課題も見えてきたと思います。
川口：ユーザー数・アクセス数が急増したことにより、性能限界みたいなものを感じました。今は対策を入れたため、ある程度落ち着いているように見えます。しかしこれを超えるようなことが起きてしまったとしたら、今のアプリケーションアーキテクチャと組織構造では厳しいという状況です。
参考記事：devblog.thebase.in
その課題に対して、今後の具体的な対策はありますか？
川口：今後は、中長期にわたりアーキテクチャの成長を牽引できる人を増やしていきたいと思っています。それから今までBASEでは、モニタリングツールをあまり積極的に利用していなかったのですが、最近はそのツールの使い方含め、アプリケーションモニタリングに教育コストをかけていきたいという方針があります。
えふしん：モニタリングツールなどを使い、日常の中で、サービスがどのように動いていくのかをしっかり可視化していくことが重要になっていきますね。アプリをリリースするだけではなく、サービスをきちんと運営していくという意識をもてるエンジニアを育てていきたいです。
サービスの性質上、データ量もどんどん増えていきますよね。
川口：お金に関わる情報を扱っているサービスなので、例えば数年前の100円の売り上げのデータ1つであっても、BASEではそれを決して消去してはいけません。それはこれからもずっと変わらず、データ量はこれからもどんどん増えていくので、それを意識した開発を進めていかなければいけないです。
えふしん：Webの技術には「機能性」「スケーラビリティ」「セキュリティ」の3つの要素があると思います。去年までの「BASE」はUXをはじめとする「機能性」の部分を支持していただいていましたが、コロナをきっかけに次のフェーズ、つまり「スケーラビリティ」の担保を求められているということがはっきりとわかりました。そこを今後強化していかなければいけないです。
「機能性」を担保しつつも「スケーラビリティ」を担保する開発は比較的難易度が高いように感じます。どういったことを意識して開発を進めているのでしょうか？
川口：機能開発では、今の状況だけでなく、数年後の状況を意識した開発が必要だと思います。例えば、ある機能が今1000ショップのショップオーナーさんにしか使われなかったとしても、3年後には10万ショップのショップオーナーさんに使っていただく可能性があるかもしれない。その時にその機能がそのスケールに耐えられるかどうか、ということを考えて設計できているかをレビューでは必ず確認しています。
また、「捨てやすくする」ということも意識していてます。3年後にもしその機能が必要なくなった場合、簡単に切り離せるような設計にすることも大切にしていきたいです。
今後の技術選択について
技術選定についても採用候補者の方からよく聞かれると思うのですが、PHP、CakePHPは今後も継続していくのでしょうか？
えふしん：今の「BASE」を維持していこうと考えたら残ると思います。今のコードに拘泥しているということではないのですが、二重の習得コストをかけて今から全部書き換えるみたいなことは考えていません。ですが今後合理的だと考える時があれば、変更する可能性もあります。
参考記事：devblog.thebase.in
こちらも候補者の方からよく聞かれる質問かと思いますが、マイクロサービス化に取り組んでいる会社も多々ある中で、今後BASEでもマイクロサービスに取り組む予定はありますか？
川口：現時点では、採用する予定はないですね。今のBASEはドメイン別組織にもなっていないので、効率がよくないと思います。
えふしん：例えばAmazonは、組織が拡大し続ける中、色々な開発チームが1つのソースコードをいじる度にコンフリクトしてしまうような、いわゆるカオス状況を解決するためにマイクロサービスを取り入れたという経緯があるそうです。そのようにBASEも組織が拡大し、生じる問題がマイクロサービスで解決するのであれば選択しますが、今のBASEはまだそのフェーズではないと考えています。マイクロサービス自体は先人の知恵だと思っているので、組織や事業の発展に合わせて取り入れていくこと可能性も今後はあると思いますね。
BASEが求めるエンジニア像とは
これまで開発における課題をお話しいただきましたが、そういった課題の解決に向けて、どういうエンジニアがBASEにマッチすると思いますか？
川口：自分で課題設計ができる人だと思います。反対に、「課題を与えられたい人」はBASEには合わないと思います。あと、経験年数はあまり重視していなくて、自分でサービスを作るとか、インターネットで何かサービスを運営した経験を持つ方がBASEには合っているかなと思います。
えふしん：僕は、個人のインターネットの使い方を信じている人が、BASEに合っていると思います。インターネットを活用して個人やスモールチームでも活躍できること、そしてその一角に「BASE」があるということを理解していないと、この仕事は楽しくないと思いますね。
PHPを書いたことない人は、BASEで働くのは難しいですか？
川口：言語で採用条件を縛っている訳ではありません。僕自身、前職はJavaだったので、 BASEに入るまではPHPは書いたことがなかったです。でも、一つの言語を自分の手足として使えるかどうかは重視しています。あと、一通りWebアプリはどうできているのを理解できているかも重要だと考えています。『Webを支える技術 -HTTP、URI、HTML、そしてREST』という本に書かれている内容が理解できているかは一つのポイントかもしれません。
いわゆる、フルスタックエンジニアがマッチするということでしょうか？
川口：フルスタックという言葉の定義が人それぞれ異なるという前提はあるものの、面接で時折「フルスタックに活躍したい」という言葉をお聞きすることがあり、詳しくお聞きすると「技術の垣根なく開発がしたい」という方が多い印象で、それって一般的なWebアプリケーションエンジニアに求められる要件と一緒だなと感じることはあります。
えふしん：かつては求人票の条件に「フルスタックであること」と書かれていることが多かったので、無意識でフルスタックという言葉を使ってしまっているのかもしれませんね。
川口：近接する領域は見れるようになっておいたほうがいいと思います。そのほうが自分で解決できることが増えるので、何かやろうとしたときに他チームにタスクを依頼して待ちができるといったこともなくなりますし、スピーディに開発を進められますよね。
えふしん：大企業でずっとやってきた方は、特定の専門領域や所属の部署で担当している技術だけやってきたので、技術の幅を広げたくて転職する人がいらっしゃるかと思います。BASEのWebアプリケーションエンジニアには近接する技術は当たり前にできるようになってほしいと思っていますし、そういう機会も作りたいと考えています。実際、Webサービスを作るのに必要な技術を一通り身につけられる環境はありますよ。最近の事例を挙げると、フロントエンド専任のエンジニアだけでなく、サーバサイドのエンジニアがVue.jsでフロントエンドを書くとか、先ほどの話にもあったモニタリングへの投資など、そういう取り組みは意識的に行っています。
川口：フルスタックという言葉は技術的な領域を指していますが、重要なのは技術領域ではなくWebサービスのライフサイクルを一通り見れるかだと思っています。Netflix社が書いている『Full Cycle Developers at Netflix — Operate What You Build』という記事に非常に共感したのですが、設計、実装、テスト、デプロイ、保守・運用までを一通りできるチーム、フルサイクルチームを目指したいですね。
Webサービスのライフサイクルをしっかり理解して開発・運用できるかがポイントということですね。具体的に、BASEのエンジニアはどのような行動や成果が評価されるのでしょうか？テックリードやEMになっている人の共通点を教えてください。
えふしん：「諦めない」ということが大切だと思います。あと、圧倒的当事者意識を持って、役割を自ら担っていった結果、テックリードになっていることが多いですね。自分で「こういうのを作りたい」ということを提案して、ちゃんとリリースまでやり遂げた人は評価されています。もしかしたら「わがまま」なところがあるかもしれません。しかし、自分のやりたいことと、BASEのサービスの成長過程においてやるべきことを適切に結び付けていますね。
川口：「頼まれてやっている」という感覚はないと思います。あと、失敗を恐れずチャレンジできることも評価されます。結構、自分の頭で考えて、あとはやったもん勝ちというところもありますね。
自分の頭で考えて行動していくことが大切だと。
えふしん：はい。技術選択について言えば、自分の頭の中で「なぜその技術を使いたいか」という明確なビジョンがあり、それをどのようにメンテナンスしていくかまでを考えて説明できることが大切です。CTOのOKが取れた場合、提案してもらった技術で実際に開発を進めてもらっている事例もたくさんあります。
川口：技術選択だけでなく、今あるコードではないコードを書くことも大切だと思いますね。既存のコードのコピペではなく、自分の中で設計を考えられたら良いと思います。僕自身も、自分が書いて素晴らしいと思ったコードも、1年後に見たら全然ダメだと思ったりします。でも、自分が書いたコードに繰り返しレビューをもらい、改善していく過程は、自分自身の血肉になっていくと思いますし、今のチームの皆にもどんどんやってもらいたいです。
失敗を恐れる必要はないということでしょうか？
えふしん：失敗はしてもらいたいですね。でも、本当に失敗してしまうと本人が辛くなってしまうので、最終的にはそうならないような体制の組織となるよう意識しています。モニタリングなどを通して、早く気づいて軌道修正していくことを組織マネジメントではテーマとしています。
川口：どんなに気をつけていても、誰でも失敗はしてしまいます。失敗しても新しい課題に気づくことができれば、成長に繋がっていくと思います。新しくBASEに入ってくださった方にもそう思ってもらえるよう、これからもチームで意識し続けていきたいと思います。
インタビューを終えて
インタビューの間、川口さんとえふしんさんは何回も「失敗を恐れない」「自分の頭で考えることが大切」と言っていました。BASEには「Be Hopeful」という行動指針がありますが、その行動指針を日頃の業務の中でも意識されていることが伝わってきました。
一見、8年もの間運営されている「BASE」はずっと変わらないようにも見えますが、その裏側では多くの変化が起きていることがインタビューを通してわかりました。
BASEではエンジニアを積極的に募集しています！記事を読んでBASEでの課題解決に興味を持っていただいた方は、ぜひ下記より募集をご覧ください
