お久しぶりです。エウレカで Head of API / Head of QA を担当している @takochuu です。

この記事は eureka Advent Calendar 2019 13日目の記事になります。

本記事では、私がHeadを務めているAPIチームの2019年やってきたことを紹介するとともに、学びを共有する目的で書いています。

あくまで主観的な記事になりますので、何か疑問や興味がある部分などあれば Twitter / Facebook でもご連絡を頂ければと思います。

APIチームの構成と役割

APIチームの発足は2018年4月で、メンバーは11月末まで7名、現在は6名のチームです。Pairs / Pairsエンゲージのバックエンドの開発を行うのがチームの目的になります。APIチームの発足前は、事業チームにバックエンド開発を行うエンジニアが属していました。

APIチームは特定の事業のみを担当するのではなく、エウレカにおけるバックエンド開発を横断的に実施し、ナレッジを共有することも目的になっています。

事業チーム(プロジェクト)との関係性はこのようになっており、複数のチームから依頼を受け付けて仕事をこなしています。

Image for post
Image for post

例えばAWSのコンポーネントを用いた開発やバッチ処理の実装なども行うため、「APIチーム」という名称よりは広い範囲の開発を行っています。バックエンド開発全般と言った方がイメージが湧きやすいかもしれません。

バックエンドを書けるエンジニアは他にも複数人エウレカには在籍していますが、彼らはSREに所属していたり、事業チームに所属しているため、彼らと連携してシステムを運用しています。

2019年APIチームのあゆみ

Pairs開発

Pairsは言わずもがなエウレカを支える屋台骨の事業です。

リリースから7年が経過しますが、主力事業として継続して開発を行っており、会社の中でもとても関わる人の数が多い事業になります。

Pairsは日本だけではなく台湾・韓国へも展開しており、サーバーサイドは1つのリポジトリで運用をしているため、翻訳アセットの管理や抽象化を用いて仕様の異なる部分を疎結合に管理するなどの工夫が必要な開発を行っています。

事業的な側面では、大切な価値観を表現できる新機能の開発をはじめとして、多様な開発を行ってきました。

Image for post
Image for post

技術的な側面でAPIチームが2019年に取り組んできたのは主に技術的課題の計画的な対応になります。

Pairsのサーバーサイドのコードベースは2016年3月にGoにシステムリプレースを終え、3年9ヶ月運用しているのですが、開発上の経緯があり、修正したい部分なども少なからずある状態になっています。

Pairsは利用しているお客様も多く、開発に関わるメンバーも多いため、サービスを停止しての技術的な対応を行うことは極力避けたい状態です。その上で、サーバーサイドの技術的課題を計画的に管理して事業のスピードを長期的に落とさない必要があります。そのため、技術的課題を無停止で計画的に対応していく必要があり、Pairs開発の文脈ではこちらを紹介したいと思います。

まずチーム全体で、自分が問題だと思う技術的課題を書き出してもらいます。

Image for post
Image for post

その後は、優先順位を付与します。優先順位の付加の方法については、以下のようになっています。

ここで気を付けているのは、あくまで事業から逆算して意思決定をすることを意識しています。エンジニアとしては「コードが汚い」や「少し取り回しづらい」と言った理由で直したいものもやはりありますが、そうなると全てやろうとしてしまい、結果として進まない、成果が上がらない等の問題も抱える事になります。

それでは本末転倒なので、現実的にやれる範囲を設定するようにしています。

こうして選ばれた技術的な課題については、3ヶ月単位でやらなければならないチームとしての目標(OKRは全社導入はしていないのですが、チーム内ではOKRを設定しています。そのKey Result)としてセットし、貢献については評価へも反映するようにしていました。

Image for post
Image for post

こうすることにより、進まない理由が多い技術的課題への対応を仕組みで対応することが可能になり、少しづつですがコードベースの改善が進んでいます。

Pairsエンゲージ開発

Image for post
Image for post

Pairsエンゲージについては、エウレカとしてCouples以来の5年ぶりの新規事業になります。

こちらの山下が書いた記事が詳しいですが、実はエンゲージはJimと山下の2名に加え、 Kentaro Takahashi (私) / Shinichi Jufuku の4名体制で開発しています。

APIチームとしては当時7名のチームでしたので、半分を超える4名がエンゲージの開発に入る事になり、APIチームとしての仕事量が大量に増えたことでチームの負荷が上がっていました。

これにより、組織的に取り組まなければならなくなったのが採用でした

採用について

エウレカにおいての採用責任はHeadが持っており、チーム内の採用活動についてはHeadが責任を持って取りまとめています。

それまでAPIチームにおいては、Headである僕が「カジュアル面談」と「1次面接」を担当していたのですが採用が急務となった今、何らかの権限委譲を行って採用にスケーラビリティをもたせることが必要でした。(Headは事業担当のみではなく、組織関連のMTGや1on1もあるため、候補者のみなさまを増やさなければならない状況にあってHeadがボトルネックになっていました)

そこで、API内での採用定例を実施し、以下のようなことを順番に決めていきました。

結果、これまで僕一人でカジュアル面談を実施していた時と比較すると採用に関するアイデアの数も、お会いできるも格段に広くなり非常に多くの方とカジュアル面談をすることができました(ご来社頂けた方、ありがとうございました!)

このように、採用は組織にとって生命線だと言われながらも計画的にリソースを配分し、組織立って継続的に取り組んでいくことが難しい領域だと自分もやりながら感じています。

このような取り組みを通じて手応えを非常に感じていて、まだ採用に至るという結果は出せていないものの2020年度についてはこの活動を継続することによって仲間を増やしていくことができたら良いなと考えています。

おわりに

このように、エウレカのAPIチームでは求められる状況に応じて柔軟に振る舞い、成長することで成果を目指すメンバーが集まっています。

2020年も非常に楽しい開発が自分たちを待っていると思うと、Headとして準備を今年中に頑張らなきゃな、という責任感を感じます。

この記事でご興味を持って頂けたら是非チームメンバーや僕と会って頂ければと思っています。ご連絡をお待ちしています!!!!


Image for post
Image for post
go gophers by Renee French CC BY 3.0

こんにちは。 Eureka API Team Head の Kentaro Takahashi です。

エウレカでは、エンジニア志望の学生さんを対象にエウレカについて解説するイベント Eureka Engineer’s Relationships を開催しており、今回はその2回目として Hiroki Kojima / Ryosuke Sugihara / Oyanagi Gaku / Daichi Harada が社員として、 Takahiko Tanaka が現役のインターン生として登壇しました。

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

主に、「エンジニアってエウレカではどのような働き方をするの?」とか「どんなプロジェクトがあるの?」「どのように成長したの?」ということを新卒出身の社員がメインにみなさんにご説明するイベントになります。

10分程度の社員によるLTと懇親会に分かれており、懇親会では好きな技術の話や、各々学生時代に何をやっていたかなど、登壇者以外の社員も参加しざっくばらんに話させて頂いています。

今後とも、エウレカとしてこのような活動を続けていきたいと考えていますので、ぜひご友人と誘い合わせていただいて来ていただけると嬉しいです。

エウレカでは、新卒としてだけではなく長期のインターンの受け入れも行っていますので、興味があればぜひ下記Wantedlyの「話を聞きに行きたい」もしくはTwitterで @takochuu か弊社採用広報の @nanase_117 へDMをを頂ければ嬉しいです。


この記事は、eureka Advent Calender 23日目の記事です。
前日は Mizuki Kobayashiの 猫でもできるDeepLearningの文章自動生成 でした。

自己紹介
このブログでは複数回登場していますが、はじめましてなみなさまはじめまして。eurekaのAPIチームで責任者をしています、@takochuuといいます。

趣味は酒とゲームとゼンハイザーの製品を集めることです。
momentum true wireless にはめちゃ期待しています。

## 概要
この記事では、今年4月に立ち上げられたAPIチームの変遷と課題との苦闘について話したいと思います。
同じようなエンジニアリングマネージャーの皆様、スクラムマスターの皆様に読んでもらえればと思います。

## APIチーム立ち上げの経緯
これまでは、サーバーサイドの開発者は各チームに散らばっており、いくつかの課題を抱えていました。
* 書かれるソースコードの質がチームによってバラバラ
* 各開発者が持っているPairsについての知識が偏っていて、組織立った活動ができていなかった
* 育成観点で、上長・先輩がチームにいないなどスキルの成長の阻害要因があった

これらの解決を図る形で、4月にされた意思決定が「サーバーサイドの開発者を1つのチームに集結させる」という意思決定でした。

Image for post
Image for post

APIチームは、上記の図のように特定の事業部のチームに属さず、事業部を横断して成果を出す事が求められる組織横断型のチームになります。

事業部に対してサーバーサイドが絡む施策については、事業部 <-> API <-> AI / SREとのコミュニケーションの中央になることが多いことから、次の2つがAPIチームのミッションになりました。

1.APIチームとして、JP・Globalチームに対しての情報共有に責任を持つ
2.長期的な技術投資が可能な開発体制を構築することにより、フロントエンドの要望を実現するAPI開発を行う事に責任を持つ

タックマンモデル

Image for post
Image for post

上記はタックマンモデルと呼ばれる考え方で、チームビルディングにおいての段階を表現したモデルになります。
プロセスには4段階あり、形成後、混乱を経て統一(目的・役割期待などが一致する)状態から、機能(力が目標達成に向く)状態になるというモデルになります。

すべてのチームは平等に上記プロセスを踏むと僕は考えており、APIチームにおいてそれぞれの期で何が起きたか、何に向き合ってきたかを解説します。

形成期 (2018/04 ~ 2018/07)

Image for post
Image for post

形成期は、タックマンモデル的に言うとお互いを全く知らない状態で、責任者に指示を求めるフェーズとされています。

この時期に、僕をはじめとしたメンバー8人はそれぞれ、Global事業・UI/UXチーム・マネタイズチーム・ユーザ獲得チームなど別々のチームから集まってきました。もちろん全員で一緒に働いた経験などはありません。

そこで、 yoh nakamuraさんに相談をしておおよそ3時間半をかけて「ドラッカー風エクササイズ」「Working Agreement」「インセプションデッキ」というワークを行い、相互に価値観を擦り合わせてチームがスタートしました。

同時に、CustomerCareチームからの土日の問い合わせ対応や、Globalチーム、JPチームとの関わり方をチームで相談しつつ決めていきました。 (この頃に、JPチームとしてカンバンでの仕事がスタートしていきます。)

その後は、APIチームの中でのMTGの進め方を定義したり、チーム内の日々の仕事をどのように改善するかという観点において話し合いを重ねることになります。

Working Agreementの中で「ペアワークを一度は検討する」というものがあったのですが、Pairsの中で機能の実装を理解している範囲が各々違い、新しい施策として行おうとしている実装が正しいのか、正しくないのか決めることができせんでした。なので、ペアワークはやめることにしました。

この頃はまだ、「長期的な技術投資が可能な開発体制を構築する」 ということに取り組むことはできていない状態で、目の前のタスクをさばいていくので精一杯。コミュニケーションの中央として機能することも遠かった時期です。

混乱期 (2018/07–2018/10)

Image for post
Image for post

混乱期は役割を意識し始める時期で、メンバー間の衝突が起こる時期とされています。

この時期には、ペアワークをやめて、JP / Globalそれぞれに専任で開発者を立てて開発していたのがこの時期です。
それにより、一時的にタスクが消化されていくが常にチームはパツパツ状態。
優先順位が高く、タスクの粒度が大きい(6ヶ月程度)プロジェクトを複数持った時に他のタスクができない状態になってしまっていました。差し込みに対して上手くコミュニケーションできていないことありました。

そこで、チームメンバーと話し合い、会議体を見直す事にしました。
これまでAPIチームで行ってきたMTGは「Daily Standup」と「振り返り」の2つでしたが、新たにナレッジシェアを目的とした「レビュー会」とチームのベロシティが阻害されていないか確認するための「Doneレビュー」を追加しました。

レビュー会
これは、週1回の頻度で出されたプルリクエストから粒度の大きいものや、見て欲しいものをチームで見て設計や書かれたコードに対して会話をするという内容です。
Pairsのナレッジをシェアすることと、設計・実装のクオリティを上げることの2つが目的になります。

Doneレビュー
チームの生産効率を阻害する要因(着手してからの待ちが多いなど)がないかを確認するためのMTGです。
Doneになったチケットを並べ、納期通りだったか、そうでなければどのような状態だったのかを会話していきます。

この2つを追加し、振り返りMTGの頻度を見直したことによって課題が見えるようになってきました。
しかし、まだ形成器と変わらずミッションに対してはできていない状態が続いていたため、僕たちは自分たちの目標をもっと具体的なものにして、自分たちで自分たちの行先を決めていくことが大事でした。

統一期 (2018/10 ~ )

Image for post
Image for post

統一期は、オープンな意見交換が可能になり、お互いを認め合う時期だと言われています。

この時期の10月にJamesがAPIに加入し、メンバーは合計で8人になりました。このタイミングで、元々やりたかった「長期的な技術投資が可能な開発体制を構築することにより、フロントエンドの要望を実現するAPI開発を行う事に責任を持つ」ことにトライすることを決めました。

1. 今のPairsサーバーサイドの中で課題をチームで洗い出し、12月が終わるまでにやるべきことを決め、やりきること。
2. 会社の技術広報としてブログの執筆
3. 古くなったAPI仕様書のメンテナンス

この3つが12月末までのAPIチームの目標になりました。

また、このタイミングからペア/モブワークを再開することにしました。チーム立ち上げから6ヶ月経ち、色々な開発を経験したことでチームのメンバーが開発を上手にこなせる状態になってきていたからです。

僕を入れて8人のチームは、以下のように分けました
・Aチーム: JPの最優先の施策を開発するチーム
・Bチーム: 柔軟に施策開発を行うチーム (領域はJPなど問わない)
・Cチーム(個人): Globalの開発を行う個人チーム
@takochuu: 全体のプロジェクトマネジメントや、課題の設定、MTGへの出席、外部への説明など

結果として、複数人で同じ作業(ペア・モブワーク)を行ったにもかかわらずチームの開発量は落ちず、設計・実装などのナレッジがシェアできました。

今は12/22ですが、今の所目標に対してはすべて達成可能な状態で推移できていて、本来のミッションにようやく近づけるようになりました。

学びですが、やはりチームの立ち上げというのは時間がかかります。焦って何かを変える、というよりも自分たちで気づいて変えていくことの重要性を感じた1年でした。
それに伴い、やはり自分の能力を上げる努力は常日頃やっていかないと取り残されてしまうと感じた1年でもあります。
医龍にもそのような言葉がありましたよね。

### これから
このような推移を辿ってきたAPIチームですが、来年はより事業を長期的に成長させるため、大きい技術課題の解決にトライしたいと考えています。

詳細はもちろんこの場には書けませんが、興味を持って頂いた方は @takochuu まで Twitterでmention頂ければ色々カジュアルにお話させていただければと。

長文でしたが読んでいただいてありがとうございました!
ぜひ、みなさまとお話するのを楽しみにしています。

それでは、よいお年を。

About

Kentaro Takahashi

Head of API Team at eureka, inc.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store