アンドパッドのマイクロサービス基盤チームを紹介します！

はじめに

こんにちは、マイクロサービス基盤チーム所属のzigeninです。
前回の取り組みを紹介しました記事に続いてこの記事では、基盤チームについて紹介します。
チームの取り組みやチームに興味を持っていただければと思います。

チーム紹介

マイクロサービス基盤チームを紹介します。「マイクロサービス基盤チーム」と表記しましたが、アンドパッド社内では「基盤チーム」と呼ばれています。

この呼称には、

マイクロサービスは単なる手段であり、手段が先行して目的を忘れて欲しくない

との名付け親の意図が込められています。*1

用語の定義

はじめに本文で使用する単語を定義させていただきます。

コアドメイン：アンドパッドの事業に直結するドメイン
- 施工管理が該当します
  - 施工管理は建設現場のマネジメントです。ソフトウェア開発にたとえるとプロジェクトマネジメントに近く、ツールとしてはJIRAやGitHub Projectをイメージしていただけると当たらずといえども遠からずです。
汎用ドメイン：コアドメインを支援するドメイン
- 施工管理などのコアドメインに付随する機能です
  - 認証/認可などがこれに当たります

基盤チームの活動

基盤チームの活動の柱は3つです。

認可や通知などの汎用ドメインをマイクロサービス化する
どのサービス開発でも使える技術基盤/開発ガイドラインを整備する
コアドメインのマイクロサービス化を支援する

コアドメインには、それぞれに専任の開発チームがあります。建設業界固有のコアドメインについては、各開発チームがドメイン知識を豊富に持っていることもあり、各サービスの開発チームがマイクロサービス化を担当し、基盤チームでは技術的な支援やお手伝いをしています。

メンバー構成

メンバーはエンジニアリングマネージャ, サーバサイドエンジニア, Web フロントエンジニアの役割を担っています。

現在、基盤チームでは複数のサービスを開発しています。大半のメンバーは、複数のサービス開発を兼務しています。

開発の流れ

まず、開発対象のサービス決めです。CMO、エンジニアリングマネージャ、テックリードが開発対象のサービスの優先度を決めます。各メンバーからの志願や指名により、担当エンジニアが決まります。

チームメンバーは、マネージャー、Web フロント、WEB APIサーバ、バックエンドサーバいずれかの役割を担当します。デザイナはチームに常にアサインされているわけではなく、必要に応じてスポット参戦してくれます。

開発項目やその優先順位の決め方は、サービスごとに異なります。お客さまが直接利用し操作するサービスではお客さまの要望を重視し、間接的なサービスにおいては、開発者を重視して定める傾向にあります。

タスクは、GitHub Issueとして登録し、ZenHubのボードを使って状況共有します。基盤チームの範囲ではスプリントの設定はしていません*2。とはいえ期日がないわけではなく、必要性やサービスの性質に応じて期日を設定しています。

イベント

基盤チームのイベントは4つあります。

朝会(毎日)
- 毎朝20 〜 30分開催
- 大体の流れ
  1. 当番制で5~10分のスピーチ*3
  2. 各メンバーの前回やったこと/今日やること/相談
  3. 全体的な連絡/相談
gopher会(週次)
- Goの標準ライブラリのコードリーディング
- 静的解析などの発展的なトピックを学ぶ
- ジェネリックなどの新しいトピックを学ぶ
チーム週次定例
- 話したいことがある人がフリーテーマで話す場
  - ツールや技術のLT
  - 朝会で話すにはボリュームがあるトピックの議論
チーム月次定例
- 基盤チーム全体に関わることを話す場
- 議題の例
  - 開発対象のサービスの優先順位決め
  - 開発体制の変更

チームの雰囲気

基盤チームは落ち着いた雰囲気で、プロフェッショナルな集団です。事業内容や開発に興味があるという方におすすめできます。

筆者としては、キン肉マンソルジャーチームのような雰囲気を目指しています。*4。

現状の課題

基盤チームとして、今後取り組んでいきたい課題を紹介します。

組織面

メンバーは増加傾向にあるが、それでもまだまだ不足している
「アンドパッド = Railsの会社」の印象が強く、Go + マイクロサービスにも力を入れている印象が薄い
コアドメインのサービス開発チームで、マイクロサービス化を推進する流れを作れていない
- コアドメインのサービスの開発チームは現在進行系で機能追加や機能改善もしていることが主因です。ただ、マイクロサービスのメリットを伝えきれていないという理由もあるのかと思っています。

採用について

基盤チームでは、チームメンバーを募集中です。ここからは、基盤チームの採用について紹介します。

アンドパッド基盤チームにおいて経験できること

マイクロサービスに取り組める機会
立ち上がったばかりのスタートアップにおいては、マイクロサービスを経験することは難しいと思います。事業が小さくそれほどドメインがない段階では、マイクロサービス化することによるメリットに対してデメリットが大きく、マイクロサービスを採用することが少ないからです。アンドパッドのように、マイクロサービスに取り組める会社はそれほど多くないと思います。
技術選定の自由度
前回記事で課題に挙げたように、今後ノウハウを更に積みあげ、また開発環境を整備していきたい環境にあります。つまり、技術選定、導入がしやすい状況です。
そもそもマイクロサービスはサービス一つ一つが小規模であり、サービス間はAPIやメッセージングでやりとりするので、その中身がどう実装されているかは、サービス開発担当者以外からすると、それほど重要ではありません。したがって、サービスの技術選定に対して開発者が大きな裁量権を持つことができます。
仕組みづくりができる機会
技術選定と同様、組織や開発フローにおける仕組みにも課題感があり、挑戦している真っ最中です。

チームメンバーに求めているもの

基礎がしっかりしていること
当たり前なことが当たり前にできること
自分の担当領域だけでなく周辺領域にも関わろうとする姿勢
自分の知見や経験を共有すること
技術習得以外にも仕事の動機があること

まとめると、基礎がしっかりしていること、閉鎖的でないことを求めています。以下に各項目について具体的に紹介します。

基礎がしっかりしていること

基礎ができている人は、いろいろな場面に応用が利きますし、スキルの習得速度も早いと考えています。

たとえば、「AWS Cognito + Open ID Connectで認証を実現したことがあります! OpenID Connect/OAuth2の仕様? AWS Cognitoがよしなにやってくれるからよく知らないです。」というよりも、「AWS Cognitoは知らんけど、Open ID Connectの仕様をある程度把握しているし、やろうと思えばフレームワークもライブラリも使わずに自前で認証サーバを実装できるぜ」という方が良いと思います*5。なぜなら、Open ID Connectの知識の方がAWS Cognitoの知識よりも、より基礎的で汎用性が高いからです。Open ID Connectの知識があれば、AWS Cognito以外の認証の場面でも有用ですし、トラブルシュートも円滑にできます。AWS Cognitoの表面しか理解していないと、こうはいかないと考えています。

また、ある1つのプログラミング言語しか使ったことがないものの、その言語の文法、ベストプラクティス、プログラムが動く原理などの基礎知識が身についている人がいたとします。そういう方は、他のプログラミング言語を学ぶときも覚えるのが早いです。どの言語でも、根本的な所はそれほど変わらないからです*6。

当たり前なことが当たり前にできること

当たり前なことが当たり前にできるというのは、面接ではアピールしづらいですが、想像以上に貴重です。そういう方は、周囲のメンバーに不要な負荷をかけることが少ないので、一緒に働いていて心地が良いです。

修正した箇所はちゃんと動作確認する
エラーが出たらログをしっかり読む
ツールなどを導入したときは、導入した後の運用のことも考え、面倒を見る
分からないことがあったら長く考えすぎずに周囲に質問してみる
期日が守れそうになかったら連絡する
プロダクトマネージャーやデザイナーの要求を鵜呑みにしすぎず、自分なりに考えている
質問を受けたり、フィードバックを求められたら、リアルタイムとまでいかなくてもなるべく早く応答する

当たり前のことではありますが、私自身しっかりと守れるよう日々心がけています。

自分の担当領域だけでなく周辺領域にも関わる姿勢

基盤チームには基本的に、サーバサイドエンジニア or Web フロントエンジニアとして参加して頂くことになろうかと思います。この職種にとらわれずサーバやWeb フロントのことだけでなく、インフラも触ったり、チーム活動にも関わってくれると嬉しいです。

たとえば、現状では自分たちでインフラの構成を考えたり、設定を記述する必要があります。そのため、自分の仕事はGo言語のコードを書くだけ or TypeScriptのコードを書くだけではなく必要な技術領域には積極的に関わって頂きたいと思います。基盤チーム内の誰かにインフラの設定を頼むこともできますが、その人の負担も増えますし、作業待ちが発生して開発速度も落ちてしまいます。

自分の知見や経験を共有すること

前回記事で紹介しましたとおり、技術面で様々な課題に取り組んでいきたいと考えています。また技術選定の自由度が高く挑戦しやすい環境にあります。周囲に自分の知見や経験を共有してもらい、チームや組織にノウハウを蓄積していけると嬉しいです。

新しい技術や手法を試したり、問題にぶつかって解決したときに、自分の中だけで完結してしまうのは勿体ないことです。個人としては強くなりますが、チームや組織はそれほど強くなりません。いつまでも未開の地のままです。

技術習得以外の仕事の動機があること

「〇〇を習得したい(〇〇にはgRPCなどの技術的なワードが入る)」だけが仕事の動機になっている方がいますが、それを習得したらすぐに辞めそうという印象を持ってしまいます。技術習得を動機にすることは良いですが、それ以外の動機も欲しいと思っています。そのような動機の有無や強さが、成果の差になると考えています。